[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191007141432.GA22083@andrea.guest.corp.microsoft.com>
Date: Mon, 7 Oct 2019 16:14:32 +0200
From: Andrea Parri <parri.andrea@...il.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Christian Brauner <christian.brauner@...ntu.com>,
bsingharora@...il.com, Marco Elver <elver@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
syzbot <syzbot+c5d03165a1bd1dead0c1@...kaller.appspotmail.com>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH v2] taskstats: fix data-race
> > > static struct taskstats *taskstats_tgid_alloc(struct task_struct *tsk)
> > > {
> > > struct signal_struct *sig = tsk->signal;
> > > - struct taskstats *stats;
> > > + struct taskstats *stats_new, *stats;
> > >
> > > - if (sig->stats || thread_group_empty(tsk))
> > > - goto ret;
> > > + /* Pairs with smp_store_release() below. */
> > > + stats = READ_ONCE(sig->stats);
> >
> > This pairing suggests that the READ_ONCE() is heading an address
> > dependency, but I fail to identify it: what is the target memory
> > access of such a (putative) dependency?
>
> I would assume callers of this function access *stats. So the
> dependency is between loading stats and accessing *stats.
AFAICT, the only caller of the function in 5.4-rc2 is taskstats_exit(),
which 'casts' the return value to a boolean (so I really don't see how
any address dependency could be carried over/relied upon here).
Andrea
Powered by blists - more mailing lists