> On Jan 18, 2023, at 2:42 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 2023-01-18 at 19:08 +0000, Chuck Lever III wrote: >> >>> On Jan 18, 2023, at 12:31 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>> >>> When queueing a dispose list to the appropriate "freeme" lists, it >>> pointlessly queues the objects one at a time to an intermediate list. >>> >>> Remove a few helpers and just open code a list_move to make it more >>> clear and efficient. Better document the resulting functions with >>> kerneldoc comments. >> >> I'd like to freeze the filecache code until we've sorted out the >> destroy_deleg_unhashed crashes. Shall I simply maintain 3/6 and >> 4/6 and any subsequent filecache changes (like my rhltable >> rewrite) on a topic branch? >> >> One good reason to do that is to enable an eventual fix to be >> backported to stable kernels without also needing to pull in >> intervening clean-up patches. >> >> I've already applied a couple small changes that I would rather >> wait on for this reason. I might move those over to the topic >> branch as well... I promise to keep it based on nfsd-next so it >> makes sense to continue developing filecache work on top of the >> topic branch. >> >> The other patches in this series are sensible clean-ups that I >> plan to apply for v6.3 if there are no other objections. >> > > So that means you won't take patches 3 and 4, but the rest are ok? They all look fine to me. I've applied 1, 2, 5, and 6 to nfsd-next, and 3 and 4 along with several others have been applied to a branch called topic-filecache-cleanups, which is published now so you can continue developing against that and so it will get pulled into the 0-day test harness. I will merge the stuff in that topic branch at some point, I'm just not committing yet to applying it specifically to v6.3. Yes, you can call me "too conservative." :-) But I am sensitive to addressing the destroy_unhashed_deleg crashers in v6.1, which is to become an LTS if I understand correctly. That's the main reason for adding this extra step for filecache-related clean-ups. Narrow bug fixes still go right into nfsd-next or nfsd-fixes, as usual. If this arrangement becomes onerous, I will mix those commits back into the general nfsd-next population and we will never speak of it again. -- Chuck Lever
