linux-kernel - Re: 3.11-rc regression bisected: s2disk does not work (was Re: [PATCH v3 13/16] futex: use freezable blocking call)

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] [day] [month] [year] [list]

Message-ID: <20130723235827.014f7899@xenia.leun.net>
Date:	Tue, 23 Jul 2013 23:58:27 +0200
From:	Michael Leun <lkml20130126@...ton.leun.net>
To:	Colin Cross <ccross@...roid.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mandeep Singh Baines <msb@...omium.org>,
	Oleg Nesterov <oleg@...hat.com>,
	linux-nfs <linux-nfs@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>, Tejun Heo <tj@...nel.org>,
	Darren Hart <dvhart@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Randy Dunlap <rdunlap@...radead.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: 3.11-rc regression bisected: s2disk does not work (was Re:
 [PATCH v3 13/16] futex: use freezable blocking call)

On Tue, 23 Jul 2013 13:31:49 -0700
Colin Cross <ccross@...roid.com> wrote:

> On Mon, Jul 22, 2013 at 11:28 PM, Colin Cross <ccross@...roid.com>
> wrote:
> > On Mon, Jul 22, 2013 at 6:41 PM, Rafael J. Wysocki <rjw@...k.pl>
> > wrote:
> >> On Monday, July 22, 2013 05:42:49 PM Colin Cross wrote:
> >>> On Mon, Jul 22, 2013 at 5:32 PM, Linus Torvalds
> >>> <torvalds@...ux-foundation.org> wrote:
> >>> > On Mon, Jul 22, 2013 at 4:55 PM, Colin Cross
> >>> > <ccross@...roid.com> wrote:
> >>> >>
> >>> >> I think the right solution is to add a flag to the freezing
> >>> >> task that marks it unfreezable.  I  think PF_NOFREEZE would
> >>> >> work, although it is normally used on kernel threads, can you
> >>> >> see if the attached patch helps?
> >>> >
> >>> > Hmm. That does seem to be the right thing to do, but I wonder
> >>> > about the *other* callers of freeze_processes() IOW, kexec and
> >>> > friends.
> >>> >
> >>> > So maybe we should do this in {freeze|thaw}_processes() itself,
> >>> > and just make the rule be that the caller of freeze_processes()
> >>> > itself is obviously not frozen, and has to be the same one that
> >>> > then thaws things?
> >>> >
> >>> > Colin? Rafael? Comments?
> >>> >
> >>> >                 Linus
> >>>
> >>> I was worried about clearing the flag in thaw_processes().  If a
> >>> kernel thread with PF_NOFREEZE set ever called thaw_processes(),
> >>> which autosleep might do, it would clear the flag.  Or if a
> >>> different thread called freeze_processes() and thaw_processes().
> >>
> >> Is that legitimate?
> >
> > Nothing precludes it today, but I don't see any need for it.  I'll
> > add a comment when I add the flag.
> >
> >>> All the other callers besides the SNAPSHOT_FREEZE ioctl stay in
> >>> the kernel between freeze_processes() and thaw_processes(), which
> >>> makes the fanout of places that could call try_to_freeze() much
> >>> more controllable.
> >>>
> >>> Using a new flag that operates like PF_NOFREEZE but doesn't
> >>> conflict with it, or a nofreeze_depth counter, would also work.
> >>
> >> Well, that would be robust enough.  At least if the purpose of
> >> that new flag is clearly specified, people hopefully won't be
> >> tempted to optimize it away in the future.
> >>
> >> Thanks,
> >> Rafael
> >
> > OK, I'll add a new flag.
> 
> 
> Michael, can you see if this patch works and doesn't throw any
> warnings during suspend or resume?

Tried several times with and without threads = y in suspend.conf, tried
also to produce high load / much processes / high memory usage.

Worked every time, no WARN seen.

> If the extra process flag is considered too precious for this
> (there are only 2 left after this patch) I could get the
> same functionality by having freeze_processes() reject calls
> from a PF_KTHREAD|PF_NOFREEZE thread, and use PF_KTHREAD to
> determine if PF_NOFREEZE should be cleared in thaw_processes().

If another solution is considered please do not hesitate to send me the
patch for another round of check.

-- 
MfG,

Michael Leun

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