On Sat, May 16, 2020 at 12:42:59PM +0900, Masami Hiramatsu wrote:
> > Provide alternative versions of probe_kernel_read, probe_kernel_write
> > and strncpy_from_kernel_unsafe that don't need set_fs magic, but instead
> > use arch hooks that are modelled after unsafe_{get,put}_user to access
> > ker
Hi Christoph,
On Wed, 13 May 2020 18:00:34 +0200
Christoph Hellwig wrote:
> Provide alternative versions of probe_kernel_read, probe_kernel_write
> and strncpy_from_kernel_unsafe that don't need set_fs magic, but instead
> use arch hooks that are modelled after unsafe_{get,put}_user to access
>
On Wed, May 13, 2020 at 12:48:54PM -0700, Linus Torvalds wrote:
> Looking at the current users of "probe_kernel_read()", it looks like
> it's almost mostly things that just want a single byte or word.
>
> It's not 100% that: we definitely do several things that want the
> "copy" semantics vs the "
On Wed, May 13, 2020 at 12:40 PM Christoph Hellwig wrote:
>
> We do export something like it, currently it is called
> probe_kernel_address, and the last patch renames it to
> get_kernel_nofault. However it is implemented as a wrapper
> around probe_kernel_address / copy_from_kernel_nofault and t
On Wed, May 13, 2020 at 12:36:18PM -0700, Linus Torvalds wrote:
> > + arch_kernel_read(dst, src, type, err_label);\
>
> I'm wondering if
>
> (a) we shouldn't expose this as an interface in general
We do export something like it, currently it is called
probe_kernel_addr
On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig wrote:
>
> + arch_kernel_read(dst, src, type, err_label);\
I'm wondering if
(a) we shouldn't expose this as an interface in general
(b) it wouldn't be named differently..
The reason for (a) is that several users of t
Provide alternative versions of probe_kernel_read, probe_kernel_write
and strncpy_from_kernel_unsafe that don't need set_fs magic, but instead
use arch hooks that are modelled after unsafe_{get,put}_user to access
kernel memory in an exception safe way.
Signed-off-by: Christoph Hellwig
---
mm/ma
