linux-kernel - Re: [patch 3/3] clockevents: Fix resume logic

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]

Date:	Tue, 15 May 2007 16:52:46 +0000
From:	Pavel Machek <pavel@....cz>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	tglx@...utronix.de, "Rafael J. Wysocki" <rjw@...k.pl>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <johnstul@...ibm.com>, linux-acpi@...r.kernel.org
Subject: Re: [patch 3/3] clockevents: Fix resume logic - updated version

Hi!

> > > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > > return statement.  Any theories there?
> > 
> > Only stack or memory corruption come into mind, but I have no clue how
> > this is related to the resume logic changes.
> 
> So I had the brilliant idea of turning on some kernel debugging.  It's
> a shame that CONFIG_SOFTWARE_SUSPEND disables CONFIG_DEBUG_PAGEALLOC.

We now switch to separate page tables for hibernation, IIRC, so we may
be able to get DEBUG_PAGEALLOC to work. I'll take a look.

> [   73.533454] swsusp: Basic memory bitmaps created
> [   73.550429] Stopping tasks ... BUG: at kernel/lockdep.c:2414 check_flags()
> [   73.550988]  [<c0104c14>] show_trace_log_lvl+0x1a/0x30
> [   73.551143]  [<c0105769>] show_trace+0x12/0x14
> [   73.551279]  [<c01057c1>] dump_stack+0x15/0x17
> [   73.551412]  [<c0132732>] check_flags+0x93/0x13d
> [   73.551554]  [<c0135558>] lock_acquire+0x28/0x7f
> [   73.551691]  [<c0310e35>] _spin_lock+0x2b/0x38
> [   73.551827]  [<c013dc43>] refrigerator+0x16/0xc7
> [   73.551965]  [<c0125d2e>] get_signal_to_deliver+0x32/0x387
> [   73.552124]  [<c010336d>] do_notify_resume+0x91/0x6a9
> [   73.552271]  [<c0103df1>] work_notifysig+0x13/0x1a
> [   73.552413]  =======================
> [   73.552507] irq event stamp: 3075
> [   73.552595] hardirqs last  enabled at (3075): [<c0103e51>] syscall_exit_work+0x11/0x26
> [   73.552821] hardirqs last disabled at (3074): [<c0103d35>] syscall_exit+0x9/0x1a
> [   73.553046] softirqs last  enabled at (2778): [<c01209f2>] __do_softirq+0x92/0x9a
> [   73.553255] softirqs last disabled at (2693): [<c0120a27>] do_softirq+0x2d/0x46
> [   73.559504] done.
> [   73.559569] Shrinking memory...  .-.done (0 pages freed)
> [   73.646511] Freed 0 kbytes in 0.08 seconds (0.00 MB/s)
> [   73.649595] platform sonypi: freeze
> [   73.649707] platform bluetooth: freeze
> [   73.649817] usb_endpoint usbdev5.1_ep81: PM: suspend 0->1, parent 5-0:1.0 already 2
> [   73.650023] hub 5-0:1.0: PM: suspend 2-->1
> 
> <snippage>
> 
> [   73.739499] ipw2200 0000:06:0b.0: freeze
> [   73.743860] eth1: Going into suspend...
> [   73.748444] e100 0000:06:08.0: freeze
> 
> at this point I lost netconsole (earlier testing was without netconsole
> btw)

Commenting out e100's suspend routine might do the trick.

> void refrigerator(void)
> {
> 	/* Hmm, should we be allowed to suspend when there are realtime
> 	   processes around? */
> 	long save;
> 
> -->	task_lock(current);
> 	if (freezing(current)) {
> 		frozen_process();
> 		task_unlock(current);
> 	} else {
> 
> 
> I don't really know what lockdep is complaining about there.  I assume I'm
> not supposed to, given that whoever wrote that couldn't be bothered
> documenting any of it.

> I _think_ it means that lockdep believes that local irqs are enabled
> (according to its state tracking), only it turns out that they're not.


Huh, running refrigerator with interrupts disabled? I do not think we
are doing _that_.

							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/