From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73858 invoked by alias); 28 Feb 2018 23:12:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 73845 invoked by uid 89); 28 Feb 2018 23:12:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HTo:U*devel X-HELO: mta01.ornl.gov Received: from mta01.ornl.gov (HELO mta01.ornl.gov) (128.219.177.137) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Feb 2018 23:12:07 +0000 X-SG: RELAYLIST Received: from emgwy2.ornl.gov ([160.91.254.10]) by iron1.ornl.gov with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2018 18:12:05 -0500 Received: from EXCHCS31.ornl.gov (exchcs31.ornl.gov [128.219.12.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by emgwy2.ornl.gov (Postfix) with ESMTPS id 3zsBCn0Qrfz2T5hv; Wed, 28 Feb 2018 18:12:05 -0500 (EST) Received: from EXCHCS34.ornl.gov (128.219.12.148) by EXCHCS31.ornl.gov (128.219.12.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 28 Feb 2018 18:12:04 -0500 Received: from EXCHCS33.ornl.gov (128.219.12.147) by EXCHCS34.ornl.gov (128.219.12.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 28 Feb 2018 18:12:04 -0500 Received: from EXCHCS33.ornl.gov ([fe80::8d3a:2313:2176:93cd]) by EXCHCS33.ornl.gov ([fe80::8d3a:2313:2176:93cd%15]) with mapi id 15.00.1320.000; Wed, 28 Feb 2018 18:12:04 -0500 From: "Atchley, Scott" To: Open MPI Developers CC: Andrew Morton , Mike Rapoport , Alexander Viro , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "criu@openvz.org" , "gdb@sourceware.org" , "rr-dev@mozilla.org" , Arnd Bergmann , Michael Kerrisk , Thomas Gleixner , Josh Triplett , Jann Horn , Greg KH , Andrei Vagin Subject: Re: [OMPI devel] [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe Date: Wed, 28 Feb 2018 23:12:00 -0000 Message-ID: References: <1515479453-14672-1-git-send-email-rppt@linux.vnet.ibm.com> <20180220164406.3ec34509376f16841dc66e34@linux-foundation.org> <3122ec5a-7f73-f6b4-33ea-8c10ef32e5b0@virtuozzo.com> <20180227021818.GA31386@altlinux.org> <627ac4f8-a52d-0582-0c9e-e70ea667fa7e@virtuozzo.com> In-Reply-To: <627ac4f8-a52d-0582-0c9e-e70ea667fa7e@virtuozzo.com> x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-ID: <37B81FBCB154B54D891DDE89E76BC0D1@ornl.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2018-02/txt/msg00112.txt.bz2 > On Feb 28, 2018, at 2:12 AM, Pavel Emelyanov wrote: >=20 > On 02/27/2018 05:18 AM, Dmitry V. Levin wrote: >> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote: >>> On 02/21/2018 03:44 AM, Andrew Morton wrote: >>>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport wrote: >>>>=20 >>>>> This patches introduces new process_vmsplice system call that combines >>>>> functionality of process_vm_read and vmsplice. >>>>=20 >>>> All seems fairly strightforward. The big question is: do we know that >>>> people will actually use this, and get sufficient value from it to >>>> justify its addition? >>>=20 >>> Yes, that's what bothers us a lot too :) I've tried to start with findi= ng out if anyone=20 >>> used the sys_read/write_process_vm() calls, but failed :( Does anybody = know how popular >>> these syscalls are? >>=20 >> Well, process_vm_readv itself is quite popular, it's used by debuggers n= owadays, >> see e.g. >> $ strace -qq -esignal=3Dnone -eprocess_vm_readv strace -qq -o/dev/null c= at /dev/null >=20 > I see. Well, yes, this use-case will not benefit much from remote splice.= How about more > interactive debug by, say, gdb? It may attach, then splice all the memory= , then analyze > the victim code/data w/o copying it to its address space? >=20 > -- Pavel I may be completely off base, but could a FUSE daemon use this to read memo= ry from the client and dump it to a file descriptor without copying the dat= a into the kernel?=20