[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] libbb: Converted safe_read to safe_write format
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2019-10-19 15:21:25
Message-ID: CAK1hOcNaTZhaFhj99N8d2kh=Gru6ENMMYgcO25vmAV7RKn4ozA () mail ! gmail ! com
[Download RAW message or body]

On Fri, Oct 18, 2019 at 11:09 PM Michael Conrad <mconrad@intellitree.com> wrote:
> > On 10/18/2019 10:54 AM, Denys Vlasenko wrote:
> > On Thu, Oct 10, 2019 at 4:35 PM Martin Lewis <martin.lewis.x84@gmail.com> wrote:
> Could you please elaborate on what was lacking in the INT_MAX part? As seen in \
> write's man page: 
> On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 \
> (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is \
> true on 
> both 32-bit and 64-bit systems.)
> 
> Wouldn't it create an issue with 64 bit systems when trying to read/write large \
> files? 
> This seemed like a change not prompted by an actually observed buggy behavior.
> 
> In fact, to my eyes
> 
> + if (count > SYS_BUFSIZE_MAX) + count = SYS_BUFSIZE_MAX;
> 
> looks like it introduces a bug. read() is always allowed to return a short count \
> however the kernel pleases, and safe_read is supposed to call it in a loop until \
> the desired size is reached or until EOF or a fatal error.

No, it's full_read(). safe_read() only loops on EINTR.

> If you truncate the count before beginning the loop, then the caller ends up with a \
> short read even though there might be more data.

Yes. safe_read() users either must code for this, or they use it in a
context where
short reads do not make sense - e.g. when you read an UDP packet,
short reads never
happen - you will always receive the full packet in one read (if your
buffer is large enough),
it will never be spuriously split by the kernel.

There is in fact some obscure standards language which also guarantees
that reading from
an ordinary file should not return spurious partial reads. IIRC Linus decided
that Linux will not honour this for very large I/O blocks.

> (not that anyone would likely have a reason to require more than 2GB in a single \
> buffer anyway…)

dd is a legitimate case, I guess. Testing dd (coreutils) 8.30, 64-bit:

dd bs=4G count=1 <FILE >FILE2

does perform a 4G-sized read syscall, gets 0x7ffff000 bytes, writes
them, and exits.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]