Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Marco Elver <elver@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Eric Dumazet <edumazet@google.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	syzbot <syzbot+3ef049d50587836c0606@syzkaller.appspotmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrea Parri <parri.andrea@gmail.com>,
	LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>
Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file
Date: Tue, 12 Nov 2019 16:25:52 -0800
Message-ID: <20191113002552.GY2865@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <CANpmjNP4qj7XcYcdrEEb+0_qeg-ii77qy0=-b9k07VRyNjqixA@mail.gmail.com>

On Mon, Nov 11, 2019 at 04:10:20PM +0100, Marco Elver wrote:
> On Mon, 11 Nov 2019 at 15:31, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Mon, Nov 11, 2019 at 03:17:51PM +0100, Marco Elver wrote:
> > > On Sun, 10 Nov 2019 at 21:44, Paul E. McKenney <paulmck@kernel.org> wrote:
> > > >
> > > > On Sun, Nov 10, 2019 at 11:20:53AM -0800, Linus Torvalds wrote:
> > > > > On Sun, Nov 10, 2019 at 11:12 AM Linus Torvalds
> > > > > <torvalds@linux-foundation.org> wrote:
> > > > > >
> > > > > > And this is where WRITE_IDEMPOTENT would make a possible difference.
> > > > > > In particular, if we make the optimization to do the "read and only
> > > > > > write if changed"
> > > > >
> > > > > It might be useful for checking too. IOW, something like KCSAN could
> > > > > actually check that if a field has an idempotent write to it, all
> > > > > writes always have the same value.
> > > > >
> > > > > Again, there's the issue with lifetime.
> > > > >
> > > > > Part of that is "initialization is different". Those writes would not
> > > > > be marked idempotent, of course, and they'd write another value.
> > > > >
> > > > > There's also the issue of lifetime at the _end_ of the use, of course.
> > > > > There _are_ interesting data races at the end of the lifetime, both
> > > > > reads and writes.
> > > > >
> > > > > In particular, if it's a sticky flag, in order for there to not be any
> > > > > races, all the writes have to happen with a refcount held, and the
> > > > > final read has to happen after the final refcount is dropped (and the
> > > > > refcounts have to have atomicity and ordering, of course). I'm not
> > > > > sure how easy something like that is model in KSAN. Maybe it already
> > > > > does things like that for all the other refcount stuff we do.
> > > > >
> > > > > But the lifetime can be problematic for other reasons too - in this
> > > > > particular case we have a union for that sticky flag (which is used
> > > > > under the refcount), and then when the final refcount is released we
> > > > > read that value (thus no data race) but because of the union we will
> > > > > now start using that field with *different* data. It becomes that RCU
> > > > > list head instead.
> > > > >
> > > > > That kind of "it used to be a sticky flag, but now the lifetime of the
> > > > > flag is over, and it's something entirely different" might be a
> > > > > nightmare for something like KCSAN. It sounds complicated to check
> > > > > for, but I have no idea what KCSAN really considers complicated or
> > > > > not.
> > > >
> > > > But will "one size fits all" be practical and useful?
> > > >
> > > > For my code, I would be happy to accept a significant "false positive"
> > > > rate to get even a probabilistic warning of other-task accesses to some
> > > > of RCU's fields.  Even if the accesses were perfect from a functional
> > > > viewpoint, they could be problematic from a performance and scalability
> > > > viewpoint.  And for something like RCU, real bugs, even those that are
> > > > very improbable, need to be fixed.
> > > >
> > > > But other code (and thus other developers and maintainers) are going to
> > > > have different needs.  For all I know, some might have good reasons to
> > > > exclude their code from KCSAN analysis entirely.
> > > >
> > > > Would it make sense for KCSAN to have per-file/subsystem/whatever flags
> > > > specifying the depth of the analysis?
> > >
> > > Just to answer this: we already have this, and disable certain files
> > > already. So it's an option if required. Just need maintainers to add
> > > KCSAN_SANITIZE := n, or KCSAN_SANITIZE_file.o := n to Makefiles, and
> > > KCSAN will simply ignore those.
> > >
> > > FWIW we now also have a config option to "ignore repeated writes with
> > > the same value". It may be a little overaggressive/imprecise in
> > > filtering data races, but anything else like the super precise
> > > analysis involving tracking lifetimes and values (and whatever else
> > > the rules would require) is simply too complex. So, the current
> > > solution will avoid reporting cases like the original report here
> > > (__alloc_file), but at the cost of maybe being a little imprecise.
> > > It's probably a reasonable trade-off, given that we have too many data
> > > races to deal with on syzbot anyway.
> >
> > Nice!
> >
> > Is this added repeated-writes analysis something that can be disabled?
> > I would prefer that the analysis of RCU complain in this case as a
> > probabilistic cache-locality warning.  If it can be disabled, please
> > let me know if there is anything that I need to do to make this happen.
> 
> It's hidden behind a Kconfig config option, and actually disabled by
> default. We can't enable/disable this on a per-file basis.
> 
> Right now, we'll just enable it on the public syzbot instance, which
> will use the most conservative config.  Of course you can still run
> your own fuzzer/stress test of choice with KCSAN and the option
> disabled. Is that enough?
> 
> Otherwise I could also just say if the symbolized top stack frame
> contains "rcu_", don't ignore -- which would be a little hacky and
> imprecise though. What do you prefer?

Tough question.  ;-)

We could try the "rcu_" trick, and if it doesn't cause problems for
others, why not?

						Thanx, Paul

  reply index

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAHk-=wjB61GNmqpX0BLA5tpL4tsjWV7akaTc2Roth7uGgax+mw@mail.gmail.com>
2019-11-10 16:09 ` Alan Stern
2019-11-10 19:10   ` Marco Elver
2019-11-11 15:51     ` Alan Stern
2019-11-11 16:51       ` Linus Torvalds
2019-11-11 17:52         ` Eric Dumazet
2019-11-11 18:04           ` Linus Torvalds
2019-11-11 18:31             ` Eric Dumazet
2019-11-11 18:44               ` Eric Dumazet
2019-11-11 19:00                 ` Linus Torvalds
2019-11-11 19:13                   ` Eric Dumazet
2019-11-11 20:43                     ` Linus Torvalds
2019-11-11 20:46                       ` Linus Torvalds
2019-11-11 21:53                         ` Eric Dumazet
2019-11-11 23:51                   ` Linus Torvalds
2019-11-12 16:50                     ` Kirill Smelkov
2019-11-12 17:23                       ` Linus Torvalds
2019-11-12 17:36                         ` Linus Torvalds
2019-11-17 18:56                           ` Kirill Smelkov
2019-11-17 19:20                             ` Linus Torvalds
2019-11-11 18:50               ` Linus Torvalds
2019-11-11 18:59                 ` Marco Elver
2019-11-11 18:59                 ` Eric Dumazet
2019-11-10 19:12   ` Linus Torvalds
2019-11-10 19:20     ` Linus Torvalds
2019-11-10 20:44       ` Paul E. McKenney
2019-11-10 21:10         ` Linus Torvalds
2019-11-10 21:31           ` Paul E. McKenney
2019-11-11 14:17         ` Marco Elver
2019-11-11 14:31           ` Paul E. McKenney
2019-11-11 15:10             ` Marco Elver
2019-11-13  0:25               ` Paul E. McKenney [this message]
2019-11-12 19:14     ` Alan Stern
2019-11-12 19:47       ` Linus Torvalds
2019-11-12 20:29         ` Alan Stern
2019-11-12 20:58           ` Linus Torvalds
2019-11-12 21:13             ` Linus Torvalds
2019-11-12 22:05               ` Marco Elver
2019-11-12 21:48             ` Alan Stern
2019-11-12 22:07               ` Eric Dumazet
2019-11-12 22:44                 ` Alexei Starovoitov
2019-11-12 23:17                   ` Eric Dumazet
2019-11-12 23:40                     ` Linus Torvalds
2019-11-13 15:00                       ` Marco Elver
2019-11-13 16:57                         ` Linus Torvalds
2019-11-13 21:33                           ` Marco Elver
2019-11-13 21:50                             ` Alan Stern
2019-11-13 22:48                               ` Marco Elver
2019-11-08 13:16 syzbot
2019-11-08 13:28 ` Eric Dumazet
2019-11-08 17:01   ` Linus Torvalds
2019-11-08 17:22     ` Eric Dumazet
2019-11-08 17:38       ` Linus Torvalds
2019-11-08 17:53         ` Eric Dumazet
2019-11-08 17:55           ` Eric Dumazet
2019-11-08 18:02             ` Eric Dumazet
2019-11-08 18:12               ` Linus Torvalds
2019-11-08 20:30             ` Linus Torvalds
2019-11-08 20:53               ` Eric Dumazet
2019-11-08 21:36                 ` Linus Torvalds
2019-11-08 18:05           ` Linus Torvalds
2019-11-08 18:15             ` Marco Elver
2019-11-08 18:40               ` Linus Torvalds
2019-11-08 19:48                 ` Marco Elver
2019-11-08 20:26                   ` Linus Torvalds
2019-11-08 21:57                     ` Alan Stern
2019-11-08 22:06                       ` Linus Torvalds
2019-11-09 23:08                         ` Alan Stern

Reply instructions:

You may reply publically 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=20191113002552.GY2865@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=akiyks@gmail.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=syzbot+3ef049d50587836c0606@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git