mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Ayush <ayush37735@gmail.com>
Cc: Thomas Winischhofer <thomas@winischhofer.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+3bc656a9271e7c8a5c6b@syzkaller.appspotmail.com
Subject: Re: [PATCH v1] USB: sisusbvga: avoid initializing device in open
Date: Sun, 6 Sep 2026 08:10:32 +0200	[thread overview]
Message-ID: <20260906081032.5ef81315.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260905193634.160600-1-ayush37735@gmail.com>

On Sun,  6 Sep 2026 01:06:34 +0530, Ayush wrote:
> The USB core holds minor_rwsem while invoking a USB character
> device's open callback. sisusb_open() can currently initialize the
> device while holding sisusb->lock, and that initialization performs
> synchronous USB I/O.
> 
> High-speed devices are already initialized during probe. Treat a
> probe-time initialization failure as a probe failure instead of
> retrying initialization from open, so the open callback no longer
> performs blocking device initialization.
> 
> Reported-by: syzbot+3bc656a9271e7c8a5c6b@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3bc656a9271e7c8a5c6b

Does this even fix the repro? I see no syzbot test requests there.

It seems that even if you delete this code, sisusb_open() will simply
wait on mutex_lock() before it even reaches this point.

The root cause is isusb_init_gfxdevice(), called by probe() and from
here, taking 10 minutes to complete on nonresponsive device. This is
the second time (that I know of) syzbot ran into this recently.


Thomas, do you still have this HW and a will to improve the driver,
or test / comment on patches? I suspect that those timeouts and retries
in the init routine are vastly excessive.

> Signed-off-by: Ayush <ayush37735@gmail.com>
> ---
>  drivers/usb/misc/sisusbvga/sisusbvga.c | 29 ++++++++++++--------------
>  1 file changed, 13 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/usb/misc/sisusbvga/sisusbvga.c b/drivers/usb/misc/sisusbvga/sisusbvga.c
> index 3e75a7c24828..6723a65b12b8 100644
> --- a/drivers/usb/misc/sisusbvga/sisusbvga.c
> +++ b/drivers/usb/misc/sisusbvga/sisusbvga.c
> @@ -2223,20 +2223,10 @@ static int sisusb_open(struct inode *inode, struct file *file)
>  	}
>  
>  	if (!sisusb->devinit) {
> -		if (sisusb->sisusb_dev->speed == USB_SPEED_HIGH ||
> -				sisusb->sisusb_dev->speed >= USB_SPEED_SUPER) {
> -			if (sisusb_init_gfxdevice(sisusb, 0)) {
> -				mutex_unlock(&sisusb->lock);
> -				dev_err(&sisusb->sisusb_dev->dev,
> -						"Failed to initialize device\n");
> -				return -EIO;
> -			}
> -		} else {
> -			mutex_unlock(&sisusb->lock);
> -			dev_err(&sisusb->sisusb_dev->dev,
> -					"Device not attached to USB 2.0 hub\n");
> -			return -EIO;
> -		}
> +		mutex_unlock(&sisusb->lock);
> +		dev_err(&sisusb->sisusb_dev->dev,
> +			"Device not initialized\n");
> +		return -EIO;

Not sure if we really want to log every failure to open some device.

Not sure if EIO is the right code to retun from open(), particularly
after probe failure.

And really, are we opening the device after probe failed (see below)?
Seems weird...

>  	}
>  
>  	/* Increment usage count for our sisusb */
> @@ -2880,9 +2870,16 @@ static int sisusb_probe(struct usb_interface *intf,
>  
>  	if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
>  		int initscreen = 1;
> -		if (sisusb_init_gfxdevice(sisusb, initscreen))
> +
> +		if (sisusb_init_gfxdevice(sisusb, initscreen)) {
>  			dev_err(&sisusb->sisusb_dev->dev,
> -					"Failed to early initialize device\n");
> +				"Failed to early initialize device\n");
> +			sisusb->present = 0;
> +			usb_set_intfdata(intf, NULL);
> +			usb_put_dev(sisusb->sisusb_dev);
> +			retval = -EIO;
> +			goto error_4;
> +		}
>  
>  	} else
>  		dev_info(&sisusb->sisusb_dev->dev,
> -- 
> 2.53.0
> 

  reply	other threads:[~2026-09-06  6:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-05 19:36 Ayush
2026-09-06  6:10 ` Michal Pecio [this message]
2026-09-06 11:02   ` Thomas Winischhofer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260906081032.5ef81315.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=ayush37735@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzbot+3bc656a9271e7c8a5c6b@syzkaller.appspotmail.com \
    --cc=thomas@winischhofer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®