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 E6E5BC54E41 for ; Mon, 4 Mar 2024 09:04:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 666EA6B009E; Mon, 4 Mar 2024 04:04:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 617F66B00A0; Mon, 4 Mar 2024 04:04:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E1076B00A1; Mon, 4 Mar 2024 04:04:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3669F6B009E for ; Mon, 4 Mar 2024 04:04:34 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E1F601C0083 for ; Mon, 4 Mar 2024 09:04:33 +0000 (UTC) X-FDA: 81858770826.27.47046F3 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf30.hostedemail.com (Postfix) with ESMTP id DAE438000A for ; Mon, 4 Mar 2024 09:04:30 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709543072; a=rsa-sha256; cv=none; b=6yFLdo12Ju4i4NmNFACKroP8vL6WkdSm9Y7XWR7F78Q7w75vQIHulQht5Tmz+hLILNCF9L Rf9ckOoA8+8w5OtTeloQ/TxAPWSaobzXYoMwXzRPr9a18HNCxpC756DC9bHNgwZrqM7qnj L7n2TjG2urcyjAKrCI6yCiu3vPJMWfY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709543072; 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; bh=31ORx180AmKi5DlPwHbZhspCIk9/U6vBDjoZZuGLy9w=; b=oipyNv4LLeDC5oLLe6vQEPcNRTLFmYcV4v3DJUZMAL8zDKhY188dSxZiswZuPIA1lQn/O6 c2tv2QP8nTGsX9MZU9QrfZNLHcyCAIBh6z7zPAecyaqlmDAozLD7MLXeo+A86EraGfTVY8 d+tzbZFdlyUOwNVQN81JEHuj+4qsNXo= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4TpCRN5t7MzNp35; Mon, 4 Mar 2024 17:03:44 +0800 (CST) Received: from dggpemd200001.china.huawei.com (unknown [7.185.36.224]) by mail.maildlp.com (Postfix) with ESMTPS id 4CAE2180073; Mon, 4 Mar 2024 17:04:26 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) by dggpemd200001.china.huawei.com (7.185.36.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 17:04:25 +0800 Message-ID: Date: Mon, 4 Mar 2024 17:04:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird CC: , , , , , , , Subject: Re: [Question] CoW on VM_PFNMAP vma during write fault Content-Language: en-US To: , , , , , , , , , , References: <20240227122814.3781907-1-mawupeng1@huawei.com> <234a5423-8d6d-444a-a27c-c772a71c9871@huawei.com> <6e948123-df3a-4450-8fd3-76b9131a35a0@redhat.com> From: mawupeng In-Reply-To: <6e948123-df3a-4450-8fd3-76b9131a35a0@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemd200001.china.huawei.com (7.185.36.224) X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DAE438000A X-Stat-Signature: zzr8fo6yef8nh1hhgbfmqjg6qsbg1uzz X-Rspam-User: X-HE-Tag: 1709543070-243439 X-HE-Meta: U2FsdGVkX1/6tREOxUHB764/olzsxoDZZ82zhEh7bZFet2QifQW2sVF+h12IxytUFOnL/+Q95C17Snxd033pxtSPf5NmX1eKwrCHcLHGmgs2HgsS9vZLHN9V4olfV9ypJd+zSvP6wdan07/77uiCp7kQzFUD7q9/TcD19bi+E6wd1darGAQ5y/uZMHo2NHTS73MTFaZB/bS4fb7luoVt4rtpn7nN/a+ayrIl/PouazEWutPQkLSLkZMAj5/XaO3V83BAjzOBeXxGUNqWFvYjIMmTofmn2kstH/h3Wkppg4QaMdOrd1dgLFYg46SKye2XDRqylWR2ls8jOgTp2rtg9gB5486ZN6xYUhBeWWJ4Sccry2wG6igRQWJjRLD9z2+rkPMOlP3C6yAVen+PDc03hs/7pDU7mHosFntKsSb9M7BNJgyofJp1xTB4W6QKs03ZW2s38+Ik9IKyCFitI7GXMlkYwkhEaca2PeJQkRVyEzuFjTQ4PhJQOSrrVsMOc1Xl3HiFe9HtwRRCke8GXu/GQiXzZNw+f3tUrS8UH7IOY6TDStdeXgYF36bZEAAO9/fCY16NAki2mcUxVQWj2EcwZeVsX1bp/6u/XTdt9VavxdT5gvhzoWetGUomkYnjSRRl2B/lYdCke4hNCLjc1hDEdbKRXxxjErWiFlSIVd2QScBOLArK9jQ6oFaHITZ7mtZDrrr4Cj4KY7tLqtLN5PFByItNlqfSvdmPMd4cPjHaDoLl2PlROlVSV6n0uiq/Soid2jBiKOous9pdVmiTwVasRj0I8yDZv48fdQj+vhOv36oHiY5wJaD9qViUDVrK4h++EJ6dzOd3E7Qytoy/iXRLvDryhd3GI6dCKgtN7RoFgSikKn9zj6Q6yoMC1mPbE+x95UcE9CHTS2Pd1b6GibPEVa8BywtpABleytvhxWMn6F47GN4KVKDmaiEYJxSdR9vxuSJD27Bx4xr52LVQNGb zH4WJX4U b/O2rybGrjmA3bGDjyydxSgDIbGgwP0KqD1f3WMuMKi5MPslZ72YmRG3TGfl6hsvpWpJjlMue5tORU9DGx92DXRirNRS+YsMOpKWtwtbzngvYymGa4f3ywIM9j1mn5zS5CCK89dT4V4q/VYDpzJw8bKocDuFM0FpH+ZOL/IK2nrI1rKEMjiu0ghwtGSeBw/NzAohAPehaxNRSvx+3QgHvLpTR8IhsgG+FgNskCCHNTxyiba0R5wDlZs/MQA== 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 2024/3/4 16:57, David Hildenbrand wrote: > On 04.03.24 09:47, mawupeng wrote: >> Hi Maintainers, kindly ping... >> >> On 2024/2/28 9:55, 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). >> >> We found this problem in 5.10, Commit 9f78bf330a66 ("xsk: support use vaddr as ring") Fix this >> problem during supporting vaddr by remap VM_PFNMAP by VM_MIXEDMAP. But other modules which >> use remap_pfn_range may still have this problem. > > I wrote a simple reproducer using MAP_PRIVATE of iouring queues on Friday. > >> >> It do seems wired for private mappings, What is the good reason? > > I'm sure there are some use cases that require MAP_PRIVATE of such areas, and usually there is nothing wrong with that. So MAP_PRIVATE for VM_PFNMAP area with write access is ok? What is the user case for this situation? > > It's just that the PAT implementation incompatible. PAT do have its problem. > > I can submit a cleaned-up version of my patches. Thanks >