Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1244392pxj; Fri, 4 Jun 2021 09:25:15 -0700 (PDT) X-Received: by 2002:aa7:c0d3:: with SMTP id j19mr5613876edp.196.1622823915143; Fri, 04 Jun 2021 09:25:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLqUoJqUPSAsBE8B5Ie7Sc6An+FC5G+MmGTwOFLpNusxUY+e4rmZhYDp6dl5xhN1kA4DYG X-Received: by 2002:aa7:c0d3:: with SMTP id j19mr5613732edp.196.1622823914229; Fri, 04 Jun 2021 09:25:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622823914; cv=none; d=google.com; s=arc-20160816; b=jiJZiGy/Q3CR28VmM93Luk/XPiGgGckG1kUP4Pd6ek1pYsyv7OgNhyeQJzgornO/uT rW8rQkZ0jk8EsALLQh1hCxMUOtGzRf9obj+q8YIuwz9bmRX7YQFDWT4/Zmazrux6ruqm ep21prQrwsEcwFwbMP1X5LI9N2Y23amaPF4B3ij5h2Xopu4FEnS3qV+vmGo+yVRk9zg2 MlyRHFO0cwzBMKZcxDrDq070VTtcYtqgIcUC+fTpfP5Ki0fEYbZA8nDAacEt0aHSqSuG /f4sLOEg5wWVj2Ion4O9zhSEgfKZgc+/uSf1k0kfgIhFLTa3pXBEqN3M6YE1q3ondSET 0POA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+iOBxDQbD2ed0NxOel6oW+MbPuaic+oU14y+34RdBqk=; b=0tGnucP7ieiR1JEt1auXBYuBeK5yp6xAnzzAcUnY9JW4Ffbas8DjCBZzcJ3pOAByXk 3T6Xv57rTq34q1P373V5imzy+HoUmD77ijdEPOIpwDSkIxEpXOKbiIa8RKgO6b05xZTb Hs8ycHk4prizLv42S30q2bJIUPttSTE6mfy6SjkNHW2DUxvzVTC4qmxm8gfAxjXhDrRi XDS073sDkq9AfSoBmZqoumRSr7+O811uc/pirBaDKdfyoKCoOjcqSwvt437QbZBgcjMe NkZCBD5e7Gd+Su2FRZa0XHl2vhQJNFtdIZb6ssO0KtiuMf9d/dMH6lR5AMznygI2CTQq 18TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=S3iL0bso; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i3si5000779ejp.610.2021.06.04.09.24.50; Fri, 04 Jun 2021 09:25:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=S3iL0bso; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231488AbhFDQXy (ORCPT + 99 others); Fri, 4 Jun 2021 12:23:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:42014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231415AbhFDQXv (ORCPT ); Fri, 4 Jun 2021 12:23:51 -0400 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.