From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 484B234E745 for ; Thu, 2 Jul 2026 14:40:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783003227; cv=none; b=eBdqpmAKljbbprG0Dh72KR1vhqethaEIR7mPIqWA/pvNNavC0HOsQKWCfTv0cIi8mjpW5dFKMTFfw5NA619TaDMvvovgqjrZB16D6M5H3CZcePqD+hciFLNGbYiofdf5py6mV0s3nZslPDzDhRooggG+Hfpm6C8S1JUvTqfZF8g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783003227; c=relaxed/simple; bh=8SXQMwkQWak5JtAlo0/6+48IpTWeTNNenwJue0W4smw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Bb7esVqUFroS1EOjv1So8pEp9AzH0QIKe3m7cOkZTaxNZFEpn/G62oDaAAJHdFvPSG5htM2YkcYrioMl/k4ChpSB3fTJbQTenxbvBoYqzT4p5dzelgxwQ9kfoQuGUE8kgO9qZdoeK0BOUL7HogAc2Z0Pc3II+DpvXsimKYMn2AY= 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=jvvQ1eSa; arc=none smtp.client-ip=209.85.214.177 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="jvvQ1eSa" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2c9c9913ddaso4851685ad.0 for ; Thu, 02 Jul 2026 07:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783003224; x=1783608024; 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=bTU+3Q9UdlwatP5ZqPWog06rA34o9OKHK0DTOYICJmE=; b=jvvQ1eSaP5WXnf9K2SlFP/zgQ5nK9pQBGP2xSVHVQKyavmnIDkNOxIjr+/erdacXf4 QVp+VIH6pysHmTckKTt5wpC3KHJzK0PkLfERp5dBK7pBQ0DdX6d+bpIz5P1CeDFJiB/m lfWntRXuh4FBL8YRYL0bW0emDpMhAEFe85+bsM2g2hIMY0myryofzvaudehbRl9H7Oiq B8WhFlucCXRklqjSGiyr4te55wovehnbt6UDgLa1GgM2FwjbEKGYa+lhR5NYCosVJqHh WlWcrIo/wfrqq2VXJhy/WY87FAJxDs6TCaNa4miB9YQrehtJnBWDtxFIsq9qhAbXlLNt /ScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783003224; x=1783608024; 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=bTU+3Q9UdlwatP5ZqPWog06rA34o9OKHK0DTOYICJmE=; b=aDmyDQlG9A0LDmXd1qPaztmGVE6H6De45pHS6U6apGr0DtU2r8Li9BbLnPJwP3j8ff RnIdozZdybD43cVqvE/O38lYd94jc7ZMYPCSVxVvbrUxMYfR++q59KXlY9pfaHNB6YbN LK4s8eKYwiCH4OvhB/JMiNNTp/XjAdaVupKP45lIevhLwRcLiDeBzBNQMViYG2I2rqKk JmOiM53qF1bMLkYdCpNtDvZwfpgGTQrLErJQ04gzSJMm4sQDdeC+DFSBXtWW8kUi/fy2 p7UiaQ/BVDlHkFyr11yUBefyo2LvEh5eHxyV+iXuP8FZTeYyyZqCj/CmRQpg6NUCN+WW lIqQ== X-Forwarded-Encrypted: i=1; AHgh+Rq3WYhlC0JvXuUfY2LnW0b7Gewy2AKDcsfKucP5UNMl5izNy70Dn/H2PmYmD9EWQKv+QcoviPPVdZYFl3QT@vger.kernel.org X-Gm-Message-State: AOJu0YzpM3jBuUqupgLJhOGXaAidetecLOA5PcEjeYHSnB72CrRMf8f8 YKnxg6h4qUhoRmPb8lyDXZ3omLZhVQhllWNMo/CVBiLM3I5L/r1FNZse X-Gm-Gg: AfdE7ckEDUsrIsFDsYbdzp0FoFO7P6zTuLUeeb65uo16tH3PmXB0ezOLzJOGfbh5zSa N8SAhxcZJt/eRUYSkwSwgIbHo8tMwgMWYQE8QS0ZEbJZs3gohzXakTs56oL4Pcy4WX39696FuNX 6jWbAFM/+Kzvd83SWg1EySsLc85/k7aW7Wp/0Q3FL2A5Z8liA2b9915CWFu0iWd5FK6+LQWnHSh JlNv79KOu7CAsMbtPlbCVv6DmXEoqabh32kwDiRqJRLj5c+7kZBcQaERCRZAakB5w3m5f4Tkcio hmnFp2zt5wbcyV//4bh7Rq5+yhy4wJfLVWZ04gZfXT88s/Ib4XVI9CI6FhOkI4THS6vIneDMjeh sRyYf15wS5md8iBIYf/EVDQE11M+uuUImMenXcK3QizYuQR/1fMKj+Pxha6aGWS0ulFHadU7lwr tV5/DQb7WVRGgE3iaggQsKDWKOrw1Ry4CqcZ/gCV3d8x9aezKiADRRH7jgpnXX X-Received: by 2002:a17:902:ccc2:b0:2ca:12aa:a390 with SMTP id d9443c01a7336-2caca49abbdmr2156365ad.0.1783003224398; Thu, 02 Jul 2026 07:40:24 -0700 (PDT) Received: from ?IPV6:240e:390:e4a:af91:e858:9955:9be:dcd0? ([240e:390:e4a:af91:e858:9955:9be:dcd0]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ca9a8dadaasm14634105ad.14.2026.07.02.07.40.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2026 07:40:24 -0700 (PDT) Message-ID: Date: Thu, 2 Jul 2026 22:40:17 +0800 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] ext4: clarify return semantics of ext4_load_tail_bh() To: Jan Kara Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yangerkun@huawei.com References: <20260701142009.1510104-1-yizhang089@gmail.com> <20260701142009.1510104-3-yizhang089@gmail.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 7/2/2026 5:53 PM, Jan Kara wrote: > On Wed 01-07-26 22:20:05, yizhang089@gmail.com wrote: >> From: Zhang Yi >> >> ext4_load_tail_bh() returns NULL for both holes and clean unwritten >> buffers, but the conditions that lead to this are not obvious from the >> code alone. Document this behavior to clarify the return value, so that >> readers do not mistakenly assume that only holes result in a NULL >> return. >> >> Also update the inline comment following the ext4_get_block() call to >> reflect this: both holes and clean unwritten buffers fall through to the >> "nothing to do" path. >> >> Signed-off-by: Zhang Yi >> --- >> fs/ext4/inode.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c >> index c2c2d6ac7f3d..0b31fa873743 100644 >> --- a/fs/ext4/inode.c >> +++ b/fs/ext4/inode.c >> @@ -4026,6 +4026,10 @@ void ext4_set_aops(struct inode *inode) >> * because it might have data in pagecache (eg, if called from ext4_zero_range, >> * ext4_punch_hole, etc) which needs to be properly zeroed out. Otherwise a >> * racing writeback can come later and flush the stale pagecache to disk. >> + * >> + * Return the loaded bh if it actually needs zeroing - in written, dirty >> + * unwritten, or delalloc state. Return NULL if it's clean (i.e., a hole or >> + * a clean unwritten block). >> */ > > Great that you're adding this comment because when I was reading previous > patch, I've spent like 10 minutes trying to figure that out :). But as far > as I'm reading the code, ext4_load_tail_bh() will return the unwritten bh > even if it is clean - map_bh() in _ext4_get_block() will set > buffer_mapped() even for unwritten extent. What am I missing? BTW, it also > seems to be ext4_load_tail_bh() could attempt to ext4_read_bh_lock() on > unwritten bh if things align wrongly... > > Honza Thank you for the review! Please note the ext4_update_bh_state(bh, map.m_flags) call in _ext4_get_block() — it restores the mapped flag back to unwritten. As a result, the !buffer_mapped(bh) check will evaluate to true for a clean unwritten block, the function will return NULL. Thanks, Yi. > >> static struct buffer_head *ext4_load_tail_bh(struct inode *inode, loff_t from) >> { >> @@ -4065,7 +4069,7 @@ static struct buffer_head *ext4_load_tail_bh(struct inode *inode, loff_t from) >> if (!buffer_mapped(bh)) { >> BUFFER_TRACE(bh, "unmapped"); >> ext4_get_block(inode, iblock, bh, 0); >> - /* unmapped? It's a hole - nothing to do */ >> + /* It's a hole or a clean unwritten block - nothing to do */ >> if (!buffer_mapped(bh)) { >> BUFFER_TRACE(bh, "still unmapped"); >> goto unlock; >> -- >> 2.53.0 >>