Messages in this thread | | | From | Roland McGrath <> | Subject | Re: regression introduced by - timers: fix itimer/many thread hang | Date | Mon, 17 Nov 2008 10:16:55 -0800 (PST) |
| |
> > - if (!->signal) > > + if (->exit_state) > > return; > > Yes, unless I missed something again, this should work. I'll send > the (simple) patches soon, but I have no idea how to test them.
That certainly will exclude the problem of crashing in the tick interrupt after exit_notify. Unfortunately, it's moving in an undesireable direction for the long run. That is, it loses from the accounting even more of the CPU time spent on the exit path.
> However, I'm afraid there is another problem. On 32 bit cpus we can't > read "u64 sum_exec_runtime" atomically, and so thread_group_cputime() > can "overestimate" ->sum_exec_runtime by (up to) UINT_MAX if it races > with the thread which updates its per_cpu_ptr(.totals). This for example > means that check_process_timers() can fire the CPUCLOCK_SCHED timers > before time. > > No?
Yes, I think you're right. The best solution that comes to mind off hand is to protect the update/read of that u64 with a seqcount_t on 32-bit.
Thanks, Roland
| |