Re: [PATCH 1/2] fs: add a FMODE_ flag to indicate IOCB_HAS_METADATA availability

[Christoph Hellwig <hch@lst.de>]

On Tue, Aug 19, 2025 at 12:14:26PM +0200, Christian Brauner wrote:
> On Tue, Aug 19, 2025 at 11:22:19AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 19, 2025 at 11:14:41AM +0200, Christian Brauner wrote:
> > > It kind of feels like that f_iocb_flags should be changed so that
> > > subsystems like block can just raise some internal flags directly
> > > instead of grabbing a f_mode flag everytime they need to make some
> > > IOCB_* flag conditional on the file. That would mean changing the
> > > unconditional assigment to file->f_iocb_flags to a |= to not mask flags
> > > raised by the kernel itself.
> > 
> > This isn't about block.  I will be setting this for a file system
> > operation as well and use the same io_uring code for that.  That's
> > how I ran into the issue.
> 
> Yes, I get that. That's not what this is about. If IOCB_* flags keep
> getting added that then need an additional opt-out via an FMODE_* flag
> it's very annoying because you keep taking FMODE_* bits.

Agreed.

> The thing is
> that it should be possible to keep that information completely contained
> to f_iocb_flags without polluting f_mode.

I don't really understand how that would work.  The basic problem is that
we add optional features/flags to read and write, and we need a way to
check that they are supported and reject them without each time having
to update all instances.  For that VFS-level code needs some way to do
a per-instance check of available features.