linux-kernel - Re: [RFC][PATCH -next] pstore: replace spin_lock with spin_trylock

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, 27 Sep 2011 13:59:19 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Seiji Aguchi <seiji.aguchi@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	Matthew Garrett <mjg@...hat.com>,
	"Chen, Gong" <gong.chen@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: Re: [RFC][PATCH -next] pstore: replace spin_lock with
 spin_trylock_irqsave in panic path

On Tue, Sep 27, 2011 at 10:46:32AM -0700, Luck, Tony wrote:
> > Personally, I am not sure we want to abort here at the pstore layer, it
> > should probably be aborted lower.  There isn't any reason why we can't
> > continue from a pstore perspective (we can just bust the spinlock).
> 
> But do we really have much chance at getting a real dump in this case?
> The pstore buf_lock is protecting the memory that the backend uses to
> save the data. If we can't get the lock, then we are going to conflict
> using that buffer with whoever does have the lock. So we will probably
> mess up whatever data they were trying to save, as well as not managing

Ok.  Do we care?  I assumed the panic data would be more
relevant/interesting than whatever pstore was doing before (like loading
previous log files).

> to save our panic data. So this isn't just a back-end issue, it is

I assumed we are just overwriting the buffer with the current data, so
unless the other cpu is chugging along while this cpu is in panic, the new
data shouldn't get corrupted, no?

Cheers,
Don

> fundamental to the pstore layer (since it depends on this back end buffer).
> 
> This is a tough call - but I'm leaning a bit towards taking this patch.
> 
> I agree with your suggestion that we need a better comment by the "return"
> (and also in the change log) saying why we are not saving the panic dmesg.
> 
> -Tony 
--
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/