From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Jiri Slaby <jslaby@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
Andrey Konovalov <andreyknvl@google.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>
Subject: Re: Potential data race in flush_to_ldisc
Date: Fri, 28 Aug 2015 13:10:00 -0500 [thread overview]
Message-ID: <20150828181000.GB16113@kroah.com> (raw)
In-Reply-To: <CACT4Y+Zaebxi+qhakKqE=oirQmbND_AsLRa7hjsLFfs7QtTGWQ@mail.gmail.com>
On Fri, Aug 28, 2015 at 06:57:17PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> We are working on a dynamic data race detector for the Linux kernel,
> KernelThreadSanitizer (ktsan):
> https://github.com/google/ktsan/wiki
>
> While booting kernel (upstream revision 21bdb584af8c) we got a report:
>
> ThreadSanitizer: data-race in release_tty
>
> Write of size 8 by thread T325 (K2579):
> [<ffffffff81655c43>] release_tty+0xf3/0x1c0 drivers/tty/tty_io.c:1688
> [<ffffffff816563a8>] tty_release+0x698/0x7c0 drivers/tty/tty_io.c:1920
> [<ffffffff8126154f>] __fput+0x15f/0x310 fs/file_table.c:207
> [<ffffffff8126176d>] ____fput+0x1d/0x30 fs/file_table.c:243
> [<ffffffff810b9485>] task_work_run+0x115/0x130 kernel/task_work.c:123
> (discriminator 1)
> [< inlined >] do_notify_resume+0x73/0x80
> tracehook_notify_resume include/linux/tracehook.h:190
> [<ffffffff81006da3>] do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:757
> [<ffffffff81ee25fc>] int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326
>
> Previous read of size 8 by thread T19 (K16):
> [<ffffffff816624d9>] flush_to_ldisc+0x29/0x300 drivers/tty/tty_buffer.c:472
> [<ffffffff810b1fce>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b2530>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bbbd0>] kthread+0x150/0x170 kernel/kthread.c:207
> [<ffffffff81ee281f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:526
>
>
> flush_to_ldisc accesses port->itty:
>
> static void flush_to_ldisc(struct work_struct *work)
> {
> ...
> tty = port->itty;
> if (tty == NULL)
> return;
> disc = tty_ldisc_ref(tty);
>
> while release_tty concurrently sets itty to NULL:
>
> static void release_tty(struct tty_struct *tty, int idx)
> {
> ...
> tty->port->itty = NULL;
> if (tty->link)
> tty->link->port->itty = NULL;
> cancel_work_sync(&tty->port->buf.work);
> tty_kref_put(tty->link);
> tty_kref_put(tty);
> }
>
> It seems that read of port->itty requires to be at least READ_ONCE,
> because otherwise flush_to_ldisc can check that itty is not NULL, then
> re-read it again and crash with NULL deref.
> I don't know what is ownership and locking story here. There can be
> larger issue here: either a lock is missing, or itty can be deleted
> under flush_to_ldisc feet.
>
> Please confirm that this is real but. If so please fix it.
Patches are always gladly accepted. Don't force us to try to determine
if your tool is finding false-positives or not. That is your
responsibility, not ours :)
thanks,
greg k-h
next prev parent reply other threads:[~2015-08-28 18:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 16:57 Potential data race in flush_to_ldisc Dmitry Vyukov
2015-08-28 18:10 ` Greg Kroah-Hartman [this message]
2015-08-28 18:18 ` Dmitry Vyukov
2015-08-28 19:24 ` Peter Hurley
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=20150828181000.GB16113@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=jslaby@suse.cz \
--cc=kcc@google.com \
--cc=linux-kernel@vger.kernel.org \
/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.