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: <987664A83D2D224EAE907B061CE93D5301EE421365@orsmsx505.amr.corp.intel.com>
Date:	Tue, 27 Sep 2011 12:02:38 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Don Zickus <dzickus@...hat.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

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

Yes we care - saving panic data is most likely the single most important
thing that pstore does.  I just have severe doubts that it will actually
save anything useful if we just blindly continue if we can't get the lock.

What actually happens next will be dependent on the back-end. For
the state machine in ERST, one possible outcome is a hang. For many
people a hang is considered worse than a panic.

> 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?

I really have no idea what *will* happen.  Lots of things are possible, only
some of them are desirable.

Is this patch based on a real-life case of a system deadlocking? I'd
like to know if we are just talking around the theoretical case that
the lock may be held at panic time - or something that has actually been
seen in real life.

-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ