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 72EDFC27C75 for ; Thu, 13 Jun 2024 07:57:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F03C06B00A1; Thu, 13 Jun 2024 03:57:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB3446B00A2; Thu, 13 Jun 2024 03:57:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7B056B00A3; Thu, 13 Jun 2024 03:57:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BAA196B00A1 for ; Thu, 13 Jun 2024 03:57:30 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 509551209DC for ; Thu, 13 Jun 2024 07:57:30 +0000 (UTC) X-FDA: 82225110660.17.3FE639F Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf10.hostedemail.com (Postfix) with ESMTP id 66578C000B for ; Thu, 13 Jun 2024 07:57:27 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=ufiRXK33; spf=none (imf10.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=1718265447; 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=79yFZYpSBlXzMXdhcFqLZ1+QEuQndmTfBg2z7dCBcsQ=; b=hBFRJXZ03ApuqjyjTrwDapVPemovP3/Q1fET/GGeXtYxRg0eIienwwZQPSl7K0k/y60h8n q74BX0nV92Ouns31YlORgtUkm39cmq9i4+QSw0mcveoH7fHrZJU397jAn0/f5hXKHGbxdd yLBT37bWR3bPuy5zZNEDC/NuRGcUMtU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=ufiRXK33; spf=none (imf10.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=1718265447; a=rsa-sha256; cv=none; b=8Kd8TZENoaWKcRxUm8Zciqp0Uzypc5xr+WmO531c8e4I2ZZJCUWAYvAXqEnF0HdlFvDRQ0 CkyHYdeS0n5Dia8vu0YvYRZD62TnBd9u1+JGXRowh0IEireLVIu7ACKIFZ4QOWuaqlMWfT yyQgRtxX+fZvnBf37x8M9KbM5osnsK8= 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=79yFZYpSBlXzMXdhcFqLZ1+QEuQndmTfBg2z7dCBcsQ=; b=ufiRXK33iwPT52qMweawk+OWHz UHy76pHAoq4FtanliK55TY0PAhlq8bdzpGxLhXU7aMNxsbkShMh1E3thr/ooRajcAqRzIFfUtY8mi 79YvdhtpJNLRRlIop6Tq9eT4ltptxwXXe8VEkHqLyxhDU9j3PmqH4dvK/kT9U1PIOwo+esP9BTFhS pExIIix2k1NIiFrjOm0ZfiWnrNMYhZOxhRR1fKKERHZ8WURp2MP4MwqqeNlfTf5EUczDN+cOPQVn4 mCYoMgeMmQmtpG2Y0pqGoqWj5VmT/SvAi1Br10KqisT75BbPayg3B4lcdmwqBZ/g2wGHd5xsfrYGo kT32WvGA==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHfKc-0000000FaHy-2BAQ; Thu, 13 Jun 2024 07:57:14 +0000 Date: Thu, 13 Jun 2024 00:57:14 -0700 From: Luis Chamberlain To: Matthew Wilcox , David Hildenbrand , Hugh Dickins , yang@os.amperecomputing.com, linmiaohe@huawei.com, muchun.song@linux.dev, osalvador@suse.de Cc: "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-1-kernel@pankajraghav.com> <20240607145902.1137853-7-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 66578C000B X-Stat-Signature: pwsdcp45dd4rknfxe3hbr9rt6eg7ej7p X-Rspam-User: X-HE-Tag: 1718265447-412277 X-HE-Meta: U2FsdGVkX19NTOlfX5GlaUQTrzw9yt7/6F2j23wD5iNHdvFiNHLX/7MMVflv2DqCD49M3tP35dajuEKNYkxdhNLLmWYkbV1gr4vTpoQjfK25jAkG7wLGiH4cUKX/n+AmWUUD4qQnqo3eYr+LsKZ/pHospEGkYfva4q/eO3xa+8lBjh4j9AYZ8RSKQO1ILPv+Z3vY4NDBeVsgmKXb3rJawdk+9/R0G7jneV2XG9mYfEd0AjCasZhkWbGV+V58CFNqM5YT7U0uXvJW2PvAh1QzaqT3kxEK1ADuVmUmoz/xa57kHun7tZr42bUigOv74skZ1jS9egLQ0xExCbhi4FaSLh3UjbPifxatMxjf8TOUiBYAXEvKTKc2/tmor/GEhbvS/7MpnMa7Wb3OLkYw1DkJ0+lBJ90eXtaNss6Y/+8e4kNhz6AlOhmBJ+dljqPulYJFCi3GHTpkv1NZZ8/dW+gWdKcr6Wbo6qmUqRHdFF7mgwMIoVqG//CYi+OBJcK0jEqADl8fEoV09MkoWj6FlGCjrwyTC9LPZChR9EJFYsP6RZA3dqK/7MZI0bIQqVgLy+3m2ulTUjtpQTZ6U9bH3KIY1LimjTCICnpxjjWWX9rpLUEq4HTknhdrS3VTteHM/jVzGBD10qqjkbwZ8CZlq6EPH59fSgvyHE10N1vZ+xkqcHhbs7clq7btLb9wFTMJHc8cIwtPaJKANjJ2NEt+WSmHY+hjKclUEDBQIEdiq4itj4gB5JqonUitDPxN33wjRW/gvgMGIsolzQ0F3zO9FbFfoN/LWL4AuuzpdRlFcsgLe1MpOE3Wslq5kGlfc3gAgsMoPV0jbGI23k/jnSlRUiJbk64MkCGkP7wtA5/O545i9SdrFSGNRR2Dl28tE8fB1PP6x9lMuSCbB+qLeJetAXFrgUEJ30xNG7E/VibI9gNGrdi3+5tHYNfIqHNWkqbGoihJRsJVY9ISO7i2BtvLrPn mXky7Udg PP0d7j6wekuG7g8zPakozn8F9N5e5X6x74m6JmufncqM85cFFj31Oet3ssmmib6gsZxw28BBYy4ptq9mlDTQp3Hz4jBn0DOcdxSnZugbXrdFn+kBNsIgWXnfGZ17VOU7v3X/9il4Pjcs4ocjWaNq71wAf1WL/SS13OPRE6TRyPZwlO0HJNTdCahpJJODkssjWh63H1frvVD0RD0y8aicIRjPqcLOEbFnIrxLnsY3kX6MqiM2GDQPpnovknNcGVzjb20hUjVWabXkNA8d0/JGEsPnO9Y+YCuc+Nk83GbThDmoEDgN2PuICg40QhsZND9Ap8GCMLPTG4DrngbMBxrCtiF0cfpa4wViw7Vi+KK/T1ZN9MzmIXpkG5cWUC9OqJRc5Tl/13rG+hniSf5Hh98Bqlmj4BpT/evAcvfWcOs2mxWdsw2bHZFHF1O7RP2s3QhDjlnhecrSvsdrJCsCZAAms7zicQrdCxFvgIQOtJG73WgJYFGGTPSGrNjwzAUronft48qxQNorzTgF8TxUUfzWpxg3mwC4zNiqXTZCItlvO1oH3yWWbvy3xo13lIA== 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, Jun 12, 2024 at 08:08:15PM +0100, Matthew Wilcox wrote: > On Fri, Jun 07, 2024 at 02:58:57PM +0000, Pankaj Raghav (Samsung) wrote: > > From: Pankaj Raghav > > > > Usually the page cache does not extend beyond the size of the inode, > > therefore, no PTEs are created for folios that extend beyond the size. > > > > But with LBS support, we might extend page cache beyond the size of the > > inode as we need to guarantee folios of minimum order. Cap the PTE range > > to be created for the page cache up to the max allowed zero-fill file > > end, which is aligned to the PAGE_SIZE. > > I think this is slightly misleading because we might well zero-fill > to the end of the folio. The issue is that we're supposed to SIGBUS > if userspace accesses pages which lie entirely beyond the end of this > file. Can you rephrase this? > > (from mmap(2)) > SIGBUS Attempted access to a page of the buffer that lies beyond the end > of the mapped file. For an explanation of the treatment of the > bytes in the page that corresponds to the end of a mapped file > that is not a multiple of the page size, see NOTES. > > > The code is good though. > > Reviewed-by: Matthew Wilcox (Oracle) Since I've been curating the respective fstests test to test for this POSIX corner case [0] I wanted to enable the test for tmpfs instead of skipping it as I originally had it, and that meant also realizing mmap(2) specifically says this now: Huge page (Huge TLB) mappings ... For mmap(), offset must be a multiple of the underlying huge page size. The system automatically aligns length to be a multiple of the underlying huge page size. So do we need to adjust this patch with this: diff --git a/mm/filemap.c b/mm/filemap.c index ea78963f0956..9c8897ba90ff 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3617,6 +3617,7 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf, vm_fault_t ret = 0; unsigned long rss = 0; unsigned int nr_pages = 0, mmap_miss = 0, mmap_miss_saved, folio_type; + unsigned int align = PAGE_SIZE; rcu_read_lock(); folio = next_uptodate_folio(&xas, mapping, end_pgoff); @@ -3636,7 +3637,10 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf, goto out; } - file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; + if (folio_test_pmd_mappable(folio)) + align = 1 << folio_order(folio); + + file_end = DIV_ROUND_UP(i_size_read(mapping->host), align) - 1; if (end_pgoff > file_end) end_pgoff = file_end; [0] https://lore.kernel.org/all/20240611030203.1719072-3-mcgrof@kernel.org/ Luis