Re: ARM64 kernel crash

From: Robin Murphy
Date: Wed Dec 15 2021 - 07:29:34 EST


On 2021-12-15 10:53, Mark Rutland wrote:
Hi Chris,

On Wed, Dec 15, 2021 at 07:36:34AM +0000, Chris Ward wrote:
Please personally cc me on answers/comments as I am not currently
subscribed to the LKML.
Trying again because I messed up the format badly the first time
round. Apologies for that.

For arm/arm64 stuff, it's best to also Cc LAKML
(linux-arm-kernel@xxxxxxxxxxxxxxxxxxx). I've added that here, and for the
benefit of others I've kept your entire mail as context. In future replies I
will trim this.

Please also note that kernel mailing list style is to reply inline (as I've don
with this mail) rather than to top-post. That helps to keep discussions
legible, and makes it possible to trim irrelevant context. Please keep any
replies in kind with that style.

My team has a problem which is being bounced between Canonical support
and Xilinx support.
We are using kernel 5.4.0-xilinx-v2020.2 built from sources under
https://github.com/Xilinx/linux-xlnx with a Ubuntu 20.04 userland on
an ARM64 embedded linux machine (i.e. not x86-64).

Can you share the config used? e.g. was that `defconfig`, or something else?

When trying to set up a file system on a ramdisk, we get a kernel crash for
sizes of ramdisk larger than 2GB while trying to 'dd if=/dev/zero ...' in
preparation for issuing mkfs.

FWIW "larger than 2GB" immediately stands out as a massive red flag for signed integer overflow leading to memory corruption *somewhere*, and all the splats in the log below do look like they could simply be fallout from that.

Building the vendor kernel with KASAN enabled might be another worthwhile avenue of investigation - if that can flag up a wild memory access at the point where it actually occurs, you've got more chance of working backwards from there to the root cause.

Robin.