When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock.
Fix it by using tasklet_hi_schedule() to schedule the inner f_midi_transmit() via a tasklet from the completion handler.
Link: https://lore.kernel.org/all/CAArt=LjxU0fUZOj06X+5tkeGT+6RbXzpWg1h4t4Fwa_KGVA... Fixes: d5daf49b58661 ("USB: gadget: midi: add midi function driver") Cc: stable@vger.kernel.org Signed-off-by: Jill Donahue jilliandonahue58@gmail.com --- drivers/usb/gadget/function/f_midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c index 837fcdfa3840..37d438e5d451 100644 --- a/drivers/usb/gadget/function/f_midi.c +++ b/drivers/usb/gadget/function/f_midi.c @@ -283,7 +283,7 @@ f_midi_complete(struct usb_ep *ep, struct usb_request *req) /* Our transmit completed. See if there's more to go. * f_midi_transmit eats req, don't queue it again. */ req->length = 0; - f_midi_transmit(midi); + tasklet_hi_schedule(&midi->tasklet); return; } break;
On Fri, Feb 07, 2025 at 01:34:41PM -0700, Jill Donahue wrote:
When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock.
Fix it by using tasklet_hi_schedule() to schedule the inner f_midi_transmit() via a tasklet from the completion handler.
Link: https://lore.kernel.org/all/CAArt=LjxU0fUZOj06X+5tkeGT+6RbXzpWg1h4t4Fwa_KGVA... Fixes: d5daf49b58661 ("USB: gadget: midi: add midi function driver") Cc: stable@vger.kernel.org Signed-off-by: Jill Donahue jilliandonahue58@gmail.com
drivers/usb/gadget/function/f_midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c index 837fcdfa3840..37d438e5d451 100644 --- a/drivers/usb/gadget/function/f_midi.c +++ b/drivers/usb/gadget/function/f_midi.c @@ -283,7 +283,7 @@ f_midi_complete(struct usb_ep *ep, struct usb_request *req) /* Our transmit completed. See if there's more to go. * f_midi_transmit eats req, don't queue it again. */ req->length = 0;
f_midi_transmit(midi);
tasklet_hi_schedule(&midi->tasklet); return;-- 2.25.1
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree.
You are receiving this message because of the following common error(s) as indicated below:
- This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/process/submitting-patches.rst for what needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers.
thanks,
greg k-h's patch email bot
Hi Jill,
kernel test robot noticed the following build errors:
[auto build test ERROR on usb/usb-testing] [also build test ERROR on usb/usb-next usb/usb-linus westeri-thunderbolt/next linus/master v6.14-rc1 next-20250207] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jill-Donahue/f_midi_complete-... base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing patch link: https://lore.kernel.org/r/20250207203441.945196-1-jilliandonahue58%40gmail.c... patch subject: [PATCH v3] f_midi_complete to call tasklet_hi_schedule config: i386-buildonly-randconfig-003-20250208 (https://download.01.org/0day-ci/archive/20250208/202502081928.T2cRhulq-lkp@i...) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250208/202502081928.T2cRhulq-lkp@i...)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot lkp@intel.com | Closes: https://lore.kernel.org/oe-kbuild-all/202502081928.T2cRhulq-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/usb/gadget/function/f_midi.c: In function 'f_midi_complete':
drivers/usb/gadget/function/f_midi.c:286:50: error: 'struct f_midi' has no member named 'tasklet'
286 | tasklet_hi_schedule(&midi->tasklet); | ^~
vim +286 drivers/usb/gadget/function/f_midi.c
269 270 static void 271 f_midi_complete(struct usb_ep *ep, struct usb_request *req) 272 { 273 struct f_midi *midi = ep->driver_data; 274 struct usb_composite_dev *cdev = midi->func.config->cdev; 275 int status = req->status; 276 277 switch (status) { 278 case 0: /* normal completion */ 279 if (ep == midi->out_ep) { 280 /* We received stuff. req is queued again, below */ 281 f_midi_handle_out_data(ep, req); 282 } else if (ep == midi->in_ep) { 283 /* Our transmit completed. See if there's more to go. 284 * f_midi_transmit eats req, don't queue it again. */ 285 req->length = 0;
286 tasklet_hi_schedule(&midi->tasklet);
287 return; 288 } 289 break; 290 291 /* this endpoint is normally active while we're configured */ 292 case -ECONNABORTED: /* hardware forced ep reset */ 293 case -ECONNRESET: /* request dequeued */ 294 case -ESHUTDOWN: /* disconnect from host */ 295 VDBG(cdev, "%s gone (%d), %d/%d\n", ep->name, status, 296 req->actual, req->length); 297 if (ep == midi->out_ep) { 298 f_midi_handle_out_data(ep, req); 299 /* We don't need to free IN requests because it's handled 300 * by the midi->in_req_fifo. */ 301 free_ep_req(ep, req); 302 } 303 return; 304 305 case -EOVERFLOW: /* buffer overrun on read means that 306 * we didn't provide a big enough buffer. 307 */ 308 default: 309 DBG(cdev, "%s complete --> %d, %d/%d\n", ep->name, 310 status, req->actual, req->length); 311 break; 312 case -EREMOTEIO: /* short read */ 313 break; 314 } 315 316 status = usb_ep_queue(ep, req, GFP_ATOMIC); 317 if (status) { 318 ERROR(cdev, "kill %s: resubmit %d bytes --> %d\n", 319 ep->name, req->length, status); 320 usb_ep_set_halt(ep); 321 /* FIXME recover later ... somehow */ 322 } 323 } 324
Hi Jill,
kernel test robot noticed the following build errors:
[auto build test ERROR on usb/usb-testing] [also build test ERROR on usb/usb-next usb/usb-linus westeri-thunderbolt/next linus/master v6.14-rc1 next-20250207] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jill-Donahue/f_midi_complete-... base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing patch link: https://lore.kernel.org/r/20250207203441.945196-1-jilliandonahue58%40gmail.c... patch subject: [PATCH v3] f_midi_complete to call tasklet_hi_schedule config: arm-randconfig-002-20250208 (https://download.01.org/0day-ci/archive/20250208/202502082022.ILQXjseT-lkp@i...) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250208/202502082022.ILQXjseT-lkp@i...)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot lkp@intel.com | Closes: https://lore.kernel.org/oe-kbuild-all/202502082022.ILQXjseT-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/usb/gadget/function/f_midi.c:286:31: error: no member named 'tasklet' in 'struct f_midi'
286 | tasklet_hi_schedule(&midi->tasklet); | ~~~~ ^ 1 error generated.
vim +286 drivers/usb/gadget/function/f_midi.c
269 270 static void 271 f_midi_complete(struct usb_ep *ep, struct usb_request *req) 272 { 273 struct f_midi *midi = ep->driver_data; 274 struct usb_composite_dev *cdev = midi->func.config->cdev; 275 int status = req->status; 276 277 switch (status) { 278 case 0: /* normal completion */ 279 if (ep == midi->out_ep) { 280 /* We received stuff. req is queued again, below */ 281 f_midi_handle_out_data(ep, req); 282 } else if (ep == midi->in_ep) { 283 /* Our transmit completed. See if there's more to go. 284 * f_midi_transmit eats req, don't queue it again. */ 285 req->length = 0;
286 tasklet_hi_schedule(&midi->tasklet);
287 return; 288 } 289 break; 290 291 /* this endpoint is normally active while we're configured */ 292 case -ECONNABORTED: /* hardware forced ep reset */ 293 case -ECONNRESET: /* request dequeued */ 294 case -ESHUTDOWN: /* disconnect from host */ 295 VDBG(cdev, "%s gone (%d), %d/%d\n", ep->name, status, 296 req->actual, req->length); 297 if (ep == midi->out_ep) { 298 f_midi_handle_out_data(ep, req); 299 /* We don't need to free IN requests because it's handled 300 * by the midi->in_req_fifo. */ 301 free_ep_req(ep, req); 302 } 303 return; 304 305 case -EOVERFLOW: /* buffer overrun on read means that 306 * we didn't provide a big enough buffer. 307 */ 308 default: 309 DBG(cdev, "%s complete --> %d, %d/%d\n", ep->name, 310 status, req->actual, req->length); 311 break; 312 case -EREMOTEIO: /* short read */ 313 break; 314 } 315 316 status = usb_ep_queue(ep, req, GFP_ATOMIC); 317 if (status) { 318 ERROR(cdev, "kill %s: resubmit %d bytes --> %d\n", 319 ep->name, req->length, status); 320 usb_ep_set_halt(ep); 321 /* FIXME recover later ... somehow */ 322 } 323 } 324
Ah yea, this error happens because in this commit: https://github.com/torvalds/linux/commit/8653d71ce3763aedcf3d2331f59beda3fec... the tasklets are replaced with works. Should I request the patch to be in v5.10 or should I update the fix to use queue_work(system_highpri_wq, &midi->work) ?
drivers/usb/gadget/function/f_midi.c:286:31: error: no member named 'tasklet' in 'struct f_midi'
286 | tasklet_hi_schedule(&midi->tasklet); | ~~~~ ^1 error generated.
Jill
On Mon, Feb 10, 2025 at 10:18:13AM -0700, Jillian Donahue wrote:
Ah yea, this error happens because in this commit: https://github.com/torvalds/linux/commit/8653d71ce3763aedcf3d2331f59beda3fec... the tasklets are replaced with works. Should I request the patch to be in v5.10 or should I update the fix to use queue_work(system_highpri_wq, &midi->work) ?
drivers/usb/gadget/function/f_midi.c:286:31: error: no member named 'tasklet' in 'struct f_midi'
286 | tasklet_hi_schedule(&midi->tasklet); | ~~~~ ^1 error generated.
Always submit your changes based on the latest kernel tree (ideally the latest development tree). Any older kernel backports can happen after they end up in a release.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Jill Donahue -
Jillian Donahue
-
kernel test robot