Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp653874yba; Thu, 16 May 2019 06:59:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlhkIgi+gqJWyEx1eAHlRS72os1B/YkqSHHGz+j36DZTMdljocwVa6/1ZM95eHLY0L/WV2 X-Received: by 2002:a63:c106:: with SMTP id w6mr46935107pgf.422.1558015176785; Thu, 16 May 2019 06:59:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558015176; cv=none; d=google.com; s=arc-20160816; b=sxDtZpbV+dNLka1pjmrAZQUdaNlIoJ1Jgg6pDmAsytTK8B6WKfx8z3BKzUf/lfSCm2 6bi2e9xhZIEGzi9cigJVb/cFKPQWqE5EakXfui9bNjCAVgZggmkHDxaDVdb+NvwLz9ri gQr/io+H8wBPT3DV/FYmQPdgOlUAP5taMSGTrvSWf58RnoaiDD9oPBfppPU+aPiWA0NT sXK1fa6t1v7KjapRUTNGe4prJCrtFzLbcapeWPD6ea+SHT3/4lT8sj8NdJ1utC34kELa //igJKGQFds+5UWQrCgeRAr14oHXG7yO5NY+CKSH6AN8pfnWhS5BFT8NEwRgaIFGINBK G7jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hMg6dnhzdcWw2ldpfI8t/8HN5Ji8Fr/MgcAD4iNFIxU=; b=pzRfcj1kDIC4ytOeH+KXcnHSumO3vupHSTgMKXn3rIRq8KFF/1bCmfyxzH1r7HOgxp /CgHEAn5kK6XAbv2NbXtHFU09MzrFfUgKVdZo4wX9VQowraUouUY9QxdGfkbQR8euVLV OFvtSE5Avo3ofYTczN7SULxyKfJIKEddAzej7yMJv7PBaRHluemVm/Nvoq3I3LbPD6KR NeX6sMKq7uyzj0UC2FKqC55rrrgKBVcalAh8CrMwtJMDM1Kd8W0tR6bgumKNwDiTJGmy wFiq3sHdqTGMwz1R4LXEtpqpJKjNhHiY/JTipvU+6oLBgiO8ScQw+3bJZ7o1GQircR6W v67A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 126si5172122pgc.2.2019.05.16.06.59.20; Thu, 16 May 2019 06:59:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727774AbfEPN5E (ORCPT + 99 others); Thu, 16 May 2019 09:57:04 -0400 Received: from relay.sw.ru ([185.231.240.75]:54072 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726911AbfEPN5E (ORCPT ); Thu, 16 May 2019 09:57:04 -0400 Received: from [172.16.25.169] by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1hRGsK-00075H-1m; Thu, 16 May 2019 16:56:48 +0300 Subject: Re: [PATCH RFC 0/5] mm: process_vm_mmap() -- syscall for duplication a process mapping To: Jann Horn Cc: Andrew Morton , Dan Williams , Michal Hocko , keith.busch@intel.com, "Kirill A . Shutemov" , pasha.tatashin@oracle.com, Alexander Duyck , ira.weiny@intel.com, Andrey Konovalov , arunks@codeaurora.org, Vlastimil Babka , Christoph Lameter , Rik van Riel , Kees Cook , hannes@cmpxchg.org, npiggin@gmail.com, Mathieu Desnoyers , Shakeel Butt , Roman Gushchin , Andrea Arcangeli , Hugh Dickins , Jerome Glisse , Mel Gorman , daniel.m.jordan@oracle.com, kernel list , Linux-MM , Linux API References: <155793276388.13922.18064660723547377633.stgit@localhost.localdomain> From: Kirill Tkhai Message-ID: <89124a45-ddfd-9c96-1957-304f67d4b9bc@virtuozzo.com> Date: Thu, 16 May 2019 16:56:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16.05.2019 16:32, Jann Horn wrote: > 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? I have just never seen, a socket memory may be preempted into swap. If so, there is a fundamental problem. But, anyway, like you guessed below: > 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? Data are usually sent encrypted and compressed by socket, so there is no possibility to go this way. You may want to do everything with data, before passing to another process. Kirill