On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:Well, this was acutally invented before you've decided to remove the freezing of tasks from the suspend code path (which I think is a mistake, but that's only my personal opinion, so it doesn't matter very much ;-)) and I regard it as a workaround. Under the (optimistic, IMO) assumption that the relevant user space task won't block on I/O with a suspended device involved or something like this. BTW, I know of two subsystems that want their kernel threads to be frozen for synchronization purposes. Please see these messages: 1) https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012592.html (plus follow up) 2) http://marc.info/?l=linux-kernel&m=117919066830575&w=2 Your patch breaks them and I suspect there are more cases like these. Besides, there's the hibernation that needs to freeze tasks for another reason, so it needs some way to ensure that drivers won't request firmware while the user land is frozen. Yes, I think we should do this. Greetings, Rafael -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 33/37] dccp: Initialisation framework for feature negotiation |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
