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 486A6C02196 for ; Wed, 5 Feb 2025 12:11:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D08E2280004; Wed, 5 Feb 2025 07:11:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CBCED280003; Wed, 5 Feb 2025 07:11:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5BD0280004; Wed, 5 Feb 2025 07:11:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 968F7280003 for ; Wed, 5 Feb 2025 07:11:11 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 35D05495AF for ; Wed, 5 Feb 2025 12:10:33 +0000 (UTC) X-FDA: 83085773946.04.F7CA590 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf17.hostedemail.com (Postfix) with ESMTP id 4C2E34000F for ; Wed, 5 Feb 2025 12:10:31 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YqYGuNhP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738757431; a=rsa-sha256; cv=none; b=Q/xBwGkHBbVdTQleh5CgVO2Z6S8DwLwNJ/rQqYo7DNlFlJ/QVgxjHZP5bCY7JlQ4nM+LyJ YsqAPW1FkRF7g5EH4ZY+/odqPeOBsm7B0cNFW2BKSO3HPQd0X/1gkFBeCRkpP2v5/aLfBc r0VgHLMSMasdxSECPFzNGLVY21lv0Ig= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YqYGuNhP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738757431; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=CM9edJiBMXn21mPbe8Qk4uoLTtdcK1HokgiZWsmiPV8=; b=dsEK+pqhwQSzYW3wB/T1DpvHj9ADm6MomCoKvswl5vkSCBZST4aEXE6UHVPLzN7bU7/fur ggE5gutphcpqE0WfzkAclcQR8WNGULXzP7efTcsVDfdZi7CZaeHJkQ9rmyWE5N5tGs0iEl nUquGl/1Zj5qAR4oWlCo91JJJios5NU= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-38db52ccc0fso389608f8f.3 for ; Wed, 05 Feb 2025 04:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738757430; x=1739362230; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CM9edJiBMXn21mPbe8Qk4uoLTtdcK1HokgiZWsmiPV8=; b=YqYGuNhPOit0OIhgAGaIyr8ZYY/Dc+eHBCDAY9Bm7jmeSukW+jyjAWhZAw9q6Gy96B KeDcIRfpunkGu7OoSPe39jBhUD7twWAo+2I4tosDDyVYONUXn4e3WoBSWLbx7I0DbdJ6 xRIghTzXO8fYomJ/LE5gEhWbitoxh7HyU3QBlAsTlYqJootgrgW19scOogxO0BxiSW86 bPiCOI9rziDoICG5/Si4Cgd6J+VkzoSM15eykD6NVquhwMpHlenSudnm48q7G403Cjkh 8v8+Mf3R/gBUiWR81fkrqEcC1EYBzsQES7dszI1a9AMdL7EVXiM2Q70+lOyKXvtJuX71 af7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738757430; x=1739362230; h=content-transfer-encoding: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=CM9edJiBMXn21mPbe8Qk4uoLTtdcK1HokgiZWsmiPV8=; b=pAReE/Zm3C+qhZsiFkZHGLEiuUudppT5xeGQ566sRZPEP0I5yL6ES7FYT7TBWt9pkC JZt6nCbPyggOljnb3vQ7mp/GCmRzeVp4Er/2iPI/H43gmHGh+b5zm9wgxP876lqenm8l ejxvKHevCCwUlycffqWSghR4pcJZQvuMgf6iBJoPxSEZ7bM7D5leZSxd4iuIXLJ/Zt1A mVyCDt021gApxEPF3FAwevxDTymiV2RvYCWlQCBQV+Ar0msR8IsdxrcW1A3yLr5ypbPD /PAkReC+4+icTUcKocHGfOHS7noaTWQ7ii/bR4QDs2Xfng3CqppGbY4qGqN6qNq0zPSg 0q3w== X-Forwarded-Encrypted: i=1; AJvYcCU4+DlSPtS3GkedMRT6HS7o/nmL4CLDxA1YHBeuxgkD2w2Ze5GSZmEcNX34ckt/1aeSGMKCRr2rHg==@kvack.org X-Gm-Message-State: AOJu0Yy24QU/4D8K3I3h1cE6BsTsvBx50tjzd5Qe9uuGJloZTATsufGa fCDpo1jh/LnAbHdyW++kCaPNmfSl0gl8m65SAM0PeVZS2EU46dKApERnKdRO+6ktrwnRQ9Sy1y5 sKHT39JBvNJwWdaOIVAVNsduR/3BXt/Lqusnx X-Gm-Gg: ASbGncuYVFrea+Pkx48MAtOSWZozEzPYRy5yeFn8iaeHaNlq9rMbJ1l7qS4ARuQSiWu RgB1oLUT5i8yc6d5SZ30FB0qNpU0LFaWYsmXVjvtOSE67Pqg1/a3zNir70057q+C/0asFB82/Ng Q9fCwc6tqGtanvYg4hrVyLHzY1AJ0= X-Google-Smtp-Source: AGHT+IEJRX8Gawq5uTZWc7gghQE3VD3b5s1utE8n3fNb/Dxuk/7Rl4NYgvzDN4Jo2pf/N+jO5EMKYukFZfnclOVEP6g= X-Received: by 2002:adf:fdc4:0:b0:385:fd07:85f4 with SMTP id ffacd0b85a97d-38db488960amr1453466f8f.31.1738757429509; Wed, 05 Feb 2025 04:10:29 -0800 (PST) MIME-Version: 1.0 References: <20250203-vma-v13-0-2b998268a396@google.com> <20250203-vma-v13-2-2b998268a396@google.com> In-Reply-To: From: Alice Ryhl Date: Wed, 5 Feb 2025 13:10:16 +0100 X-Gm-Features: AWEUYZlj_xoYsvNCca0RfpQ0eQ7nYggzNeG2vXSDC6JyOIm_4a-qi1ks5bLCsaM Message-ID: Subject: Re: [PATCH v13 2/8] mm: rust: add vm_area_struct methods that require read access To: "Liam R. Howlett" , Alice Ryhl , Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4C2E34000F X-Stat-Signature: bcu34fxkam85degf63mrdenbyez4aew8 X-Rspam-User: X-HE-Tag: 1738757431-38027 X-HE-Meta: U2FsdGVkX1+BocMrDjWHuBdrRacUsAHQRXKbJcMLbJ6i2tagzP9fChLIzUNxUOynLy41xchPAsc3cxRdzLXztE2FkSzC5pULbx9Ktz8UdrcPTKUDh+iODoYPrlzdkI2bX9t7ry4+vrRvpb9jU4q6xROH/K0QL3baBb/IqGrHcfYrsCN/cJUOed6hvHDtVj5KaaHBJZeUdw2EHVv7x6TMnBKNrfkgMgVNkDChI4dYZ5Vhlytd1AGdC9vOyK1W3mNwMkKttZod9bshfhMqYanLB5fjCXX23Hs4vUjWwIUODe6C1ewQcDHMKPy5hdDKnLpPPW4ArUZ2oBhOxraOswYshUzJTvQnl/VN31dEFQG4fU7d2cVhHQNhAIANdgm8TFWCHLMoYwq/hqfCC0y4jlQgOFnoNnhhH6UjgXxP7m+ZHFvkiG504s+m4Chpx5JLaGrtf3MFVLH4ydmI5uLo4HS648qTiJQ6OnFWPXIz+vDN4ecpw2doTDD+6G2pRo1hcFTXmGziDLAxHt48czgA4Vdy4AtwEjpDPl/uOanLs5zn473BHiuJhL8b9fg/Q93wlIx7wfw+Revbd1jk/rUtsgJfz5n9azbeuHTCfVDQRfWYZe2iIw+41SVoM7nJuOVeLN8Dicl3tH3+jrUIEQWLGCIa3ywLOZVxhOPMleIA5P1Mo4B3syTivTQCRwEoE7fYggijxkm1lFgaBgozHAFH5BeTFp+fqLKggOJNydXPnn5dZJCuWtzOoQkbUEA7PxmVMnhN4hSQSFbE4vRhbYmAcwpr2U6KbfeoQDUKGbAKJq5z+nT3fP7NfRt+KfrDhZoBvUUcXt9UjWLNgTQxhEkTBget9Xf4Z6gA0RYNEp9wP8RnnbOKFcmJWidjSc+kBTKsMyk2PDxEHnII6cLwVbF0rz1fRgfZuhfzjU+FkR3wwReu5yfpMPppYKRhxK1W5tqmxlCMH2aQniiOVzYp8bqBT6G YkZKX8lf 33kUBYedF1nWSkSDZ6rjXXkJU05N7lLzMhGZIYty8KvaAsyKMb4lmDOd3k7IdCOdt4DQUdwy8GdfFBZc+cFuN9uLiybcylKdbjGq22sdHryF7FQ8HpjkGN2o6dui9Jch87++9AklsTRXV2gKB1BjhS0HAOklaAE77Mcr8ka00MYPgqJZCla1TsLi8a0knX9d+jKGu0BmXQKxfURJoQTUeGOuBnpcGgC6RaffP4WWtz7qxJL4iMDtsmgKUhSSz0K/5tctTnQfsPCDF2JOAaCsqljUzDRp4Xv67iQQMgPPT/G3TwmQvQVnNoxqqbAC5lM0PWOyHAMYeNE6qOzVQHlRRDlkCRw== X-Bogosity: Unsure, tests=bogofilter, spamicity=0.500000, 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 Tue, Feb 4, 2025 at 4:46=E2=80=AFPM Liam R. Howlett wrote: > > > > > > + let vma =3D unsafe { bindings::vma_lookup(self.mm.as_r= aw(), vma_addr) }; > > > > > > + > > > > > > + if vma.is_null() { > > > > > > + None > > > > > > + } else { > > > > > > + // SAFETY: We just checked that a vma was found, s= o the pointer is valid. Furthermore, > > > > > > + // the returned area will borrow from this read lo= ck guard, so it can only be used > > > > > > + // while the mmap read lock is still held. > > > > > > > > > > So We have complicated the locking of the vmas with rcu and per-v= ma > > > > > locking recently. We are now able to look up and use a vma under= the > > > > > rcu read lock. Does this translate to rust model? > > > > > > > > > > I believe this is true in recent version of binder as well? > > > > > > > > Yes. The safety requirements of VmAreaRef is that you must hold the > > > > mmap read lock *or* the vma read lock while you have a VmAreaRef > > > > reference. This particular method achieves that requirement by hold= ing > > > > the mmap read lock. But there is also a Rust lock_vma_under_rcu(), = see > > > > patch 4 for that. > > > > > > Right, okay. Thanks. You can get the reference by only holding the = rcu > > > read lock, but you should hold the vma lock to ensure that the vma > > > itself (and not just the pointer) is safe to use. > > > > Hmm... To modify the vma, you must hold the mmap *and* vma write lock, > > so holding the mmap read lock prevents mutations? > > Sorry, I think I confused things with my answer. Your code is fine. > The phrasing of the "only be used while the mmap read lock is still > held" made me wonder about further clarification on the locking here > (because the locking is confusing). > > Yes, mmap read lock means there are no writers that can modify the vma. > Essentially, you are using the lock to ensure the entire vma space isn't > changed during your operation - which is heavier than just locking one > vma. I could extend the safety comment like this: SAFETY: We just checked that a vma was found, so the pointer is valid. Furthermore, the returned area will borrow from this read lock guard, so it can only be used while the mmap read lock is still held. This ensures that there are no writers because writers must hold both the mmap and vma write lock. Alice