mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked@iki.fi>
To: Patrick McHardy <kaber@trash.net>
Cc: linux-kernel@vger.kernel.org,
	Netfilter Development Mailinglist 
	<netfilter-devel@lists.netfilter.org>
Subject: Re: netfilter QUEUE target and packet socket interactions buggy or not
Date: Tue, 13 Sep 2005 21:22:07 +0300	[thread overview]
Message-ID: <873bo8akvk.fsf@aka.i.naked.iki.fi> (raw)
In-Reply-To: <4326FF69.9060004@trash.net> (Patrick McHardy's message of "Tue, 13 Sep 2005 18:33:45 +0200")

Patrick McHardy wrote:
> Nuutti Kotivuori wrote:
>>
>> Appended here is a backtrace with the tg3 driver. Also, it seems that
>> the bug cannot be reproduced with uniprocessor, only SMP.
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000018
>
> This means inode->i_security was NULL. AFAICT it is only set to NULL in
> inode_free_security() when the inode is freed. This shouldn't happen
> while the packet is queued since the skb should hold a reference to
> the socket on the output path. So it could be some protocol forgetting
> to increase the refcnt when taking a reference.

Right.

> What kind of packet is this? And what kernel version are you
> running? Until recently ip_conntrack did some fiddling with skb->sk
> which could lead to a packet on the output path with skb->sk set but
> no reference taken.

This happens on Red Hat Enterprise Linux 4, with a 2.6.9 kernel (with
a gazillion of Red Hat patches in it, latest ones being from 2.6.11)
and the ip_queue patch that adds the bottom-half disabling. I will
know for sure tomorrow, but it seems that it doesn't appear on vanilla
2.6.13.1 or without SMP.

It is very hard to know which packet specifically triggers this. The
machine is under heavy load in general, a lot of packets are handled
via a QUEUE target, and some packets are captured via packet socket.

I will post more details tomorrow, but if you could point me towards
the changes in ip_conntrack that affected this, it would be very
helpful. I could check if they are in the Red Hat kernel and if not,
patch them manually and see if it makes a difference. The problem is
now reproduciable in a couple hours, so it shouldn't be too hard.

Thanks,
-- Naked


  reply	other threads:[~2005-09-13 17:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 22:12 Nuutti Kotivuori
2005-09-12 22:11 ` David S. Miller
2005-09-12 22:34   ` Nuutti Kotivuori
2005-09-13 10:54     ` Nuutti Kotivuori
2005-09-13 16:33       ` Patrick McHardy
2005-09-13 18:22         ` Nuutti Kotivuori [this message]
2005-09-14 11:20 ` Nuutti Kotivuori

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=873bo8akvk.fsf@aka.i.naked.iki.fi \
    --to=naked@iki.fi \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@lists.netfilter.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

all inboxes | Powered by JetHome®