mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Andrew Morton <akpm@digeo.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH]Timer list init is done AFTER use
Date: Fri, 20 Dec 2002 12:01:46 -0800	[thread overview]
Message-ID: <3E03772A.D5D85171@mvista.com> (raw)
In-Reply-To: <3E0370C1.21909EF5@digeo.com>

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

  reply	other threads:[~2002-12-20 19:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-20  8:43 george anzinger
2002-12-20 10:26 ` Andrew Morton
2002-12-20 17:18   ` george anzinger
2002-12-20 19:34     ` Andrew Morton
2002-12-20 20:01       ` george anzinger [this message]
2002-12-20 20:31         ` Andrew Morton
2002-12-22  8:38         ` Andrew Morton
2002-12-22  9:58           ` george anzinger
2002-12-22 21:14           ` Martin J. Bligh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E03772A.D5D85171@mvista.com \
    --to=george@mvista.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome