From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: syzkaller-bugs@googlegroups.com,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Johan Hovold <johan@kernel.org>,
syzkaller-bugs@googlegroups.com, rydberg@bitmath.org,
syzbot <syzbot+deb6abc36aad4008f407@syzkaller.appspotmail.com>,
linux-input@vger.kernel.org
Subject: Re: [syzbot] INFO: task hung in __input_unregister_device (4)
Date: Thu, 21 Jul 2022 18:53:27 +0200 [thread overview]
Message-ID: <8095587.T7Z3S40VBb@opensuse> (raw)
In-Reply-To: <2bcd5385-2423-2e8f-be01-9db93afaba43@I-love.SAKURA.ne.jp>
On giovedì 21 luglio 2022 17:06:26 CEST Tetsuo Handa wrote:
> On 2022/07/21 23:45, Fabio M. De Francesco wrote:
> > If it can be fixed, as you said, by a simple notification to
> > wait_event_interruptible(), why not changing iforce_usb_disconnect()
the
> > following way?
> >
> > static void iforce_usb_disconnect(struct usb_interface *intf)
> > {
> > struct iforce_usb *iforce_usb = usb_get_intfdata(intf);
> >
> > usb_set_intfdata(intf, NULL);
> >
> > __set_bit(IFORCE_XMIT_RUNNING, iforce_usb->iforce.xmit_flags);
>
> I assume you meant clear_bit() here, for
>
> wait_event_interruptible(iforce->wait,
> !test_bit(IFORCE_XMIT_RUNNING, iforce->xmit_flags));
>
> waits until IFORCE_XMIT_RUNNING bit is cleared.
>
Sorry, yes you are correct. I didn't note that negation of test_bit().
However, you understood what I was trying to convey :-)
> However, clear_bit() is racy, for IFORCE_XMIT_RUNNING bit is set by
> iforce_send_packet() at the previous line.
Why not protecting with a mutex, I mean both in iforce_usb_disconnect() and
soon before calling iforce_send_packet() in iforce_close()?
> > wake_up(&iforce_usb->iforce.wait);
> >
> > input_unregister_device(iforce_usb->iforce.dev);
> >
> > usb_free_urb(iforce_usb->irq);
> > usb_free_urb(iforce_usb->out);
> >
> > kfree(iforce_usb);
> > }
> >
> > I am sorry if I'm overlooking anything, especially because I'm entering
> > this thread without reading the other messages and so without knowing
the
> > whole context. Furthermore I haven't even test-compiled these changes
:-(
>
> So far, I asked syzbot to test
>
> --- a/drivers/input/joystick/iforce/iforce-usb.c
> +++ b/drivers/input/joystick/iforce/iforce-usb.c
> @@ -258,6 +258,9 @@ static void iforce_usb_disconnect(struct
usb_interface *intf)
>
> usb_set_intfdata(intf, NULL);
>
> + usb_poison_urb(iforce_usb->irq);
> + usb_poison_urb(iforce_usb->out);
> +
> input_unregister_device(iforce_usb->iforce.dev);
>
> usb_free_urb(iforce_usb->irq);
>
> which still triggered this problem, and
>
> --- a/drivers/input/joystick/iforce/iforce-main.c
> +++ b/drivers/input/joystick/iforce/iforce-main.c
> @@ -200,8 +200,10 @@ static void iforce_close(struct input_dev *dev)
> /* Disable force feedback playback */
> iforce_send_packet(iforce, FF_CMD_ENABLE, "\001");
> /* Wait for the command to complete */
> - wait_event_interruptible(iforce->wait,
> - !test_bit(IFORCE_XMIT_RUNNING, iforce-
>xmit_flags));
> + wait_event_interruptible_timeout
> + (iforce->wait,
> + !test_bit(IFORCE_XMIT_RUNNING, iforce-
>xmit_flags),
> + 5 * HZ);
> }
>
> iforce->xport_ops->stop_io(iforce);
>
> which did not trigger this problem.
It did not clear this problem because of _timeout(), I guess.
If I recall correctly, this task hanged in wait_event_interruptible() and
your problem was how to clear that bit and make the task return from
wait_event_interruptible(). Correct?
Now you changed this code to return after some time, despite that flag.
Are you sure this is the better suited way to fix this bug?
>
> Since wait_event_interruptible() was used here, I think we can expect
that
> it is tolerable to continue without waiting for the command to
complete...
Ah, yes. Maybe you are right here but I wouldn't bet on what authors
thought when they called wait_event_interruptible() :-)
Thanks,
Fabio
> --
> You received this message because you are subscribed to the Google Groups
"syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
msgid/syzkaller-bugs/2bcd5385-2423-2e8f-be01-9db93afaba43%40I-
love.SAKURA.ne.jp.
>
next prev parent reply other threads:[~2022-07-21 16:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-02 5:32 [syzbot] INFO: task hung in __input_unregister_device (4) syzbot
2022-07-02 15:32 ` syzbot
2022-07-22 13:33 ` Fabio M. De Francesco
2022-07-22 13:53 ` syzbot
2022-07-02 22:16 ` syzbot
2022-07-21 11:11 ` Tetsuo Handa
2022-07-21 14:45 ` Fabio M. De Francesco
2022-07-21 15:06 ` Tetsuo Handa
2022-07-21 16:53 ` Fabio M. De Francesco [this message]
2022-07-21 18:16 ` Fabio M. De Francesco
2022-07-22 14:39 ` Tetsuo Handa
2022-07-22 19:15 ` Fabio M. De Francesco
2022-07-22 19:25 ` Fabio M. De Francesco
2022-07-23 5:38 ` Tetsuo Handa
2022-07-26 3:53 ` Tetsuo Handa
2022-07-26 4:40 ` Fabio M. De Francesco
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=8095587.T7Z3S40VBb@opensuse \
--to=fmdefrancesco@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=johan@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rydberg@bitmath.org \
--cc=syzbot+deb6abc36aad4008f407@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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;
as well as URLs for NNTP newsgroup(s).