Messages in this thread | | | Date | Mon, 3 Feb 2020 09:25:54 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Confused about hlist_unhashed_lockless() |
| |
On Mon, Feb 03, 2020 at 04:05:25PM +0000, David Laight wrote: > From: Marco Elver > > Sent: 03 February 2020 15:55 > > > > On Mon, 3 Feb 2020 at 16:45, David Laight <David.Laight@aculab.com> wrote: > > > > > > From: Eric Dumazet > > > > Sent: 31 January 2020 18:53 > > > > > > > > On Fri, Jan 31, 2020 at 10:48 AM Eric Dumazet <edumazet@google.com> wrote: > > > > > > > > > > > > > > This is nice, now with have data_race() > > > > > > > > > > Remember these patches were sent 2 months ago, at a time we were > > > > > trying to sort out things. > > > > > > > > > > data_race() was merged a few days ago. > > > > > > > > Well, actually data_race() is not there yet anyway. > > > > > > Shouldn't it be NO_DATA_RACE() ?? > > > > Various options were considered, and based on feedback from Linus, > > decided 'data_race(..)' is the best option: > > https://lore.kernel.org/linux-fsdevel/CAHk- > > =wg5CkOEF8DTez1Qu0XTEFw_oHhxN98bDnFqbY7HL5AB2g@mail.gmail.com/ > > > > It's meant to be as unobtrusive as possible, and an all-caps macro was > > ruled out. > > Except that it then looks like something that actually does something. > > > Second, the "NO_" prefix would be incorrect, since it'd be the > > opposite of what it is. The macro is meant to document and mark a > > deliberate data race. > > It should be IGNORE_DATA_RACE() then.
People will get used to the name more quickly than they will get used to typing the extra seven characters. Here is the current comment header:
/* * data_race(): macro to document that accesses in an expression may conflict with * other concurrent accesses resulting in data races, but the resulting * behaviour is deemed safe regardless. * * This macro *does not* affect normal code generation, but is a hint to tooling * that data races here should be ignored. */
I will be converting this to docbook form.
In addition, in the KCSAN documentation:
* KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that any data races due to accesses in ``expr`` should be ignored and resulting behaviour when encountering a data race is deemed safe.
Fair enough?
Thanx, Paul
| |