linux-ext4 - [PATCH 2/2] ext4: don't bump nr_to_write if LONG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Aug 2010 09:04:29 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: [PATCH 2/2] ext4: don't bump nr_to_write if LONG_MAX

In some cases we can reach ext4_da_writepages with
wbc->nr_to_write == LONG_MAX, !range_cyclic, and range_whole=1;
in this case we will try to bump it up by a factor of 8, which
leads to a nr_to_write value of -8.

I think we still get through the logic without changing
wbc->nr_to_write because the other tests which would change
it don't trip, but it seems dangerous to overflow 
desired_nr_to_write in the interim, it's not obvious.

Signed-off-by: Eric Sandeen <sandeen@...hat.com>
---

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 93497f6..2e72a4a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3004,9 +3004,11 @@ static int ext4_da_writepages(struct address_space *mapping,
 	 * sbi->max_writeback_mb_bump whichever is smaller.
 	 */
 	max_pages = sbi->s_max_writeback_mb_bump << (20 - PAGE_CACHE_SHIFT);
-	if (!range_cyclic && range_whole)
-		desired_nr_to_write = wbc->nr_to_write * 8;
-	else
+	if (!range_cyclic && range_whole) {
+		desired_nr_to_write = wbc->nr_to_write;
+		if (desired_nr_to_write != LONG_MAX)
+			desired_nr_to_write *= 8;
+	} else
 		desired_nr_to_write = ext4_num_dirty_pages(inode, index,
 							   max_pages);
 	if (desired_nr_to_write > max_pages)


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html