Re: [PATCH v2] nfsd: do not allow exporting of special kernel filesystems

[Christoph Hellwig <hch@lst.de>]

On Thu, Jan 22, 2026 at 03:19:42PM +0100, Amir Goldstein wrote:
> Most of the stakeholders approved the approach in v1 [1] and
> only comments were regarding lack of documentation for the new
> incomapatible methods.
> 
> I did my best to add minimal documentation to express the fact
> that those methods are not compatible with nfsd and remote filesystem
> export in general.
> 
> Further documentations regarding the new uses of export_operations
> beyond their original use for nfs export is outside the scope of this
> patch and frankly, outside the reach of my documentation skills...

As last time I'd be happy to help write documentation, but even
after looking at the methods, their documentations and the commits
adding them I do not understand them.  So getting an explanation
from Christian would be really helpful to move forward here.

Note that you and Jan reviewed those patches, so I'd hope you two
know at least a little about the use case as well.

Btw, the nsfs ->open method seems identical to the default.


>   * permission:
> + *    Allow filesystems to specify a custom permission function for the
> + *    open_by_handle_at(2) syscall instead of the default CAP_DAC_READ_SEARCH
> + *    check. This custom permission function is not respected by nfsd.

may_decode_fh actually does a lot more things if the capable check
fails. (btw, shouldn't that use (ns_)capable_noaudit to not generate
audit messages?).