[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Apr 2019 15:09:02 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Joel Fernandes <joel@...lfernandes.org>
cc: "Paul E. McKenney" <paulmck@...ux.ibm.com>,
Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>,
Kees Cook <keescook@...omium.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
LKML <linux-kernel@...r.kernel.org>,
Android Kernel Team <kernel-team@...roid.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>, Michal Hocko <mhocko@...e.com>,
"Reshetova, Elena" <elena.reshetova@...el.com>
Subject: Re: [PATCH] Convert struct pid count to refcount_t
On Thu, 4 Apr 2019, Joel Fernandes wrote:
> FWIW, thought to mention (feel free ignore the suggestion if its
> meaningless): If there is any chance that the outcome can be better
> outputted, like r1=X; x=1; Where X stands for the result of a data race, that
> would be lovely. I don't know much about herd internals (yet) to say if the
> suggestion makes sense but as a user, it would certainly help reduce
> confusion.
I don't think that is feasible. For one thing, according to the C
Standard, in the presence of a data race a program is allowed to do
anything at all. There's no point trying to display all possible
outcomes of an execution!
If we adopted the proposal that certain kinds of data races only result
in undefined values, things would be a little better. It's possible
that the herd program could be changed to support undefined values.
At present, however, it does not.
Alan Stern
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
