linux-kernel - RE: [PATCH] pstore: avoid recursive spinlocks in the oops_in

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]

Message-ID: <3908561D78D1C84285E8C5FCA982C28F19D43892@ORSMSX108.amr.corp.intel.com>
Date:	Thu, 20 Sep 2012 23:48:32 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
CC:	"Liu, Chuansheng" <chuansheng.liu@...el.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Colin Cross <ccross@...roid.com>
Subject: RE: [PATCH] pstore: avoid recursive spinlocks in the
 oops_in_progress case

> True, but the lock is used to protect pstore->buf, I doubt that
> any backend will actually want to grab it, no?

The lock is doing double duty to protect the buffer, and the back-end driver.

But even if we split it into two (one for the buffer, taken by pstore, and one
internal to the backend to protect interaction with the f/w). Ifwe ignore the
fact that we can't get the lock that protects  the buffer means it is very likely
that we corrupt the previous record that was being written by clobbering the
buffer with the data for this new record.

I'd prefer to maximize the chances that the earlier record gets written.

-Tony