From: Will Deacon <will@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset
Date: Fri, 9 Feb 2024 17:11:55 +0000 [thread overview]
Message-ID: <20240209171155.GB25069@willie-the-truck> (raw)
In-Reply-To: <CAD=FV=XupbtO3_+P9=XO26vH_5nALSSLZZHZywPSR_hQsWxM0Q@mail.gmail.com>
Hi Doug,
On Mon, Feb 05, 2024 at 09:02:08AM -0800, Doug Anderson wrote:
> Hi,
>
> On Sat, Feb 3, 2024 at 4:18 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Doug Anderson observed that ChromeOS crashes are being reported which
> > include failing allocations of order 7 during core dumps due to ptrace
> > allocating storage for regsets:
> >
> > chrome: page allocation failure: order:7,
> > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
> > nodemask=(null),cpuset=urgent,mems_allowed=0
> > ...
> > regset_get_alloc+0x1c/0x28
> > elf_core_dump+0x3d8/0xd8c
> > do_coredump+0xeb8/0x1378
> >
> > with further investigation showing that this is:
> >
> > [ 66.957385] DOUG: Allocating 279584 bytes
> >
> > which is the maximum size of the SVE regset. As Doug observes it is not
> > entirely surprising that such a large allocation of contiguous memory might
> > fail on a long running system.
> >
> > The SVE regset is currently sized to hold SVE registers with a VQ of
> > SVE_VQ_MAX which is 512, substantially more than the architectural maximum
> > of 16 which we might see even in a system emulating the limits of the
> > architecture. Since we don't expose the size we tell the regset core
> > externally let's define ARCH_SVE_VQ_MAX with the actual architectural
> > maximum and use that for the regset, we'll still overallocate most of the
> > time but much less so which will be helpful even if the core is fixed to
> > not require contiguous allocations.
> >
> > We could also teach the ptrace core about runtime discoverable regset sizes
> > but that would be a more invasive change and this is being observed in
> > practical systems.
> >
> > Reported-by: Doug Anderson <dianders@chromium.org>
> > Signed-off-by: Mark Brown <broonie@kernel.org>
>
> Confirmed that when I send a "quit" signal to Chrome now that the
> allocation I see for "core_note_type" NT_ARM_SVE goes down from
> 279,584 bytes (n=17474) to just 8,768 bytes (n=548). I'm not
> intimately familiar with this code so I'll skip the Reviewed-by unless
> someone thinks it would be valuable for me to analyze more. I think
> there are already plenty of people who know this well, so for now,
> just:
>
> Tested-by: Douglas Anderson <dianders@chromium.org>
I can pick this up as a short-term hack if it solves the problem for you,
but I also saw that you posted:
https://lore.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid
to fallback onto vmalloc() for large allocations.
What's your preference for a fix?
Cheers,
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset
Date: Fri, 9 Feb 2024 17:11:55 +0000 [thread overview]
Message-ID: <20240209171155.GB25069@willie-the-truck> (raw)
In-Reply-To: <CAD=FV=XupbtO3_+P9=XO26vH_5nALSSLZZHZywPSR_hQsWxM0Q@mail.gmail.com>
Hi Doug,
On Mon, Feb 05, 2024 at 09:02:08AM -0800, Doug Anderson wrote:
> Hi,
>
> On Sat, Feb 3, 2024 at 4:18 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Doug Anderson observed that ChromeOS crashes are being reported which
> > include failing allocations of order 7 during core dumps due to ptrace
> > allocating storage for regsets:
> >
> > chrome: page allocation failure: order:7,
> > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
> > nodemask=(null),cpuset=urgent,mems_allowed=0
> > ...
> > regset_get_alloc+0x1c/0x28
> > elf_core_dump+0x3d8/0xd8c
> > do_coredump+0xeb8/0x1378
> >
> > with further investigation showing that this is:
> >
> > [ 66.957385] DOUG: Allocating 279584 bytes
> >
> > which is the maximum size of the SVE regset. As Doug observes it is not
> > entirely surprising that such a large allocation of contiguous memory might
> > fail on a long running system.
> >
> > The SVE regset is currently sized to hold SVE registers with a VQ of
> > SVE_VQ_MAX which is 512, substantially more than the architectural maximum
> > of 16 which we might see even in a system emulating the limits of the
> > architecture. Since we don't expose the size we tell the regset core
> > externally let's define ARCH_SVE_VQ_MAX with the actual architectural
> > maximum and use that for the regset, we'll still overallocate most of the
> > time but much less so which will be helpful even if the core is fixed to
> > not require contiguous allocations.
> >
> > We could also teach the ptrace core about runtime discoverable regset sizes
> > but that would be a more invasive change and this is being observed in
> > practical systems.
> >
> > Reported-by: Doug Anderson <dianders@chromium.org>
> > Signed-off-by: Mark Brown <broonie@kernel.org>
>
> Confirmed that when I send a "quit" signal to Chrome now that the
> allocation I see for "core_note_type" NT_ARM_SVE goes down from
> 279,584 bytes (n=17474) to just 8,768 bytes (n=548). I'm not
> intimately familiar with this code so I'll skip the Reviewed-by unless
> someone thinks it would be valuable for me to analyze more. I think
> there are already plenty of people who know this well, so for now,
> just:
>
> Tested-by: Douglas Anderson <dianders@chromium.org>
I can pick this up as a short-term hack if it solves the problem for you,
but I also saw that you posted:
https://lore.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid
to fallback onto vmalloc() for large allocations.
What's your preference for a fix?
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-09 17:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-03 12:16 [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Mark Brown
2024-02-03 12:16 ` Mark Brown
2024-02-05 17:02 ` Doug Anderson
2024-02-05 17:02 ` Doug Anderson
2024-02-09 17:11 ` Will Deacon [this message]
2024-02-09 17:11 ` Will Deacon
2024-02-09 17:40 ` Mark Brown
2024-02-09 17:40 ` Mark Brown
2024-02-05 17:11 ` Dave Martin
2024-02-05 17:11 ` Dave Martin
2024-02-05 17:41 ` Mark Brown
2024-02-05 17:41 ` Mark Brown
2024-02-07 12:23 ` Dave Martin
2024-02-07 12:23 ` Dave Martin
2024-02-07 13:09 ` Mark Brown
2024-02-07 13:09 ` Mark Brown
2024-02-07 13:51 ` Dave Martin
2024-02-07 13:51 ` Dave Martin
2024-02-07 15:07 ` Mark Brown
2024-02-07 15:07 ` Mark Brown
2024-02-12 16:50 ` Dave Martin
2024-02-12 16:50 ` Dave Martin
2024-02-12 17:09 ` Mark Brown
2024-02-12 17:09 ` Mark Brown
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=20240209171155.GB25069@willie-the-truck \
--to=will@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dianders@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.