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.