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. > > Also, in general, I don't think using freezing widely for kernel > > threads / wqs is a good idea. Plugging device access at subsystem > > layer should cover most cases and we have notifiers to implement such > > support and to handle special cases. There are even code paths which > > try to determine whether system went through PM operation by looking > > at whether %current went through the freezer. IMHO, we'll be better > > off with removing freezer support for kthreads. :( > > 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!". :( Thanks. -- tejun _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
