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
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: [email protected]
> [mailto:[email protected]]On Behalf Of
> Deepinder Singh
> Sent: Thursday, January 31, 2002 10:33 AM
> To: [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I use GRE tunnels a lot. I have run my rc.networking script several
dozen times with no problems and everything is cranking along nicely.
You can view my scripts at http://blue-labs.org/. I always use a
single numbered interface, "gre1".
However the below really is a bug that should be fixed I would imagine.
David
Deepinder Singh wrote:
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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: [email protected]
>>[mailto:[email protected]]On Behalf Of
>>Deepinder Singh
>>Sent: Thursday, January 31, 2002 10:33 AM
>>To: [email protected]
>>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 [email protected]
>>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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
In article <[email protected]> you write:
> 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
I don't think this is the same problem. The code dealing with device
allocation in CIPE is not related at all to the in-kernel stuff, as
seen from my POV. Btw. you must have a weird bug, as this has always
worked perfectly enough for me. (Perhaps your detailed config would
help figure it out.)
Olaf
I don't think there is a kernel problem, there is an ioctl to delete
tunnels and it does work. if tun0 down does not delete the tunnel you
need to send down the ioctl as well. I don't know what user tools do
this for you, I have always done my own.
This is all the code ryou really need
{
struct ifreq ifr;
int fd;
int i=0;
if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
SYSLOG(LOG_DAEMON | LOG_ERR, "Cannot open socket to close tunnel(s)\n");
return;
}
sprintf(ifr.ifr_name,"tun%d", i);
if( (ioctl(fd, SIOCDELTUNNEL, &ifr) < 0) {
SYSLOG(LOG_DAEMON | LOG_ERR, "Can't DELTUNNEL %s (%m)\n", ifr.ifr_name);
}