From: Crutcher Dunnavant <crutcher@datastacks.com>
To: linux-kernel@vger.kernel.org
Subject: Re: printk while interrupts are disabled
Date: Tue, 2 Oct 2001 10:22:10 -0400 [thread overview]
Message-ID: <20011002102210.B1630@mueller.datastacks.com> (raw)
In-Reply-To: <3BB9A6F4.6BDDAA81@berlin.de>
In-Reply-To: <3BB9A6F4.6BDDAA81@berlin.de>; from n.roos@berlin.de on Tue, Oct 02, 2001 at 01:37:24PM +0200
++ 02/10/01 13:37 +0200 - Norbert Roos:
> Hello!
>
> Simple question: Do printk()s get printed while interrupts are disabled
> (after cli)?
They get stuffed into a buffer to be printed later. It is possible to
overflow that buffer, and lose some of your printk messages.
from krenel/printk.c:
/*
* This is printk. It can be called from any context. We want it to
* work.
*
* We try to grab the console_sem. If we succeed, it's easy - we log
* the output and
* call the console drivers. If we fail to get the semaphore we place
* the output
* into the log buffer and return. The current holder of the
* console_sem will
* notice the new output in release_console_sem() and will send it to
* the
* consoles before releasing the semaphore.
*
* One effect of this deferred printing is that code which calls
* printk() and
* then changes console_loglevel may break. This is because
* console_loglevel
* is inspected when the actual printing occurs.
*/
...
/* This stops the holder of console_sem just where we want him
* */
spin_lock_irqsave(&logbuf_lock, flags);
--
Crutcher <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$
next prev parent reply other threads:[~2001-10-02 14:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-02 11:37 printk while interrupts are disabled Norbert Roos
2001-10-02 14:22 ` Crutcher Dunnavant [this message]
2001-10-02 14:33 ` Tim Waugh
2001-10-02 17:09 ` Andrew Morton
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=20011002102210.B1630@mueller.datastacks.com \
--to=crutcher@datastacks.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 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.