Re: [PATCH] erofs: use the opener's credential when verifing metadata accesses

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/5/11 14:18, Christoph Hellwig wrote:
> On Fri, May 08, 2026 at 05:10:21PM +0800, Gao Xiang wrote:
>> On the one side, I hope if there could be some interface for
>> such temporary usage rather than just one vfs_iter_read model.
> 
> As in a in-kernel mmap?  While not entirely impossible, the locking
> model for that sounds horrible.

I don't think it needs a full in-kernel mmap, it just works on
some uptodate folios.

Which locking model? For page cache, it's expected that all folios
shouldn't clear uptodate randomly at any time.

At least for erofs use cases, we only care uptodate folios, no
matter if it's being invalidated/truncated or not (mapping == NULL).
Maybe it's not suitable for other stricter cases, but for immutable
fs models, that is enough and efficient.

> 
>>> Now for reads it mostly works on the most common disk-based file systems,
>>> but it does create lots of problem for slightly more complex ones like
>>> network/clustered or synthetic file systems.  It also really breaks
>>
>> Just out of curiousity, could you point out one specific path
>> so I can look into that.
> 
> file system might require their own locking, e.g. cluster locks for
> cluster file systems, and at least in the path direct page cache access
> also caused problems with NFS data invalidation semantics.  Last but not
> least ->read_folio has a file paramater that isn't really a file but a
> file system specific cookie.  So calling this with something not managed
> by the file system can cause problems as has caused crashes in the past,
> although the offender at that time (the old smbfs) is now gone.

file is indeed a cookie, but I did some research on the codebase,
and I've seen no odd cases other than a real "struct file *" anymore.

I agree such usage is kind of gray area, but I've seen no risk in
practice as long as the underlay fs supports proper ->read_folio
callback (and erofs restricts that.)

> 
>> But could we just fix this issue first for previous linux versions?
> 
> I just pointed out another issue.  You'll have to fix the credentials
> either way.

I really hope Matthew could give some opinion on this too, because
this way, the underlay cache can be directly used for temporary use,
and it should be a RO access and won't impact any fs-owned state.

Anyway, I could work out an alternative, but that makes the metadata
access less efficient.

Thanks,
Gao Xiang