From: Peter Zijlstra <[email protected]>
To: Linus Torvalds <[email protected]>
Cc: Andy Lutomirski <[email protected]>,
Thomas Gleixner <[email protected]>,
Stefan Metzmacher <[email protected]>, Jens Axboe <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
io-uring <[email protected]>,
the arch/x86 maintainers <[email protected]>,
[email protected]
Subject: Re: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads
Date: Tue, 4 May 2021 10:39:23 +0200 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHk-=wh0KoEZXPYMGkfkeVEerSCEF1AiCZSvz9TRrx=Kj74D+Q@mail.gmail.com>
+ linux-toolchains
On Mon, May 03, 2021 at 12:14:45PM -0700, Linus Torvalds wrote:
> On Mon, May 3, 2021 at 9:05 AM Andy Lutomirski <[email protected]> wrote:
> >
> > Linus, what is the actual effect of allowing gdb to attach these threads? Can we instead make all the regset ops do:
> >
> > if (not actually a user thread) return -EINVAL;
>
> I don't think it matters - the end result ends up being the same, ie
> gdb gets confused about whether the (parent) thread is a 32-bit or
> 64-bit one.
>
> So the basic issue is
>
> (a) we want the IO threads to look exactly like normal user threads
> as far as the kernel is concerned, because we had way too many bugs
> due to special cases.
>
> (b) but that means that they are also visible to user space, and then
> gdb has this odd thing where it takes the 64-bit vs 32-bit data for
> the whole process from one thread, and picks the worst possible thread
> to do it (ie explicitly not even the main thread, so usually the IO
> thread!)
>
> That (a) ended up really being critical. The issues with special cases
> were just horrendous, both for security issues (ie "make them kernel
> threads but carry user credentials" just caused lots of problems) but
> also for various just random other state handling issues (signal state
> in particular).
>
> So generally, the IO threads are now 100% normal threads - it's
> literally just that they never return to user space because they are
> always just doing the IO offload on the kernel side.
>
> That part is lovely, but part of the "100% IO threads" really is that
> they share the signal struct too, which in turn means that they very
> much show up as normal threads. Again, not a problem: they really
> _are_ normal threads for all intents and purposes.
>
> But then that (b) issue means that gdb gets confused by them. I
> personally think that's just a pure gdb mis-feature, but I also think
> that "hey, if we just make the register state look like the main
> thread, and unconfuse gdb that way, problem solved".
>
> So I'd actually rather not make these non-special threads any more
> special at all. And I strongly suspect that making ptrace() not work
> on them will just confuse gdb even more - so it would make them just
> unnecessarily special in the kernel, for no actual gain.
>
> Is the right thing to do to fix gdb to not look at irrelevant thread B
> when deciding whether thread A is 64-bit or not? Yeah, that seems like
> obviously the RightThing(tm) to me.
>
> But at the same time, this is arguably about "regression", although at
> the same time it's "gdb doesn't understand new user programs that use
> new features, film at 11", so I think that argument is partly bogus
> too.
>
> So my personal preference would be:
>
> - make those threads look even more like user threads, even if that
> means giving them pointless user segment data that the threads
> themselves will never use
>
> So I think Stefan's patch is reasonable, if not pretty. Literally
> becasue of that "make these threads look even more normal"
>
> - ALSO fix gdb that is doing obviously garbage stupid things
>
> But I'm obviously not involved in that "ALSO fix gdb" part, and
> arguably the kernel hack then makes it more likely that gdb will
> continue doing its insane broken thing.
Anybody on toolchains that can help get GDB fixed?
next prev parent reply other threads:[~2021-05-04 8:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[email protected]>
2021-05-03 16:05 ` [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads Andy Lutomirski
2021-05-03 19:14 ` Linus Torvalds
2021-05-03 20:15 ` Andy Lutomirski
2021-05-03 20:21 ` Andy Lutomirski
2021-05-03 20:37 ` Linus Torvalds
2021-05-03 21:26 ` Jens Axboe
2021-05-03 21:49 ` Andy Lutomirski
2021-05-03 22:08 ` Linus Torvalds
2021-05-03 22:56 ` Thomas Gleixner
2021-05-03 23:15 ` Andy Lutomirski
2021-05-03 23:16 ` Linus Torvalds
2021-05-03 23:19 ` Linus Torvalds
2021-05-03 23:27 ` Stefan Metzmacher
2021-05-03 23:48 ` Linus Torvalds
2021-05-04 2:50 ` Jens Axboe
2021-05-04 11:39 ` Stefan Metzmacher
2021-05-04 15:53 ` Linus Torvalds
2021-05-12 4:24 ` Olivier Langlois
2021-05-12 17:44 ` Linus Torvalds
2021-05-12 20:55 ` Jens Axboe
2021-05-20 4:13 ` Olivier Langlois
2021-05-21 7:31 ` Olivier Langlois
2021-05-25 19:39 ` Olivier Langlois
2021-05-25 19:45 ` Olivier Langlois
2021-05-25 19:52 ` Jens Axboe
2021-05-25 20:23 ` Linus Torvalds
2021-05-04 8:22 ` David Laight
2021-05-04 0:01 ` Andy Lutomirski
2021-05-04 8:39 ` Peter Zijlstra [this message]
2021-05-04 15:35 ` Borislav Petkov
2021-05-04 15:55 ` Simon Marchi
2021-05-05 11:29 ` Stefan Metzmacher
2021-05-05 21:59 ` Simon Marchi
2021-05-05 22:11 ` Andy Lutomirski
2021-05-05 23:12 ` Borislav Petkov
2021-05-05 23:22 ` Andy Lutomirski
2021-05-06 1:04 ` Simon Marchi
2021-05-06 15:11 ` Andy Lutomirski
2021-05-06 9:47 ` David Laight
2021-05-06 9:53 ` David Laight
2021-05-05 22:21 ` Stefan Metzmacher
2021-05-05 23:15 ` Simon Marchi
2021-04-11 15:27 Stefan Metzmacher
2021-04-14 21:28 ` Stefan Metzmacher
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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