Re: [PATCH] NFSD: Guard admin state-revocation walks with NFSD_NET_UP
Jeff Layton <[email protected]>
| Newsgroups | gmane.linux.nfs |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2026-06-22 at 09:14 -0400, Chuck Lever wrote: > On Mon, 2026-06-22 at 07:57 -0400, Jeff Layton wrote: > > Can nn->nfsd_serv be non-NULL while the NFSv4 state tables are still > > NULL? > > ... > > Would checking nn->nfsd_net_up instead of nn->nfsd_serv be more > > accurate here, since nfsd_net_up is set at the tail of > > nfsd_startup_net() exactly when the state tables become valid? > > Yep, that's exactly the gap. The hunk you've quoted is 1/3 of the > earlier "post-shutdown use-after-free" series, which only guarded the > shutdown side of the window. nn->nfsd_serv is also set at service > creation, before nfsd_startup_net() allocates conf_id_hashtbl, so the > startup side was still exposed. > > The thread you're replying to is the follow-on that closes it: it > switches all three unlock paths (write_unlock_fs, > nfsd_nl_unlock_filesystem_doit, nfsd_nl_unlock_export_doit) from > nn->nfsd_serv to test_bit(NFSD_NET_UP, &nn->flags) and rewrites the > walkers' Context: notes to match. NFSD_NET_UP is set at the tail of > nfsd_startup_net() and cleared in nfsd_shutdown_net() after the tables > are freed, so it brackets precisely the window you describe. > > I assume your comment was meant for 1/3 of that series rather than > this thread... but we've reached the same conclusion, so no action > needed beyond this patch, correct? Ahh right. I missed that that had been fixed in the other series. This is fine then. Reviewed-by: Jeff Layton <[email protected]>