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 6622DC3601E for ; Thu, 10 Apr 2025 19:14:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3F5528008A; Thu, 10 Apr 2025 15:14:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEE396B0379; Thu, 10 Apr 2025 15:14:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB70028008A; Thu, 10 Apr 2025 15:14:51 -0400 (EDT) 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 ACF426B0378 for ; Thu, 10 Apr 2025 15:14:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4A0705B6B5 for ; Thu, 10 Apr 2025 19:14:52 +0000 (UTC) X-FDA: 83319086424.09.7AB32A6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 6630980005 for ; Thu, 10 Apr 2025 19:14:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OgqgG0yv; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744312490; 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=CsYtj+99g3ufjQJJHjFAKOMB1TbPSAbut7l/t4VyhoI=; b=d+Yx6GYv8WOAYxatoooUrbnNbum02w03DUydfblwMMAODMdlwht1N+4QDILZd/I/9IXB13 ZNWBL10hGmDt8kCOp3F8VOb0AzrsKKo2yixzHJ9kuJ66xB7ubNsBKE1V8ng9fNTa9vRdvX J9B6ZkptGFRs/asKcXY0hQOkQfIWeBo= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OgqgG0yv; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744312490; a=rsa-sha256; cv=none; b=TePvqv0vbdosuXBqgqqeD3UTdAnDuJ4YxJxTxiAx5cJbBWjLFqzN62yk18dsk5EhY66NC4 QsFo4Wx17YLTVE7/q3UGZI1nFLhsE09KSMkQKDRpew00SzXJqjem7SXSdu9DKonVblvCG4 R50QEEVXd5J/2ghbI0odRUyXQfMkVcQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CsYtj+99g3ufjQJJHjFAKOMB1TbPSAbut7l/t4VyhoI=; b=OgqgG0yvYXYzbeEjyL07gDUjCu mmr8lsjZFCr15eIv1ausUPOR8UA6YqU5DRnILF0lcUOvDriAt5FgPGrdK1hTQyKI25p7Qi67DBnAI +j4/l7AGRBgE+wd4KSGfoKoE9jTREvBKNDNDCO3iiYqLN+JFn+ohlEi9oGS9PAzMq+FSWWIpEJulF QR6HLHfRrDEjRHKJA55MuY5tUvZ+Z4j3G7BUUatHHwAVL8v0+HmUSAS+Cqnax/juu0QN8ymkw777o l4nba4AJDruop7NKF5V8tQPBOlRJyWhzMusRCZY34/xPg2+5efM2k4+67Uoal/vBmwe0W+ZBVp0gx LtTdjosA==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1u2xMN-00000003HtV-1JN8; Thu, 10 Apr 2025 19:14:47 +0000 Date: Thu, 10 Apr 2025 20:14:47 +0100 From: Matthew Wilcox To: John Hubbard Cc: Christoph Hellwig , David Hildenbrand , David Howells , "Kirill A. Shutemov" , linux-mm@kvack.org, Jens Axboe , linux-block@vger.kernel.org Subject: Re: Does GUP page unpinning have to be done in the pinning context? Message-ID: References: <939183.1743762009@warthog.procyon.org.uk> <67d4486b-658e-4f3f-9a67-8785616e6905@redhat.com> <21dfcbfc-5295-4493-8ae1-eaa82f018472@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21dfcbfc-5295-4493-8ae1-eaa82f018472@nvidia.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6630980005 X-Stat-Signature: jr9d3mpif7yeqnxdxe5sffn7hbtqd8i4 X-Rspam-User: X-HE-Tag: 1744312490-852838 X-HE-Meta: U2FsdGVkX1+HaroEyRx16GfHk/gJQ10VIg+OHVLiePScibTCl6yRwQgAtfBZqk44imDnVQtv1yFaGI0z0YbJkPdQmkR1hms7H8q+vBhqJgG95PJLo9t5Ci2/VBeLwdJzBu1FRddDR2spsApNvfqn6mSNVSwPrzt9CE2qM10vPIoyOwXM60G5Jjv/KDC2d9+d+e9lM8uZojAxMQuMfZuEYVbj5ijACn8G9ghg3Gb59QXcu/UIvZZSw6+fwLovp/TbPKNouyWjvzNuvVXkIvATG5wV89VSZlue1gooyIv1bEoOimL90JUtJqApouWuIluiE6E1eT3Mv1mz33LBS/zJC/qXjcsN7etZD/qOtyg/WjIIVA4aFIADY+QrKzoFdjIgyXoxjfaCjFISG47p73yLGX3mCjjcEJOKhCy1YrLnrr0YRLdvdZOSu7X+qHLwH6EedqNq/Vak+5pyFUnlpzW959b3Rox7GK09IMrVE+ntOOSmm2m0tL6YdJxhd8VaELNbI3/uGmu4CJuS0gYz2tBmMVrnK2WGlpcyALNGX56Wmxcu97hlV5jPi/I3k7YjSWdSgkoha5fGOyzRZCIQIjpXvu+y8EpUAW1kppt0w+3QDCN1UTDHrXSwLrhFT2ZOYsvgUDNf8ALsozbCrB9W1Duwix6jJOHVMUlQWEVkWQKygxWYcp59vkIKc/vbB4sXnEFqoknisPAxpnPETMatqXYhcT/pqcIQ+lhYz8jlzJFDvUWNVDv5c2XJAkn6VFvlKfjFss/6H+YdEjZVEw1LBuinRiGG563RY2zn3+Z/h6/ICfiW74fAWbkzGPL7rjvmByoUTzASIUiQ9GAL0gzAkZjnSC8tyTDE3unRYwk45whjGbeaVUX+gqVVeabKnMS/+1las4glUYHzpJFlUoFUI0lImgVrbZoG+BD6Fv0ZOwyX/Rjbn8/aZtGML3SQ6pxBaTb6WvAgwmPKBAPJ3Lhkmom FTf3xnl5 chraEY641mY9Bp9WiCOfDJdgJmrtnx7GCdgXfB8oZ+cR/AGk6ejvt3L0/SFRTahfsHp2dIBiBagUW7805h4rJEg+qrxbGeF6RMxom2Bw5TCIT19isTBWZ/OoBWzpwo2ZVxoiE+phjn4CYpZeS/dpftnkzoGrylsCa7pB26q9dIpbHsd5a3IpxW2MJH7E2CpkjRcZSHuti/TGZvllcjNs2M1mo43JdHYcyufLYgiOcbnVlLYR0Fe9qsAjWZmyMksvs3dWWj6w7H3obJo/zjL7MVx48QnZX2BRjhvknrdH0dYzyq5c= 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, Apr 10, 2025 at 12:11:42PM -0700, John Hubbard wrote: > On 4/10/25 12:28 AM, Christoph Hellwig wrote: > > On Wed, Apr 09, 2025 at 07:56:07PM -0700, John Hubbard wrote: > >> This topic always worries me, because the original problem with > >> dirty pages is still unfixed: setting pages dirty upon unpinning > >> is both widely done (last time I checked), and yet broken, because > >> it doesn't do a mkdirty() call to set up writeback buffers. > >> > >> The solution always seemed to point toward "get a file lease on that > >> range, before pinning", but it's a contentious design area to say > >> the least. > > > > For the bio based direct I/O implementations we do set the pages > > dirty before starting I/O using bio_set_pages_dirty, which uses > > folio_mark_dirty and thus calls into the file systems using > > ->dirty_folio. But we also do a second pass on I/O completion > > before the buffers are unpinned. Which I think now that we pin > > the folios is superfluous. > > > > Oh actually I think I was wrong in my earlier reply about clearing > the dirty bit. Because in Jan Kara's original bug report, what > happened was that periodic writeback came in while the pages > were pinned, and cleared the dirty bit--and also deleted the > page buffers (file system specific behavior) that are required > for writeback. > > So then later when the pages are unpinned and marked dirty, > that causes the next writeback to fail in an unexpected way > (it used to cause ext4 BUG checks, in fact). > > So the problem here is that these pinned pages can get cleaned > while they are pinned, and then dirtied again by DMA (invisible > to the filesystem). Did we fix that already? Because it's relatively easy to writeback pinned pages and _not_ clear the dirty flag. That handles the two problems which are falsely thinking that a heavily-mapped order-0 page is pinned (we write it back anyway, so don't lose data on crash), and doesn't strip the bufferheads.