On Fri, 30 Aug 2024, Chuck Lever wrote:
> On Thu, Aug 29, 2024 at 09:26:39AM -0400, Jeff Layton wrote:
> > From: NeilBrown <neilb@xxxxxxx>
> >
> > It is not safe to dereference fl->c.flc_owner without first confirming
> > fl->fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict()
> > tests fl_lmops but largely ignores the result and assumes that flc_owner
> > is an nfs4_delegation anyway. This is wrong.
> >
> > With this patch we restore the "!= &nfsd_lease_mng_ops" case to behave
> > as it did before the changed mentioned below. This the same as the
> > current code, but without any reference to a possible delegation.
> >
> > Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation")
> > Signed-off-by: NeilBrown <neilb@xxxxxxx>
> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
>
> I've already applied this to nfsd-fixes.
>
> If I include this commit in both nfsd-fixes and nfsd-next then the
> linux-next merge whines about duplicate patches. Stephen Rothwell
> suggested git-merging nfsd-fixes and nfsd-next but I'm not quite
> confident enough to try that.
>
> Barring another solution, merging this series will have to wait a
> few days before the two trees can sync up.
Hmmm.... I would probably always rebase nfsd-next on nfsd-fixes, which
I would rebase on the most recent of rc0, rc1, or the latest rc to
receive nfsd patches.
nfsd-fixes is currently based on 6.10-rc7, while -next is based on
6.11-rc5.
Why the 6.10 base??
NeilBrown
