Message-ID: <20111101065958.50addab5@tlielax.poochiereds.net>
Date:	Tue, 1 Nov 2011 06:59:58 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Steve French <sfrench@...ba.org>, linux-kernel@...r.kernel.org,
	Oleg Nesterov <oleg@...hat.com>, linux-pm@...r.kernel.org,
	linux-cifs@...r.kernel.org,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Neil Brown <neilb@...e.de>, trond.myklebust@...app.com,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make
 fake_signal_wake_up() wake TASK_KILLABLE tasks too"

On Tue, 1 Nov 2011 04:13:37 -0400
Jeff Layton <jlayton@...hat.com> wrote:

> On Mon, 31 Oct 2011 17:55:05 -0700
> Tejun Heo <tj@...nel.org> 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@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists