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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/