mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Florian Weimer <fweimer@redhat.com>, Olivier Dion <odion@efficios.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	David Matlack <dmatlack@google.com>,
	Marco Elver <elver@google.com>,
	Sean Christopherson <seanjc@google.com>,
	Wei Liu <wei.liu@kernel.org>,
	Mathias Stearn <mathias@mongodb.com>,
	Chris Kennelly <ckennelly@google.com>,
	Blake Oler <blake.oler@mongodb.com>,
	Rich Felker <dalias@libc.org>,
	Matthew Wilcox <willy@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Carlos O'Donell <codonell@redhat.com>
Subject: Re: [RFC PATCH 1/5] rseq: uapi: add rseq operation definitions
Date: Wed, 09 Sep 2026 00:15:38 +0200	[thread overview]
Message-ID: <87h5jz1jat.ffs@fw13> (raw)
In-Reply-To: <lhuy0dbd4zd.fsf@oldenburg.str.redhat.com>

On Tue, Sep 08 2026 at 19:31, Florian Weimer wrote:
>>> Would it be possible to use actual CPU instructions running in userspace
>>> for this?  I assume not because it's not possible to restore the
>>> register contents.
>>
>> Well I had in mind another solution, albeit some might find it ugly but
>> I think it does have the merit to be explored.
>>
>> Basically, instead of doing all the operations in the kernel, we could
>> setup something akin to a signal handler by pushing a frame on the
>> userspace stack and resuming the execution of the thread into that
>> "handler".  Userspace is now responsible of everything, including
>> returning to the original IP.
>
> On mere context switch (not signal delivery), I don't think the kernel
> assumes that there is a valid stack pointer.  These scheme would change
> that.  This would be fine for managed code, but this scheme has to work
> with arbitrary code that reassigns registers temporarily.

You are right that aside of signal handling there is no assumption, but
as signal handling can happen at arbitrary times user space should not
play with SP unless there is an alternative signal stack, which has its
own nasties as we all know.

If there is truly code which needs to trainwreck SP for a sane reason
and not just because and has a good reason to utilize such a
library/functionality, then we can work around that by a mandating a
separate "fixup" stack per thread to enable this functionality. Then the
screwed up user space stack pointer becomes completely irrelevant and
the only interesting register on the kernel entry stack is the return IP
which got pushed by the hardware. And provide an option to work without
this indirection of course. :)

There are probably other solutions, but I really want to move this to
user space and not introduce yet another limited single purpose
"interpreter" in the kernel, which will be "extended" and duct taped
forever.

TBH. At some point we have to stop pretending that we can support all
possible insanities and their arbitrary combination. That just limits
ourself and puts the burden and the complexity into the wrong places
just because.

Thanks,

        tglx





  reply	other threads:[~2026-09-08 22:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 15:33 [RFC PATCH 0/5] rseq: add support for RSEQ operations odion
2026-08-28 15:33 ` [RFC PATCH 1/5] rseq: uapi: add rseq operation definitions odion
2026-08-29 22:34   ` Dmitry Vyukov
2026-08-29 22:47     ` Dmitry Vyukov
2026-08-31  8:37   ` Florian Weimer
2026-09-08 16:01     ` Olivier Dion
2026-09-08 17:31       ` Florian Weimer
2026-09-08 22:15         ` Thomas Gleixner [this message]
2026-08-28 15:33 ` [RFC PATCH 2/5] rseq: add per-task rseq operation state odion
2026-08-29 22:37   ` Dmitry Vyukov
2026-08-28 15:33 ` [RFC PATCH 3/5] rseq: apply operations on exit to user space odion
2026-08-29 22:42   ` Dmitry Vyukov
2026-08-28 15:33 ` [RFC PATCH 4/5] rseq: register and unregister operations via prctl odion
2026-08-29 22:50   ` Dmitry Vyukov
2026-08-28 15:33 ` [RFC PATCH 5/5] selftests/rseq: add coverage for rseq operations odion
2026-09-08 16:56 ` [RFC PATCH 0/5] rseq: add support for RSEQ operations Thomas Gleixner
2026-09-08 17:38   ` Olivier Dion
2026-09-08 21:29     ` Thomas Gleixner
2026-09-09 14:54       ` Dmitry Vyukov

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=87h5jz1jat.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=blake.oler@mongodb.com \
    --cc=boqun@kernel.org \
    --cc=ckennelly@google.com \
    --cc=codonell@redhat.com \
    --cc=dalias@libc.org \
    --cc=dmatlack@google.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=fweimer@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathias@mongodb.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=odion@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --cc=wei.liu@kernel.org \
    --cc=willy@infradead.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

all inboxes | Powered by JetHome®