Re: [BISECTED] kexec regression on PowerBook G4

[Christophe Leroy <christophe.leroy@c-s.fr>]

Le 24/05/2019 à 07:46, Christophe Leroy a écrit :
> Hi
> 
> Le 24/05/2019 à 00:23, Aaro Koskinen a écrit :
>> Hi,
>>
>> On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote:
>>> Le 23/05/2019 à 19:27, Aaro Koskinen a écrit :
>>>> On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote:
>>>>> Ok, the Oops confirms that the error is due to executing the kexec 
>>>>> control
>>>>> code which is located outside the kernel text area.
>>>>>
>>>>> My yesterday's proposed change doesn't work because on book3S/32, NX
>>>>> protection is based on setting segments to NX, and using IBATs for 
>>>>> kernel
>>>>> text.
>>>>>
>>>>> Can you try the patch I sent out a few minutes ago ?
>>>>> (https://patchwork.ozlabs.org/patch/1103827/)
>>>>
>>>> It now crashes with "BUG: Unable to handle kernel instruction fetch"
>>>> and the faulting address is 0xef13a000.
>>>
>>> Ok.
>>>
>>> Can you try with both changes at the same time, ie the mtsrin(...) 
>>> and the
>>> change_page_attr() ?
>>>
>>> I suspect that allthough the HW is not able to check EXEC flag, the 
>>> SW will
>>> check it before loading the hash entry.
>>
>> Unfortunately still no luck... The crash is pretty much the same with 
>> both
>> changes.
> 
> Right. In fact change_page_attr() does nothing because this part of RAM 
> is mapped by DBATs so v_block_mapped() returns not NULL.
> 
> So, we have to set an IBAT for this area. I'll try and send you a new 
> patch for that before noon (CET).
> 

patch sent out. In the patch I have also added a printk to print the 
buffer address, so if the problem still occurs, we'll know if the 
problem is really at the address of the buffer or if we are wrong from 
the beginning.

Christophe