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 5BA29C54798 for ; Wed, 28 Feb 2024 02:11:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D68576B024D; Tue, 27 Feb 2024 21:11:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D18196B0254; Tue, 27 Feb 2024 21:11:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB92A6B0255; Tue, 27 Feb 2024 21:11:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A9B496B024D for ; Tue, 27 Feb 2024 21:11:12 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 78C4CA0659 for ; Wed, 28 Feb 2024 02:11:12 +0000 (UTC) X-FDA: 81839585184.26.0CA9DE9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id E82BDA0009 for ; Wed, 28 Feb 2024 02:11:08 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=h7ZyXrxq; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709086271; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SXJbCm+VxWCOy8utsVzLxhtFAwCalPFzLbzPxM8Jrn4=; b=iNJbGhEoZ8XWBill0spM+2jxK+caQPJgOOZZrTWfTgR6dO5uVJIROUWG1PUk0Kx7X3ZcZg L6vlVzccANXWndjTKHSxmeZtDDffnfFK4r3iraJIwpZXnyWC9CdLvsyZRrel5mQRiFN6O/ u3I47CX8eod5GJX0+31vqx8kacTobhM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=h7ZyXrxq; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709086271; a=rsa-sha256; cv=none; b=Q8JCZcnBBVMLnzH6ub7ze0jfZeESr/E/haemgd2nk14haMrwZJDykgS4PWA+6T003dUSSr 1TF/sNcMsd9ov7pw6hroHlYPzj33b+B+K/e7vEP8q8NBIpnyzLdVedSK2Ls/jkeD94GDNw qv+/SpQaNAO2qo4AaWqJOAaBLzytJt8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=SXJbCm+VxWCOy8utsVzLxhtFAwCalPFzLbzPxM8Jrn4=; b=h7ZyXrxqUYwMBGEli9ZNIQoaIi HRt8poIxMUBJPl3LSMr0+xLkjXLzKLiAtxCgeeDpKMXvIkn3ICLO1dRwXC28aFym3nYX/sPq5DwML OinIwMFxs8SDtYUlL/kq6jTQpj4iIPJry3VeSrrCa1y9pVeu0dELJMdZDrrEf7oaz+rjcZMfQRAfd VtlR0UKWwUwInjJwgkMo1v8LWKw9EQ002dhRTezVcgg7AVGvVw/vX6aTRWxsqxoAfEZXfslpAS+/a fDFLSfTKIl/xZf7jL5b2ZwOxDJjhuzoKptcqvcTWop/oFAXFMDjtOwkyA3nQXJ9Bpxvn3H/S2ErkH IVj8C0jg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rf9PB-00000003zeD-0Sof; Wed, 28 Feb 2024 02:10:45 +0000 Date: Wed, 28 Feb 2024 02:10:45 +0000 From: Matthew Wilcox To: mawupeng Cc: david@redhat.com, akpm@linux-foundation.org, khlebnikov@openvz.org, jaredeh@gmail.com, linmiaohe@huawei.com, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, tglx@linutronix.de, peterz@infradead.org, linux-kernel@vger.kernel.org, x86@kernel.org, mingo@redhat.com, rdunlap@infradead.org, bhelgaas@google.com, linux-mm@kvack.org Subject: Re: [Question] CoW on VM_PFNMAP vma during write fault Message-ID: References: <20240227122814.3781907-1-mawupeng1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: E82BDA0009 X-Rspam-User: X-Stat-Signature: jjkhqmpdi781ku8u9rniai5kky6czhjg X-Rspamd-Server: rspam01 X-HE-Tag: 1709086268-376515 X-HE-Meta: U2FsdGVkX1+b3ccj02vFdXz9C88HnodnTVGzupnCc4aLqzfdBJQVLnMte1fE46CUbBzxwUOQdXLyCr4B+yMLOcG0Pzyx6FyCuMZ5QNuGnTMXx2GkSAgTtceHm7CkOGa0FXofeRpHnN7T+Nr7NwwBhPwvWVErQkwShubw/VrwU5YhisJWBHlLlLxNpxjw8qO/kbWUJfMN2Ap4cDtFuEQnLkLc/F2Sg8f1qfu7W1QaC2zdfUg/5XDeecvxpBCqgDzT9k8PsXnKqAUEM+JdwgX0u7/6+QJ1RRVUQqAoY3R/SG1J6rnzAG2qxV/L8H9sRC4x01tPZ3P7non2wOzyHqF7mNOsHqwKp+66ISQ8WuLPuuaV24+22TEO84KOrjfmr/HsRKx7nIPnhCMel+w66zBHMjw+TbW8FXQNMgr6KZ2Awgcy5R001sp5fqeuCOBwPpc9wrwgsG9ZfrpeLKmyGyZTvqwdSaXBQrzQz8/bJ6slY5SSSyXR9AtwG7fRzgULdzCW3sKYbIqVRcMmQVGJhNJA9XI6s7BXHMoHu8vc2JhECmXnXXrWHY67/cgzC7MfKep16ATTMJL2tWSM8zCfZ9PU3O/Axvk7ejYYNkvazlcZo4/JLEHi/mM/aEnjzMFegT6iZZxY8TS+KSYNLs2SxtnIEB5hdmYr+3DsNTuEEKqYdD4YumF1S1ld07yWzIhWadhxiBv2J1u0NqWV7uuU7OgzMt35AdZ2gZcf/vfItSF7EB19MVvkzytamoEl7kSsNqV2KagTNvRgtcrb/dhIEswI8M+T5LIXt+2K9cNkdVu2aoRchhPjdVquJZjFolKl9iL/xI6spP9cX9Ifaogh+g5eEuQ8Py+R+SAYoZDlGWLdGX6EIWZb6D/GNahvYd9o2/6F 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: List-Subscribe: List-Unsubscribe: On Wed, Feb 28, 2024 at 09:55:24AM +0800, mawupeng wrote: > On 2024/2/27 21:15, David Hildenbrand wrote: > > On 27.02.24 14:00, David Hildenbrand wrote: > >> On 27.02.24 13:28, Wupeng Ma wrote: > >>> We find that a warn will be produced during our test, the detail log is > >>> shown in the end. > >>> > >>> The core problem of this warn is that the first pfn of this pfnmap vma is > >>> cleared during memory-failure. Digging into the source we find that this > >>> problem can be triggered as following: > >>> > >>> // mmap with MAP_PRIVATE and specific fd which hook mmap > >>> mmap(MAP_PRIVATE, fd) > >>>     __mmap_region > >>>       remap_pfn_range > >>>       // set vma with pfnmap and the prot of pte is read only > >>>      > >> > >> Okay, so we get a MAP_PRIVATE VM_PFNMAP I assume. > >> > >> What fd is that exactly? Often, we disallow private mappings in the > >> mmap() callback (for a good reason). > > just a device fd with device-specify mmap which use remap_pfn_range to assign memory. But what meaning do you want MAP_PRIVATE of this fd to have? Does it make sense to permit this, or should you rather just return -EINVAL if somebody tries to mmap() with MAP_PRIVATE set?