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: <50C0F944.5040208@codeaurora.org> Date: Thu, 06 Dec 2012 12:00:04 -0800 From: Laura Abbott <lauraa@...eaurora.org> To: Mel Gorman <mgorman@...e.de> CC: linux-mm@...ck.org, linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org Subject: Re: [PATCH] mm: Use aligned zone start for pfn_to_bitidx calculation On 12/6/2012 2:12 AM, Mel Gorman wrote: > On Tue, Dec 04, 2012 at 02:10:01PM -0800, Laura Abbott wrote: >> The current calculation in pfn_to_bitidx assumes that >> (pfn - zone->zone_start_pfn) >> pageblock_order will return the >> same bit for all pfn in a pageblock. If zone_start_pfn is not >> aligned to pageblock_nr_pages, this may not always be correct. >> >> Consider the following with pageblock order = 10, zone start 2MB: >> >> pfn | pfn - zone start | (pfn - zone start) >> page block order >> ---------------------------------------------------------------- >> 0x26000 | 0x25e00 | 0x97 >> 0x26100 | 0x25f00 | 0x97 >> 0x26200 | 0x26000 | 0x98 >> 0x26300 | 0x26100 | 0x98 >> >> This means that calling {get,set}_pageblock_migratetype on a single >> page will not set the migratetype for the full block. The correct >> fix is to round down zone_start_pfn for the bit index calculation. >> Rather than do this calculation everytime, store this precalcualted >> algined start in the zone structure to allow the actual start_pfn to >> be used elsewhere. >> >> Change-Id: I13e2f53f50db294f38ec86138c17c6fe29f0ee82 >> Signed-off-by: Laura Abbott <lauraa@...eaurora.org> > > Hi Laura, > > There should be no need to add a new zone field. It's probably ok in terms > of functionality but it does mean that we have to worry about things like > hotplug (FWIW, should be fine) and the memory overhead is added even on > CONFIG_SPARSEMEM where it is not needed. Instead, mask out the lower bits > in pfn_to_bitidx() using the same round_down trick you already do. The > cost is negligible. > > Thanks. > I was debating if storing the size was actually necessary. I'll resubmit with the calculation done directly in the function. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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