| Message ID | 20190821101201.5377-1-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | usb: gadget: udc: core: Fix error case while binding pending gadget drivers | expand |
On Wed, 21 Aug 2019, Roger Quadros wrote: > If binding a pending gadget driver fails we should not > remove it from the pending driver list, otherwise it > will cause a segmentation fault later when the gadget driver is > unloaded. > Signed-off-by: Roger Quadros <rogerq@ti.com> > --- > drivers/usb/gadget/udc/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c > index 7cf34beb50df..c272c8014772 100644 > --- a/drivers/usb/gadget/udc/core.c > +++ b/drivers/usb/gadget/udc/core.c > @@ -1142,7 +1142,7 @@ static int check_pending_gadget_drivers(struct usb_udc *udc) > if (!driver->udc_name || strcmp(driver->udc_name, > dev_name(&udc->dev)) == 0) { > ret = udc_bind_to_driver(udc, driver); > - if (ret != -EPROBE_DEFER) > + if (!ret) > list_del(&driver->pending); > break; > } This is kind of a policy question. If binding a pending gadget driver fails, should the driver remain pending? Depending on the answer to this question, you might want to change the list_del to list_del_init. That should fix the segmentation fault just as well. Alan Stern
On 21/08/2019 17:30, Alan Stern wrote: > On Wed, 21 Aug 2019, Roger Quadros wrote: > >> If binding a pending gadget driver fails we should not >> remove it from the pending driver list, otherwise it >> will cause a segmentation fault later when the gadget driver is >> unloaded. > >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> --- >> drivers/usb/gadget/udc/core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c >> index 7cf34beb50df..c272c8014772 100644 >> --- a/drivers/usb/gadget/udc/core.c >> +++ b/drivers/usb/gadget/udc/core.c >> @@ -1142,7 +1142,7 @@ static int check_pending_gadget_drivers(struct usb_udc *udc) >> if (!driver->udc_name || strcmp(driver->udc_name, >> dev_name(&udc->dev)) == 0) { >> ret = udc_bind_to_driver(udc, driver); >> - if (ret != -EPROBE_DEFER) >> + if (!ret) >> list_del(&driver->pending); >> break; >> } > > This is kind of a policy question. If binding a pending gadget driver > fails, should the driver remain pending? > > Depending on the answer to this question, you might want to change the > list_del to list_del_init. That should fix the segmentation fault > just as well. OK. I'll send a revised patch to retain existing policy. cheers, -roger
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index 7cf34beb50df..c272c8014772 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -1142,7 +1142,7 @@ static int check_pending_gadget_drivers(struct usb_udc *udc) if (!driver->udc_name || strcmp(driver->udc_name, dev_name(&udc->dev)) == 0) { ret = udc_bind_to_driver(udc, driver); - if (ret != -EPROBE_DEFER) + if (!ret) list_del(&driver->pending); break; }
If binding a pending gadget driver fails we should not remove it from the pending driver list, otherwise it will cause a segmentation fault later when the gadget driver is unloaded. Test case: - Make sure no UDC is available - modprobe g_mass_storage file=wrongfile - Load UDC driver so it becomes available lun0: unable to open backing file: wrongfile - modprobe -r g_mass_storage [ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108 [ 60.908346] Mem abort info: [ 60.911145] ESR = 0x96000044 [ 60.914227] Exception class = DABT (current EL), IL = 32 bits [ 60.920162] SET = 0, FnV = 0 [ 60.923217] EA = 0, S1PTW = 0 [ 60.926354] Data abort info: [ 60.929228] ISV = 0, ISS = 0x00000044 [ 60.933058] CM = 0, WnR = 1 [ 60.936011] [dead000000000108] address between user and kernel address ranges [ 60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6 [ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69) [ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 #92 [ 61.008658] Hardware name: Texas Instruments SoC (DT) [ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO) [ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core] [ 61.031750] sp : ffff00001338fda0 [ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000 [ 61.040346] x27: 0000000000000000 x26: 0000000000000000 [ 61.045642] x25: 0000000056000000 x24: 0000000000000800 [ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8 [ 61.056234] x21: ffff000001100000 x20: ffff000002020260 [ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000 [ 61.066825] x17: 0000000000000000 x16: 0000000000000000 [ 61.072121] x15: 0000000000000000 x14: 0000000000000000 [ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff [ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f [ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000 [ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff [ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000 [ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000 [ 61.109190] x1 : dead000000000100 x0 : dead000000000200 [ 61.114486] Call trace: [ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite] [ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage] [ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0 [ 61.138458] el0_svc_common+0x90/0x158 [ 61.142192] el0_svc_handler+0x2c/0x80 [ 61.145926] el0_svc+0x8/0xc [ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420) [ 61.154869] ---[ end trace afb22e9b637bd9a7 ]--- Segmentation fault Signed-off-by: Roger Quadros <rogerq@ti.com> --- drivers/usb/gadget/udc/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)