From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA4CAC25B76 for ; Mon, 3 Jun 2024 15:46:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C2B46B0092; Mon, 3 Jun 2024 11:46:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54C296B0093; Mon, 3 Jun 2024 11:46:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C69C6B0095; Mon, 3 Jun 2024 11:46:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1B5DC6B0092 for ; Mon, 3 Jun 2024 11:46:51 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9972014018C for ; Mon, 3 Jun 2024 15:46:50 +0000 (UTC) X-FDA: 82190005380.17.4116B76 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf30.hostedemail.com (Postfix) with ESMTP id C2A6580012 for ; Mon, 3 Jun 2024 15:46:48 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gVSEER3r; spf=pass (imf30.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717429608; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jnfJd+lacSEBp37hacsO6bP3SrPCDbi68n4xf8Hh4fw=; b=UBosghKRdDIlB1ICHASiEMf9nRf77uZjr0kz/yl4VFtrlHn2sZqquGhN2ZtEGqr4vogg5S BjZRLMiBlbxZ5QnyX8M1bVsNYEmEyGtrNPcTGYD5PNX25LJfjLn5MdFfQmje5PEVvLdGzt Pz317Bw851fIluamqdubl3vjU3Av5Ls= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gVSEER3r; spf=pass (imf30.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717429608; a=rsa-sha256; cv=none; b=3DbNqcve4VMIWoTJ9cTFMU5k2Ufqc2q9QstwwGqJPzafIjvN1WTYarZec8AHA/h8bfAYYb fJca6z44dEHrglij7bOIMnZVJxnM6SmL0iS6aVniIBf04kHyKlQITjHRB0smY7IzpEIArl miJoYEHlIEJK1wtcS2LekVjn5iX749M= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-57a2406f951so4767591a12.1 for ; Mon, 03 Jun 2024 08:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717429607; x=1718034407; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jnfJd+lacSEBp37hacsO6bP3SrPCDbi68n4xf8Hh4fw=; b=gVSEER3r66DhtVuinQL6xwsIW0BSypVYQKNjZtkUG+DxEgCNghoeavA0KxI/nsIdnx G3AlVhyl/qnyHinPuKKxsSL+7djwYz5sgFqeM5VeelKDGnd/pIRPIF4GlGCD00TVsGQb vYCOs6IhoCmxDslNRfWoFEQduHWhTMit9QCZ6Z3VhtGUINhFKW3CsaEarkXffISH8UH8 26lEjq1gJrwIt/Y8kMvnK6Lh88PEUdZ600tZpBzmoDnsT7JSWpSe3mov2LMt+4cWSQWD jpQq6uqxxwPmHbtZD/OPSx6toEqFVT8iLIcqHhVvTe3pzCj146GxuqvyXK9lPYlq8WiA eH6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717429607; x=1718034407; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jnfJd+lacSEBp37hacsO6bP3SrPCDbi68n4xf8Hh4fw=; b=IRhS9rThXLYaP74nrt9Tomi+ltU/bgcTO+maimGFBGimdWUzGEraNvKS0462B2Tp3o Zg7bAbJDJGK0BZc6Sr02XQHCkccXp0k+ZX8RJ9D2sgK7rH2Jw4iYffaLiucmGIVpluIn QFBdGw/EsSa6KqT39VZgAtccJzibeqGL//cBRo/kOs+tl5a4d6CPiB4ExI3Rxx+yXjVL WuD4yZvNJvNtmLW34nXJ1un+X13cc5xq1ej1HtWn58QESSWj5yJ9gDbnyIuPXB9igt+z 66sU7M4eGfIQREs4C6v0ADGz24Y7Lgfhton+8pUbV7APPzwOp3HFekjePMXDyrHhWQo5 yjJw== X-Forwarded-Encrypted: i=1; AJvYcCWf6YU+q1MAp9F1Jh23B2JXy9hTEGnIs77dyoV9y44z3ysc3/OH68kwKINsOwedrIWmBuNoRx7g+p2SzOqwzhydyXw= X-Gm-Message-State: AOJu0Ywu5Y/6TWQ/O5U/X+4k3uoBtP/SEc8Mv9AMONBx55Vd2KZZjoYx bGo1GWE2ES1Z6ZPO6U2zfDuLkNkGN3YY7nG6ImgjR43qp4xJGAbGkNEtLPNWUHh1hNAYiNHTd21 +VlWiONsO1A28zOLTYGj5hcUzKV53WwnoM6E= X-Google-Smtp-Source: AGHT+IH5lMgmQGkOya9kL/O3tdhpGKBIaAMuCKPUcjlzlO7HWIBEj6o9klkQSNbuUx2CcQ6Q73Lfn1wbQhv7v/mo6n0= X-Received: by 2002:a50:d6d4:0:b0:57a:23d9:9ef6 with SMTP id 4fb4d7f45d1cf-57a5b7ac3c7mr2973799a12.25.1717429607199; Mon, 03 Jun 2024 08:46:47 -0700 (PDT) MIME-Version: 1.0 References: <20240603140745.83880-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Mon, 3 Jun 2024 23:46:35 +0800 Message-ID: Subject: Re: [PATCH v2 1/1] mm/mlock: implement folio_mlock_step() using folio_pte_batch() To: David Hildenbrand Cc: Matthew Wilcox , akpm@linux-foundation.org, ryan.roberts@arm.com, 21cnbao@gmail.com, baolin.wang@linux.alibaba.com, ziy@nvidia.com, fengwei.yin@intel.com, ying.huang@intel.com, libang.li@antgroup.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ob7p5xfepmock9enjdp49ssk465x1u1h X-Rspamd-Queue-Id: C2A6580012 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1717429608-817776 X-HE-Meta: U2FsdGVkX1/pOJIoOjrOgGLsr0xNzIs543NCKw1oQpqIRCeZdLVNDn8+ZnZLmBH2M+ADwnwIKklTZtRGOy+OCkt+dnoYBNCIgBXvitK3CWBSTvNgWMBXnF/Vc1md5lMV7FVVSLr6AqId/DOLsfTLFWtiDqgcoT9gy0oICgwGY69FnIlHUWAMJBRvroUq6NCfW6Te5OTZuEDLEw4siQBU7dOKHPo9zErFNEu6R/fC2KwSccjZvSbivSRhTBFjWHqUOV1H3dTzIAL6Hrnxxx9T2xTQU0a4h9HmgNHXW/VdHNqV/rCdRQicP8YuRZAjoFGx/BWMwEhmtKMQmmlJBq2BGztXBy5OF4kUsVoiCAktRhiT7xGvq7JPsC3nYvJa3O6Yi9+cZ/G8/MWX65DjwCHhjxgxW0thva54PHM1YiiYwO44sy++EKYv5oE9s+uKf8+CUqDXc+inbD1DD3gWJYM9/wjRIhBMY/Dge0rE6IlzEef8HaqPav7Hplu8N66ukxO1+w7qxJf3r67MbqB8sxqw8Y4LGnSI+42R4DTtMdQ1ndegU0+26ZcnEHAfilRNYasmF3sX4+Kw8VI5f2T7o3VmJjGqAgnIKWSgLTDh0lLhzMJBe8iIi6WW1nyt4IQwDrfHvfQ3Di8ovxWAfN8tTqFQi1jW+a6kc4JC7bLJhIfVh4Q/BI1nNSWbt7/6B8bcwGD38EyVQ1eRamftguFpGJg29Bs1fDf3JjMeFtGXUYuC+bGL+qVfNoj1jKzL7lOYmltQaWwdJxhwscGqWhj1SLuLQVKdF/mjiJ6DcCZHXWtqNZ7mno78K7ECt9Q5Sbo8PgHVsDuHerWyZNIHkYef1qpBXqLCjP7mx8zjcB9Cmd03tSBwsCNTbVTD2xrGnaHwqP0wgpMcnTvYGWVKlbFhjkYK+9DlDForfAQ3jLKsW1Nd0NrJpoTHym7E6a9tubp4t6fokK2o8YgegLOiau2CDYw YqKjQlTj /P0cVK2lV1G6dF3R3wUQn4OAUQcU/Z0gF7rsMmEF/pEINnJydvRYujz4jgGG1uEPKLrhZFLSpDZsB8FIPDStDFZFmrjszvXrYRyOndIZJiEO7ggMPzrY0s45HBT/zOVmpbakG/0BxI9sDdHirUDS48axIrQSmuyXBbFtNzWiIVawEgkG/nQALUk3amnSubMUv9Tvk+Wke1yN6+71OCr6TuvAT+PgznCjV/ldIvytjHiQq8XKJiH8ZHG7C7ET7k7wcNijncSkXMV6isToC1niEQc5cEL8otkBAQzJVZQfVp/MuaE/w7+CgbsAYRs5ONiJq0nsvQynCbQZSNcK5gMcBQu/bYGRXmIxQ7pvcTLsejMmOM8gKBajwT6PP9t+m/5M+PFz4ZwGbnMYlAZmtMGnBqMN4Qoc4bR5zvGW6TwrIJirGTK8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jun 3, 2024 at 11:26=E2=80=AFPM David Hildenbrand wrote: > > On 03.06.24 17:01, Matthew Wilcox wrote: > > On Mon, Jun 03, 2024 at 04:56:05PM +0200, David Hildenbrand wrote: > >> On 03.06.24 16:43, Matthew Wilcox wrote: > >>> On Mon, Jun 03, 2024 at 10:07:45PM +0800, Lance Yang wrote: > >>>> +++ b/mm/mlock.c > >>>> @@ -307,26 +307,15 @@ void munlock_folio(struct folio *folio) > >>>> static inline unsigned int folio_mlock_step(struct folio *folio, > >>>> pte_t *pte, unsigned long addr, unsigned long end= ) > >>>> { > >>>> - unsigned int count, i, nr =3D folio_nr_pages(folio); > >>>> - unsigned long pfn =3D folio_pfn(folio); > >>>> + const fpb_t fpb_flags =3D FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRT= Y; > >>>> + unsigned int count =3D (end - addr) >> PAGE_SHIFT; > >>> > >>> This is a pre-existing bug, but ... what happens if you're on a 64-bi= t > >>> system and you mlock() a range that is exactly 2^44 bytes? Seems to = me > >>> that count becomes 0. Why not use an unsigned long here and avoid th= e > >>> problem entirely? > >>> > >>> folio_pte_batch() also needs to take an unsigned long max_nr in that > >>> case, because you aren't restricting it to folio_nr_pages(). > >> > >> Yeah, likely we should also take a look at other folio_pte_batch() use= rs > >> like copy_present_ptes() that pass the count as an int. Nothing should > >> really be broken, but we might not batch as much as we could, which is > >> unfortunate. > > > > You did include: > > > > VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio= ); > > > > so at the least we have a userspace-triggerable warning. > > Yes, and max_nr =3D=3D 0 would likely not be healthy to the system. > > But > > For copy_pte_range(), zap_pte_range() and the madvise users, we should > always have: > next =3D pmd_addr_end(addr, end); > > and use "next" as the actual "end" -- not the VMA end. So "end - addr" = =3D > "next - addr" should never exceed a single PMD size. > > > mlock_pte_range() is also called from walk_page_range(), which uses > next =3D pmd_addr_end(addr, end); > > So likely exceeding PMD size is not possible here and all is working as > expected. Thanks for clarifying! I agree that currently all is fine, so perhaps we don't worry about that :) > > Will double check later. I did a double-check and you're correct. Thanks, Lance > > -- > Cheers, > > David / dhildenb >