lkml.org 
[lkml]   [2000]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH #2] console lock grabbed too early in printk...
    Date
    Chris Lattner writes:
    > 6. Poor judgement and placement of printk's can lead to recursive
    > printk's.

    With the stock kernel and the non-user pointer rule, the only way to
    cause this is to put a printk in either printk itself, or the console
    print function. In this case, no amount of changes to the locking will
    fix this. In fact, trying to fix it makes it far worse.

    > 5. As such, a kernel developer may not invest as much thought into printk
    > placement as, say, a new buffer cache design.

    With what I've said above, the kernel developer would have to be very
    dumb to put a printk in those places. It's almost on the level of doing:

    void a(void)
    {
    b();
    }

    void b(void)
    {
    a();
    }

    > Personally, I don't care which one is used, I just don't want to get
    > burned again in the future.

    The rules:

    1. Don't pass user addresses to printk
    2. Don't call printk from the low-level console print routes

    If this rules are followed, you will not get burned.
    _____
    |_____| ------------------------------------------------- ---+---+-
    | | Russell King rmk@arm.linux.org.uk --- ---
    | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
    | +-+-+ --- -+-
    / | THE developer of ARM Linux |+| /|\
    / | | | --- |
    +-+-+ ------------------------------------------------- /\\\ |

    -
    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.022 / U:0.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site