Re: [PATCH v2 1/4] ntfs: add named stream ioctls support

[Namjae Jeon]

On Wed, Oct 7, 2026 at 11:07 AM CharSyam <charsyam@xxxxxxxxx> wrote:
>
> Hi Namjae,
>
> I found an error-reporting issue in NTFS_IOC_STREAM_READ. The underlying
> bug predates this patch: ntfs_inode_attr_pread() breaks when
> read_mapping_folio() fails without saving PTR_ERR(folio). It therefore
> returns the number of bytes read before the error. The new ioctl treats
> that nonnegative result as success and reports it in bytes_returned.
>
> An I/O error on the first 4 KiB can appear as a successful zero-byte
> read; an error on the second 4 KiB can appear as a successful 4 KiB
> read. A caller copying or backing up the stream may interpret either
> result as EOF and stop, even though the stream is larger. The on-disk
> stream size is unchanged.
>
> I tested this in QEMU with a 16 MiB named stream filled with 'A' and
> an 8 KiB read at offset 0. Using blkdebug to inject EIO on the first
> 4 KiB, the ioctl returned success with bytes_returned=0. Injecting EIO
> on the second 4 KiB returned success with bytes_returned=4096. After
> the change below, both cases return -EIO and copy no stream data to
> userspace. A retry without the injected fault reads all 8192 bytes.
> A read crossing the actual EOF still succeeds with a short count of
> 4096 bytes.
>
> Please propagate the folio error, including when earlier pages in the
> same request were read:
>
>         folio = read_mapping_folio(mapping, index, NULL);
>         if (IS_ERR(folio)) {
>                 err = PTR_ERR(folio);
>                 break;
>         }
>
> The existing `return err ? (s64)err : total;` then returns the error.
> The ioctl already copies its temporary kernel buffer to userspace only
> on success, so it will not expose partial data on this failure. The
> UAPI should also state that a successful short read indicates EOF and
> that a read error copies no stream data.
Okay, I will fix it in v3.
Thanks for the review!