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 8A10DC6379F for ; Thu, 9 Feb 2023 21:54:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8E086B00A4; Thu, 9 Feb 2023 16:54:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B3D9E6B00A5; Thu, 9 Feb 2023 16:54:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A054A6B00A6; Thu, 9 Feb 2023 16:54:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9553D6B00A4 for ; Thu, 9 Feb 2023 16:54:04 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 64AF3AB452 for ; Thu, 9 Feb 2023 21:54:04 +0000 (UTC) X-FDA: 80449106808.20.84FE126 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf14.hostedemail.com (Postfix) with ESMTP id 7C400100015 for ; Thu, 9 Feb 2023 21:54:02 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=Dka+5DdM; dmarc=none; spf=none (imf14.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 209.85.214.181) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675979642; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0oX/lGmYsdyx5VnhUGqtR+KDAdmrsp9Y/YPHFCTjwNA=; b=JY5tqFCew7ZLsbPR62NE/02u0S22B2scEhcTVtKC0BX4Ej1SWc1Mi3etqzoXkO6qZSBbra G0f2R65XK7v/ZB5zMbiQtlg6DNy3QBhxq4MARwrAejliVzHH8ZF5O7rMjG7Wq77Px0A8zW m2KAVNcweuhyiGw/BmdJPTHT332uh/Q= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=Dka+5DdM; dmarc=none; spf=none (imf14.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 209.85.214.181) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675979642; a=rsa-sha256; cv=none; b=vmzrXbqPNshCUd1NSGcjxuZWUqaYgXLQ0uQCK15d8xFvMuoF6GFoFct6Y+hT1J9dSdW4Dx LfxNyihH+rN3cXPc7/sqCo7LRS/LljBu7IZqSh4iTmZiA5hppsoa4ilYnupJWcVwXQmF0+ KMgqF05/HMHj3a2f56a3pmGQffSWYNo= Received: by mail-pl1-f181.google.com with SMTP id o8so2094403pls.11 for ; Thu, 09 Feb 2023 13:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0oX/lGmYsdyx5VnhUGqtR+KDAdmrsp9Y/YPHFCTjwNA=; b=Dka+5DdMdyuJvweTAJtER7ujyyrCUwCe7DZogFEspsK7zh/SU9WcyEFz8K9FPImVEx fVJTz1DCFLQFbRcXrYhMAlDtL42Wzyqv1YdFqNdD4i5wX2o6LFQiHw/Ut3SZ8mSYDaFt ajAqsQ/eWwraRs5nLh46MxwPRfQQkHe9xu3WRyeB2E0nIA9pqT//ImS/ilF3reKnS318 s52iLbBbRBMvr91PhWvVABusRn4qwzys1mmvDkN1XyMveU2OpjzikGbARFQy6DbNufEX vmI8ThZrgVJ4hsy8KfZl3B/uOduwMhMaCn3oewsfyEeMuFYZwKkdG+z9Hsi2iiU7xIWN P88A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0oX/lGmYsdyx5VnhUGqtR+KDAdmrsp9Y/YPHFCTjwNA=; b=33JiFVF0CQiHC6IQDeZmh0evIzTADkJhVvtLIK5uGDta92KnA1QpuJzD+MztpWgrDN pR0zFgQRlxl1kcTgaNKPPfg7XPJM7b2Z10+9DI5uECJN7kFLtilI2zjPSpdIof8REz2r hF7Mj3dVQRz3vEf02Io/aZLWbpoAn02Psmp8EoC9AkXhWvK6BFmmJltM5l4S/P7Ojh63 fCwvfOdKpb4etmrj96hOsoob5GDqL+IhS7Xk0mYPYc1vIXlB/sXZMetb0Yk7zS8bGUxJ 7XZV20Fpe7/6Q0aveEQptfZmssioM1YxzWvxbgqogC+BSV5xJvcPid89qq4lM3VfIKto zcFg== X-Gm-Message-State: AO0yUKX36iAHPQVz89vEJbj1GDo7qMTlp4o7JOgSZqdzFDGamR9URAc7 PXrXfukFVbHwi6xEL2L3TlBOJg== X-Google-Smtp-Source: AK7set+AzVGstAfdK4z0lHZ07rf0XD9ogpNvaI86WtR3MzF0pWUdM+mcOrZ5j7LF7wQNCocTD+G2iQ== X-Received: by 2002:a05:6a20:7f8e:b0:c0:b55b:8259 with SMTP id d14-20020a056a207f8e00b000c0b55b8259mr14663046pzj.0.1675979641353; Thu, 09 Feb 2023 13:54:01 -0800 (PST) Received: from dread.disaster.area (pa49-181-4-128.pa.nsw.optusnet.com.au. [49.181.4.128]) by smtp.gmail.com with ESMTPSA id j16-20020a62e910000000b0058d9a5bac88sm1885080pfh.203.2023.02.09.13.54.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 13:54:00 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1pQEre-00DO2z-CV; Fri, 10 Feb 2023 08:53:58 +1100 Date: Fri, 10 Feb 2023 08:53:58 +1100 From: Dave Chinner To: Matthew Wilcox Cc: "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner Subject: Re: [PATCH 1/3] xfs: Remove xfs_filemap_map_pages() wrapper Message-ID: <20230209215358.GG360264@dread.disaster.area> References: <20230208145335.307287-1-willy@infradead.org> <20230208145335.307287-2-willy@infradead.org> <20230208215311.GC360264@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7C400100015 X-Stat-Signature: cjz8rc67qit8nqpum6kqbm3ahtyhspk1 X-HE-Tag: 1675979642-26542 X-HE-Meta: U2FsdGVkX1/putWl90GUiaMBX/Gdm1qh6GULCQ7TWRy6Nic371Rbeag2G/dR1hhvaxHc2wKd9YU4/s2nzNan+YnPMOCf8crKaJXp3m/ZjVzrBfWsT1gA++869fE5cj292ReVq5lctLOZglt1z0vgWMdKUbhY4j3ufNT4rEosHUXxHco21n6PfbtDBK0Q3JyHccPaG+TUDut0hzPw+ciamzz3v49dUbszA/N0IRPgA9F6lNO35J/67nudPgCHS+LLja0lS3wrcIrWv/uUwaQa2Mn80jXmv9pCIsb9esvzxjxj0wJ/HH95CpPkFdxH2atAb4XMF2/mLRZYEAoGwLOSIloxqVTB8IQoi5H7smNunUqlJdic4sNg8l0qLo52ogmI69q05zA2aMyCe+I6Jtz15Hf0VfGw3m9meON10IJVDga8dBUYY081eXnlVF5Kge3fd2201WmFfpApSewffxxIRbyGZZ3yl2R/v/dGQ3xt8R8C92+dlm+bBBiM2Qk+8cyv8BMeb0cFuRzQmTs8UCAq1taeCHd+huneuXX2ucohmVaR+YeilQyBoplLtxfNhF+JhdMgfSGTvrCLiCMh1mrDvkpT+ICJkw4hFmAMUYS8Muiwk2zGy0wxGWLXJfOnlpjTGtanTugWxjUUZOFYxlLHOgHforLqbogfqqkHj7U0ULFHvh24VMccJYUgeNNo9BDkOYy4EoM8r2nESTZJJfTZhkpLo9/y1Wi+Olfpy8nygKiULAScKub771n7iO0HdytLhCP/D96Jn2I8Splydb4vzfu8VpNT4F5RfBJDkUoBQb/l9s75AqQh4sS5h5z+9i9gPcwg7bIyfCdnhzgbzDnYHxSO33f0vR9GA1UA9hb6mW4FiWhGYwh137NpKR5mZiWtP74CXsfXwOz7RqSXgXxTt2l3MO/BgAHv7hDzrfVz1WsyCdu6kAEXPB/7HTYY2VUyziFvznbjScL7jSPTTQQ Jubah0+l FH+MNSuUqiVrs4Bnb0shcXzkNCR3Ymq4Nk+PbsXGiETSEvV7wn5sAseRSY7CDLv9VfUKC3JikVac2kxzrjBrjwOqFMzX3De+ca31m6xGdbZP0uNH+SHcq1ApTfMA6WoMHIDWxs4PcmAFNw/75s1EEqteIKDIN9j4EiZlo6xXwe0y0Mqe+Z29GGXLngqANpDQrLI/bl+JlLHRv2s7NBAN/SNOwOlx0tvPIvb43CDLLAXJd/7HboeQ13kYD5ow56PnpjqSXOP3ZBfdiZlae4IFWKOXLw+lodMoquUU3QU3ugrti700pqyvRt5GSR6qjtgfIH7jN7aITFc7Jp2k/kEI0nO8Gh5Pa5BsRWjR0FJ1b+Nfzjs5NxRyc+JwMjSnaTZeidB4io+qO6WzycmHxOxujFgnILXXEPgXsflJRYA/FWU3gM7fZLty10qSZH4NYXabmUFM2vggYSkSuaL2CULmKPDZ3+Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.038847, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 09, 2023 at 02:44:20AM +0000, Matthew Wilcox wrote: > On Thu, Feb 09, 2023 at 08:53:11AM +1100, Dave Chinner wrote: > > > If XFS really needs it, > > > it can trylock the semaphore and return 0 if it fails, falling back to > > > the ->fault path. But I don't think XFS actually needs it. > > > > > > The ->map_pages path trylocks the folio, checks the folio->mapping, > > > checks uptodate, then checks beyond EOF (not relevant to hole punch). > > > Then it takes the page table lock and puts the page(s) into the page > > > tables, unlocks the folio and moves on to the next folio. > > > > > > The hole-punch path, like the truncate path, takes the folio lock, > > > unmaps the folio (which will take the page table lock) and removes > > > it from the page cache. > > > > > > So what's the race? > > > > Hole punch is a multi-folio operation, so while we are operating on > > invalidating one folio, another folio in the range we've already > > invalidated could be instantiated and mapped, leaving mapped > > up-to-date pages over a range we *require* the page cache to empty. > > Nope. ->map_pages is defined to _not_ instantiate new pages. > If there are uptodate pages in the page cache, they can be mapped, but > missing pages will be skipped, and left to ->fault to bring in. Sure, but *at the time this change was made* other operations could instantiate pages whilst an invalidate was running, and then ->map_pages could also find them and map them whilst that invalidation was still running. i.e. the race conditions that existed before the mapping->invalidate_lock was introduced (ie. we couldn't intercept read page faults instantiating pages in the page cache at all) didn't require ->map_pages to instantiate the page for it to be able to expose incorrect data to userspace when page faults raced with an ongoing invalidation operation. While this may not be able to happen now if everything is using the mapping->invalidate_lock correctly (because read faults are now intercepted before they can instatiate new page cache pages), it doesn't mean it wasn't possible in the past..... -Dave. -- Dave Chinner david@fromorbit.com