From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D43343E5563; Mon, 2 Mar 2026 13:57:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772459850; cv=none; b=gxMHg/1MDny2NCI/5VgYwPpXgH44FZcJ7fcPHdlPpt3W2jRZ+jcxSk9wdX5F+v8j4l1wW+vAzvfJffhnvUG7jAy7yD2VI0SeBjs4Y+pHCBobZKqi4FAq8U6YO6ycoUR33yqLpDp9BEJ4lqkIu6owiR888xhW014MevKbUAQ0goI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772459850; c=relaxed/simple; bh=UV2mNPBNzqomza8bGMJZVxSDC6YpRR0TOAlLfetIp9M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eiyieAFqxgRjvk8xSbOZnYfaEccU4LIqHPuI413eTFS9HRhBzc8VuBzRQqlRbJEj3JbBzbcwqqhCCYlFpX2Awlt6wzvvB5/lonsvhKs+Z323s6JxX/sqxjxTYI0srG3kD6z79FjqCTMM9XcZtaUhXSCqpL03Q1XfFDhjBKF0l4w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jd2LsCVC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jd2LsCVC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80786C19423; Mon, 2 Mar 2026 13:57:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772459850; bh=UV2mNPBNzqomza8bGMJZVxSDC6YpRR0TOAlLfetIp9M=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Jd2LsCVCQ7xuIl5ZNQ/Usg0S+rgGGYa+BwwiymmVREWmOaCSGbGfPcTHS60e3cECR eieLMPUsvOqbrIzsQuCDbaGARJ5YxKGeohDjdJzjpDI+uVaZ3uGcbJtSDAiZ/o1Hjo zzZkvU9Jjm1Z4sKQMokRZOrB7wRIhNt9GzMTUhMi1O+HoDBUACxdvdJ8RIspigE9zh iu/+2FmrskCm3sYPA8MiWu0qCrX6J2MdJeMQ3Z7uxoWvGmNaGGaTGANfhRwNNQmDbw h9LidjBVhgij0rY8yI90uTAochDeVyjY4FexLkmaD5atdgFlx54jV7iuT/WT2+oW4s 9VQ00DlFkw2xQ== Message-ID: Date: Mon, 2 Mar 2026 08:57:28 -0500 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] fs: add umount notifier chain for filesystem unmount notification To: NeilBrown Cc: Amir Goldstein , Jan Kara , Christian Brauner , Jan Kara , Jeff Layton , Olga Kornievskaia , Dai Ngo , Tom Talpey , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Chuck Lever References: <20260224163908.44060-1-cel@kernel.org> <20260224163908.44060-2-cel@kernel.org> <20260226-alimente-kunst-fb9eae636deb@brauner> <1165a90b-acbf-4c0d-a7e3-3972eba0d35a@kernel.org> <3cff098e-74a8-4111-babb-9c13c7ba2344@kernel.org> <07a2af61-6737-4e47-ad69-652af18eb47b@app.fastmail.com> <177242454307.7472.11164903103911826962@noble.neil.brown.name> From: Chuck Lever Content-Language: en-US Organization: kernel.org In-Reply-To: <177242454307.7472.11164903103911826962@noble.neil.brown.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/1/26 11:09 PM, NeilBrown wrote: > On Mon, 02 Mar 2026, Chuck Lever wrote: >> >> On Sun, Mar 1, 2026, at 1:09 PM, Amir Goldstein wrote: >>> On Sun, Mar 1, 2026 at 6:21 PM Chuck Lever wrote: >>>> Perhaps that description nails down too much implementation detail, >>>> and it might be stale. A broader description is this user story: >>>> >>>> "As a system administrator, I'd like to be able to unexport an NFSD >>> >>> Doesn't "unexporting" involve communicating to nfsd? >>> Meaning calling to svc_export_put() to path_put() the >>> share root path? >>> >>>> share that is being accessed by NFSv4 clients, and then unmount it, >>>> reliably (for example, via automation). Currently the umount step >>>> hangs if there are still outstanding delegations granted to the NFSv4 >>>> clients." >>> >>> Can't svc_export_put() be the trigger for nfsd to release all resources >>> associated with this share? >> >> Currently unexport does not revoke NFSv4 state. So, that would >> be a user-visible behavior change. I suggested that approach a >> few months ago to linux-nfs@ and there was push-back. >> > > Could we add a "-F" or similar flag to "exportfs -u" which implements the > desired semantic? i.e. asking nfsd to release all locks and close all > state on the filesystem. That meets my needs, but should be passed by the linux-nfs@ review committee. -F could probably just use the existing "unlock filesystem" API after it does the unexport. -- Chuck Lever