On Fri 2015-10-30 11:29:08, Alan Stern wrote:
> On Fri, 30 Oct 2015, Jiri Kosina wrote:
>
> > This series is a followup to my proposal I brought up on Kernel Summit in
> > Seoul. Noone seemed to had any principal objections, so let's have wider
> > audience look into it.
> >
> > In a nuthsell: freezing of kernel threads is horrible interface with
> > unclear semantics and guarantees, and I am surprised it ever worked
> > properly. Plus there are a lot of places that simply use it in a
> > completely wrong way (which is not suprising, given the lack of defined
> > semantics and requirements).
> >
> > I've tested this over a series of suspend/resume cycles on several
> > machines with at least ext4, btrfs and xfs, and it survived the testing
> > without any harm.
> >
> > Patch 1/3 implements the actual change, and has a more detailed
> > explanation on "why?" and "how?" questions in the changelog
>
> This patch talks about freezing in relation to hibernation. What about
> other forms of suspend?
>
> Also, it replaces kthread freezing with filesystem freezing. What
> about kthreads performing I/O that doesn't go through a filesystem?
> You write:
>
> > the only facility that is needed during suspend: "no persistent fs
> > changes are allowed from now on"
>
> I would say instead "no I/O is allowed from now on". Maybe that's an
> overstatement, but I think it comes closer to the truth.
Exactly. And I'm pretty sure hardware drivers do use kernel threads,
and do I/O from them.
LEDs are just one example
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
