| From | David Howells <> | Subject | Re: [PATCH v6 01/34] vfs: Unconditionally set IOCB_WRITE in call_write_iter() | Date | Thu, 19 Jan 2023 11:06:52 +0000 |
| |
Al Viro <viro@zeniv.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
|