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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B55DC43381 for ; Fri, 22 Mar 2019 23:20:27 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C96C2218D4 for ; Fri, 22 Mar 2019 23:20:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C96C2218D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1h7TRg-0003gC-25; Fri, 22 Mar 2019 19:19:28 -0400 Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h7TRe-0003g1-OT for kernelnewbies@kernelnewbies.org; Fri, 22 Mar 2019 19:19:26 -0400 Received: from mr5.cc.vt.edu (mail.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x2MNJKO7015767 for ; Fri, 22 Mar 2019 19:19:20 -0400 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mr5.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x2MNJFT2013782 for ; Fri, 22 Mar 2019 19:19:20 -0400 Received: by mail-qk1-f199.google.com with SMTP id f196so3384666qke.4 for ; Fri, 22 Mar 2019 16:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=aV17npH6gRjB6oHoKuc8M/lLrKApF4+jFwHBONLp/3I=; b=lXy1EEqSWQJuaLwk7V5aeQGaA2nxZHpMcT4HyKDQElT5q/QhN4t2x4iDLKogL3wxZS 7yXvSR8OXINcaOyrIgWOqOTt1lHZ8VFiLuKtc7tUmbu2m7yNYDSIgm66ASMRXG1x7hS+ wE7HIb+8oLToU+SrYgTP80ZRLOxqGuNFR/P3G0TljWrMWIrOgg8QRE3eJw2UX2kfol9l Y4bQ/qucLGoHwYLdlFYiqCgvyKoFMipn8jHHjrfAWg1LlSvutmFNgpCq9KzIy+ht0A1B 4z9PV5vzSHjPJkczk5MNXH/bFYF/6YrRGhX/ZI4YZTHNr3D34jD7e08MhSmNkrdVFFEJ mqtw== X-Gm-Message-State: APjAAAVzj87HybLktSK/6dTUak9ULd0Aw58akZYt0HQAEKVRnNDL7rAJ wEoiyOx7+3a63vKi83TFPfGJRbwYg7RE3umx5irN60FNC+wOExlq+nh1YXpFDeiVbAiE6qmA0yH S1W3Psg4qsLe9bWepj4L4NcGxRYj/5Xa7CeBwkww= X-Received: by 2002:a0c:b78e:: with SMTP id l14mr10539570qve.129.1553296755135; Fri, 22 Mar 2019 16:19:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzUjvV3i7F9KVfAYpYpiEhD5f6Twag4Uv09Lg6+JxQVTiup27RNOOrzxD+BPjVAovNjrodzw== X-Received: by 2002:a0c:b78e:: with SMTP id l14mr10539562qve.129.1553296754904; Fri, 22 Mar 2019 16:19:14 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:4341::7ca]) by smtp.gmail.com with ESMTPSA id 204sm1735316qki.58.2019.03.22.16.19.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Mar 2019 16:19:13 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Lev Olshvang Subject: Re: What will happen if 2 processes map same physical page In-reply-to: <2235291553246149@sas1-0a6c2e2b59d7.qloud-c.yandex.net> References: <6967041553089359@myt2-66bcb87429e6.qloud-c.yandex.net> <16760.1553101675@turing-police> <3935481553162177@sas2-ce04c18c415c.qloud-c.yandex.net> <20190321104528.33471e38@narunkot> <2235291553246149@sas1-0a6c2e2b59d7.qloud-c.yandex.net> Mime-Version: 1.0 Date: Fri, 22 Mar 2019 19:19:12 -0400 Message-ID: <25010.1553296752@turing-police> Cc: linux-il , Okash Khawaja , kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Fri, 22 Mar 2019 12:15:49 +0300, Lev Olshvang said: > But the question might be rephrased : IMHO Kernel should mandate same PTE > flags no matter how many virtual mapping were made to the same physical page. And exactly *why* should it be "mandated"? Certainly, for many classes of objects, such as shared libraries, it's a desirable feature (maybe - but see below). However, there's plenty of *other* use cases where the programmer may want to have one control process having read/write access to a memory segment, while a bunch of worker processes are merely reading the data. For instance, if you're serving out complicated computations to sub-processes that involve a lot of parameters and input data, the control process already *has* all this data (potentially megabytes of it) in memory. Using shared memory to transfer it to the worker process is a lot more efficient than having to stuff it all through a socket. And even for shared libraries, you may want one process to be able to write to the space while others are reading it, for live patching and similar functions. (Yes, there's a security trade-off there - and yes, there are sites that will accept the risk, and no, that sort of trade-off belongs in userspace, not in the kernel). The kernel does mechanism, not policy. So it's totally reasonable to have a defined way for userspace to say "this page can only be shared with these permissions" - that's mechanism. Having the kernel force a specific value without a good architectural reason is policy. (Sometimes the kernel does force things to work a specific way if it's required to guarantee system stability. That's why you can't use the write() system call on a directory even if you have write permissions - you can only use stuff like link() and open(). Permissions on shared memory pages don't involve that sort of kernel self-defense issue. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies