Re: [PATCH 1/2] sched: Introduce rcuwait machinery

From	Oleg Nesterov <oleg@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH 1/2] sched: Introduce rcuwait machinery
Date	2017-01-17 18:50 +0100
Message-ID	<t0G3o-1zz-31@gated-at.bofh.it> (permalink)
References	<sRf2p-3NJ-3@gated-at.bofh.it> <sRf2p-3NJ-1@gated-at.bofh.it> <t04r7-1D1-15@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 01/15, Davidlohr Bueso wrote:
>
> On Thu, 22 Dec 2016, Bueso wrote:
>
>> +	WARN_ON(current->exit_state);                                   \
>
> While not related to this patch, but per 3245d6acab9 (exit: fix race
> between wait_consider_task() and wait_task_zombie()), should we not
> *_ONCE() all things ->exit_state?

current->exit_state != 0 is stable. I mean, only current can change it
from zero to non-zero, and once it is non-zero it can't be zero again.

> I'm not really refering to a specific
> bug (much less here, where that race would not matter obviously), but
> if nothing else, for documentation

Oh, I won't argue but I do not agree. To me, READ_ONCE() often adds some
confusion because I can almost never understand if it is actually needed
for correctness or it was added "just in case".

Oleg.

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: [PATCH 1/2] sched: Introduce rcuwait machinery Oleg Nesterov <oleg@redhat.com> - 2017-01-17 18:50 +0100

csiph-web