summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorBenjamin Marzinski <bmarzins@redhat.com>2026-07-06 16:23:24 -0400
committerYury Norov <ynorov@nvidia.com>2026-07-22 15:38:37 -0400
commit1c61b0a6e5c472737619f74f79c390363ee258df (patch)
tree3c75002308997ff5fc7937a20029b9bd3669a572 /tools/perf/scripts/python
parentdf81d444dc740778f7c7a2d4c3500136851375aa (diff)
bitops: make the *_bit_le functions use unsigned long
The *_bit_le functions use a signed integer for the bit number. However, the *_bit functions can use an unsigned long. This causes problems if there is a large bitmap and a bit number > 0x80000000 is passed in. Since that is a negative int, it will get sign extended to a long when getting passed to the *_bit function, turning it into a huge bit number. This usually ends up with the memory address wrapping around and the function accessing memory before the start of the bitmap. Avoid this by making the *_bit_le functions take an unsigned long. This can be triggered by faking an almost 4TB dm-mirror device, which uses bitmaps to track the mirror regions: $ dmsetup create bigzero --table '0 8589934590 zero' $ dmsetup create mymirror --table '0 8589934590 mirror core 2 2 nosync 2 /dev/mapper/bigzero 0 /dev/mapper/bigzero 0' This will access memory before the start of the sync_bits bitmap, and likely hit the guard page of the previously allocated clean_bits bitmap, causing a kernel panic with the old code. I looked and didn't see any crazy code using the signed int to intentionally try and access bits before some address within the bitmap. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions