On Tue 04-12-18 09:31:11, Linus Torvalds wrote: > On Tue, Dec 4, 2018 at 1:58 AM Michal Hocko <mho...@kernel.org> wrote: > > > > AFAIU both suspend and hibernation require the system to enter quiescent > > state with no task potentially interfering with suspended devices. And > > in this particular case those de-thread-ed threads will certainly not > > interfere so silencing the lockdep sounds like a reasonable workaround. > > I still think it would be better to simply not freeze killed user processes. > > We already have things like > > if (test_tsk_thread_flag(p, TIF_MEMDIE)) > return false; > > exactly because we do not want to freeze processes that are about to > die due to being killed. Very similar situation: we don't want to > freeze those processes, because doing so would halt them from freeing > the resources that may be needed for suspend or hibernate.
Yeah, we do not freeze oom victims but that is really far from trivial to achieve. In order to do so we post-pone quiescent state until we know all the TIF_MEMDIE threads are gone. See oom_killer_disable. In short it is a painfull code. > How about something like we set PF_NOFREEZE when we set PF_EXITING? At > that point we've pretty much turned into a kernel thread, no? Hmm, that doesn't sound like a bad idea but I am not sure it will help because those threads we are waiting for might be block way before they reached PF_EXITING. I would expect that threads that actually reach that state usually die shortly. Unless I am missing something we are talking about basically two cases here. Those threads are frozen while de_thread waits for them because zap_other_threads cannot wake them from the fridge or they are blocked in uninterruptible sleep somewhere in the kernel. The later is the fundamental problem. The former could be hacked around (check PF_FROZEN and use uninterruptible wake), I guess but I haven't thought that through yet. -- Michal Hocko SUSE Labs