From: Catalin Marinas <catalin.marinas@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
benh@amazon.com, Szabolcs Nagy <szabolcs.nagy@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: ucontext, kernel vs. userspace (glibc)
Date: Tue, 31 Aug 2021 18:44:14 +0100 [thread overview]
Message-ID: <YS5qbkE0WIDsF4qK@arm.com> (raw)
In-Reply-To: <131d684ea46de6330ab90532ab73729d6c0690bd.camel@kernel.crashing.org>
Hi Ben,
On Mon, Aug 30, 2021 at 08:40:03PM +1000, Benjamin Herrenschmidt wrote:
> So I'm discovering arm64 intricacies and today, as I was looking at SVE
> support (in the context of distro glibc backports.. don't ask), I
> noticed that glibc has no provision for dealing with kernel generated
> ucontext's in its {get,set,swap}_context functions...
>
> (It says so explicitly in the code unless I misunderstood).
>
> So one thing we did to "solve" this on ppc64 a while ago was to create
> a swapcontext syscall which can operate as all 3 operations (you can
> have NULL arguments), which also handles the sigprocmask (bonus:
> atomically with the context get/set from a userspace perspective).
>
> Would it make sense to do something similar on aarch64 ? (And have
> glibc then exploit it).
>
> The hard-to-solve thing is the case where the SVE context spills
> outside of the ucontext itself, in the extra room on the stack, since
> programs that "now" about ucontext will not have allocated space for
> that, so that's more/less a lost cause already.
I haven't fully parsed your email yet but adding a Mark B for SVE and
Szabolcs for glibc (and removing Dave who left Arm recently).
--
Catalin
_______________________________________________
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:[~2021-08-31 17:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 10:40 ucontext, kernel vs. userspace (glibc) Benjamin Herrenschmidt
2021-08-31 17:44 ` Catalin Marinas [this message]
2021-09-02 12:42 ` Mark Brown
2021-09-03 7:14 ` Benjamin Herrenschmidt
2021-09-03 11:02 ` Szabolcs Nagy
2021-09-03 12:25 ` 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=YS5qbkE0WIDsF4qK@arm.com \
--to=catalin.marinas@arm.com \
--cc=benh@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=szabolcs.nagy@arm.com \
--cc=will@kernel.org \
/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.