On Mon, Jul 14, 2025 at 01:50:48PM +1000, NeilBrown wrote: > On Wed, 09 Jul 2025, Mike Snitzer wrote: > > [Preface: this revert makes it much less likely to "lose the race", > > whereby causing nfsd_shutdown_net() to hang, so we'd do well to take > > the time/care to properly fix whatever is lacking in Neil's commit > > c25a89770d1f] > > Was this the first time you posted on this issue? If so it seem strange > to start a discussion with a revert with out a clear undertstanding of > the problem... Might seem strange, but it seems strange for code to have gotten upstream without having been properly tested to reveal such basic issues. And when I embarked on what should've been a quick revert, only to find that the series of changes weren't even bisect safe, that only gave me more justification to rip all the code out in the hopes of restoring known solid LOCALIO functionality (from v6.14). > > Maybe > > --- a/fs/nfs_common/nfslocalio.c > +++ b/fs/nfs_common/nfslocalio.c > @@ -177,7 +177,7 @@ static bool nfs_uuid_put(nfs_uuid_t *nfs_uuid) > /* nfs_close_local_fh() is doing the > * close and we must wait. until it unlinks > */ > - wait_var_event_spinlock(nfl, > + wait_var_event_spinlock(nfl->nfs_uuid, > list_first_entry_or_null( > &nfs_uuid->files, > struct nfs_file_localio, > > > will fix the problem - I'm waiting on the wrong address, which could > cause various things to hang. Yes, as I just replied to your official patch posting for this, I will test. But the "maybe" nature lacks confidence and that needs to improve. ;) Are you able to test LOCALIO? I'll work to get better at making time to treat your LOCALIO changes as if they are my own and to fully embrace associated review/test work. But that work never quite reaches the same level of investment for me to do so as when I develop the change.. maybe "normal" but I need to get past that. We're in this together! Thanks for your time on this Neil! Mike
