Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Christoph Hellwig]

To try to reproduce your report I built a mps2_defconfig kernel
and then run the qemu command line manually extraced from your
script below, using a mainline qemu built for arm-softmmu, but it
crashes with the following message even for the baseline kernel.

qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
XPSR=40000003 -Z-- A handler
FPSCR: 00000000

Does anyone have an idea what this means?


---
/opt/qemu/bin/qemu-system-arm \
	-M mps2-an385 \
	-cpu cortex-m3 \
	-dtb arch/arm/boot/dts/mps2-an385.dtb \
	-kernel vmlinux \
	-no-reboot \
        -snapshot -m 16 \
        -initrd ~/images/rootfs-arm-m3.cpio \
        -append 'panic=-1' \
	-bios ~/images/mps2-boot.axf \
	-nographic -monitor null -serial stdio

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Guenter Roeck]

On 7/20/20 3:01 AM, Christoph Hellwig wrote:
> To try to reproduce your report I built a mps2_defconfig kernel
> and then run the qemu command line manually extraced from your
> script below, using a mainline qemu built for arm-softmmu, but it
> crashes with the following message even for the baseline kernel.
> 
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> 
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> XPSR=40000003 -Z-- A handler
> FPSCR: 00000000
> 
> Does anyone have an idea what this means?
> 

Ah, sorry, you can't use the upstream version of qemu to test mps2-an385
Linux images. You'll have to use a version from https://github.com/groeck/qemu.
I'd recommend to use the v5.0.0-local branch.

I had to make some changes to qemu to be able to boot mps2-an385.
I tried to submit those changes into upstream qemu, but that was
rejected because, as I was told, the qemu implementation
would no longer reflect the real hardware with those changes in
place.

Guenter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Peter Maydell]

On Mon, 20 Jul 2020 at 15:55, Guenter Roeck <linux@roeck-us.net> wrote:
> Ah, sorry, you can't use the upstream version of qemu to test mps2-an385
> Linux images. You'll have to use a version from https://github.com/groeck/qemu.
> I'd recommend to use the v5.0.0-local branch.
>
> I had to make some changes to qemu to be able to boot mps2-an385.
> I tried to submit those changes into upstream qemu, but that was
> rejected because, as I was told, the qemu implementation
> would no longer reflect the real hardware with those changes in
> place.

Yes; the rationale is that if you wanted to boot a kernel
on an actual MPS2 board you'd need a bit of guest code to
start it up (and to bundle the initrd/dtb in with it), so
since you need to write that code anyway you could use it for
booting the kernel in QEMU too.

I appreciate that this is awkward for kernel developers (and
perhaps for some other users too), but QEMU's handling of
-kernel and built-in-bootloader code is already a morass of
special cases and do-what-I-mean behaviour that I'm not
enthusiastic about further complicating :-)

(https://lists.gnu.org/archive/html/qemu-arm/2018-06/msg00393.html
has the archive of our original discussion on the point, for
other readers of this post interested in further context and
discussion.)

thanks
-- PMM

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel