linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v5] ramoops: use pstore interface
@ 2012-01-17 23:58 Kees Cook
  2012-01-18 22:06 ` Andrew Morton
  0 siblings, 1 reply; 17+ messages in thread
From: Kees Cook @ 2012-01-17 23:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Tony Luck, Marco Stornelli, Arnd Bergmann, Greg Kroah-Hartman,
	Randy Dunlap, linux-doc, linux-kernel

Instead of using /dev/mem directly and forcing userspace to know (or
extract) where the platform has defined persistent memory, how many
slots it has, the sizes, etc, use the common pstore infrastructure to
handle Oops gathering and extraction. This presents a much easier to
use filesystem-based view to the memory region. This also means that any
other tools that are written to understand pstore will automatically be
able to process ramoops too.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
v5:
 - Rebased.
 - Updated with changes based on feedback from Andrew Morton:
   - Increased changelog verbosity.
   - Dropped needless casts from void *.
   - Clarified ramoops_pstore_write() comments.
v4:
 - Rebased to Linus's tree.
v3:
 - Added more documentation about which memory regions it would be
   used with.
v2:
 - General reworking.
---
 Documentation/ramoops.txt |    8 +-
 drivers/char/Kconfig      |    1 +
 drivers/char/ramoops.c    |  203 ++++++++++++++++++++++++++++++++++----------
 3 files changed, 162 insertions(+), 50 deletions(-)

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 8fb1ba7..a0b9d8e 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
 Sergiu Iordache <sergiu@chromium.org>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
 0. Introduction
 
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with the actual data.
 
 4. Reading the data
 
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 4364303..f166499 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -603,6 +603,7 @@ source "drivers/s390/char/Kconfig"
 config RAMOOPS
 	tristate "Log panic/oops to a RAM buffer"
 	depends on HAS_IOMEM
+	depends on PSTORE
 	default n
 	help
 	  This enables panic and oops messages to be logged to a circular
diff --git a/drivers/char/ramoops.c b/drivers/char/ramoops.c
index 9fec323..5a75d70 100644
--- a/drivers/char/ramoops.c
+++ b/drivers/char/ramoops.c
@@ -2,6 +2,7 @@
  * RAM Oops/Panic logger
  *
  * Copyright (C) 2010 Marco Stornelli <marco.stornelli@gmail.com>
+ * Copyright (C) 2011 Kees Cook <keescook@chromium.org>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -24,7 +25,7 @@
 #include <linux/kernel.h>
 #include <linux/err.h>
 #include <linux/module.h>
-#include <linux/kmsg_dump.h>
+#include <linux/pstore.h>
 #include <linux/time.h>
 #include <linux/err.h>
 #include <linux/io.h>
@@ -56,73 +57,156 @@ module_param(dump_oops, int, 0600);
 MODULE_PARM_DESC(dump_oops,
 		"set to 1 to dump oopses, 0 to only dump panics (default 1)");
 
-static struct ramoops_context {
-	struct kmsg_dumper dump;
+struct ramoops_context {
 	void *virt_addr;
 	phys_addr_t phys_addr;
 	unsigned long size;
-	unsigned long record_size;
+	size_t record_size;
 	int dump_oops;
-	int count;
-	int max_count;
-} oops_cxt;
+	unsigned int count;
+	unsigned int max_count;
+	unsigned int read_count;
+	struct pstore_info pstore;
+};
 
 static struct platform_device *dummy;
 static struct ramoops_platform_data *dummy_data;
 
-static void ramoops_do_dump(struct kmsg_dumper *dumper,
-		enum kmsg_dump_reason reason, const char *s1, unsigned long l1,
-		const char *s2, unsigned long l2)
+static int ramoops_pstore_open(struct pstore_info *psi)
+{
+	struct ramoops_context *cxt = psi->data;
+
+	cxt->read_count = 0;
+	return 0;
+}
+
+static ssize_t ramoops_pstore_read(u64 *id, enum pstore_type_id *type,
+				   struct timespec *time,
+				   char **buf,
+				   struct pstore_info *psi)
 {
-	struct ramoops_context *cxt = container_of(dumper,
-			struct ramoops_context, dump);
-	unsigned long s1_start, s2_start;
-	unsigned long l1_cpy, l2_cpy;
-	int res, hdr_size;
-	char *buf, *buf_orig;
+	ssize_t size;
+	char *rambuf;
+	struct ramoops_context *cxt = psi->data;
+
+	if (cxt->read_count >= cxt->max_count)
+		return -EINVAL;
+	*id = cxt->read_count++;
+	/* Only supports dmesg output so far. */
+	*type = PSTORE_TYPE_DMESG;
+	/* TODO(kees): Bogus time for the moment. */
+	time->tv_sec = 0;
+	time->tv_nsec = 0;
+
+	rambuf = cxt->virt_addr + (*id * cxt->record_size);
+	size = strnlen(rambuf, cxt->record_size);
+	*buf = kmalloc(size, GFP_KERNEL);
+	if (*buf == NULL)
+		return -ENOMEM;
+	memcpy(*buf, rambuf, size);
+
+	return size;
+}
+
+static int ramoops_pstore_write(enum pstore_type_id type,
+				enum kmsg_dump_reason reason,
+				u64 *id,
+				unsigned int part,
+				size_t size, struct pstore_info *psi)
+{
+	char *buf;
+	size_t res;
 	struct timeval timestamp;
+	struct ramoops_context *cxt = psi->data;
+	size_t available = cxt->record_size;
+
+	/* Currently ramoops is designed to only store dmesg dumps. */
+	if (type != PSTORE_TYPE_DMESG)
+		return -EINVAL;
 
+	/* Out of the various dmesg dump types, ramoops is currently designed
+	 * to only store crash logs, rather than storing general kernel logs.
+	 */
 	if (reason != KMSG_DUMP_OOPS &&
 	    reason != KMSG_DUMP_PANIC)
-		return;
+		return -EINVAL;
 
-	/* Only dump oopses if dump_oops is set */
+	/* Skip Oopes when configured to do so. */
 	if (reason == KMSG_DUMP_OOPS && !cxt->dump_oops)
-		return;
+		return -EINVAL;
+
+	/* Explicitly only take the first part of any new crash.
+	 * If our buffer is larger than kmsg_bytes, this can never happen,
+	 * and if our buffer is smaller than kmsg_bytes, we don't want the
+	 * report split across multiple records.
+	 */
+	if (part != 1)
+		return -ENOSPC;
 
 	buf = cxt->virt_addr + (cxt->count * cxt->record_size);
-	buf_orig = buf;
 
-	memset(buf, '\0', cxt->record_size);
 	res = sprintf(buf, "%s", RAMOOPS_KERNMSG_HDR);
 	buf += res;
+	available -= res;
+
 	do_gettimeofday(&timestamp);
 	res = sprintf(buf, "%lu.%lu\n", (long)timestamp.tv_sec, (long)timestamp.tv_usec);
 	buf += res;
+	available -= res;
 
-	hdr_size = buf - buf_orig;
-	l2_cpy = min(l2, cxt->record_size - hdr_size);
-	l1_cpy = min(l1, cxt->record_size - hdr_size - l2_cpy);
+	if (size > available)
+		size = available;
 
-	s2_start = l2 - l2_cpy;
-	s1_start = l1 - l1_cpy;
-
-	memcpy(buf, s1 + s1_start, l1_cpy);
-	memcpy(buf + l1_cpy, s2 + s2_start, l2_cpy);
+	memcpy(buf, cxt->pstore.buf, size);
+	memset(buf + size, '\0', available - size);
 
 	cxt->count = (cxt->count + 1) % cxt->max_count;
+
+	return 0;
+}
+
+static int ramoops_pstore_erase(enum pstore_type_id type, u64 id,
+				struct pstore_info *psi)
+{
+	char *buf;
+	struct ramoops_context *cxt = psi->data;
+
+	if (id >= cxt->max_count)
+		return -EINVAL;
+
+	buf = cxt->virt_addr + (id * cxt->record_size);
+	memset(buf, '\0', cxt->record_size);
+
+	return 0;
 }
 
+static struct ramoops_context oops_cxt = {
+	.pstore = {
+		.owner	= THIS_MODULE,
+		.name	= "ramoops",
+		.open	= ramoops_pstore_open,
+		.read	= ramoops_pstore_read,
+		.write	= ramoops_pstore_write,
+		.erase	= ramoops_pstore_erase,
+	},
+};
+
 static int __init ramoops_probe(struct platform_device *pdev)
 {
 	struct ramoops_platform_data *pdata = pdev->dev.platform_data;
 	struct ramoops_context *cxt = &oops_cxt;
 	int err = -EINVAL;
 
+	/* Only a single ramoops area allowed at a time, so fail extra
+	 * probes.
+	 */
+	if (cxt->max_count)
+		goto fail_out;
+
 	if (!pdata->mem_size || !pdata->record_size) {
 		pr_err("The memory size and the record size must be "
 			"non-zero\n");
-		goto fail3;
+		goto fail_out;
 	}
 
 	pdata->mem_size = rounddown_pow_of_two(pdata->mem_size);
@@ -131,14 +215,15 @@ static int __init ramoops_probe(struct platform_device *pdev)
 	/* Check for the minimum memory size */
 	if (pdata->mem_size < MIN_MEM_SIZE &&
 			pdata->record_size < MIN_MEM_SIZE) {
-		pr_err("memory size too small, minium is %lu\n", MIN_MEM_SIZE);
-		goto fail3;
+		pr_err("memory size too small, minimum is %lu\n",
+			MIN_MEM_SIZE);
+		goto fail_out;
 	}
 
 	if (pdata->mem_size < pdata->record_size) {
 		pr_err("The memory size must be larger than the "
 			"records size\n");
-		goto fail3;
+		goto fail_out;
 	}
 
 	cxt->max_count = pdata->mem_size / pdata->record_size;
@@ -148,23 +233,32 @@ static int __init ramoops_probe(struct platform_device *pdev)
 	cxt->record_size = pdata->record_size;
 	cxt->dump_oops = pdata->dump_oops;
 
+	cxt->pstore.data = cxt;
+	cxt->pstore.bufsize = cxt->record_size;
+	cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
+	spin_lock_init(&cxt->pstore.buf_lock);
+	if (!cxt->pstore.buf) {
+		pr_err("cannot allocate pstore buffer\n");
+		goto fail_clear;
+	}
+
 	if (!request_mem_region(cxt->phys_addr, cxt->size, "ramoops")) {
-		pr_err("request mem region failed\n");
+		pr_err("request mem region (0x%lx@0x%llx) failed\n",
+			cxt->size, cxt->phys_addr);
 		err = -EINVAL;
-		goto fail3;
+		goto fail_buf;
 	}
 
 	cxt->virt_addr = ioremap(cxt->phys_addr,  cxt->size);
 	if (!cxt->virt_addr) {
 		pr_err("ioremap failed\n");
-		goto fail2;
+		goto fail_mem_region;
 	}
 
-	cxt->dump.dump = ramoops_do_dump;
-	err = kmsg_dump_register(&cxt->dump);
+	err = pstore_register(&cxt->pstore);
 	if (err) {
-		pr_err("registering kmsg dumper failed\n");
-		goto fail1;
+		pr_err("registering with pstore failed\n");
+		goto fail_iounmap;
 	}
 
 	/*
@@ -176,26 +270,43 @@ static int __init ramoops_probe(struct platform_device *pdev)
 	record_size = pdata->record_size;
 	dump_oops = pdata->dump_oops;
 
+	pr_info("attached 0x%lx@0x%llx (%ux0x%zx)\n",
+		cxt->size, cxt->phys_addr, cxt->max_count, cxt->record_size);
+
 	return 0;
 
-fail1:
+fail_iounmap:
 	iounmap(cxt->virt_addr);
-fail2:
+fail_mem_region:
 	release_mem_region(cxt->phys_addr, cxt->size);
-fail3:
+fail_buf:
+	kfree(cxt->pstore.buf);
+fail_clear:
+	cxt->pstore.bufsize = 0;
+	cxt->max_count = 0;
+fail_out:
 	return err;
 }
 
 static int __exit ramoops_remove(struct platform_device *pdev)
 {
+#if 0
+	/* TODO(kees): We cannot unload ramoops since pstore doesn't support
+	 * unregistering yet.
+	 */
 	struct ramoops_context *cxt = &oops_cxt;
 
-	if (kmsg_dump_unregister(&cxt->dump) < 0)
-		pr_warn("could not unregister kmsg_dumper\n");
-
 	iounmap(cxt->virt_addr);
 	release_mem_region(cxt->phys_addr, cxt->size);
+	cxt->max_count = 0;
+
+	/* TODO(kees): When pstore supports unregistering, call it here. */
+	kfree(cxt->pstore.buf);
+	cxt->pstore.bufsize = 0;
+
 	return 0;
+#endif
+	return -EBUSY;
 }
 
 static struct platform_driver ramoops_driver = {
-- 
1.7.0.4


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-01-17 23:58 [PATCH v5] ramoops: use pstore interface Kees Cook
@ 2012-01-18 22:06 ` Andrew Morton
  2012-01-18 22:16   ` Kees Cook
  2012-01-18 22:37   ` Luck, Tony
  0 siblings, 2 replies; 17+ messages in thread
From: Andrew Morton @ 2012-01-18 22:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: Tony Luck, Marco Stornelli, Arnd Bergmann, Greg Kroah-Hartman,
	Randy Dunlap, linux-doc, linux-kernel

On Tue, 17 Jan 2012 15:58:52 -0800
Kees Cook <keescook@chromium.org> wrote:

> Instead of using /dev/mem directly and forcing userspace to know (or
> extract) where the platform has defined persistent memory, how many
> slots it has, the sizes, etc, use the common pstore infrastructure to
> handle Oops gathering and extraction. This presents a much easier to
> use filesystem-based view to the memory region. This also means that any
> other tools that are written to understand pstore will automatically be
> able to process ramoops too.
> 
> ...
>
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -603,6 +603,7 @@ source "drivers/s390/char/Kconfig"
>  config RAMOOPS
>  	tristate "Log panic/oops to a RAM buffer"
>  	depends on HAS_IOMEM
> +	depends on PSTORE
>  	default n
>  	help
>  	  This enables panic and oops messages to be logged to a circular

I think this is the right thing to do, but boy I hate it.  You sit
there wondering "wtf do I need to enable so I can use feature X".  I
sometimes use menuconfig's search feature, other times go trawl the
Kconfig files.  There should be a capability in Kconfig to just turn on
the terminal feature, enabling any precondition features on the way. 
Everyone loves Kconfig.

>
> ...
>
>  static int __exit ramoops_remove(struct platform_device *pdev)
>  {
> +#if 0
> +	/* TODO(kees): We cannot unload ramoops since pstore doesn't support
> +	 * unregistering yet.
> +	 */

Well that sucks.  Is pstore getting fixed?

>  	struct ramoops_context *cxt = &oops_cxt;
>  
> -	if (kmsg_dump_unregister(&cxt->dump) < 0)
> -		pr_warn("could not unregister kmsg_dumper\n");
> -
>  	iounmap(cxt->virt_addr);
>  	release_mem_region(cxt->phys_addr, cxt->size);
> +	cxt->max_count = 0;
> +
> +	/* TODO(kees): When pstore supports unregistering, call it here. */
> +	kfree(cxt->pstore.buf);
> +	cxt->pstore.bufsize = 0;
> +
>  	return 0;
> +#endif
> +	return -EBUSY;
>  }
>  
>  static struct platform_driver ramoops_driver = {


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-01-18 22:06 ` Andrew Morton
@ 2012-01-18 22:16   ` Kees Cook
  2012-01-18 22:40     ` Seiji Aguchi
  2012-01-18 22:37   ` Luck, Tony
  1 sibling, 1 reply; 17+ messages in thread
From: Kees Cook @ 2012-01-18 22:16 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Tony Luck, Marco Stornelli, Arnd Bergmann, Greg Kroah-Hartman,
	Randy Dunlap, linux-doc, linux-kernel

On Wed, Jan 18, 2012 at 2:06 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 17 Jan 2012 15:58:52 -0800
> Kees Cook <keescook@chromium.org> wrote:
>
>> --- a/drivers/char/Kconfig
>> +++ b/drivers/char/Kconfig
>> @@ -603,6 +603,7 @@ source "drivers/s390/char/Kconfig"
>>  config RAMOOPS
>>       tristate "Log panic/oops to a RAM buffer"
>>       depends on HAS_IOMEM
>> +     depends on PSTORE
>>       default n
>>       help
>>         This enables panic and oops messages to be logged to a circular
>
> I think this is the right thing to do, but boy I hate it.  You sit
> there wondering "wtf do I need to enable so I can use feature X".  I
> sometimes use menuconfig's search feature, other times go trawl the
> Kconfig files.  There should be a capability in Kconfig to just turn on
> the terminal feature, enabling any precondition features on the way.
> Everyone loves Kconfig.

Heh. Yeah, makes a lot of thing undiscoverable in menuconfig. Maybe
stuff should be greyed out instead of just disappearing.

>>  static int __exit ramoops_remove(struct platform_device *pdev)
>>  {
>> +#if 0
>> +     /* TODO(kees): We cannot unload ramoops since pstore doesn't support
>> +      * unregistering yet.
>> +      */
>
> Well that sucks.  Is pstore getting fixed?

Tony, any plans for changing this? I'm ready when it does! :)

Thanks,

-Kees

-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [PATCH v5] ramoops: use pstore interface
  2012-01-18 22:06 ` Andrew Morton
  2012-01-18 22:16   ` Kees Cook
@ 2012-01-18 22:37   ` Luck, Tony
  1 sibling, 0 replies; 17+ messages in thread
From: Luck, Tony @ 2012-01-18 22:37 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Marco Stornelli, Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap,
	linux-doc, linux-kernel

> > +	/* TODO(kees): We cannot unload ramoops since pstore doesn't support
> > +	 * unregistering yet.
> > +	 */
>
> Well that sucks.  Is pstore getting fixed?

While it might be useful for developers who have machines that
support multiple back-ends to load & unload - there really isn't
any credible end-user case for it - so it has a very low priority.
Perhaps zero (it would complicate the code for no useful purpose).

Even for development there's a lot of re-booting (after all, pstore
is really about saving the kernel log when the system crashes :-).

-Tony

^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [PATCH v5] ramoops: use pstore interface
  2012-01-18 22:16   ` Kees Cook
@ 2012-01-18 22:40     ` Seiji Aguchi
  2012-01-18 22:47       ` Kees Cook
  0 siblings, 1 reply; 17+ messages in thread
From: Seiji Aguchi @ 2012-01-18 22:40 UTC (permalink / raw)
  To: Kees Cook, Andrew Morton
  Cc: Tony Luck, Marco Stornelli, Arnd Bergmann, Greg Kroah-Hartman,
	Randy Dunlap, linux-doc, linux-kernel

>>>  static int __exit ramoops_remove(struct platform_device *pdev)
>>>  {
>>> +#if 0
>>> +     /* TODO(kees): We cannot unload ramoops since pstore doesn't support
>>> +      * unregistering yet.
>>> +      */
>>
>> Well that sucks.  Is pstore getting fixed?
>
>Tony, any plans for changing this? I'm ready when it does! :)
>
>

I have an question about this.

Are there any specific usecases you need to unload ramoops?

If users really would like to get kernel messages, unregistering ramoops is not needed.

Seiji

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-01-18 22:40     ` Seiji Aguchi
@ 2012-01-18 22:47       ` Kees Cook
  2012-01-18 23:20         ` Seiji Aguchi
  0 siblings, 1 reply; 17+ messages in thread
From: Kees Cook @ 2012-01-18 22:47 UTC (permalink / raw)
  To: Seiji Aguchi
  Cc: Andrew Morton, Tony Luck, Marco Stornelli, Arnd Bergmann,
	Greg Kroah-Hartman, Randy Dunlap, linux-doc, linux-kernel

On Wed, Jan 18, 2012 at 2:40 PM, Seiji Aguchi <seiji.aguchi@hds.com> wrote:
>>>>  static int __exit ramoops_remove(struct platform_device *pdev)
>>>>  {
>>>> +#if 0
>>>> +     /* TODO(kees): We cannot unload ramoops since pstore doesn't support
>>>> +      * unregistering yet.
>>>> +      */
>>>
>>> Well that sucks.  Is pstore getting fixed?
>>
>>Tony, any plans for changing this? I'm ready when it does! :)
>
> I have an question about this.
>
> Are there any specific usecases you need to unload ramoops?

For me, it would be useful during development. Beyond that, not that I can see.

-Kees

-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [PATCH v5] ramoops: use pstore interface
  2012-01-18 22:47       ` Kees Cook
@ 2012-01-18 23:20         ` Seiji Aguchi
  2012-01-21  8:33           ` Marco Stornelli
  0 siblings, 1 reply; 17+ messages in thread
From: Seiji Aguchi @ 2012-01-18 23:20 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Tony Luck, Marco Stornelli, Arnd Bergmann,
	Greg Kroah-Hartman, Randy Dunlap, linux-doc, linux-kernel

>> Are there any specific usecases you need to unload ramoops?
>
>For me, it would be useful during development. Beyond that, not that I can see.

Thank you for your quick relay. I understood this is useful for you.

But, as Tony said, I think this is a low priority because 
there is a side effect for end users.
If they unload ramoops by mistake, messages will be lost.

In my opinion, we have to consider whether each feature 
is truly needed for end users (not for developers).

Seiji


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-01-18 23:20         ` Seiji Aguchi
@ 2012-01-21  8:33           ` Marco Stornelli
  2012-04-02 20:39             ` Shuah Khan
  0 siblings, 1 reply; 17+ messages in thread
From: Marco Stornelli @ 2012-01-21  8:33 UTC (permalink / raw)
  To: Seiji Aguchi
  Cc: Kees Cook, Andrew Morton, Tony Luck, Arnd Bergmann,
	Greg Kroah-Hartman, Randy Dunlap, linux-doc, linux-kernel

Il 19/01/2012 00:20, Seiji Aguchi ha scritto:
>>> Are there any specific usecases you need to unload ramoops?
>>
>> For me, it would be useful during development. Beyond that, not that I can see.
>
> Thank you for your quick relay. I understood this is useful for you.
>
> But, as Tony said, I think this is a low priority because
> there is a side effect for end users.
> If they unload ramoops by mistake, messages will be lost.
>
> In my opinion, we have to consider whether each feature
> is truly needed for end users (not for developers).
>
> Seiji
>
>

First of all ramoops was born mainly for debug purpose and to help the 
maintainability of a product. I used it in systems where the uptime (so 
no reboot) was important. So it can be very useful for me load the 
module, gather logs and unload it for example. A kernel panic is not 
recoverable so the reboot is needed but it's not always true for a 
kernel oops.

Marco

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-01-21  8:33           ` Marco Stornelli
@ 2012-04-02 20:39             ` Shuah Khan
  2012-04-02 20:51               ` Kees Cook
  0 siblings, 1 reply; 17+ messages in thread
From: Shuah Khan @ 2012-04-02 20:39 UTC (permalink / raw)
  To: Kees Cook; +Cc: LKML


> First of all ramoops was born mainly for debug purpose and to help the 
> maintainability of a product. I used it in systems where the uptime (so 
> no reboot) was important. So it can be very useful for me load the 
> module, gather logs and unload it for example. A kernel panic is not 
> recoverable so the reboot is needed but it's not always true for a 
> kernel oops.
> 
> Marco

What is the status of this patch? Don't see it in 3.3 and haven't
checked 3.4-rc1 yet.

-- Shuah


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-02 20:39             ` Shuah Khan
@ 2012-04-02 20:51               ` Kees Cook
  2012-04-02 21:09                 ` Andrew Morton
  2012-04-09 21:33                 ` Andrew Morton
  0 siblings, 2 replies; 17+ messages in thread
From: Kees Cook @ 2012-04-02 20:51 UTC (permalink / raw)
  To: shuahkhan, Matt Morton; +Cc: LKML

On Mon, Apr 2, 2012 at 1:39 PM, Shuah Khan <shuahkhan@gmail.com> wrote:
>> First of all ramoops was born mainly for debug purpose and to help the
>> maintainability of a product. I used it in systems where the uptime (so
>> no reboot) was important. So it can be very useful for me load the
>> module, gather logs and unload it for example. A kernel panic is not
>> recoverable so the reboot is needed but it's not always true for a
>> kernel oops.
>>
>> Marco
>
> What is the status of this patch? Don't see it in 3.3 and haven't
> checked 3.4-rc1 yet.

Hi,

I've been hoping it would get into 3.4. It's in the -mm tree, and has
been living in linux-next for a while. I'm not sure why it hasn't been
merged into Linus's tree yet. Andrew, is there a reason it hasn't been
merged?

http://marc.info/?l=linux-mm-commits&m=132692455101733&w=4

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=07eff225ead22b21fe5aba32cd2695248a9e4d1f

-Kees

-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-02 20:51               ` Kees Cook
@ 2012-04-02 21:09                 ` Andrew Morton
  2012-04-09 21:33                 ` Andrew Morton
  1 sibling, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2012-04-02 21:09 UTC (permalink / raw)
  To: Kees Cook; +Cc: shuahkhan, LKML

On Mon, 2 Apr 2012 13:51:29 -0700 Kees Cook <keescook@chromium.org> wrote:

> On Mon, Apr 2, 2012 at 1:39 PM, Shuah Khan <shuahkhan@gmail.com> wrote:
> >> First of all ramoops was born mainly for debug purpose and to help the
> >> maintainability of a product. I used it in systems where the uptime (so
> >> no reboot) was important. So it can be very useful for me load the
> >> module, gather logs and unload it for example. A kernel panic is not
> >> recoverable so the reboot is needed but it's not always true for a
> >> kernel oops.
> >>
> >> Marco
> >
> > What is the status of this patch? Don't see it in 3.3 and haven't
> > checked 3.4-rc1 yet.
> 
> Hi,
> 
> I've been hoping it would get into 3.4. It's in the -mm tree, and has
> been living in linux-next for a while. I'm not sure why it hasn't been
> merged into Linus's tree yet. Andrew, is there a reason it hasn't been
> merged?
> 

It's not forgotten about - sometimes I'll hold a few things over until
rc2 to give myself time to go back and review the discussion.  The
ramoops and c/r patches fell into that bucket this time.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-02 20:51               ` Kees Cook
  2012-04-02 21:09                 ` Andrew Morton
@ 2012-04-09 21:33                 ` Andrew Morton
  2012-04-09 21:42                   ` Luck, Tony
  1 sibling, 1 reply; 17+ messages in thread
From: Andrew Morton @ 2012-04-09 21:33 UTC (permalink / raw)
  To: Kees Cook; +Cc: shuahkhan, LKML, Tony Luck, Marco Stornelli

On Mon, 2 Apr 2012 13:51:29 -0700
Kees Cook <keescook@chromium.org> wrote:

> On Mon, Apr 2, 2012 at 1:39 PM, Shuah Khan <shuahkhan@gmail.com> wrote:
> >> First of all ramoops was born mainly for debug purpose and to help the
> >> maintainability of a product. I used it in systems where the uptime (so
> >> no reboot) was important. So it can be very useful for me load the
> >> module, gather logs and unload it for example. A kernel panic is not
> >> recoverable so the reboot is needed but it's not always true for a
> >> kernel oops.
> >>
> >> Marco
> >
> > What is the status of this patch? Don't see it in 3.3 and haven't
> > checked 3.4-rc1 yet.
> 
> Hi,
> 
> I've been hoping it would get into 3.4. It's in the -mm tree, and has
> been living in linux-next for a while. I'm not sure why it hasn't been
> merged into Linus's tree yet. Andrew, is there a reason it hasn't been
> merged?

The patch breaks ramoops module unloading.  Tony says there's "no
credible end-user case" for this and Marco promptly provided one,
which was ignored.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [PATCH v5] ramoops: use pstore interface
  2012-04-09 21:33                 ` Andrew Morton
@ 2012-04-09 21:42                   ` Luck, Tony
  2012-04-10  8:34                     ` Marco Stornelli
  0 siblings, 1 reply; 17+ messages in thread
From: Luck, Tony @ 2012-04-09 21:42 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook; +Cc: shuahkhan, LKML, Marco Stornelli

> The patch breaks ramoops module unloading.  Tony says there's "no
> credible end-user case" for this and Marco promptly provided one,
> which was ignored.

I'm not sure that I understood Marco's use case. He said:

> First of all ramoops was born mainly for debug purpose and
> to help the maintainability of a product. I used it in systems
> where the uptime (so no reboot) was important. So it can be
> very useful for me load the module, gather logs and unload it
> for example. A kernel panic is not recoverable so the reboot
> is needed but it's not always true for a kernel oops.

In the non-crashed oops case ... aren't all the logs you need
in /var/log/messages?

-Tony


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-09 21:42                   ` Luck, Tony
@ 2012-04-10  8:34                     ` Marco Stornelli
  2012-04-10 16:11                       ` Kees Cook
  0 siblings, 1 reply; 17+ messages in thread
From: Marco Stornelli @ 2012-04-10  8:34 UTC (permalink / raw)
  To: Luck, Tony; +Cc: Andrew Morton, Kees Cook, shuahkhan, LKML

Il 09/04/2012 23:42, Luck, Tony ha scritto:
>> The patch breaks ramoops module unloading.  Tony says there's "no
>> credible end-user case" for this and Marco promptly provided one,
>> which was ignored.
>
> I'm not sure that I understood Marco's use case. He said:
>
>> First of all ramoops was born mainly for debug purpose and
>> to help the maintainability of a product. I used it in systems
>> where the uptime (so no reboot) was important. So it can be
>> very useful for me load the module, gather logs and unload it
>> for example. A kernel panic is not recoverable so the reboot
>> is needed but it's not always true for a kernel oops.
>
> In the non-crashed oops case ... aren't all the logs you need
> in /var/log/messages?
>
> -Tony

Maybe you right, but it could be useful to have a "single log point" 
especially for automatic/semi-automatic log gathering. I'm not sure we 
can *always* read from messages in case of non-crashed oops. Sure, it 
will be possible after a reboot, but if /var was mounted with tmpfs (on 
embedded systems it's possible :)) we have no log.

PS: It's only a brainstorming on all the possible situation :)

Marco

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-10  8:34                     ` Marco Stornelli
@ 2012-04-10 16:11                       ` Kees Cook
  2012-04-11  6:33                         ` Marco Stornelli
  0 siblings, 1 reply; 17+ messages in thread
From: Kees Cook @ 2012-04-10 16:11 UTC (permalink / raw)
  To: Marco Stornelli; +Cc: Luck, Tony, Andrew Morton, shuahkhan, LKML

On Tue, Apr 10, 2012 at 1:34 AM, Marco Stornelli
<marco.stornelli@gmail.com> wrote:
> Il 09/04/2012 23:42, Luck, Tony ha scritto:
>
>>> The patch breaks ramoops module unloading.  Tony says there's "no
>>> credible end-user case" for this and Marco promptly provided one,
>>> which was ignored.
>>
>>
>> I'm not sure that I understood Marco's use case. He said:
>>
>>> First of all ramoops was born mainly for debug purpose and
>>> to help the maintainability of a product. I used it in systems
>>> where the uptime (so no reboot) was important. So it can be
>>> very useful for me load the module, gather logs and unload it
>>> for example. A kernel panic is not recoverable so the reboot
>>> is needed but it's not always true for a kernel oops.
>>
>>
>> In the non-crashed oops case ... aren't all the logs you need
>> in /var/log/messages?
>>
>> -Tony
>
>
> Maybe you right, but it could be useful to have a "single log point"
> especially for automatic/semi-automatic log gathering. I'm not sure we can
> *always* read from messages in case of non-crashed oops. Sure, it will be
> possible after a reboot, but if /var was mounted with tmpfs (on embedded
> systems it's possible :)) we have no log.
>
> PS: It's only a brainstorming on all the possible situation :)

Do you feel that this lack of unloading is still a sufficient reason
to NAK the ramoops patch?

-Kees

-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-10 16:11                       ` Kees Cook
@ 2012-04-11  6:33                         ` Marco Stornelli
  2012-04-11  6:37                           ` Andrew Morton
  0 siblings, 1 reply; 17+ messages in thread
From: Marco Stornelli @ 2012-04-11  6:33 UTC (permalink / raw)
  To: Kees Cook; +Cc: Luck, Tony, Andrew Morton, shuahkhan, LKML

2012/4/10 Kees Cook <keescook@chromium.org>:
> On Tue, Apr 10, 2012 at 1:34 AM, Marco Stornelli
> <marco.stornelli@gmail.com> wrote:
>> Il 09/04/2012 23:42, Luck, Tony ha scritto:
>>
>>>> The patch breaks ramoops module unloading.  Tony says there's "no
>>>> credible end-user case" for this and Marco promptly provided one,
>>>> which was ignored.
>>>
>>>
>>> I'm not sure that I understood Marco's use case. He said:
>>>
>>>> First of all ramoops was born mainly for debug purpose and
>>>> to help the maintainability of a product. I used it in systems
>>>> where the uptime (so no reboot) was important. So it can be
>>>> very useful for me load the module, gather logs and unload it
>>>> for example. A kernel panic is not recoverable so the reboot
>>>> is needed but it's not always true for a kernel oops.
>>>
>>>
>>> In the non-crashed oops case ... aren't all the logs you need
>>> in /var/log/messages?
>>>
>>> -Tony
>>
>>
>> Maybe you right, but it could be useful to have a "single log point"
>> especially for automatic/semi-automatic log gathering. I'm not sure we can
>> *always* read from messages in case of non-crashed oops. Sure, it will be
>> possible after a reboot, but if /var was mounted with tmpfs (on embedded
>> systems it's possible :)) we have no log.
>>
>> PS: It's only a brainstorming on all the possible situation :)
>
> Do you feel that this lack of unloading is still a sufficient reason
> to NAK the ramoops patch?
>
> -Kees
>
> --
> Kees Cook
> ChromeOS Security

I don't want to use a "veto" about this patch. If nobody see problem
to apply it, then even ok for me. As I said I'm guessing possible
situations where an unload features is useful.

Andrew what do you think?

Marco

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v5] ramoops: use pstore interface
  2012-04-11  6:33                         ` Marco Stornelli
@ 2012-04-11  6:37                           ` Andrew Morton
  0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2012-04-11  6:37 UTC (permalink / raw)
  To: Marco Stornelli; +Cc: Kees Cook, Luck, Tony, shuahkhan, LKML

On Wed, 11 Apr 2012 08:33:15 +0200 Marco Stornelli <marco.stornelli@gmail.com> wrote:

> I don't want to use a "veto" about this patch. If nobody see problem
> to apply it, then even ok for me. As I said I'm guessing possible
> situations where an unload features is useful.
> 
> Andrew what do you think?

Yes, I plan to send it to Linus.

breaking unloading is a regression, albeit a small one.  It's a bit
sad that nobody appears to intend to fix it.

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2012-04-11  6:37 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-17 23:58 [PATCH v5] ramoops: use pstore interface Kees Cook
2012-01-18 22:06 ` Andrew Morton
2012-01-18 22:16   ` Kees Cook
2012-01-18 22:40     ` Seiji Aguchi
2012-01-18 22:47       ` Kees Cook
2012-01-18 23:20         ` Seiji Aguchi
2012-01-21  8:33           ` Marco Stornelli
2012-04-02 20:39             ` Shuah Khan
2012-04-02 20:51               ` Kees Cook
2012-04-02 21:09                 ` Andrew Morton
2012-04-09 21:33                 ` Andrew Morton
2012-04-09 21:42                   ` Luck, Tony
2012-04-10  8:34                     ` Marco Stornelli
2012-04-10 16:11                       ` Kees Cook
2012-04-11  6:33                         ` Marco Stornelli
2012-04-11  6:37                           ` Andrew Morton
2012-01-18 22:37   ` Luck, Tony

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).