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 ED08CC6FA8E for ; Fri, 24 Feb 2023 20:46:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CAED6B0071; Fri, 24 Feb 2023 15:46:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 27B546B0073; Fri, 24 Feb 2023 15:46:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1421B6B0078; Fri, 24 Feb 2023 15:46:02 -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 04ED26B0071 for ; Fri, 24 Feb 2023 15:46:02 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6478BC0DD1 for ; Fri, 24 Feb 2023 20:46:01 +0000 (UTC) X-FDA: 80503367322.11.5360DB8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 1A96120027 for ; Fri, 24 Feb 2023 20:45:58 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CylG0YEw; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677271559; 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=CXWCcTWtQAtpZMwkWvr7mMFe5zhDDr+sLVb4ims5Yh0=; b=Ti4PY30reYhMhLJk/0xVYcdB6yu0QM8LogGqsa23pm7jfVCcCTkgo5Ybz7CEhGHbfyKrAf aSAqh466/JOeE8/CeG3aMDAl7/cBGL5/wjF1b6/aY/1uhBikY7Pv70lkV6gELQqdKED3Iw GEedbNc0wYoIoSMxzW/OnOaV6wXAyio= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CylG0YEw; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677271559; a=rsa-sha256; cv=none; b=lQwsC1JcPeVJmT3wJpQKyeE3Q4cPqxUILWKICxlm0dtCVkUs4s4CZOmz2LlSRY10harrC5 logAKa0OGpvUOx8IjVOtW7UJjir+2Cf0jOI1NAn9e3+wHZlBwXJEqmjGAlPm68bgm+5Ivg YECqoc9bEOa7NRNB0kjaEMVm2hsohJE= 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=CXWCcTWtQAtpZMwkWvr7mMFe5zhDDr+sLVb4ims5Yh0=; b=CylG0YEwbg2HdKH7WRiHhc2PBo nUcBZWh4rU5DPQ9TwdH1oAb9/Ki20Z6DOb6Ha5jHTHCvDkMlTfpaTXMwpuw0Bvgs2fdtbMG/HxmHT vIBBsmb3nuBB7M2BfMJXYIsxJprhU5uFI5uvnTCU2Oz1HT0JWktUV45xoGl5q88xfFYtAXrigMAhQ yOJfDntwgXWN5/ONFP/Y6G71jxIrYJLc7viTo8ZZZ2RfK7t2YEA1QoZR293oxziJBqPqymqZMJS+D 0JsJPpN/gaMvOUAuWMzrGJBRDnQ8QT9WUERS6zRYpMLPdq7RDiwCW2wfjnjDcVjp08CukIx0wG+6+ qXj78o9w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVewi-00FYW5-RI; Fri, 24 Feb 2023 20:45:36 +0000 Date: Fri, 24 Feb 2023 20:45:36 +0000 From: Matthew Wilcox To: Linus Torvalds Cc: David Howells , Steve French , Vishal Moola , Andrew Morton , Jan Kara , Paulo Alcantara , Huang Ying , Baolin Wang , Xin Hao , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] cifs: Fix cifs_writepages_region() Message-ID: References: <2134430.1677240738@warthog.procyon.org.uk> <2009825.1677229488@warthog.procyon.org.uk> <20230220135225.91b0f28344c01d5306c31230@linux-foundation.org> <2213409.1677249075@warthog.procyon.org.uk> <2385089.1677258941@warthog.procyon.org.uk> <2390711.1677269637@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: xjjtqweif3yo8gr7fe1ye9tfi7y7rbqw X-Rspamd-Queue-Id: 1A96120027 X-HE-Tag: 1677271558-930832 X-HE-Meta: U2FsdGVkX1+CQ63sEyFKfaGw3EUcD+r67Ng18soUKY6TYLk4oBYYx6RUbtrIO1PD5CiMmLURu+9+0dLlbQKnN0OUd1w/lrYW9S3MNd/g/qpuVcYQ83KeWUajDZ+UNy9l1TthJICOFhWi5Ag3EHvvAdMF46NjFtnL3MMAefjvUxhLV97UNxh09LaUQjTZG6Xzyc7NYlJjHPJH4qsVAt9wvjiwjtcVkU+75sfBPPcXNa1/ndA2M+qPCzZht7tqRIQ1FbZduI3NG4YjsxFTWggYUvRdQtAF+xswXcGjBHRvwsTHLRz17OU0uFZHNsbi/H4pSk3clASpZwcGrePFX3ogELu2YZSMAKwb+sO/ttftMYhFX8/byUDlNfZV4z3bp/CCZZB35Qom69+/9eHSnZiNmbHZrrNDEzbn44zZPcrETWKGyv7Atee8gCSjmv8KDeU6e9SNSHm4zQGpv4LqWWO7putTJzLrH4bO0nAFdINQxXSJ4M9DUkHrCzXwAWr9nJjU7dbtHaOxPwhSyfqZ1Lmxmr8xc4lmj8njaftX22/vUnARP71ncrf1+pGJKBjAmHUoDgxnr0fCxeS41XT+8kVgGndLlKBVEeXcGGBgxe+P7uj8avOc7OB1Qn9TYzcFmaVtec8ZEo9Y4TbY9PmAKYK/cGrHRCR5K9GeQfjyKt0irh1OkOGkDAJHhtTYKxmS8VrnPu1zb17L9WcE44VIoDPvmwZ8cvBp/3RgWUm7EaiiRiecLjHMUsEE2PSm7qWrS/h+DVQI8/bpa0sKWNOGs9d8nMsIaP/j9azU2TiNUogMDt5AX4o9bHbpQcCGjurmVl0cbUljs0JZxpphH37J+b9pD0wtGVjGSPit+yWIzSAet2NOIp8Vbuf4GPktzfQaRXBhSHa63eKeqA3v/qN3I5i9tOUVZA4pUHK2H+R4ktaTCr+9zweFyVkNRzsEhxq8PVP6itXdfq/fsb33AKoKGE+ PlmEAbs8 npmdvyD1VAFkZOFIdV0WFWIfp4lhAjSl+fhkZL10QyF0zpuc6Plc14OhrpJooNgDgJrYE/A+ilXV/DGTswdKia2+wyJqm3T+FTjA0jDacXqy2zX84yGhgUxUvBAX0vgcdqfSUMeUJN7zJAOcSliK7LY3umbzMzYWu5evACjgpbqMvxIefd8Bsb2NgXL+2YWiYChfz4YdQTECFb09Bg146eMIIZQy9uyveRS6b9HcDD12U8w6Gw0k/uJP+jmD2r9gxrPfWHUkwqKwJCGFteDNXM0wOKerYKNIWZn8MZlGpcpfw4gU= 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: On Fri, Feb 24, 2023 at 12:16:49PM -0800, Linus Torvalds wrote: > On Fri, Feb 24, 2023 at 12:14 PM David Howells wrote: > > > > Then why do we have to wait for PG_writeback to complete? > > At least for PG_writeback, it's about "the _previous_ dirty write is > still under way, but - since PG_dirty is set again - the page has been > dirtied since". > > So we have to start _another_ writeback, because while the current > writeback *might* have written the updated data, that is not at all > certain or clear. also, we only have a writeback bit, not a writeback count. And when the current writeback completes, it'll clear that bit. We're also being kind to our backing store and not writing to the same block twice at the same time. > I'm not sure what the fscache rules are. My understanding is that the fscache bit is set under several circumstances, but if the folio is dirty _and_ the fscache bit is set, it means the folio is currently being written to the cache device. I don't see a conflict there; we can write to the backing store and the cache device at the same time.