On Tue, 17 May 2005, Andrew Morton wrote:
> Well, hrm, maybe. If this task has one sibling thread, and that thread is
> in the process of exitting then (current == next_thread(current)) may
> become true before that sibling thread has had a chance to dump its process
> accounting info into the signal structure.
The task is only "unhashed" after the counters have been added in
__exit_signal. See release_task in kernel/exit.c
> If that dumping happens prior to the __detach_pid() call then things are
> probably OK (modulo memory ordering issues). Otherwise there's a little
> window where the accounting will go wrong.
__exit_signal takes various locks that will insure the proper sequencing.
> Have you audited that code to ensure that the desired sequencing occurs in
> all cases and that the appropriate barriers are in place?
AFAIK release task is always called for task removal.
> It all looks a bit fast-and-loose. If there are significant performance
> benefits and these issues are loudly commented (they aren't at present)
> then maybe-OK, I guess.
There are significant performance benefits in particular for one standard
NUMA benchmark that keeps calling sys_times over and over. I believe other
programs may exhibit the same brain dead behavior.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
