| 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
| ||
|
Message-ID: <4BECB562.2080200@cesarb.net> Date: Thu, 13 May 2010 23:28:50 -0300 From: Cesar Eduardo Barros <cesarb@...arb.net> To: Wu Fengguang <fengguang.wu@...el.com> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH] radix-tree: fix radix_tree_prev_hole underflow case Em 13-05-2010 23:15, Wu Fengguang escreveu: > On Fri, May 14, 2010 at 10:05:24AM +0800, Cesar Eduardo Barros wrote: >> radix_tree_prev_hole() used LONG_MAX to detect underflow; however, >> ULONG_MAX is clearly what was intended, both here and by its only user >> (count_history_pages at mm/readahead.c). > > Good catch, thanks! I actually have a more smart > radix_tree_prev_hole() that uses ULONG_MAX. I saw it already ([PATCH 14/16] radixtree: speed up the search for hole), but it misses the LONG_MAX in the documentation comment. > Andrew, fortunately this bug has little impact on readahead. I agree, if I read it correctly it should only have any impact either when very near LONG_MAX or in the unlikely case that there is no hole at ULONG_MAX. And even then, the impact should be limited. -- Cesar Eduardo Barros cesarb@...arb.net cesar.barros@...il.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists