From: Andrew Morton <akpm@digeo.com>
To: george anzinger <george@mvista.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 11:34:25 -0800 [thread overview]
Message-ID: <3E0370C1.21909EF5@digeo.com> (raw)
In-Reply-To: <3E0350CA.6B99F722@mvista.com>
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?
--- 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.. */
_
next prev parent reply other threads:[~2002-12-20 19:26 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 [this message]
2002-12-20 20:01 ` george anzinger
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=3E0370C1.21909EF5@digeo.com \
--to=akpm@digeo.com \
--cc=george@mvista.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