Messages in this thread | | | Date | Wed, 29 Oct 2014 10:35:03 +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: > > > > 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() ?
Fair point indeed. Now I had a look at __refrigerator() and is there any reason we should not remove that .check_kthr_stop argument and replace it with an unconditional (current->flags & PF_KTHREAD) ?
| |