linux-kernel - Suspend-to-ram not working when ftrace is enabled, again!

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

Message-ID: <4F6754DA.6090401@linux.vnet.ibm.com>
Date:	Mon, 19 Mar 2012 21:16:34 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	"mingo@...e.hu" <mingo@...e.hu>, "pavel@....cz" <pavel@....cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Suspend-to-ram not working when ftrace is enabled, again!

Hi,

If tracing is enabled and we are tracing low-level suspend-to-ram related
functions like restore_processor_state() etc (which are included by default
in the list of traced functions), and we try suspending the machine, the
machine doesn't resume. It reboots instead.
(If we trace some unrelated functions like kzalloc() for example, there is
no problem with suspend/resume).

Looking at https://lkml.org/lkml/2008/8/27/177, it appears that this
is an old problem and also had a workaround (disabling tracing around
suspend). The above patch corresponds to commit id: f42ac38c59 (ftrace:
disable tracing for suspend to ram), which went in around 2.6.27 I think.
But then commit cbe2f5a6e84 (tracing: allow tracing of suspend/resume &
hibernation code again) reverted that commit.

And from https://lkml.org/lkml/2008/8/21/349, it looks like 2.6.28 and
further was supposed to be problem-free. But unfortunately this problem has
resurfaced.

I tested kernel 2.6.32.54 and I observed that the machine reboots during
resume, which looks exactly like the problem discussed in the link above.

In another machine, I tested 3.3-rc6 and it doesn't seem to respond to
resume events (like button press, lid open) at all. It just seems to remain
suspended forever.

Should we resort to disabling ftrace around suspend again? Or do we have a
better solution this time around?

Regards,
Srivatsa S. Bhat

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