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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.