On Tue, 11 Oct 2011 21:14:28 +0200 "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > On Tuesday, October 11, 2011, Jeff Layton wrote: > > On Tue, 11 Oct 2011 08:18:48 +0200 > > Pavel Machek <pavel@xxxxxx> wrote: > > > > > > > > Hi! > > > > > > > TASK_KILLABLE is often used to put tasks to sleep for quite some time. > > > > One of the most common uses is to put tasks to sleep while waiting for > > > > replies from a server on a networked filesystem (such as CIFS or NFS). > > > > > > > > Unfortunately, fake_signal_wake_up does not currently wake up tasks > > > > that are sleeping in TASK_KILLABLE state. This means that even if the > > > > code were in place to allow them to freeze while in this sleep, it > > > > wouldn't work anyway. > > > > > > > > This patch changes this function to wake tasks in this state as well. > > > > This should be harmless -- if the code doing the sleeping doesn't have > > > > handling to deal with freezer events, it should just go back to sleep. > > > > > > I'm pretty sure this will break something; but that does not mean it > > > is bad idea, just that it should be merged early and tested a lot. > > > > > > > FWIW, I looked at most of the places in the kernel that do > > TASK_KILLABLE sleeps and they look like they'll handle this correctly. > > The main one I wasn't sure about was mem_cgroup_handle_oom(), but I > > think it'll do the right thing too. I certainly could have missed > > something though... > > > > In any case, would you mind merging this via the linux-pm tree for 3.2? > > I will push it for 3.2. > Hi Rafael, Trond asked if you would also be willing to push patches 3 and 4 in this series for 3.2 as well [1]? Note that patch #4 got another revision so we'll want to make sure that you get that one. I can resend the nfs/sunrpc patches if that will help... [1]: I think Steve F is going to push patch #2, so that one shouldn't be an issue. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
