[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2C09821A9E@USINDEVS01.corp.hds.com>
Date: Fri, 17 Sep 2010 11:08:48 -0400
From: Seiji Aguchi <seiji.aguchi@....com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>,
"simon.kagstrom@...insight.net" <simon.kagstrom@...insight.net>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Satoru Moriya <satoru.moriya@....com>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>
Subject: RE: [PATCH] Fix kexec abort due to IPI from panic().
Hi Eric,
Thank you for your quick response!
>Disabling interrupts is fine,
Thanks!
>However that call to kmsg_dump(KMSG_DUMP_KEXEC) is a bug as it introduces locks
>into a path that should not be taking locks.
I'd like to find a way that kexec coexists with kmsg_dump(KMSG_DUMP_KEXEC) because
kmsg_dump is a useful troubleshooting feature as well.
So, I will improve kmsg_dump(KMSG_DUMP_KEXEC) if there are some bugs.
Could you please let me know your concern?
It is helpful for me if you have an example scenario kexec fails.
>Nothing in the crash_kexec path should even have the option of blocking.
Do you mean I need to change kmsg_dump(KMSG_DUMP_KEXEC) to lockless?
Seiji
--
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/
Powered by blists - more mailing lists