Message-ID: <553F8004.8020408@hitachi.com>
Date: Tue, 28 Apr 2015 21:41:40 +0900
From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0
MIME-Version: 1.0
To: minyard@acm.org
CC: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ipmi: Fix a problem that messages are not issued in run_to_completion
 mode
References: <5538560C.1040502@hitachi.com> <553A3E7D.6040207@acm.org>
In-Reply-To: <553A3E7D.6040207@acm.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1185
Lines: 33

Hello,

(2015/04/24 22:00), Corey Minyard wrote:
> Ah, yes, you are correct.  Queued for 4.1.  Thanks.

Thank you for the review.

By the way, I'm planning some enhancements of IPMI driver
in panic context.  Currently, we can call panic notifiers
before crash_kexec() by specifying crash_kexec_post_notifiers
as a boot parameter.  By utilizing this feature, we can write
SEL records before entering kdump process; we can save some
information even if kdump fails.  Here, notifier calls
shouldn't prevent the kdump process.  So, the reliability of
panic notifier calls is very important.

I noticed that there are possible infinite loops in the
panic notifier call of IPMI driver (we assume BMC is
unreliable).  To evict possible infinite loops, I'm considering
introducing some retry timeout or retry count limit to the
run_to_completion procedure.

Do you have any opinions?

-- 
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/