m68k 54418 fails to execute user space

[Jean-Michel Hautbois]

Hi Michael,

On 26/06/2024 03:56, Michael Schmitz wrote:
> Jean-Michel,
> 
> On 24/06/24 20:56, Jean-Michel Hautbois wrote:
>>
>> When I printk the do_page_fault first debug, I get for the first call 
>> to ls:
>> bash-5.2# ls
>> [   14.700000] do page fault:
>> [   14.700000] regs->sr=0x0, regs->pc=0x70069ee6, address=0x70069ee6, 
>> 0, (ptrval)
> 
> Page not present, read fault. Please disable obfuscation of kernel 
> pointer addresses by printk. Maybe also disable address space 
> randomization while debugging this.

Randomization is disabled, I think I don't have hash pointers... Will 
heck again, thanks for the explanation.

> 
>> This call works almost fine (I still have the assert failed: 
>> folio->private != NULL issue).
>>
>> And when I call it a second time, I get:
>> bash-5.2# ls
>> [   19.820000] do page fault:
>> [   19.820000] regs->sr=0x0, regs->pc=0x6011d65a, address=0x700e2004, 
>> 2, (ptrval)
> 
> Page not present, write fault.
> 
> It would be helpful if you could get a dump of /proc/1/maps before the 
> execve() syscall in your helloworld init replacement. That might confirm 
> all these addresses are legit (assuming mappings survive across 
> execve(), that is), and what they correspond to.

Executing mount /proc will make it impossible to then call cat 
/proc/1/maps :-(. Can I enable a printk somewhere in the kernel to do 
the same maybe ?

JM

> 
>>
>> The address corresponds to the defined zone ELF_ET_DYN_BASE as I set 
>> it to 0x70000000.
>>
>> regs->pc is not the same as the address. It might be unrelevant, but 
>> any help is appreciated to understand the process behind :-).
>>
>> I keep digging, and I am in the asm part which fears me a bit !
> 
> I don't see that you'd need to look at any asm code here.
> 
> Cheers,
> 
>      Michael
> 
>>
>> Thanks !
>> JM