From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0FD391632DA for ; Wed, 5 Feb 2025 15:24:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738769067; cv=none; b=ARdQAGmtA9AXOAbAx19ODm+mE4Qo5LkR2vcBJX/N8lTuFFQKQDNYxo2O8C76kMeB0jtJ1tKjz3KlzAcFKvWfdMbb6xVAiq/7NZNLhrzuH5yp3Hg7R5uQvSpkEZW3W231CbpjTesJfAICbFW6a/ni3uLj+sU6cmmB0M0ZWasy5Ec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738769067; c=relaxed/simple; bh=RgnLrNkg9LQXYy1twLEj6EteqD+deF14Iq9XrS1HPZI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Content-Type; b=d/zqBgY9OB1Y2kPKYJP63iCL0looiE8s9EPz+JB/K+JNsA1XluUjrltU2QcakCpWqdS2bw1dhB72QJw52Jc3IJ6kwi7c34uhPtx5DkBg9VrSRrxGv3B+RPWDevDVQ1eo73Vhjizt2I0W0MPx6LREBRSdlRRB+zee5pvgBHQ7M/s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=PWCmvD6K; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PWCmvD6K" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2f9cd8ecbceso3208873a91.0 for ; Wed, 05 Feb 2025 07:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738769065; x=1739373865; darn=vger.kernel.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=KGUFj/mah/kn+/uxQ4Btu9bKF0UOsIAWYRzSd3+gFfM=; b=PWCmvD6KmJm9h+wuCzf2bdNMHbls/yTGicth9HdWrA3xHpTnpoM5QZfkVdOmmfXMV1 5frvYCPq1xmbIJwr8QTeKZtZrvmlGyXj6RD6HI0edRc4TkEIODSykcPQg1e6OTdp4rS1 h5KLg736daBW59WubR71+dk8Us/bH0OnIkcj5zDMZbMdItKhS48QcUAYJBenxrLYbI9a 7TIIIBH++O5kvADoXYdPLLghhv7cIqBQhGtktIv9gMsy5MgNEv6bDhvxilZxi1j1RcNr I4H7UZZGV53y1PrTq/zUWmM2xugjBxnTGPP5ndj6rM0i1pWOPx7CCDFqSIl8FD5+A2OW AAuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738769065; x=1739373865; 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=KGUFj/mah/kn+/uxQ4Btu9bKF0UOsIAWYRzSd3+gFfM=; b=eNwigOxp8vPRLxO/MAKQ9tQFCoc1qwfMKEgeH+1yoN8vhSTIGhmEWbKFCFz8JUojzw xK8eyTSwLpDqCuMuH1VxMjFH4hNgCkq03DKMs9sPTivLnXagu2fV1F0UZkm2MJueqbGt PEEYz3WTO6CanebYxlkDAHiGtUbTUo8CjLLFtd+MNpPraact9FqxlpnY92UCNdDwP48z R9N/WU2Bip5dR/SBOkg6Lgip/oV0uNcwX+3yrWZtCpp2TXDwRaSdE0Cmx4NQi/Ht168f 56y4BmiiQzl6itt+NVHwtxihXbomJ/auN5PdBJzpb1tnksJ331e+SzIyiFOwAcDtNMoK k4bw== X-Forwarded-Encrypted: i=1; AJvYcCXX8XtLaVL+rx5EaI5iDFKWDZBDq9NhMoemuqsl+9nNxgQWaWyICt8vI3u1L1QMKMPCS+oCeQWIWfyVd1EC4w==@vger.kernel.org X-Gm-Message-State: AOJu0Yx5jIqIgl6juNBnYiBB2ZtMENKvv4/POOuLRKgGtRCa48yCN7H7 xrxGUNvoq1F5ifYnNFUpGNDfedN+ZSbJFgXJUsOGjuuRHfZ5KG7rB5v6jbBOVlJAxw/Fy+QKBvd ruB1bYPfsDPijfaI5pApzaeF4lCT/NNV36kBl X-Gm-Gg: ASbGncuQzJrvnhsz3kdiDdiALHEeZkaYxAUL7ojtjhrhBiAyFbMuQOMo7aXlpFPgdwq b/pVBbBQD3at1Wfgp3OAIwn53BBe7T8zbysyORC6kO/bDl2egZoOqyz7N2sJy1hEWDvK4FSnPba 2HlIT449fxxUa3SmxaxTva3x+9IMY= X-Google-Smtp-Source: AGHT+IFbR/Za3bzQ561Moir1l01pSJAcHP+agVl6hNv1WMjaZabDacA+FBKaP1s+i3G2zvW5BNr6B5Ren6dXC7QGv6w= X-Received: by 2002:a17:90b:370c:b0:2ee:c91a:acf7 with SMTP id 98e67ed59e1d1-2f9e0753763mr5096043a91.4.1738769065057; Wed, 05 Feb 2025 07:24:25 -0800 (PST) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 16:24:11 +0100 X-Gm-Features: AWEUYZmq_vX8tVFSj3KjtvPi2OOSFFsq6QpKo6Pfs-lOXylEZQu2sCfVDes0wgA 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 On Wed, Feb 5, 2025 at 3:38=E2=80=AFPM Liam R. Howlett wrote: > > * Alice Ryhl [250205 07:10]: > > 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_raw(), vma_addr) }; > > > > > > > > + > > > > > > > > + if vma.is_null() { > > > > > > > > + None > > > > > > > > + } else { > > > > > > > > + // SAFETY: We just checked that a vma was foun= d, so the pointer is valid. Furthermore, > > > > > > > > + // the returned area will borrow from this rea= d lock 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 p= er-vma > > > > > > > locking recently. We are now able to look up and use a vma u= nder 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 VmAreaRe= f > > > > > > reference. This particular method achieves that requirement by = holding > > > > > > 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 vm= a > > > > > itself (and not just the pointer) is safe to use. > > > > > > > > Hmm... To modify the vma, you must hold the mmap *and* vma write lo= ck, > > > > 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 vm= a. > > > Essentially, you are using the lock to ensure the entire vma space is= n't > > > changed during your operation - which is heavier than just locking on= e > > > 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. > > How about just changing the last part to: > > Furthermore, the returned vma is still under the protection of the read > lock guard and can be used while the mmap read lock is still held. Well, the important part here is that you can't do this: let guard =3D mm.mmap_read_lock(); let vma =3D guard.vma_lookup(...)?; drop(guard); vma.foo(); since that would use the vma after the lock has been released. The reason that the above is prevented is because `vma` borrows from `guard`, so you can only use `vma` while `guard` is still valid. Alice