This is a note to let you know that I've just added the patch titled
devpts: plug the memory leak in kill_sb
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
devpts-plug-the-memory-leak-in-kill_sb.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 66da0e1f9034140ae2f571ef96e254a25083906c Mon Sep 17 00:00:00 2001
From: Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 12 Nov 2013 15:11:45 -0800
Subject: devpts: plug the memory leak in kill_sb
From: Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx>
commit 66da0e1f9034140ae2f571ef96e254a25083906c upstream.
When devpts is unmounted, there may be a no-longer-used IDR tree hanging
off the superblock we are about to kill. This needs to be cleaned up
before destroying the SB.
The leak is usually not a big deal because unmounting devpts is typically
done when shutting down the whole machine. However, shutting down an LXC
container instead of a physical machine exposes the problem (the garbage
is detectable with kmemleak).
Signed-off-by: Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx>
Cc: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/devpts/inode.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -475,6 +475,7 @@ static void devpts_kill_sb(struct super_
{
struct pts_fs_info *fsi = DEVPTS_SB(sb);
+ ida_destroy(&fsi->allocated_ptys);
kfree(fsi);
kill_litter_super(sb);
}
Patches currently in stable-queue which might be from ihadzic@xxxxxxxxxxxxxxxxxxxxxx are
queue-3.4/devpts-plug-the-memory-leak-in-kill_sb.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html