usb_kill_urb(9)
π
usb_kill_urb β kernel API manual, bestie edition
okay so you know usb_kill_urb(9)? that's the one. this is the kernel API manual page for it, and we're gonna get through it together, no cap π«Ά
β¨ NAME β¨
usb_kill_urb β cancel a transfer request and wait for it to finish πβ³
yeah. it cancels. and it waits. both. it does the most, honestly.
πΈ SYNOPSIS πΈ
void usb_kill_urb (struct urb *urb );
that's it. that's the whole signature. void, so nothing comes back to you β she's not returning anything, she's just done when she's done. π
π¦ ARGUMENTS π¦
urbβ pointer to a URB describing a previously submitted request, and yes it may beNULL. your girl is allowed to be aNULLpointer, she contains multitudes π
π DESCRIPTION π
okay so here's the tea β β this routine cancels an in-progress request. and it is guaranteed that upon return, all completion handlers will have finished and the URB will be totally idle and available for reuse. like, fully rested, skin clear, ready to go again β¨
these features make this an ideal way to stop I/O in a disconnect callback or close function. it's literally giving "responsible friend who makes sure everyone gets home safe" energy π«Ά
if the request has not already finished or been unlinked, the completion handler will see urb->status == -ENOENT. so heads up, your handler's gonna get that value and be like "oh π" β that's expected, that's correct.
while the routine is running, attempts to resubmit the URB will fail with error -EPERM. so even if the URB's completion handler always tries to resubmit (we all know that one handler), it will not succeed and the URB will become idle. the routine said "sit down." and it sat down π
π¨ big one, bestie, do not skip: the URB must not be deallocated while this routine is running. in particular, when a driver calls this routine, it must insure that the completion handler cannot deallocate the URB. like, that's a real rule, not a vibe, fr fr π
β οΈ this routine may not be used in an interrupt context (such as a bottom half or a completion handler), or when holding a spinlock, or in other situations where the caller can't schedule. if you can't schedule, you can't be here. that's the whole thing. periodt.
π and this routine should not be called by a driver after its disconnect method has returned. after that, it's over, it's giving "the party ended an hour ago," go home π
π SEE ALSO π
kernel file ./drivers/usb/core/urb.c β that's the main character source file, go read it π§
and the whole friend group:
usb_init_urb(9)usb_alloc_urb(9)usb_free_urb(9)usb_get_urb(9)usb_anchor_urb(9)usb_unanchor_urb(9)usb_pipe_type_check(9)usb_urb_ep_type_check(9)usb_submit_urb(9)usb_unlink_urb(9)usb_poison_urb(9)usb_block_urb(9)usb_kill_anchored_urbs(9)usb_poison_anchored_urbs(9)usb_unpoison_anchored_urbs(9)usb_anchor_suspend_wakeups(9)usb_anchor_resume_wakeups(9)usb_wait_anchor_empty_timeout(9)usb_get_from_anchor(9)usb_scuttle_anchored_urbs(9)usb_anchor_empty(9)
they're all icons, they all ate π₯
π sign-off π
this masterpiece lives in ./drivers/usb/core, dated October 2026, and it's part of the Kernel API Manual. ngl, a whole manual page about waiting for your URB to finish? highkey iconic. go forth and kill your URBs responsibly, bestie ππβ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms