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...
> >Is there a kmalloc flag that you can pass that says not to sleep?  I'm not
> >too familiar with that area...

> GFP_ATOMIC, see Documentation/DocBook/kernel-hacking.tmpl, but then you

Thanks!

> have to test for kmalloc failing. What do you do if kmalloc fails?
> Drop the message and report that you dropped it. Instead of calling
> extra kernel services from what was previously a leaf function, just
> report lost messages as a bug.

Yes, that is what I would do... if printk is being recursively called AND
kmalloc can't help us out... then we really have problems. :)

> Anything that complicates printk is a Bad Idea (TM), too many bits of
> kernel code assume that printk works under all circumstances.
> Detecting and avoiding deadlock is good, calling other kernel functions
> from printk is bad.

Agreed, except that this only occurs for one specific case that *induces
deadlock* right now, and is only likely to be run into when debugging
stuff (ie lots of printk's are added)... let me add emphasis
here: SEMANTICS/INVOKED FUNCTIONS ARE CHANGED FOR ANY CASES THAT DOES NOT
CURRENTLY INDUCE DEADLOCK. As such, I see no problem with just "BUG"ing
if we are really screwed.

-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:0.046 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site