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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 2 Dec 2010 10:45:26 -0800
From:	Tony Luck <>
To:	Andrew Morton <>
Cc:	"" <>,
	"" <>,
	"" <>,
	"" <>, "" <>,
	"Huang, Ying" <>,
	Borislav Petkov <>,
	David Miller <>,
	Alan Cox <>,
	Jim Keniston <>,
	Kyungmin Park <>,
	Geert Uytterhoeven <>
Subject: Re: [RFC] persistent store (version 2) (part 1 of 2)

On Thu, Dec 2, 2010 at 8:19 AM, Tony Luck <> wrote:
> was being used? But even then, the user interface wouldn't change
> we could just have each device register a string to be included in
> the filename. Users could look at it if they cared, or ignore it if
> they don't care. The "type" of the data should stay at the front
> of the name so userspace can do "for f in dmesg*" to look at
> al the saved console logs, and it wouldn't matter if the files were
> "dmesg-0", "dmesg-1" or "dmesg-erst-0", "dmesg-erst-1". I
> can't quite see why anyone would care which device was used,
> but the option to provide it would be there without breaking
> apps that used the v1 interface.

Hmmm I may throw the devicename into the filename anyway ... I
still can't see why anyone would care where it came from, but doing
this would allow for consistent filenames across reboots.  My old
code just stuck sequential numbers on the end of the filenames to
make sure it didn't get collisions.  But this means that someone
might be looking at /dev/pstore/dmesg-1 when the system panics.
After the reboot they see two files: the old one and a new one. But
the old code didn't guarantee that the old one would still be "dmesg-1",
it might be "dmesg-2" and "dmesg-1" might now have the latest panic
(ordering is at the whim of the underlying storage, and if it operates in
a LIFO way this could happen).

If I name the file "dmesg-{storename}-{recordid}" then unerased
entries will get the same name next time - which may avoid some

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists