From: Mark Brown <broonie@kernel.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
benh@amazon.com, Szabolcs Nagy <szabolcs.nagy@arm.com>
Subject: Re: ucontext, kernel vs. userspace (glibc)
Date: Thu, 2 Sep 2021 13:42:36 +0100 [thread overview]
Message-ID: <20210902124236.GA4402@sirena.org.uk> (raw)
In-Reply-To: <131d684ea46de6330ab90532ab73729d6c0690bd.camel@kernel.crashing.org>
[-- Attachment #1.1: Type: text/plain, Size: 1448 bytes --]
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).
I think the usefulness of such an interface is mainly a question for
userspace - I don't immediately see any issue with implementing it if
it's useful to people.
> 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.
You can figure out the maximum possible size for a context so it would
be possible to define a mechanism for pointing to extra data I guess but
yeah, it's going to be a problem when we start seeing systems with large
enough register state.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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-09-02 12:45 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
2021-09-02 12:42 ` Mark Brown [this message]
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=20210902124236.GA4402@sirena.org.uk \
--to=broonie@kernel.org \
--cc=benh@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--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 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).