Re: [PATCH 5.10 762/770] nfsd: separate nfsd_last_thread() from nfsd_put()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 18, 2024 at 03:20:51AM -0400, Dominique Martinet wrote:
> (Sorry for the slow reply)
> 
> Jeff Layton wrote on Tue, Jun 25, 2024 at 11:45:22AM -0400:
> > > Jeff, you're the one who suggested reverting the two back then, sorry
> > > to
> > > dump it on you but do you remember the kind of problems you ran into?
> > > Is there any chance it would have gone unoticed in the 5.15 tree for
> > > 2.5 months? (5.15.154 was April 2024)
> > 
> > Sorry, I don't think I kept a record of that panic that I hit at the
> > time. I do think that I looked at the original bug report and it looked
> > like it was probably the same problem, but I don't remember the
> > details.
> > 
> > I think I just mentioned reverting them because I didn't see the
> > benefit in taking those into an old kernel. These are privileged
> > anyway, so even if they are bugs I don't seem them as particularly
> > critical.
> 
> Right, normal users can't stop the nfsd so you're correct it probably
> doesn't matter as far as security goes (and this correctly doesn't have
> any of the shiny new CVEs assigned); I'm now curious why it got
> backported to all these trees at all if nothing needs it.

We wanted to backport the NFSD file cache fixes from v5.19 through
v6.3 to LTS v6.1, v5.15, and v5.10. Since it wasn't just a handful
of specific patches that fixed the NFSD file cache, Sasha and Greg
asked me to backport the full range of NFSD commits up until v6.3
to these 3 kernels. The goals were:

1. To fix the file cache
2. To create a platform in the LTS code bases to make it easier to
   backport the more complex upstream NFSD fixes going forward

Thus the backport of course included some commits that would not
normally have been backported to an LTS kernel. That has surprised
a few folks.


> Anyway, I really just started looking at it because it got reverted in
> 6.1 so was wondering why it didn't get reverted in other trees, but if
> it hadn't made it to any tree I wouldn't have cared at all...
> 
> As long as there doesn't seem to be a problem with older trees (and at
> least I'm not getting any weird hang or crash on shutdown on my 5.10)
> let's leave things as they are.

The only bothersome thing seems to be the inconsistency between the
LTS kernels. I haven't heard a report of a problem.


> > > (Bonus question: if that is really all there is, would that make
> > > sense
> > > / should we take the commits back in 6.1 with that extra fix?)
> > 
> > Maybe? The problem is that someone has to do the testing for this.
> > These interfaces aren't currently part of any testsuite, so a lot of
> > that tends to be a manual effort.
> 
> Agreed, let's not add more work there if no-one can quickly test this.
> 
> If it turns out some later commit that actually needs this gets
> backported to 6.1 we can always bring the pair of commits back when
> someone notices.

Sounds like a plan.


-- 
Chuck Lever




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux