[PATCH] usb: translate ENOSPC for user space

[PATCH] usb: translate ENOSPC for user space

[Oliver Neukum]

In case of insufficient bandwidth usb_submit_urb()
returns -ENOSPC. Translating this to -EIO is not
optimal. There are insufficient resources not
an error. EBUSY is a better fit.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 include/linux/usb.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/usb.h b/include/linux/usb.h
index 04277af4bb9d..815f2212936e 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -2075,6 +2075,8 @@ static inline int usb_translate_errors(int error_code)
 	case -ENODEV:
 	case -EOPNOTSUPP:
 		return error_code;
+	case -ENOSPC:
+		return -EBUSY;
 	default:
 		return -EIO;
 	}
-- 
2.53.0

Re: [PATCH] usb: translate ENOSPC for user space

[Michal Pecio]

On Wed, 25 Mar 2026 15:55:20 +0100, Oliver Neukum wrote:
> In case of insufficient bandwidth usb_submit_urb()
> returns -ENOSPC. Translating this to -EIO is not
> optimal. There are insufficient resources not
> an error. EBUSY is a better fit.
> 
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
>  include/linux/usb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index 04277af4bb9d..815f2212936e 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -2075,6 +2075,8 @@ static inline int usb_translate_errors(int error_code)
>  	case -ENODEV:
>  	case -EOPNOTSUPP:
>  		return error_code;
> +	case -ENOSPC:
> +		return -EBUSY;
>  	default:
>  		return -EIO;
>  	}

This function is used by serial drivers in syscalls like "set/get modem
control" and apparently also "write/read data" in cdc-wdm.

So when they fail because the USB I/O failed, does userspace really
care whether the I/O failed due to insufficient USB resources?
Are those syscalls documented to return EBUSY and is userspace expected
to handle it better than EIO in those particular cases?

I would assume that EBUSY means too many processes are trying to do too
many thing with this tty at once, and that's not the case. My recovery
might be to find such processes and kill them, and it wouldn't help.

What real world improvement was achieved? ;)

Does it ever happen? ENOSPC applies to periodic URBs, but that code
looks like sometihng that would end up using control or bulk.

Regards,
Michal