On Wed, Jan 25, 2023 at 01:05:55PM -0700, Jens Axboe wrote:
> On 1/25/23 12:50?PM, Harris, James R wrote:
> > Hi,
> >
> > I can reliably hit a kernel oops with ublk_drv using the following abnormal sequence of events (repro .c file at end of this e-mail):
> >
> > 1) modprobe ublk_drv
> > 2) run test app which basically does:
> > a) submit UBLK_CMD_ADD_DEV
> > b) submit UBLK_CMD_SET_PARAMS
> > c) wait for completions
> > d) do *not* submit UBLK_CMD_START_DEV
> > e) exit
> > 3) rmmod ublk_drv
> >
> > Reproduces on 6.2-rc5, 6.1.5 and 6.1.
>
> Something like this may do it, but I'll let Ming sort out the details
> on what's the most appropriate fix.
Hi Jens and James,
The ublk char device still needs to be deleted even though START_DEV
isn't called given the char device is added in ADD_DEV's handler, so
the current logic is correct.
The root cause is that 'ublk_chr_class' is destroyed too early, so
the following patch should fix the issue.
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 17b677b5d3b2..e54693204630 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -2092,13 +2092,12 @@ static void __exit ublk_exit(void)
struct ublk_device *ub;
int id;
- class_destroy(ublk_chr_class);
-
- misc_deregister(&ublk_misc);
-
idr_for_each_entry(&ublk_index_idr, ub, id)
ublk_remove(ub);
+ class_destroy(ublk_chr_class);
+ misc_deregister(&ublk_misc);
+
idr_destroy(&ublk_index_idr);
unregister_chrdev_region(ublk_chr_devt, UBLK_MINORS);
}
Thanks,
Ming
