Re: Handling incoming ZLP in cdc-wdm

[Oliver Neukum <oneukum@suse.com>]

On 02.04.25 17:01, Robert Hodaszi wrote:

> 
> But we cannot return with -EAGAIN. If we do that, we're back to sqrt(1), and get stuck again.

Then we have a problem. If we are servicing a read() syscall,
we have to either return data, or, if we cannot do that
we either sleep or return -EAGAIN depending on O_NONBLOCK.

There is nothing we can do about that. This makes me think
that the issue here is poll() rather than in wdm_read()

> So what about modifying the service_interrupt_work to no simply set WDM_READ if resp_count is 0, but instead to check if there's any real message in the buffer, to not confuse consumers. Something like this:

That specific proposal will not work because the issue
is in service_interrupt_work() which can already be scheduled.
We cannot prevent that.

>     diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
>     index 37873acd18f4..9037379f3603 100644
>     --- a/drivers/usb/class/cdc-wdm.c
>     +++ b/drivers/usb/class/cdc-wdm.c
>     @@ -1010,7 +1010,7 @@ static void service_interrupt_work(struct
>     work_struct *work)
> 
>              spin_lock_irq(&desc->iuspin);
>              service_outstanding_interrupt(desc);
>     -       if (!desc->resp_count) {
>     +       if (!desc->resp_count && (desc->length || desc->rerr)) {
>                      set_bit(WDM_READ, &desc->flags);
>                      wake_up(&desc->wait);

And what happens if wdm_read() wakes up because a signal is delivered?

	Regards
		Oliver