lkml.org 
[lkml]   [2005]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Provide better printk() support for SMP machines
    Date
    Andrew Morton <akpm@osdl.org> 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
    unsigned:-/

    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.

    David
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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