Re: zram: block_state returns premature EOF with short read buffers

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (26/09/29 13:13), Sergey Senozhatsky wrote:
> > However, reading the same file with a one-byte buffer returns zero
> > bytes:
> > 
> >         # python3 - <<'PY'
> >         import os
> > 
> >         path = "/sys/kernel/debug/zram/zram0/block_state"
> >         fd = os.open(path, os.O_RDONLY)
> > 
> >         try:
> >             for attempt in range(3):
> >                 data = os.read(fd, 1)
> >                 offset = os.lseek(fd, 0, os.SEEK_CUR)
> >                 print(
> >                     f"read {attempt}: bytes={len(data)}, "
> >                     f"data={data!r}, offset={offset}"
> >                 )
> >         finally:
> >             os.close(fd)
> >         PY
> > 
> >         read 0: bytes=0, data=b'', offset=0
> >         read 1: bytes=0, data=b'', offset=0
> >         read 2: bytes=0, data=b'', offset=0
> > 
> > The file contains a valid record, but the short-buffer reads return zero
> > bytes repeatedly and the file position remains unchanged.
> > 
> > This does not appear to be a memory-safety or security issue. The
> > observed impact is that userspace readers using a short buffer receive
> > zero bytes and cannot make progress through this debugfs file.
> > 
> > Could you please confirm whether this short-read behavior is expected
> > for block_state?
> 
> I don't think I tend to see this as a problem.  Why would anyone do
> a 1-byte (or any other tiny buffer) read in a loop?  block_state holds
> a lot of data, just pass a huge buffer maybe?

If we can find a real-world library/tool (rust, go, etc.) that does those
short reads then I guess we might want to fix this.