[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKkKhCFpaWm1hb8r3GHx10KBRQvpJNTtYPSAc6m28A7sQA@mail.gmail.com>
Date: Mon, 29 Mar 2021 12:38:59 -0400
From: Len Brown <lenb@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Andy Lutomirski <luto@...nel.org>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>,
Dave Hansen <dave.hansen@...el.com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
libc-alpha <libc-alpha@...rceware.org>,
Florian Weimer <fweimer@...hat.com>,
Rich Felker <dalias@...c.org>, Kyle Huey <me@...ehuey.com>,
Keno Fischer <keno@...iacomputing.com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
> In particular, the library may use instructions that main() doesn't know exist.
And so I'll ask my question another way.
How is it okay to change the value of XCR0 during the run time of a program?
I submit that it is not, and that is a deal-killer for a request/release API.
eg. main() doesn't know that the math library wants to use AMX,
and neither does the threading library. So main() doesn't know to
call the API before either library is invoked. The threading library starts up
and creates user-space threads based on the initial value from XCR0.
Then the math library calls the API, which adds bits to XCRO,
and then the user-space context switch in the threading library corrupts data
because the new XCR0 size doesn't match the initial size.
-Len
Powered by blists - more mailing lists