Skip to content

Commit e041e0a

Browse files
committed
lib/bitmap: extend comment for bitmap_(from,to)_arr32()
On LE systems bitmaps are naturally ordered, therefore we can potentially use bitmap_copy routines when converting from 32-bit arrays, even if host system is 64-bit. But it may lead to out-of-bond access due to unsafe typecast, and the bitmap_(from,to)_arr32 comment doesn't explain that clearly CC: Alexander Gordeev <[email protected]> CC: Andy Shevchenko <[email protected]> CC: Christian Borntraeger <[email protected]> CC: Claudio Imbrenda <[email protected]> CC: David Hildenbrand <[email protected]> CC: Heiko Carstens <[email protected]> CC: Janosch Frank <[email protected]> CC: Rasmus Villemoes <[email protected]> CC: Sven Schnelle <[email protected]> CC: Vasily Gorbik <[email protected]> Signed-off-by: Yury Norov <[email protected]>
1 parent 6d7131b commit e041e0a

File tree

1 file changed

+6
-2
lines changed

1 file changed

+6
-2
lines changed

include/linux/bitmap.h

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -264,8 +264,12 @@ static inline void bitmap_copy_clear_tail(unsigned long *dst,
264264
}
265265

266266
/*
267-
* On 32-bit systems bitmaps are represented as u32 arrays internally, and
268-
* therefore conversion is not needed when copying data from/to arrays of u32.
267+
* On 32-bit systems bitmaps are represented as u32 arrays internally. On LE64
268+
* machines the order of hi and lo parts of numbers match the bitmap structure.
269+
* In both cases conversion is not needed when copying data from/to arrays of
270+
* u32. But in LE64 case, typecast in bitmap_copy_clear_tail() may lead
271+
* to out-of-bound access. To avoid that, both LE and BE variants of 64-bit
272+
* architectures are not using bitmap_copy_clear_tail().
269273
*/
270274
#if BITS_PER_LONG == 64
271275
void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf,

0 commit comments

Comments
 (0)