io_uring / dio metadata fixes

io_uring / dio metadata fixes

[Christoph Hellwig]

Hi all,

while trying to add XFS support for passing through metadata I ran
into a few issues with how that support is wire up for the current
block device use cases, and this fixes it.

Diffstat:
 block/fops.c       |   13 ++++++++-----
 include/linux/fs.h |    3 ++-
 io_uring/rw.c      |    3 +++
 3 files changed, 13 insertions(+), 6 deletions(-)

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

[Christoph Hellwig]

Currently the kernel will happily route io_uring requests with metadata
to file operations that don't support it.  Add a FMODE_ flag to guard
that.

Fixes: 4de2ce04c862 ("fs: introduce IOCB_HAS_METADATA for metadata")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/fops.c       | 3 +++
 include/linux/fs.h | 3 ++-
 io_uring/rw.c      | 3 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/block/fops.c b/block/fops.c
index 82451ac8ff25..08e7c21bd9f1 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -7,6 +7,7 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <linux/blkdev.h>
+#include <linux/blk-integrity.h>
 #include <linux/buffer_head.h>
 #include <linux/mpage.h>
 #include <linux/uio.h>
@@ -687,6 +688,8 @@ static int blkdev_open(struct inode *inode, struct file *filp)
 
 	if (bdev_can_atomic_write(bdev))
 		filp->f_mode |= FMODE_CAN_ATOMIC_WRITE;
+	if (blk_get_integrity(bdev->bd_disk))
+		filp->f_mode |= FMODE_HAS_METADATA;
 
 	ret = bdev_open(bdev, mode, filp->private_data, NULL, filp);
 	if (ret)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d7ab4f96d705..601d036a6c78 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -149,7 +149,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
 /* Expect random access pattern */
 #define FMODE_RANDOM		((__force fmode_t)(1 << 12))
 
-/* FMODE_* bit 13 */
+/* Supports IOCB_HAS_METADATA */
+#define FMODE_HAS_METADATA	((__force fmode_t)(1 << 13))
 
 /* File is opened with O_PATH; almost nothing can be done with it */
 #define FMODE_PATH		((__force fmode_t)(1 << 14))
diff --git a/io_uring/rw.c b/io_uring/rw.c
index 52a5b950b2e5..af5a54b5db12 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -886,6 +886,9 @@ static int io_rw_init_file(struct io_kiocb *req, fmode_t mode, int rw_type)
 	if (req->flags & REQ_F_HAS_METADATA) {
 		struct io_async_rw *io = req->async_data;
 
+		if (!(file->f_mode & FMODE_HAS_METADATA))
+			return -EINVAL;
+
 		/*
 		 * We have a union of meta fields with wpq used for buffered-io
 		 * in io_async_rw, so fail it here.
-- 
2.47.2

[PATCH 2/2] block: don't silently ignore metadata for sync read/write

[Christoph Hellwig]

The block fops don't try to handle metadata for synchronous requests,
probably because the completion handler looks at dio->iocb which is not
valid for synchronous requests.

But silently ignoring metadata (or warning in case of
__blkdev_direct_IO_simple) is a really bad idea as that can cause
silent data corruption if a user ever shows up.

Instead simply handle metadata for synchronous requests as the completion
handler can simply check for bio_integrity() as the block layer default
integrity will already be freed at this point, and thus bio_integrity()
will only return true for user mapped integrity.

Fixes: 3d8b5a22d404 ("block: add support to pass user meta buffer")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/fops.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/block/fops.c b/block/fops.c
index 08e7c21bd9f1..ddbc69c0922b 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -55,7 +55,6 @@ static ssize_t __blkdev_direct_IO_simple(struct kiocb *iocb,
 	struct bio bio;
 	ssize_t ret;
 
-	WARN_ON_ONCE(iocb->ki_flags & IOCB_HAS_METADATA);
 	if (nr_pages <= DIO_INLINE_BIO_VECS)
 		vecs = inline_vecs;
 	else {
@@ -132,7 +131,7 @@ static void blkdev_bio_end_io(struct bio *bio)
 	if (bio->bi_status && !dio->bio.bi_status)
 		dio->bio.bi_status = bio->bi_status;
 
-	if (!is_sync && (dio->iocb->ki_flags & IOCB_HAS_METADATA))
+	if (bio_integrity(bio))
 		bio_integrity_unmap_user(bio);
 
 	if (atomic_dec_and_test(&dio->ref)) {
@@ -234,7 +233,7 @@ static ssize_t __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter,
 			}
 			bio->bi_opf |= REQ_NOWAIT;
 		}
-		if (!is_sync && (iocb->ki_flags & IOCB_HAS_METADATA)) {
+		if (iocb->ki_flags & IOCB_HAS_METADATA) {
 			ret = bio_integrity_map_iter(bio, iocb->private);
 			if (unlikely(ret))
 				goto fail;
@@ -302,7 +301,7 @@ static void blkdev_bio_end_io_async(struct bio *bio)
 		ret = blk_status_to_errno(bio->bi_status);
 	}
 
-	if (iocb->ki_flags & IOCB_HAS_METADATA)
+	if (bio_integrity(bio))
 		bio_integrity_unmap_user(bio);
 
 	iocb->ki_complete(iocb, ret);
@@ -423,7 +422,8 @@ static ssize_t blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
 	}
 
 	nr_pages = bio_iov_vecs_to_alloc(iter, BIO_MAX_VECS + 1);
-	if (likely(nr_pages <= BIO_MAX_VECS)) {
+	if (likely(nr_pages <= BIO_MAX_VECS &&
+		   !(iocb->ki_flags & IOCB_HAS_METADATA))) {
 		if (is_sync_kiocb(iocb))
 			return __blkdev_direct_IO_simple(iocb, iter, bdev,
 							nr_pages);
-- 
2.47.2

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

[Christian Brauner]

On Tue, Aug 19, 2025 at 10:25:00AM +0200, Christoph Hellwig wrote:
> Currently the kernel will happily route io_uring requests with metadata
> to file operations that don't support it.  Add a FMODE_ flag to guard
> that.
> 
> Fixes: 4de2ce04c862 ("fs: introduce IOCB_HAS_METADATA for metadata")
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---

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.

Then you can just push the burden of stuff like IOCB_HAS_* vs
IOCB_SUPPORTS/CAN_* to f_iocb_flags instead of the FMODE_* space.

>  block/fops.c       | 3 +++
>  include/linux/fs.h | 3 ++-
>  io_uring/rw.c      | 3 +++
>  3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/block/fops.c b/block/fops.c
> index 82451ac8ff25..08e7c21bd9f1 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -7,6 +7,7 @@
>  #include <linux/init.h>
>  #include <linux/mm.h>
>  #include <linux/blkdev.h>
> +#include <linux/blk-integrity.h>
>  #include <linux/buffer_head.h>
>  #include <linux/mpage.h>
>  #include <linux/uio.h>
> @@ -687,6 +688,8 @@ static int blkdev_open(struct inode *inode, struct file *filp)
>  
>  	if (bdev_can_atomic_write(bdev))
>  		filp->f_mode |= FMODE_CAN_ATOMIC_WRITE;
> +	if (blk_get_integrity(bdev->bd_disk))
> +		filp->f_mode |= FMODE_HAS_METADATA;
>  
>  	ret = bdev_open(bdev, mode, filp->private_data, NULL, filp);
>  	if (ret)
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index d7ab4f96d705..601d036a6c78 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -149,7 +149,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
>  /* Expect random access pattern */
>  #define FMODE_RANDOM		((__force fmode_t)(1 << 12))
>  
> -/* FMODE_* bit 13 */
> +/* Supports IOCB_HAS_METADATA */
> +#define FMODE_HAS_METADATA	((__force fmode_t)(1 << 13))
>  
>  /* File is opened with O_PATH; almost nothing can be done with it */
>  #define FMODE_PATH		((__force fmode_t)(1 << 14))
> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index 52a5b950b2e5..af5a54b5db12 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
> @@ -886,6 +886,9 @@ static int io_rw_init_file(struct io_kiocb *req, fmode_t mode, int rw_type)
>  	if (req->flags & REQ_F_HAS_METADATA) {
>  		struct io_async_rw *io = req->async_data;
>  
> +		if (!(file->f_mode & FMODE_HAS_METADATA))
> +			return -EINVAL;
> +
>  		/*
>  		 * We have a union of meta fields with wpq used for buffered-io
>  		 * in io_async_rw, so fail it here.
> -- 
> 2.47.2
> 

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

[Christoph Hellwig]

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.

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

[Christian Brauner]

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. The thing is
that it should be possible to keep that information completely contained
to f_iocb_flags without polluting f_mode.

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

[Christoph Hellwig]

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.

Re: [PATCH 2/2] block: don't silently ignore metadata for sync read/write

[Martin K. Petersen]

Christoph,

> The block fops don't try to handle metadata for synchronous requests,
> probably because the completion handler looks at dio->iocb which is
> not valid for synchronous requests.
>
> But silently ignoring metadata (or warning in case of
> __blkdev_direct_IO_simple) is a really bad idea as that can cause
> silent data corruption if a user ever shows up.

Looks fine.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen

Re: io_uring / dio metadata fixes

[Christian Brauner]

On Tue, 19 Aug 2025 10:24:59 +0200, Christoph Hellwig wrote:
> while trying to add XFS support for passing through metadata I ran
> into a few issues with how that support is wire up for the current
> block device use cases, and this fixes it.
> 
> Diffstat:
>  block/fops.c       |   13 ++++++++-----
>  include/linux/fs.h |    3 ++-
>  io_uring/rw.c      |    3 +++
>  3 files changed, 13 insertions(+), 6 deletions(-)
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/2] fs: add a FMODE_ flag to indicate IOCB_HAS_METADATA availability
      https://git.kernel.org/vfs/vfs/c/d072148a8631
[2/2] block: don't silently ignore metadata for sync read/write
      https://git.kernel.org/vfs/vfs/c/2729a60bbfb9

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

[Christian Brauner]

On Tue, Aug 19, 2025 at 03:34:47PM +0200, Christoph Hellwig wrote:
> 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.

I meant something like this which should effectively be the same thing
just that we move the burden of having to use two bits completely into
file->f_iocb_flags instead of wasting a file->f_mode bit:

diff --git a/block/fops.c b/block/fops.c
index ddbc69c0922b..a90f1127d035 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -689,7 +689,7 @@ static int blkdev_open(struct inode *inode, struct file *filp)
        if (bdev_can_atomic_write(bdev))
                filp->f_mode |= FMODE_CAN_ATOMIC_WRITE;
        if (blk_get_integrity(bdev->bd_disk))
-               filp->f_mode |= FMODE_HAS_METADATA;
+               filp->f_iocb_flags |= IOCB_MAY_USE_METADATA;

        ret = bdev_open(bdev, mode, filp->private_data, NULL, filp);
        if (ret)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 601d036a6c78..a40a1bf7bad5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -149,9 +149,6 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
 /* Expect random access pattern */
 #define FMODE_RANDOM           ((__force fmode_t)(1 << 12))

-/* Supports IOCB_HAS_METADATA */
-#define FMODE_HAS_METADATA     ((__force fmode_t)(1 << 13))
-
 /* File is opened with O_PATH; almost nothing can be done with it */
 #define FMODE_PATH             ((__force fmode_t)(1 << 14))

@@ -384,25 +381,27 @@ struct readahead_control;
 /* kiocb is a read or write operation submitted by fs/aio.c. */
 #define IOCB_AIO_RW            (1 << 23)
 #define IOCB_HAS_METADATA      (1 << 24)
+#define IOCB_MAY_USE_METADATA  (1 << 25)

 /* for use in trace events */
 #define TRACE_IOCB_STRINGS \
-       { IOCB_HIPRI,           "HIPRI" }, \
-       { IOCB_DSYNC,           "DSYNC" }, \
-       { IOCB_SYNC,            "SYNC" }, \
-       { IOCB_NOWAIT,          "NOWAIT" }, \
-       { IOCB_APPEND,          "APPEND" }, \
-       { IOCB_ATOMIC,          "ATOMIC" }, \
-       { IOCB_DONTCACHE,       "DONTCACHE" }, \
-       { IOCB_EVENTFD,         "EVENTFD"}, \
-       { IOCB_DIRECT,          "DIRECT" }, \
-       { IOCB_WRITE,           "WRITE" }, \
-       { IOCB_WAITQ,           "WAITQ" }, \
-       { IOCB_NOIO,            "NOIO" }, \
-       { IOCB_ALLOC_CACHE,     "ALLOC_CACHE" }, \
-       { IOCB_DIO_CALLER_COMP, "CALLER_COMP" }, \
-       { IOCB_AIO_RW,          "AIO_RW" }, \
-       { IOCB_HAS_METADATA,    "AIO_HAS_METADATA" }
+       { IOCB_HIPRI,                   "HIPRI" }, \
+       { IOCB_DSYNC,                   "DSYNC" }, \
+       { IOCB_SYNC,                    "SYNC" }, \
+       { IOCB_NOWAIT,                  "NOWAIT" }, \
+       { IOCB_APPEND,                  "APPEND" }, \
+       { IOCB_ATOMIC,                  "ATOMIC" }, \
+       { IOCB_DONTCACHE,               "DONTCACHE" }, \
+       { IOCB_EVENTFD,                 "EVENTFD"}, \
+       { IOCB_DIRECT,                  "DIRECT" }, \
+       { IOCB_WRITE,                   "WRITE" }, \
+       { IOCB_WAITQ,                   "WAITQ" }, \
+       { IOCB_NOIO,                    "NOIO" }, \
+       { IOCB_ALLOC_CACHE,             "ALLOC_CACHE" }, \
+       { IOCB_DIO_CALLER_COMP,         "CALLER_COMP" }, \
+       { IOCB_AIO_RW,                  "AIO_RW" }, \
+       { IOCB_HAS_METADATA,            "AIO_HAS_METADATA" }, \
+       { IOCB_MAY_USE_METADATA,        "AIO_MAY_USE_METADATA" }

 struct kiocb {
        struct file             *ki_filp;
@@ -3786,6 +3785,10 @@ static inline bool vma_is_fsdax(struct vm_area_struct *vma)
 static inline int iocb_flags(struct file *file)
 {
        int res = 0;
+
+       /* Retain flags that the kernel raises internally. */
+       res |= (file->f_iocb_flags & (IOCB_HAS_METADATA | IOCB_MAY_USE_METADATA));
+
        if (file->f_flags & O_APPEND)
                res |= IOCB_APPEND;
        if (file->f_flags & O_DIRECT)
diff --git a/io_uring/rw.c b/io_uring/rw.c
index af5a54b5db12..23e9103c62d4 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -886,7 +886,7 @@ static int io_rw_init_file(struct io_kiocb *req, fmode_t mode, int rw_type)
        if (req->flags & REQ_F_HAS_METADATA) {
                struct io_async_rw *io = req->async_data;

-               if (!(file->f_mode & FMODE_HAS_METADATA))
+               if (!(file->f_iocb_flags & IOCB_MAY_USE_METADATA))
                        return -EINVAL;

                /*

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

[Christoph Hellwig]

On Wed, Aug 20, 2025 at 11:40:36AM +0200, Christian Brauner wrote:
> I meant something like this which should effectively be the same thing
> just that we move the burden of having to use two bits completely into
> file->f_iocb_flags instead of wasting a file->f_mode bit:

Yeah, that could work.  But I think the double use of f_iocb_flags is
a bit confusing.  Another option at least for this case would be to
have a FOP_ flag, and then check inside the operation if it is supported
for this particular instance.

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

[Christian Brauner]

On Thu, Aug 21, 2025 at 10:42:13AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 20, 2025 at 11:40:36AM +0200, Christian Brauner wrote:
> > I meant something like this which should effectively be the same thing
> > just that we move the burden of having to use two bits completely into
> > file->f_iocb_flags instead of wasting a file->f_mode bit:
> 
> Yeah, that could work.  But I think the double use of f_iocb_flags is
> a bit confusing.  Another option at least for this case would be to
> have a FOP_ flag, and then check inside the operation if it is supported
> for this particular instance.

Do you want to try something like that? Maybe we can do this for other
FMODE_*-based IOCB_* opt{in,outs}?

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

[Christoph Hellwig]

On Mon, Aug 25, 2025 at 02:01:07PM +0200, Christian Brauner wrote:
> On Thu, Aug 21, 2025 at 10:42:13AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 20, 2025 at 11:40:36AM +0200, Christian Brauner wrote:
> > > I meant something like this which should effectively be the same thing
> > > just that we move the burden of having to use two bits completely into
> > > file->f_iocb_flags instead of wasting a file->f_mode bit:
> > 
> > Yeah, that could work.  But I think the double use of f_iocb_flags is
> > a bit confusing.  Another option at least for this case would be to
> > have a FOP_ flag, and then check inside the operation if it is supported
> > for this particular instance.
> 
> Do you want to try something like that? Maybe we can do this for other
> FMODE_*-based IOCB_* opt{in,outs}?

Yes, I also need to move on of the FOP_ flags to a scheme like that.
However I'm pretty busy at the momen, so I'm unlikely to get to it
before mid-September.