On Monday, October 31, 2011, Tejun Heo wrote: > Commit 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake > TASK_KILLABLE tasks too" made freezer wake up tasks in TASK_KILLABLE > sleep too citing non-interruptible but killable sleeps in cifs and > nfs. > > I don't think we can do this. We should not send spurious unsolicited > non-interruptible wakeups. Most synchornization constructs are built > to cope with spurious wakeups and any INTERRUPTIBLE sleep must be able > to handle spurious wakeups but that's not true for KILLABLE sleeps - > KILLABLE condition cannot be cancelled. > > This is probably okay for most cases but circumventing fundamental > wakeup condition like this is asking for trouble. Furthermore, I'm > not sure the behavior change brought on by this change - breaking > nfs/cifs uninterruptible operation guarantee - is correct. If such > behavior is desirable, the right thing to do is using intr mount > option, not circumventing it from PM layer. Do you have any specific examples of breakage, or is it just that you _think_ it's not quite right? One patch depending on that change has been merged already and I have two more in the queue, so I'd like to clarify this ASAP. Jeff, Steve? > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> > Cc: Jeff Layton <jlayton@xxxxxxxxxx> > --- > Neil, Steve, do the network filesystems need a way to indicate "I can > either be killed or enter freezer"? > > Thanks. > > kernel/freezer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/freezer.c b/kernel/freezer.c > index 66a594e..7b01de9 100644 > --- a/kernel/freezer.c > +++ b/kernel/freezer.c > @@ -67,7 +67,7 @@ static void fake_signal_wake_up(struct task_struct *p) > unsigned long flags; > > spin_lock_irqsave(&p->sighand->siglock, flags); > - signal_wake_up(p, 1); > + signal_wake_up(p, 0); > spin_unlock_irqrestore(&p->sighand->siglock, flags); > } Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
