lkml.org 
[lkml]   [2002]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH]Timer list init is done AFTER use
    Andrew Morton wrote:
    >
    > george anzinger wrote:
    > >
    > > Andrew Morton wrote:
    > > >
    > > > george anzinger wrote:
    > > > >
    > > > > On SMP systems the timer list init is done by way of a
    > > > > cpu_notifier call. This has two problems:
    > > > >
    > > > > 1.) Timers are started WAY before the cpu_notifier call
    > > > > chain is executed. In particular the console blanking timer
    > > > > is deleted and inserted every time printk() is called. That
    > > > > this does not fail is only because the kernel has yet to
    > > > > protect location zero.
    > > >
    > > > But init_timers() directly calls timer_cpu_notify(), which directly
    > > > calls init_timers_cpu().
    > > >
    > > > So your patch appears to be a no-op for the boot CPU.
    > >
    > > That is correct. The problem is when cpu_init is called for
    > > the secondary cpus. It almost immediately calls printk.
    >
    > OK. So until that CPU sees it bit come on in smp_commenced_mask()
    > it's not allowed to assume that it is running yet.
    >
    > > ...
    > > My comments here are a wonderment if
    > > this is the right thing to do when doing a hot swap of the
    > > cpu. I sort of doubt that this is correct.
    >
    > I agree. And from a quick read it does seem that ia32 is
    > doing the right thing apart from calling printk.
    >
    > I don't think we should make changes to the timer code because
    > who knows what assumptions other console drivers could be making?
    >
    > I don't think we should carefully remove all printk() calls because
    > printk() is supposed to be robust, and always callable.
    >
    > The logical thing is to implement arch_consoles_callable(). Does
    > this look workable?

    I am not sure. The first question is when does the online
    bit get set for cpu 0. The next is that it does inhibit a
    rather large block of printks. Is this ok?

    Mind you, I have not tried it yet...

    -g
    >
    > --- 25/kernel/printk.c~ga Fri Dec 20 11:32:05 2002
    > +++ 25-akpm/kernel/printk.c Fri Dec 20 11:33:14 2002
    > @@ -43,7 +43,11 @@
    > #define LOG_BUF_MASK (LOG_BUF_LEN-1)
    >
    > #ifndef arch_consoles_callable
    > -#define arch_consoles_callable() (1)
    > +/*
    > + * Some console drivers may assume that per-cpu resources have been allocated.
    > + * So don't allow them to be called by this CPU until it is officially up.
    > + */
    > +#define arch_consoles_callable() cpu_online(smp_processor_id())
    > #endif
    >
    > /* printk's without a loglevel use this.. */
    >

    --
    George Anzinger george@mvista.com
    High-res-timers:
    http://sourceforge.net/projects/high-res-timers/
    Preemption patch:
    http://www.kernel.org/pub/linux/kernel/people/rml
    -
    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-03-22 13:31    [W:0.026 / U:0.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site