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: <3908561D78D1C84285E8C5FCA982C28F19D4404F@ORSMSX108.amr.corp.intel.com>
Date:	Mon, 24 Sep 2012 15:02:35 +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

> And my plan was to get rid of the fact that backends touch pstore->buf
> directly. Backends would always receive anonymous 'buf' pointer (we
> already have write_buf callback that does exactly this), and thus it

It feels like we are just shuffling the lock problem from one place
to another.  In the panic case we have to use a pre-allocated buffer
(hoping that we can allocate one seems to be a foolish plan). So
we'd need a lock around use of that buffer somewhere - whether
it is in the panic code, the pstore generic code, or the back-end
driver.

Can you describe where you'd like to end up?

-Tony