From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>, Tejun Heo <tj@kernel.org>
Subject: [PATCH 0/4] Safely removing mmaped files
Date: Fri, 04 Sep 2009 12:24:44 -0700 [thread overview]
Message-ID: <m1fxb2wm0z.fsf@fess.ebiederm.org> (raw)
Currently when mmaped files are removed I have not found a single
instance in the kernel where we handle it correctly. Frequently after
a hot remove we will either leak a file (with weird ensuing
consequences) or we will goof and not call vm_ops->close() which can
cause leaks.
It turns out this problem isn't too bad to actually fix and this
patchset is my generic solution. Tested against 2.6.31-rc8 with a
process that mmaped /sys/*/*/resource0 and /proc/bus/pci/*/*.
I'm not certain what the best way to carry these patches is to get
them merged. Andrew can you carry this patchset?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>, Tejun Heo <tj@kernel.org>
Subject: [PATCH 0/4] Safely removing mmaped files
Date: Fri, 04 Sep 2009 12:24:44 -0700 [thread overview]
Message-ID: <m1fxb2wm0z.fsf@fess.ebiederm.org> (raw)
Currently when mmaped files are removed I have not found a single
instance in the kernel where we handle it correctly. Frequently after
a hot remove we will either leak a file (with weird ensuing
consequences) or we will goof and not call vm_ops->close() which can
cause leaks.
It turns out this problem isn't too bad to actually fix and this
patchset is my generic solution. Tested against 2.6.31-rc8 with a
process that mmaped /sys/*/*/resource0 and /proc/bus/pci/*/*.
I'm not certain what the best way to carry these patches is to get
them merged. Andrew can you carry this patchset?
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>, Tejun Heo <tj@kernel.org>
Subject: [PATCH 0/4] Safely removing mmaped files
Date: Fri, 04 Sep 2009 12:24:44 -0700 [thread overview]
Message-ID: <m1fxb2wm0z.fsf@fess.ebiederm.org> (raw)
Currently when mmaped files are removed I have not found a single
instance in the kernel where we handle it correctly. Frequently after
a hot remove we will either leak a file (with weird ensuing
consequences) or we will goof and not call vm_ops->close() which can
cause leaks.
It turns out this problem isn't too bad to actually fix and this
patchset is my generic solution. Tested against 2.6.31-rc8 with a
process that mmaped /sys/*/*/resource0 and /proc/bus/pci/*/*.
I'm not certain what the best way to carry these patches is to get
them merged. Andrew can you carry this patchset?
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2009-09-04 20:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-04 19:24 Eric W. Biederman [this message]
2009-09-04 19:24 ` [PATCH 0/4] Safely removing mmaped files Eric W. Biederman
2009-09-04 19:24 ` Eric W. Biederman
2009-09-04 19:25 ` [PATCH 1/4] mm: Introduce revoke_file_mappings Eric W. Biederman
2009-09-04 19:25 ` Eric W. Biederman
2009-09-04 19:26 ` [PATCH 2/4] sysfs: Use revoke_file_mappings Eric W. Biederman
2009-09-04 19:26 ` Eric W. Biederman
2009-09-04 19:26 ` Eric W. Biederman
2009-09-04 19:27 ` [PATCH 3/4] proc: Clean up mmaps when a proc file is removed Eric W. Biederman
2009-09-04 19:27 ` Eric W. Biederman
2009-09-04 19:27 ` Eric W. Biederman
2009-09-04 19:28 ` [PATCH 4/4] pci: Remove bogus check of proc dir entry usage Eric W. Biederman
2009-09-04 19:28 ` Eric W. Biederman
2009-09-04 19:28 ` Eric W. Biederman
2009-09-08 22:18 ` [PATCH 1/4] mm: Introduce revoke_file_mappings Andrew Morton
2009-09-08 22:18 ` Andrew Morton
2009-09-08 22:18 ` Andrew Morton
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=m1fxb2wm0z.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@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.