linux-kernel - Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake TASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Oct 2011 16:53:35 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Steve French <smfrench@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeff Layton <jlayton@...hat.com>,
	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>
Subject: Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make
 fake_signal_wake_up() wake TASK_KILLABLE tasks too"

Hello,

On Mon, Oct 31, 2011 at 06:45:48PM -0500, Steve French wrote:
> >> Signed-off-by: Tejun Heo <tj@...nel.org>
> >> Cc: Jeff Layton <jlayton@...hat.com>
> >> ---
> >> Neil, Steve, do the network filesystems need a way to indicate "I can
> >> either be killed or enter freezer"?
> 
> Probably, yes, but I will defer to Jeff as he has looked
> more recently at these issues.
> 
> I can explain cifs state, and disconnect/reconnection of sessions
> (and smb2 is a little more feature rich in this regard), but will
> let Jeff explain the more subtle points you are getting at.

Hmmm... I'm getting confused.

For nfs, this really is a non-issue.  Either the user wants nointr or
intr behavior.  NFS nointr is rather crazy - it's basically "nothing
can do anything to tasks which is doing NFS IO until it's complete"
and really meant to be used for servers sharing filesystems for /usr,
/home and stuff.  It doesn't make whole lot of sense on systems which
may go suspend and that's why there's intr option.

I suppose the problem is that cifs doesn't know how to do 'intr' yet,
right?  If that really is the problem, the correct long term solution
would be implementing proper intr behavior and it doesn't make any
sense to push this type of change to PM core to for short term
workaround.  Just use prepare_to_wait() / schedule() / finish_wait()
directly w/ INTERRUPTIBLE sleep and don't break out of wait loop on
signal_pending().  If this should be used in multiple places, write up
a wait_event_XXX() wrapper.  There is absolutely no reason to change
wakeup condition.

Thank you.

-- 
tejun
--
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/