.33 patches

2 files changed, 71 insertions, 0 deletions

diff --git a/queue-2.6.33/ubifs-fix-memory-leak-on-error-path.patch b/queue-2.6.33/ubifs-fix-memory-leak-on-error-path.patch
new file mode 100644
index 0000000..cfebe72
--- /dev/null
+++ b/queue-2.6.33/ubifs-fix-memory-leak-on-error-path.patch
@@ -0,0 +1,31 @@
+From 812eb258311f89bcd664a34a620f249d54a2cd83 Mon Sep 17 00:00:00 2001
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Date: Tue, 31 May 2011 08:40:40 +0300
+Subject: UBIFS: fix memory leak on error path
+
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+
+commit 812eb258311f89bcd664a34a620f249d54a2cd83 upstream.
+
+UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
+failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
+Although the object is small, the alignment can make it large - e.g., 2KiB
+if the min. I/O unit is 2KiB.
+
+Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ubifs/journal.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ubifs/journal.c
++++ b/fs/ubifs/journal.c
+@@ -665,6 +665,7 @@ out_free:
+ 
+ out_release:
+ 	release_head(c, BASEHD);
++	kfree(dent);
+ out_ro:
+ 	ubifs_ro_mode(c, err);
+ 	if (last_reference)
diff --git a/queue-2.6.33/ubifs-fix-shrinker-object-count-reports.patch b/queue-2.6.33/ubifs-fix-shrinker-object-count-reports.patch
new file mode 100644
index 0000000..5d02eba
--- /dev/null
+++ b/queue-2.6.33/ubifs-fix-shrinker-object-count-reports.patch
@@ -0,0 +1,40 @@
+From cf610bf4199770420629d3bc273494bd27ad6c1d Mon Sep 17 00:00:00 2001
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Date: Tue, 31 May 2011 07:03:21 +0300
+Subject: UBIFS: fix shrinker object count reports
+
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+
+commit cf610bf4199770420629d3bc273494bd27ad6c1d upstream.
+
+Sometimes VM asks the shrinker to return amount of objects it can shrink,
+and we return the ubifs_clean_zn_cnt in that case. However, it is possible
+that this counter is negative for a short period of time, due to the way
+UBIFS TNC code updates it. And I can observe the following warnings sometimes:
+
+shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788
+
+This patch makes sure UBIFS never returns negative count of objects.
+
+Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ubifs/shrinker.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/ubifs/shrinker.c
++++ b/fs/ubifs/shrinker.c
+@@ -283,7 +283,11 @@ int ubifs_shrinker(int nr, gfp_t gfp_mas
+ 	long clean_zn_cnt = atomic_long_read(&ubifs_clean_zn_cnt);
+ 
+ 	if (nr == 0)
+-		return clean_zn_cnt;
++		/*
++		 * Due to the way UBIFS updates the clean znode counter it may
++		 * temporarily be negative.
++		 */
++		return clean_zn_cnt >= 0 ? clean_zn_cnt : 1;
+ 
+ 	if (!clean_zn_cnt) {
+ 		/*