On Mon, 2024-11-11 at 11:26 -0500, Chuck Lever wrote:
> On Mon, Nov 11, 2024 at 11:01:13AM -0500, Jeff Layton wrote:
> > The inode that nfs4_open_delegation() passes to this function is
> > wrong, which throws off the result. The inode will end up getting a
> > directory-style change attr instead of a regular-file-style one.
> >
> > Fix up nfs4_delegation_stat() to fetch STATX_MODE, and then drop the
> > inode parameter from nfsd4_change_attribute(), since it's no longer
> > needed.
> >
> > Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation")
> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> > ---
> > This version should apply cleanly to v6.12-rc7. Some later patches in
> > nfsd-next might need to be twiddled as a result, but it should be simple
> > to fix. Also, I fixed up the Fixes: to point to the right commit. This
> > dates back a bit further than I had originally thought.
>
> Ah. The Fixes: change makes this interesting. If we're not
> addressing a fix that is limited to in 12-rc, then I lean more
> towards getting this in via a normal merge window.
>
Ok.
> Also, it's pretty late in the -rc window to take fixes that are more
> than a few lines. I would like to see changes like this get some
> time in linux-next etc etc (which it has already done for v6.13, but
> would be difficult to guarantee for v6.12-rc at this point).
>
> So then that changes my concern about this to only reducing the
> number of pre-requisite patches that will need to be backported to
> cleanly apply this fix to LTS kernels.
>
> So about this:
>
> - Apply this version of the patch to nfsd-next, but earlier in the
> series
>
> - Fix up the later patches, as you mentioned above
>
> - Then let automation grab it for LTS 6.11 and 6.12
>
> Does that sound over-caffeinated, or would you be OK if I reordered
> nfsd-next as described here?
>
That sounds fine to me.
--
Jeff Layton <jlayton@xxxxxxxxxx>
