netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Ivan H. Dichev" <idichev@obs.bg>
Cc: netdev@vger.kernel.org
Subject: Re: Slow OOM in netif_RX function
Date: Fri, 25 Jan 2008 14:21:08 +0100	[thread overview]
Message-ID: <p73tzl282ij.fsf@bingen.suse.de> (raw)
In-Reply-To: <20080124211810.3E24A46E9A@smtp.obs.bg> (Ivan H. Dichev's message of "Thu\, 24 Jan 2008 23\:18\:10 +0200")

"Ivan H. Dichev" <idichev@obs.bg> writes:
>
> What could happen if I put different Lan card in every slot?
> In ex. to-private -> 3com
>       to-inet    -> VIA
>       to-dmz     -> rtl8139
> And then to look which RX function is consuming the memory.
> (boomerang_rx, rtl8139_rx, ... etc) 

The problem is unlikely to be in the driver (these are both
well tested ones) but more likely your complicated iptables setup somehow
triggers a skb leak.

There are unfortunately no shrink wrapped debug mechanisms in the kernel
for leaks like this (ok you could enable CONFIG_NETFILTER_DEBUG 
and see if it prints something interesting, but that's a long shot).

If you wanted to write a custom debugging patch I would do something like this:

- Add two new integer fields to struct sk_buff: a time stamp and a integer field
- Fill the time stamp with jiffies in alloc_skb and clear the integer field
- In __kfree_skb clear the time stamp
- For all the ipt target modules in net/ipv4/netfilter/*.c you use change their 
->target functions to put an unique value into the integer field you added.
- Do the same for the pkt_to_tuple functions for all conntrack modules

Then when you observe the leak take a crash dump using kdump on the router 
and then use crash to dump all the slab objects for the sk_head_cache.
Then look for any that have an old time stamp and check what value they
have in the integer field. Then the netfilter function who set that unique value 
likely triggered the leak somehow.

-Andi

  parent reply	other threads:[~2008-01-25 13:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24 17:28 Slow OOM in netif_RX function Ivan Dichev
2008-01-24 18:29 ` Stephen Hemminger
2008-01-24 19:12 ` Eric Dumazet
2008-01-24 21:18   ` Ivan H. Dichev
2008-01-24 21:51     ` Francois Romieu
2008-01-25 13:21     ` Andi Kleen [this message]
2008-01-25 14:12       ` Arnaldo Carvalho de Melo
2008-02-01 12:51         ` Ivan Dichev
2008-02-01 13:16           ` Eric Dumazet
2008-02-01 15:38             ` Ivan Dichev
2008-02-04 14:54               ` Ivan Dichev
2008-02-04 15:55                 ` Andi Kleen
2008-02-05  9:04                   ` Ivan Mitev
2008-02-01 14:29           ` Andi Kleen

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=p73tzl282ij.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=idichev@obs.bg \
    --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;
as well as URLs for NNTP newsgroup(s).