public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* Fix for memory leak problem in megaraid2.c /proc entries (fwd)
@ 2004-04-08 15:29 Lester Hightower
  2004-04-08 15:38 ` Matthew Wilcox
  0 siblings, 1 reply; 3+ messages in thread
From: Lester Hightower @ 2004-04-08 15:29 UTC (permalink / raw)
  To: linux-scsi

Based on this auto-response:

| Date: Thu, 08 Apr 2004 10:23:01 -0500
| From: linux-megaraid-devel-admin@lists.us.dell.com
| To: DEVNULL@10east.com
| Subject: Auto-response for your message to linux-megaraid-devel@dell.com
|
| The linux-megaraid-devel@dell.com mailing list has been discontinued.
| Please redirect your message to either:
|
| linux-scsi@vger.kernel.org  for all megaraid-specific issues
| (subscribe at http://vger.kernel.org/vger-lists.html#linux-scsi)
|
| or
|
| linux-poweredge@dell.com  for all Dell PowerEdge-specific issues
| (subscribe at http://lists.us.dell.com)


I am forwarding this email to linux-scsi@vger.kernel.org:

---------- Forwarded message ----------
Date: Thu, 8 Apr 2004 11:22:36 -0400 (EDT)
From: Lester Hightower <hightowe@10east.com>
To: linux-megaraid-devel@dell.com
Subject: Fix for memory leak problem in megaraid2.c /proc entries

This diff fixes a memory leak in megaraid2.c, v2.10.1 (Dec 03, 2003):

[root@10east scsi]# diff megaraid2.c.MEMORY_LEAK.20040408.lhh megaraid2.c
3395c3395,3399
<       if( channel >= max_channels ) return 0;
---
>       if( channel >= max_channels ) {
>               pci_free_consistent(pdev, 256, scsi_inq, scsi_inq_dma_handle);
>               mega_free_inquiry(inquiry, dma_handle, pdev);
>               return 0;
>         }

I have shared it with the proper folks (Atul Mukker) at LSI, so it will
likely (hopefully) make it into newer driver versions/newer kernels.

The problem occurs only in the circumstance where one reads one of the
/proc/megaraid/hba<X>/diskdrives-ch<N> files where the card <X> does not
have channel <N> on it.  Most people would likely not notice this leak in
normal operation, but due to the way that we monitor our MegaRaid cards in
our company (we read these /proc entries every 180s) so we found the leak
rather quickly, and unpleasantly (when your kernel eats all your RAM).

--
Lester H. Hightower <__h+i_g+h_t+o_w+e__@__10east.com>
Chief Technology Officer, 10 East Corp.

p.s. my_email_addrs =~ s/[_+]/g to email me...

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Fix for memory leak problem in megaraid2.c /proc entries (fwd)
  2004-04-08 15:29 Fix for memory leak problem in megaraid2.c /proc entries (fwd) Lester Hightower
@ 2004-04-08 15:38 ` Matthew Wilcox
  2004-04-08 15:41   ` Lester Hightower
  0 siblings, 1 reply; 3+ messages in thread
From: Matthew Wilcox @ 2004-04-08 15:38 UTC (permalink / raw)
  To: Lester Hightower; +Cc: linux-scsi

On Thu, Apr 08, 2004 at 11:29:20AM -0400, Lester Hightower wrote:
> This diff fixes a memory leak in megaraid2.c, v2.10.1 (Dec 03, 2003):
> 
> [root@10east scsi]# diff megaraid2.c.MEMORY_LEAK.20040408.lhh megaraid2.c
> 3395c3395,3399
> <       if( channel >= max_channels ) return 0;
> ---
> >       if( channel >= max_channels ) {
> >               pci_free_consistent(pdev, 256, scsi_inq, scsi_inq_dma_handle);
> >               mega_free_inquiry(inquiry, dma_handle, pdev);
> >               return 0;
> >         }

FYI, in future please use diff -u to generate diffs; they are much more
robust and easier to read than the diff default.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Fix for memory leak problem in megaraid2.c /proc entries (fwd)
  2004-04-08 15:38 ` Matthew Wilcox
@ 2004-04-08 15:41   ` Lester Hightower
  0 siblings, 0 replies; 3+ messages in thread
From: Lester Hightower @ 2004-04-08 15:41 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: linux-scsi

On Thu, 8 Apr 2004, Matthew Wilcox wrote:

> On Thu, Apr 08, 2004 at 11:29:20AM -0400, Lester Hightower wrote:
> > This diff fixes a memory leak in megaraid2.c, v2.10.1 (Dec 03, 2003):
> >
> > [root@10east scsi]# diff megaraid2.c.MEMORY_LEAK.20040408.lhh megaraid2.c
> > 3395c3395,3399
> > <       if( channel >= max_channels ) return 0;
> > ---
> > >       if( channel >= max_channels ) {
> > >               pci_free_consistent(pdev, 256, scsi_inq, scsi_inq_dma_handle);
> > >               mega_free_inquiry(inquiry, dma_handle, pdev);
> > >               return 0;
> > >         }
>
> FYI, in future please use diff -u to generate diffs; they are much more
> robust and easier to read than the diff default.


Good point.  Sorry about that -- just slipped my mind.

Here it is, BTW:

[root@10east scsi]# diff -u megaraid2.c.MEMORY_LEAK.20040408.lhh megaraid2.c
--- megaraid2.c.MEMORY_LEAK.20040408.lhh        2004-02-18 08:36:31.000000000 -0500
+++ megaraid2.c 2004-04-08 10:52:15.000000000 -0400
@@ -3392,7 +3392,11 @@

        max_channels = adapter->product_info.nchannels;

-       if( channel >= max_channels ) return 0;
+       if( channel >= max_channels ) {
+               pci_free_consistent(pdev, 256, scsi_inq, scsi_inq_dma_handle);
+               mega_free_inquiry(inquiry, dma_handle, pdev);
+               return 0;
+        }

        for( tgt = 0; tgt <= MAX_TARGET; tgt++ ) {


--
Lester

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-04-08 15:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-08 15:29 Fix for memory leak problem in megaraid2.c /proc entries (fwd) Lester Hightower
2004-04-08 15:38 ` Matthew Wilcox
2004-04-08 15:41   ` Lester Hightower

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox