On Mon, Jul 18, 2022 at 09:11:33PM +, Jane Chu wrote:
> On 7/18/2022 12:22 PM, Luck, Tony wrote:
> >> It appears the kernel is trusting that ->physical_addr_mask is non-zero
> >> in other paths. So this is at least equally broken in the presence of a
> >> broken BIOS. The impact is potentially
On 7/18/2022 12:22 PM, Luck, Tony wrote:
>> It appears the kernel is trusting that ->physical_addr_mask is non-zero
>> in other paths. So this is at least equally broken in the presence of a
>> broken BIOS. The impact is potentially larger though with this change,
>> so it might be a good
> It appears the kernel is trusting that ->physical_addr_mask is non-zero
> in other paths. So this is at least equally broken in the presence of a
> broken BIOS. The impact is potentially larger though with this change,
> so it might be a good follow-on patch to make sure that
>
Luck, Tony wrote:
> +m.misc = (MCI_MISC_ADDR_PHYS << 6) | __ffs64(mem_err->physical_addr_mask);
>
> Do we want to unconditionally trust the sanity of the BIOS provided
> physical_address_mask?
>
> There's a warning comment on the kernel __ffs64() function:
>
> * The result is not defined if
+ m.misc = (MCI_MISC_ADDR_PHYS << 6) |
__ffs64(mem_err->physical_addr_mask);
Do we want to unconditionally trust the sanity of the BIOS provided
physical_address_mask?
There's a warning comment on the kernel __ffs64() function:
* The result is not defined if no bits are set, so check
5 matches
Mail list logo
