From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A603CC433EF for ; Tue, 25 Jan 2022 11:41:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94BBA6B007B; Tue, 25 Jan 2022 06:41:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D37E6B007D; Tue, 25 Jan 2022 06:41:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 774A86B0080; Tue, 25 Jan 2022 06:41:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id 641ED6B007B for ; Tue, 25 Jan 2022 06:41:42 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 153BE184188BF for ; Tue, 25 Jan 2022 11:41:42 +0000 (UTC) X-FDA: 79068619644.29.E9BD19F Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf30.hostedemail.com (Postfix) with ESMTP id 9DED580009 for ; Tue, 25 Jan 2022 11:41:41 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id c15so10593082ljf.11 for ; Tue, 25 Jan 2022 03:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RJcbe5w2XSHxzMRgZ2Y2pQFdn57O19rCLWQF0CALTH0=; b=kGRdpXqcvVI0JCXEBkcXAlaCnbgjqFw+y8JqKUUVByiZmzUD++/K6HXdokfYHT1e/s sxFaso5HE7DDGYcZVeGpk8Msnbaks/2Hjj29YYAaKOvfBHvyu9JdDdLsYD3EMoWOhT86 bLX6DSF5pwDpP8/Ng2zMIQV/Vb/s/ltR+vKyYOtgvrsZ6+gU+V4SdJ4slvOgWET6E1+4 DrD81m/LvFIUeiDn7bli+yM8Xff0h728ycJDGY6NdzW0+koC7t9lXNLHLwulYhjYI/lj zWnCnFyvYelEtdcajUL7Io5igV21i5JXiULGMX+wOkcwQcHeXAPJL3AP9en639+5B0fu NXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RJcbe5w2XSHxzMRgZ2Y2pQFdn57O19rCLWQF0CALTH0=; b=OCaj5Vsbv4Dgpi1AlgYt4oMimRxS5jHO2zptMGt1NTfIK2XthVma4Ev4u/gSgDOyS6 9TyIqDzYz3Q2hP+rIb1+AzuAtJG9/nNcPS8/vvAEq4WVwy0NSsjPy7G66sVcjKjx8wjJ SrN+gS5BwyuxrJhdJgWvESgZo4HlLLQUltK5e9mUqkNSy6skM5CixKF5vMz0/eYr8QMY 17DRu+djjgsOCYUB4HwQcn4GYJ+ixx3IxVDNU7aIDzzVuRrFrUwZ7sYajw1EeI+1uTl2 SKZhRIoFI+Gh2ZorrFykT9DqpgOTBxb1sMfZ4Cl4uuZZ9UiVTQtQT1w/bjlXok7ZiGXk rjKQ== X-Gm-Message-State: AOAM531P8kWA68sqsuSN+i2QaWehefpAZ59FlQuxUOu0eExdbXocUSdx qHnrDs05fI6EsOw1BHaqj2JaWg== X-Google-Smtp-Source: ABdhPJwgke+5vjX1u3fzSchnQ1ruulUVi80pUf5YCUch45nk/1nrAtCaqXa+Dvm5HWQKYysafwWsUQ== X-Received: by 2002:a2e:3212:: with SMTP id y18mr3250783ljy.270.1643110899999; Tue, 25 Jan 2022 03:41:39 -0800 (PST) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id p19sm1463920lfh.18.2022.01.25.03.41.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 03:41:39 -0800 (PST) Received: by box.localdomain (Postfix, from userid 1000) id 42B23103C0E; Tue, 25 Jan 2022 14:42:12 +0300 (+03) Date: Tue, 25 Jan 2022 14:42:12 +0300 From: "Kirill A. Shutemov" To: Khalid Aziz Cc: akpm@linux-foundation.org, willy@infradead.org, longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, rppt@kernel.org, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes Message-ID: <20220125114212.ks2qtncaahi6foan@box.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=kGRdpXqc; spf=none (imf30.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.175) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspam-User: nil X-Rspamd-Queue-Id: 9DED580009 X-Stat-Signature: 8gq1h1sirio35zgdd45fyad66h58onx8 X-Rspamd-Server: rspam12 X-HE-Tag: 1643110901-54620 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jan 18, 2022 at 02:19:12PM -0700, Khalid Aziz wrote: > Example Code > ============ > > Snippet of the code that a donor process would run looks like below: > > ----------------- > addr = mmap((void *)TB(2), GB(512), PROT_READ | PROT_WRITE, > MAP_SHARED | MAP_ANONYMOUS, 0, 0); > if (addr == MAP_FAILED) > perror("ERROR: mmap failed"); > > err = syscall(MSHARE_SYSCALL, "testregion", (void *)TB(2), > GB(512), O_CREAT|O_RDWR|O_EXCL, 600); > if (err < 0) { > perror("mshare() syscall failed"); > exit(1); > } > > strncpy(addr, "Some random shared text", > sizeof("Some random shared text")); > ----------------- > > Snippet of code that a consumer process would execute looks like: > > ----------------- > fd = open("testregion", O_RDONLY); > if (fd < 0) { > perror("open failed"); > exit(1); > } > > if ((count = read(fd, &mshare_info, sizeof(mshare_info)) > 0)) > printf("INFO: %ld bytes shared at addr %lx \n", > mshare_info[1], mshare_info[0]); > else > perror("read failed"); > > close(fd); > > addr = (char *)mshare_info[0]; > err = syscall(MSHARE_SYSCALL, "testregion", (void *)mshare_info[0], > mshare_info[1], O_RDWR, 600); > if (err < 0) { > perror("mshare() syscall failed"); > exit(1); > } > > printf("Guest mmap at %px:\n", addr); > printf("%s\n", addr); > printf("\nDone\n"); > > err = syscall(MSHARE_UNLINK_SYSCALL, "testregion"); > if (err < 0) { > perror("mshare_unlink() failed"); > exit(1); > } > ----------------- I wounder if we can get away with zero-API here: we can transparently create/use shared page tables for any inode on mmap(MAP_SHARED) as long as size and alignment is sutiable. Page tables will be linked to the inode and will be freed when the last of such mapping will go away. I don't see a need in new syscalls of flags to existing one. -- Kirill A. Shutemov