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 [PATCH]Timer list init is done AFTER use 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.