The implementation of IPC pipe in libuv on Windows does not properly support
async reading. This means we cannot set the more parameter without likely
causing hangs. Sorry this is yet another followup to #4511.
Fixes#4548
After commit 18266a6969, it changed to return `ENOTDIR`, which makes it
consistent with other platforms but it also can be considered a breaking
change.
Route ftruncate() system calls through io_uring instead of the thread
pool when the kernel is new enough to support it (linux >= 6.9).
This commit harmonizes how libuv checks if the kernel is new enough.
Some ops were checking against `uv__kernel_version()` directly while
others stored the result of the version check as a feature flag.
Because the kernel version is cached, and because it is more direct
than a feature flag, I opted for the former approach.
Introduced in Linux 6.6, it tells the kernel to omit the sqarray from
the ring buffer.
Libuv initalizes the array once to an identity mapping and then forgets
about it, so not only does it save a little memory (ca. 1 KiB per ring)
but it also makes things more efficient kernel-side because it removes
a level of indirection.
Delete the fs_event_error_reporting test. It fails in different ways,
most frequently on the TSan sanitizer buildbot, due to running out of
file descriptors when that is not expected, or vice versa, *not*
running out of file descriptors when that *is* expected.
The test creates a large number of event loops and expects to,
eventually, hit EMFILE but it sometimes hits it too early, and
sometimes not at all.
I don't think TSan is really responsible here, it just makes the
invalid assumption in the test itself more visible.
Fixes: https://github.com/libuv/libuv/issues/4368
Libuv stores the `struct termios` for use inside uv_tty_reset_mode().
Node.js uses said function to restore the tty to its original mode
on SIGINT or SIGTERM, when there is no opportunity to shut down the
process normally.
Track uv_tty_t handle closing, otherwise we might be trying to use a
stale termios.
The current solution is not ideal because there can be multiple handles
that refer to the same tty/pty and, for various reasons, we can't really
determine when we close the last handle. The last handle may not even be
inside the current process.
Still, all things considered, it's probably (hopefully!) an improvement
over the status quo.
Refs: https://github.com/libuv/libuv/issues/4398
Yet another followup to #4511. The functional/legacy/increment_spec.lua
test failed most of the time without this, and passes consistently with
it. It seemed unexpected this code path gets reached (perhaps imply
that the user wrote zero bytes?), but good to fix of course.
Fixes commit 58dfb6c89b from a few days ago. DWORD_PTR is 32 bits on
x86 Windows. Use the right bit count when checking the population count.
Interestingly enough, it manifested itself as double counting online
processors, presumably because the compiler emits a ROR instead of SHR.
Fixes: https://github.com/libuv/libuv/issues/4524
Use GetProcessAffinityMask() to estimate the available parallelism.
Before this commit, it simply used the number of available CPUs.
Fixes: https://github.com/libuv/libuv/issues/4520
In #4470, I accidentally copied the bug from unix, where calling
uv_stream_set_blocking can cause the whole process to hang on a read.
However, unlike unix, where libuv attempts to set the O_NONBLOCK flag in
uv_pipe_open (as long as the handle never gets passed to uv_spawn), the
NT kernel is not capable of enabling OVERLAPPED operation later (but
fortunately, it also cannot disable it later too).
This implementation might be good to copy to unix (using FIONREAD) to
address the same bug that happens there if the user has called uv_spawn
or uv_stream_set_non_blocking on this handle in the past.
Establishes a user event for kqueue to eliminate the overhead
of the pipe and the system call read(2) per wakeup event.
---------
Signed-off-by: Andy Pan <i@andypan.me>
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Autobinding is a feature that lets the kernel pick a name for the
abstract socket, instead of userspace having to provide one.
Two bugs that this change exposed are also fixed:
1. strlen(sa.sun_path) can read past the end if the file path is exactly
sizeof(sa.sun_path) long (use memchr instead), and
2. don't return UV_ENOBUFS for abstract sockets when the buffer is
exactly large enough to hold the result; per commit e5f4b79809,
abstract socket names are not zero-terminated
Refactor / cleanup arithmetic for unix -> win filetime conversion
in order to avoid multiplication overflow.
Fixes:
```
src/win/fs.c:106:48: runtime error: signed integer overflow: 1702781567 * 10 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/fs.c:106:48 in
```
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The SQPOLL io_uring instance wasn't providing consistent behaviour to
users depending on kernel versions, load shape, ... creating issues
difficult to track and fix. Don't use this ring by default but allow
enabling it by calling `uv_loop_configure()` with
`UV_LOOP_ENABLE_IO_URING_SQPOLL`.
MSVC does not actually support ubsan. There is a long-standing ticket
requesting this:
https://developercommunity.visualstudio.com/t/add-support-for-ubsan/840750
There are no known compilers that currently accept the
`/fsanitize=undefined` spelling. clang-cl accepts `-fsanitize...`,
same as regular clang.
Also passes no-sanitizer-recover so that tests actually fail.
Fix various ubsan-detected errors, including:
* win: fix req-inl.h ubsan failure
Don't use CONTAINING_RECORD macro from WinSDK, as it doesn't use the
right trick which avoids member access on null pointer.
Fixes:
```
src/win/req-inl.h:86:10: runtime error: member access within null pointer of type 'uv_req_t' (aka 'struct uv_req_s')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior D:/a/libuv/libuv/src/win/req-inl.h:86:10
```
* test: fix ubsan failure on udp_ref3
Don't call functions through different function type.
Fixes:
```
src/win/udp.c:537:5: runtime error: call to function req_cb through pointer to incorrect function type 'void (*)(struct uv_udp_send_s *, int)'
test\test-ref.c:66: note: req_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/udp.c:537:5 in
```
* win: fix process-stdio.c ubsan failure
When accessing HANDLEs within the stdio buffer, use memcpy / memset in order to respect alignment.
Fixes:
```
src/win/process-stdio.c:197:5: runtime error: store to misaligned address 0x0230ee72d107 for type 'HANDLE' (aka 'void *'), which requires 8 byte alignment
0x0230ee72d107: note: pointer points here
00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd fd fd fd fd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/process-stdio.c:197:5 in
```
* win: fix getaddrinfo.c ubsan failure
Reworks buffer alignment handling to respect requirements.
Fixes:
```
src/win/getaddrinfo.c:157:23: runtime error: member access within misaligned address 0x0290e4c6a17c for type 'struct addrinfo', which requires 8 byte alignment
0x0290e4c6a17c: note: pointer points here
00 00 00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/getaddrinfo.c:157:23 in
```
* win: fix pipe.c ubsan failure
Changes "random" representation from pointer to number.
Fixes:
```
src/win/pipe.c:234:11: runtime error: applying non-zero offset to non-null pointer 0xffffffffffffffff produced null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/pipe.c:234:11 in
```
* unix: fix stream.c ubsan failure
Avoids performing pointer arithmetic on null pointer.
Fixes:
```
src/unix/stream.c:701:15: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/runner/work/libuv/libuv/src/unix/stream.c:701:15 in
```
This fixes a race condition if multiple threads are reading from the
same NamedPipe, which could previously lead to a deadlock situation. We
also substantially improve performance now also, since the PeekFile
call is unnecessary overhead with this change. This API was added in
Windows Vista.
Related to #4467, though doesn't address any of the problems there. I
believe that someone could now implement uv__pipe_try_write using
this same code pattern however.
Windows added a new API for file information, which doesn't have to
open the file thus greatly improving performance:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyname
The stat functions are already covered by tests, so no test was added
here. I considered comparing the result of old and new code, but that
would require exposing internal fs functions, and we would be testing
Windows functionality, not libuv.
Register the eventfd with EPOLLET to enable edge-triggered notification
where we're able to eliminate the overhead of reading the eventfd via
system call on each wakeup event.
When the eventfd counter reaches the maximum value of the unsigned 64-bit,
which may not happen for the entire lifetime of the process, we rewind the
counter and retry.
This optimization saves one system call on each event-loop wakeup,
eliminating the overhead of read(2) as well as the extra latency
for each epoll wakeup.
If the corresponding environment variables are empty, the
uv_us_homedir() and uv_os_tmpdir() return garbage values. The reason
for this situation is the Windows API which doesn't return an error
even if the path is empty.
This PR fixes this problem by checking the return value of the API
call. If it is not an error and the length of the value is less than 3,
uv_us_homedir() and uv_os_tmpdir() will return UV_ENOENT.
Fixes: https://github.com/libuv/libuv/issues/2328
