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:	Tue, 28 Apr 2015 21:41:40 +0900
From:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
To:	minyard@....org
CC:	openipmi-developer@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipmi: Fix a problem that messages are not issued in run_to_completion
 mode

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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ