Messages in this thread | | | Date | Sun, 2 Jul 2000 00:20:14 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [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/
| |