On Sat, Oct 29, 2016 at 10:47:58AM -0700, Linus Torvalds wrote:
> Also, honestly, make it use a helper: "aio_file_start_write()" and
> "aio_file_end_write()" that has the comments and the lockdep games.
>
> Because that patch is just too effing ugly.
>
> Does something like the attached work for you guys?
No. The use-after-free problem is real, nasty and only papered over by
that patch.
What happens is that io_submit_one()
* allocates aio_kiocb
* does fget() and stuffs the struct file * into kiocb
* in case of early problems we call kiocb_free(), freeing kiocb and
doing fput() on file, then bugger off.
* otherwise, eventually we get to passing that iocb to
->read_iter()/->write_iter().
* if that has resulted in anything other than -EIOCBQUEUED, we
call aio_complete(), which calls kiocb_free(), freeing kiocb and doing fput()
on file.
* if ->{read,write}_iter() returns -EIOCBQUEUED, we expect
aio_complete() to be called asynchronously.
And that call can happen as soon as we return from __blockdev_direct_IO()
(even earlier, actually). As soon as that happens, the reference to
struct file we'd acquired in io_submit_one() is dropped. If descriptor
table had been shared, another thread might have already closed that sucker,
and fput() from aio_complete() would free struct file.
That's what this patch is papering over. Because if we hit that scenario
and struct file *does* get closed asynchronously just as our ->write_iter()
is returning from __blockdev_direct_IO(), we are fucked. Not only struct
file might be freed - struct inode might've been gone too. And a bunch
of ->write_iter/->read_iter instances do access struct inode after the call
of __blockdev_direct_IO(). file_write_end() is just the tip of the iceberg -
see examples I've posted today for the things we *can't* move around.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
