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 X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CA84C433DB for ; Tue, 23 Mar 2021 14:16:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BE6060295 for ; Tue, 23 Mar 2021 14:16:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BE6060295 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6FA8C6B018A; Tue, 23 Mar 2021 10:16:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ABC26B018B; Tue, 23 Mar 2021 10:16:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54C9A6B018C; Tue, 23 Mar 2021 10:16:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 37D636B018A for ; Tue, 23 Mar 2021 10:16:53 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E2F66364E for ; Tue, 23 Mar 2021 14:16:52 +0000 (UTC) X-FDA: 77951340264.31.C4824D1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 32FA4C0007C8 for ; Tue, 23 Mar 2021 14:16:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616509003; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ecY1CzrvE1DPEu+sD2G/cZP9TNuYSjbK9W1EHfXolDw=; b=NxsK0AGEDQc7HzJXteBBKJdAUMGZMEJM1LnD7MTTFfXTAflZDfVRynHwYeqWJLBCMLk2vi scW1p4CzkMH4OwNfN6a5aq/khC65wgbhNhPlv2UAv7YQ/SmOtMYWcXr1Jwjz4Dl/m/c5Pm i0Spc6lsQosBTSAv1qxuGlSPr3shIMg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-205-exvroquTOx2NCDRTMVZpiw-1; Tue, 23 Mar 2021 10:16:39 -0400 X-MC-Unique: exvroquTOx2NCDRTMVZpiw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0C2855B365; Tue, 23 Mar 2021 14:16:36 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-112-58.rdu2.redhat.com [10.10.112.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id E189C10016FD; Tue, 23 Mar 2021 14:16:28 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20210323135116.GF1719932@casper.infradead.org> References: <20210323135116.GF1719932@casper.infradead.org> <1885296.1616410586@warthog.procyon.org.uk> <20210321105309.GG3420@casper.infradead.org> <161539526152.286939.8589700175877370401.stgit@warthog.procyon.org.uk> <161539528910.286939.1252328699383291173.stgit@warthog.procyon.org.uk> <2499407.1616505440@warthog.procyon.org.uk> To: Matthew Wilcox Cc: dhowells@redhat.com, Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Linus Torvalds , Christoph Hellwig , Alexander Viro , linux-mm@kvack.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Jeff Layton , David Wysochanski , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 02/28] mm: Add an unlock function for PG_private_2/PG_fscache MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2503809.1616508988.1@warthog.procyon.org.uk> Date: Tue, 23 Mar 2021 14:16:28 +0000 Message-ID: <2503810.1616508988@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 32FA4C0007C8 X-Stat-Signature: tab73uhrfqyqp8qqa4epk1usbpjgnawg Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616509009-66592 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: Matthew Wilcox wrote: > On Tue, Mar 23, 2021 at 01:17:20PM +0000, David Howells wrote: > > +++ b/fs/afs/write.c > > @@ -846,7 +846,7 @@ vm_fault_t afs_page_mkwrite(struct vm_fault *vmf) > > */ > > #ifdef CONFIG_AFS_FSCACHE > > if (PageFsCache(page) && > > - wait_on_page_bit_killable(page, PG_fscache) < 0) > > + wait_on_page_fscache_killable(page) < 0) > > return VM_FAULT_RETRY; > > #endif > > > > @@ -861,7 +861,8 @@ vm_fault_t afs_page_mkwrite(struct vm_fault *vmf) > > * details the portion of the page we need to write back and we might > > * need to redirty the page if there's a problem. > > */ > > - wait_on_page_writeback(page); > > + if (wait_on_page_writeback_killable(page) < 0) > > + return VM_FAULT_RETRY | VM_FAULT_LOCKED; > > You forgot to unlock the page. Do I need to? Doesn't VM_FAULT_LOCKED indicate that to the caller? Or is it impermissible to do it like that? > Also, if you're waiting killably here, do you need to wait before you get > the page lock? Ditto for waiting on fscache -- do you want to do that > before or after you get the page lock? I'm waiting both before and after. If I wait before, write() can go and trample over the page between PG_writeback/PG_fscache being cleared and us getting the lock here. Probably I should only be waiting after locking the page. > Also, I never quite understood why you needed to wait for fscache > writes to finish before allowing the page to be dirtied. Is this a > wait_for_stable_page() kind of situation, where the cache might be > calculating a checksum on it? Because as far as I can tell, once the > page is dirty in RAM, the contents of the on-disk cache are irrelevant ... > unless they're part of a RAID 5 checksum kind of situation. Um. I do want to add disconnected operation in the future and cache encryption, but, as things currently stand, it isn't necessary because the cache object is marked "in use" and will be discarded on rebinding after a power loss or crash if it's still marked when it's opened again. Also, the thought has occurred to me that I can make use of reflink copy to handle the caching of local modifications to cached files, in which case I'd rather have a clean copy to link from. David