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 6A341C7115A for ; Wed, 18 Jun 2025 10:37:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5A6E6B0098; Wed, 18 Jun 2025 06:37:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C32046B0099; Wed, 18 Jun 2025 06:37:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6F0D6B009A; Wed, 18 Jun 2025 06:37:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A92606B0098 for ; Wed, 18 Jun 2025 06:37:02 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6DEFD141295 for ; Wed, 18 Jun 2025 10:37:02 +0000 (UTC) X-FDA: 83568168684.24.3C9453B Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by imf29.hostedemail.com (Postfix) with ESMTP id 85670120006 for ; Wed, 18 Jun 2025 10:37:00 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HLIHeSEw; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=21cnbao@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=1750243020; 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=l6qb0UH+1O/3k3BaasSuo+Now7ZqMn2I9gUQF913qFs=; b=iJh4tyXTXHlJMxVag/UXdlrchxRsH3r+ZQ+1/CQR/4YiiqBJ1/VpkFxBRCaMzHu2LAHOjy ESw1Xf1mmSybTZAwjjcTJCE5TZ6KsVSuSKAyesmmu4FNUEa8+wTJhFDwF7lxBH09GClJ5Q O6y5pWM9qUWELVnfc5DYGLkunAsa94U= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HLIHeSEw; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750243020; a=rsa-sha256; cv=none; b=CBXmKMFoQpxikPuCyJj/BAkbusm8cqfIwci8kt/3/JRX+ktfMYrdS1XAghanm7z/68gjDk MWjJaB7l5/usO6lNSDgeWyQJou2U2Sg9gcK2XkbCOmF3xQRCd4xladbSReE3yGPWzDRqOW GbdjPbofcs7ckWcyqx01r/h1QqEtcG4= Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-87ecdf5f326so380058241.1 for ; Wed, 18 Jun 2025 03:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750243019; x=1750847819; 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=l6qb0UH+1O/3k3BaasSuo+Now7ZqMn2I9gUQF913qFs=; b=HLIHeSEwXHwTP7whZlwkHLQ1w4UJ2XjsAW5CZKjxOvS5mM9B907PzckmHRWp4d+RFZ UtTjpblaVXGyQ0RKoxgkXVVNh5tBE2dL8YYVN1OYgBJsx24oCmb9CizmfOWi63bJZUJ1 /nt+Ka/30rvtr5mxqXKYv5R5Eq9En+UZo5nSi69lRNjvZuvJ61FTSQBFJldseeyzhBSB Uon58XKhfkWwaKPuKNVS1Y3p1knw6TOWkIJRtyemyJJFdPxrQxnCjv8XiGIby/7tuqIf PbF11H9+WOtT4sPspDU/8+0JYbsMIjjhcFzHzR2bYH2yL980qbKXc5XjLmy9VflJ2Scm ukKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750243019; x=1750847819; 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=l6qb0UH+1O/3k3BaasSuo+Now7ZqMn2I9gUQF913qFs=; b=d+IVMx3os9X2NGcZoLcJG8/TqXxQQc1gXGCIR2kyyIrqw15R5ad/JtLzKrc+TFf4pS MLVuPe5/w01IOWEj3CaY1DhLlXIP6XpyItBiBP2IbnyvI4vEHOa4pjqvHNlN5Y1F9y3L ACyz/H6x0lvq/JvPvYX7Lo8TaIh1XfW1iedKLoVVuH2LvEBn6uSYIy9RNRlQVbNZ7QS3 qskF0RC9PEDseQ4DqGdN+AefzQgAeb7FNslHkTOSHBAJxfNMh7Fl3gb7LYLNhxdzHRmA 48zwwUlrY90eL/jsfevlblXISC0njBXzdn9PkfAdKZV7QG2/dmnhPZOrjZeXFgqcLOqi Tg7w== X-Forwarded-Encrypted: i=1; AJvYcCUyEbcshtaaPj3CnyfDtv0CAmkVlCfJ8DOpyRhqoKY3mkLQO0IY1ghHUxjnyERe0AyI4X7Fo/pakA==@kvack.org X-Gm-Message-State: AOJu0YwkQhlp+gsHsEjDt6xpkPBGAO46JVEmO0lCy1ldQAMK+K3l7PH8 boQsJ0lr1+9rYRc422zKQAI79X4OROAgfRLEGouyHpPTRj016unWIpKuS8/Gb1wYJMIAnS07SZv PY7GJi/fiGX5N5319Io7tiCiGvjSOzk0= X-Gm-Gg: ASbGncv9jAZ2v2SSeJxnOGrYxjM9rUe0tNgX1XBYX40s7WZPI5k9ArmBgSESlJe6bjt Lj4zL1mY7KgtIZZ9qY0+i7THHYSSxGE/jeEoHQaKIYwED8YLz/ZSHpB16onjY/5BY3+nDMT032h zOROainswk51YTFlLCcCkFanJaoq7xdOPQCdALTE7TY90= X-Google-Smtp-Source: AGHT+IGrQTi1dFQKKC+4Tva42Wjpw/WTHK3Uw+fY6TyPSlSCJM6XkQXHvYhRRxeMSBv55713BrZWXfpy7EhrkPvU4x8= X-Received: by 2002:a05:6102:2924:b0:4e7:b77d:7fe1 with SMTP id ada2fe7eead31-4e99729dffdmr918481137.0.1750243019526; Wed, 18 Jun 2025 03:36:59 -0700 (PDT) MIME-Version: 1.0 References: <20250607220150.2980-1-21cnbao@gmail.com> <309d22ca-6cd9-4601-8402-d441a07d9443@lucifer.local> <05d38430-3512-49b0-90da-1ae7a617a377@lucifer.local> In-Reply-To: <05d38430-3512-49b0-90da-1ae7a617a377@lucifer.local> From: Barry Song <21cnbao@gmail.com> Date: Wed, 18 Jun 2025 18:36:48 +0800 X-Gm-Features: Ac12FXzIhZQUu9QnNEnKJxKSW7chiutKLCuzqNt1W6Lvw2Zz1bxp0MqK3U7Qeh8 Message-ID: Subject: Re: [PATCH v4] mm: use per_vma lock for MADV_DONTNEED To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , "Liam R. Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Suren Baghdasaryan , Lokesh Gidra , Tangquan Zheng , Qi Zheng , Lance Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 85670120006 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: qjxd6wb4pctiy8cd3sjuaeue7ipsytuw X-HE-Tag: 1750243020-181113 X-HE-Meta: U2FsdGVkX19AXK4Xdl8ORvmK+c3LSIwMK3h4oDwqirOHkgNzHJEHEkImhYTzdqyI/4jr4j+ZadK7yQib3hZBtJZqUcbt0kmIZZqWQXT9HktqIo3uKaLuO+0L+SUl/D7dLh5FtmZ7GFTO5pqE0dczuVXhy8KcOWdrH6Wt11B2pVVXAp53V/RHdsLKAEEgAg2s02Ts8SLOBJr/PUgitw45OYDdkrdwBgj+QgwNEvTOLEStSTAJeh9PwINVoKn7V41XyPXg4CnsCiykdGIVWCnJIeyBZSdBEQJjZzT4SHQFl/xkxJcHYCwOeM9YBuKZb1em5snyYJHfqMmvZ5drIgTcYV80NcJSxsRHF9+iXxYrsqS2wtvWKveBFVpsnjKlN/ew/oJLbKFwDvXjwhayhKhHHyBmRbJqMuMdXrJDIbZN/gqpy8Mojn4Rfnglk9HIUeJsbG3lU2EmHwl594trP2xHE7L+WntgKC9lbC0jEUhSjfTR/5DDhfMi1OWsOUfImL2TZDnvwg6kYeZuBE+mgJcs4UBUDMs4jMvC2WlPQP6xOMeZxYJXUOk0fHTJ+6w1IMiPokHMXnAgZTYhbPvBBae9+HI4X7wK6k5NRiKl4diwqMPbSvEVOimc8FWu8nD93qDxWViwQBC2Q7HCN+5QWsUhiaUPq0OXRo4E9CVSRaqLQBB7aC3OBV953QKIiGacNzmDBE6SuuZgOjSH364Be0ye4jubH65WCZvC92PkHFhe1IvMX/UHXCDHGDkXfAesw0pAT1RB46XEVFjb2NOsuxSGr08+y2L2IS4zyjn67vfrnTUbAzcvLVXqDa6UMH8PT1nkjBnPFM60t6tunVKF/isdn/Msun9fbFzX7b98cid5Uy19qH1dDIg0OAf32HWUw3W57VQSN9ehEr1tKSwvmn8uLME9gb1R76/GVr7SoQUZnpK3b78WsAceKYguDNQQr5rpokiQQVXStxtwVY8ox2q wnQV6+ev yf7PH0DKXDQtNk/F2L+JCBeFWprh4jWdYGGQPZPWEWmaiu5YVAdrcfC8/st+8VK3oTN+EfAXXfpCRPeX8pU5WRwmb4L2eUW+Nr1m2Fq2F9T4O+giIcr9l7VbIb+sJ7JaymKp2X3dAx42lwPdds2sLFv8ndm6H4KhU85Qf5nz+yX4EEQspBACqr/qHMSJNBCavCsLpVcYJw4oI3wdHCYBwMGt4G/++xUiUe4DWfms1iaAXJ1NCjqUIN74mVivivUyqwus705fTuAj0Tylb0Df18CiAltsbwuNAF8rMy6ge4y7ViS2K8lsj4kTw2RP9LYhkUzlaDBy0ThDNBKf1cQSHZkhugiHQ6tXfUaa0ZFQ2uCU5wSKDKLjVskERBrBpBpJ6tmzMVLGj8mpEWtbzioA0MPRmJs6s+CUbLpz4 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 Wed, Jun 18, 2025 at 6:33=E2=80=AFPM Lorenzo Stoakes wrote: > > On Wed, Jun 18, 2025 at 06:11:26PM +0800, Barry Song wrote: > [sip] > > > ----8<---- > > > From 1ffcaea75ebdaffe15805386f6d7733883d265a5 Mon Sep 17 00:00:00 200= 1 > > > From: Lorenzo Stoakes > > > Date: Tue, 17 Jun 2025 14:35:13 +0100 > > > Subject: [PATCH] mm/madvise: avoid any chance of uninitialised pointe= r deref > > > > > > If we were to extend madvise() to support more operations under VMA l= ock, > > > we could potentially dereference prev to uninitialised state in > > > madvise_update_vma(). > > > > > > Avoid this by explicitly setting prev to vma before invoking the visi= t() > > > function. > > > > > > This has no impact on behaviour, as all visitors compatible with a VM= A lock > > > do not require prev to be set to the previous VMA and at any rate we = only > > > examine a single VMA in VMA lock mode. > > > > > > Reported-by: Lance Yang > > > Signed-off-by: Lorenzo Stoakes > > > --- > > > mm/madvise.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > > index efe5d64e1175..0970623a0e98 100644 > > > --- a/mm/madvise.c > > > +++ b/mm/madvise.c > > > @@ -1333,6 +1333,8 @@ static int madvise_vma_behavior(struct vm_area_= struct *vma, > > > return madvise_guard_remove(vma, prev, start, end); > > > } > > > > > > + /* We cannot provide prev in this lock mode. */ > > > + VM_WARN_ON_ONCE(arg->lock_mode =3D=3D MADVISE_VMA_READ_LOCK); > > > > Thanks, Lorenzo. > > Do we even reach this point for MADVISE_MMAP_READ_LOCK cases? > > madvise_update_vma() attempts to merge or split VMAs=E2=80=94wouldn't t= hat be > > a scenario that requires a write lock? > > Well we're relying on happening to reach here with the correct lock afaic= t. > > I'm going to be doing some follow-up series to clean all this up! > > I'd rather keep this in here for now just to ensure we don't miss some st= upidity > here. I have no objection to keeping this as-is=E2=80=94just curious if using VM_WARN_ON_ONCE(arg->lock_mode !=3D MADVISE_MMAP_WRITE_LOCK) would be more accurate. In any case, your cleanup series will address this, so it's probably not something we need to handle right now. > > Thanks! > > > > > The prerequisite for using a VMA read lock is that the operation must > > be safe under an mmap read lock as well. > > > > > anon_name =3D anon_vma_name(vma); > > > anon_vma_name_get(anon_name); > > > error =3D madvise_update_vma(vma, prev, start, end, new_flags= , > > > @@ -1549,6 +1551,7 @@ int madvise_walk_vmas(struct mm_struct *mm, uns= igned long start, > > > if (madv_behavior && madv_behavior->lock_mode =3D=3D MADVISE_= VMA_READ_LOCK) { > > > vma =3D try_vma_read_lock(mm, madv_behavior, start, e= nd); > > > if (vma) { > > > + prev =3D vma; > > > error =3D visit(vma, &prev, start, end, arg); > > > vma_end_read(vma); > > > return error; > > > -- > > > 2.49.0 > > Thanks Barry