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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 BCD7DC47427 for ; Fri, 4 Jun 2021 16:32:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6371A61153 for ; Fri, 4 Jun 2021 16:32:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6371A61153 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E77526B0073; Fri, 4 Jun 2021 12:32:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E26216B0082; Fri, 4 Jun 2021 12:32:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEDDF6B0085; Fri, 4 Jun 2021 12:32:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id A08E86B0073 for ; Fri, 4 Jun 2021 12:32:46 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3A556BEE1 for ; Fri, 4 Jun 2021 16:32:46 +0000 (UTC) X-FDA: 78216585132.08.3610D89 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf26.hostedemail.com (Postfix) with ESMTP id 7D5F54202A25 for ; Fri, 4 Jun 2021 16:31:36 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id B7ECB61405; Fri, 4 Jun 2021 16:22:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622823725; bh=xn5ZeMcRayu4wtKmfS44ZO8eZDtZJ7X1BNPhLvdFscA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S3iL0bsoQhg6GddljyqUxX4xeNG6w7VNhf9ddnuBhnfpmo9PKNMJ5qPMhkH4dG1Rp AFrhyQx8J2n+tSOSG9C69EH6ekvzdD6phQ0Xl2OEfUa+nHt98p5+OQpdW4FGjEe0Fp 1wYvXGfb1T2HELCDnsBeuUpueDrl2I5eXO1C4QrRIC/5HBMUbmo6u8JCWePMM6I0pL bhFTBUlPNIu3XHRJG+QGe7bBoz+q64gteJdAyceQiI+yliq+mh3bRNvMTzlf0ULk+3 hNo5+vc0tOJd1XrbbrtBtoHWUo8bs5cfdCQ9kO437M66JkBLQmakWG0+PR6SvMZkaO BqL1APQz1+4xw== Date: Fri, 4 Jun 2021 09:22:03 -0700 From: Ming Lin To: "Kirill A. Shutemov" Cc: Linus Torvalds , Hugh Dickins , Simon Ser , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm: adds NOSIGBUS extension to mmap() Message-ID: <20210604162203.GA9562@ubuntu-server> References: <1622792602-40459-1-git-send-email-mlin@kernel.org> <1622792602-40459-3-git-send-email-mlin@kernel.org> <20210604152407.ouchyfuxjvchfroe@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604152407.ouchyfuxjvchfroe@box> X-Stat-Signature: oii7j57hz6s99mz5ephafbssuqj4gcsx X-Rspamd-Queue-Id: 7D5F54202A25 X-Rspamd-Server: rspam02 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=S3iL0bso; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of mlin@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=mlin@kernel.org X-HE-Tag: 1622824296-174179 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 Fri, Jun 04, 2021 at 06:24:07PM +0300, Kirill A. Shutemov wrote: > On Fri, Jun 04, 2021 at 12:43:22AM -0700, Ming Lin wrote: > > Adds new flag MAP_NOSIGBUS of mmap() to specify the behavior of > > "don't SIGBUS on fault". Right now, this flag is only allowed > > for private mapping. > > That's not what your use case asks for. Simon explained the use case here: https://bit.ly/3wR85Lc FYI, I copied here too. ------begin------------------------------------------------------------------- Regarding the requirements for Wayland: - The baseline requirement is being able to avoid SIGBUS for read-only mappings of shm files. - Wayland clients can expand their shm files. However the compositor doesn't need to immediately access the new expanded region. The client will tell the compositor what the new shm file size is, and the compositor will re-map it. - Ideally, MAP_NOSIGBUS would work on PROT_WRITE + MAP_SHARED mappings (of course, the no-SIGBUS behavior would be restricted to that mapping). The use-case is writing back to client buffers e.g. for screen capture. From the earlier discussions it seems like this would be complicated to implement. This means we'll need to come up with a new libwayland API to allow compositors to opt-in to the read-only mappings. This is sub-optimal but seems doable. - Ideally, MAP_SIGBUS wouldn't be restricted to shm. There are use-cases for using it on ordinary files too, e.g. for sharing ICC profiles. But from the earlier replies it seems very unlikely that this will become possible, and making it work only on shm files would already be fantastic. ------end------------------------------------------------------------------- > > SIGBUS can be generated for a number of reasons, not only on fault beyond > end-of-file. vmf_error() would convert any errno, except ENOMEM to > VM_FAULT_SIGBUS. > > Do you want to ignore -EIO or -ENOSPC? I don't think so. > > > For MAP_NOSIGBUS mapping, map in the zero page on read fault > > or fill a freshly allocated page with zeroes on write fault. > > I don't like the resulting semantics: if you had a read fault beyond EOF > and got zero page, you will still see zero page even if the file grows. > Yes, it's allowed by POSIX for MAP_PRIVATE to get out-of-sync with the > file, but it's not what users used to. Actually old version did support file grows. https://github.com/minggr/linux/commit/77f3722b94ff33cafe0a72c1bf1b8fa374adb29f We can support this if there is real use case. > > It might be enough for the use case, but I would rather avoid one-user > features.