From: Eric Dumazet <eric.dumazet@gmail.com>
To: Florian Westphal <fw@strlen.de>
Cc: Sami Farin <hvtaifwkbgefbaei@gmail.com>,
netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
Subject: Re: (ipt_log_packet, sb_add) 3.6.0-rc2 kernel panic - not syncing; Fatal exception in interrupt
Date: Mon, 03 Sep 2012 00:53:05 +0200 [thread overview]
Message-ID: <1346626385.2563.44.camel@edumazet-glaptop> (raw)
In-Reply-To: <20120902132834.GB7456@breakpoint.cc>
From: Eric Dumazet <edumazet@google.com>
On Sun, 2012-09-02 at 15:28 +0200, Florian Westphal wrote:
> Sami Farin <hvtaifwkbgefbaei@gmail.com> wrote:
> > I get this panic every 1-2 days.
> > Also with 7a611e69b26069a511d9d5251c6a28af6c521121 (commit before 3.6.0-rc4).
>
> Could you please post iptables-save output?
> My guess is you're using NFLOG in INPUT?
>
> If so, I bet its caused by the tcp early demux stuff.
> Does that crash go away with ip_early_demux sysctl off?
>
> My guess is its assigning skb->sk with TIMEWAIT sockets, which
> would explain the crash.
Yes thats probably the reason.
First I thought changing demux to not do the lookup of TIMEWAIT slot in
__inet_lookup_established(), then it sounds not optimal to redo the full
lookup for ESTABLISHED sockets later in TCP stack.
So it seems we should fix xt_LOG instead
Thanks Florian !
[PATCH] xt_LOG: take care of timewait sockets
Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
full blown socket.
But with TCP early demux, we can have skb->sk pointing to a timewait
socket.
Diagnosed-by: Florian Westphal <fw@strlen.de>
Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/netfilter/xt_LOG.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
index ff5f75f..2a4f969 100644
--- a/net/netfilter/xt_LOG.c
+++ b/net/netfilter/xt_LOG.c
@@ -145,6 +145,19 @@ static int dump_tcp_header(struct sbuff *m, const struct sk_buff *skb,
return 0;
}
+static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
+{
+ if (!sk || sk->sk_state == TCP_TIME_WAIT)
+ return;
+
+ read_lock_bh(&sk->sk_callback_lock);
+ if (sk->sk_socket && sk->sk_socket->file)
+ sb_add(m, "UID=%u GID=%u ",
+ sk->sk_socket->file->f_cred->fsuid,
+ sk->sk_socket->file->f_cred->fsgid);
+ read_unlock_bh(&sk->sk_callback_lock);
+}
+
/* One level of recursion won't kill us */
static void dump_ipv4_packet(struct sbuff *m,
const struct nf_loginfo *info,
@@ -361,14 +374,8 @@ static void dump_ipv4_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & XT_LOG_UID) && !iphoff && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
- sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
- }
+ if ((logflags & XT_LOG_UID) && !iphoff)
+ dump_sk_uid_gid(m, skb->sk);
/* Max length: 16 "MARK=0xFFFFFFFF " */
if (!iphoff && skb->mark)
@@ -717,14 +724,8 @@ static void dump_ipv6_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & XT_LOG_UID) && recurse && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
- sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
- }
+ if ((logflags & XT_LOG_UID) && recurse)
+ dump_sk_uid_gid(m, skb->sk);
/* Max length: 16 "MARK=0xFFFFFFFF " */
if (!recurse && skb->mark)
next prev parent reply other threads:[~2012-09-02 22:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 13:49 (ipt_log_packet, sb_add) 3.6.0-rc2 kernel panic - not syncing; Fatal exception in interrupt Sami Farin
2012-09-02 12:20 ` Sami Farin
2012-09-02 13:28 ` Florian Westphal
2012-09-02 13:45 ` Sami Farin
2012-09-02 22:53 ` Eric Dumazet [this message]
2012-09-02 23:37 ` Eric Dumazet
2012-09-02 23:48 ` [PATCH v2] netfilter: take care of timewait sockets Eric Dumazet
2012-09-03 7:47 ` Florian Westphal
2012-09-03 9:57 ` Eric Dumazet
2012-09-03 17:23 ` David Miller
2012-09-04 7:55 ` Eric Dumazet
2012-09-04 16:16 ` David Miller
2012-09-14 9:30 ` Sami Farin
2012-09-10 5:02 ` (ipt_log_packet, sb_add) 3.6.0-rc2 kernel panic - not syncing; Fatal exception in interrupt Jan Engelhardt
2012-09-10 6:00 ` Eric Dumazet
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=1346626385.2563.44.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=fw@strlen.de \
--cc=hvtaifwkbgefbaei@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox