Messages in this thread | | | Date | Wed, 29 Oct 2014 01:00:56 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 00/11] nested sleeps, fixes and debug infrastructure |
| |
On 10/28, Peter Zijlstra wrote: > > On Tue, Oct 28, 2014 at 01:07:03AM +0100, Oleg Nesterov wrote: > > > I was going to say that wait_event_freezable() in kauditd_thread() > > is not friendly wrt kthread_should_stop() and thus we we need > > kthread_freezable_should_stop(). > > I'm not sure those two would interact, yes, both would first set either > the freezable or stop bit and then wake. If both were to race, all we > need to ensure is to check both before calling schedule again. > > A loop like: > > while (!kthread_should_stop()) { > wait_event_freezable(wq, cond); > } > > Would satisfy that, because even if kthread_should_stop() gets set first > and then freezing happens and we get into try_to_freeze() first, we'd > still to the kthread_should_stop() check right after we thaw.
Right after, yes.
But what if it calls try_to_freeze() and another thread (which should be frozen too) sleeps in kthread_stop() ?
> > Perhaps it also makes sense to redefine wait_event_freezable.*() > > via ___wait_event(cmd => freezable_schedule), but I think this needs > > another patch. > > 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.
> 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.
Anyway, I only meant that I believe your patch is correct (just it should not define wait_freezable which we already have), and you could also remove that kthread_should_stop() which only adds the confusion.
Oleg.
| |