pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by
bdb5439c3f ("x86_64: Ensure frame-table
compression leaves MAX_ORDER aligned"), when changing to loop to start
from MAX_ORDER-1 an adjustment by 1 was needed in the call to
find_next_bit() but not done.
Fix the issue by passing j+1 and i+1 to find_next_zero_bit and
find_next_bit. Also add a check for i >= BITS_PER_LONG because
find_{,next_}zero_bit() are free to assume that their last argument is
less than their middle one.
Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
CC: andrew.cooper3@citrix.com
CC: JBeulich@suse.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: konrad.wilk@oracle.com
CC: tim@xen.org
CC: wei.liu2@citrix.com
*/
for ( j = MAX_ORDER-1; ; )
{
- i = find_next_zero_bit(&mask, BITS_PER_LONG, j);
- j = find_next_bit(&mask, BITS_PER_LONG, i);
+ i = find_next_zero_bit(&mask, BITS_PER_LONG, j + 1);
+ if ( i >= BITS_PER_LONG )
+ break;
+ j = find_next_bit(&mask, BITS_PER_LONG, i + 1);
if ( j >= BITS_PER_LONG )
break;
if ( j - i > hole_shift )