system_nrt_wq, system suspend, and the freezer

[Alan Stern]

On Thu, 16 Feb 2012, Tejun Heo wrote:

> Hello,
> 
> On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
> > Um.  I don't think I can audit all the calls in the kernel that submit
> > block requests and determine which ones need to be allowed while a
> > system sleep is in progress.
> 
> ??? we need to do that anyway and the ones which should go through are
> much smaller than the ones which shouldn't go through.

Agreed.  I'm just saying that it's too big a job for me to handle by
myself.  And all the marking has to be done before you plug the
unmarked requests; otherwise you could break hibernation.


> > Well, there are some dedicated threads that exist for no other purpose
> > than to do I/O to devices and to handle hotplug/unplug events.  I don't
> > see any reason not allow such threads to be freezable.  It's a quick, 
> > convenient method for getting them out of the way.
> 
> Well, it's convenient to use incorrectly.  If you look at most of
> freezable kthreads, they're sadly broken.  I mean, a lot of kthread
> users don't even get kthread_should_stop() right.  With freezable()
> thrown into the mix, it seems hopeless.  With wq, it's better as
> freezing is handled by wq proper.  Even then, I don't know.  It just
> seems to lead people to think "ooh, I marked it freezable so I don't
> have to think about synchronization across PM events.  Freezer will
> magically solve this for me!".  :(

Certainly there are issues which need to be considered carefully.  That 
doesn't mean it should never be used.

Alan Stern