* Q: does force_iret() make any sense today?
@ 2019-12-18 15:31 Oleg Nesterov
2019-12-18 15:45 ` Brian Gerst
0 siblings, 1 reply; 3+ messages in thread
From: Oleg Nesterov @ 2019-12-18 15:31 UTC (permalink / raw)
To: Andy Lutomirski, Borislav Petkov, Brian Gerst, Ingo Molnar, Peter Anvin
Cc: linux-kernel, x86
I do not pretend I understand the arch/x86/entry/ code, but it seems that
asm does all the necessary checks and the "extra" TIF_NOTIFY_RESUME simply
has no effect except tracehook_notify_resume() will be called for no reason?
Oleg.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Q: does force_iret() make any sense today?
2019-12-18 15:31 Q: does force_iret() make any sense today? Oleg Nesterov
@ 2019-12-18 15:45 ` Brian Gerst
2019-12-18 16:06 ` Oleg Nesterov
0 siblings, 1 reply; 3+ messages in thread
From: Brian Gerst @ 2019-12-18 15:45 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andy Lutomirski, Borislav Petkov, Ingo Molnar, Peter Anvin,
Linux Kernel Mailing List, the arch/x86 maintainers
On Wed, Dec 18, 2019 at 10:31 AM Oleg Nesterov <oleg@redhat.com> wrote:
>
> I do not pretend I understand the arch/x86/entry/ code, but it seems that
> asm does all the necessary checks and the "extra" TIF_NOTIFY_RESUME simply
> has no effect except tracehook_notify_resume() will be called for no reason?
It's a relic of a time before the more robust checks for
SYSRET/SYSEXIT were added. The idea was to divert the syscall return
flow off the fast path. Even if no exit work was done, the slow path
always returned with IRET. But with all the entry rework that has
been done it is no longer needed and can be removed.
--
Brian Gerst
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Q: does force_iret() make any sense today?
2019-12-18 15:45 ` Brian Gerst
@ 2019-12-18 16:06 ` Oleg Nesterov
0 siblings, 0 replies; 3+ messages in thread
From: Oleg Nesterov @ 2019-12-18 16:06 UTC (permalink / raw)
To: Brian Gerst
Cc: Andy Lutomirski, Borislav Petkov, Ingo Molnar, Peter Anvin,
Linux Kernel Mailing List, the arch/x86 maintainers
On 12/18, Brian Gerst wrote:
>
> On Wed, Dec 18, 2019 at 10:31 AM Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > I do not pretend I understand the arch/x86/entry/ code, but it seems that
> > asm does all the necessary checks and the "extra" TIF_NOTIFY_RESUME simply
> > has no effect except tracehook_notify_resume() will be called for no reason?
>
> It's a relic of a time before the more robust checks for
> SYSRET/SYSEXIT were added. The idea was to divert the syscall return
> flow off the fast path. Even if no exit work was done, the slow path
> always returned with IRET. But with all the entry rework that has
> been done it is no longer needed and can be removed.
Thanks, this was my understanding. Will you make a patch?
Oleg.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-18 16:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-18 15:31 Q: does force_iret() make any sense today? Oleg Nesterov
2019-12-18 15:45 ` Brian Gerst
2019-12-18 16:06 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).