[PATCH] target/hppa: prevent overflow in BTLB entry size calculation

[gerben@altlinux.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1155 bytes --]

1) I’m not entirely sure why using long long is considered “always wrong,”
especially since just a few lines above there’s a similar usage here:

qemu_log_mask(CPU_LOG_MMU, "PDC_BLOCK_TLB: PDC_BTLB_INSERT "
                    "0x%08llx-0x%08llx: vpage 0x%llx for phys page 0x%04x len %d "
                    "into slot %d\n",
                    (long long) virt_page << TARGET_PAGE_BITS,
                    (long long) (virt_page + len) << TARGET_PAGE_BITS,
                    (long long) virt_page, phys_page, len, slot);

That said, I do agree that using long long here might not be the best approach, and I’ll fix it.

2) If len can approach INT32_MAX, why wouldn’t the calculation len * TARGET_PAGE_SIZE cause an overflow?
This operation is done between an unsigned int and a constant, and uses 32-bit arithmetic.
I agree this patch likely doesn’t affect real scenarios — when running the Debian image
I saw only values where len <= 2048 and TARGET_PAGE_SIZE = 4096, so no overflow would occur.
However, as I understand it, these values come from outside and are not validated anywhere,
so theoretically they could be arbitrary.