> On Aug 30, 2024, at 2:01 AM, NeilBrown <neilb@xxxxxxx> wrote: > > 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. That straightforward strategy leaves NFSD fixes scattered throughout the merge history. > nfsd-fixes is currently based on 6.10-rc7, while -next is based on > 6.11-rc5. > > Why the 6.10 base?? nfsd-fixes extends the branch I initially submitted to Linus for the last merge window. That makes it easy to locate the full set of NFSD commits that go into each kernel release in the order they were submitted and keeps the merge topology simpler. B - C - D - E <<< nfsd / \ \ - A - X - Y - Z - AA - <<< master Or, that's the theory anyway. And generally it's not an irritant except for right near the end of the development cycle. I'm not 100% wedded to this approach, and I am interested in discussion and improvement. Stephen Rothwell suggested that I provide a single merged branch for development and for linux-next to pull. I almost understand how to do that, but it's still a bit beyond my current everyday tooling (stgit). -- Chuck Lever