* Re: [CHECKER] 6 memory leaks
@ 2003-04-21 20:27 Jean Tourrilhes
2003-04-21 20:53 ` William Lee Irwin III
0 siblings, 1 reply; 9+ messages in thread
From: Jean Tourrilhes @ 2003-04-21 20:27 UTC (permalink / raw)
To: irda-users, Muli Ben-Yehuda, William Lee Irwin III
Cc: Linux kernel mailing list
William Lee Irwin III wrote :
>
> On Sat, Apr 19, 2003 at 12:44:45PM +0300, Muli Ben-Yehuda wrote:
> > Index: net/irda/irttp.c
> > ===================================================================
> > RCS file: /home/cvs/linux-2.5/net/irda/irttp.c,v
> > retrieving revision 1.12
> > diff -u -r1.12 irttp.c
> > --- net/irda/irttp.c 25 Feb 2003 05:02:46 -0000 1.12
> > +++ net/irda/irttp.c 19 Apr 2003 08:50:00 -0000
> > @@ -263,7 +263,7 @@
> >
> > IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
> > self->rx_sdu_size);
> > - ASSERT(n <= self->rx_sdu_size, return NULL;);
> > + ASSERT(n <= self->rx_sdu_size, {dev_kfree_skb(skb); return NULL;});
> >
> > /* Set the new length */
> > skb_trim(skb, n);
Thanks for the heads up. I'm preparing a massive skb leak
patch for 2.5.X, I'll slip that into it. I'll probably code that
differently so that it looks "cleaner".
By the way, this is not terribly important, as if ASSERT do
trigger we usually have bigger problems than memory leaks (like you
may want to reboot rather sooner than later).
> I'm in terror. ASSERT()? return NULL in a macro argument?
> Any chance of cleaning that up a bit while you're at it?
>
> -- wli
Rather than fixing imaginary non-existing bugs, I prefer to
spend my time fixing real bugs that byte real users. This construct is
perfectly sound and valid, and it needs to be done in this way, the
only issue is that someone should rename "ASSERT" into "IRDA_ASSERT".
Have fun...
Jean
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-21 20:27 [CHECKER] 6 memory leaks Jean Tourrilhes
@ 2003-04-21 20:53 ` William Lee Irwin III
0 siblings, 0 replies; 9+ messages in thread
From: William Lee Irwin III @ 2003-04-21 20:53 UTC (permalink / raw)
To: jt; +Cc: irda-users, Muli Ben-Yehuda, Linux kernel mailing list
William Lee Irwin III wrote :
>> I'm in terror. ASSERT()? return NULL in a macro argument?
>> Any chance of cleaning that up a bit while you're at it?
On Mon, Apr 21, 2003 at 01:27:28PM -0700, Jean Tourrilhes wrote:
> Rather than fixing imaginary non-existing bugs, I prefer to
> spend my time fixing real bugs that byte real users. This construct is
> perfectly sound and valid, and it needs to be done in this way, the
> only issue is that someone should rename "ASSERT" into "IRDA_ASSERT".
The construct is a Lovecraftian horror. I've already lost my lunch once
over extremely disgusting code today, and I don't care to intentionally
read or run IRDA code ever again.
-- wli
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 12:08 ` James Morris
@ 2003-04-19 12:28 ` Muli Ben-Yehuda
0 siblings, 0 replies; 9+ messages in thread
From: Muli Ben-Yehuda @ 2003-04-19 12:28 UTC (permalink / raw)
To: James Morris; +Cc: Andy Chou, Linux-Kernel
[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]
On Sat, Apr 19, 2003 at 10:08:41PM +1000, James Morris wrote:
> On Sat, 19 Apr 2003, Muli Ben-Yehuda wrote:
>
> > This one appears to be exactly the same as the previous one, except
> > the line number is different. Does that mean the checker things there
> > are two leaks in this piece of code?
>
> This one was for the ipv6 version. If you could make a patch for ipv6,
> I'll forward both to Dave Miller.
Here it is, thanks.
Index: net/ipv4/netfilter/ip_queue.c
===================================================================
RCS file: /home/cvs/linux-2.5/net/ipv4/netfilter/ip_queue.c,v
retrieving revision 1.13
diff -u -r1.13 ip_queue.c
--- net/ipv4/netfilter/ip_queue.c 3 Apr 2003 16:59:51 -0000 1.13
+++ net/ipv4/netfilter/ip_queue.c 19 Apr 2003 11:35:11 -0000
@@ -300,8 +300,9 @@
write_lock_bh(&queue_lock);
if (!peer_pid)
- goto err_out_unlock;
+ goto err_out_free_nskb;
+ /* netlink_unicast will either free the nskb or attach it to a socket */
status = netlink_unicast(ipqnl, nskb, peer_pid, MSG_DONTWAIT);
if (status < 0)
goto err_out_unlock;
@@ -312,6 +313,9 @@
write_unlock_bh(&queue_lock);
return status;
+
+err_out_free_nskb:
+ kfree_skb(nskb);
err_out_unlock:
write_unlock_bh(&queue_lock);
Index: net/ipv6/netfilter/ip6_queue.c
===================================================================
RCS file: /home/cvs/linux-2.5/net/ipv6/netfilter/ip6_queue.c,v
retrieving revision 1.10
diff -u -r1.10 ip6_queue.c
--- net/ipv6/netfilter/ip6_queue.c 5 Apr 2003 01:30:47 -0000 1.10
+++ net/ipv6/netfilter/ip6_queue.c 19 Apr 2003 11:35:12 -0000
@@ -304,8 +304,9 @@
write_lock_bh(&queue_lock);
if (!peer_pid)
- goto err_out_unlock;
+ goto err_out_free_nskb;
+ /* netlink_unicast will either free the nskb or attach it to a socket */
status = netlink_unicast(ipqnl, nskb, peer_pid, MSG_DONTWAIT);
if (status < 0)
goto err_out_unlock;
@@ -316,6 +317,9 @@
write_unlock_bh(&queue_lock);
return status;
+
+err_out_free_nskb:
+ kfree_skb(nskb);
err_out_unlock:
write_unlock_bh(&queue_lock);
--
Muli Ben-Yehuda
http://www.mulix.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 9:44 ` Muli Ben-Yehuda
2003-04-19 9:55 ` William Lee Irwin III
@ 2003-04-19 12:08 ` James Morris
2003-04-19 12:28 ` Muli Ben-Yehuda
1 sibling, 1 reply; 9+ messages in thread
From: James Morris @ 2003-04-19 12:08 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Andy Chou, Linux-Kernel
On Sat, 19 Apr 2003, Muli Ben-Yehuda wrote:
> This one appears to be exactly the same as the previous one, except
> the line number is different. Does that mean the checker things there
> are two leaks in this piece of code?
This one was for the ipv6 version. If you could make a patch for ipv6,
I'll forward both to Dave Miller.
Thanks,
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 10:02 ` Muli Ben-Yehuda
@ 2003-04-19 10:13 ` William Lee Irwin III
0 siblings, 0 replies; 9+ messages in thread
From: William Lee Irwin III @ 2003-04-19 10:13 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Linux-Kernel, irda-users
At some point in the past, I wrote:
>> I'm in terror. ASSERT()? return NULL in a macro argument?
>> Any chance of cleaning that up a bit while you're at it?
On Sat, Apr 19, 2003 at 01:02:08PM +0300, Muli Ben-Yehuda wrote:
> I'm afraid it's rather wide-spread...
> mulix@granada:~/kernel/cvs/linux-2.5$ grep ASSERT net/irda/*.c | grep return | wc -l
> 511
> I'm willing to do the grunt work of converting it, if it's ok with the
> IRDA maintainers.
I'm not going to ask too much here. Whatever you have time to do, feel
like doing, and can get past the maintainers is fine by me.
-- wli
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 9:55 ` William Lee Irwin III
@ 2003-04-19 10:02 ` Muli Ben-Yehuda
2003-04-19 10:13 ` William Lee Irwin III
0 siblings, 1 reply; 9+ messages in thread
From: Muli Ben-Yehuda @ 2003-04-19 10:02 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Linux-Kernel, irda-users
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Sat, Apr 19, 2003 at 02:55:26AM -0700, William Lee Irwin III wrote:
> On Sat, Apr 19, 2003 at 12:44:45PM +0300, Muli Ben-Yehuda wrote:
> > Index: net/irda/irttp.c
> > ===================================================================
> > RCS file: /home/cvs/linux-2.5/net/irda/irttp.c,v
> > retrieving revision 1.12
> > diff -u -r1.12 irttp.c
> > --- net/irda/irttp.c 25 Feb 2003 05:02:46 -0000 1.12
> > +++ net/irda/irttp.c 19 Apr 2003 08:50:00 -0000
> > @@ -263,7 +263,7 @@
> >
> > IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
> > self->rx_sdu_size);
> > - ASSERT(n <= self->rx_sdu_size, return NULL;);
> > + ASSERT(n <= self->rx_sdu_size, {dev_kfree_skb(skb); return NULL;});
> >
> > /* Set the new length */
> > skb_trim(skb, n);
>
> I'm in terror. ASSERT()? return NULL in a macro argument?
> Any chance of cleaning that up a bit while you're at it?
I'm afraid it's rather wide-spread...
mulix@granada:~/kernel/cvs/linux-2.5$ grep ASSERT net/irda/*.c | grep return | wc -l
511
I'm willing to do the grunt work of converting it, if it's ok with the
IRDA maintainers.
--
Muli Ben-Yehuda
http://www.mulix.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 9:44 ` Muli Ben-Yehuda
@ 2003-04-19 9:55 ` William Lee Irwin III
2003-04-19 10:02 ` Muli Ben-Yehuda
2003-04-19 12:08 ` James Morris
1 sibling, 1 reply; 9+ messages in thread
From: William Lee Irwin III @ 2003-04-19 9:55 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Andy Chou, Linux-Kernel
On Sat, Apr 19, 2003 at 12:44:45PM +0300, Muli Ben-Yehuda wrote:
> Index: net/irda/irttp.c
> ===================================================================
> RCS file: /home/cvs/linux-2.5/net/irda/irttp.c,v
> retrieving revision 1.12
> diff -u -r1.12 irttp.c
> --- net/irda/irttp.c 25 Feb 2003 05:02:46 -0000 1.12
> +++ net/irda/irttp.c 19 Apr 2003 08:50:00 -0000
> @@ -263,7 +263,7 @@
>
> IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
> self->rx_sdu_size);
> - ASSERT(n <= self->rx_sdu_size, return NULL;);
> + ASSERT(n <= self->rx_sdu_size, {dev_kfree_skb(skb); return NULL;});
>
> /* Set the new length */
> skb_trim(skb, n);
I'm in terror. ASSERT()? return NULL in a macro argument?
Any chance of cleaning that up a bit while you're at it?
-- wli
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [CHECKER] 6 memory leaks
2003-04-19 2:50 Andy Chou
@ 2003-04-19 9:44 ` Muli Ben-Yehuda
2003-04-19 9:55 ` William Lee Irwin III
2003-04-19 12:08 ` James Morris
0 siblings, 2 replies; 9+ messages in thread
From: Muli Ben-Yehuda @ 2003-04-19 9:44 UTC (permalink / raw)
To: Andy Chou; +Cc: Linux-Kernel
[-- Attachment #1: Type: text/plain, Size: 7858 bytes --]
On Fri, Apr 18, 2003 at 07:50:25PM -0700, Andy Chou wrote:
> The following memory leaks were found by static analysis using the MC
> system (aka "Stanford Checker"). This is only an incremental list of new
> bugs found by an updated version of the memory leak checker. I checked
> the ipv4 and ipv6 bugs and they are still in 2.5.67.
>
> Confirmation/rejection would be appreciated for any of these bugs.
>
> -Andy
> ---------------------------------------------------------
> [BUG]
> /u1/acc/linux/2.5.48/net/ipv4/netfilter/ip_queue.c:321:ipq_enqueue_packet: ERROR:LEAK:296:321:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ipv4/netfilter/ip_queue.c:296:ipq_build_packet_message]
>
> entry->rt_info.tos = iph->tos;
> entry->rt_info.daddr = iph->daddr;
> entry->rt_info.saddr = iph->saddr;
> }
>
> Start --->
> nskb = ipq_build_packet_message(entry, &status);
This one appears to be a leak. Patch attached.
> static int
> ---------------------------------------------------------
> [BUG]
> /u1/acc/linux/2.5.48/net/ipv6/netfilter/ip6_queue.c:326:ipq_enqueue_packet: ERROR:LEAK:301:326:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ipv6/netfilter/ip6_queue.c:301:ipq_build_packet_message]
>
>
> entry->rt_info.daddr = iph->daddr;
> entry->rt_info.saddr = iph->saddr;
> }
This one appears to be exactly the same as the previous one, except
the line number is different. Does that mean the checker things there
are two leaks in this piece of code?
> ---------------------------------------------------------
> [BUG]
> /u1/acc/linux/2.5.48/net/irda/irttp.c:266:irttp_reassemble_skb: ERROR:LEAK:242:266:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/irda/irttp.c:242:dev_alloc_skb]
>
> ASSERT(self->magic == TTP_TSAP_MAGIC, return NULL;);
>
> IRDA_DEBUG(2, "%s(), self->rx_sdu_size=%d\n", __FUNCTION__,
> self->rx_sdu_size);
>
> Start --->
> skb = dev_alloc_skb(TTP_HEADER + self->rx_sdu_size);
>
> ... DELETED 18 lines ...
>
> }
> IRDA_DEBUG(2, "%s(), frame len=%d\n", __FUNCTION__, n);
>
> IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
> self->rx_sdu_size);
> Error --->
> ASSERT(n <= self->rx_sdu_size, return NULL;);
This one appears to be a leak. Patch attached (not compiled - file
does not compile currently).
> /u1/acc/linux/2.5.48/drivers/isdn/tpam/tpam_queues.c:150:tpam_irq: ERROR:LEAK:112:150:Memory leak [Allocated from: /u1/acc/linux/2.5.48/drivers/isdn/tpam/tpam_queues.c:112:alloc_skb]
>
>
> /* get the beginning of the message (pci_mpb part) */
> copy_from_pam(card, &mpb, (void *)uploadptr, sizeof(pci_mpb));
>
> /* allocate the sk_buff */
> Start --->
> if (!(skb = alloc_skb(sizeof(skb_header) + sizeof(pci_mpb) +
>
> ... DELETED 32 lines ...
>
> hpic = readl(card->bar0 + TPAM_HPIC_REGISTER);
> if (waiting_too_long++ > 0xfffffff) {
> spin_unlock(&card->lock);
> printk(KERN_ERR "TurboPAM(tpam_irq): "
> "waiting too long...\n");
> Error --->
This one appears to be a leak, patch attached. Not compiled either,
the old ISDN4Linux does not compile.
> ---------------------------------------------------------
> [BUG]
> /u1/acc/linux/2.5.48/drivers/net/wan/sdla_ppp.c:1921:rx_intr: ERROR:LEAK:1830:1921:Memory leak [Allocated from: /u1/acc/linux/2.5.48/drivers/net/wan/sdla_ppp.c:1830:dev_alloc_skb]
>
>
> len = rxbuf->length;
> ppp_priv_area = dev->priv;
>
> /* Allocate socket buffer */
> Start --->
> skb = dev_alloc_skb(len);
>
> ... DELETED 85 lines ...
>
> /* Release buffer element and calculate a pointer to the next one */
> rxbuf->flag = 0x00;
> card->rxmb = ++rxbuf;
> if ((void*)rxbuf > card->u.p.rxbuf_last)
> card->rxmb = card->u.p.rxbuf_base;
> Error --->
> }
This one appears to be a leak. Patch attached.
> ---------------------------------------------------------
> [BUG]
> /u1/acc/linux/2.5.48/net/ax25/af_ax25.c:1294:ax25_connect: ERROR:LEAK:1168:1294:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ax25/af_ax25.c:1168:kmalloc]
>
> if (fsa->fsa_ax25.sax25_ndigis < 1 || fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS) {
> err = -EINVAL;
> goto out;
> }
>
> Start --->
> if ((digi = kmalloc(sizeof(ax25_digi), GFP_KERNEL)) == NULL) {
>
> ... DELETED 120 lines ...
>
> sock->state = SS_CONNECTED;
>
> out:
> release_sock(sk);
>
> Error --->
This one appears to be a leak, patch attached.
Index: drivers/isdn/tpam/tpam_queues.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/isdn/tpam/tpam_queues.c,v
retrieving revision 1.4
diff -u -r1.4 tpam_queues.c
--- drivers/isdn/tpam/tpam_queues.c 2 Oct 2002 01:32:32 -0000 1.4
+++ drivers/isdn/tpam/tpam_queues.c 19 Apr 2003 08:49:49 -0000
@@ -144,6 +144,7 @@
do {
hpic = readl(card->bar0 + TPAM_HPIC_REGISTER);
if (waiting_too_long++ > 0xfffffff) {
+ kfree_skb(skb);
spin_unlock(&card->lock);
printk(KERN_ERR "TurboPAM(tpam_irq): "
"waiting too long...\n");
Index: drivers/net/wan/sdla_ppp.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/net/wan/sdla_ppp.c,v
retrieving revision 1.23
diff -u -r1.23 sdla_ppp.c
--- drivers/net/wan/sdla_ppp.c 7 Mar 2003 15:39:16 -0000 1.23
+++ drivers/net/wan/sdla_ppp.c 19 Apr 2003 08:49:52 -0000
@@ -1747,11 +1747,10 @@
if (!test_bit(SEND_CRIT, &card->wandev.critical)){
ppp_send(card, skb->data, skb->len, htons(ETH_P_IPX));
}
- dev_kfree_skb_any(skb);
-
} else {
++card->wandev.stats.rx_dropped;
}
+ dev_kfree_skb_any(skb);
} else {
/* Pass data up the protocol stack */
skb->dev = dev;
Index: net/ax25/af_ax25.c
===================================================================
RCS file: /home/cvs/linux-2.5/net/ax25/af_ax25.c,v
retrieving revision 1.16
diff -u -r1.16 af_ax25.c
--- net/ax25/af_ax25.c 11 Mar 2003 01:33:58 -0000 1.16
+++ net/ax25/af_ax25.c 19 Apr 2003 08:49:58 -0000
@@ -1202,6 +1202,8 @@
ax25_insert_socket(ax25);
} else {
if (ax25->ax25_dev == NULL) {
+ if (digi != NULL)
+ kfree(digi);
err = -EHOSTUNREACH;
goto out;
}
Index: net/ipv4/netfilter/ip_queue.c
===================================================================
RCS file: /home/cvs/linux-2.5/net/ipv4/netfilter/ip_queue.c,v
retrieving revision 1.13
diff -u -r1.13 ip_queue.c
--- net/ipv4/netfilter/ip_queue.c 3 Apr 2003 16:59:51 -0000 1.13
+++ net/ipv4/netfilter/ip_queue.c 19 Apr 2003 08:49:58 -0000
@@ -298,10 +298,11 @@
goto err_out_free;
write_lock_bh(&queue_lock);
-
+
if (!peer_pid)
- goto err_out_unlock;
+ goto err_out_free_nskb;
+ /* netlink_unicast will either free the nskb or attach it to a socket */
status = netlink_unicast(ipqnl, nskb, peer_pid, MSG_DONTWAIT);
if (status < 0)
goto err_out_unlock;
@@ -312,6 +313,9 @@
write_unlock_bh(&queue_lock);
return status;
+
+err_out_free_nskb:
+ kfree_skb(nskb);
err_out_unlock:
write_unlock_bh(&queue_lock);
Index: net/irda/irttp.c
===================================================================
RCS file: /home/cvs/linux-2.5/net/irda/irttp.c,v
retrieving revision 1.12
diff -u -r1.12 irttp.c
--- net/irda/irttp.c 25 Feb 2003 05:02:46 -0000 1.12
+++ net/irda/irttp.c 19 Apr 2003 08:50:00 -0000
@@ -263,7 +263,7 @@
IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
self->rx_sdu_size);
- ASSERT(n <= self->rx_sdu_size, return NULL;);
+ ASSERT(n <= self->rx_sdu_size, {dev_kfree_skb(skb); return NULL;});
/* Set the new length */
skb_trim(skb, n);
--
Muli Ben-Yehuda
http://www.mulix.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [CHECKER] 6 memory leaks
@ 2003-04-19 2:50 Andy Chou
2003-04-19 9:44 ` Muli Ben-Yehuda
0 siblings, 1 reply; 9+ messages in thread
From: Andy Chou @ 2003-04-19 2:50 UTC (permalink / raw)
To: linux-kernel; +Cc: mc, madan, wendy.cheng
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
The following memory leaks were found by static analysis using the MC
system (aka "Stanford Checker"). This is only an incremental list of new
bugs found by an updated version of the memory leak checker. I checked
the ipv4 and ipv6 bugs and they are still in 2.5.67.
Confirmation/rejection would be appreciated for any of these bugs.
-Andy
[-- Attachment #2: err --]
[-- Type: text/plain, Size: 3792 bytes --]
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/net/ipv4/netfilter/ip_queue.c:321:ipq_enqueue_packet: ERROR:LEAK:296:321:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ipv4/netfilter/ip_queue.c:296:ipq_build_packet_message]
entry->rt_info.tos = iph->tos;
entry->rt_info.daddr = iph->daddr;
entry->rt_info.saddr = iph->saddr;
}
Start --->
nskb = ipq_build_packet_message(entry, &status);
... DELETED 19 lines ...
err_out_unlock:
write_unlock_bh(&queue_lock);
err_out_free:
kfree(entry);
Error --->
return status;
}
static int
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/net/ipv6/netfilter/ip6_queue.c:326:ipq_enqueue_packet: ERROR:LEAK:301:326:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ipv6/netfilter/ip6_queue.c:301:ipq_build_packet_message]
entry->rt_info.daddr = iph->daddr;
entry->rt_info.saddr = iph->saddr;
}
Start --->
nskb = ipq_build_packet_message(entry, &status);
... DELETED 19 lines ...
err_out_unlock:
write_unlock_bh(&queue_lock);
err_out_free:
kfree(entry);
Error --->
return status;
}
/*
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/net/irda/irttp.c:266:irttp_reassemble_skb: ERROR:LEAK:242:266:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/irda/irttp.c:242:dev_alloc_skb]
ASSERT(self->magic == TTP_TSAP_MAGIC, return NULL;);
IRDA_DEBUG(2, "%s(), self->rx_sdu_size=%d\n", __FUNCTION__,
self->rx_sdu_size);
Start --->
skb = dev_alloc_skb(TTP_HEADER + self->rx_sdu_size);
... DELETED 18 lines ...
}
IRDA_DEBUG(2, "%s(), frame len=%d\n", __FUNCTION__, n);
IRDA_DEBUG(2, "%s(), rx_sdu_size=%d\n", __FUNCTION__,
self->rx_sdu_size);
Error --->
ASSERT(n <= self->rx_sdu_size, return NULL;);
/* Set the new length */
skb_trim(skb, n);
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/drivers/isdn/tpam/tpam_queues.c:150:tpam_irq: ERROR:LEAK:112:150:Memory leak [Allocated from: /u1/acc/linux/2.5.48/drivers/isdn/tpam/tpam_queues.c:112:alloc_skb]
/* get the beginning of the message (pci_mpb part) */
copy_from_pam(card, &mpb, (void *)uploadptr, sizeof(pci_mpb));
/* allocate the sk_buff */
Start --->
if (!(skb = alloc_skb(sizeof(skb_header) + sizeof(pci_mpb) +
... DELETED 32 lines ...
hpic = readl(card->bar0 + TPAM_HPIC_REGISTER);
if (waiting_too_long++ > 0xfffffff) {
spin_unlock(&card->lock);
printk(KERN_ERR "TurboPAM(tpam_irq): "
"waiting too long...\n");
Error --->
return;
}
} while (hpic & 0x00000002);
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/drivers/net/wan/sdla_ppp.c:1921:rx_intr: ERROR:LEAK:1830:1921:Memory leak [Allocated from: /u1/acc/linux/2.5.48/drivers/net/wan/sdla_ppp.c:1830:dev_alloc_skb]
len = rxbuf->length;
ppp_priv_area = dev->priv;
/* Allocate socket buffer */
Start --->
skb = dev_alloc_skb(len);
... DELETED 85 lines ...
/* Release buffer element and calculate a pointer to the next one */
rxbuf->flag = 0x00;
card->rxmb = ++rxbuf;
if ((void*)rxbuf > card->u.p.rxbuf_last)
card->rxmb = card->u.p.rxbuf_base;
Error --->
}
void event_intr (sdla_t *card)
---------------------------------------------------------
[BUG]
/u1/acc/linux/2.5.48/net/ax25/af_ax25.c:1294:ax25_connect: ERROR:LEAK:1168:1294:Memory leak [Allocated from: /u1/acc/linux/2.5.48/net/ax25/af_ax25.c:1168:kmalloc]
if (fsa->fsa_ax25.sax25_ndigis < 1 || fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS) {
err = -EINVAL;
goto out;
}
Start --->
if ((digi = kmalloc(sizeof(ax25_digi), GFP_KERNEL)) == NULL) {
... DELETED 120 lines ...
sock->state = SS_CONNECTED;
out:
release_sock(sk);
Error --->
return 0;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-04-21 20:43 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-21 20:27 [CHECKER] 6 memory leaks Jean Tourrilhes
2003-04-21 20:53 ` William Lee Irwin III
-- strict thread matches above, loose matches on Subject: below --
2003-04-19 2:50 Andy Chou
2003-04-19 9:44 ` Muli Ben-Yehuda
2003-04-19 9:55 ` William Lee Irwin III
2003-04-19 10:02 ` Muli Ben-Yehuda
2003-04-19 10:13 ` William Lee Irwin III
2003-04-19 12:08 ` James Morris
2003-04-19 12:28 ` Muli Ben-Yehuda
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).