[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWLk9LKV4+_mrOKDc3GUvXbCjqA5R6cdpqq02xoRCBOHw@mail.gmail.com>
Date: Wed, 23 Oct 2019 14:30:51 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Will Deacon <will@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
kvm list <kvm@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Mike Rapoport <rppt@...ux.ibm.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Miroslav Benes <mbenes@...e.cz>
Subject: Re: [patch V2 08/17] x86/entry: Move syscall irq tracing to C code
On Wed, Oct 23, 2019 at 5:31 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Interrupt state tracing can be safely done in C code. The few stack
> operations in assembly do not need to be covered.
>
> Remove the now pointless indirection via .Lsyscall_32_done and jump to
> swapgs_restore_regs_and_return_to_usermode directly.
This doesn't look right.
> #define SYSCALL_EXIT_WORK_FLAGS \
> @@ -279,6 +282,9 @@ static void syscall_slow_exit_work(struc
> {
> struct thread_info *ti;
>
> + /* User to kernel transition disabled interrupts. */
> + trace_hardirqs_off();
> +
So you just traced IRQs off, but...
> enter_from_user_mode();
> local_irq_enable();
Now they're on and traced on again?
I also don't see how your patch handles the fastpath case.
How about the attached patch instead?
View attachment "irqtrace.patch" of type "text/x-patch" (2651 bytes)
Powered by blists - more mailing lists