<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 12:28 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/11/21 11:01 AM, enh via Toybox wrote:<br>
> Found by inspection.<br>
<br>
Many moons ago I hit a "zero length read that wasn't end of stream" when a<br>
pipeline was interrupted by a signal. I'm pretty sure the kernel guys have fixed<br>
it since, but at the time it was distinguished by EAGAIN and led me down the<br>
path of trying to figure out what SA_RESTART actually meant.<br></blockquote><div><br></div><div>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:</div><div><br></div><div> cmn r0, #(MAX_ERRNO + 1)<br> bxls lr<br> neg r0, r0<br> b __set_errno_internal # (tail call that will do the `bx lr`)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thus I'd be more comfortable if we set errno to 0 before the call and then<br>
tested <1 && EAGAIN. Old scars. :)<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not finding the original, but I am finding one of my follow-up questions:<br>
<br>
<a href="http://lkml.iu.edu/hypermail/linux/kernel/0701.2/0777.html" rel="noreferrer" target="_blank">http://lkml.iu.edu/hypermail/linux/kernel/0701.2/0777.html</a><br>
<br>
Um, let's see... no, this was a different bug:<br>
<br>
<a href="http://lkml.iu.edu/hypermail/linux/kernel/0503.3/1756.html" rel="noreferrer" target="_blank">http://lkml.iu.edu/hypermail/linux/kernel/0503.3/1756.html</a><br>
<br>
The bug I hit wasn't involving user mode linux, it was corrupting pipelined<br>
tarballs when you suspended and then resumed the pipeline. It basically threw in<br>
one O_NONBLOCK cycle in there, or something?<br>
<br>
(Sigh. It's a pity Google can't "show oldest results first". Or that <a href="http://archive.org" rel="noreferrer" target="_blank">archive.org</a><br>
isn't properly searchable...)<br>
<br>
Also not it: <a href="http://lkml.iu.edu/hypermail/linux/kernel/0104.1/1008.html" rel="noreferrer" target="_blank">http://lkml.iu.edu/hypermail/linux/kernel/0104.1/1008.html</a><br>
<br>
Ha, I'd forgotten about<br>
<a href="http://lkml.iu.edu/hypermail/linux/kernel/0206.2/0835.html" rel="noreferrer" target="_blank">http://lkml.iu.edu/hypermail/linux/kernel/0206.2/0835.html</a> (which got WAY more<br>
feasible when container support started being merged 8 years later)...<br>
<br>
I'll stop now.<br>
<br>
Rob<br>
</blockquote></div></div>