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 BE699C27C4F for ; Thu, 13 Jun 2024 19:39:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53AE06B0088; Thu, 13 Jun 2024 15:39:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C0346B00AD; Thu, 13 Jun 2024 15:39:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EC936B00D4; Thu, 13 Jun 2024 15:39:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 070076B0088 for ; Thu, 13 Jun 2024 15:39:47 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A4D5FC0334 for ; Thu, 13 Jun 2024 19:39:46 +0000 (UTC) X-FDA: 82226880372.02.279501B Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf17.hostedemail.com (Postfix) with ESMTP id 77A704000A for ; Thu, 13 Jun 2024 19:39:44 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="gHN1FKo/"; spf=none (imf17.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718307584; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zszsi0/aB2A5gS3nj8dtgFtDV/ZCUUoBmBVvRLy5hi4=; b=g1X9tW/lrvSiV/SkZE1cXbCasTYvk7j8yDhlEpNA0u0RxoGX+ACn4fIehqQAE+kUNyY2sg OhTg6xcsi35CcGaTohzmtDvQ063/kjhRj7BkiXKj+m5tdcqj/qFXNxk61EToX5gtioX4Yd hQaq0OgI3CpeJVg6DhFTgeMR9RKz13I= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="gHN1FKo/"; spf=none (imf17.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718307584; a=rsa-sha256; cv=none; b=MMpoT7MBXq5C9yoT9yf8vUvIEk9lMGSO1IB2cm8jzAumok9djeSPJNRvs3ZtmonEatSiNN PHO+A0FQU6wYvspeyoQv58+iLQsFKK68BHw6QvjRE9iWLIQlKMtSM8K4bsPEswH/V531bl xpgHnGJ/yTrxCyWR7A2l170VEmRVmzg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zszsi0/aB2A5gS3nj8dtgFtDV/ZCUUoBmBVvRLy5hi4=; b=gHN1FKo/gLkrKUqlWBHqnu5ICW tW5aD/4ifvUlVBvAHVylwxXEpvpguH59nQIX5H6WkFRNAcj6aR6TGR85v0cTHzvT2KQLdtR+GK0qP fRmgw6YLsUmThl/Kj9O8bJ9c9WkikVf2myaGQ0AC+cbud5Kas7Rt2Zk23eOZRFygikkg32gTOx+QJ xDbOzuShVX9VaDl6R7wJcm7vk5BygjkwJ7F5F48D0/KBW0pW3PE4W5wJ0FDsLUXA3MMZrLGY+7OVE bOYGVzvlISO1vrDkKgNhrnErMIfjOL9QiGpY9qESwtpkw4aFLKPBBohz8/DBdxlQdUoGyPo7c4OqL 8iHdTHtg==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHqIG-00000000IvW-0Jyf; Thu, 13 Jun 2024 19:39:32 +0000 Date: Thu, 13 Jun 2024 12:39:32 -0700 From: Luis Chamberlain To: Matthew Wilcox Cc: David Hildenbrand , Hugh Dickins , yang@os.amperecomputing.com, linmiaohe@huawei.com, muchun.song@linux.dev, osalvador@suse.de, "Pankaj Raghav (Samsung)" , david@fromorbit.com, djwong@kernel.org, chandan.babu@oracle.com, brauner@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, hare@suse.de, linux-kernel@vger.kernel.org, Zi Yan , linux-xfs@vger.kernel.org, p.raghav@samsung.com, linux-fsdevel@vger.kernel.org, hch@lst.de, gost.dev@samsung.com, cl@os.amperecomputing.com, john.g.garry@oracle.com Subject: Re: [PATCH v7 06/11] filemap: cap PTE range to be created to allowed zero fill in folio_map_range() Message-ID: References: <20240607145902.1137853-7-kernel@pankajraghav.com> <818f69fa-9dc7-4ca0-b3ab-a667cd1fb16d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: iqi3zzuf6uzfinyp8icyodnftmk5bddd X-Rspam-User: X-Rspamd-Queue-Id: 77A704000A X-Rspamd-Server: rspam02 X-HE-Tag: 1718307584-209540 X-HE-Meta: U2FsdGVkX1+eHJuZX6rG5k2BnSdzffAYWpyjxNx4+ZLrSnXlJtyp41FDLvECuYIgTZBhh4VJfh5fKgoA3nWwsj+luTreeyRWpf4B3IbfKXCKsYz15SVXmQkELQuKPGAxahnJy3vaE58yeRbM7gFGUuOyaR8b58M10bmDzxr+idrhDVp1bRNOMWP+hghTGKhSweHyMTFCdpAz4G08GrPWxz5O5hwDQpcaBn5+B2ogLj04y6Tf2T7kUX13PeJ24/1nNggCbBZCz0Asj4LJK6aElsAd7lQ9ZKAl7V4E6eCR869KJpr3ejFEIYzvXn8Hh6EW+ClFJxDWUHIfmVDTgHfeL6Lb/F65q6v1oDSQgDJXEjvhQ082Z2xPdiULvIJy0O/nvqBfRhlN/4zBVg91NTtWdLomGkDgt91ojI/U9s85K4swDM9Rx/v0twgoMXIif2ZJmIUpa3t5E673l7TKiljCPNHUC1WotHxN45EoTvIaGnmbS9NvNFJkhlVeMEJCyoEMX8KDF80wBLWxggI7UIkJjTtXWBFYe+EOrrhV4hn2KtwrgwmMzefoa687CdEZqW//08rMknGXXrt5GgtfNdThetoLqvhb0ZQFrQDTrugSMoOmpFXKz5ilIXu03a35ifAkzWeZLr7gAiR+r+Nog4lAwliLVWnk1LTZgfz0BGk9rgJ8cbRdonq3xTCYNgQ+Ld6XV+ID1ViwsOS5l1D792l9A1TbxDLfLDjA9ZjTnNdpvNW3aexjD8HhGLIHTtH/gZdB7F3R3U6qVwon0lvx/hrgwoS5a6iE1RsAOOdGtZBGLaVmDnsT+YQSPhkDp+rdWTJawYIpVZ67Dr3iPKuqv1qawkhrlpoxmpseHEgTMxJzBIsPoQuy7hJXleUIhzQF19Cxk9ZgbV4R8EieRKDwBspx20NR4U06ogySASXwBAWD3kKl0KRRNgT6cyF24lNSYKTNr6KuIJvbnFHXXSBYFlx Yz3asIdm n5ov1wjODg/NXiQ3FLV0i1vzHD6CZhaNAVRzQNFVMwrXMdsvzRNFv9PKWv+RoXCR0FTDPJcx6hmu1Pjs9bZ0QZI2tZxuGApDgK4ZZvdVxvrs4voJ2Zw+sf3EtAvCS3XhNF1fkMAPjE4H71QQHndy88tBVN5/1jH40oxtXOpfO4H3W5/ICOgNwiSplv5+z3vyc5WQWojnOM8H3ooebjwN1/SCh9PXvidWyCj3WKGov9aDhNGJGjZI7+hBgKGjdC+PTfQrlMqLMiPt0yZ79Fhmswp8Q+DMPRsxjo7ayC93WBfLCNHhADWkvcWkssQqmtgoS3gM2EQ4g5wGAjn4UwbtS+JvqkUFUpvzEcDywf+sTweJ9q5RTd7yjFpqI5fmqyutZ3TE4JT/VWeNgGxc0Yy4afvk6QcCrFd9AcnKCyqxB4EvbIzo= 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 Thu, Jun 13, 2024 at 04:40:28PM +0100, Matthew Wilcox wrote: > On Thu, Jun 13, 2024 at 08:38:15AM -0700, Luis Chamberlain wrote: > > On Thu, Jun 13, 2024 at 04:32:27PM +0100, Matthew Wilcox wrote: > > > On Thu, Jun 13, 2024 at 08:27:27AM -0700, Luis Chamberlain wrote: > > > > The case I tested that failed the test was tmpfs with huge pages (not > > > > large folios). So should we then have this: > > > > > > No. > > > > OK so this does have a change for tmpfs with huge pages enabled, do we > > take the position then this is a fix for that? > > You literally said it was a fix just a few messages up thread? > > Besides, the behaviour changes (currently) depending on whether > you specify "within_size" or "always". This patch makes it consistent. The quoted mmap(2) text made me doubt it, and I was looking for clarification. It seems clear now based on feedback the text does not apply to tmpfs with huge pages, and so we'll just annotate it as a fix for tmpfs with huge pages. It makes sense to not apply, I mean, why *would* you assume you will have an extended range zeroed out range to muck around with beyond PAGE_SIZE just because huge pages were used when the rest of all other filesystem APIs count on the mmap(2) PAGE_SIZE boundary. Thanks! Luis