On Tue, 1 Nov 2011 04:13:37 -0400 Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 31 Oct 2011 17:55:05 -0700 > Tejun Heo <tj@xxxxxxxxxx> wrote: > > > Hey, again. > > > > On Mon, Oct 31, 2011 at 04:30:59PM -0700, Tejun Heo wrote: > > > I can't remember one off the top of my head but I'm pretty sure there > > > at least are few which expect tight inter-locking between sleeps and > > > wakeups. I'll look for examples and post reply. ISTR them being > > > kernel threads so this might not apply directly but it's still a > > > dangerous game to play. > > > > Hmm... I couldn't find KILLABLE used like that but here are two > > UNINTERRUPTIBLE sleep examples. > > > > * kthread_start() depends on the fact that a kthread won't be woken up > > from UNINTERRUPTIBLE sleep spuriously. > > > > * jfs_flush_journal() doesn't check whether the wakeup was spurious > > after waiting if !tblkGC_COMMITTED. > > > > Maybe we can re-define KILLABLE as killable && freezable but IMHO that > > requires pretty strong rationales. If at all possible, let's not > > diddle with that if it can be worked around some other way. > > > > Thank you. > > > > (cc'ing Trond and the linux-nfs mailing list -- fwiw, he maintains the > NFS client code -- Bruce is the NFS server maintainer and probably has > little interest in this thread). > > The main reason for this change is primarily that we have people with > laptops and nfs and cifs mounts that sometimes fail to suspend. > > IIUC, the TASK_KILLABLE was mostly added to ensure that file-store > writes would be uninterruptible, but still allow those tasks to be > killed if the process is going down anyway. > > The intr/nointr mount options in NFS have been deprecated since > TASK_KILLABLE was added. The scheme now is basically that those sleeps > ignore any signals except for fatal ones. So, that knob is meaningless > and has been for a long time now. > > cifs never had a working intr/nointr knob, but signal handling while > waiting for replies was always a difficult thing to handle correctly. I > don't think the right answer is to go back to using such a knob in cifs > or nfs. > > I suppose we could look at going back to the world of complicated > signal handling and TASK_INTERRUPTIBLE, but that's not a trivial change > either. The TASK_WAKE_FREEZABLE flag you mention might make more sense > than doing that. > Also, since task state and signal handling clearly isn't my forte...can you clarify what the main difference is in using a TASK_KILLABLE sleep vs. TASK_INTERRUPTIBLE with all signals but SIGKILL blocked? I know that the process state would end up different (S vs. D state). Is there anything else we'd need to be concerned with if we converted all these call sites to use such a scheme in lieu of a new TASK_WAKE_FREEZABLE flag or similar? -- 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
