aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ubifs/shrinker.c
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2011-05-31 00:03:21 -0400
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2011-06-03 11:12:24 -0400
commitcf610bf4199770420629d3bc273494bd27ad6c1d (patch)
tree76418cad3b35d8b40090ae13d5100de598e6c4cb /fs/ubifs/shrinker.c
parentda8b94ea61c5d80aae0cc7b7541f1e0fa7459391 (diff)
UBIFS: fix shrinker object count reports
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> Cc: stable@kernel.org
Diffstat (limited to 'fs/ubifs/shrinker.c')
-rw-r--r--fs/ubifs/shrinker.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/fs/ubifs/shrinker.c b/fs/ubifs/shrinker.c
index ca953a945029..9e1d05666fed 100644
--- a/fs/ubifs/shrinker.c
+++ b/fs/ubifs/shrinker.c
@@ -284,7 +284,11 @@ int ubifs_shrinker(struct shrinker *shrink, struct shrink_control *sc)
284 long clean_zn_cnt = atomic_long_read(&ubifs_clean_zn_cnt); 284 long clean_zn_cnt = atomic_long_read(&ubifs_clean_zn_cnt);
285 285
286 if (nr == 0) 286 if (nr == 0)
287 return clean_zn_cnt; 287 /*
288 * Due to the way UBIFS updates the clean znode counter it may
289 * temporarily be negative.
290 */
291 return clean_zn_cnt >= 0 ? clean_zn_cnt : 1;
288 292
289 if (!clean_zn_cnt) { 293 if (!clean_zn_cnt) {
290 /* 294 /*