Bug 177429 - kernel memory leak in mousedev_release
Summary: kernel memory leak in mousedev_release
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-10 17:09 UTC by Kimball Murray
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-02 00:02:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Candidate #1 - plug the leak (902 bytes, patch)
2006-01-27 06:16 UTC, Pete Zaitcev
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0304 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 4 Update 5 2007-04-28 18:58:50 UTC

Description Kimball Murray 2006-01-10 17:09:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
When the sole user of /dev/input/mice opens and closes that file, the system will eventually invoke the oom_killer, which will kill everything in the system until nothing is left running.

Version-Release number of selected component (if applicable):
kernel-2.4.9-27EL

How reproducible:
Always

Steps to Reproduce:
1. Make sure nobody has /dev/input/mice open (use lsof or fuser)
2. Run a program that opens and closes /dev/input/mice forever.  Here's a sample ruby script, if you're into that sort of thing :)

#!/usr/bin/env ruby

while (true)
        f = File.new('/dev/input/mice')
        f.close
end

3. Run "watch -n1 free" and see the available memory draining away, rather quickly.  Also, run "watch -n1 'cat /proc/slabinfo | grep size-512'" and see the number of size-512 slabs increase rapidly.
  

Actual Results:  oom_killer started shooting everything.

Expected Results:  memory footprint should have stayed roughly constant

Additional info:

mousedev_open(...) kmalloc's a mousedev_list structure, which should be freed in mousedev_release(...).  Problem is, there's an exit path in mousedev_release(...) that skips the kfree.

Note: the mousedev_list structure is just over 300 bytes, which lines up with the observation about the size-512 slab growth.

I added some printk debug in that routine to verify it.  Here's the unmodified code:

static int mousedev_release(struct inode * inode, struct file * file)
{
        struct mousedev_list *list = file->private_data;

        mousedev_fasync(-1, file, 0);

        list_del(&list->node);

        if (!--list->mousedev->open) {
                if (list->mousedev->minor == MOUSEDEV_MIX)
-->  We take this exit path, avoiding the kfree below.
                        return mixdev_release();

                if (!mousedev_mix.open) {
                        if (list->mousedev->exist)
                                input_close_device(&list->mousedev->handle);
                        else
                                mousedev_free(list->mousedev);
                }
        }

        kfree(list);
        return 0;
}


I changed the "return mixdev_release()" line above into a block like this:
{
    int rc = mixdev_release();
    kfree(list);
    return rc;
}
and that seemed to take care of the leak.

This bug exists upstream as well.  I've verified the oom_killer behavior against Linus' 2.6.15 git tree.

Comment 2 Pete Zaitcev 2006-01-27 06:16:43 UTC
Created attachment 123766 [details]
Candidate #1 - plug the leak

Comment 3 Pete Zaitcev 2006-01-27 06:18:51 UTC
The candidate patch #1 is for upstream, but it applies fine to RHEL 4 U3
(with an offset, but no fuzz).

I'm going to turn this with the upstream and post for acks after that.

Comment 4 Pete Zaitcev 2006-04-15 00:04:59 UTC
This is included upstream in 2.6.17-rc1 at least, though slightly modified.
The bug seems to be languishing at U4 Proposed list.


Comment 7 Jason Baron 2006-09-06 18:23:06 UTC
committed in stream U5 build 42.7. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/


Comment 8 RHEL Product and Program Management 2006-09-07 19:34:41 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 9 RHEL Product and Program Management 2006-09-07 19:34:41 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 RHEL Product and Program Management 2006-09-07 19:34:47 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 14 Red Hat Bugzilla 2007-05-02 00:02:27 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0304.html



Note You need to log in before you can comment on or make changes to this bug.