From: "Deepinder Singh" <dsingh@somanetworks.com>
To: George Bonser <george@gator.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory leaks with GRE Tunnels
Date: Thu, 31 Jan 2002 14:40:44 -0500 [thread overview]
Message-ID: <3C599DBC.2040802@somanetworks.com> (raw)
In-Reply-To: <CHEKKPICCNOGICGMDODJKEHPGDAA.george@gator.com>
Sorry for the oversight - I am running 2.4.16
It probably is realted. Normally a physical interface really never needs
to be deleted so maybe no one is thinking of reusing the freed up
numbers and just grabbing the next unused one ( far less management
issues ) .
-Deepinder
George Bonser wrote:
> I wonder if this also causes a different problem ... when using CIPE
> (which is a tunnel of a different sort) if I stop a tunnel, I can not
> restart it with the same cipe device number. I get a message that the
> device is in use. I have to unload and reload the CIPE module to be
> able to use the device numbers configured in the config file. If I
> increment the device each time (e.g. cipcb0, then cipcb1, cipcb2) I
> restart the tunnel, it works. I wonder if it is something in the way
> Linux handles tunnel interfaces in the generic sense and not just
> limited to GRE.
>
> By the way, this behavior is on 2.2 kernels, I have no CIPE units
> running 2.4 and you did not mention which kernel version you are
> using.
>
>
>
>>-----Original Message-----
>>From: linux-kernel-owner@vger.kernel.org
>>[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of
>>Deepinder Singh
>>Sent: Thursday, January 31, 2002 10:33 AM
>>To: linux-kernel@vger.kernel.org
>>Subject: Memory leaks with GRE Tunnels
>>
>>
>>Hi ,
>>
>>I have been doing some testing using GRE tunnels in Linux (
>>which btw
>>work great ). I found that creating and deleting a tunnel
>>results in a
>>memory leak.
>>
>>To test it out I wrote a small script that basically loops around
>>creating and then deleting 8000 tunnel interfaces at a time. On the
>>eighth iteration the system hangs a whole with no error
>>messages. There
>> was still enoungh virtual memory around even with the leaks so I
>>figured something else is wrong. It turns out that the
>>interface numbers
>>( as seen in ' ip link ls' ) do not seem to be reused when
>>an interface
>>is deleted and as such the system hangs when the number reaches 64K.
>>
>>I suspect the two issues are realted but am more of a cisco
>>guy and know
>>kernel internals. The total mem leak for the 64 K tunnels
>>is about 200 megs.
>>
>>Please cc me if you reply to this post as I am not on the list.
>>
>>thanks,
>>Deepinder Singh
>>Sr. Network Eng.
>>Soma Networks
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe
>>linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2002-01-31 19:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-31 18:33 Memory leaks with GRE Tunnels Deepinder Singh
2002-01-31 18:57 ` George Bonser
2002-01-31 19:40 ` Deepinder Singh [this message]
2002-02-02 4:29 ` andrew may
2002-01-31 20:49 ` Olaf Titz
2002-01-31 19:35 ` David Ford
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=3C599DBC.2040802@somanetworks.com \
--to=dsingh@somanetworks.com \
--cc=george@gator.com \
--cc=linux-kernel@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.