[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2728922.1674126412@warthog.procyon.org.uk>
Date: Thu, 19 Jan 2023 11:06:52 +0000
From: David Howells <dhowells@...hat.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: dhowells@...hat.com, 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()
Al Viro <viro@...iv.linux.org.uk> wrote:
> ->write_iter() <- nvmet_file_submit_bvec()
> ->write_iter() <- call_write_iter() <- lo_rw_aio()
Could call init_kiocb() in lo_rw_aio() and then just overwrite ki_ioprio.
> ->write_iter() <- call_write_iter() <- fd_execute_rw_aio()
fd_execute_rw_aio() perhaps should call init_kiocb() since the struct is
allocated with kmalloc() and not fully initialised.
> ->write_iter() <- call_write_iter() <- vfs_iocb_iter_write()
>
> The last 4 neither set KIOCB_WRITE nor call init_sync_kiocb().
vfs_iocb_iter_write() is given an initialised kiocb. It should not be calling
init_sync_kiocb() itself.
It's called from two places: cachefiles, which initialises the kiocb itself
and sets IOCB_WRITE, and overlayfs, which gets the kiocb from the VFS via its
->write_iter hook the caller of which should have already set IOCB_WRITE.
cachefiles should be using init_kiocb() - though since it used kzalloc,
init_kiocb() clearing the struct is redundant.
> What's more, there are places that call instances (or their guts - look at
> btrfs_do_write_iter() callers) directly...
At least in the case of btrfs_ioctl_encoded_write(), that can call
init_kiocb(). But as you say, there are more to be found.
David
Powered by blists - more mailing lists