From: Greg KH <gregkh@linuxfoundation.org>
To: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
Subject: Re: [PATCH 2/2] vt: selection, push sel_lock up
Date: Fri, 28 Feb 2020 14:04:00 +0100 [thread overview]
Message-ID: <20200228130400.GA3017265@kroah.com> (raw)
In-Reply-To: <71582fee-257c-3ef4-7c03-3d43651898ff@suse.cz>
On Fri, Feb 28, 2020 at 01:59:36PM +0100, Jiri Slaby wrote:
> On 28. 02. 20, 13:03, Greg KH wrote:
> > On Fri, Feb 28, 2020 at 12:54:06PM +0100, Jiri Slaby wrote:
> >> sel_lock cannot nest in the console lock. Thanks to syzkaller, the
> >> kernel states firmly:
> >>
> >>> WARNING: possible circular locking dependency detected
> >>> 5.6.0-rc3-syzkaller #0 Not tainted
> >>> ------------------------------------------------------
> >>> syz-executor.4/20336 is trying to acquire lock:
> >>> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
> ...
> >>> other info that might help us debug this:
> >>>
> >>> Chain exists of:
> >>> &tty->termios_rwsem --> console_lock --> sel_lock
> >>
> >> Clearly. From the above, we have:
> >> console_lock -> sel_lock
> >> sel_lock -> termios_rwsem
> >> termios_rwsem -> console_lock
> >>
> >> Fix this by reversing the console_lock -> sel_lock dependency in
> >> ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
> >>
> >> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> >> Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
> >> Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
> >
> > As 07e6124a1a46 was marked for stable, both of these should be as well,
> > right?
>
> Ah, yes. My bad again, sorry.
>
> > And did you happen to test these two with the syzbot tool to see if it
> > really did fix the report?
>
> Nope, this syz* stuff is a black magic for me. How can I do that?
From the syzbot report at the bottom it says:
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
Try running these through that and let's see if we get a "success"
report or not.
thanks,
greg k-h
prev parent reply other threads:[~2020-02-28 13:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 11:54 [PATCH 1/2] vt: selection, push console lock down Jiri Slaby
2020-02-28 11:54 ` [PATCH 2/2] vt: selection, push sel_lock up Jiri Slaby
2020-02-28 12:03 ` Greg KH
2020-02-28 12:59 ` Jiri Slaby
2020-02-28 13:04 ` Greg KH [this message]
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=20200228130400.GA3017265@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=syzbot+26183d9746e62da329b8@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.