loop: Fix oops and possible deadlocks
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest16 patches 5 repliesIn review
- v215 patches 8 repliesSuperseded
- v114 patches 2 repliesSuperseded
Changes in v3 from the cover letter
* Rebase on top of 4.20-rc1
* Add patch to stop fooling lockdep about loop_ctl_mutex
Patches in v3 No applies recorded yet
Reviews trailers per patch
2 of 16 patches have a Reviewed-by or Acked-by.
| Patch | Jan Kara |
|---|---|
| 1/16 | R-b |
| 2/16 | R-b |
| 3/16 | |
| 4/16 | |
| 5/16 | |
| 6/16 | |
| 7/16 | |
| 8/16 | |
| 9/16 | |
| 10/16 | |
| 11/16 | |
| 12/16 | |
| 13/16 | |
| 14/16 | |
| 15/16 | |
| 16/16 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/16 v3] loop: Fix oops and possible deadlocks
Hi,
this patch series fixes oops and possible deadlocks as reported by syzbot [1] [2]. The second patch in the series (from Tetsuo) fixes the oops, the remaining patches are cleaning up the locking in the loop driver so that we can in the end reasonably easily switch to rereading partitions without holding mutex protecting the loop device.
I have tested the patches by creating, deleting, modifying loop devices, and by running loop blktests (as well as creating new ones with the load syzkaller has used to detect the problem). Review is welcome but I think the patches are fine to go as far as I'm concerned! Jens, can you please pick them up?
Changes since v1:
* Added patch moving fput() calls in loop_change_fd() from under loop_ctl_mutex
* Fixed bug in loop_control_ioctl() where it failed to return error properly
Changes since v2:
* Rebase on top of 4.20-rc1
* Add patch to stop fooling lockdep about loop_ctl_mutex
Honza
[1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3
[2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889