From: Robin Murphy <robin.murphy@arm.com>
To: Mark Rutland <mark.rutland@arm.com>, tjcw@cantab.net
Cc: linux-kernel@vger.kernel.org, Chris Ward <tjcw01@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: ARM64 kernel crash
Date: Wed, 15 Dec 2021 12:29:25 +0000 [thread overview]
Message-ID: <96bbd76e-3667-749a-1fda-458e6fa40a27@arm.com> (raw)
In-Reply-To: <YbnCbyPdsRNFb1iz@FVFF77S0Q05N>
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@lists.infradead.org). 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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-12-15 12:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAC=wTOhV_QTAbH+u8amNF4+wu6ae5qCLmtWW4Z2zNdVZHrfA=Q@mail.gmail.com>
2021-12-15 10:53 ` ARM64 kernel crash Mark Rutland
2021-12-15 12:29 ` Robin Murphy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96bbd76e-3667-749a-1fda-458e6fa40a27@arm.com \
--to=robin.murphy@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=tjcw01@gmail.com \
--cc=tjcw@cantab.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox