dle-develop — Dependable Linux Effort mailing list for developers

[Dle-develop] Sesión de peluqueria, lavar, tinte y peinado por solo 13€! 60% Dto. menú de entrantes y parrillada de marisco por solo 15€, depilación casi completa y masaje corporal por 27,50€ y más ofertas solidarias

[MyBonusWeb S. <ne...@my...>]

	



	



 in...@my... a tu libreta
de direcciones y llegaremos siempre a tu bandeja de entrada.
							


							



								
									Ofertas Solidarias en Tu Ciudad

								Sé solidario, colabora con los que lo necesitan solo con tu email
								
							


							



							



								
50% Dto. Sesión de depilación más masaje relajante.

Oferta especial!

								
								
							


									SOLO: 27,50€
							


							




									original:
55€

								
								50%
								
								27,50€
							




								
								
								
								
							


								
								

										Una depilación casi completa a un precio excepcional: piernas enteras, axilas, cejas y labio para terminar con un masaje corporal¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
50% Dto. Relaja todos tus sentidos, tu cuerpo te lo agradecerá.

Simplemente
relájate...

								
								
							


									SOLO: 27,50€
							


							




									original:
55€

								
								50%
								
								27,50€
							




								
								
								
								
							


								
								

										Tomate tu tiempo, date este regalo, tú te lo mereces. Rompe con tu rutina y date este regalo. Disfruta de esta sesión de relajación, donde tu mente y cuerpo entrarán en armonía.¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
60% Dto.Disfruta de este apetitoso menú de entrantes + parrillada de marisco

Hínchate
de marisco...

								
								
							


									SOLO: 15,00€
							


							




									original:
35€

								
								60%
								
								20,00€
							




								
								
								
								
							


								
								

										Degusta este completísimo menú compuesto de entrante y de los pescados y mariscos mas frescos del mercado acompañado por un buen vino ribeiro más postre .¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
41% Dto. Ponte guapa con una sesión de peluquería, Lavar, tinte y peinado

Oferta espectacular!

								
								
							


									SOLO: 13,00€
							


							




									original:
22€

								
								41%
								
								9,00€
							




								
								
								
								
							


								
								

										Consigue un pelo brillante, con color y forma, y disfruta de un nuevo look.¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 6 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



								
								
								
								
							



							


								Si
nos referencias a tus amigos o familiares todos tendréis un gran descuento en la compra de vuestros ¡MyBonus!
								
								
									Sé el primero en recibir nuestras ofertas, para ello haz click en tu ciudad:

Madrid · Barcelona · Bilbao · Valencia · Zaragoza · Sevilla · Málaga · A Coruña · Mallorca · Alicante · Las Palmas · Valladolid · Córdoba · Granada · Oviedo · Otra

								
							




							


Descuentos solidarios de hasta el 90% en tu ciudad
www.mybonusweb.com

							


									Actualmente estás suscrito a este boletín con la cuenta (dle...@li...). Tus datos se encuentran recogidos en un fichero automatizado cuyo responsable es Mybonus Experience S.L., a través de la web www.mybonusweb.com podrás ejercitar los derechos de acceso, rectificación, cancelación y oposición. Todo ello en cumplimiento de lo dispuesto en la Ley Orgánica 15/1999,
de 13 de Diciembre de Protección de Datos de Carácter Personal.


									Por favor no respondas a este mail. Si tienes cualquier duda o sugerencia contacta con in...@my... (in...@my...) 

									Si NO deseas recibir las fantásticas ofertas solidarias de tu ciudad con las que tienes un ahorro de hasta el 90% y además ayudas a proyectos solidarios, haz click aquí

							


							


			

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Matthew G. <mj...@re...>]

On Tue, Jul 19, 2011 at 08:27:54PM +0100, Matthew Garrett wrote:
> On Tue, Jul 19, 2011 at 03:14:22PM -0400, Seiji Aguchi wrote:
> > 
> > >And how does that handle the case where we're halfway through a pstore
> > >access when the NMI arrives? ERST, at least, has a complex state
> > >machine. You can't guarantee what starting one transaction without
> > >completing one that was in process will do.
> > 
> > As for ERST, write access is protected by raw_spin_trylock_irqsave(&erst_lock).
> > Are there anything I'm missing?
> 
> If there's already locking involved, what benefit does removing the lock 
> in the pstore code give? You'll just hang when you hit the erst code 
> instead of the pstore code.

I'm sorry, you're right, this is a trylock so we won't hang in this 
case. We should probably document that in the pstore documentation to 
ensure that any future backends have the same behaviour.

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Matthew G. <mj...@re...>]

On Tue, Jul 19, 2011 at 03:14:22PM -0400, Seiji Aguchi wrote:
> 
> >And how does that handle the case where we're halfway through a pstore
> >access when the NMI arrives? ERST, at least, has a complex state
> >machine. You can't guarantee what starting one transaction without
> >completing one that was in process will do.
> 
> As for ERST, write access is protected by raw_spin_trylock_irqsave(&erst_lock).
> Are there anything I'm missing?

If there's already locking involved, what benefit does removing the lock 
in the pstore code give? You'll just hang when you hit the erst code 
instead of the pstore code.

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Don Z. <dz...@re...>]

On Tue, Jul 19, 2011 at 03:02:12PM -0400, Vivek Goyal wrote:
> > Another interesting question is do we need to log anything in the kdump
> > path?  Isn't kdump generating the same info?  What added value do we get
> > over kdump?
> 
> I had the same question. The argument is that kdump can fail and they
> can not afford to not capture any info at all. So before kdump executes
> they want to save some state to NVRAM.
> 
> I am wondering that saving this info to NVRAM, can it be done early in
> second kernel? I guess we are not supposed to take any EFI services in
> second kernel so it might not be possible.

Actually the write to NVRAM wouldn't be so bad if ERST supported it.  It
would just be an equvialent to a memcpy.  Currently it uses a complicated
state machine to a persistent storage which complicates things.  As a
result I get nervous if ERST firmware issues would block us from executing
kdump.

Cheers,
Don

Re: [Dle-develop] [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Seiji A. <sei...@hd...>]

Hi,

>Why can't we log something in user
>space when user initiates a reboot, let it get logged in /var/log/messages
>and then umount the file root and go ahead with reboot. Why does kernel
>need to capture that info in NVRAM.

Thank you for coordinating discussion.
I will reply to your question.

Regards,

Seiji

>-----Original Message-----
>From: Vivek Goyal [mailto:vg...@re...]
>Sent: Tuesday, July 19, 2011 2:48 PM
>To: Seiji Aguchi
>Cc: ke...@li...; lin...@vg...; lin...@li...; Eric W. Biederman; KOSAKI
>Motohiro; Americo Wang; Matthew Garrett; ton...@in...; Andrew Morton; Jarod Wilson; hp...@zy...;
>dz...@re...; dle...@li...; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path
>
>On Tue, Jul 19, 2011 at 02:23:26PM -0400, Seiji Aguchi wrote:
>> Hi,
>>
>> [Upstream status]
>>    Discussion about kmsg_dump() in kdump path:
>>     - Eric and Vivek are worried about reliability of existing kmsg_dump().
>>     - Especially, Vivek would like to remove a RCU  function call chain in kdump path
>> 　　　 which kernel modules can register their function calls freely.
>>
>>    Discussion about pstore in nmi_hander.
>>     - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.
>
>You did not answer my questions in the last posting mail thread and gone
>ahead with the new posting. How are we supposed to discuss something. This
>has been a problem on this mail thread since the beginneing. There is
>little open discussion.
>
>So if you want to make any progress in this direction, what will help
>is open discussion.
>
>Locking is going to be a problem. So atleast we can remove kmsg_dump()
>infrastructure from reboot path. Why can't we log something in user
>space when user initiates a reboot, let it get logged in /var/log/messages
>and then umount the file root and go ahead with reboot. Why does kernel
>need to capture that info in NVRAM.
>
>If we can get rid of all the logging thing on reboot path, then at least
>it does not need to be lock protected with crash path.
>
>Thanks
>Vivek

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Seiji A. <sei...@hd...>]

>And how does that handle the case where we're halfway through a pstore
>access when the NMI arrives? ERST, at least, has a complex state
>machine. You can't guarantee what starting one transaction without
>completing one that was in process will do.

As for ERST, write access is protected by raw_spin_trylock_irqsave(&erst_lock).
Are there anything I'm missing?

Seiji


>-----Original Message-----
>From: Matthew Garrett [mailto:mj...@re...]
>Sent: Tuesday, July 19, 2011 2:52 PM
>To: Seiji Aguchi
>Cc: ke...@li...; lin...@vg...; lin...@li...; Eric W. Biederman; Vivek
>Goyal; KOSAKI Motohiro; Americo Wang; ton...@in...; Andrew Morton; Jarod Wilson; hp...@zy...; dz...@re...;
>dle...@li...; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
>
>On Tue, Jul 19, 2011 at 02:48:22PM -0400, Seiji Aguchi wrote:
>> >How is this safe? What happens if there's a pstore access in process
>> >when you hit this codepath?
>>
>> This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().
>>
>> Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.
>
>And how does that handle the case where we're halfway through a pstore
>access when the NMI arrives? ERST, at least, has a complex state
>machine. You can't guarantee what starting one transaction without
>completing one that was in process will do.
>
>--
>Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Vivek G. <vg...@re...>]

On Tue, Jul 19, 2011 at 02:54:11PM -0400, Don Zickus wrote:
> On Tue, Jul 19, 2011 at 02:48:22PM -0400, Seiji Aguchi wrote:
> > >How is this safe? What happens if there's a pstore access in process
> > >when you hit this codepath?
> > 
> > This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().
> > 
> > Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.
> > 
> > 
> > @@ -1081,6 +1083,7 @@ void crash_kexec(struct pt_regs *regs)
> >  			crash_setup_regs(&fixed_regs, regs);
> >  			crash_save_vmcoreinfo();
> >  			machine_crash_shutdown(&fixed_regs);
> > +			pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC);
> > 
> > Seiji
> 
> Another interesting question is do we need to log anything in the kdump
> path?  Isn't kdump generating the same info?  What added value do we get
> over kdump?

I had the same question. The argument is that kdump can fail and they
can not afford to not capture any info at all. So before kdump executes
they want to save some state to NVRAM.

I am wondering that saving this info to NVRAM, can it be done early in
second kernel? I guess we are not supposed to take any EFI services in
second kernel so it might not be possible.

Thanks
Vivek

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Don Z. <dz...@re...>]

On Tue, Jul 19, 2011 at 02:48:22PM -0400, Seiji Aguchi wrote:
> >How is this safe? What happens if there's a pstore access in process
> >when you hit this codepath?
> 
> This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().
> 
> Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.
> 
> 
> @@ -1081,6 +1083,7 @@ void crash_kexec(struct pt_regs *regs)
>  			crash_setup_regs(&fixed_regs, regs);
>  			crash_save_vmcoreinfo();
>  			machine_crash_shutdown(&fixed_regs);
> +			pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC);
> 
> Seiji

Another interesting question is do we need to log anything in the kdump
path?  Isn't kdump generating the same info?  What added value do we get
over kdump?

Cheers,
Don

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Matthew G. <mj...@re...>]

On Tue, Jul 19, 2011 at 02:48:22PM -0400, Seiji Aguchi wrote:
> >How is this safe? What happens if there's a pstore access in process
> >when you hit this codepath?
> 
> This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().
> 
> Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.

And how does that handle the case where we're halfway through a pstore
access when the NMI arrives? ERST, at least, has a complex state 
machine. You can't guarantee what starting one transaction without 
completing one that was in process will do.

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Seiji A. <sei...@hd...>]

>How is this safe? What happens if there's a pstore access in process
>when you hit this codepath?

This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().

Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.


@@ -1081,6 +1083,7 @@ void crash_kexec(struct pt_regs *regs)
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
+			pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC);

Seiji

>-----Original Message-----
>From: Matthew Garrett [mailto:mj...@re...]
>Sent: Tuesday, July 19, 2011 2:35 PM
>To: Seiji Aguchi
>Cc: ke...@li...; lin...@vg...; lin...@li...; Eric W. Biederman; Vivek
>Goyal; KOSAKI Motohiro; Americo Wang; ton...@in...; Andrew Morton; Jarod Wilson; hp...@zy...; dz...@re...;
>dle...@li...; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
>
>On Tue, Jul 19, 2011 at 02:24:27PM -0400, Seiji Aguchi wrote:
>
>> -	mutex_lock(&psinfo->buf_mutex);
>> +	switch (reason) {
>> +	case KMSG_DUMP_KEXEC:
>> +		/* Skip if there is no driver or there is a driver calling
>> +		   pstore_register() */
>> +		if (!psinfo || !spin_trylock(&pstore_lock))
>> +			return;
>> +		break;
>> +	default:
>> +		mutex_lock(&psinfo->buf_mutex);
>
>How is this safe? What happens if there's a pstore access in process
>when you hit this codepath?
>
>--
>Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Vivek G. <vg...@re...>]

On Tue, Jul 19, 2011 at 02:23:26PM -0400, Seiji Aguchi wrote:
> Hi,
> 
> [Upstream status]
>    Discussion about kmsg_dump() in kdump path: 
>     - Eric and Vivek are worried about reliability of existing kmsg_dump().
>     - Especially, Vivek would like to remove a RCU  function call chain in kdump path
> 　　　 which kernel modules can register their function calls freely. 
> 
>    Discussion about pstore in nmi_hander.
>     - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.

You did not answer my questions in the last posting mail thread and gone
ahead with the new posting. How are we supposed to discuss something. This
has been a problem on this mail thread since the beginneing. There is
little open discussion. 

So if you want to make any progress in this direction, what will help
is open discussion.

Locking is going to be a problem. So atleast we can remove kmsg_dump()
infrastructure from reboot path. Why can't we log something in user
space when user initiates a reboot, let it get logged in /var/log/messages
and then umount the file root and go ahead with reboot. Why does kernel
need to capture that info in NVRAM.

If we can get rid of all the logging thing on reboot path, then at least
it does not need to be lock protected with crash path.

Thanks
Vivek

Re: [Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Matthew G. <mj...@re...>]

On Tue, Jul 19, 2011 at 02:24:27PM -0400, Seiji Aguchi wrote:

> -	mutex_lock(&psinfo->buf_mutex);
> +	switch (reason) {
> +	case KMSG_DUMP_KEXEC:
> +		/* Skip if there is no driver or there is a driver calling
> +		   pstore_register() */
> +		if (!psinfo || !spin_trylock(&pstore_lock))
> +			return;
> +		break;
> +	default:
> +		mutex_lock(&psinfo->buf_mutex);

How is this safe? What happens if there's a pstore access in process 
when you hit this codepath?

-- 
Matthew Garrett | mj...@sr...

[Dle-develop] [RFC][PATCH -mmotm 4/4] pstore: ramoops support

[Seiji A. <sei...@hd...>]

Hi,

Pstore can support ramoops with this patch.

 drivers/char/Kconfig
 - Add "depends on PSTORE" to CONFIG_RAMOOPS

 drivers/char/ramoops.c
 - Add pstore_info structure so that ramoops can call pstore_register()
 - Remove kmsg_dump_unregister because pstore doesn't support unregister operation
 - Remove do_gettimeofday() from kexec/panic path for avoiding dead lock due to logbuf_lock of WARN_ON() in getnstimeofday().

 kernel/time/timekeeping.c
 - introduce get_useconds() which get "xtime.nsec / 1000" without taking lock 

TODO:
  - I couldn't find any Documentation about ramoops.
    Please let me know how to test my patch.

  - I haven't implemented reader/eraser callbacks supported by pstore.

  - If ramoops users would like to unload module,
    pstore needs to support unregister operation.

 Signed-off-by: Seiji Aguchi <sei...@hd...>

---
 drivers/char/Kconfig      |    1 +
 drivers/char/ramoops.c    |  114 ++++++++++++++++++++++++++++++---------------
 include/linux/time.h      |    1 +
 kernel/time/timekeeping.c |    6 ++
 4 files changed, 85 insertions(+), 37 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 423fd56..c805d1e 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 8092c31..41c82e3 100644
--- a/drivers/char/ramoops.c
+++ b/drivers/char/ramoops.c
@@ -24,6 +24,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/kmsg_dump.h>
+#include <linux/pstore.h>
 #include <linux/time.h>
 #include <linux/io.h>
 #include <linux/ioport.h>
@@ -34,6 +35,7 @@
 #include <linux/debugfs.h>
 
 #define RAMOOPS_KERNMSG_HDR "===="
+#define RAMOOPS_HDR_SIZE 44 /* 4 (RAMOOPS_KERN_MSG_HDR)  + 40 (timestamp) */
 #define MIN_MEM_SIZE 4096UL
 #define RAMOOPS_DIR "ramoops"
 #define RAMOOPS_NEXT "next"
@@ -58,6 +60,43 @@ 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 unsigned long total_size;
+static int ramoops_open(struct pstore_info *psi);
+static int ramoops_close(struct pstore_info *psi);
+static ssize_t ramoops_reader(u64 *id, enum pstore_type_id *type,
+			      struct timespec *time);
+static u64 ramoops_dumper(enum pstore_type_id type, size_t size,
+			  enum kmsg_dump_reason reason);
+static int ramoops_eraser(u64 record_id);
+
+static struct pstore_info ramoops_info = {
+	.owner		= THIS_MODULE,
+	.name		= "ramoops",
+	.open		= ramoops_open,
+	.close		= ramoops_close,
+	.read		= ramoops_reader,
+	.write		= ramoops_dumper,
+	.erase		= ramoops_eraser
+};
+
+static int ramoops_open(struct pstore_info *psi)
+{
+	return 0;
+}
+
+static int ramoops_close(struct pstore_info *psi)
+{
+	return 0;
+}
+
+static ssize_t ramoops_reader(u64 *id, enum pstore_type_id *type,
+			      struct timespec *time)
+{
+	return -EINVAL;
+}
+
+
+
 static struct ramoops_context {
 	struct kmsg_dumper dump;
 	void *virt_addr;
@@ -141,49 +180,51 @@ static const struct file_operations ramoops_next_fops = {
 	.read = ramoops_read_next,
 };
 
-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 u64 ramoops_dumper(enum pstore_type_id type, size_t size,
+			  enum kmsg_dump_reason reason)
 {
-	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;
+	char *buf;
 	struct timeval timestamp;
+	struct ramoops_context *cxt = &oops_cxt;
 
 	if (reason != KMSG_DUMP_OOPS &&
-	    reason != KMSG_DUMP_PANIC)
-		return;
+	    reason != KMSG_DUMP_PANIC &&
+	    reason != KMSG_DUMP_KEXEC)
+		return 0;
 
 	/* Only dump oopses if dump_oops is set */
 	if (reason == KMSG_DUMP_OOPS && !cxt->dump_oops)
-		return;
+		return 0;
 
-	mutex_lock(&ramoops_mutex);
-	buf = cxt->virt_addr + (cxt->count * cxt->record_size);
-	buf_orig = buf;
+	if (total_size >= record_size)
+		return 0;
 
-	memset(buf, '\0', cxt->record_size);
-	res = sprintf(buf, "%s", RAMOOPS_KERNMSG_HDR);
-	buf += res;
-	do_gettimeofday(&timestamp);
-	res = sprintf(buf, "%lu.%lu\n", (long)timestamp.tv_sec, (long)timestamp.tv_usec);
-	buf += res;
+	if (reason == KMSG_DUMP_OOPS) {
+		mutex_lock(&ramoops_mutex);
+		do_gettimeofday(&timestamp);
+	} else {
+		timestamp.tv_sec = get_seconds();
+		timestamp.tv_usec = get_useconds();
+	}
 
-	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);
+	buf = cxt->virt_addr + (cxt->count * record_size);
+	snprintf(buf, RAMOOPS_HDR_SIZE, "%s%lu.%lu\n",
+		 RAMOOPS_KERNMSG_HDR, (long)timestamp.tv_sec,
+		 (long)timestamp.tv_usec);
+	ramoops_info.buf += record_size;
+	total_size = total_size + size + RAMOOPS_HDR_SIZE;
 
-	s2_start = l2 - l2_cpy;
-	s1_start = l1 - l1_cpy;
+	cxt->count = (cxt->count + 1) % cxt->max_count;
 
-	memcpy(buf, s1 + s1_start, l1_cpy);
-	memcpy(buf + l1_cpy, s2 + s2_start, l2_cpy);
+	if (reason == KMSG_DUMP_OOPS)
+		mutex_unlock(&ramoops_mutex);
 
-	cxt->count = (cxt->count + 1) % cxt->max_count;
-	mutex_unlock(&ramoops_mutex);
+	return 0;
+}
+
+static int ramoops_eraser(u64 record_id)
+{
+	return 0;
 }
 
 static int __init ramoops_probe(struct platform_device *pdev)
@@ -233,11 +274,13 @@ static int __init ramoops_probe(struct platform_device *pdev)
 		pr_err("ioremap failed\n");
 		goto fail2;
 	}
+	memset(cxt->virt_addr, '\0', cxt->size);
 
-	cxt->dump.dump = ramoops_do_dump;
-	err = kmsg_dump_register(&cxt->dump);
-	if (err) {
-		pr_err("registering kmsg dumper failed\n");
+	mutex_init(&ramoops_info.buf_mutex);
+	ramoops_info.buf = cxt->virt_addr + RAMOOPS_HDR_SIZE;
+	ramoops_info.bufsize = record_size - RAMOOPS_HDR_SIZE;
+	if (pstore_register(&ramoops_info)) {
+		printk(KERN_ERR "Could not register with persistent store\n");
 		goto fail1;
 	}
 
@@ -284,9 +327,6 @@ static int __exit ramoops_remove(struct platform_device *pdev)
 {
 	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);
 	return 0;
diff --git a/include/linux/time.h b/include/linux/time.h
index b306178..cff6bb5 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -121,6 +121,7 @@ void timekeeping_init(void);
 extern int timekeeping_suspended;
 
 unsigned long get_seconds(void);
+unsigned long get_useconds(void);
 struct timespec current_kernel_time(void);
 struct timespec __current_kernel_time(void); /* does not take xtime_lock */
 struct timespec get_monotonic_coarse(void);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 342408c..1927edc 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1029,6 +1029,12 @@ unsigned long get_seconds(void)
 }
 EXPORT_SYMBOL(get_seconds);
 
+unsigned long get_useconds(void)
+{
+	return xtime.tv_sec / 1000;
+}
+EXPORT_SYMBOL(get_useconds);
+
 struct timespec __current_kernel_time(void)
 {
 	return xtime;
-- 
1.7.1

[Dle-develop] [RFC][PATCH -mmotm 3/4] pstore: mtdoops support

[Seiji A. <sei...@hd...>]

Hi,

Pstore can support mtdoops with this patch.

fs/pstore/platform.c
 - Add "reason" argument to pstore_dump() so that mtdoops can select its behaivor in accordance with each reason

 drivers/mtd/Kconfig
 - Add "depends on PSTORE" to CONFIG_MTD_OOPS

 drivers/mtd/mtdoops.c
 - Add pstore_info structure so that mtdoops can call pstore_register()
 - Remove kmsg_dump_unregister because pstore doesn't support unregister operation
 - Change printk() to DEBUG() in kexec path for avoiding dead lock due to logbuf_lock

 drivers/acpi/apei/erst.c
 - Add "reason" argument to erst_write()

TODO:
  - I don't have any access to machine capable of Memory Technology Device.
    Please help to test my patch.

  - I haven't implemented reader/eraser callbacks supported by pstore.
  - If mtdoops users would like to unload module,
    pstore needs to support unregister operation.

 Signed-off-by: Seiji Aguchi <sei...@hd...>

---
 drivers/acpi/apei/erst.c |    6 ++-
 drivers/mtd/Kconfig      |    1 +
 drivers/mtd/mtdoops.c    |   95 +++++++++++++++++++++++++++++++--------------
 fs/pstore/platform.c     |    5 +-
 include/linux/pstore.h   |    3 +-
 5 files changed, 75 insertions(+), 35 deletions(-)

diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index e6cef8e..ee936b6 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -933,7 +933,8 @@ static int erst_open_pstore(struct pstore_info *psi);
 static int erst_close_pstore(struct pstore_info *psi);
 static ssize_t erst_reader(u64 *id, enum pstore_type_id *type,
 		       struct timespec *time);
-static u64 erst_writer(enum pstore_type_id type, size_t size);
+static u64 erst_writer(enum pstore_type_id type, size_t size,
+		       enum kmsg_dump_reason reason);
 
 static struct pstore_info erst_info = {
 	.owner		= THIS_MODULE,
@@ -1037,7 +1038,8 @@ out:
 	return (rc < 0) ? rc : (len - sizeof(*rcd));
 }
 
-static u64 erst_writer(enum pstore_type_id type, size_t size)
+static u64 erst_writer(enum pstore_type_id type, size_t size,
+		       enum kmsg_dump_reason reason)
 {
 	struct cper_pstore_record *rcd = (struct cper_pstore_record *)
 					(erst_info.buf - sizeof(*rcd));
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index cc02e21..63a6e04 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -301,6 +301,7 @@ config SM_FTL
 
 config MTD_OOPS
 	tristate "Log panic/oops to an MTD buffer"
+	depends on PSTORE
 	help
 	  This enables panic and oops messages to be logged to a circular
 	  buffer in a flash partition where it can be read back at some
diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 56eac4e..61b1120 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
@@ -32,6 +32,7 @@
 #include <linux/interrupt.h>
 #include <linux/mtd/mtd.h>
 #include <linux/kmsg_dump.h>
+#include <linux/pstore.h>
 
 /* Maximum MTD partition size */
 #define MTDOOPS_MAX_MTD_SIZE (8 * 1024 * 1024)
@@ -54,6 +55,25 @@ 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 unsigned long total_size;
+static int mtdoops_open(struct pstore_info *psi);
+static int mtdoops_close(struct pstore_info *psi);
+static ssize_t mtdoops_reader(u64 *id, enum pstore_type_id *type,
+			       struct timespec *time);
+static u64 mtdoops_dumper(enum pstore_type_id type, size_t size,
+			  enum kmsg_dump_reason reason);
+static int mtdoops_eraser(u64 record_id);
+
+static struct pstore_info mtdoops_info = {
+	.owner          = THIS_MODULE,
+	.name           = "mtdoops",
+	.open           = mtdoops_open,
+	.close          = mtdoops_close,
+	.read           = mtdoops_reader,
+	.write          = mtdoops_dumper,
+	.erase          = mtdoops_eraser
+};
+
 static struct mtdoops_context {
 	struct kmsg_dumper dump;
 
@@ -229,8 +249,9 @@ static void mtdoops_write(struct mtdoops_context *cxt, int panic)
 					record_size, &retlen, cxt->oops_buf);
 
 	if (retlen != record_size || ret < 0)
-		printk(KERN_ERR "mtdoops: write failure at %ld (%td of %ld written), error %d\n",
-		       cxt->nextpage * record_size, retlen, record_size, ret);
+		DEBUG(MTD_DEBUG_LEVEL3, "mtdoops: write failure at %ld (%td of "
+		      "%ld written), error %d\n", cxt->nextpage * record_size,
+		      retlen, record_size, ret);
 	mark_page_used(cxt, cxt->nextpage);
 	memset(cxt->oops_buf, 0xff, record_size);
 
@@ -297,47 +318,62 @@ static void find_next_position(struct mtdoops_context *cxt)
 	mtdoops_inc_counter(cxt);
 }
 
-static void mtdoops_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 mtdoops_open(struct pstore_info *psi)
+{
+	return 0;
+}
+
+static int mtdoops_close(struct pstore_info *psi)
+{
+	return 0;
+}
+
+static ssize_t mtdoops_reader(u64 *id, enum pstore_type_id *type,
+			     struct timespec *time)
 {
-	struct mtdoops_context *cxt = container_of(dumper,
-			struct mtdoops_context, dump);
-	unsigned long s1_start, s2_start;
-	unsigned long l1_cpy, l2_cpy;
-	char *dst;
+	return -EINVAL;
+}
+
+static u64 mtdoops_dumper(enum pstore_type_id type, size_t size,
+			  enum kmsg_dump_reason reason)
+{
+	struct mtdoops_context *cxt = &oops_cxt;
 
 	if (reason != KMSG_DUMP_OOPS &&
-	    reason != KMSG_DUMP_PANIC)
-		return;
+	    reason != KMSG_DUMP_PANIC &&
+	    reason != KMSG_DUMP_KEXEC)
+		return 0;
 
 	/* Only dump oopses if dump_oops is set */
 	if (reason == KMSG_DUMP_OOPS && !dump_oops)
-		return;
-
-	dst = cxt->oops_buf + MTDOOPS_HEADER_SIZE; /* Skip the header */
-	l2_cpy = min(l2, record_size - MTDOOPS_HEADER_SIZE);
-	l1_cpy = min(l1, record_size - MTDOOPS_HEADER_SIZE - l2_cpy);
-
-	s2_start = l2 - l2_cpy;
-	s1_start = l1 - l1_cpy;
+		return 0;
 
-	memcpy(dst, s1 + s1_start, l1_cpy);
-	memcpy(dst + l1_cpy, s2 + s2_start, l2_cpy);
+	if (total_size >= record_size)
+		return 0;
 
 	/* Panics must be written immediately */
 	if (reason != KMSG_DUMP_OOPS) {
 		if (!cxt->mtd->panic_write)
-			printk(KERN_ERR "mtdoops: Cannot write from panic without panic_write\n");
-		else
+			DEBUG(MTD_DEBUG_LEVEL3, "mtdoops: Cannot write from "
+			      "panic without panic_write\n");
+		else {
 			mtdoops_write(cxt, 1);
-		return;
+			total_size = total_size + size + MTDOOPS_HEADER_SIZE;
+		}
+		return 0;
 	}
 
 	/* For other cases, schedule work to write it "nicely" */
 	schedule_work(&cxt->work_write);
+	return 0;
 }
 
+static int mtdoops_eraser(u64 record_id)
+{
+	return 0;
+}
+
+
 static void mtdoops_notify_add(struct mtd_info *mtd)
 {
 	struct mtdoops_context *cxt = &oops_cxt;
@@ -374,8 +410,10 @@ static void mtdoops_notify_add(struct mtd_info *mtd)
 		return;
 	}
 
-	cxt->dump.dump = mtdoops_do_dump;
-	err = kmsg_dump_register(&cxt->dump);
+	mutex_init(&mtdoops_info.buf_mutex);
+	mtdoops_info.buf = cxt->oops_buf + MTDOOPS_HEADER_SIZE;
+	mtdoops_info.bufsize = record_size - MTDOOPS_HEADER_SIZE;
+	err = pstore_register(&mtdoops_info);
 	if (err) {
 		printk(KERN_ERR "mtdoops: registering kmsg dumper failed, error %d\n", err);
 		vfree(cxt->oops_page_used);
@@ -396,9 +434,6 @@ static void mtdoops_notify_remove(struct mtd_info *mtd)
 	if (mtd->index != cxt->mtd_index || cxt->mtd_index < 0)
 		return;
 
-	if (kmsg_dump_unregister(&cxt->dump) < 0)
-		printk(KERN_WARNING "mtdoops: could not unregister kmsg_dumper\n");
-
 	cxt->mtd = NULL;
 	flush_work_sync(&cxt->work_erase);
 	flush_work_sync(&cxt->work_write);
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 061911c..cd42b4e 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -105,7 +105,8 @@ static void pstore_dump(struct kmsg_dumper *dumper,
 		memcpy(dst, s1 + s1_start, l1_cpy);
 		memcpy(dst + l1_cpy, s2 + s2_start, l2_cpy);
 
-		id = psinfo->write(PSTORE_TYPE_DMESG, hsize + l1_cpy + l2_cpy);
+		id = psinfo->write(PSTORE_TYPE_DMESG, hsize + l1_cpy + l2_cpy,
+				   reason);
 		if (reason == KMSG_DUMP_OOPS && pstore_is_mounted())
 			pstore_mkfile(PSTORE_TYPE_DMESG, psinfo->name, id,
 				      psinfo->buf, hsize + l1_cpy + l2_cpy,
@@ -220,7 +221,7 @@ int pstore_write(enum pstore_type_id type, char *buf, size_t size)
 
 	mutex_lock(&psinfo->buf_mutex);
 	memcpy(psinfo->buf, buf, size);
-	id = psinfo->write(type, size);
+	id = psinfo->write(type, size, 0);
 	if (pstore_is_mounted())
 		pstore_mkfile(PSTORE_TYPE_DMESG, psinfo->name, id, psinfo->buf,
 			      size, CURRENT_TIME, psinfo->erase);
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 5cf008d..47b974f 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -41,7 +41,8 @@ struct pstore_info {
 	int		(*close)(struct pstore_info *psi);
 	ssize_t		(*read)(u64 *id, enum pstore_type_id *type,
 			struct timespec *time);
-	u64		(*write)(enum pstore_type_id type, size_t size);
+	u64		(*write)(enum pstore_type_id type, size_t size,
+				 enum kmsg_dump_reason reason);
 	int		(*erase)(u64 id);
 };
 
-- 
1.7.1

[Dle-develop] [RFC][PATCH -mmotm 2/4] Remove mutex_lock from pstore in panic path

[Seiji A. <sei...@hd...>]

Hi,
 
This patch removes a function call chain of kmsg_dump and mutex_lock of pstore from panic path 
 so that both pstore and APEI storage backend can work reliably in panic path.

 kernel/kexec.c
   - Move kmsg_dump(KMSG_DUMP_PANIC) behind machine_crash_shutdown() so that pstore can
     work with one cpu.

 fs/pstore/platform.c
   pstore_dump()
   - Remove mutex_lock from panic path

 kernel/printk.c
   - Add spin_lock_init(&logbuf) for avoiding dead lock in panic path

TODO:
  APEI storage backend will work with this patch.
  However, I don't have any access to servers capable of APEI storage backend.
  Please help to test my patch.

 Signed-off-by: Seiji Aguchi <sei...@hd...>

---
 fs/pstore/platform.c |    3 ++-
 kernel/panic.c       |    4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c index 85e0a9c..061911c 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -75,6 +75,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
 		why = "Unknown";
 
 	switch (reason) {
+	case KMSG_DUMP_PANIC:
 	case KMSG_DUMP_KEXEC:
 		/* Skip if there is no driver or there is a driver calling
 		   pstore_register() */
@@ -114,7 +115,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
 		total += l1_cpy + l2_cpy;
 	}
 
-	if (reason != KMSG_DUMP_KEXEC)
+	if (reason != KMSG_DUMP_PANIC && reason != KMSG_DUMP_KEXEC)
 		mutex_unlock(&psinfo->buf_mutex);
 }
 
diff --git a/kernel/panic.c b/kernel/panic.c index 6923167..a9dce52 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -11,6 +11,7 @@
 #include <linux/debug_locks.h>
 #include <linux/interrupt.h>
 #include <linux/kmsg_dump.h>
+#include <linux/pstore.h>
 #include <linux/kallsyms.h>
 #include <linux/notifier.h>
 #include <linux/module.h>
@@ -88,14 +89,13 @@ NORET_TYPE void panic(const char * fmt, ...)
 	 */
 	crash_kexec(NULL);
 
-	kmsg_dump(KMSG_DUMP_PANIC);
-
 	/*
 	 * Note smp_send_stop is the usual smp shutdown function, which
 	 * unfortunately means it may not be hardened to work in a panic
 	 * situation.
 	 */
 	smp_send_stop();
+	pstore_kmsg_dump_in_interrupt(KMSG_DUMP_PANIC);
 
 	atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
 
--
1.7.1

[Dle-develop] [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Seiji A. <sei...@hd...>]

Hi,

This patch adds static function calls so that both pstore and APEI storage backend can work reliably in kexec path.


 kernel/kexec.c
   - Add pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC) just after machine_crash_shutdown() so that pstore can
     work with one cpu.

 kernel/printk.c
   - Introduce get_logbuf_nolock() so that pstore can get values of logbuf without taking lock.

 fs/pstore/platform.c
   - Introduce pstore_kmsg_dump_in_interrupt() so that pstore/APEI storage backend can output kernel messages without taking lock.
   pstore_dump()
   - Add error checks below because pstore_dump() is called from kmsg_dump(KMSG_DUMP_KEXEC) directly.
       - Skip if no driver is registered
       - Skip if there is a driver calling pstore_register()/pstore_unregister()
   - Remove mutex_lock from kexec path

TODO:
  APEI storage backend will work with this patch.
  However, I don't have any access to servers capable of APEI storage backend.
  Please help to test my patch.

 Signed-off-by: Seiji Aguchi <sei...@hd...>

---
 fs/pstore/platform.c      |   27 +++++++++++++++++++++++++--
 include/linux/kmsg_dump.h |    1 +
 include/linux/pstore.h    |    9 +++++++++
 kernel/kexec.c            |    3 +++
 kernel/printk.c           |   29 +++++++++++++++++++++++++++++
 5 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index f2c3ff2..85e0a9c 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -74,7 +74,17 @@ static void pstore_dump(struct kmsg_dumper *dumper,
 	else
 		why = "Unknown";
 
-	mutex_lock(&psinfo->buf_mutex);
+	switch (reason) {
+	case KMSG_DUMP_KEXEC:
+		/* Skip if there is no driver or there is a driver calling
+		   pstore_register() */
+		if (!psinfo || !spin_trylock(&pstore_lock))
+			return;
+		break;
+	default:
+		mutex_lock(&psinfo->buf_mutex);
+	}
+
 	oopscount++;
 	while (total < kmsg_bytes) {
 		dst = psinfo->buf;
@@ -103,7 +113,20 @@ static void pstore_dump(struct kmsg_dumper *dumper,
 		l2 -= l2_cpy;
 		total += l1_cpy + l2_cpy;
 	}
-	mutex_unlock(&psinfo->buf_mutex);
+
+	if (reason != KMSG_DUMP_KEXEC)
+		mutex_unlock(&psinfo->buf_mutex);
+}
+
+void pstore_kmsg_dump_in_interrupt(enum kmsg_dump_reason reason)
+{
+	const char *s1, *s2;
+	unsigned long l1, l2;
+
+	/* get logbuf values without spin_lock for avoiding dead lock */
+	get_logbuf_nolock(&s1, &l1, &s2, &l2);
+
+	pstore_dump(NULL, reason, s1, l1, s2, l2);
 }
 
 static struct kmsg_dumper pstore_dumper = {
diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
index fee6631..ee0c952 100644
--- a/include/linux/kmsg_dump.h
+++ b/include/linux/kmsg_dump.h
@@ -18,6 +18,7 @@
 enum kmsg_dump_reason {
 	KMSG_DUMP_OOPS,
 	KMSG_DUMP_PANIC,
+	KMSG_DUMP_KEXEC,
 	KMSG_DUMP_RESTART,
 	KMSG_DUMP_HALT,
 	KMSG_DUMP_POWEROFF,
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 2455ef2..5cf008d 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -22,6 +22,8 @@
 #ifndef _LINUX_PSTORE_H
 #define _LINUX_PSTORE_H
 
+#include<linux/kmsg_dump.h>
+
 /* types */
 enum pstore_type_id {
 	PSTORE_TYPE_DMESG	= 0,
@@ -46,6 +48,9 @@ struct pstore_info {
 #ifdef CONFIG_PSTORE
 extern int pstore_register(struct pstore_info *);
 extern int pstore_write(enum pstore_type_id type, char *buf, size_t size);
+extern void pstore_kmsg_dump_in_interrupt(enum kmsg_dump_reason reason);
+extern void get_logbuf_nolock(const char **s1, unsigned long *l1,
+			      const char **s2, unsigned long *l2);
 #else
 static inline int
 pstore_register(struct pstore_info *psi)
@@ -57,6 +62,10 @@ pstore_write(enum pstore_type_id type, char *buf, size_t size)
 {
 	return -ENODEV;
 }
+static inline void
+pstore_kmsg_dump_in_interrupt(enum kmsg_dump_reason reason)
+{
+}
 #endif
 
 #endif /*_LINUX_PSTORE_H*/
diff --git a/kernel/kexec.c b/kernel/kexec.c
index e24bc1b..8e2761a 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -33,6 +33,8 @@
 #include <linux/vmalloc.h>
 #include <linux/swap.h>
 #include <linux/syscore_ops.h>
+#include <linux/kmsg_dump.h>
+#include <linux/pstore.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>
@@ -1081,6 +1083,7 @@ void crash_kexec(struct pt_regs *regs)
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
+			pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC);
 			machine_kexec(kexec_crash_image);
 		}
 		mutex_unlock(&kexec_mutex);
diff --git a/kernel/printk.c b/kernel/printk.c
index 37dff34..966a7d9 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1710,6 +1710,35 @@ int kmsg_dump_unregister(struct kmsg_dumper *dumper)
 }
 EXPORT_SYMBOL_GPL(kmsg_dump_unregister);
 
+
+void get_logbuf_nolock(const char **s1, unsigned long *l1, const char **s2,
+		       unsigned long *l2)
+{
+	unsigned long end;
+	unsigned chars;
+
+	/* Theoretically, the log could move on after we do this, but
+	   there's not a lot we can do about that. The new messages
+	   will overwrite the start of what we dump. */
+	end = log_end & LOG_BUF_MASK;
+	chars = logged_chars;
+
+	if (chars > end) {
+		*s1 = log_buf + log_buf_len - chars + end;
+		*l1 = chars - end;
+
+		*s2 = log_buf;
+		*l2 = end;
+	} else {
+		*s1 = "";
+		*l1 = 0;
+
+		*s2 = log_buf + end - chars;
+		*l2 = chars;
+	}
+
+}
+
 /**
  * kmsg_dump - dump kernel log to kernel message dumpers.
  * @reason: the reason (oops, panic etc) for dumping
-- 
1.7.1

[Dle-develop] [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Seiji A. <sei...@hd...>]

Hi,

[Upstream status]
   Discussion about kmsg_dump() in kdump path: 
    - Eric and Vivek are worried about reliability of existing kmsg_dump().
    - Especially, Vivek would like to remove a RCU  function call chain in kdump path
　　　 which kernel modules can register their function calls freely. 

   Discussion about pstore in nmi_hander.
    - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.
    

[Build Status]
  Built this patch on 3.0.0-rc6-mm1 in x86_64.

[Patch Description]

 For meeting Eric/Vivek's requirements and solving an issue of pstore in nmi_hander due to mutex_lock,
 I propose following patches.

  [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

        Some people who are not familiar with kexec may add function calls getting 
        spin_lock/mutex_lock in kexec path. These function calls causes failure of kexec. 
        So, I suggest replace a call chain with static function calls so that we can keep 
        reliability of kexec.

        APEI storage backend will work well in kexec path by applying this patch.

        Summary of this patch:
        - Call pstore_kmsg_dump_in_interrupt() directly in kexec path
        - Remove mutex_lock in pstore_dump() of kexec path

  [RFC][PATCH -mmotm 2/4] Remove mutex_lock from pstore in panic path

        Pstore must not take mutex_lock in panic path as well as kexec path 
        because panic() is called in interrupt context like nmi_handler.
        APEI storage backend will work well in panic path with this patch.

        Summary of this patch:
        - Remove kmsg_dump(KMSG_DUMP_PANIC)
        - Call pstore_kmsg_dump_in_interrupt() directly in panic path
        - Remove mutex_lock in pstore_dump() of panic path

  [RFC][PATCH -mmotm 3/4] pstore: mtdoops support

        - Pstore can support mtdoops with this patch.

  [RFC][PATCH -mmotm 4/4] pstore: ramoops support

        - Pstore can support ramoops with this patch.

[Dle-develop] Una entrada para concierto del festival de música Samamadrid por solo 10€, tonifícate y adelgaza por tan solo 10€, circuito de arborismo por 15€ y más ofertas solidarias

[MyBonusWeb S. <ne...@my...>]

	



	



 in...@my... a tu libreta
de direcciones y llegaremos siempre a tu bandeja de entrada.
							


							



								
									Ofertas Solidarias en Tu Ciudad

								Sé solidario, colabora con los que lo necesitan solo con tu email
								
							


							



							



								
50% Dto. Una entrada para concierto del Festival de Música Samamadrid

Disfruta
de la música...

								
								
							


									SOLO: 10,00€
							


							




									original:
20€

								
								50%
								
								10,00€
							




								
								
								
								
							


								
								

										Relájate y disfruta de la música en el Festival de Música Antigua de Samamadrid. Varios conciertos durante todo el mes de Julio, de estilos similares y con los mejores artistas de música antigua.¡Consigue tu MyBonus
Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
50% Dto. Ya no tienes excusa para lucir tu mejor figura

Presume de cuerpo este
verano...

								
								
							


									SOLO: 10,00€
							


							




									original:
20€

								
								50%
								
								10,00€
							




								
								
								
								
							


								
								

										Tonifícate, adelgaza y mejora tu flexibilidad sin apenas realizar esfuerzo. Prueba este nuevo sistema de Gimnasia Asistida para recuperar tu línea sin cansarte¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
50% Dto.Circuito de arborismo de aproximadamente 3 horas.

Aventura divertida por un
precio increíble...

								
								
							


									SOLO: 15,00€
							


							




									original:
30€

								
								50%
								
								15,00€
							




								
								
								
								
							


								
								

										¿Te gustan las aventuras? Consigue esta aventura por un increíble precio, Arborismo durante 3 horas aproximadamente con diferentes modalidades de recorrido. Para niños o adultos que midan más de 1,50 cm de altura.¡Consigue tu
MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
60% Dto. Consigue unos brillos espectaculares sin dañar tu cabello

Oferta
espectacular!

								
								
							


									SOLO: 24,00€
							


							




									original:
60€

								
								60%
								
								36,00€
							




								
								
								
								
							


								
								

										Dale a tu pelo un aspecto cuidado y bonito con los Velos de Color (Valido para cabellos teñidos y naturales)¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 6 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



								
								
								
								
							



							


								Si
nos referencias a tus amigos o familiares todos tendréis un gran descuento en la compra de vuestros ¡MyBonus!
								
								
									Sé el primero en recibir nuestras ofertas, para ello haz click en tu ciudad:

Madrid · Barcelona · Bilbao · Valencia · Zaragoza · Sevilla · Málaga · A Coruña · Mallorca · Alicante · Las Palmas · Valladolid · Córdoba · Granada · Oviedo · Otra

								
							




							


Descuentos solidarios de hasta el 90% en tu ciudad
www.mybonusweb.com

							


									Actualmente estás suscrito a este boletín con la cuenta (dle...@li...). Tus datos se encuentran recogidos en un fichero automatizado cuyo responsable es Mybonus Experience S.L., a través de la web www.mybonusweb.com podrás ejercitar los derechos de acceso, rectificación, cancelación y oposición. Todo ello en cumplimiento de lo dispuesto en la Ley Orgánica 15/1999,
de 13 de Diciembre de Protección de Datos de Carácter Personal.


									Por favor no respondas a este mail. Si tienes cualquier duda o sugerencia contacta con in...@my... (in...@my...) 

									Si NO deseas recibir las fantásticas ofertas solidarias de tu ciudad con las que tienes un ahorro de hasta el 90% y además ayudas a proyectos solidarios, haz click aquí

							


							


			

Re: [Dle-develop] [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[Vivek G. <vg...@re...>]

On Sat, Jul 16, 2011 at 09:16:06AM -0700, Eric W. Biederman wrote:

[..]
> Am I wrong in thinking that the core motivation behind this patch is
> that our EFI support sucks and thus kdump on EFI does not work on some
> platforms?

One of the arguments seems is that kdump might not work 100% of the
time and saving kernel messages atleast gets some information out
reliably.

I think being able to save dmesg to NVRAM, in general sounds good to
me (if done in a relatively clean manner). Especially if we can get
rid of code taking locks and code path executed after crash is not
tool long and relatively easy to audit.

Thanks
Vivek

[Dle-develop] Broncea tu piel por solo 35€, cena con alguien en la playa por tan solo 56€, limpieza de cutis completa por solo 19€ y más ofertas solidarias

[MyBonusWeb S. <ne...@my...>]

	



	



 in...@my... a tu libreta
de direcciones y llegaremos siempre a tu bandeja de entrada.
							


							



								
									Ofertas Solidarias en Tu Ciudad

								Sé solidario, colabora con los que lo necesitan solo con tu email
								
							


							



							



								
30% Dto. Consigue un moreno espectacular

Broncea tu piel...

								
								
							


									SOLO: 35,00€
							


							




									original:
50€

								
								30%
								
								15,00€
							




								
								
								
								
							


								
								

										Dale tono a tu piel con el bronceado de rayos UVA. 10 sesiones a un precio espectacular para que puedas estar moreno sin tomar el sol.¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
35% Dto. Comparte este menú en el mejor chiringuito de la playa de Barcelona

Cena con alguien en la playa...

								
								
							


									SOLO: 56,00€
							


							




									original:
86€

								
								35%
								
								30,00€
							




								
								
								
								
							


								
								

										Disfruta en el mejor chiringuito de la playa de Barcelona, de una cena en una ubicación única.¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
52% Dto.Prepara tu piel para el verano con una limpieza de cutis completa

Una piel
suave y bonita...

								
								
							


									SOLO: 19,00€
							


							




									original:
40€

								
								52%
								
								21,00€
							




								
								
								
								
							


								
								

										Luce una bonita piel este verano con este tratamiento Disfruta de esta limpieza de cutis con los mejores productos naturales y ademas llévate de regalo una crema hidratante según tu tipo de piel ¡Consigue tu MyBonus
Ya!
									
										Con reserva previa. Validez del MyBonus, 3 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



							



								
50% Dto. Disfruta de unas uñas elegantes, cuidadas y bonitas

Luce tus uñas
como nunca...

								
								
							


									SOLO: 10,00€
							


							




									original:
20€

								
								50%
								
								10,00€
							




								
								
								
								
							


								
								

										Muestra tus manos perfectas hasta el más mínimo detalle gracias a la manicura con decoración a pincel que te ofrece Toscano Estilistas. ¡Consigue tu MyBonus Ya!
									
										Con reserva previa. Validez del MyBonus, 6 meses.
								
								
								
							


								
								
								
								
							


								
								
								
								
							



								
								
								
								
							



							


								Si
nos referencias a tus amigos o familiares todos tendréis un gran descuento en la compra de vuestros ¡MyBonus!
								
								
									Sé el primero en recibir nuestras ofertas, para ello haz click en tu ciudad:

Madrid · Barcelona · Bilbao · Valencia · Zaragoza · Sevilla · Málaga · A Coruña · Mallorca · Alicante · Las Palmas · Valladolid · Córdoba · Granada · Oviedo · Otra

								
							




							


Descuentos solidarios de hasta el 90% en tu ciudad
www.mybonusweb.com

							


									Actualmente estás suscrito a este boletín con la cuenta (dle...@li...). Tus datos se encuentran recogidos en un fichero automatizado cuyo responsable es Mybonus Experience S.L., a través de la web www.mybonusweb.com podrás ejercitar los derechos de acceso, rectificación, cancelación y oposición. Todo ello en cumplimiento de lo dispuesto en la Ley Orgánica 15/1999,
de 13 de Diciembre de Protección de Datos de Carácter Personal.


									Por favor no respondas a este mail. Si tienes cualquier duda o sugerencia contacta con in...@my... (in...@my...) 

									Si NO deseas recibir las fantásticas ofertas solidarias de tu ciudad con las que tienes un ahorro de hasta el 90% y además ayudas a proyectos solidarios, puedes enviar un email desde tu cuenta a: ba...@my...
							


							


			

Re: [Dle-develop] [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[Matthew G. <mj...@re...>]

On Sat, Jul 16, 2011 at 01:11:47PM -0700, Eric W. Biederman wrote:

> Without some real understanding of what is going on I'm not inclined
> to meet any of this half way and summarily reject every change to
> the kexec on panic code path.

There are platforms that simply refuse to correctly function with a 1:1 
physical/virtual mapping. But that's not the point here - this patch 
simply hardcodes saving dmesg to an EFI variable rather than using 
kmsg_dump and pstore in order to avoid handling the locking, and does 
nothing whatsoever to change the amount of EFI code involved.

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[<ebi...@xm...>]

Matthew Garrett <mj...@re...> writes:

2> On Sat, Jul 16, 2011 at 09:16:06AM -0700, Eric W. Biederman wrote:
>
>> What is going on with EFI support?  We are still making efi calls in
>> virtual mode, and we don't have the one unified identity mapped physical
>> page table that hpa and I think others were working a while back.  Even
>> if because of bugs we need to transition EFI to virtual mode we can
>> still set physical to virtual so we don't have to deal with the nonsense.
>
> No, we can't. It doesn't work.
>
>> Can we please make our EFI support ask the minimal from EFI before
>> adding lots more to it?
>
> No.
>
>> Am I wrong in thinking that the core motivation behind this patch is
>> that our EFI support sucks and thus kdump on EFI does not work on some
>> platforms?
>
> Yes, you are.

Will someone please give some explanation?

Without some real understanding of what is going on I'm not inclined
to meet any of this half way and summarily reject every change to
the kexec on panic code path.

Eric

Re: [Dle-develop] [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[Matthew G. <mj...@re...>]

On Sat, Jul 16, 2011 at 09:16:06AM -0700, Eric W. Biederman wrote:

> What is going on with EFI support?  We are still making efi calls in
> virtual mode, and we don't have the one unified identity mapped physical
> page table that hpa and I think others were working a while back.  Even
> if because of bugs we need to transition EFI to virtual mode we can
> still set physical to virtual so we don't have to deal with the nonsense.

No, we can't. It doesn't work.

> Can we please make our EFI support ask the minimal from EFI before
> adding lots more to it?

No.

> Am I wrong in thinking that the core motivation behind this patch is
> that our EFI support sucks and thus kdump on EFI does not work on some
> platforms?

Yes, you are.

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[<ebi...@xm...>]

Seiji Aguchi <sei...@hd...> writes:

> Hi,
>
> [Background]
>  - Requirement in enterprise area
>  From our support service experience, we always need to detect root causes of OS panic.
>  Because customers in enterprise area never forgive us if kdump fails and  we can't detect
>  root causes of panic due to lack of materials for investigation.
>
>  That is why I would like to add kmsg_dump() in kdump path.

You are whittling this down to something that has a chance of being
useful, but the code still has a ways to go.

It is good that you have managed to run tests that on one hardware
platform the firmware is reliable and that this does not reduce the odds
of kexec.  Your starting assertion however is that you can not do this
in the kernel started by kexec on panic because kexec on panic is
unreliable.  You don't have test cases that show your code working
when the kexec on panic kernel does not.

Calling out to EFI continues not to inspire my confidence that this
code will work on a wide variety of hardware platforms.

What is going on with EFI support?  We are still making efi calls in
virtual mode, and we don't have the one unified identity mapped physical
page table that hpa and I think others were working a while back.  Even
if because of bugs we need to transition EFI to virtual mode we can
still set physical to virtual so we don't have to deal with the nonsense.

Can we please make our EFI support ask the minimal from EFI before
adding lots more to it?

Am I wrong in thinking that the core motivation behind this patch is
that our EFI support sucks and thus kdump on EFI does not work on some
platforms?

Eric

Re: [Dle-develop] [RFC PATCH 0/4] Persistent device name using alias name

[Nao N. <nao...@hi...>]

Hi, Karel

Thank you for your comments.

(2011/07/15 21:48), Karel Zak wrote:
> On Fri, Jul 15, 2011 at 03:55:02PM +0900, Nao Nishijima wrote:
>>>  If there is not /dev/foo and /sys/block/foo then the patch introduces
>>>  a REGRESSION. 
>>>  
>>>  The names from /proc/partitions are used in many applications
>>>  (libblkid, fdisk, ...) for many many years. The applications will not
>>>  work as expected.
>>>
>>
>> I think that it is not a regression when users do not set an alias name.
>> Of course, I am going to modify all these utils so that users can use
>> alias names.
>>
>> The purpose of alias names is to unify the name of device which users
>> operate and see. Therefore, I think that users would like to get an
>> alias name from it, because currently they get a device name form it.
>>
>> However, for who wants to use alias name only for dmesg, I have an
>> enhancement idea that users can choose alias names or device names in
>> procfs by sysctl (default is device names).
> 
>>From my point of view
> 
>     dmesg | grep <alias>
> 
> seems a little bit problematic, because for example initial messages
> for the device will be invisible. In the log will be messages with
> original canonical names and another (later) messages with aliases, you
> can also change the alias, etc. Seems like a mess. The log should be
> consistent...
> 
> I think it would be better to use always only canonical names in the
> kernel log and translate to something more user-friendly in userspace.
> For example if you add some meta-information to the kernel log then we
> can improve dmesg(1) to translate the canonical names to aliases.
> 
>  printk(KERN_INFO "this is info about %{device}s", device);
> 
>  <5>[105221.774534]{device=sda} this is info about sda
> 
> or whatever... (this is a nice topic with many colors for the bike
> shed:-)
> 
>> I would like to hear your opinion about this.
> 
> If you want to modify all the userspace utils then you don't have to
> modify /proc/partitions :-)
> 
> You can keep the standard names in /proc/partitions (so the file will
> be compatible with /sys and /dev) and you can modify all the utils to
> translate the canonical device names to aliases. The result will be
> the same, except "cat /proc/partitions" -- but I think that instead of
> "cat" you can use "lsblk".
> 

"lsblk" is great. (Sorry, I didn't know this command until now)

I think it would be good that users can get alias name from BOTH of
"lsblk" and "/proc/partitions", because users expect to see same name in
kernel output and command output　as they can see now.

In kernel message, I think that "alias name" is necessary. Because those
logs are output when kernel crashes, it outputs kernel message to serial
console. In that case, it's hard to convert canonical device name to
alias name.

> If you add only the attribute (alias name) to the /sys then you don't
> have to care if all the utils are already modified.
> 
> Anyway, I still agree with Kay and Greg -- the proper solution
> is to improve printk() and dmesg(1). The aliases could be implemented 
> in userspace by udev /dev/disk/by-alias/<cool_name> symlinks.
> 

Best regards,

-- 
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research  Laboratory
Email： nao...@hi...