[PATCH v2] erofs-utils: lib: fix infinite loop on EOF in erofs_io_xcopy

[PATCH v2] erofs-utils: lib: fix infinite loop on EOF in erofs_io_xcopy

[Ajay Rajera]

erofs_io_xcopy() has a fallback do-while loop for when the
kernel fast-paths (copy_file_range/sendfile) do not handle all
the data.  The loop does:

    ret = erofs_io_read(vin, buf, ret);
    if (ret < 0)
        return ret;
    if (ret > 0) { ... pos += ret; }
    len -= ret;
  } while (len);

When erofs_io_read() returns 0 (EOF -- source exhausted before
all bytes were copied), only the ret < 0 and ret > 0 branches
were handled.  Since ret == 0, `len -= ret` is a no-op and
`while (len)` stays true, causing the loop to spin forever at
100% CPU with no error and no progress.

This can be triggered when building an EROFS image from an input
file that is shorter than expected -- e.g. a truncated source
file, a pipe/FIFO that closes early, or a file being modified
concurrently during mkfs.

Fix it by treating a zero return as an error (-EIO) so the
caller fails cleanly instead of hanging indefinitely.

Also fix the long-standing 'pading' -> 'padding' typo in the
short-read diagnostic message of erofs_dev_read().

Signed-off-by: Ajay Rajera <newajay.11r@gmail.com>
---
v2:
 - Use a cleaner if/else if structure instead of nested ifs (Lucas)
 - Return -EIO instead of -ENODATA on premature EOF as it represents an I/O issue (Lucas)
Signed-off-by: Ajay Rajera <newajay.11r@gmail.com>
---
 lib/io.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/io.c b/lib/io.c
index 0c5eb2c..cb99dee 100644
--- a/lib/io.c
+++ b/lib/io.c
@@ -430,7 +430,7 @@ ssize_t erofs_dev_read(struct erofs_sb_info *sbi, int device_id,
 	if (read < 0)
 		return read;
 	if (read < len) {
-		erofs_info("reach EOF of device @ %llu, pading with zeroes",
+		erofs_info("reach EOF of device @ %llu, padding with zeroes",
 			   offset | 0ULL);
 		memset(buf + read, 0, len - read);
 	}
@@ -667,12 +667,13 @@ int erofs_io_xcopy(struct erofs_vfile *vout, off_t pos,
 		ret = erofs_io_read(vin, buf, ret);
 		if (ret < 0)
 			return ret;
-		if (ret > 0) {
-			ret = erofs_io_pwrite(vout, buf, pos, ret);
-			if (ret < 0)
-				return ret;
-			pos += ret;
-		}
+		else if (!ret)
+			return -EIO;
+
+		ret = erofs_io_pwrite(vout, buf, pos, ret);
+		if (ret < 0)
+			return ret;
+		pos += ret;
 		len -= ret;
 	} while (len);
 	return 0;
-- 
2.51.0.windows.1

Re: [PATCH v2] erofs-utils: lib: fix infinite loop on EOF in erofs_io_xcopy

[Gao Xiang]

On 2026/3/21 11:42, Ajay Rajera wrote:
> Thank you, I appreciate it.
> 
> best regards,
> Ajay Rajera
> 
> On Sat, 21 Mar 2026 at 08:41, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2026/3/21 02:50, Ajay Rajera wrote:
>>> erofs_io_xcopy() has a fallback do-while loop for when the
>>> kernel fast-paths (copy_file_range/sendfile) do not handle all
>>> the data.  The loop does:
>>>
>>>       ret = erofs_io_read(vin, buf, ret);
>>>       if (ret < 0)
>>>           return ret;
>>>       if (ret > 0) { ... pos += ret; }
>>>       len -= ret;
>>>     } while (len);
>>>
>>> When erofs_io_read() returns 0 (EOF -- source exhausted before
>>> all bytes were copied), only the ret < 0 and ret > 0 branches
>>> were handled.  Since ret == 0, `len -= ret` is a no-op and
>>> `while (len)` stays true, causing the loop to spin forever at
>>> 100% CPU with no error and no progress.
>>>
>>> This can be triggered when building an EROFS image from an input
>>> file that is shorter than expected -- e.g. a truncated source
>>> file, a pipe/FIFO that closes early, or a file being modified
>>> concurrently during mkfs.
>>>
>>> Fix it by treating a zero return as an error (-EIO) so the
>>> caller fails cleanly instead of hanging indefinitely.
>>>
>>> Also fix the long-standing 'pading' -> 'padding' typo in the
>>> short-read diagnostic message of erofs_dev_read().
>>>
>>> Signed-off-by: Ajay Rajera <newajay.11r@gmail.com>
>>
>> Look good to me, will apply.

This patch cause a regression which can cause build failure:
https://github.com/erofs/erofsnightly/actions/runs/23392598146/job/68049898517

It can be reproduced by:
$ mkfs/mkfs.erofs --zfeature-bits=78 foo.erofs linux-5.4.140

I dropped this patch.

Thanks,
Gao Xiang

>>
>> Thanks,
>> Gao Xiang

Re: [PATCH v2] erofs-utils: lib: fix infinite loop on EOF in erofs_io_xcopy

[Ajay Rajera]

yeah, I checked it and you are right.
I have sent patch v3 to fix this.
Thanks,
Ajay Rajera.

On Sun, 22 Mar 2026 at 08:53, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2026/3/21 11:42, Ajay Rajera wrote:
> > Thank you, I appreciate it.
> >
> > best regards,
> > Ajay Rajera
> >
> > On Sat, 21 Mar 2026 at 08:41, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >>
> >>
> >> On 2026/3/21 02:50, Ajay Rajera wrote:
> >>> erofs_io_xcopy() has a fallback do-while loop for when the
> >>> kernel fast-paths (copy_file_range/sendfile) do not handle all
> >>> the data.  The loop does:
> >>>
> >>>       ret = erofs_io_read(vin, buf, ret);
> >>>       if (ret < 0)
> >>>           return ret;
> >>>       if (ret > 0) { ... pos += ret; }
> >>>       len -= ret;
> >>>     } while (len);
> >>>
> >>> When erofs_io_read() returns 0 (EOF -- source exhausted before
> >>> all bytes were copied), only the ret < 0 and ret > 0 branches
> >>> were handled.  Since ret == 0, `len -= ret` is a no-op and
> >>> `while (len)` stays true, causing the loop to spin forever at
> >>> 100% CPU with no error and no progress.
> >>>
> >>> This can be triggered when building an EROFS image from an input
> >>> file that is shorter than expected -- e.g. a truncated source
> >>> file, a pipe/FIFO that closes early, or a file being modified
> >>> concurrently during mkfs.
> >>>
> >>> Fix it by treating a zero return as an error (-EIO) so the
> >>> caller fails cleanly instead of hanging indefinitely.
> >>>
> >>> Also fix the long-standing 'pading' -> 'padding' typo in the
> >>> short-read diagnostic message of erofs_dev_read().
> >>>
> >>> Signed-off-by: Ajay Rajera <newajay.11r@gmail.com>
> >>
> >> Look good to me, will apply.
>
> This patch cause a regression which can cause build failure:
> https://github.com/erofs/erofsnightly/actions/runs/23392598146/job/68049898517
>
> It can be reproduced by:
> $ mkfs/mkfs.erofs --zfeature-bits=78 foo.erofs linux-5.4.140
>
> I dropped this patch.
>
> Thanks,
> Gao Xiang
>
> >>
> >> Thanks,
> >> Gao Xiang
>