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 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.