lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 May 2019 15:32:06 +0200
From:   Jann Horn <>
To:     Kirill Tkhai <>
Cc:     Andrew Morton <>,
        Dan Williams <>,
        Michal Hocko <>,,
        "Kirill A . Shutemov" <>,,
        Alexander Duyck <>,, Andrey Konovalov <>,, Vlastimil Babka <>,
        Christoph Lameter <>,
        Rik van Riel <>,
        Kees Cook <>,,,
        Mathieu Desnoyers <>,
        Shakeel Butt <>,
        Roman Gushchin <>,
        Andrea Arcangeli <>,
        Hugh Dickins <>,
        Jerome Glisse <>,
        Mel Gorman <>,,
        kernel list <>,
        Linux-MM <>,
        Linux API <>
Subject: Re: [PATCH RFC 0/5] mm: process_vm_mmap() -- syscall for duplication
 a process mapping

On Wed, May 15, 2019 at 5:11 PM Kirill Tkhai <> wrote:
> This patchset adds a new syscall, which makes possible
> to clone a mapping from a process to another process.
> The syscall supplements the functionality provided
> by process_vm_writev() and process_vm_readv() syscalls,
> and it may be useful in many situation.
> The proposed syscall aims to introduce an interface, which
> supplements currently existing process_vm_writev() and
> process_vm_readv(), and allows to solve the problem with
> anonymous memory transfer. The above example may be rewritten as:
>         void *buf;
>         buf = mmap(NULL, n * PAGE_SIZE, PROT_READ|PROT_WRITE,
>                    MAP_PRIVATE|MAP_ANONYMOUS, ...);
>         recv(sock, buf, n * PAGE_SIZE, 0);
>         /* Sign of @pid is direction: "from @pid task to current" or vice versa. */
>         process_vm_mmap(-pid, buf, n * PAGE_SIZE, remote_addr, PVMMAP_FIXED);
>         munmap(buf, n * PAGE_SIZE);

In this specific example, an alternative would be to splice() from the
socket into /proc/$pid/mem, or something like that, right?
proc_mem_operations has no ->splice_read() at the moment, and it'd
need that to be more efficient, but that could be built without
creating new UAPI, right?

But I guess maybe your workload is not that simple? What do you
actually do with the received data between receiving it and shoving it
over into the other process?

Powered by blists - more mailing lists