[lkml]   [2005]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Provide better printk() support for SMP machines
    Andrew Morton <> wrote:

    > hm, I guess it adds a theoretical deadlock if some other CPU is in the
    > middle of printk and is trying to take some_lock and this CPU takes an oops
    > while holding some_lock. Probably that's an acceptable tradeoff though.

    What it perhaps needs is a maximum number of spins or something like that.

    > Does this guy really need to be volatile?

    atomic_t is volatile, so that makes no difference.

    Actually, I shouldn't use an atomic_t or a signed int as the CPU ID is

    I'm using -1 / UINT_MAX as a "not in use" thing, but I'm not sure that's
    strictly viable.

    > Coud we use atomic_t and lose that wmb()?

    I talked it over with David Woodhouse, and he's convinced me that we don't
    need the barrier: the only thing we care about is getting a printk within a
    printk on the CPU because of an oops. THEN we have to break the lock. And in
    that case we're looking for the CPU number being set to that of our CPU, and
    only our CPU will ever set that.

    > Methinks this should be raw_smp_processor_id().

    Not only that, but the whole function needs wrapping in preemption
    disablement, lest the processor ID change under us.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-07-08 14:35    [W:0.019 / U:11.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site