Re: [PATHC] 3.6 spinlock fix
On Fri, 15 Feb 2013, Tim Sander wrote: > > On Thu, Feb 14, 2013 at 5:35 PM, Thomas Gleixner wrote: > > > On Thu, 14 Feb 2013, Tim Sander wrote: > > >> > That's true, but w/o seing the OOM output I can't tell what's > > >> > exhausting the memory. > > >> > > >> When fuzzing the serial port one probably should switch of sysreq. It > > >> seems > > >> as if there is a break send somehow and then it selects the OOM option. > > >> So when switching of MAGIC_SYSRQ the OOMs are gone. So its a non issue. > > > > > > Amazing that you get the break+oom combo out of that fuzzer! > That fuzzer is running at 57600Hz while the serial port of the fuzzed device > is > running twice that rate. The break condition seems to be easy hit by the > fuzzer > i've sent in a previous mail. > > Doing a basic "git whatchanged" and searching for "trinity" is rather > > impressive, regardless of the kernel version and/or where "rogue states" > > may currently be at with their "program" Kudos to davej for that. > Mh, but thats not trinity! Havn't tried that but well fuzzing at a different > serial rate than the receiver might be a good idea even if it sounds pretty > stupid. > > Attached is the patch for the 3.6.9-rt kernel (but i think this should also > apply > to the "normal" 3.6 i guess). But as Greg already took care of this patch i > guess > that only for convinience. Also it seems as if the patch sent to Greg is > missing the > #include ? Errm, no. The in_kdb_printk() is an RT specific issue, so I left it out for the mainline fix. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATHC] 3.6 spinlock fix
On Fri, 15 Feb 2013, Tim Sander wrote: On Thu, Feb 14, 2013 at 5:35 PM, Thomas Gleixner t...@linutronix.de wrote: On Thu, 14 Feb 2013, Tim Sander wrote: That's true, but w/o seing the OOM output I can't tell what's exhausting the memory. When fuzzing the serial port one probably should switch of sysreq. It seems as if there is a break send somehow and then it selects the OOM option. So when switching of MAGIC_SYSRQ the OOMs are gone. So its a non issue. Amazing that you get the break+oom combo out of that fuzzer! That fuzzer is running at 57600Hz while the serial port of the fuzzed device is running twice that rate. The break condition seems to be easy hit by the fuzzer i've sent in a previous mail. Doing a basic git whatchanged and searching for trinity is rather impressive, regardless of the kernel version and/or where rogue states may currently be at with their program Kudos to davej for that. Mh, but thats not trinity! Havn't tried that but well fuzzing at a different serial rate than the receiver might be a good idea even if it sounds pretty stupid. Attached is the patch for the 3.6.9-rt kernel (but i think this should also apply to the normal 3.6 i guess). But as Greg already took care of this patch i guess that only for convinience. Also it seems as if the patch sent to Greg is missing the #include linux/kdb.h? Errm, no. The in_kdb_printk() is an RT specific issue, so I left it out for the mainline fix. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATHC] 3.6 spinlock fix
Hi > On Thu, Feb 14, 2013 at 5:35 PM, Thomas Gleixner wrote: > > On Thu, 14 Feb 2013, Tim Sander wrote: > >> > That's true, but w/o seing the OOM output I can't tell what's > >> > exhausting the memory. > >> > >> When fuzzing the serial port one probably should switch of sysreq. It > >> seems > >> as if there is a break send somehow and then it selects the OOM option. > >> So when switching of MAGIC_SYSRQ the OOMs are gone. So its a non issue. > > > > Amazing that you get the break+oom combo out of that fuzzer! That fuzzer is running at 57600Hz while the serial port of the fuzzed device is running twice that rate. The break condition seems to be easy hit by the fuzzer i've sent in a previous mail. > Doing a basic "git whatchanged" and searching for "trinity" is rather > impressive, regardless of the kernel version and/or where "rogue states" > may currently be at with their "program" Kudos to davej for that. Mh, but thats not trinity! Havn't tried that but well fuzzing at a different serial rate than the receiver might be a good idea even if it sounds pretty stupid. Attached is the patch for the 3.6.9-rt kernel (but i think this should also apply to the "normal" 3.6 i guess). But as Greg already took care of this patch i guess that only for convinience. Also it seems as if the patch sent to Greg is missing the #include ? Best regards Tim tglx: fix imx.c spinlock diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index e309e8b..39820ea 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -1213,8 +1214,12 @@ imx_console_write(struct console *co, const char *s, unsigned int count) struct imx_port_ucrs old_ucr; unsigned int ucr1; unsigned long flags; + int locked = 1; - spin_lock_irqsave(>port.lock, flags); + if (sport->port.sysrq || oops_in_progress || in_kdb_printk()) + locked = spin_trylock_irqsave(>port.lock, flags); + else + spin_lock_irqsave(>port.lock, flags); /* * First, save UCR1/2/3 and then disable interrupts @@ -1241,7 +1246,8 @@ imx_console_write(struct console *co, const char *s, unsigned int count) imx_port_ucrs_restore(>port, _ucr); - spin_unlock_irqrestore(>port.lock, flags); + if (locked) + spin_unlock_irqrestore(>port.lock, flags); } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
