RE: A bug about system call on ARM

From: Wang, Yalin
Date: Wed May 29 2013 - 05:51:12 EST


Hi

This is kernel.log and the stack which is recovered by Trace32 tools.
Please have a look at it .

Thanks

-----Original Message-----
From: Will Deacon [mailto:will.deacon@xxxxxxx]
Sent: Wednesday, May 29, 2013 5:48 PM
To: richard -rw- weinberger
Cc: Wang, Yalin; linux-arch@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Subject: Re: A bug about system call on ARM

Hello,

On Wed, May 29, 2013 at 09:46:42AM +0100, richard -rw- weinberger wrote:
> On Wed, May 29, 2013 at 10:24 AM, Wang, Yalin <Yalin.Wang@xxxxxxxxxxxxxx> wrote:
> > I have download the latest linux kernel code 3.9.4 And Compare with
> > 3.4.0 kernel .
> >
> > It seems there is no change for this part , So it will still happen
> > .
> > Does anyone know who is responsible for arm arch part kernel code ?
>
> See MAINTAINERS file.
> CC'ing linux-arm-kernel@xxxxxxxxxxxxxxxxxxx

Cheers for adding us to CC.

> >> #ifdef CONFIG_ARM_THUMB
> >> tst r8, #PSR_T_BIT
> >> movne r10, #0 @ no thumb OABI emulation
> >> ldreq r10, [lr, #-4] @ get SWI instruction // crash at this instruction, when get SWI instruction

Do you have the panic log please? Also, which SoC are you using and how are you reproducing this?

> >> ldr r10, [lr, #-4] @ get SWI instruction
> >> A710( and ip, r10, #0x0f000000 @ check for SWI )
> >> A710( teq ip, #0x0f000000 )
> >> A710( bne .Larm710bug )
> >> #endif
> >> #ifdef CONFIG_CPU_ENDIAN_BE8
> >> rev r10, r10 @ little endian instruction
> >> #endif
> >>
> >> /******************************************************************
> >> ***
> >> ******************************/
> >>
> >> Then reason why it will crash when get SWI instruction is maybe
> >> This page is clear to aged by kernel, But this MMU fault happpened
> >> in kernel, So the kernel do_page_fault function will not clear this
> >> page to young, So that will crash .

Sounds like we might need some USER annotations around the instruction loads, but we should also rework the code so that we re-enable interrupts first.

Will

Attachment: kernel.log
Description: kernel.log

crash_noites_save_this_cpu(type = CRASH_NOTE_CRASHING = 0x2, cpu = 0x1)
update_crash_notes(?, ?, ?)
notifier_call_chain(?, val = 0x0, v = 0xC0ECBE9C, nr_to_call = 0x5, nr_calls = 0x0)
__atomic_notifier_call_chain(nh = 0xC0ECC29C, val = 0x0, v = 0xC0ECBE9C, nr_to_call = 0xFFFFFFFF, nr_calls = 0x0)
atomic_notifier_call_chain(?, ?, ?)
panic(fmt = 0xC098BC02)
die(?, regs = 0xE0601F68, err = 0x17)
__do_kernel_fault.part.8(mm = 0xC73E7DC0, addr = 0x4020841C, fsr = 0x17, regs = 0xE0601F68)
do_page_fault(addr = 0xC73E7DC0, fsr = 0x17, regs = 0x4020841C)
do_DataAbort(addr = 0x4020841C, fsr = 0x17, regs = 0xE0601F68)
__dabt_svc(asm)
exception
vector_swi(asm)
ret_fast_syscall(asm)
exception
NUR:0xFFFF:0x40208420(asm)
end of frame