Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1560857 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

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.

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web