linux-kernel - Re: kdump regression compared to v2.6.35

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, 30 Aug 2010 16:21:02 +0200
From:	Tejun Heo <tj@...nel.org>
To:	CAI Qian <caiqian@...hat.com>
CC:	kexec <kexec@...ts.infradead.org>, linux-next@...r.kernel.org,
	torvalds@...ux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: kdump regression compared to v2.6.35

Hello,

On 08/30/2010 04:02 PM, CAI Qian wrote:
>> Hmm, odd.  So, here's the said debug patch.  It will periodically
>> check all works and report if any work is being delayed for too long.
>> If the max wait goes over 30secs, it will dump all task states and
>> disable itself.  Can you please apply the patch on top of rc2 +
>> wq#for-linus and report the output?  It should tell us who's stuck
>> where.
>
> Nothing new was printed after around 10 minutes.

Eh... that's interesting.  That means no work is stalled on
workqueues, so it at least is not a workqueue stall.  Can you please
try the following then?  Or if sysrq wasn't working because your
keyboard wasn't initialized at that point, you can setup serial
console and trigger sysrq that way.

Thanks.

diff --git a/init/main.c b/init/main.c
index 94ab488..e156b8f 100644
--- a/init/main.c
+++ b/init/main.c
@@ -423,11 +423,19 @@ static void __init setup_command_line(char *command_line)

 static __initdata DECLARE_COMPLETION(kthreadd_done);

+static void show_state_timer_fn(unsigned long data)
+{
+	show_state();
+}
+static DEFINE_TIMER(show_state_timer, show_state_timer_fn, 0, 0);
+
 static noinline void __init_refok rest_init(void)
 	__releases(kernel_lock)
 {
 	int pid;

+	printk("XXX show_state_timer registered\n");
+	mod_timer(&show_state_timer, jiffies + 180 * HZ);
 	rcu_scheduler_starting();
 	/*
 	 * We need to spawn init first so that it obtains pid 1, however
--
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/