From: Jim Keniston <jkenisto@us.ibm.com>
To: James Morris <jmorris@intercode.com.au>
Cc: Andrew Morton <akpm@osdl.org>,
davem@redhat.com, linux-kernel@vger.kernel.org,
netdev@oss.sgi.com, jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk,
rddunlap@osdl.org, kuznet@ms2.inr.ac.ru
Subject: Re: [PATCH] [1/2] kernel error reporting (revised)
Date: Fri, 18 Jul 2003 10:06:15 -0700 [thread overview]
Message-ID: <3F182907.30EA5922@us.ibm.com> (raw)
In-Reply-To: Mutt.LNX.4.44.0307181148340.5813-100000@excalibur.intercode.com.au
James Morris wrote:
>
> On Thu, 17 Jul 2003, Jim Keniston wrote:
>
> > 3. Given the above, what should the evlog.c caller do when
> > kernel_error_event_iov() returns -EINPROGRESS?
> > a. Nothing. Figure the packet will probably get logged.
> > b. Just to be safe, report it via printk, the same way we report dropped
> > packets.
> > We currently do (a). (b) would mean that every event logged from IRQ
> > context would be cc-ed to printk.
>
> I don't think this irq detection logic should be added at all here, let
> the caller reschedule its logging if running in irq context.
>
> - James
> --
> James Morris
> <jmorris@intercode.com.au>
Yes, this makes sense. At the kerror.c level, just return -EDEADLK if in_irq().
Delay packet delivery (via a tasklet, as before) at the evlog.c level instead.
That way, we know at the evlog.c level (in the tasklet) whether the event packet
was delivered to anybody, and can paraphrase it to printk if it wasn't.
Is this the sort of thing you had in mind?
Jim K
next prev parent reply other threads:[~2003-07-18 16:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-08 17:31 [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Jim Keniston
2003-07-08 17:59 ` Andrew Morton
2003-07-08 19:22 ` Jim Keniston
2003-07-08 19:45 ` Jim Keniston
2003-07-10 4:42 ` James Morris
2003-07-10 19:08 ` Jim Keniston
2003-07-11 15:37 ` James Morris
2003-07-12 5:09 ` David S. Miller
2003-07-12 5:41 ` David S. Miller
2003-07-13 1:17 ` James Morris
2003-07-13 5:34 ` David S. Miller
2003-07-15 17:42 ` [PATCH] [1/2] kernel error reporting (revised) Jim Keniston
2003-07-15 17:45 ` [PATCH] [2/2] " Jim Keniston
2003-07-15 19:51 ` [PATCH] [1/2] " Andrew Morton
2003-07-15 23:10 ` kuznet
2003-07-17 19:13 ` Jim Keniston
2003-07-18 1:53 ` James Morris
2003-07-18 17:06 ` Jim Keniston [this message]
2003-07-18 23:29 ` Jim Keniston
2003-07-19 23:52 ` James Morris
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=3F182907.30EA5922@us.ibm.com \
--to=jkenisto@us.ibm.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=jgarzik@pobox.com \
--cc=jmorris@intercode.com.au \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=rddunlap@osdl.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;
as well as URLs for NNTP newsgroup(s).