> >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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST