From: Ard Biesheuvel <email@example.com>
To: Marek Szyprowski <firstname.lastname@example.org>
Russell King <email@example.com>,
Nicolas Pitre <firstname.lastname@example.org>, Arnd Bergmann <email@example.com>,
Kees Cook <firstname.lastname@example.org>,
Keith Packard <email@example.com>,
Linus Walleij <firstname.lastname@example.org>,
Nick Desaulniers <email@example.com>,
Tony Lindgren <firstname.lastname@example.org>,
Krzysztof Kozlowski <email@example.com>,
Linux Samsung SOC <firstname.lastname@example.org>
Subject: Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
Date: Tue, 21 Dec 2021 14:34:47 +0100 [thread overview]
Message-ID: <CAMj1kXG3neg0riLAaU32KLvB2PLBNzwqgO0F21nbK1ivS=FwMg@mail.gmail.com> (raw)
On Tue, 21 Dec 2021 at 12:15, Marek Szyprowski <email@example.com> wrote:
> Hi Ard,
> On 21.12.2021 11:44, Ard Biesheuvel wrote:
> > On Tue, 21 Dec 2021 at 11:39, Marek Szyprowski <firstname.lastname@example.org> wrote:
> >> On 22.11.2021 10:28, Ard Biesheuvel wrote:
> >>> Wire up the generic support for managing task stack allocations via vmalloc,
> >>> and implement the entry code that detects whether we faulted because of a
> >>> stack overrun (or future stack overrun caused by pushing the pt_regs array)
> >>> While this adds a fair amount of tricky entry asm code, it should be
> >>> noted that it only adds a TST + branch to the svc_entry path. The code
> >>> implementing the non-trivial handling of the overflow stack is emitted
> >>> out-of-line into the .text section.
> >>> Since on ARM, we rely on do_translation_fault() to keep PMD level page
> >>> table entries that cover the vmalloc region up to date, we need to
> >>> ensure that we don't hit such a stale PMD entry when accessing the
> >>> stack. So we do a dummy read from the new stack while still running from
> >>> the old one on the context switch path, and bump the vmalloc_seq counter
> >>> when PMD level entries in the vmalloc range are modified, so that the MM
> >>> switch fetches the latest version of the entries.
> >>> Note that we need to increase the per-mode stack by 1 word, to gain some
> >>> space to stash a GPR until we know it is safe to touch the stack.
> >>> However, due to the cacheline alignment of the struct, this does not
> >>> actually increase the memory footprint of the struct stack array at all.
> >>> Signed-off-by: Ard Biesheuvel <email@example.com>
> >>> Tested-by: Keith Packard <firstname.lastname@example.org>
> >> This patch landed recently in linux-next 20211220 as commit a1c510d0adc6
> >> ("ARM: implement support for vmap'ed stacks"). Sadly it breaks
> >> suspend/resume operation on all ARM 32bit Exynos SoCs. Probably the
> >> suspend/resume related code must be updated somehow (it partially works
> >> on physical addresses and disabled MMU), but I didn't analyze it yet. If
> >> you have any hints, let me know.
> > Are there any such systems in KernelCI? We caught a suspend/resume
> > related issue in development, which is why the hunk below was added.
> I think that some Exynos-based Odroids (U3 and XU3) were some time ago
> available in KernelCI, but I don't know if they are still there.
> > In general, any virt-to-phys translation involving and address on the
> > stack will become problematic.
> > Could you please confirm whether the issue persists with the patch
> > applied but with CONFIG_VMAP_STACK turned off? Just so we know we are
> > looking in the right place?
> I've just checked. After disabling CONFIG_VMAP_STACK suspend/resume
> works fine both on commit a1c510d0adc6 and linux-next 20211220.
Thanks. Any other context you can provide beyond 'does not work' ?
linux-arm-kernel mailing list
next prev parent reply other threads:[~2021-12-21 13:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 9:28 [PATCH v4 0/7] ARM: add vmap'ed stack support Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 1/7] ARM: memcpy: use frame pointer as unwind anchor Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 2/7] ARM: memmove: " Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 3/7] ARM: memset: clean up unwind annotations Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 4/7] ARM: unwind: disregard unwind info before stack frame is set up Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 5/7] ARM: switch_to: clean up Thumb2 code path Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 6/7] ARM: entry: rework stack realignment code in svc_entry Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 7/7] ARM: implement support for vmap'ed stacks Ard Biesheuvel
[not found] ` <CGME20211221103854eucas1p2592e38fcc84c1c3506fce87f1dab6739@eucas1p2.samsung.com>
2021-12-21 10:38 ` Marek Szyprowski
2021-12-21 10:42 ` Krzysztof Kozlowski
2021-12-21 10:46 ` Marek Szyprowski
2021-12-21 10:44 ` Ard Biesheuvel
2021-12-21 11:15 ` Marek Szyprowski
2021-12-21 13:34 ` Ard Biesheuvel [this message]
2021-12-21 13:51 ` Marek Szyprowski
2021-12-21 16:20 ` Ard Biesheuvel
2021-12-21 21:56 ` Marek Szyprowski
2021-12-23 14:23 ` Ard Biesheuvel
2021-12-28 14:39 ` Geert Uytterhoeven
2021-12-28 16:12 ` Geert Uytterhoeven
2021-12-28 16:27 ` Ard Biesheuvel
2022-01-05 11:08 ` Jon Hunter
2022-01-05 11:12 ` Ard Biesheuvel
2022-01-05 11:33 ` Jon Hunter
2022-01-05 13:53 ` Russell King (Oracle)
2022-01-05 16:49 ` Jon Hunter
2022-01-05 17:02 ` Ard Biesheuvel
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).