Re: [PATCH REPOST] usb: udc: Make tracing aware that usb_ep_alloc_request() can return NULL

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

- Felipe (bounce)

On 2026-10-12 13:26:18 [+0200], Greg KH wrote:
> On Mon, Oct 12, 2026 at 11:49:11AM +0200, Sebastian Andrzej Siewior wrote:
> > The alloc_request callback of the EP can return NULL if it was not able
> > to allocate a request. This NULL pointer will then be dereferenced by
> > tracing in order to show details about it.
> 
> When does that happen?

In usb_ep_alloc_request() when ep->ops->alloc_request() return NULL.

> > Let tracing check the req pointer and if NULL just write 0.
> 
> Why not fix up the calling point and if req is NULL, not call the
> tracepoint as odds are something went really wrong at that point in
> time, right?

usb_ep_alloc_request() uses it as:
	trace_usb_ep_alloc_request(ep, req, req ? 0 : -ENOMEM);

so if the allocations fails the entry in the trace buffer will be 
"EPNAME: req NULL … --> -12" aka ENOMEM.
If that trace point is skipped then we have nothing.

Now sashiko pointed out that in usb_ep_queue() that request can be
completed immediately (instead queueing it) and then
usb_gadget_giveback_request() could release it before the tracepoint is
using `req'.

"Immediate" completion could happen for ep0 handling/
composite_setup_complete() but this does not do it. 
loopback_complete() does free `req' for error case (such as
-ECONNABORTED) but this should not happen on enqueue. And if it does,
that memory is still mapped but maybe with bogus content.

This makes me think that it would be better to have copy of `req' on
stack for the tracing case.

> thanks,
> 
> greg k-h

Sebastian