All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Dave Watson <davejwatson@fb.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	Paul Turner <pjt@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Hunter <ahh@google.com>, Andi Kleen <andi@firstfloor.org>,
	Chris Lameter <cl@linux.com>, Ben Maurer <bmaurer@fb.com>,
	rostedt <rostedt@goodmis.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@a>
Subject: Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)
Date: Mon, 16 Apr 2018 15:21:19 -0400 (EDT)	[thread overview]
Message-ID: <435471300.11403.1523906479091.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CA+55aFzZtY5ELKc+TGf9BA6px300BNzedadm_yNXzODTKN=HgQ@mail.gmail.com>

----- On Apr 16, 2018, at 2:39 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

> On Mon, Apr 16, 2018 at 11:35 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> Specifically for single-stepping, the __rseq_table section introduced
>> at user-level will allow newer debuggers and tools which do line and
>> instruction-level single-stepping to skip over rseq critical sections.
>> However, this breaks existing debuggers and tools.
> 
> I really don't think single-stepping is a valid argument.
> 
> Even if the cpu_opv() allows you to "single step", you're not actually
> single stepping the same thing that you're using. So you are literally
> debugging something else than the real code.
> 
> At that point, you don't need "cpu_opv()", you need to just load
> /dev/urandom in a buffer, and single-step that. Ta-daa! No new kernel
> functionality needed.
> 
> So if the main argument for cpu_opv is single-stepping, then just rip
> it out. It's not useful.

No, single-stepping is not the only use-case. Accessing remote cpu
data is another use-case fulfilled by cpu_opv, which I think is more
compelling.

> 
> Anybody who cares deeply about single-stepping shouldn't be using
> optimistic algorithms, and they shouldn't be doing multi-threaded
> stuff either. They won't be able to use things like transactional
> memory either.
> 
> You can't single-step into the kernel to see what the kernel does
> either when you're debugging something.
> 
> News at 11: "single stepping isn't always viable".

I don't mind if people cannot stop the program with a debugger and
observe the state of registers manually at each step though a rseq
critical section.

I do mind breaking existing tools that rely on single-stepping
approaches to automatically analyze program behavior [1,2].
Introducing a rseq critical section into a library (e.g. glibc
memory allocator) would cause existing programs being analyzed
with existing tools to hang.

And I try very hard to avoid being told I'm the one breaking
user-space. ;-)

Thanks,

Mathieu

[1] http://rr-project.org/
[2] https://www.gnu.org/software/gdb/news/reversible.html

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Dave Watson <davejwatson@fb.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	Paul Turner <pjt@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Hunter <ahh@google.com>, Andi Kleen <andi@firstfloor.org>,
	Chris Lameter <cl@linux.com>, Ben Maurer <bmaurer@fb.com>,
	rostedt <rostedt@goodmis.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)
Date: Mon, 16 Apr 2018 15:21:19 -0400 (EDT)	[thread overview]
Message-ID: <435471300.11403.1523906479091.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CA+55aFzZtY5ELKc+TGf9BA6px300BNzedadm_yNXzODTKN=HgQ@mail.gmail.com>

----- On Apr 16, 2018, at 2:39 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

> On Mon, Apr 16, 2018 at 11:35 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> Specifically for single-stepping, the __rseq_table section introduced
>> at user-level will allow newer debuggers and tools which do line and
>> instruction-level single-stepping to skip over rseq critical sections.
>> However, this breaks existing debuggers and tools.
> 
> I really don't think single-stepping is a valid argument.
> 
> Even if the cpu_opv() allows you to "single step", you're not actually
> single stepping the same thing that you're using. So you are literally
> debugging something else than the real code.
> 
> At that point, you don't need "cpu_opv()", you need to just load
> /dev/urandom in a buffer, and single-step that. Ta-daa! No new kernel
> functionality needed.
> 
> So if the main argument for cpu_opv is single-stepping, then just rip
> it out. It's not useful.

No, single-stepping is not the only use-case. Accessing remote cpu
data is another use-case fulfilled by cpu_opv, which I think is more
compelling.

> 
> Anybody who cares deeply about single-stepping shouldn't be using
> optimistic algorithms, and they shouldn't be doing multi-threaded
> stuff either. They won't be able to use things like transactional
> memory either.
> 
> You can't single-step into the kernel to see what the kernel does
> either when you're debugging something.
> 
> News at 11: "single stepping isn't always viable".

I don't mind if people cannot stop the program with a debugger and
observe the state of registers manually at each step though a rseq
critical section.

I do mind breaking existing tools that rely on single-stepping
approaches to automatically analyze program behavior [1,2].
Introducing a rseq critical section into a library (e.g. glibc
memory allocator) would cause existing programs being analyzed
with existing tools to hang.

And I try very hard to avoid being told I'm the one breaking
user-space. ;-)

Thanks,

Mathieu

[1] http://rr-project.org/
[2] https://www.gnu.org/software/gdb/news/reversible.html

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2018-04-16 19:21 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 19:27 [RFC PATCH for 4.18 00/23] Restartable sequences and CPU op vector Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 01/23] uapi headers: Provide types_32_64.h (v2) Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 02/23] rseq: Introduce restartable sequences system call (v13) Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 03/23] arm: Add restartable sequences support Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 04/23] arm: Wire up restartable sequences system call Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 05/23] x86: Add support for restartable sequences (v2) Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 06/23] x86: Wire up restartable sequence system call Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 07/23] powerpc: Add support for restartable sequences Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 08/23] powerpc: Wire up restartable sequences system call Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 09/23] sched: Implement push_task_to_cpu (v2) Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 10/23] mm: Introduce vm_map_user_ram, vm_unmap_user_ram Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 11/23] mm: Provide is_vma_noncached Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7) Mathieu Desnoyers
2018-04-12 19:43   ` Linus Torvalds
2018-04-12 19:43     ` Linus Torvalds
2018-04-12 19:59     ` Mathieu Desnoyers
2018-04-12 19:59       ` Mathieu Desnoyers
2018-04-12 20:07       ` Linus Torvalds
2018-04-12 20:07         ` Linus Torvalds
2018-04-13 12:16         ` Mathieu Desnoyers
2018-04-13 12:16           ` Mathieu Desnoyers
2018-04-13 16:37           ` Linus Torvalds
2018-04-13 16:37             ` Linus Torvalds
2018-04-13 18:06             ` Mathieu Desnoyers
2018-04-13 18:06               ` Mathieu Desnoyers
2018-04-12 20:23     ` Andi Kleen
2018-04-12 20:23       ` Andi Kleen
2018-04-16 16:28       ` Mathieu Desnoyers
2018-04-16 16:28         ` Mathieu Desnoyers
2018-04-16 17:02         ` Andi Kleen
2018-04-16 17:02           ` Andi Kleen
2018-04-14 22:44     ` Andy Lutomirski
2018-04-14 22:44       ` Andy Lutomirski
2018-04-16 18:35       ` Mathieu Desnoyers
2018-04-16 18:35         ` Mathieu Desnoyers
2018-04-16 18:39         ` Linus Torvalds
2018-04-16 18:39           ` Linus Torvalds
2018-04-16 19:21           ` Mathieu Desnoyers [this message]
2018-04-16 19:21             ` Mathieu Desnoyers
2018-04-16 19:26             ` Linus Torvalds
2018-04-16 19:26               ` Linus Torvalds
2018-04-16 20:58               ` Mathieu Desnoyers
2018-04-16 20:58                 ` Mathieu Desnoyers
2018-05-04 14:32                 ` Mathieu Desnoyers
2018-05-04 14:32                   ` Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 13/23] x86: Wire up cpu_opv system call Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 14/23] powerpc: " Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 15/23] arm: " Mathieu Desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 16/23] selftests: lib.mk: Introduce OVERRIDE_TARGETS Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 17/23] cpu_opv: selftests: Implement selftests (v7) Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 18/23] rseq: selftests: Provide rseq library (v5) Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 19/23] rseq: selftests: Provide percpu_op API Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 20/23] rseq: selftests: Provide basic test Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 21/23] rseq: selftests: Provide basic percpu ops test Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:27 ` [RFC PATCH for 4.18 22/23] rseq: selftests: Provide parametrized tests Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` Mathieu Desnoyers
2018-04-12 19:27   ` mathieu.desnoyers
2018-04-12 19:28 ` [RFC PATCH for 4.18 23/23] rseq: selftests: Provide Makefile, scripts, gitignore Mathieu Desnoyers
2018-04-12 19:28   ` Mathieu Desnoyers
2018-04-12 19:28   ` Mathieu Desnoyers
2018-04-12 19:28   ` mathieu.desnoyers

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=435471300.11403.1523906479091.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ahh@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=davejwatson@fb.com \
    --cc=hpa@zytor.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@a \
    /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.