[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F3284BBB1@ORSMSX114.amr.corp.intel.com>
Date: Fri, 27 Jun 2014 20:43:14 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>, Xie XiuQi <xiexiuqi@...wei.com>
CC: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
"Chen, Gong" <gong.chen@...ux.intel.com>,
"joe@...ches.com" <joe@...ches.com>,
"m.chehab@...sung.com" <m.chehab@...sung.com>,
"arozansk@...hat.com" <arozansk@...hat.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Li Bin <huawei.libin@...wei.com>
Subject: RE: [PATCH v3 4/9] ACPI, x86: Extended error log driver for x86
platform
>> There's a logbuf_lock in printk. If logbuf_lock is held by other cpu,
>> it'll lead to an infinity spin here. Isn't it?
>
> Yes, but we want to take the risk and print something out before the
> machine dies instead of waiting to get into printk-safe context first
> and maybe corrupt state.
Not all machine checks are fatal - it would be bad for us to go into an
infinite spin instead of executing the recovery code.
> Besides, there's work currently going on to make printk safe in atomic
> context so...
Good - we need this.
-Tony
Powered by blists - more mailing lists