linux-kernel - Re: 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]

Date:	Thu, 26 Dec 2013 14:01:20 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	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: Re: No freezing of kernel threads (was: Re: [GIT PULL] libata fixes
 for v3.13-rc5)

Hey,

On Thu, Dec 26, 2013 at 01:42:29PM -0500, Alan Stern wrote:
> In the case of hibernation, it's not so simple.  We do need to perform 
> I/O, in order to save the memory image.  But we also need to avoid 
> unnecessary I/O, in order to keep the on-disk data consistent with the 
> data in the memory image.  You probably can't accomplish this at the 
> device driver or subsystem level.

That was what I assumed too but Rafael tells me it has nothing to do
with hibernation.

> > which bothers me about the freezer is that it's essentially a separate
> > entry point for suspend/resume implementation, and not a particularly
> > well designed one at that.  Things which depend on freezer for PM ops
> > would need completely separate paths for runtime PM.  They probably
> > need some deviations anyway but freezer would push it unnecessarily.
> 
> Maybe it's the other way around: The separate paths are necessary, and 
> the freezer _simplifies_ the system sleep ops.

Again, the point is it's too big a tool given the problem with history
of abuse.  It sure is "convenient" to have tools at that level for
that particular user - not because the task at hand fits such solution
but because a lot more is being paid elsewhere.  It just is out of
proportion and isn't a good design in larger sense.

As for autopm vs. system pm, there sure are necessary differences
between the two but they also can share a lot.  At least, it looks
that way from libata side.  I really don't think having two separate
paradigms in implementing PM is a good idea even if the two paths have
to deviate in significant ways.

> Taking khubd as an example, I have to agree that converting it to a
> workqueue would be a big simplification overall.  And yet there are
> some things khubd does which are (as far as I know) rather difficult to
> accomplish with workqueues.  One example in drivers/usb/core/hub.c:  
> kick_khubd() calls usb_autopm_get_interface_no_resume() if and only if
> it added the hub to the event list (and it does so before releasing the
> list's lock).  How can you do that with a workqueue?

Do the same thing and just replace wake_up() with queue_work()?

Thanks.

-- 
tejun
--
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/