linux-kernel - No freezing of kernel threads (was: Re: [GIT PULL] libata fixes for v3.13-rc5)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1312252211550.15064-100000@netrider.rowland.org>
Date:	Wed, 25 Dec 2013 22:29:30 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
cc:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	<linux-ide@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...r.kernel.org>
Subject: No freezing of kernel threads (was: Re: [GIT PULL] libata fixes for
 v3.13-rc5)

n Wed, 25 Dec 2013, Rafael J. Wysocki wrote:

> > Is this discussed in more detail somewhere (an email thread, for
> > example)?
> 
> This one, more or less: https://lkml.org/lkml/2013/12/13/402

Thanks.  As I understand it (correct me if this is wrong), the problem
is that some subsystems wait for a freezable work queue or kthread to
carry out some job, and they do this as part of their resume pathway.  
Obviously this leads to deadlock.

One possible answer is to fix the subsystems -- make them not do that
any more.  Easier said than done, I suppose.  In any case, this is a
class of errors that is not easily detectable at the moment (could
lockdep be taught to recognize it?).

But I don't see how swinging to the other extreme (i.e., making no
kernel threads or work queues freezable) really solves anything.  
Those things are freezable for real reasons; they do stuff that must
not happen while the system is in the middle of a sleep transition.

Thus...  If a subsystem's resume pathway depends on something happening 
which must not happen during a sleep transition, then something is 
fundamentally broken.

Perhaps the problem could be solved by a finer-grained approach.  For
example, maybe some of these work queues or kthreads need to be frozen
only while the system is suspending, so they can safely be thawed when
the resume begins.  Would that fix the problem that began this 
discussion?

I know that in the case of khubd, we really do want it to remain frozen 
throughout the entire sleep transition.

Alan Stern

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