From: Pekka Pietikainen <pp@ee.oulu.fi>
To: Brandon Craig Rhodes <brandon@rhodesmill.org>
Cc: netdev@vger.kernel.org
Subject: Re: TKIP encryption should allocate enough tailroom
Date: Fri, 19 Jan 2007 14:23:23 +0200 [thread overview]
Message-ID: <20070119122323.GA32747@ee.oulu.fi> (raw)
In-Reply-To: <87hcuo30di.fsf@ten22.rhodesmill.org>
On Thu, Jan 18, 2007 at 08:55:37AM -0500, Brandon Craig Rhodes wrote:
> to debugging messages! In some circumstances, debug messages are
> always produced; in several others, net_ratelimit() is called to
> decided whether to print an error (but why in these cases and not
> others?); and in many cases, nothing is printed at all (is this
> because convention would dictate that the caller discover the error
> and print something out?).
>
> If I want to generate a patch that festoons the ieee80211 functions
> with informative error messages, what are the guidelines?
My understanding is:
BUG_ON() / BUG() if it's a clear "impossible" condition ("function calling
me was wrong") null pointers/buffer lengths being inconsistent. Might even be
justified in this case?
net_ratelimit() says:
/*
* All net warning printk()s should be guarded by this function.
*/
int net_ratelimit(void)
{
return __printk_ratelimit(net_msg_cost, net_msg_burst);
}
Especially important if the code path can be triggered by anyone (local user
or arbitrary packet from the network). Otherwise not that big a deal if it's
buggy code elsewhere in the kernel that causes the message to be printed.
You fix the code and you stop getting thousands of lines of debug
messages/second (which is why net_ratelimit() exists).
If it's an arbitrary packet from the network, there probably should even
be a sysctl to enable/disable debug output completely. IPv4 has:
static void ip_handle_martian_source(struct net_device *dev,
struct in_device *in_dev,
struct sk_buff *skb,
__be32 daddr,
__be32 saddr)
{
RT_CACHE_STAT_INC(in_martian_src);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) {
/*
* RFC1812 recommendation, if source is martian,
* the only hint is MAC header.
*/
printk(KERN_WARNING "martian source %u.%u.%u.%u from "
"%u.%u.%u.%u, on dev %s\n",
NIPQUAD(daddr), NIPQUAD(saddr), dev->name);
...
(so there's a #ifdef _and_ a log_martians sysctl to see debug output).
In general #ifdefs should be avoided.
prev parent reply other threads:[~2007-01-19 12:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-17 2:31 TKIP encryption should allocate enough tailroom Brandon Craig Rhodes
2007-01-17 3:39 ` Mitchell Blank Jr
2007-01-17 3:34 ` Brandon Craig Rhodes
2007-01-17 6:34 ` Herbert Xu
2007-01-17 7:18 ` Herbert Xu
2007-01-17 3:50 ` Michael Wu
2007-01-17 16:46 ` Brandon Craig Rhodes
2007-01-17 17:23 ` Larry Finger
2007-01-17 17:38 ` Brandon Craig Rhodes
2007-01-18 13:16 ` Pekka Pietikainen
2007-01-18 13:55 ` Brandon Craig Rhodes
2007-01-19 12:23 ` Pekka Pietikainen [this message]
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=20070119122323.GA32747@ee.oulu.fi \
--to=pp@ee.oulu.fi \
--cc=brandon@rhodesmill.org \
--cc=netdev@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.