Received-SPF: pass (google.com: domain of linux-nfs+bounces-2360-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sun, 17 Mar 2024 10:56:37 -0400
From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
        Alexander Aring <alex.aring@gmail.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>, Steve French <sfrench@samba.org>,
        Paulo Alcantara <pc@manguebit.com>,
        Ronnie Sahlberg <ronniesahlberg@gmail.com>,
        Shyam Prasad N <sprasad@microsoft.com>, Tom Talpey <tom@talpey.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        David Howells <dhowells@redhat.com>, Tyler Hicks <code@tyhicks.com>,
        Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>,
        Dai Ngo <Dai.Ngo@oracle.com>, Miklos Szeredi <miklos@szeredi.hu>,
        Amir Goldstein <amir73il@gmail.com>,
        Namjae Jeon <linkinjeon@kernel.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
        linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
        netfs@lists.linux.dev, ecryptfs@vger.kernel.org,
        linux-unionfs@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH RFC 02/24] filelock: add a lm_set_conflict lease_manager
 callback
Message-ID: <ZfcDHPq68nZBaY5D@manet.1015granger.net>
References: <20240315-dir-deleg-v1-0-a1d6209a3654@kernel.org>
 <20240315-dir-deleg-v1-2-a1d6209a3654@kernel.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240315-dir-deleg-v1-2-a1d6209a3654@kernel.org>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?up/3yb9q7Dss3wTossytneGhVRlNGrkwXVCD1Gh5GEiqp1Bcd2+f5+Y/gJ3g?=
 =?us-ascii?Q?51a4Had090X2d5BfJsdots6XrUvqPkVjng+MFFduqDZGB5bvE4Xi44rIhC3w?=
 =?us-ascii?Q?ZwzR4l4mm3GPT6ZtGfjnVEVmh+19+g5rRnIFnCfsEoy8JOgebGOwwsgWwxyl?=
 =?us-ascii?Q?jOePX9Sq07CE8YO1+dgtYIk+drz02hZVDAU0HDjw6KYJsvkFTI0JCOBmKnEl?=
 =?us-ascii?Q?4824RSYquJNMmXui8xRVTUp2HELEIK5vLAg9MkqYDRzKBoMs0SUJJpU4zv3J?=
 =?us-ascii?Q?T6jhRhnTDFsdNEYm3JSX3mrJDzVpGzDdSw2Hxljcfla0P8vgD6jDiXXqYC0c?=
 =?us-ascii?Q?PTxwx6ytwxVTCq7sgHht3PbGi2mZPoK5o9EcDIx2+TkqvhcATPN2P0sl8Fio?=
 =?us-ascii?Q?0y0WZEjq6UhufGNOUTTEdzkry2K1B0gySy7eW9MKo0SfMgKDk5lCWmwXob97?=
 =?us-ascii?Q?u77c9NPp4ATRATuWKx+iKwG4s4jqCVoYyUpaTcnei4Dj4JsiD0kiOimN6wSB?=
 =?us-ascii?Q?PJ6xKe6cfU0u4H/cOFTxyG3bVcAnvoDNiNLuVTLJYd5IL+mkbKc3g4/ajwN0?=
 =?us-ascii?Q?vHhAam2PiBcBdKipAx2YPbUyJ80J0dYzcqpnDPe2keBAmRTJUL3P14Y/ordC?=
 =?us-ascii?Q?ago3vVLrvz3wCt1SpFFhmMayoJdzshbEuFEfNR9Rz0GK+uxQwpWaIri6LVIL?=
 =?us-ascii?Q?GEIk1/9miZ/OTUWD+j1f7tuLQwgwg94iz+fiiI3oT7Hl4NvPS3B+BOnq6hmG?=
 =?us-ascii?Q?pp20mbQe4IM+8erd2soxzimi2LXj22Izujbhhzhokc+4kvUGnsiIzdAmGStH?=
 =?us-ascii?Q?5i3mANZzN/lYycRyo8GTdTuLV64bBme1y4XPueVeZWSsAwDbaHcrZFLQHq/5?=
 =?us-ascii?Q?Oang1BKydIjQS58C7DJL4Ud5GXSdVFf6oY6vtFN66i0LgelAy9yx/QQhMPUD?=
 =?us-ascii?Q?1IDQNUF7Y3WMZL6H5SFF6tZ4+caM3XluwiQPCvSY8sLjbHrme/JYNcF8gxs7?=
 =?us-ascii?Q?qLAkv0YbdGM0j66ZMnAUh94EmNAizOrKLw9RD0eF+apnAnqEMhETDaxoWhI+?=
 =?us-ascii?Q?StMaSUIzzHGEB0XiuMhYh9n19OTicjrd0iAq4zaZgc8xPnS4z+GutRuaRujN?=
 =?us-ascii?Q?GS87E1OtyXCsK0saISQMIV0xhdmzK8BL5opc9M4fZ1qFbm0l9TcpRRsgw4MA?=
 =?us-ascii?Q?axdNH5PFELdjgWjYoazbnaxYKEuHycMzOzWoKpp2G/GX8LPyvxwoFZTCqzJO?=
 =?us-ascii?Q?iRJczNtD12GL4V04bpVogQux6LMbNv4kfdtmzguMH1JUvdkmBgFyopQ/JJZT?=
 =?us-ascii?Q?49i9/zcNrZgnyRnsLgXAQfp327SNB4pPTYNuhO5XSDTMap579OeFjz98jEFv?=
 =?us-ascii?Q?9HyHtY6X7UTh4nKVRmg3TXpEfcQwvu6myJ3zGjZoo+dSwhwdd4IvTVrSFBua?=
 =?us-ascii?Q?pRRKNdksqbWeN5Yfxbbk+ZcCkF4LWlxdGiNdlVKdZf1TVeQ77qYyGzw6JhkO?=
 =?us-ascii?Q?9ZS/LLpa2jTg9XeliAgwKta6sWXe9T2oOORHfNmv4W6JhijfwBlykyfTUSiK?=
 =?us-ascii?Q?9w5adv9sUwJ5L14A8SVJXRmi6ZJ6p8ZAbmNc5ZRe+hThgQoTw0noKdcXQLLw?=
 =?us-ascii?Q?vg=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	ucWCUXp11/HnCWtCsaNOD4LUKMXvnzWMUztY0NLuGUH3ICq4SBSWmSgwFe6Nw5Jt0RLGy1A24444OHwO+3egK5ZE/XJdZVjqLLujH3n9+E82+xVYCetWov9Zo6yFMNA2LdOjgv52Qu0fv0px2bmcA9r8KbQQBiIjhq9lGC2pyRyuP3VnJSRvrR7pko1D8xIR+Q3zf19AVnubJOjjsPVsSU9x3WXfEkspVZ1xseLLpWrTpVaf5A8ROCs7B1IfSNH4/w0TjW0fq7Kr/OrOGSU8dkCODy88mDnLbAVRCtm58dAM7vPTTdTUtKu6aCAVqpQmKQsFKX28REIDQ759ce9m81x5jBZg1IWX76ouyEWg0hef4B9MuOYymbiC39ZhW0EpP2xkvBn8JpSW+UOtQVwTiPHXKa8MTC2mdfmVdtpn/xjzQvbqjzPdwKBBs2hF7Y4PfWqSIscFkaIQGDqtAsrjX/44AsGzIOPoEfpRa9jpodjSd1N+f+M/VtPdVtMt5n6g3LgPFhZJoUyrC3OszoL1HJwvG3p7kVWT5IC+7ubGxP7YYsfS7N0lqmna2rbZiJViZvrwcWCEhhm9DZdeAHfakiqQpszO/E57aDJ/JHx+8bk=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ba56375-f60c-4c9a-4a1f-08dc469277ed
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2024 14:56:47.3088
 (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: NZmAkwH5CP83TJlAFEajxWvg9ra74XwjSZYZKGi0+PE4Tjx5r1Vmq91QwwcD9zntU5Z4Gn2i3UN/zUCvDDkpfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4693
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-17_10,2024-03-15_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 spamscore=0
 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2403140000 definitions=main-2403170117
X-Proofpoint-GUID: jqTna1Jy16LDnR5-c6p6l7ATj0QxRhXJ
X-Proofpoint-ORIG-GUID: jqTna1Jy16LDnR5-c6p6l7ATj0QxRhXJ

On Fri, Mar 15, 2024 at 12:52:53PM -0400, 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 extra checks when performing a setlease.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/locks.c               |  5 +++++
>  include/linux/filelock.h | 10 ++++++++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index cb4b35d26162..415cca8e9565 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1822,6 +1822,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_set_conflict &&
> +		    lease->fl_lmops->lm_set_conflict(lease, fl))
> +			goto out;
> +
>  		/*
>  		 * 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 daee999d05f3..c5fc768087df 100644
> --- a/include/linux/filelock.h
> +++ b/include/linux/filelock.h
> @@ -49,6 +49,16 @@ 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_set_conflict - 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.

To make it clear which return value causes add_lease() to abort, I'd
rather see API contract-style descriptions of the meaning of the
return values instead of this design note. Something like:

 * Return values:
 *   %true: @new and @old conflict
 *   %false: No conflict detected


> +	 */
> +	bool (*lm_set_conflict)(struct file_lease *new, struct file_lease *old);
>  };
>  
>  struct lock_manager {
> 
> -- 
> 2.44.0
> 

-- 
Chuck Lever