From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 229BC390200 for ; Fri, 12 Jun 2026 03:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781235770; cv=none; b=SjXmpodJUqDoDbJFzKyl6oHNvvxLsQvbVjIjc9yD1q+TMy/98iGeoeztyKeq0Pd7LlXQPvkjPhsrRPOAb0b05vjcgYxmUdn+5YpMMGz73tOlNB+VQzY68U5es/SVPnF9jrKmGEnNpvb79XJownF5LKeziQn7qEGUEs06Jsi3uos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781235770; c=relaxed/simple; bh=0Ml1BRfOkJAtTrtz8gssG/JfnPy8pf0VVHbhRExmPmo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=O614TiCPYbOnmx52u2YdfMEMwxaW3+xJZ/+WSIEMC7/4AN7z2J+NAgwHSbJG0SyG9KeBsyaB1wdC+vbQgaeesiQjZox237txNHydaFMAE1g5Y2G3sv2Gw6JDLpft0dy0bINW37fWLTpAOoi29Za3gRW699fA1uYAnUUTh29y7Wo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=A4k/eIYv; arc=none smtp.client-ip=115.124.30.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="A4k/eIYv" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1781235760; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=KlewREvmlKxyUSiB6UGySm1S0lQUskxigHenXGFtImY=; b=A4k/eIYvCv+2xP8E4ca6DPWpbMI6Bjl/tWb9vz/zF4fYyC3psSAS8xfzQJdONQ7dTO6pYii5VZb/EnRgSie1zTRMVKZf8JyrCR9y7ufDcyJLcZfyL7nDqrHuM7q4GzvqMMXzrtAjY1GV7qK6mIlJOjy/MRWzU0pUbvdeJML4JOU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X4fy44o_1781235759; Received: from 30.221.132.172(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X4fy44o_1781235759 cluster:ay36) by smtp.aliyun-inc.com; Fri, 12 Jun 2026 11:42:39 +0800 Message-ID: <58bef9af-0926-4948-b917-e38c3793f596@linux.alibaba.com> Date: Fri, 12 Jun 2026 11:42:38 +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] erofs: prevent buffered read bio merges across device chunks To: Yifan Zhao , linux-erofs@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org, yekelu1@huawei.com, jingrui@huawei.com, zhukeqian1@huawei.com References: <20260612033244.993507-1-zhaoyifan28@huawei.com> From: Gao Xiang In-Reply-To: <20260612033244.993507-1-zhaoyifan28@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/6/12 11:32, Yifan Zhao wrote: > EROFS chunked files may place adjacent logical chunks on different > devices. The physical block numbers are per-device, so two neighboring > chunks can still look sector-contiguous to the generic iomap buffered > read code. > > For example: > > logical file offset > 0 8K 16K 24K > +----------+----------+----------+ > | chunk 0 | chunk 1 | chunk 2 | > +----------+----------+----------+ > | | | > v v v > dev 1 dev 3 dev 3 > sector 8 sector 24 sector 40 > > The transition from chunk 0 to chunk 1 crosses a device boundary, but > iomap can still treat sector-contiguous bios as mergeable without > checking whether they belong to the same device. > > The pending bio, however, is still bound to the previous block device: > > bio->bi_bdev = dev 1 > > file 0..8K -> dev 1, sector 8 > file 8..16K -> dev 3, sector 24 > (must not be added here) > > If the second range is added to the same bio, it will be submitted to > dev 1 and read from the wrong backing device, which is easy to trigger > with readahead. > > This only affects paths using erofs_aops, where buffered reads go > through iomap bio helpers. > > Fix by install EROFS-specific iomap read ops and split the pending > buffered read bio whenever the next mapped range belongs to a different > bdev. After the split, fall back to the generic iomap bio read helper > for the normal sector-based merge checks. > > Reported-by: Kelu Ye > Assisted-by: Codex:GPT-5.5 > Signed-off-by: Yifan Zhao I think it's an iomap bug instead, see: iomap_bio_read_folio_range(), we should fix iomap instead. Thanks, Gao Xiang