[Toybox] [PATCH] sendfile_len: don't check errno unless we set it.

[enh]

On Fri, Mar 12, 2021 at 12:28 AM Rob Landley <rob at landley.net> wrote:

> On 3/11/21 11:01 AM, enh via Toybox wrote:
> > Found by inspection.
>
> Many moons ago I hit a "zero length read that wasn't end of stream" when a
> pipeline was interrupted by a signal. I'm pretty sure the kernel guys have
> fixed
> it since, but at the time it was distinguished by EAGAIN and led me down
> the
> path of trying to figure out what SA_RESTART actually meant.
>

it isn't possible on Linux --- syscalls on any commercially relevant
architecture don't have a separate "-1 for failure" and "errno" (MIPS is
the only exception i know of). so if the kernel were bogusly returning 0,
by definition the libc couldn't set errno because it got 0 back. here's the
snippet from the end of bionic's arm32 syscall(3), which is the same as the
code that's inlined into all the generated assembler system call stubs:

    cmn     r0, #(MAX_ERRNO + 1)
    bxls    lr
    neg     r0, r0
    b       __set_errno_internal # (tail call that will do the `bx lr`)

Thus I'd be more comfortable if we set errno to 0 before the call and then
> tested <1 && EAGAIN. Old scars. :)
>

since they're system calls there's no chance for libc to clobber errno on
its own, i think that's fine too, but i think you're misremembering
something and don't actually need this. (unless you had a _libc_ bug at
some point.)


> I'm not finding the original, but I am finding one of my follow-up
> questions:
>
>   http://lkml.iu.edu/hypermail/linux/kernel/0701.2/0777.html
>
> Um, let's see... no, this was a different bug:
>
>   http://lkml.iu.edu/hypermail/linux/kernel/0503.3/1756.html
>
> The bug I hit wasn't involving user mode linux, it was corrupting pipelined
> tarballs when you suspended and then resumed the pipeline. It basically
> threw in
> one O_NONBLOCK cycle in there, or something?
>
> (Sigh. It's a pity Google can't "show oldest results first". Or that
> archive.org
> isn't properly searchable...)
>
> Also not it: http://lkml.iu.edu/hypermail/linux/kernel/0104.1/1008.html
>
> Ha, I'd forgotten about
> http://lkml.iu.edu/hypermail/linux/kernel/0206.2/0835.html (which got WAY
> more
> feasible when container support started being merged 8 years later)...
>
> I'll stop now.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210312/4a3be5ec/attachment-0001.htm>