lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <176042008301.1793333.506325387242251221@noble.neil.brown.name>
Date: Tue, 14 Oct 2025 16:34:43 +1100
From: NeilBrown <neilb@...mail.net>
To: "Jeff Layton" <jlayton@...nel.org>
Cc: "Miklos Szeredi" <miklos@...redi.hu>,
 "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>,
 "Chuck Lever" <chuck.lever@...cle.com>,
 "Alexander Aring" <alex.aring@...il.com>,
 "Trond Myklebust" <trondmy@...nel.org>,
 "Anna Schumaker" <anna@...nel.org>, "Steve French" <sfrench@...ba.org>,
 "Paulo Alcantara" <pc@...guebit.org>,
 "Ronnie Sahlberg" <ronniesahlberg@...il.com>,
 "Shyam Prasad N" <sprasad@...rosoft.com>, "Tom Talpey" <tom@...pey.com>,
 "Bharath SM" <bharathsm@...rosoft.com>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 "Danilo Krummrich" <dakr@...nel.org>,
 "David Howells" <dhowells@...hat.com>, "Tyler Hicks" <code@...icks.com>,
 "Olga Kornievskaia" <okorniev@...hat.com>,
 "Dai Ngo" <Dai.Ngo@...cle.com>, "Amir Goldstein" <amir73il@...il.com>,
 "Namjae Jeon" <linkinjeon@...nel.org>,
 "Steve French" <smfrench@...il.com>,
 "Sergey Senozhatsky" <senozhatsky@...omium.org>,
 "Carlos Maiolino" <cem@...nel.org>,
 "Kuniyuki Iwashima" <kuniyu@...gle.com>,
 "David S. Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, "Simon Horman" <horms@...nel.org>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
 samba-technical@...ts.samba.org, netfs@...ts.linux.dev,
 ecryptfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
 linux-xfs@...r.kernel.org, netdev@...r.kernel.org,
 "Jeff Layton" <jlayton@...nel.org>
Subject:
 Re: [PATCH 02/13] filelock: add a lm_may_setlease lease_manager callback

On Tue, 14 Oct 2025, Jeff Layton wrote:
> The NFSv4.1 protocol adds support for directory delegations, but it
> specifies that if you already have a delegation and try to request a new
> one on the same filehandle, the server must reply that the delegation is
> unavailable.
> 
> Add a new lease manager callback to allow the lease manager (nfsd in
> this case) to impose this extra check when performing a setlease.
> 
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
>  fs/locks.c               |  5 +++++
>  include/linux/filelock.h | 14 ++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 0b16921fb52e602ea2e0c3de39d9d772af98ba7d..9e366b13674538dbf482ffdeee92fc717733ee20 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1826,6 +1826,11 @@ generic_add_lease(struct file *filp, int arg, struct file_lease **flp, void **pr
>  			continue;
>  		}
>  
> +		/* Allow the lease manager to veto the setlease */
> +		if (lease->fl_lmops->lm_may_setlease &&
> +		    !lease->fl_lmops->lm_may_setlease(lease, fl))
> +			goto out;
> +

I don't see any locking around this.  What if the condition which
triggers a veto happens after this check, and before the lm_change
below?
Should lm_change implement the veto?  Return -EAGAIN?

NeilBrown


>  		/*
>  		 * No exclusive leases if someone else has a lease on
>  		 * this file:
> diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> index c2ce8ba05d068b451ecf8f513b7e532819a29944..70079beddf61aa32ef01f1114cf0cb3ffaf2131a 100644
> --- a/include/linux/filelock.h
> +++ b/include/linux/filelock.h
> @@ -49,6 +49,20 @@ struct lease_manager_operations {
>  	int (*lm_change)(struct file_lease *, int, struct list_head *);
>  	void (*lm_setup)(struct file_lease *, void **);
>  	bool (*lm_breaker_owns_lease)(struct file_lease *);
> +
> +	/**
> +	 * lm_may_setlease - extra conditions for setlease
> +	 * @new: new file_lease being set
> +	 * @old: old (extant) file_lease
> +	 *
> +	 * This allows the lease manager to add extra conditions when
> +	 * setting a lease, based on the presence of an existing lease.
> +	 *
> +	 * Return values:
> +	 *   %false: @new and @old conflict
> +	 *   %true: No conflict detected
> +	 */
> +	bool (*lm_may_setlease)(struct file_lease *new, struct file_lease *old);
>  };
>  
>  struct lock_manager {
> 
> -- 
> 2.51.0
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ