From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (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 2592E3F7892 for ; Mon, 17 Aug 2026 11:07:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964853; cv=none; b=mFxMm4O/QCdncsFG7TKfrFbi0VLKR/ll5NAz6iN6sPZUXy6be3X6hMQG2j/C3Q1nnPFdHUbVoS3itcL7z3la3Mm/9+JdjVZQ2KaI+qMo7qxCyaOAu1+XjnCh9uwXN+6LAHKpbhPSDBNt3lYWsRCFm84PaHgV9dwkabhWDc6jHsI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964853; c=relaxed/simple; bh=e73NdorI6LGinThzPMM9qlaq4WdI7II1OvIcIKTKM4Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=U8vbjxU3TS0zN8GWiIUI/DOIVsVo37m0g3v67bMXWJKQ0bJUc7O087+xczD6E8wwdc3SS0prtnK3Ce575xPI2vA0hsEQwvhhvX23BUsJtwVNgGUeaULbFR5xXl1LsrQrQvdbRRqgIILOqaFzs162sEnfwYEK2ilzYeZv2qoYPQI= 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=TcRtptqZ; arc=none smtp.client-ip=209.85.215.180 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="TcRtptqZ" Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-ca7bea5e5b3so2346211a12.1 for ; Mon, 17 Aug 2026 04:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786964851; x=1787569651; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=iPDbOKwzDa8vtpfSUiBNZ/5Xwtz6TiDkuOOU4awK/CA=; b=TcRtptqZcXCWf0QyvE9/JxmnpX9lXkmO43/YsTjuv08JoeeziXs61TaYH5WmqisB5C IZvNLzADmZ4NsIYVJTJ+8zWXkj4DzBoyjKiHpfwX07fL4CTBpvOuh14BrKd+LuzDHalv O4PKHCMGcuGLouMvz3u+AvIaOt/LDGeRcuyVwHDAaTLc2jCv55MKstgR8ba0PuXYd/Rt SgyvUggo9nnuCIrLd0yIJFk80t+ySqf3kd5uieXqqV2rstU0EWeccWFfTb2Cop+mV3nK xiLdyx6tjCtpmm/su41fN1G13iqRTeX96ScBoVRk8apngzP3dgsDQ8UnGFYF3IswQrZ7 yTJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786964851; x=1787569651; h=content-transfer-encoding:content-type: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:content-type; bh=iPDbOKwzDa8vtpfSUiBNZ/5Xwtz6TiDkuOOU4awK/CA=; b=Bam+HeemWJas9rBtzoh/OJeovqI4zc0gd5lR2b639qNewJ2zfyJvR5CjTOa8u7ra9a MFPnXg/+5ndJza3nj5LgjdheyzPXcmUSgjEWqKd0wg8j102qDsnP8WvJXan2je6yYrj5 p75ZhNRNfqRh8DriefgUDW51+Hr6fXu+oU5bxQGTyucf4vnX4oZKIvQ+8VpRb22Aic6O RM07zMUb9M7x7bARghzAJoGuSy0pRUTs/+77frqgiX/l3R6m82ruIkgWpubCivWZ7+Ng 91Q9Q/y17fq13Y/aBl2GsxESZF3XPaEacAljEhVEADSIuvyDMmlxXntl9HXTT4TXjyFA rDMg== X-Gm-Message-State: AOJu0Yx6psJAfKAlOD2L/dRL0DpGh5mWVOgl8CMbSuMGTJLbRkcj5+XK g8TD1p+fHVyOdZCvjVyMNY5qGIzaOXBU+Xff+snYyvgsqNHTLlA2l7of X-Gm-Gg: AR+sD13beTChtfEg66SDlvx82tewrJV+ZD9J0Gav6btjpVe+tuVThd3M8PMnZqI4xmM 3Vjvav5RgWTZWeZaD8aZYWt38LNKZvHPXE9x9X/wjmRR7KjOTKMNgwlgsE1uhZZN6AxQ9lNHozd SSrZ5+AOrRAcmzCa4FcX2dCDvV6P6cra0xRhagtJuOS29gkTBXCDRZT9UpExZY+Bu0QYA+bXrR+ zz2BQWLLTS7rSxUX3zLb9Cakt2bRlWJo4dIaYgFEJYdz4Nao/yPII3QV3PQ2k/XfIcyQLzmLY6Y 5yrdnG+5ieP5zoqUcLWbOjfXLjBRah4z+2neUrRxraaOXPCjd4V+6N3PgtK72RnmJeXwXSUFAuO IEtqAZU7rHJVlhFvTCitQ5GYwanJmzT5TE/8185mD0DJzG+ykHxN5NiS0oQ5H4zEpuwn7bZ7s3R 7G84bwFmFLGDY6Vru0Wqwkokg+hTZfKLCTRktCN5C370Ji3R7ib63h1TF9Yp6SP2P5CuHr9Ql+m /fZ3PVzZC8YojiMxgM= X-Received: by 2002:a05:6a20:4305:b0:3bf:6222:2e7e with SMTP id adf61e73a8af0-3cc71c1b20dmr25115013637.4.1786964851226; Mon, 17 Aug 2026 04:07:31 -0700 (PDT) Received: from [100.125.248.95] ([124.70.231.46]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc13c00d84asm531019a12.19.2026.08.17.04.07.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2026 04:07:30 -0700 (PDT) Message-ID: Date: Mon, 17 Aug 2026 19:06:56 +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 -next v5 10/32] ext4: skip block allocation for holes in the data submission path To: Zhang Yi , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com References: <20260814093331.1703882-1-yi.zhang@huaweicloud.com> <20260814093331.1703882-11-yi.zhang@huaweicloud.com> Content-Language: en-US From: Zhang Yi In-Reply-To: <20260814093331.1703882-11-yi.zhang@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/14/2026 5:33 PM, Zhang Yi wrote: > From: Zhang Yi > > When ext4_map_blocks() is called from the data submission path and I/O > end extent conversion path (EXT4_GET_BLOCKS_IO_SUBMIT), it should not > allocate blocks if the lookup returns a hole. > > The writeback path can legitimately encounter dirty ranges that map to > holes. For example, when a folio straddles i_size and the tail beyond > i_size is dirtied via a mmap write. Allocating blocks for such ranges is > wrong because there is no data to write back, the dirty bits should > simply be discarded without submitting I/O. This mirrors the existing > buffer_head writeback path, where mpage_add_bh_to_extent() skips > unmapped buffers and ext4_bio_write_folio() clears their dirty bits. > > In the ioend extent conversion path, holes are also not expected because > we should wait for folio writeback before punching hole. If one is > encountered, it likely indicates a failure in the concurrency > protection. In this case, to avoid losing data beyond the hole, do not > stop conversion, continue on the remaining ranges. This prepares for the > buffered iomap writeback conversion. > > Signed-off-by: Zhang Yi > --- > fs/ext4/extents.c | 8 ++++++-- > fs/ext4/inode.c | 7 +++++++ > 2 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index 76038b6c3655..0d62d9312284 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -5167,11 +5167,15 @@ int ext4_convert_unwritten_extents(handle_t *handle, struct inode *inode, > EXT4_GET_BLOCKS_IO_CONVERT_EXT | > EXT4_EX_NOCACHE); > if (ret <= 0) { > + /* > + * If the ret is zero, an unexpected hole may cause > + * conversion to fail. To avoid data loss during I/O > + * end conversion, skip the hole and continue > + * converting subsequent blocks. > + */ > ext4_warning(inode->i_sb, > "inode #%llu: block %u: len %u: ext4_map_blocks returned %d", > inode->i_ino, map.m_lblk, map.m_len, ret); > - if (unlikely(ret == 0)) > - ret = -EINVAL; Hmm, we'd lose the error code here. Sashiko also mentioned in the review of patch 19 that hitting a hole during conversion could corrupt other files. That's a serious bug, so continuing the conversion doesn't make much sense. I think we should drop this change and just return the error early. Yi. > } else { > conv_blocks += map.m_len; > } > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index 5dcc3f7b2ffd..d8c3e5e13b8a 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -823,6 +823,13 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode, > map->m_flags |= EXT4_MAP_MAPPED; > goto out_handle; > } > + } else if (retval == 0) { > + /* > + * Do not allocate blocks for holes in the context of > + * data submission path. > + */ > + if (!map->m_flags && (flags & EXT4_GET_BLOCKS_IO_SUBMIT)) > + goto out_handle; > } > > if (!handle) {