From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87BF3346E43 for ; Wed, 24 Jun 2026 13:30:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782307818; cv=none; b=WGgju1LWljilFbofzbTzc5JdqmeVd/lKosmv0u4zsvGluhVGfCwLQZhd2CiTGdB+MyJ6BNWIr3vSTULORq3vV9Ns5MBuYLOHvHIkox5mAD75J8MPdvomeePBL3bhLpdNFeT4gn74EvvFHDzVynqMOQExa88fSZu3MVGFpRfn4Cg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782307818; c=relaxed/simple; bh=x5J///5NPUcpX55tKsjGNahFZmgb6VfI1DKrdJb5DwA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MnJNuA//dsgnmlbiDh9//oqZbbJMvHabvge3QHVXO5U6cyq4TSFs0/kDuNMaf/1tuHMNUSHSKPuoHpB/ho9bOF2PITNyiwqsJfdtqwIRrK218eMUcrr3CHiO8czZQNytzVW0MZ1abofL1VSHlTK0JK9tiQmJY9hwwrl2TTLp3Hc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IoCBCgC8; arc=none smtp.client-ip=209.85.210.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IoCBCgC8" Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7e718d46a6aso515109a34.0 for ; Wed, 24 Jun 2026 06:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782307816; x=1782912616; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nJMUfV0d4iL8GIoizfgvCU8470KRE9mKLUPI4sCYS14=; b=IoCBCgC8J/FaPjb3ZmV3dvAWFh1cGzYjQ+5K8fgyXGPNVIljDt6xT4UXEu4+cv4y/9 DeBVwlxZMztbZL4E+e13jCkSA1IZTaJmMlCdmMHIRMpitSDY/lmLpjEtM3pF4oYITJzZ ABhpQmn/IAY2FgjuGE4XKCnw6sWQHVDo5MxS8IzRQHKkSSz8uBS5yLefqJwtHwUux26C P3Ke24y4GxblSfUQZFm53iFlm3yjnOAfAteDRVGBx0giT4F4S1zC/dqaau9JlXXI6LYk zN4/31Aev4CLe61zMLdaOGkSlRBQfuSa9poB6r2voQYH2Nfl3Lct6O6yPa2DwYhgDkwR VEpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782307816; x=1782912616; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nJMUfV0d4iL8GIoizfgvCU8470KRE9mKLUPI4sCYS14=; b=Dw+K3LTp/uvvg/cLg0SyddSLDwVl/w6tUWtkTSzTJxxcGxDiEv7hMrUUOqw5HcN5+X W0BhCXfbMgQ25IQWMeSAK5G3oZQ3zBy7hyn1IN0AtB9CPQZyosRcc+sH7r5Ca6oTCCbF 86qFGaeMtNiLyiSv3F6+LRbe75920y01wytHZ//RakQhE/7Xm6tuZLjDO9v2+BcrF9uL /Nz9ilySoUarir3UfQMLwbcVa3xWEPmSFktL/po31laDzHPhoB2HIIkfVsy9WJuZG6pr LWPFzf8jG2sXBjImc77oUa7u+u/UWROCp7mB4y3yKnWE2I5+DQBm4BsYs5EQfxdhTE8r iRJw== X-Forwarded-Encrypted: i=1; AFNElJ+1EggSD86T5ruEsqJ4rECThEW2RVU7Hx5YAWR0XqFijpXhcCpy9HYyYW7NqhsU5G+iASKIUnRvzRkUQOo=@vger.kernel.org X-Gm-Message-State: AOJu0Ywrk1i2TrXCqzlXN+uQrLRvNzX8g/3CcN+VxPqkamFwksqhwKs3 kOnaLxJIOy6CySB7/ejCIXvRktWSqQYMxqegVHeM6I7ps2yjKdrxRVL7 X-Gm-Gg: AfdE7clGUGeorHYpRof7bj2e9cM1SCgMmwQznfBhepQo11MFWhqA7DAlKrQAhe4/CD2 jDAMtmTPd8u7U/ft47JTaJ8GKK6FJNpBW+V6Y0lZuePC3HtNECfqOEIPRbtarybcX3QUilKdzJ+ OHg6KqJJJJCKj6yB2f7Rq8T8mCXqvGDGyfdKzhzX+eNADdR7TOTj6iRPQnpIwm0dM/OHr9QjoK/ HpotZ/YzYq6U+oJejwcBstUtM6SjHVqnX8r237iy+dnB8j7nEbV5M+MPO3jXJIgSGOwuZu077MV PTPYfwJZASe4rUE/ZhZ2h9zEvtdmVDw6/R3yCucl7vjSBXQoUOCD3+aiZehYxJBMMl6quX7/Rsi PGJW+ugwsnWCOegb7+x2HOwgvXTmoLmN1IpDqlKmpgkPNNKqs5IckAaB6Cvq7cW/ZRjq5knNsIK 1DGxzo95pIkWAGHyMIdW8Kqb5NvkS6lPwe X-Received: by 2002:a05:6830:2a0d:b0:7e7:62f:727e with SMTP id 46e09a7af769-7e986cc0cb8mr2435079a34.22.1782307816330; Wed, 24 Jun 2026 06:30:16 -0700 (PDT) Received: from [100.125.248.95] ([124.70.231.46]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e944008fe7sm11846550a34.6.2026.06.24.06.30.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2026 06:30:15 -0700 (PDT) Message-ID: <7471b9cb-158a-4ed4-a1ce-95270ef38974@gmail.com> Date: Wed, 24 Jun 2026 21:29:58 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ext4: cancel dirty accounting for folios without buffers To: Jan Kara , Zhu Jia Cc: Zhang Yi , tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, ojaswin@linux.ibm.com, ritesh.list@gmail.com, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260623094947.7853-1-zhujia.zj@bytedance.com> <81ed36cc-b5c8-41cf-8b7d-16611e61e294@huaweicloud.com> <20260624094535.1-zhujia.zj@bytedance.com> Content-Language: en-US From: Zhang Yi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/24/2026 8:32 PM, Jan Kara wrote: > On Wed 24-06-26 17:52:06, Zhu Jia wrote: >> Hi Yi, >> >> Thanks for taking a look. >> >> Yes, clearing PAGECACHE_TAG_DIRTY/TOWRITE would make the page-cache state >> cleaner. I had a version that did this by adding a helper around >> folio_cancel_dirty() and clearing the xarray tags after confirming the >> folio was still the same clean page-cache entry. >> >> It looked like this: >> >> static void ext4_cancel_dirty_folio(struct address_space *mapping, >> struct folio *folio) >> { >> XA_STATE(xas, &mapping->i_pages, folio->index); >> unsigned long flags; >> >> folio_cancel_dirty(folio); >> >> xas_lock_irqsave(&xas, flags); >> if (xas_load(&xas) == folio && !folio_test_dirty(folio)) { >> xas_clear_mark(&xas, PAGECACHE_TAG_DIRTY); >> xas_clear_mark(&xas, PAGECACHE_TAG_TOWRITE); >> } >> xas_unlock_irqrestore(&xas, flags); >> } >> >> The reason I left the tags unchanged in this version is that I was not sure >> whether it is appropriate for ext4 to open-code xarray tag cleanup directly. >> >> If you think this is the right direction, I can add the helper back and >> send a v2. > > That was a good judgement! Playing with xarray tags like this in filesystem > code is certainly not a good thing. For now, I'd leave the xarray tags > dangling - they will be eventually synced with reality on next writeback > attempt. If this inconsistency of tags needs to be fixed, the fix belongs > to the generic code (so that it can be used in other places as well). > > Honza Yes, I agree. Directly clearing the tag via open code is not a good approach. However, I took a look at the !nr_to_submit branch in ext4_bio_write_folio(), and it seems to have a similar simple handling pattern—it directly calls __folio_start_writeback() and folio_end_writeback(), which appears to be an elegant way to clear them. Could we also call these two helpers just after folio_cancel_dirty() here? Thanks, Yi.