public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: j-nomura@ce.jp.nec.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.16 kernel/printk.c (per processor initializationcheck)
Date: Mon, 03 Dec 2001 17:45:19 -0800	[thread overview]
Message-ID: <3C0C2AAF.6141D797@zip.com.au> (raw)
In-Reply-To: <3C0B43DC.7A8F582A@zip.com.au>, <20011203144615C.nomura@hpc.bs1.fc.nec.co.jp> <3C0B43DC.7A8F582A@zip.com.au> <20011203193235S.nomura@hpc.bs1.fc.nec.co.jp>

j-nomura@ce.jp.nec.com wrote:
> 
> Hi,
> 
> Thank you for commenting.
> 
> From: Andrew Morton <akpm@zip.com.au>
> Subject: Re: [PATCH] 2.4.16 kernel/printk.c (per processor initialization check)
> Date: Mon, 03 Dec 2001 01:20:28 -0800
> 
> > Seems that there is some sort of ordering problem here - someone
> > is calling printk before the MMU is initialised, but after some
> > console drivers have been installed.
> 
> Yes.
> Because smp_init() is later in place than console_init(), printk() can be
> called in such a situation.
> For example, in IA-64, identify_cpu() is called before ia64_mmu_init(),
> while identify_cpu() calls printk() in it.
> I don't think the ordering itself is a problem.
> 
> > I suspect the real fix is elsewhere, but I'm not sure where.
> >
> > Probably a clearer place to put this test would be within
> > printk itself, immediately before the down_trylock.  Does that
> > work?
> 
> The reason I put it in release_console_sem() is that release_console_sem()
> can be called from other functions than printk(), e.g. console_unblank().
> I agree with you that it is clearer but I think it is not sufficient.
> 

I really doubt if any of those paths could be called before
even the MMU is set up.

It seems that the ia64 port has installed some console drivers,
and has then called them before it is ready to do so.  Via printk.

It should not have installed the console drivers that early.  Do
you know what console driver is causing the problem?

If the console driver is not fixable then a more general approach
would be, in printk.c:

#ifndef ARCH_HAS_PRINTK_MAY_BE_USED
#define printk_may_be_used() (1)
#endif

then, in printk() itself:

                if (*p == '\n')
                        log_level_unknown = 1;
        }

+	if (!printk_may_be_used())
+		return printed_len;

        if (!down_trylock(&console_sem)) {
                /*

then, for ia64, give it a printk_may_be_used() function, and
define ARCH_HAS_PRINTK_MAY_BE_USED somewhere.

Or just not install console drivers before they may be safely
used!

-

  reply	other threads:[~2001-12-04  2:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-03  5:46 [PATCH] 2.4.16 kernel/printk.c (per processor initialization check) j-nomura
2001-12-03  9:20 ` Andrew Morton
2001-12-03 10:32   ` j-nomura
2001-12-04  1:45     ` Andrew Morton [this message]
2001-12-06  5:01       ` [PATCH] 2.4.16 kernel/printk.c (per processor initializationcheck) j-nomura
2001-12-07  3:40         ` [PATCH] 2.4.16 kernel/printk.c (per processorinitializationcheck) Andrew Morton
2001-12-07 18:52           ` Marcelo Tosatti
2001-12-07 20:52             ` William Lee Irwin III
2001-12-07 21:37             ` David Mosberger
2001-12-07 20:47               ` Marcelo Tosatti
2001-12-07 22:17                 ` David Mosberger
2001-12-07 21:09                   ` Marcelo Tosatti
2001-12-08  1:10                     ` David Mosberger
2001-12-08 11:27                       ` Alan Cox
2001-12-08 16:41                         ` David Mosberger
2001-12-08 20:45                           ` Alan Cox
2001-12-09  0:32                             ` David Mosberger
2001-12-09  0:55                               ` Alan Cox
2001-12-09  0:58                                 ` David Mosberger
2001-12-09  1:15                                   ` Alan Cox
2001-12-09  1:14                                     ` David Mosberger
2001-12-09  1:32                                       ` Alan Cox
2001-12-07 22:08               ` Alan Cox
2001-12-07 22:14               ` Christopher Friesen

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=3C0C2AAF.6141D797@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    /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