[PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

When a client holds an existing OPEN stateid for a file and then
requests a new OPEN that could receive a write delegation, the
server must not grant that delegation. A write delegation promises
the client it can handle "all opens" locally, but this promise is
violated when the server is already tracking open state for that
same client.

Currently, nfsd4_check_conflicting_opens() prevents write
delegations only when other clients have write opens. It does not
check for existing opens from the same client. This creates a
problematic situation:

1. Client opens file O_RDONLY, gets READ delegation (or just OPEN)
2. Client returns READ delegation but keeps the OPEN stateid
3. Client opens same file O_WRONLY
4. Server grants WRITE delegation
5. nfsd4_add_rdaccess_to_wrdeleg() tries to add READ access
6. Finds fp->fi_fds[O_RDONLY] already set from step 1

Seen with generic/750 over NFSv4.1.

Fixes: 1d3dd1d56ce8 ("NFSD: Enable write delegation support")
X-Cc: stable@vger.kernel.org
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/nfsd/nfs4state.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

Changes since v1:
* This patch replaces https://lore.kernel.org/linux-nfs/20251201220955.1949-1-cel@kernel.org/
* 2/2 adds a canary where this bug was caught


diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 35004568d43e..1c9802d06de1 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -5947,11 +5947,16 @@ static int nfsd4_check_conflicting_opens(struct nfs4_client *clp,
 	 */
 	spin_lock(&fp->fi_lock);
 	list_for_each_entry(st, &fp->fi_stateids, st_perfile) {
-		if (st->st_openstp == NULL /* it's an open */ &&
-		    access_permit_write(st) &&
-		    st->st_stid.sc_client != clp) {
-			spin_unlock(&fp->fi_lock);
-			return -EAGAIN;
+		if (st->st_openstp == NULL /* it's an open */) {
+			if (st->st_stid.sc_client != clp &&
+			    access_permit_write(st)) {
+				spin_unlock(&fp->fi_lock);
+				return -EAGAIN;
+			}
+			if (st->st_stid.sc_client == clp) {
+				spin_unlock(&fp->fi_lock);
+				return -EAGAIN;
+			}
 		}
 	}
 	spin_unlock(&fp->fi_lock);
-- 
2.52.0

[PATCH v2 2/2] NFSD: WARN if fi_fds[O_RDONLY] is already populated

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

nfsd4_add_rdaccess_to_wrdeleg() expects that fi_fds[O_RDONLY] is
NULL. If it's not NULL, there's a software bug somewhere else that
needs to be looked into.

Replace the redundant fp assignment with a WARN_ON_ONCE.

Suggested-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/nfsd/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 1c9802d06de1..b8fd0ed3fd53 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -6236,7 +6236,7 @@ nfsd4_add_rdaccess_to_wrdeleg(struct svc_rqst *rqstp, struct nfsd4_open *open,
 		fp = stp->st_stid.sc_file;
 		spin_lock(&fp->fi_lock);
 		__nfs4_file_get_access(fp, NFS4_SHARE_ACCESS_READ);
-		fp = stp->st_stid.sc_file;
+		WARN_ON_ONCE(fp->fi_fds[O_RDONLY] != NULL);
 		fp->fi_fds[O_RDONLY] = nf;
 		fp->fi_rdeleg_file = nf;
 		spin_unlock(&fp->fi_lock);
-- 
2.52.0

Re: [PATCH v2 2/2] NFSD: WARN if fi_fds[O_RDONLY] is already populated

[Jeff Layton]

On Tue, 2025-12-02 at 17:42 -0500, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> nfsd4_add_rdaccess_to_wrdeleg() expects that fi_fds[O_RDONLY] is
> NULL. If it's not NULL, there's a software bug somewhere else that
> needs to be looked into.
> 
> Replace the redundant fp assignment with a WARN_ON_ONCE.
> 
> Suggested-by: Jeff Layton <jlayton@kernel.org>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  fs/nfsd/nfs4state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 1c9802d06de1..b8fd0ed3fd53 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -6236,7 +6236,7 @@ nfsd4_add_rdaccess_to_wrdeleg(struct svc_rqst *rqstp, struct nfsd4_open *open,
>  		fp = stp->st_stid.sc_file;
>  		spin_lock(&fp->fi_lock);
>  		__nfs4_file_get_access(fp, NFS4_SHARE_ACCESS_READ);
> -		fp = stp->st_stid.sc_file;
> +		WARN_ON_ONCE(fp->fi_fds[O_RDONLY] != NULL);
>  		fp->fi_fds[O_RDONLY] = nf;
>  		fp->fi_rdeleg_file = nf;
>  		spin_unlock(&fp->fi_lock);

Given that the client can have the file open for read before we grant a
write deleg, then this would fire pretty often I think. This might not
be a good idea either.

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[NeilBrown]

On Wed, 03 Dec 2025, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> When a client holds an existing OPEN stateid for a file and then
> requests a new OPEN that could receive a write delegation, the
> server must not grant that delegation. A write delegation promises
> the client it can handle "all opens" locally, but this promise is
> violated when the server is already tracking open state for that
> same client.

Can you please spell out how the promise is violated?
Where RFC 8881, section 10.4 says

   An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
   own, all opens. 

I interpret that to mean that all open *requests* from the application can
now be handled without reference to the server.
I don't think that "all opens" can reasonably refer to "all existing or
future open state for the file".  Is that how you interpret it?

Thanks,
NeilBrown

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Chuck Lever]

On Tue, Dec 2, 2025, at 6:28 PM, NeilBrown wrote:
> On Wed, 03 Dec 2025, Chuck Lever wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>> 
>> When a client holds an existing OPEN stateid for a file and then
>> requests a new OPEN that could receive a write delegation, the
>> server must not grant that delegation. A write delegation promises
>> the client it can handle "all opens" locally, but this promise is
>> violated when the server is already tracking open state for that
>> same client.
>
> Can you please spell out how the promise is violated?
> Where RFC 8881, section 10.4 says
>
>    An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
>    own, all opens. 
>
> I interpret that to mean that all open *requests* from the application can
> now be handled without reference to the server.
> I don't think that "all opens" can reasonably refer to "all existing or
> future open state for the file".  Is that how you interpret it?

It is: as long as a client holds a write delegation stateid, that’s a
promise that the server will inform that client when any other client
wants to open that file. In other words, an NFS server can’t offer a
write delegation to a client if there is another OPEN on that file.

The issue here is about an OPEN that occurred in the past and is still
active, not a future OPEN. NFSD was checking for OPENs that other
clients had for a file before offering a write delegation, but it does not
currently check if the /requesting client/ itself has an OPEN stateid for
that file.

The scenario I observed is that the requesting client held an OPEN
for SHARED_ACCESS_READ on the file. The code in
nfsd4_add_rdaccess_to_wrdeleg() assumes that if NFSD is about
to set up a write delegation, the pointer in fi_fds[O_RDONLY] is NULL.
That assumption isn’t true if that client still holds the S_A_R OPEN
state id, and fi_fds[O_RDONLY] for that file then gets overwritten and
the nfsd_file it previously referenced is orphaned.


-- 
Chuck Lever

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[NeilBrown]

On Wed, 03 Dec 2025, Chuck Lever wrote:
> 
> On Tue, Dec 2, 2025, at 6:28 PM, NeilBrown wrote:
> > On Wed, 03 Dec 2025, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@oracle.com>
> >> 
> >> When a client holds an existing OPEN stateid for a file and then
> >> requests a new OPEN that could receive a write delegation, the
> >> server must not grant that delegation. A write delegation promises
> >> the client it can handle "all opens" locally, but this promise is
> >> violated when the server is already tracking open state for that
> >> same client.
> >
> > Can you please spell out how the promise is violated?
> > Where RFC 8881, section 10.4 says
> >
> >    An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
> >    own, all opens. 
> >
> > I interpret that to mean that all open *requests* from the application can
> > now be handled without reference to the server.
> > I don't think that "all opens" can reasonably refer to "all existing or
> > future open state for the file".  Is that how you interpret it?
> 
> It is: as long as a client holds a write delegation stateid, that’s a
> promise that the server will inform that client when any other client
> wants to open that file. In other words, an NFS server can’t offer a
> write delegation to a client if there is another OPEN on that file.

Agreed: "other" client and "another" OPEN.

> 
> The issue here is about an OPEN that occurred in the past and is still
> active, not a future OPEN. NFSD was checking for OPENs that other
> clients had for a file before offering a write delegation, but it does not
> currently check if the /requesting client/ itself has an OPEN stateid for
> that file.
> 

I don't see a problem with offering a write delegation when the client
previously had the same file open.
Note that a client only ever has one stateid for any given file.  If it
opens the same file again, it will get the same stateid - with seqid
incremented.  If it closes the stateid, then it will not have that file
open at all any more.

If the client has the file open for READ, then opens again for WRITE,
then it does not get "another" open, it gets "the same" open, but with
different access.  When the client hold a write delegation, then it can
be sure there is only one open stateid for that file - the one that it
holds (it cannot hold two for the same file).

> The scenario I observed is that the requesting client held an OPEN
> for SHARED_ACCESS_READ on the file. The code in
> nfsd4_add_rdaccess_to_wrdeleg() assumes that if NFSD is about
> to set up a write delegation, the pointer in fi_fds[O_RDONLY] is NULL.
> That assumption isn’t true if that client still holds the S_A_R OPEN
> state id, and fi_fds[O_RDONLY] for that file then gets overwritten and
> the nfsd_file it previously referenced is orphaned.

I agree that the current code is flawed.  It needs to allow for the
possibility that the client already had the file open.  I just don't see
the justification for withholding a delegation when an open is upgraded
from read-only to read-write.

If the client already holds a READ delegation, then I see that there
might be a problem.  I don't think there *should* be a problem, but I
cannot see in the RFC how it would be handled.  Would the existing
delegation get upgraded the same way that the OPEN stateid is upgraded? 
Or would a new delegation be issued?  The RFC isn't clear so I don't
think it can happen (safely).

I note that section 10.4 says:

    The following is a typical set of conditions that servers might use
    in deciding whether an OPEN should be delegated: 
     ....
    - There must be no current OPEN conflicting with the requested delegation.

That text seems advisory rather than normative.  Does an OPEN from the
same client conflict with a delegation?  Maybe it depends on your
perspective.

I also note 18.16.3 says:

     If another client has a delegation of the file being opened that
     conflicts with open being done (...), the delegation(s) MUST be
     recalled,

So if the SAME client has a delegation - it doesn't need to be recalled?

and
       In the case of an OPEN_DELEGATE_WRITE delegation, any open by a
       different client will conflict,

Again "different client" - any open by the same client, it would seem,
does not conflict.

Thanks,
NeilBrown

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Jeff Layton]

On Wed, 2025-12-03 at 13:31 +1100, NeilBrown wrote:
> On Wed, 03 Dec 2025, Chuck Lever wrote:
> > 
> > On Tue, Dec 2, 2025, at 6:28 PM, NeilBrown wrote:
> > > On Wed, 03 Dec 2025, Chuck Lever wrote:
> > > > From: Chuck Lever <chuck.lever@oracle.com>
> > > > 
> > > > When a client holds an existing OPEN stateid for a file and then
> > > > requests a new OPEN that could receive a write delegation, the
> > > > server must not grant that delegation. A write delegation promises
> > > > the client it can handle "all opens" locally, but this promise is
> > > > violated when the server is already tracking open state for that
> > > > same client.
> > > 
> > > Can you please spell out how the promise is violated?
> > > Where RFC 8881, section 10.4 says
> > > 
> > >    An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
> > >    own, all opens. 
> > > 
> > > I interpret that to mean that all open *requests* from the application can
> > > now be handled without reference to the server.
> > > I don't think that "all opens" can reasonably refer to "all existing or
> > > future open state for the file".  Is that how you interpret it?
> > 
> > It is: as long as a client holds a write delegation stateid, that’s a
> > promise that the server will inform that client when any other client
> > wants to open that file. In other words, an NFS server can’t offer a
> > write delegation to a client if there is another OPEN on that file.
> 
> Agreed: "other" client and "another" OPEN.
> 
> > 
> > The issue here is about an OPEN that occurred in the past and is still
> > active, not a future OPEN. NFSD was checking for OPENs that other
> > clients had for a file before offering a write delegation, but it does not
> > currently check if the /requesting client/ itself has an OPEN stateid for
> > that file.
> > 
> 
> I don't see a problem with offering a write delegation when the client
> previously had the same file open.
> Note that a client only ever has one stateid for any given file.  If it
> opens the same file again, it will get the same stateid - with seqid
> incremented.  If it closes the stateid, then it will not have that file
> open at all any more.
> 
> If the client has the file open for READ, then opens again for WRITE,
> then it does not get "another" open, it gets "the same" open, but with
> different access.  When the client hold a write delegation, then it can
> be sure there is only one open stateid for that file - the one that it
> holds (it cannot hold two for the same file).
> 
> > The scenario I observed is that the requesting client held an OPEN
> > for SHARED_ACCESS_READ on the file. The code in
> > nfsd4_add_rdaccess_to_wrdeleg() assumes that if NFSD is about
> > to set up a write delegation, the pointer in fi_fds[O_RDONLY] is NULL.
> > That assumption isn’t true if that client still holds the S_A_R OPEN
> > state id, and fi_fds[O_RDONLY] for that file then gets overwritten and
> > the nfsd_file it previously referenced is orphaned.
> 
> I agree that the current code is flawed.  It needs to allow for the
> possibility that the client already had the file open.  I just don't see
> the justification for withholding a delegation when an open is upgraded
> from read-only to read-write.
> 
> If the client already holds a READ delegation, then I see that there
> might be a problem.  I don't think there *should* be a problem, but I
> cannot see in the RFC how it would be handled.  Would the existing
> delegation get upgraded the same way that the OPEN stateid is upgraded? 
> Or would a new delegation be issued?  The RFC isn't clear so I don't
> think it can happen (safely).
> 
> I note that section 10.4 says:
> 
>     The following is a typical set of conditions that servers might use
>     in deciding whether an OPEN should be delegated: 
>      ....
>     - There must be no current OPEN conflicting with the requested delegation.
> 
> That text seems advisory rather than normative.  Does an OPEN from the
> same client conflict with a delegation?  Maybe it depends on your
> perspective.
> 
> I also note 18.16.3 says:
> 
>      If another client has a delegation of the file being opened that
>      conflicts with open being done (...), the delegation(s) MUST be
>      recalled,
> 
> So if the SAME client has a delegation - it doesn't need to be recalled?
> 
> and
>        In the case of an OPEN_DELEGATE_WRITE delegation, any open by a
>        different client will conflict,
> 
> Again "different client" - any open by the same client, it would seem,
> does not conflict.
> 

I agree with Neil here (despite my questioning this on our call
yesterday).

Conceptually, granting a write delegation to a client that already
holds an open stateid for the file doesn't seem problematic. Before
returning that delegation, the client would need to establish open
stateids for any opens that it had granted locally. If it already holds
an open stateid though, then that isn't a problem IMO -- it just has a
head start on establishing them before a DELEGRETURN.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Chuck Lever]

On Wed, Dec 3, 2025, at 7:26 AM, Jeff Layton wrote:
> On Wed, 2025-12-03 at 13:31 +1100, NeilBrown wrote:
>> On Wed, 03 Dec 2025, Chuck Lever wrote:
>> > 
>> > On Tue, Dec 2, 2025, at 6:28 PM, NeilBrown wrote:
>> > > On Wed, 03 Dec 2025, Chuck Lever wrote:
>> > > > From: Chuck Lever <chuck.lever@oracle.com>
>> > > > 
>> > > > When a client holds an existing OPEN stateid for a file and then
>> > > > requests a new OPEN that could receive a write delegation, the
>> > > > server must not grant that delegation. A write delegation promises
>> > > > the client it can handle "all opens" locally, but this promise is
>> > > > violated when the server is already tracking open state for that
>> > > > same client.
>> > > 
>> > > Can you please spell out how the promise is violated?
>> > > Where RFC 8881, section 10.4 says
>> > > 
>> > >    An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
>> > >    own, all opens. 
>> > > 
>> > > I interpret that to mean that all open *requests* from the application can
>> > > now be handled without reference to the server.
>> > > I don't think that "all opens" can reasonably refer to "all existing or
>> > > future open state for the file".  Is that how you interpret it?
>> > 
>> > It is: as long as a client holds a write delegation stateid, that’s a
>> > promise that the server will inform that client when any other client
>> > wants to open that file. In other words, an NFS server can’t offer a
>> > write delegation to a client if there is another OPEN on that file.
>> 
>> Agreed: "other" client and "another" OPEN.
>> 
>> > 
>> > The issue here is about an OPEN that occurred in the past and is still
>> > active, not a future OPEN. NFSD was checking for OPENs that other
>> > clients had for a file before offering a write delegation, but it does not
>> > currently check if the /requesting client/ itself has an OPEN stateid for
>> > that file.
>> > 
>> 
>> I don't see a problem with offering a write delegation when the client
>> previously had the same file open.
>> Note that a client only ever has one stateid for any given file.  If it
>> opens the same file again, it will get the same stateid - with seqid
>> incremented.  If it closes the stateid, then it will not have that file
>> open at all any more.

> I agree with Neil here (despite my questioning this on our call
> yesterday).
>
> Conceptually, granting a write delegation to a client that already
> holds an open stateid for the file doesn't seem problematic. Before
> returning that delegation, the client would need to establish open
> stateids for any opens that it had granted locally. If it already holds
> an open stateid though, then that isn't a problem IMO -- it just has a
> head start on establishing them before a DELEGRETURN.

Then you prefer the v1 patch that reuses the nfsd_file already
in fi_fds[O_RDONLY], and we can drop the addition of the
WARN_ON_ONCE ?


-- 
Chuck Lever

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Jeff Layton]

On Wed, 2025-12-03 at 09:54 -0500, Chuck Lever wrote:
> 
> On Wed, Dec 3, 2025, at 7:26 AM, Jeff Layton wrote:
> > On Wed, 2025-12-03 at 13:31 +1100, NeilBrown wrote:
> > > On Wed, 03 Dec 2025, Chuck Lever wrote:
> > > > 
> > > > On Tue, Dec 2, 2025, at 6:28 PM, NeilBrown wrote:
> > > > > On Wed, 03 Dec 2025, Chuck Lever wrote:
> > > > > > From: Chuck Lever <chuck.lever@oracle.com>
> > > > > > 
> > > > > > When a client holds an existing OPEN stateid for a file and then
> > > > > > requests a new OPEN that could receive a write delegation, the
> > > > > > server must not grant that delegation. A write delegation promises
> > > > > > the client it can handle "all opens" locally, but this promise is
> > > > > > violated when the server is already tracking open state for that
> > > > > > same client.
> > > > > 
> > > > > Can you please spell out how the promise is violated?
> > > > > Where RFC 8881, section 10.4 says
> > > > > 
> > > > >    An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its
> > > > >    own, all opens. 
> > > > > 
> > > > > I interpret that to mean that all open *requests* from the application can
> > > > > now be handled without reference to the server.
> > > > > I don't think that "all opens" can reasonably refer to "all existing or
> > > > > future open state for the file".  Is that how you interpret it?
> > > > 
> > > > It is: as long as a client holds a write delegation stateid, that’s a
> > > > promise that the server will inform that client when any other client
> > > > wants to open that file. In other words, an NFS server can’t offer a
> > > > write delegation to a client if there is another OPEN on that file.
> > > 
> > > Agreed: "other" client and "another" OPEN.
> > > 
> > > > 
> > > > The issue here is about an OPEN that occurred in the past and is still
> > > > active, not a future OPEN. NFSD was checking for OPENs that other
> > > > clients had for a file before offering a write delegation, but it does not
> > > > currently check if the /requesting client/ itself has an OPEN stateid for
> > > > that file.
> > > > 
> > > 
> > > I don't see a problem with offering a write delegation when the client
> > > previously had the same file open.
> > > Note that a client only ever has one stateid for any given file.  If it
> > > opens the same file again, it will get the same stateid - with seqid
> > > incremented.  If it closes the stateid, then it will not have that file
> > > open at all any more.
> 
> > I agree with Neil here (despite my questioning this on our call
> > yesterday).
> > 
> > Conceptually, granting a write delegation to a client that already
> > holds an open stateid for the file doesn't seem problematic. Before
> > returning that delegation, the client would need to establish open
> > stateids for any opens that it had granted locally. If it already holds
> > an open stateid though, then that isn't a problem IMO -- it just has a
> > head start on establishing them before a DELEGRETURN.
> 
> Then you prefer the v1 patch that reuses the nfsd_file already
> in fi_fds[O_RDONLY], and we can drop the addition of the
> WARN_ON_ONCE ?
> 

Yeah, I think that's probably the best thing to do.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[NeilBrown]

On Thu, 04 Dec 2025, Chuck Lever wrote:
> 
> On Wed, Dec 3, 2025, at 7:26 AM, Jeff Layton wrote:

> 
> > I agree with Neil here (despite my questioning this on our call
> > yesterday).

Ahh.. I wondered what had triggered the about-face between one patch set
and the next.  I now see it was your off-line conversation ...
Maybe it would help to surface this:

  Jeff suggested in a private conversation that ....  so this version
  takes a different approach and .....

??

> 
> Then you prefer the v1 patch that reuses the nfsd_file already
> in fi_fds[O_RDONLY], and we can drop the addition of the
> WARN_ON_ONCE ?

That is the direction that I would prefer too.

Thanks,
NeilBrown

Re: [PATCH v2 1/2] nfsd: prevent write delegations when client has existing opens

[Chuck Lever]

On Wed, Dec 3, 2025, at 5:45 PM, NeilBrown wrote:
> On Thu, 04 Dec 2025, Chuck Lever wrote:
>> 
>> On Wed, Dec 3, 2025, at 7:26 AM, Jeff Layton wrote:
>
>> 
>> > I agree with Neil here (despite my questioning this on our call
>> > yesterday).
>
> Ahh.. I wondered what had triggered the about-face between one patch set
> and the next.  I now see it was your off-line conversation ...
> Maybe it would help to surface this:
>
>   Jeff suggested in a private conversation that ....  so this version
>   takes a different approach and .....

The idea I took from my conversation with Jeff was that v1 might not
have actually gotten to the root of the problem. I thought it might be
evident from the higher-level fix in v2 that RCA was ongoing, but
perhaps it wasn’t that obvious.


>> Then you prefer the v1 patch that reuses the nfsd_file already
>> in fi_fds[O_RDONLY], and we can drop the addition of the
>> WARN_ON_ONCE ?
>
> That is the direction that I would prefer too.

I’ve applied v1 to nfsd-testing. As always, it is still open to review
comments.


-- 
Chuck Lever