From: "David S. Miller" <davem@davemloft.net>
To: torvalds@osdl.org
Cc: jsmith@drexel.edu, linux-kernel@vger.kernel.org
Subject: Re: Instability in kernel version 2.6.12.5
Date: Thu, 06 Oct 2005 13:23:22 -0700 (PDT) [thread overview]
Message-ID: <20051006.132322.85672611.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0510061110170.31407@g5.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Date: Thu, 6 Oct 2005 11:24:25 -0700 (PDT)
> For example, maybe some networking timer just changes its "expires" field
> _while_ a timer is active directly rather than using "mod_timer()", which
> can screw up the sorting - and that can affect other timers.
We actually investigated a possible case of this recently.
It was thought that perhaps it was possible for the ARP
generic neighbour cache to double-add a timer, so we added
a guard by converting it to mod_timer() from add_timer()
and making sure it always returns "0" (timer not active).
static inline void neigh_add_timer(struct neighbour *n, unsigned long when)
{
if (unlikely(mod_timer(&n->timer, when))) {
printk("NEIGH: BUG, double timer add, state is %x\n",
n->nud_state);
}
}
But this new debugging hasn't triggered for anyone yet :-)
In general the networking tends to use mod_timer() exclusively, for
the simple reason that this makes refcounting on the object so much
simpler. For example, all of the socket timer helpers do stuff like
this:
void sk_reset_timer(struct sock *sk, struct timer_list* timer,
unsigned long expires)
{
if (!mod_timer(timer, expires))
sock_hold(sk);
}
void sk_stop_timer(struct sock *sk, struct timer_list* timer)
{
if (timer_pending(timer) && del_timer(timer))
__sock_put(sk);
}
I have no idea what the situation is in the netfilter bits, but
something similar is likely.
This brings me to a topic I'd like addressed. add_timer() no longer
checks whether it is adding a timer twice or not.
This debugging functionality got lost when add_timer() was changed
to be implemented in terms of __mod_timer(). I really think adding
back a "BUG_ON(timer_pending(timer)" would be a very good idea.
I believe Andrew Morton even added this bug check into his -mm tree
last time I brought this issue up.
Finally, it could be argued that add_timer() is not really a necessary
interface and that one can do whatever they need to purely using
mod_timer(). mod_timer() is kind of like a NAND gate I suppose :-)
next prev parent reply other threads:[~2005-10-06 20:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-06 17:30 Justin R. Smith
2005-10-06 18:24 ` Linus Torvalds
2005-10-06 20:23 ` David S. Miller [this message]
2005-10-07 16:41 ` Romano Giannetti
2005-10-08 21:38 ` Nathan Lynch
2005-10-10 2:53 ` Herbert Xu
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=20051006.132322.85672611.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=jsmith@drexel.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@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
Powered by JetHome