All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	Will Deacon <will@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	bsingharora@gmail.com, Marco Elver <elver@google.com>,
	stable <stable@vger.kernel.org>,
	syzbot <syzbot+c5d03165a1bd1dead0c1@syzkaller.appspotmail.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH v6] taskstats: fix data-race
Date: Thu, 24 Oct 2019 15:05:02 +0200	[thread overview]
Message-ID: <20191024130502.GA11335@andrea.guest.corp.microsoft.com> (raw)
In-Reply-To: <CACT4Y+Z2-mm6Qk0cecJdiA5B_VsQ1v8k2z+RWrDQv6dTNFXFog@mail.gmail.com>

On Thu, Oct 24, 2019 at 01:51:20PM +0200, Dmitry Vyukov wrote:
> On Thu, Oct 24, 2019 at 1:32 PM Andrea Parri <parri.andrea@gmail.com> wrote:
> >
> > > How these later loads can be completely independent of the pointer
> > > value? They need to obtain the pointer value from somewhere. And this
> > > can only be done by loaded it. And if a thread loads a pointer and
> > > then dereferences that pointer, that's a data/address dependency and
> > > we assume this is now covered by READ_ONCE.
> >
> > The "dependency" I was considering here is a dependency _between the
> > load of sig->stats in taskstats_tgid_alloc() and the (program-order)
> > later loads of *(sig->stats) in taskstats_exit().  Roughly speaking,
> > such a dependency should correspond to a dependency chain at the asm
> > or registers level from the first load to the later loads; e.g., in:
> >
> >   Thread [register r0 contains the address of sig->stats]
> >
> >   A: LOAD r1,[r0]       // LOAD_ACQUIRE sig->stats
> >      ...
> >   B: LOAD r2,[r0]       // LOAD *(sig->stats)
> >   C: LOAD r3,[r2]
> >
> > there would be no such dependency from A to C.  Compare, e.g., with:
> >
> >   Thread [register r0 contains the address of sig->stats]
> >
> >   A: LOAD r1,[r0]       // LOAD_ACQUIRE sig->stats
> >      ...
> >   C: LOAD r3,[r1]       // LOAD *(sig->stats)
> >
> > AFAICT, there's no guarantee that the compilers will generate such a
> > dependency from the code under discussion.
> 
> Fixing this by making A ACQUIRE looks like somewhat weird code pattern
> to me (though correct). B is what loads the address used to read
> indirect data, so B ought to be ACQUIRE (or LOAD-DEPENDS which we get
> from READ_ONCE).
> 
> What you are suggesting is:
> 
> addr = ptr.load(memory_order_acquire);
> if (addr) {
>   addr = ptr.load(memory_order_relaxed);
>   data = *addr;
> }
> 
> whereas the canonical/non-convoluted form of this pattern is:
> 
> addr = ptr.load(memory_order_consume);
> if (addr)
>   data = *addr;

No, I'd rather be suggesting:

  addr = ptr.load(memory_order_acquire);
  if (addr)
    data = *addr;

since I'd not expect any form of encouragement to rely on "consume" or
on "READ_ONCE() + true-address-dependency" from myself.  ;-)

IAC, v6 looks more like:

  addr = ptr.load(memory_order_consume);
  if (!!addr)
    *ptr = 1;
  data = *ptr;

to me (hence my comments/questions ...).

Thanks,
  Andrea

  reply	other threads:[~2019-10-24 13:05 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-05  4:26 KCSAN: data-race in taskstats_exit / taskstats_exit syzbot
2019-10-05  4:29 ` Dmitry Vyukov
2019-10-05 11:29   ` Christian Brauner
2019-10-05 11:28 ` [PATCH] taskstats: fix data-race Christian Brauner
2019-10-05 13:33   ` Marco Elver
2019-10-05 14:15     ` Christian Brauner
2019-10-05 14:34       ` Marco Elver
2019-10-06 10:00   ` Dmitry Vyukov
2019-10-06 10:59     ` Christian Brauner
2019-10-06 23:52   ` Christian Brauner
2019-10-07  7:31     ` Dmitry Vyukov
2019-10-07  9:29       ` Christian Brauner
2019-10-07 10:40     ` Andrea Parri
2019-10-07 10:50       ` Christian Brauner
2019-10-07 11:01       ` [PATCH v2] " Christian Brauner
2019-10-07 13:18         ` Andrea Parri
2019-10-07 13:28           ` Christian Brauner
2019-10-07 13:50           ` Dmitry Vyukov
2019-10-07 13:55             ` Christian Brauner
2019-10-07 14:08               ` Dmitry Vyukov
2019-10-07 14:10                 ` Christian Brauner
2019-10-07 14:14             ` Andrea Parri
2019-10-07 14:18               ` Dmitry Vyukov
2019-10-08 14:20                 ` Andrea Parri
2019-10-08 14:24                   ` Christian Brauner
2019-10-08 15:26                     ` Andrea Parri
2019-10-08 15:35                       ` Christian Brauner
2019-10-08 15:44                         ` Andrea Parri
2019-10-09 11:31                           ` [PATCH] " Christian Brauner
2019-10-09 11:40                             ` Christian Brauner
2019-10-09 11:48                             ` [PATCH v5] " Christian Brauner
2019-10-09 12:08                               ` Andrea Parri
2019-10-09 13:26                               ` Christian Brauner
2019-10-21 11:33                               ` [PATCH v6] " Christian Brauner
2019-10-21 12:19                                 ` Rasmus Villemoes
2019-10-21 13:04                                   ` Christian Brauner
2019-11-29 17:56                                     ` Will Deacon
2019-11-30 15:08                                       ` Christian Brauner
2019-10-23 12:16                                 ` Andrea Parri
2019-10-23 12:39                                   ` Dmitry Vyukov
2019-10-23 13:11                                     ` Christian Brauner
2019-10-23 13:20                                       ` Dmitry Vyukov
2019-10-24 11:31                                     ` Andrea Parri
2019-10-24 11:51                                       ` Dmitry Vyukov
2019-10-24 13:05                                         ` Andrea Parri [this message]
2019-10-24 13:13                                           ` Dmitry Vyukov
2019-10-24 13:21                                             ` Christian Brauner
2019-10-24 13:34                                               ` Dmitry Vyukov
2019-10-24 13:43                                             ` Andrea Parri
2019-10-24 13:58                                               ` Dmitry Vyukov
2019-10-24 14:40                                                 ` Andrea Parri
2019-10-24 14:49                                                   ` Dmitry Vyukov
2019-11-29 17:57                                 ` Will Deacon
2019-10-09 11:48                             ` [PATCH] " Marco Elver
2019-10-09 11:53                               ` Christian Brauner
2019-11-06  0:27   ` Balbir Singh
2019-11-06  0:09 ` KCSAN: data-race in taskstats_exit / taskstats_exit Balbir Singh
2019-11-06 10:23   ` Marco Elver
2019-11-07 10:39     ` Balbir Singh
2019-11-08  0:54     ` Balbir Singh
2019-11-08  8:55       ` Dmitry Vyukov
2019-11-09  3:42         ` Balbir Singh

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=20191024130502.GA11335@andrea.guest.corp.microsoft.com \
    --to=parri.andrea@gmail.com \
    --cc=bsingharora@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+c5d03165a1bd1dead0c1@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=will@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.