public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	kirill.shutemov@linux.intel.com
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: [GIT PULL] x86/mm for 6.2
Date: Thu, 15 Dec 2022 13:53:07 -0800	[thread overview]
Message-ID: <242daeb2-b96b-d0dd-5597-ebf5fb2dfeca@intel.com> (raw)
In-Reply-To: <CAHk-=wjyy3iKS0B=A-yAPqjE3xiUU_5AiXApCasuYKTNu842dQ@mail.gmail.com>

On 12/15/22 09:26, Linus Torvalds wrote:
> But if you feel like all threads have to share the same LAM state, it
> does seem a lot simpler if you just say "you need to set that state
> before you start any threads". No?

That would be a lot simpler.  I have one bit of hesitation there, though.

Back in the MPX days, we had some users pop up and tell us that MPX
wasn't working for them on certain threads.  Those threads ended up
having been clone()'d even _before_ MPX got enabled which was via some
pre-main() startup code that the compiler inserted.  Since these early
threads' FPU state was copied before MPX setup was done, they never got
MPX-enabled.

Right or wrong, since then I've basically assumed that someone might be
creating threads behind my back.

Maybe we call those "early thread" folks too crazy to get LAM.  Maybe I
need to forget it ever happened, but they were actual users that got
bitten and cared enough to report it.  Or, heck, maybe I'm just
delusional because I can't find any trace of this conversation in the
list archives.

LAM _is_ slightly different than what MPX hit, though, since instead of
totally silent breakage the app can whine about the LAM prctl() having
failed.

Anyway, message heard loud and clear about the untagged_addr() races and
the interfaces.  We'll find some way to fix those up for the next merge
window.

  reply	other threads:[~2022-12-15 21:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 17:42 [GIT PULL] x86/mm for 6.2 Dave Hansen
2022-12-14 22:36 ` Linus Torvalds
2022-12-15 12:30   ` kirill.shutemov
2022-12-15 17:17     ` Linus Torvalds
2022-12-15 17:26       ` Linus Torvalds
2022-12-15 21:53         ` Dave Hansen [this message]
2022-12-15 22:46           ` Linus Torvalds
2022-12-16  2:16       ` kirill.shutemov
2022-12-16 15:05         ` Kirill A. Shutemov
2022-12-16 15:43           ` Linus Torvalds
2022-12-17 16:43             ` Kirill A. Shutemov
2022-12-16 20:09 ` Jason A. Donenfeld

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=242daeb2-b96b-d0dd-5597-ebf5fb2dfeca@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox