Musl pipe2 missing

[adrian-budau]

Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well x86_64-unknown-linux-musl and arm-unknown-linux-musleabi(hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands.

The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones).

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f004af72249cff12f048b4ba16fc4d6e

Running with strace proves that pipe2 is not used, and that instead the fallback is:

[pid 11648] pipe( <unfinished ...>                                                                  
[pid 11647] ioctl(9, FIOCLEX <unfinished ...>                                                                                                                                                                     
[pid 11648] <... pipe resumed> [11, 12]) = 0                                                                                                                                                                       
[pid 11647] <... ioctl resumed> )       = 0                                                                            
[pid 11648] ioctl(11, FIOCLEX <unfinished ...>                                                         
[pid 11647] ioctl(10, FIOCLEX <unfinished ...>   

vs the x86_64-unknown-linux-gnu target:

[pid  2128] pipe2( <unfinished ...>                                                                                                                                                                               
[pid  2127] pipe2( <unfinished ...>                                                                                                                                                                               
[pid  2128] <... pipe2 resumed> [6, 7], O_CLOEXEC) = 0                                                                                                                                                            
[pid  2127] <... pipe2 resumed> [8, 9], O_CLOEXEC) = 0                

Versions affected:

• 1.30.1
• 1.31.0 - Current stable
• rustc 1.32.0-nightly (4a45578 2018-12-07)

Later Edit:
Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).

[eddyb]

cc @alexcrichton

[adrian-budau]

Did some investigation regarding this bug:
The culprit seems to be: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/weak.rs

More specifically the following comment: “It assumes that
//! we've been dynamically linked to the library the symbol comes from, but that
//! is currently always the case for things like libpthread/libc.”

Well this is not the case for musl target binaries.

pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing.

https://github.com/esmil/musl/blob/master/src/unistd/pipe2.c

A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets.

I could do it myself if this sounds resonable.

[alexcrichton]

Thanks for the report @adrian-budau! Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!

[adrian-budau]

Is this kind of what you had in mind? master...adrian-budau:syscall_fix_musl

I wanna know if I should go like this, or I understood you wrong.