iomap: fix WARN_ON_ONCE() from unprivileged users
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by unprivileged users which would taint the kernel, or worse - panic if panic_on_warn or panic_on_taint is set. Hence, just convert it to pr_warn_ratelimited() to let users know their workloads are racing. Thank Dave Chinner for the initial analysis of the racing reproducers. Signed-off-by: Qian Cai <cai@lca.pw> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
This commit is contained in:
parent
f4d51dffc6
commit
a805c11165
|
@ -388,6 +388,16 @@ iomap_dio_actor(struct inode *inode, loff_t pos, loff_t length,
|
|||
return iomap_dio_bio_actor(inode, pos, length, dio, iomap);
|
||||
case IOMAP_INLINE:
|
||||
return iomap_dio_inline_actor(inode, pos, length, dio, iomap);
|
||||
case IOMAP_DELALLOC:
|
||||
/*
|
||||
* DIO is not serialised against mmap() access at all, and so
|
||||
* if the page_mkwrite occurs between the writeback and the
|
||||
* iomap_apply() call in the DIO path, then it will see the
|
||||
* DELALLOC block that the page-mkwrite allocated.
|
||||
*/
|
||||
pr_warn_ratelimited("Direct I/O collision with buffered writes! File: %pD4 Comm: %.20s\n",
|
||||
dio->iocb->ki_filp, current->comm);
|
||||
return -EIO;
|
||||
default:
|
||||
WARN_ON_ONCE(1);
|
||||
return -EIO;
|
||||
|
|
Loading…
Reference in New Issue