Re: recap of 9p problems in 6.9

["Eric Van Hensbergen" <eric.vanhensbergen@linux.dev>]

April 8, 2024 at 9:07 PM, "Dominique Martinet" <asmadeus@codewreck.org> wrote:
> Replying to both mails at once
> Eric Van Hensbergen wrote on Mon, Apr 08, 2024 at 11:14:07PM +0000: 
> > Thanks for looking into these Dominique - I've got the reports queued
> >  up and am just looking to ring fence some time to dig into them before
> >  I commit to a revert. The change in handling of inode matching and
> >  keeping inodes around in the cache longer are likely the root of all
> >  of these, but the old code had so much unexplained corner cases I
> >  really want to understand the problems before revert.
> My opinion here is that there's been quite a few people reporting to be
> impacted, so while I agree we need to understand the old cruft
> eventually I think it's time to rollback and try harder to reproduce
> the various errors we've been reported and investigate in another branch
> (not even -next, as that is also used by people for non-reg -- breaking
> other parts of the kernel's non-reg will just make people stop using 9p)
> And when we do finally manage to reproduce this that'll make another
> workload we can test regularly for future regressions, I think we need
> more of these (like my parallel unlink code); everything I'm running is
> either too nice (e.g. proper build without parallel write accesses
> within a file) or too synthetic (fsstress etc); more "real-world" tests
> can't hurt.
> 

I do agree with this, but want one more day before I give up.  I'm going to work on this today and tomorrow to see if I can fix Kent and Oleg's problems, including looking at a partial revert (as you suggest, maybe just reverting the inode_drop patch would clean up most of these for the time being since everyone doesn't seem to be operating in cached mode anyways).

Sorry for diving down the rat hole last night, I should have just looked at the trace.  I've added access=client to my test sweeps so I can see if Kent's problem is related to acls.  fstest just takes so long to run.

     -eric