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-next>] [day] [month] [year] [list]
Date:	Fri, 9 Oct 2015 10:52:52 +0900
From:	Hiraku Toyooka <hiraku.toyooka.gu@...achi.com>
To:	<tony.luck@...el.com>, <keescook@...omium.org>, <anton@...msg.org>,
	<salyzyn@...roid.com>, <ccross@...roid.com>,
	<seiji.aguchi.tr@...achi.com>, LKML <linux-kernel@...r.kernel.org>
Subject: [RFD] pstore: pmsg: ramoops: add multiple pmsg instances

Hello,

I'm trying to make the feature of multiple pmsg instances for ramoops.
I would like to discuss a possible way of getting the feature added to
mainline.

The reason to add the multiple pmsg is to preserve particular
messages over a long time, which are useful for failure analysis.

Currently, we can use /dev/pmsg0 to log userspace messages into pstore.
It is useful but we can use only one pstore buffer even if pstore
backend module (e.g. ramoops) can create multiple buffers. When one
messages happen to be generated repeatedly, old messages are
overwritten by them regardless of the importance of the messages.

Multiple pmsg will solves the problem. If we have two pmsg files:
/dev/pmsg{0,1}, we can write all messages into /dev/pmsg0, while
writing important ones into /dev/pmsg1. It can also be used for
preserving important kernel messages selected by an userspace daemon.

We have two types of files for pmsg. /dev/pmsg0 is for logging and
/sys/fs/pstore/pmsg-$backend-0 is for read. We can extend these files
like pmsg{0,1,2,...}, pmsg-$backend-{0,1,2,...}.

To realize this /dev/pmsgN interface, pstore backend modules which
manage multiple buffers for pmsg should tell the necessary numbers of
buffer to pstore_register_pmsg() via pstore_info. In addition, for
ramoops, I think the following works for ram.c are necessary at least.

* Parse multiple pmsg size in module parameter, for example,
  pmsg_size=0x2000,0x1000,...

* Change pmsg_size in ramoops_platform_data to a pointer of size
  array.

 struct ramoops_platform_data {
        ...
-	unsigned long	pmsg_size;
+	unsigned long	*pmsg_size;
        ...
 };

  When a ramoops's backend driver registers the platform_data and want
  pmsg buffers, it should allocate an array of size for pmsg_size.
  (Although there is no ramoops's backend which uses pmsg currently)

* Give an ID for each pmsg buffer, and modify some functions related to
  buffer allocation.

What do you think about this idea?

Best regards,
Hiraku Toyooka


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