Messages in this thread | | | Date | Wed, 29 Oct 2014 15:26:54 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 00/11] nested sleeps, fixes and debug infrastructure |
| |
On Wed, Oct 29, 2014 at 01:00:56AM +0100, Oleg Nesterov wrote: > On 10/28, Peter Zijlstra wrote:
> > So I talked to Rafael yesterday and I'm going to replace all the > > wait_event*() stuff, and I suppose also freezable_schedule() because > > they're racy. > > > > The moment we call freezer_do_not_count() the freezer will ignore us, > > this means the thread could still be running (albeit not for long) when > > the freezer reports success. > > Yes, sure. IIRC the theory was that a PF_FREEZER_SKIP will do nothing > "wrong" wrt freezing/suspend before it actually sleeps, but I guess > today we can't assume this.
Esp. the wait_event_freezable*() family seems suspicious in that the cond stmt can actually result in quite a lot of code.
But see below, I don't think we have a guarantee it will _ever_ sleep.
Also, this calls schedule(); try_to_freeze() in a suitable loop that's safe against spurious wakeups, OTOH..
> > Ideally I'll be able to kill the entire freezer_do_not_count() stuff. > > Agreed... but it is not clear to me what exactly we can/should do.
.. I looked at freezable_schedule() and I'm not sure how to 'fix' that. The problem being things like signal.c:ptrace_stop() that will actually misbehave in the face of spurious wakeups as allowed by try_to_freeze().
Then again, freezable_schedule() isn't nearly as bad as the wait_event_freezable() stuff because it does indeed guarantee the task only calls schedule().
Then again, it is possible to miss these tasks and report freeze success with a running task all the same, suppose its already woken but preempted before freezer_count(). The for_each_process_thread() loop in try_to_freeze_tasks() will skip over it.
And all I can come up with is horrible.. maybe for another day.
| |