lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH #2] console lock grabbed too early in printk...
> >Wait, back up, let me get this straight.  There are two situations here:
> >1. Recursive printk occurs before kmalloc is initialized:
> >You claim that a panic is WORSE for debugging that an undetected deadlock
> >is? How does that assist with debugging???

> The deadlock shows up in printk where the problem is obvious. A call
> to kmalloc before it is ready will break somewhere else in kernel, well
> away from the real problem and harder to debug. I have absolutely no
> objection to removing the deadlock, but calling extra functions from
> printk is wrong.

How does one detect deadlock? This is a serious question, because I am
obviously pretty miserable at it. :) In my case, I had a page fault
interrupting my stack trace so I couldn't "see" events going all the way
back to when the kernel thread initially grabbed that lock...

> >2. Recursive printk occurs after kmalloc is initialized:
> >You claim that merely counting the failed messages is better than doing
> >_THE_RIGHT_THING_ is every case except OOM (which would be treated quite
> >similarly to what you are describing....

> If kmalloc ever calls back to printk then you get recursion and blow
> the kernel stack, again confusing the original problem. There are

okay, understood. :) In my patch "#3" I take an approach that is
basically what you describe... I tally up the counts and then print out
the missed message count when the next successful printk comes around...

> >btw, if nothing else, why not just print out the format str on OOM? That
> >way you don't even need a buffer...
>
> Possible, except that one of the things that the console lock does is
> stop multiple cpus writing to the console at the same time. Bypass the
> console lock to do output and you get overlapping text under SMP - hard
> to read.

What I was thinking is that I could save a pointer to the message format
string and then print it out later... upon further thought it's pretty
obvious that the format string might not be around any longer... and to be
safe I'd have to make a copy... back to the original problem! :)

-Chris


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:1.251 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site