kernel/linux.git/drivers/block/loop.h, branch v4.14.263

Revert "block/loop: Use global lock for ioctl() operation."

2019-05-02T07:40:33+00:00

This reverts commit 57da9a9742200f391d1cf93fea389f7ddc25ec9a which is commit 310ca162d779efee8a2dc3731439680f3e9c1e86 upstream. Jan Kara has reported seeing problems with this patch applied, as has Salvatore Bonaccorso, so let's drop it for now. Reported-by: Salvatore Bonaccorso Reported-by: Jan Kara Cc: Tetsuo Handa Cc: Jens Axboe Signed-off-by: Greg Kroah-Hartman

block/loop: Use global lock for ioctl() operation.

2019-01-23T07:09:51+00:00

commit 310ca162d779efee8a2dc3731439680f3e9c1e86 upstream. syzbot is reporting NULL pointer dereference [1] which is caused by race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other loop devices at loop_validate_file() without holding corresponding lo->lo_ctl_mutex locks. Since ioctl() request on loop devices is not frequent operation, we don't need fine grained locking. Let's use global lock in order to allow safe traversal at loop_validate_file(). Note that syzbot is also reporting circular locking dependency between bdev->bd_mutex and lo->lo_ctl_mutex [2] which is caused by calling blkdev_reread_part() with lock held. This patch does not address it. [1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3 [2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889 Signed-off-by: Tetsuo Handa Reported-by: syzbot Reviewed-by: Jan Kara Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

loop: remember whether sysfs_create_group() was done

2018-07-17T09:39:33+00:00

commit d3349b6b3c373ac1fbfb040b810fcee5e2adc7e0 upstream. syzbot is hitting WARN() triggered by memory allocation fault injection [1] because loop module is calling sysfs_remove_group() when sysfs_create_group() failed. Fix this by remembering whether sysfs_create_group() succeeded. [1] https://syzkaller.appspot.com/bug?id=3f86c0edf75c86d2633aeb9dd69eccc70bc7e90b Signed-off-by: Tetsuo Handa Reported-by: syzbot Reviewed-by: Greg Kroah-Hartman Renamed sysfs_ready -> sysfs_inited. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

loop: remove union of use_aio and ref in struct loop_cmd

2017-09-25T14:56:05+00:00

When the request is completed, lo_complete_rq() checks cmd->use_aio. However, if this is in fact an aio request, cmd->use_aio will have already been reused as cmd->ref by lo_rw_aio*. Fix it by not using a union. On x86_64, there's a hole after the union anyways, so this doesn't make struct loop_cmd any bigger. Fixes: 92d773324b7e ("block/loop: fix use after free") Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe

block/loop: remove unused field

2017-09-01T19:57:35+00:00

nobody uses the list. Signed-off-by: Shaohua Li Signed-off-by: Jens Axboe

block/loop: fix use after free

2017-09-01T19:57:33+00:00

lo_rw_aio->call_read_iter-> 1 aops->direct_IO 2 iov_iter_revert lo_rw_aio_complete could happen between 1 and 2, the bio and bvec could be freed before 2, which accesses bvec. Signed-off-by: Shaohua Li Signed-off-by: Jens Axboe

block/loop: allow request merge for directio mode

2017-09-01T14:44:34+00:00

Currently loop disables merge. While it makes sense for buffer IO mode, directio mode can benefit from request merge. Without merge, loop could send small size IO to underlayer disk and harm performance. Reviewed-by: Omar Sandoval Signed-off-by: Shaohua Li Signed-off-by: Jens Axboe

loop: get rid of lo_blocksize

2017-08-31T19:51:10+00:00

This is only used for setting the soft block size on the struct block_device once and then never used again. Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe

Revert "loop: support 4k physical blocksize"

2017-08-23T21:57:55+00:00

There's some stuff still up in the air, let's not get stuck with a subpar ABI. I'll follow up with something better for 4.14. Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe

loop: support 4k physical blocksize

2017-06-08T14:40:00+00:00

When generating bootable VM images certain systems (most notably s390x) require devices with 4k blocksize. This patch implements a new flag 'LO_FLAGS_BLOCKSIZE' which will set the physical blocksize to that of the underlying device, and allow to change the logical blocksize for up to the physical blocksize. Signed-off-by: Hannes Reinecke Signed-off-by: Jens Axboe