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, 22 Mar 2011 10:42:45 +0200
From:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
To:	"ext Luck, Tony" <tony.luck@...el.com>
Cc:	linux-kernel@...r.kernel.org, Seiji Aguchi <seiji.aguchi@....com>,
	David Woodhouse <dwmw2@...radead.org>,
	Marco Stornelli <marco.stornelli@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] pstore: Don't use persistent store for normal shutdown

On Mon, 2011-03-21 at 11:24 -0700, ext Luck, Tony wrote:
> In commit 04c6862c055fb687c90d9652f32c11a063df15cf
> kmsg_dump: add kmsg_dump() calls to the reboot, halt, poweroff and emergency_restart paths
> 
> Seiji Aguchi added kmsg_dump options for all the "normal" ways
> that a system can be shut down (KEXEC, RESTART, HALT and POWEROFF).
> It doesn't seem useful to save the kernel log to persistent store
> in these cases.
> 
> Signed-off-by: Tony Luck <tony.luck@...el.com>
> 
> ---
> 
> My /dev/pstore changes have been merged - and I immediately noticed that they
> now save a record on every shutdown.  Some simple detective work with git found
> that kmsg_dump now has some new "reasons" for calling its subscribers.
> 
> This patch excludes the four "normal shutdown" cases from being logged
> to persistent store, on the assumption that we don't want to clutter up
> a limited amount of storage space with routine data.  My presumption is
> that there is some other subscriber to kmsg_dump that is doing something
> with these reason codes ... is that right?  Or do you think that we should
> save the tail of kernel log into persistent store for every shutdown?
> 
> Perhaps we could save less data for these new reasons? Other ideas?

If you ask me, this smells like policy in the kernel. I'd look into the
direction of having only the mechanisms in the kernel and letting the
user-space making policy decisions by choosing what he wants to filter
out and what he wants to store via some pstore interfaces.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

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