On Fri, 2007-09-21 at 17:02 +0100, Paulo Marques wrote:
> Gilboa Davara wrote:
> > Hello all,
>
> Hi, Gilboa
>
> > (1) Problem:
> > I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on
> > i386 kernels, do_IRQ calls dump_stack which, down the path, uses
> > print_symbol (display)
Gilboa Davara wrote:
Hello all,
Hi, Gilboa
(1) Problem:
I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on
i386 kernels, do_IRQ calls dump_stack which, down the path, uses
print_symbol (display) and sprint_symbol (format) to format and display
the function name/address/mod
Steven Rostedt wrote:
On Wed, Sep 19, 2007 at 03:25:15PM +0100, Paulo Marques wrote:
if we change the interface from "print_symbol(fmt, addr)" to
"print_symbol(prefix, addr, int newline)" we can simply do:
printk(prefix);
printk_symbol(addr);
if (newline)
printk("\n");
NACK
I just w
On Fri, 2007-09-21 at 15:21 +0100, Paulo Marques wrote:
> Gilboa Davara wrote:
> > Hello Paulo,
>
> Hi, Gilboa
>
> Usually the developer can separate the output by hand in the unlikely
> case of simultaneous concurrent users of printk, so I don't think this
> is really a big problem.
In genera
On Wed, Sep 19, 2007 at 03:25:15PM +0100, Paulo Marques wrote:
>
> if we change the interface from "print_symbol(fmt, addr)" to
> "print_symbol(prefix, addr, int newline)" we can simply do:
>
> printk(prefix);
> printk_symbol(addr);
> if (newline)
> printk("\n");
NACK
I just wrote somethin
On Fri, 2007-09-21 at 10:47 -0400, Steven Rostedt wrote:
> On Sat, Sep 15, 2007 at 02:35:29PM +0300, Gilboa Davara wrote:
> > - return sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
> > + if (namebuf)
> > + kfree(namebuf);
>
> Note, the if condition is not needed, kfree
On Sat, Sep 15, 2007 at 02:35:29PM +0300, Gilboa Davara wrote:
> - return sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
> + if (namebuf)
> + kfree(namebuf);
Note, the if condition is not needed, kfree handles null pointers fine.
-- Steve
-
To unsubscribe from th
Hello all,
(1) Problem:
I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on
i386 kernels, do_IRQ calls dump_stack which, down the path, uses
print_symbol (display) and sprint_symbol (format) to format and display
the function name/address/module.
Both function use stack based ch
Gilboa Davara wrote:
Hello Paulo,
Hi, Gilboa
[snip]
[...]
if we change the interface from "print_symbol(fmt, addr)" to
"print_symbol(prefix, addr, int newline)" we can simply do:
printk(prefix);
printk_symbol(addr);
if (newline)
printk("\n");
where "printk_symbol" is a new functi
Hello Paulo,
[snip]
> I must say I agree with Satyam here.
>
> Locking in the panic path might leave us without some critical debug
> information, which is much more important than all this.
>
> Maybe it would be better to change the print_symbol interface to avoid
> having a "char buffer[KSYM
Hello Satyam,
On Wed, 2007-09-19 at 06:30 +0530, Satyam Sharma wrote:
> Hi Gilboa,
>
>
> On Sat, 15 Sep 2007, Gilboa Davara wrote:
> >
> > This is my second stab at solving the "stack over flow due to
> > dump_strace when close to stack-overflow is detected by do_IRQ" problem.
> > (Hopefully)
Satyam Sharma wrote:
On Sat, 15 Sep 2007, Gilboa Davara wrote:
printk(fmt, buffer);
+
+ spin_unlock_irqrestore(&symbol_lock, flags);
But I still don't much like this :-(
I must say I agree with Satyam here.
Locking in the panic path might leave us without some critical debug
Hi Gilboa,
On Sat, 15 Sep 2007, Gilboa Davara wrote:
>
> This is my second stab at solving the "stack over flow due to
> dump_strace when close to stack-overflow is detected by do_IRQ" problem.
> (Hopefully) this patch is creates less noise then the previous one.
>
> [snip]
> > I'll try and cre
Hello all, Satyam,
This is my second stab at solving the "stack over flow due to
dump_strace when close to stack-overflow is detected by do_IRQ" problem.
(Hopefully) this patch is creates less noise then the previous one.
[snip]
> I'll try and create an option 2 (static allocation, minimal lockin
On Sat, 2007-09-15 at 18:32 +0530, Satyam Sharma wrote:
> Hi,
>
>
> On 9/15/07, Gilboa Davara <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
> > out a possible stack overflow... when CONFIG_DEBUG_STACKOVERFLOW is
> > enable
Hi,
On 9/15/07, Gilboa Davara <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
> out a possible stack overflow... when CONFIG_DEBUG_STACKOVERFLOW is
> enabled. (Though not limited to it)
Yeah, I have experienced this phenomenon/pr
Hello all,
In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
out a possible stack overflow... when CONFIG_DEBUG_STACKOVERFLOW is
enabled. (Though not limited to it)
Code path is simple: do_IRQ detects a a near stack overflow condition
and calls show_trace_log_lvl which, down
17 matches
Mail list logo
