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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 13AD1C4338F for ; Thu, 12 Aug 2021 18:16:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 859756103A for ; Thu, 12 Aug 2021 18:16:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 859756103A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CCDEF8D0002; Thu, 12 Aug 2021 14:16:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7D738D0001; Thu, 12 Aug 2021 14:16:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B47948D0002; Thu, 12 Aug 2021 14:16:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 982298D0001 for ; Thu, 12 Aug 2021 14:16:12 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3D3CD181D7EB1 for ; Thu, 12 Aug 2021 18:16:12 +0000 (UTC) X-FDA: 78467232984.32.BBBB3DF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id CF32150496E7 for ; Thu, 12 Aug 2021 18:16:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628792171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S+E4q/M54NKHA7t+0+yZiG5e1rXRHCWENhzfTmuDkeE=; b=RawMQ3PTPceFKV/d0tmIa46zjSOmXvEQ8gf2/p8o38LOlggg1fl5cecYRqDPWbmuXchFND XQV5X7T/P82eZYhCOv9Gecas3ffr4/O1lzDzOPS44a9Gtzh4Fo1dVCur++kGOcrhi13qZI /fFdtvYDIecVkBSoxP4NbW5KvAc5APA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-564-0clPGp-sOp-JtYWaSFVzGw-1; Thu, 12 Aug 2021 14:16:09 -0400 X-MC-Unique: 0clPGp-sOp-JtYWaSFVzGw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3A8A21853029; Thu, 12 Aug 2021 18:16:03 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BB15D1017CE5; Thu, 12 Aug 2021 18:15:42 +0000 (UTC) From: Florian Weimer To: ebiederm@xmission.com (Eric W. Biederman) Cc: "Andy Lutomirski" , "David Hildenbrand" , "Linux Kernel Mailing List" , "Linus Torvalds" , "Andrew Morton" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "H. Peter Anvin" , "Al Viro" , "Alexey Dobriyan" , "Steven Rostedt" , "Peter Zijlstra (Intel)" , "Arnaldo Carvalho de Melo" , "Mark Rutland" , "Alexander Shishkin" , "Jiri Olsa" , "Namhyung Kim" , "Petr Mladek" , "Sergey Senozhatsky" , "Andy Shevchenko" , "Rasmus Villemoes" , "Kees Cook" , "Greg Ungerer" , "Geert Uytterhoeven" , "Mike Rapoport" , "Vlastimil Babka" , "Vincenzo Frascino" , "Chinwen Chang" , "Michel Lespinasse" , "Catalin Marinas" , "Matthew Wilcox (Oracle)" , "Huang Ying" , "Jann Horn" , "Feng Tang" , "Kevin Brodsky" , "Michael Ellerman" , "Shawn Anastasio" , "Steven Price" , "Nicholas Piggin" , "Christian Brauner" , "Jens Axboe" , "Gabriel Krisman Bertazi" , "Peter Xu" , "Suren Baghdasaryan" , "Shakeel Butt" , "Marco Elver" , "Daniel Jordan" , "Nicolas Viennot" , "Thomas Cedeno" , "Collin Fijalkovich" , "Michal Hocko" , "Miklos Szeredi" , "Chengguang Xu" , Christian =?utf-8?Q?K=C3=B6nig?= , linux-unionfs@vger.kernel.org, "Linux API" , "the arch/x86 maintainers" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> Date: Thu, 12 Aug 2021 20:15:40 +0200 In-Reply-To: <87lf56bllc.fsf@disp2133> (Eric W. Biederman's message of "Thu, 12 Aug 2021 12:48:31 -0500") Message-ID: <87lf56edgz.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CF32150496E7 X-Stat-Signature: gmf7xny1otmp6ogm3rk7bhyrp3mricj9 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RawMQ3PT; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf05.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=fweimer@redhat.com X-HE-Tag: 1628792171-124476 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: * Eric W. Biederman: > Given that MAP_PRIVATE for shared libraries is our strategy for handling > writes to shared libraries perhaps we just need to use MAP_POPULATE or a > new related flag (perhaps MAP_PRIVATE_NOW) that just makes certain that > everything mapped from the executable is guaranteed to be visible from > the time of the mmap, and any changes from the filesystem side after > that are guaranteed to cause a copy on write. I think this is called MAP_COPY: If we could get that functionality, we would certainly use it in the glibc dynamic loader. And it's not just dynamic loaders that would benefit. But I assume there are some rather thorny issues around semantics. If the changed areas of the file are in the page cache already, everything is okay. But if parts of the file are changed or discarded that are not, they would have to be read in first, which is rather awkward. That's why I suggested the signal for all future accesses. It seems more tractable and addresses the largest issue (the difficulty of figuring out why some processes crash occasionally). Thanks, Florian