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

Date:	Tue, 23 Jul 2013 13:31:49 -0700
From:	Colin Cross <ccross@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michael Leun <lkml20130126@...ton.leun.net>,
	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 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?

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().

Download attachment "0001-power-set-PF_SUSPEND_TASK-flag-on-tasks-that-call-fr.patch" of type "application/octet-stream" (4006 bytes)