From: Peter Zijlstra <peterz@infradead.org>
To: Thiago Macieira <thiago.macieira@intel.com>
Cc: fweimer@redhat.com, "Enrico Weigelt,
metux IT consult" <lkml@metux.net>,
hjl.tools@gmail.com, libc-alpha@sourceware.org,
linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
x86@kernel.org
Subject: Re: x86 CPU features detection for applications (and AMX)
Date: Mon, 28 Jun 2021 19:43:47 +0200 [thread overview]
Message-ID: <20210628174347.GB13401@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <2094802.S4rhTtsRBG@tjmaciei-mobl1>
On Mon, Jun 28, 2021 at 09:13:29AM -0700, Thiago Macieira wrote:
> Anyway, what's the current thinking on what the arch_prctl() should be? Is
> that a per-thread state or will it affect the entire process group? And is it
> a sticky functionality, or are we talking about ref/deref?
So I didn't follow the initial discussion too well; so I might be
getting this wrong. In which case I'm hoping Thomas and/or Andy will
correct me.
But I think the proposal was per process. Having this per thread would
be really unfortunate IMO.
> Maybe in order to answer that, we need to understand what the worst case
> scenario we need to support is. What are they?
>
> 1) alt-stack signal handlers, usually for crashing signals (to catch a stack
> overflow)
>
> 2) cooperative user-space task schedulers, e.g. coroutines
>
> 3) preemptive user-space task schedulers (I don't know if such software exists
> or even if it is possible)
I think it's been done; use sigsetmask()/pthread_sigmask() as 'IRQ'
disable, and run a preemption tick off of SIGALRM or something.
> 4) combination of 1 and 3
None of those I think. The worst case is old executables using
MINSIGSTKSZ and not using the magic signal context at all, just regular
old signals. If you run them on an AVX512 enabled machine, they overflow
their stack and cause memory corruption.
AFAICT the only feasible way forward with that is some sysctl which
default disables AVX512 and add the prctl() and have some unsafe wrapper
that enables AVX512 for select 'legacy' programs for as long as they
exist :/
That is, binaries/libraries compiled against a static (and small)
MINSIGSTKSZ are the enemy. Which brings us to:
> 5) #4, in which each part is comes from a separate library with no knowledge
> of each other, and initialised concurrently in different threads
That's terrible... library init should *NEVER* spawn threads (I know,
don't start).
Anything that does this is basically unfixable, because we can't
guarantee the AMX prctl() gets done before the first thread.
So yes, worst case I suppose...
next prev parent reply other threads:[~2021-06-28 17:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 15:04 x86 CPU features detection for applications (and AMX) Florian Weimer
2021-06-23 15:32 ` Dave Hansen
2021-07-08 6:05 ` Florian Weimer
2021-07-08 14:19 ` Dave Hansen
2021-07-08 14:31 ` Florian Weimer
2021-07-08 14:36 ` Dave Hansen
2021-07-08 14:41 ` Florian Weimer
2021-06-25 23:31 ` Thiago Macieira
2021-06-28 12:40 ` Enrico Weigelt, metux IT consult
2021-06-28 13:20 ` Peter Zijlstra
2021-06-30 12:50 ` Enrico Weigelt, metux IT consult
2021-06-30 15:36 ` Thiago Macieira
2021-07-01 7:35 ` Enrico Weigelt, metux IT consult
2021-06-28 15:08 ` Thiago Macieira
2021-06-28 15:27 ` Peter Zijlstra
2021-06-28 16:13 ` Thiago Macieira
2021-06-28 17:11 ` Peter Zijlstra
2021-06-28 17:23 ` Thiago Macieira
2021-06-28 19:08 ` Peter Zijlstra
2021-06-28 19:26 ` Thiago Macieira
2021-06-28 17:43 ` Peter Zijlstra [this message]
2021-06-28 19:05 ` Thiago Macieira
2021-06-30 14:32 ` Enrico Weigelt, metux IT consult
2021-06-30 14:34 ` Florian Weimer
2021-06-30 15:16 ` Enrico Weigelt, metux IT consult
2021-06-30 15:38 ` Florian Weimer
2021-07-01 8:08 ` Enrico Weigelt, metux IT consult
2021-07-01 8:21 ` Florian Weimer
2021-07-01 11:59 ` Enrico Weigelt, metux IT consult
2021-07-06 12:57 ` Florian Weimer
2021-06-30 15:29 ` Thiago Macieira
2021-07-01 11:57 ` Enrico Weigelt, metux IT consult
2021-07-08 7:08 ` Florian Weimer
2021-07-08 15:13 ` Thiago Macieira
2021-07-08 17:56 ` 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=20210628174347.GB13401@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=lkml@metux.net \
--cc=thiago.macieira@intel.com \
--cc=x86@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.