All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Christoph Hellwig <hch@lst.de>,
	x86@kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-parisc@vger.kernel.org, linux-um@lists.infradead.org,
	netdev@vger.kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: clean up and streamline probe_kernel_* and friends v2
Date: Thu, 14 May 2020 01:04:38 +0200	[thread overview]
Message-ID: <10c58b09-5ece-e49f-a7c8-2aa6dfd22fb4@iogearbox.net> (raw)
In-Reply-To: <20200513160038.2482415-1-hch@lst.de>

On 5/13/20 6:00 PM, Christoph Hellwig wrote:
> Hi all,
> 
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing access to user memory.  It then switches x86
> over to this new mechanism by reusing the unsafe_* uaccess logic.
> 
> This version also switches to the saner copy_{from,to}_kernel_nofault
> naming suggested by Linus.
> 
> I kept the x86 helprs as-is without calling unsage_{get,put}_user as
> that avoids a number of hard to trace casts, and it will still work
> with the asm-goto based version easily.

Aside from comments on list, the series looks reasonable to me. For BPF
the bpf_probe_read() helper would be slightly penalized for probing user
memory given we now test on copy_from_kernel_nofault() first and if that
fails only then fall back to copy_from_user_nofault(), but it seems
small enough that it shouldn't matter too much and aside from that we have
the newer bpf_probe_read_kernel() and bpf_probe_read_user() anyway that
BPF progs should use instead, so I think it's okay.

For patch 14 and patch 15, do you roughly know the performance gain with
the new probe_kernel_read_loop() + arch_kernel_read() approach?

Thanks,
Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <daniel@iogearbox.net>
To: Christoph Hellwig <hch@lst.de>,
	x86@kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, bpf@vger.kernel.org
Subject: Re: clean up and streamline probe_kernel_* and friends v2
Date: Thu, 14 May 2020 01:04:38 +0200	[thread overview]
Message-ID: <10c58b09-5ece-e49f-a7c8-2aa6dfd22fb4@iogearbox.net> (raw)
In-Reply-To: <20200513160038.2482415-1-hch@lst.de>

On 5/13/20 6:00 PM, Christoph Hellwig wrote:
> Hi all,
> 
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing access to user memory.  It then switches x86
> over to this new mechanism by reusing the unsafe_* uaccess logic.
> 
> This version also switches to the saner copy_{from,to}_kernel_nofault
> naming suggested by Linus.
> 
> I kept the x86 helprs as-is without calling unsage_{get,put}_user as
> that avoids a number of hard to trace casts, and it will still work
> with the asm-goto based version easily.

Aside from comments on list, the series looks reasonable to me. For BPF
the bpf_probe_read() helper would be slightly penalized for probing user
memory given we now test on copy_from_kernel_nofault() first and if that
fails only then fall back to copy_from_user_nofault(), but it seems
small enough that it shouldn't matter too much and aside from that we have
the newer bpf_probe_read_kernel() and bpf_probe_read_user() anyway that
BPF progs should use instead, so I think it's okay.

For patch 14 and patch 15, do you roughly know the performance gain with
the new probe_kernel_read_loop() + arch_kernel_read() approach?

Thanks,
Daniel

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  parent reply	other threads:[~2020-05-13 23:04 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 16:00 clean up and streamline probe_kernel_* and friends v2 Christoph Hellwig
2020-05-13 16:00 ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 01/18] maccess: unexport probe_kernel_write and probe_user_write Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 02/18] maccess: remove various unused weak aliases Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 03/18] maccess: remove duplicate kerneldoc comments Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 04/18] maccess: clarify " Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 05/18] maccess: update the top of file comment Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 06/18] maccess: rename strncpy_from_unsafe_user to strncpy_from_user_nofault Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 07/18] maccess: rename strncpy_from_unsafe_strict to strncpy_from_kernel_nofault Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 08/18] maccess: rename strnlen_unsafe_user to strnlen_user_nofault Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 09/18] maccess: remove probe_read_common and probe_write_common Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 10/18] maccess: unify the probe kernel arch hooks Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-14  1:13   ` Masami Hiramatsu
2020-05-14  1:13     ` Masami Hiramatsu
2020-05-19  5:46     ` Christoph Hellwig
2020-05-19  5:46       ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 11/18] maccess: remove strncpy_from_unsafe Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 19:11   ` Linus Torvalds
2020-05-13 19:11     ` Linus Torvalds
2020-05-13 19:11     ` Linus Torvalds
2020-05-13 19:28     ` Christoph Hellwig
2020-05-13 19:28       ` Christoph Hellwig
2020-05-13 22:36       ` Daniel Borkmann
2020-05-13 22:36         ` Daniel Borkmann
2020-05-13 23:03         ` Linus Torvalds
2020-05-13 23:03           ` Linus Torvalds
2020-05-13 23:03           ` Linus Torvalds
2020-05-13 23:24           ` Daniel Borkmann
2020-05-13 23:24             ` Daniel Borkmann
2020-05-13 23:20         ` Masami Hiramatsu
2020-05-13 23:20           ` Masami Hiramatsu
2020-05-13 23:59           ` Linus Torvalds
2020-05-13 23:59             ` Linus Torvalds
2020-05-13 23:59             ` Linus Torvalds
2020-05-14  1:00             ` Masami Hiramatsu
2020-05-14  1:00               ` Masami Hiramatsu
2020-05-14  2:43               ` Linus Torvalds
2020-05-14  2:43                 ` Linus Torvalds
2020-05-14  2:43                 ` Linus Torvalds
2020-05-14  9:44                 ` Masami Hiramatsu
2020-05-14  9:44                   ` Masami Hiramatsu
2020-05-14 10:27                   ` Daniel Borkmann
2020-05-14 10:27                     ` Daniel Borkmann
2020-05-13 23:28         ` Al Viro
2020-05-13 23:28           ` Al Viro
2020-05-13 23:58           ` Daniel Borkmann
2020-05-13 23:58             ` Daniel Borkmann
2020-05-14 10:01             ` David Laight
2020-05-14 10:01               ` David Laight
2020-05-14 10:21               ` Daniel Borkmann
2020-05-14 10:21                 ` Daniel Borkmann
2020-05-13 16:00 ` [PATCH 12/18] maccess: always use strict semantics for probe_kernel_read Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 13/18] maccess: move user access routines together Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 14/18] maccess: allow architectures to provide kernel probing directly Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 19:36   ` Linus Torvalds
2020-05-13 19:36     ` Linus Torvalds
2020-05-13 19:36     ` Linus Torvalds
2020-05-13 19:40     ` Christoph Hellwig
2020-05-13 19:40       ` Christoph Hellwig
2020-05-13 19:48       ` Linus Torvalds
2020-05-13 19:48         ` Linus Torvalds
2020-05-13 19:48         ` Linus Torvalds
2020-05-13 19:54         ` Christoph Hellwig
2020-05-13 19:54           ` Christoph Hellwig
2020-05-16  3:42   ` Masami Hiramatsu
2020-05-16  3:42     ` Masami Hiramatsu
2020-05-18 15:09     ` Christoph Hellwig
2020-05-18 15:09       ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 15/18] x86: use non-set_fs based maccess routines Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 16:00 ` [PATCH 16/18] maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault Christoph Hellwig
2020-05-13 16:00   ` [PATCH 16/18] maccess: rename probe_kernel_{read, write} to copy_{from, to}_kernel_nofault Christoph Hellwig
2020-05-13 16:00 ` [PATCH 17/18] maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault Christoph Hellwig
2020-05-13 16:00   ` [PATCH 17/18] maccess: rename probe_user_{read, write} to copy_{from, to}_user_nofault Christoph Hellwig
2020-05-13 16:00 ` [PATCH 18/18] maccess: rename probe_kernel_address to get_kernel_nofault Christoph Hellwig
2020-05-13 16:00   ` Christoph Hellwig
2020-05-13 19:37 ` clean up and streamline probe_kernel_* and friends v2 Linus Torvalds
2020-05-13 19:37   ` Linus Torvalds
2020-05-13 19:37   ` Linus Torvalds
2020-05-13 23:04 ` Daniel Borkmann [this message]
2020-05-13 23:04   ` Daniel Borkmann
2020-05-13 23:20   ` Linus Torvalds
2020-05-13 23:20     ` Linus Torvalds
2020-05-13 23:20     ` Linus Torvalds
2020-05-19  5:50   ` Christoph Hellwig
2020-05-19  5:50     ` Christoph Hellwig

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=10c58b09-5ece-e49f-a7c8-2aa6dfd22fb4@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=mhiramat@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.