Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     Jann Horn <jannh@google.com>
CC:     Suren Baghdasaryan <surenb@google.com>,
        "willy@infradead.org" <willy@infradead.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "michel@lespinasse.org" <michel@lespinasse.org>,
        "jglisse@google.com" <jglisse@google.com>,
        "mhocko@suse.com" <mhocko@suse.com>,
        "vbabka@suse.cz" <vbabka@suse.cz>,
        "hannes@cmpxchg.org" <hannes@cmpxchg.org>,
        "mgorman@techsingularity.net" <mgorman@techsingularity.net>,
        "dave@stgolabs.net" <dave@stgolabs.net>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "ldufour@linux.ibm.com" <ldufour@linux.ibm.com>,
        "laurent.dufour@fr.ibm.com" <laurent.dufour@fr.ibm.com>,
        "paulmck@kernel.org" <paulmck@kernel.org>,
        "luto@kernel.org" <luto@kernel.org>,
        "songliubraving@fb.com" <songliubraving@fb.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "david@redhat.com" <david@redhat.com>,
        "dhowells@redhat.com" <dhowells@redhat.com>,
        "hughd@google.com" <hughd@google.com>,
        "bigeasy@linutronix.de" <bigeasy@linutronix.de>,
        "kent.overstreet@linux.dev" <kent.overstreet@linux.dev>,
        "punit.agrawal@bytedance.com" <punit.agrawal@bytedance.com>,
        "lstoakes@gmail.com" <lstoakes@gmail.com>,
        "peterjung1337@gmail.com" <peterjung1337@gmail.com>,
        "rientjes@google.com" <rientjes@google.com>,
        "axelrasmussen@google.com" <axelrasmussen@google.com>,
        "joelaf@google.com" <joelaf@google.com>,
        "minchan@google.com" <minchan@google.com>,
        "shakeelb@google.com" <shakeelb@google.com>,
        "tatashin@google.com" <tatashin@google.com>,
        "edumazet@google.com" <edumazet@google.com>,
        "gthelen@google.com" <gthelen@google.com>,
        "gurua@google.com" <gurua@google.com>,
        "arjunroy@google.com" <arjunroy@google.com>,
        "soheil@google.com" <soheil@google.com>,
        "hughlynch@google.com" <hughlynch@google.com>,
        "leewalsh@google.com" <leewalsh@google.com>,
        "posk@google.com" <posk@google.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kernel-team@android.com" <kernel-team@android.com>
Subject: Re: [PATCH 28/41] mm: introduce lock_vma_under_rcu to be used from
 arch-specific code
Thread-Topic: [PATCH 28/41] mm: introduce lock_vma_under_rcu to be used from
 arch-specific code
Thread-Index: AQHZJGyfeVOZgHFEukOrFFAlqbUFgq6jJWgAgAAlmwA=
Date:   Tue, 17 Jan 2023 23:18:03 +0000
Message-ID: <20230117231756.tlfk7zjtpk6uio4j@revolver>
References: <20230109205336.3665937-1-surenb@google.com>
 <20230109205336.3665937-29-surenb@google.com>
 <CAG48ez2cK1M=fgkYi4bPdWX7uOm15Omv6EjFgXUkS2QsqiwGSg@mail.gmail.com>
In-Reply-To: <CAG48ez2cK1M=fgkYi4bPdWX7uOm15Omv6EjFgXUkS2QsqiwGSg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?bdR70oV3ubAfFIncKN61hruC2cB7R3gKG8bsENxyHVk7Sa7EcClDnF5EoKC8?=
 =?us-ascii?Q?Vr6RO1nWSZhM03wCW0jQaXMxQwHuoW8AdnUz8IT3LayswVwiEcMWt6VilcQQ?=
 =?us-ascii?Q?oXwiHHeqQbM0TzK3ajVuwfkIfqVsm3/CE6vUEBwkCeYXyrNjmc+CKwjjSzpI?=
 =?us-ascii?Q?CZgspyfFNpA5ySGWdIkshQMV0k+aWDTQ01huWBweb1Nu38e97XyZVzYMphqH?=
 =?us-ascii?Q?zc/up6nu54j/ch5Fz22U6mbNZ53tOJzH2p8bVgSovo7x5TfFwh/vYWzkxZa3?=
 =?us-ascii?Q?vOBwyF4lhccDGo3IEuXMJPB0k9v6whSwpdSU1FbOUPuXpEhNbNjJwAeFhcoQ?=
 =?us-ascii?Q?QRQP8hlSWXEpNf+mSEKWIKlaFuy2fP37DEHg6HUIJ2XO1dt22TRkqQWlAjpK?=
 =?us-ascii?Q?YyPikKu45WohQ/Vrg0qoOSBK1ru2FaVFvP0CyU4hfQLc+weXS7JVAClqEdvu?=
 =?us-ascii?Q?SZOqsnB38KJUIohcrvDsbEp4MeVThzzxv6AqPEGBNVLKGxdhp/WeHeC2c2Yu?=
 =?us-ascii?Q?jEXuZGU/kGkW32i0NTTTfrZ8zDwiTcVjR0Mvo3Y507fMyylGt7b4qCkU5TxZ?=
 =?us-ascii?Q?3GQEVo9z3ZhbJc52sd1oCAiHtm/GFjzLnu3UEKmKJ0gFD/WC8stteZ5psSfS?=
 =?us-ascii?Q?PmYYlS0W03kbejNt/aUNNuVTFX5yk2TMH6GFYlYruriaup6SCdW7XGrqBg4K?=
 =?us-ascii?Q?kAgiI4LyZCMKn7Do0cU/cir77ODS0jfv8vgXLAOmY2bUY8gMpqpGcSWGmfn/?=
 =?us-ascii?Q?WtG3fhDH1F96w1aG+vy5it58VwaJa0I5K5++4wqCKGxIY1L+682a4RAZkaR/?=
 =?us-ascii?Q?i+ag7S6RQ9JuvM68x+d7CF+K26JPwMBAihbGa82KP89p8VoLnLhHaY5jJ0X5?=
 =?us-ascii?Q?5z+r8bcR1VtD09iMK+V8KTgqQqsflYb909u58Ciu40u3nH0pEAg4YIhcgCmU?=
 =?us-ascii?Q?EljDAsFY6IS3tir+vKgqOV9eZDwf58AWTocVyRsJzcMNUZtUP3XWtIo0yEBf?=
 =?us-ascii?Q?j5vJKnMH5V5IeBjzwlbpPWq+J5eqeI88oRYCvJr5Dv9lUxyFjqF+OX+veR7C?=
 =?us-ascii?Q?CqBzGVH1M6+xp8XYqAYg5Ru/QlQGwu/Ge3kKno+zVUlC8Q1O2+e1KSLV/Wv8?=
 =?us-ascii?Q?V7t8YqLVd6mmEmql8T0UwBK89sKD4cWxGjEzuwm6bZ00bzRpGNHs2L23Qugm?=
 =?us-ascii?Q?xPzBZEg73o2nQOtgl2f80fBoFGnzbHl7lW2eOAMFzFGwJoMf/nKQ0XzTrNr/?=
 =?us-ascii?Q?CEeYkGeLlUPBOlpGNEuWcgDTvVKVrIAfJWdDMVEAQhi5uUtMn7XTSxleoY4a?=
 =?us-ascii?Q?OzcAYqPBU//r19EC0hQnPC55tR3ANXOqbTFL9C7rHWX9Js8xkiuMy/pQoObq?=
 =?us-ascii?Q?Qdc7qlOR6P1EKoOCkuPfyWai/T2/x1vYWeuIXronVf5xKZBMwHTqfyFUpccA?=
 =?us-ascii?Q?fA7q7vvHyyFzcA+2F0NAs5G1szODtfVBrOq0vroDiFu6WJ0TUaEInElLwYsL?=
 =?us-ascii?Q?0pjzVOFjwf03ucgDHtFfqG33FYqeTjXfMuUbHhrvWLF5gYsl+JF3sN9QPK01?=
 =?us-ascii?Q?zm7wtSiuiVkJ9UjtveTi1ozfmrTylrshMSboQlGIVGUJV8QJUw85psKIVeSJ?=
 =?us-ascii?Q?qQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E36ABDF8612A484B82DC0044CAD8E101@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?nAPSDS74dTxqIBYXHjdQ4QdCPSrn5S+wm5HJEEbYz4/itDwcCAAR6oh2HKOl?=
 =?us-ascii?Q?KOnfNnDm7MYhxY6yp2JtFh5Ev0iE9IcdV4uQA0mdTY2n5tuIEWxDjtTxb1rE?=
 =?us-ascii?Q?LRzwMxYCtaDe4Ef8sc4RYc3YjTH8Fe+E1qDY9pURm2GdyOFTbZh6Bm2yuN/I?=
 =?us-ascii?Q?qljHj/oKJ/32UqS+WN4aqHS+bMUgbR/UFjLPXPnlMBgg/yJuksOHkC0nveTD?=
 =?us-ascii?Q?el7ssJR6H3ac3G/dFWj/OhQTCYYGQPIBFWgC1WgaAQo78W00OUPxtnnwHhUU?=
 =?us-ascii?Q?pNcKH3N+yObzOauW0mvFm+V/1/G47HeQz3UeVu+XKLDa8LoBXXxFRilrZbJI?=
 =?us-ascii?Q?xFOxl3iLvxp3vBV7H7sCr6uHiVz5s8nOl23RT3llXGlS6EvZJOMWOv3j3Rhe?=
 =?us-ascii?Q?mfxAXdExCJZe7s2h+roQR1Of5kkcmSBI33uXtDqDGELclnDQNo1stpydeXfN?=
 =?us-ascii?Q?exKe9h9tS6Li4oJEo9PxeKbw+r6n9SDNXiXtfqsbCLVQrlpHPCjBRSM9O7Co?=
 =?us-ascii?Q?paAxMseKDnLZCJYK1QHpbQyqnAHG6npnUeITiMIPcoytbrwERC6pBF17j9Jk?=
 =?us-ascii?Q?3pxJcJoeRhxorUzmg7RwgXeWWcNBrwxDbEH4Rm3KaGumv4Apg0wz256Xlm57?=
 =?us-ascii?Q?QmO2YjfqJDlpg0qBOJZTkpFlJfRlPTIGu8J8NjobZPuCeep0DawYthq3oMX9?=
 =?us-ascii?Q?GzKWzEbp/fXRwPmIiTDMOGvRZUqo4KzQMMdrWdP/5eekxled/bYT3OWCuMOW?=
 =?us-ascii?Q?COSYIrdZmGQO7EWloUQPD0EbGrnH0CppQ0muaGsP7xUax6sxls/nXtyfLWfU?=
 =?us-ascii?Q?Vi2M0ZwIcgS93PA3OtGvedlVA9UbaNsV9CD6Z87eT/UU5XU/TFOy/kLoufz0?=
 =?us-ascii?Q?d0yvd/qb3hjZUXzv+BzxCpizysy5iQhxJBlv7vViPi8iRC1H7T4sxMFPrOvl?=
 =?us-ascii?Q?HQhsVGaoIRu/4CZFdqXCcvRaIAQw9Kgubpei1fACpO2lfhhK9cUDKVuMMPt+?=
 =?us-ascii?Q?FiRINauEsw9720P43xclbMJ3Wr0/BV3jk133EMAkC2pjm9j4EaNJj0qlqPt0?=
 =?us-ascii?Q?BKJam7yXrltYbUKn2wVhXRdZdEnH9RNPt3h6F1CVVfTXcFswuqKsHhUxeT4t?=
 =?us-ascii?Q?rCKfobXa+euhCCZqEiNQghC5Rin9kgfQ+efaNalpngEEH2cTt3qk1ZJkHz5M?=
 =?us-ascii?Q?0XWl9rNC6eQUHR7tk3tHBWt5iV5lUNAJAxmlU2mNdm5o1XXALxwC4IWyWRIA?=
 =?us-ascii?Q?gDMPb9sKkzEtjnyf/zssW9JQN/fDQ0tnBI3n3FemW7yaTytOKDTrEyCOyoWY?=
 =?us-ascii?Q?tFG+Uv7fnPo4YowhLyaSCJEDLvNGp89gC3D3aHwxwSv7/HKuyzUlFDm1+Jkq?=
 =?us-ascii?Q?4vDaxtX2+3SLBlwfaqgOhcJvExjndshY7M8mUz8i0NlbYo3Ja0hWCdRpOXIX?=
 =?us-ascii?Q?IFAoUVP6nl32I/tiecsno+qCdakUcD1dySRG6irscjGuiYaZJccxQYPwGQJU?=
 =?us-ascii?Q?vZSujK0EHa5ILKyiQ2PbNMafmyCuIRpXV0PC?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09e1b42e-7711-48eb-b972-08daf8e1150f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2023 23:18:03.0716
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MeQ28oqHKVUmbd8KPNxCyo5pHXt08sbOPNwvFUvBmwaVcf8EPVGKw/xQ+UWhH/jqd57YcRRvtDStZK9VqbBbTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR10MB6017
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1
 definitions=2023-01-17_10,2023-01-17_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=638 adultscore=0 mlxscore=0
 phishscore=0 suspectscore=0 malwarescore=0 spamscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000
 definitions=main-2301170186
X-Proofpoint-GUID: ZzipPF0vWqs4V-Y_jxXYFWXOuLWrrPbe
X-Proofpoint-ORIG-GUID: ZzipPF0vWqs4V-Y_jxXYFWXOuLWrrPbe
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Jann Horn <jannh@google.com> [230117 16:04]:
> On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan <surenb@google.com> wro=
te:
> > Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> > page fault handling. When VMA is not found, can't be locked or changes
> > after being locked, the function returns NULL. The lookup is performed
> > under RCU protection to prevent the found VMA from being destroyed befo=
re
> > the VMA lock is acquired. VMA lock statistics are updated according to
> > the results.
> > For now only anonymous VMAs can be searched this way. In other cases th=
e
> > function returns NULL.
> [...]
> > +struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
> > +                                         unsigned long address)
> > +{
> > +       MA_STATE(mas, &mm->mm_mt, address, address);
> > +       struct vm_area_struct *vma, *validate;
> > +
> > +       rcu_read_lock();
> > +       vma =3D mas_walk(&mas);
> > +retry:
> > +       if (!vma)
> > +               goto inval;
> > +
> > +       /* Only anonymous vmas are supported for now */
> > +       if (!vma_is_anonymous(vma))
> > +               goto inval;
> > +
> > +       if (!vma_read_trylock(vma))
> > +               goto inval;
> > +
> > +       /* Check since vm_start/vm_end might change before we lock the =
VMA */
> > +       if (unlikely(address < vma->vm_start || address >=3D vma->vm_en=
d)) {
> > +               vma_read_unlock(vma);
> > +               goto inval;
> > +       }
> > +
> > +       /* Check if the VMA got isolated after we found it */
> > +       mas.index =3D address;
> > +       validate =3D mas_walk(&mas);
>=20
> Question for Maple Tree experts:
>=20
> Are you allowed to use mas_walk() like this? If the first mas_walk()
> call encountered a single-entry tree, it would store mas->node =3D
> MAS_ROOT, right? And then the second call would go into
> mas_state_walk(), mas_start() would return NULL, mas_is_ptr() would be
> true, and then mas_state_walk() would return the result of
> mas_start(), which is NULL? And we'd end up with mas_walk() returning
> NULL on the second run even though the tree hasn't changed?

This is safe for VMAs.  There might be a bug in the tree regarding
re-walking with a pointer, but it won't matter here.

A single entry tree will be a pointer if the entry is of the range 0 - 0
(mas.index =3D=3D 0, mas.last =3D=3D 0).  This would be a zero sized VMA - =
which
is not valid.

The second walk will check if the maple node is dead and restart the
walk if it is dead.  If the node isn't dead (almost always the case),
then it will be a very quick walk.

After a mas_walk(), the maple state has mas.index =3D vma->vm_start
and mas.last =3D (vma->vm_end - 1). The address is set prior to the second
walk in case of a vma split where mas.index from the first walk
is on the other side of the split than address.

>=20
> > +       if (validate !=3D vma) {
> > +               vma_read_unlock(vma);
> > +               count_vm_vma_lock_event(VMA_LOCK_MISS);
> > +               /* The area was replaced with another one. */
> > +               vma =3D validate;
> > +               goto retry;
> > +       }
> > +
> > +       rcu_read_unlock();
> > +       return vma;
> > +inval:
> > +       rcu_read_unlock();
> > +       count_vm_vma_lock_event(VMA_LOCK_ABORT);
> > +       return NULL;
> > +}=