Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
