Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
To:     =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= <j.neuschaefer@gmx.net>
Cc:     linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
        linux-kernel@vger.kernel.org
References: <cover.1543517818.git.christophe.leroy@c-s.fr>
 <8835330baa77d88e0267b0b1215b78c991e6d17a.1543517818.git.christophe.leroy@c-s.fr>
 <20181203215558.GK15324@latitude>
 <84624899-bbda-9f08-2527-151fddbd1b01@c-s.fr>
 <a253e9f8-1e0a-1596-e0ea-54261ac62212@c-s.fr>
 <20181217012837.GT15324@latitude>
 <18ba3a7c-ebfa-66aa-e231-b56985d0e89a@c-s.fr>
 <20181218030538.GA24278@latitude>
 <9a39d910-2a05-3ce7-c949-296db2d458b9@c-s.fr>
 <20181218140714.GC24278@latitude>
 <96539c09-ea57-43d6-bae9-7371235b175f@c-s.fr>
 <ee4322c4-60e1-94c5-1e55-5d4c3e4de03b@c-s.fr>
From:   Christophe Leroy <christophe.leroy@c-s.fr>
Message-ID: <c1ee5c7f-d683-924f-68cb-43e1fe14363a@c-s.fr>
Date:   Tue, 18 Dec 2018 16:04:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <ee4322c4-60e1-94c5-1e55-5d4c3e4de03b@c-s.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Le 18/12/2018 ? 15:55, Christophe Leroy a ?crit?:
> 
> 
> Le 18/12/2018 ? 15:15, Christophe Leroy a ?crit?:
>>
>>
>> Le 18/12/2018 ? 15:07, Jonathan Neusch?fer a ?crit?:
>>> On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote:
>>>> The only difference I see then are the flags. Everything else is seems
>>>> identical.
>>>>
>>>> I know you tried already, but would you mind trying once more with the
>>>> following change ?
>>>>
>>> [...]
>>>> -??????? setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
>>>> +??????? setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X);
>>>
>>> Good call, with this workaround on top of patches 1-3, it boots again:
>>>
>>> ????# mount -t debugfs d /sys/kernel/debug
>>> ????# cat /sys/kernel/debug/powerpc/block_address_translation
>>> ????---[ Instruction Block Address Translation ]---
>>> ????0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC
>>> ????1:???????? -
>>> ????2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC
>>> ????3:???????? -
>>> ????4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC
>>> ????5:???????? -
>>> ????6:???????? -
>>> ????7:???????? -
>>>
>>> ????---[ Data Block Address Translation ]---
>>> ????0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW
>>> ????1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded
>>> ????2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW
>>> ????3:???????? -
>>> ????4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW
>>> ????5:???????? -
>>> ????6:???????? -
>>> ????7:???????? -
>>>
>>>> I think we may have some code trying to modify the kernel text 
>>>> without using
>>>> code patching functions.
>>>
>>> Is there any faster way than to sprinkle some printks in setup_kernel
>>> and try to find the guilty piece of code this way?
>>
>> Can you start with the serie 
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ?
> 
> Ok, the thing I was thinking about was the MMU_init_hw() but it is 
> called before mapin_ram() so it should not be a problem. Not sure that 
> serie improves anything at all here.
> 
> So there must be something else, pretty early (before the system is able 
> to properly handle and display an Oops for write to RO area.)
> 
> Does anybody have an idea of what it can be ?


Stupid of me. In fact at the time being, BATS cover both RO and RW data 
areas, so it can definitly not be mapped with PAGE_KERNEL_ROX.

In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is 
PAGE_KERNEL_X on my side. That's the reason why I missed it.

With this change being done to patch 3, does the overall serie works for 
you ?

Thanks
Christophe


> 
> Christophe
> 
>>
>> Christophe
>>
>>>
>>>
>>> Jonathan
>>>