[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8ZTyx7vM8NpnUAj@infradead.org>
Date: Mon, 16 Jan 2023 23:52:43 -0800
From: Christoph Hellwig <hch@...radead.org>
To: David Howells <dhowells@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@....de>,
Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
Jeff Layton <jlayton@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 01/34] vfs: Unconditionally set IOCB_WRITE in
call_write_iter()
On Mon, Jan 16, 2023 at 11:08:09PM +0000, David Howells wrote:
> IOCB_WRITE is set by aio, io_uring and cachefiles before submitting a write
> operation to the VFS, but it isn't set by, say, the write() system call.
>
> Fix this by setting IOCB_WRITE unconditionally in call_write_iter().
>
> This will allow drivers to use IOCB_WRITE instead of the iterator data
> source to determine the I/O direction.
>
> Signed-off-by: David Howells <dhowells@...hat.com>
> cc: Alexander Viro <viro@...iv.linux.org.uk>
> cc: Christoph Hellwig <hch@....de>
> cc: Jens Axboe <axboe@...nel.dk>
> cc: linux-block@...r.kernel.org
> cc: linux-fsdevel@...r.kernel.org
> ---
>
> include/linux/fs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 066555ad1bf8..649ff061440e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2183,6 +2183,7 @@ static inline ssize_t call_read_iter(struct file *file, struct kiocb *kio,
> static inline ssize_t call_write_iter(struct file *file, struct kiocb *kio,
> struct iov_iter *iter)
> {
> + kio->ki_flags |= IOCB_WRITE;
> return file->f_op->write_iter(kio, iter);
> }
This doesn't remove the existing setting of IOCB_WRITE, and also
feelds like the wrong place.
I suspect the best is to:
- rename init_sync_kiocb to init_kiocb
- pass a new argument for the destination to it. I'm not entirely
sure if flags is a good thing, or an explicit READ/WRITE might be
better because it's harder to get wrong, even if a the compiler
might generate worth code for it.
- also use it in the async callers (io_uring, aio, overlayfs, loop,
nvmet, target, cachefs, file backed swap)
Powered by blists - more mailing lists