All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Lutomirski <luto@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	Brian Gerst <brgerst@gmail.com>, Juergen Gross <JGross@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [patch 4/8] x86/entry: Move irq tracing on syscall entry to C-code
Date: Mon, 02 Mar 2020 09:10:01 +0100	[thread overview]
Message-ID: <8736arfa92.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CALCETrVfXmKLN9AxOeizr1mHTA9CSG5-_UgoH8hruTMrrA-0vA@mail.gmail.com>

Andy Lutomirski <luto@kernel.org> writes:
> On Sun, Mar 1, 2020 at 10:26 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>> > So tracing itself is fine, but then if you have probes or bpf programs
>> > attached to a tracepoint these use rcu_read_lock()/unlock() which is
>> > obviosly wrong in rcuidle context.
>>
>> Definitely, any such code needs to use tricks similar to that of the
>> tracing code.  Or instead use something like SRCU, which is OK with
>> readers from idle.  Or use something like Steve Rostedt's workqueue-based
>> approach, though please be very careful with this latter, lest the
>> battery-powered embedded guys come after you for waking up idle CPUs
>> too often.  ;-)
>>
>
> Are we okay if we somehow ensure that all the entry code before
> enter_from_user_mode() only does rcuidle tracing variants and has
> kprobes off?  Including for BPF use cases?

I think this is the right thing to do. The only requirement we have
_before_ enter_from_user_mode() is to tell lockdep that interrupts are
off. There is not even the need for a real tracepoint IMO. The fact that
the lockdep call is hidden in that tracepoint is just an implementation
detail.

That would clearly set the rules straight: Anything low level entry code
before enter_from_user_mode() returns is neither probable nor
traceable.

I know that some people will argue that this is too restrictive in terms
of instrumentation, but OTOH the whole low level entry code has to be
excluded from instrumentation anyway, so having a dozen instructions
more excluded does not matter at all. Keep it simple!

> It would be *really* nice if we could statically verify this, as has
> been mentioned elsewhere in the thread.  It would also probably be
> good enough if we could do it at runtime.  Maybe with lockdep on, we
> verify rcu state in tracepoints even if the tracepoint isn't active?
> And we could plausibly have some widget that could inject something
> into *every* kprobeable function to check rcu state.

That surely would be useful.

Thanks,

        tglx

  parent reply	other threads:[~2020-03-02  8:10 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25 22:08 [patch 0/8] x86/entry: Consolidation - Part II Thomas Gleixner
2020-02-25 22:08 ` [patch 1/8] x86/entry/64: Trace irqflags unconditionally on when returing to user space Thomas Gleixner
2020-02-27 19:49   ` Borislav Petkov
2020-02-27 22:45   ` Frederic Weisbecker
2020-02-28  8:58   ` Alexandre Chartre
2020-02-25 22:08 ` [patch 2/8] x86/entry/common: Consolidate syscall entry code Thomas Gleixner
2020-02-27 19:57   ` Borislav Petkov
2020-02-27 22:52   ` Frederic Weisbecker
2020-02-28  8:59   ` Alexandre Chartre
2020-02-25 22:08 ` [patch 3/8] x86/entry/common: Mark syscall entry points notrace/nokprobe Thomas Gleixner
2020-02-27 23:15   ` Frederic Weisbecker
2020-02-28  8:59   ` Alexandre Chartre
2020-02-25 22:08 ` [patch 4/8] x86/entry: Move irq tracing on syscall entry to C-code Thomas Gleixner
2020-02-26  5:43   ` Andy Lutomirski
2020-02-26  8:17     ` Peter Zijlstra
2020-02-26 11:20       ` Andy Lutomirski
2020-02-26 19:51         ` Thomas Gleixner
2020-02-29 14:44           ` Thomas Gleixner
2020-02-29 19:25             ` Andy Lutomirski
2020-02-29 23:58               ` Steven Rostedt
2020-03-01 10:16                 ` Thomas Gleixner
2020-03-01 14:37                   ` Andy Lutomirski
2020-03-01 15:21                     ` Thomas Gleixner
2020-03-01 16:00                       ` Andy Lutomirski
2020-03-01 18:12                         ` Thomas Gleixner
2020-03-01 18:26                           ` Paul E. McKenney
2020-03-01 18:54                             ` Andy Lutomirski
2020-03-01 19:30                               ` Paul E. McKenney
2020-03-01 19:39                                 ` Andy Lutomirski
2020-03-01 20:18                                   ` Paul E. McKenney
2020-03-02  0:35                                   ` Steven Rostedt
2020-03-02  6:47                                     ` Masami Hiramatsu
2020-03-02  1:10                               ` Joel Fernandes
2020-03-02  2:18                                 ` Andy Lutomirski
2020-03-02  2:36                                   ` Joel Fernandes
2020-03-02  5:40                                     ` Andy Lutomirski
2020-03-02  8:10                               ` Thomas Gleixner [this message]
2020-03-01 18:23                         ` Steven Rostedt
2020-03-01 18:20                       ` Steven Rostedt
2020-02-27 23:11   ` Frederic Weisbecker
2020-02-28  9:00   ` Alexandre Chartre
2020-02-25 22:08 ` [patch 5/8] x86/entry/common: Provide trace/kprobe safe exit to user space functions Thomas Gleixner
2020-02-26  5:45   ` Andy Lutomirski
2020-02-26  8:15     ` Peter Zijlstra
2020-02-27 15:43   ` Alexandre Chartre
2020-02-27 15:53     ` Thomas Gleixner
2020-02-25 22:08 ` [patch 6/8] x86/entry: Move irq tracing to syscall_slow_exit_work Thomas Gleixner
2020-02-26  5:47   ` Andy Lutomirski
2020-02-27 16:12   ` Alexandre Chartre
2020-02-25 22:08 ` [patch 7/8] x86/entry: Move irq tracing to prepare_exit_to_user_mode() Thomas Gleixner
2020-02-26  5:50   ` Andy Lutomirski
2020-02-26 19:53     ` Thomas Gleixner
2020-02-26 20:07       ` Andy Lutomirski
2020-02-25 22:08 ` [patch 8/8] x86/entry: Move irqflags tracing to do_int80_syscall_32() Thomas Gleixner
2020-02-27 16:46   ` Alexandre Chartre
2020-02-28 13:49     ` Thomas Gleixner

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=8736arfa92.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=JGross@suse.com \
    --cc=arnd@arndb.de \
    --cc=brgerst@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.