On z/OS, instead of calling the uv__threadpool_cleanup() function from
inside uv_library_shutdown(), the destructor attribute must be used;
otherwise, tests will fail with exit code 1 and no output. Additionally,
post() does not need to be called when the destructor attribute is used.
Also adds uv__os390_cleanup() function to clean System V message queue
on z/OS.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
We observed crashes inside CFRelease in uv__get_cpu_speed on the new
Mac Book Pro (arm) hardware. The problem is that the stack got
clobbered. On the new mac hardware the returned length is 8.
For the 4 byte case, a temp variable is used to avoid having to add
endian-sensitive offsets.
Fixes: https://github.com/libuv/libuv/issues/3355
The combination EVFILT_WRITE+EV_EOF is valid and indicates that the
reader has disconnected (called `shutdown(SHUT_RD)`). Probably very rare
in practice, but this seems more correct.
Issue noticed (for UV_DISCONNECT clients of uv_poll), while doing
research for https://github.com/libuv/libuv/pull/3250.
In particular, previously the main thread would have an id of NULL,
which was then not valid to use with any other API that expected a
uv_thread_t handle.
On some streams (notably TTYs), it is permitted to continue reading
after getting EOF. So still stop reading on EOF, but allow the user to
reset the stream and try to read again (which may just get EOF).
This relaxes the constraint added in ce15b8405e.
Refs: https://github.com/libuv/libuv/pull/3006
It's been reported that copy_file_range() on a CIFS mount fails with
an EPERM error, even though the source and target files have the
appropriate permissions.
This is probably a variation on the EPERM error that libuv handles when
it tries to fchmod() a file on a CIFS mount that hasn't been mounted
with the "noperm" option, so let's handle it here too.
This commit applies minor refactoring because the "work around file
system bugs" section got quite unwieldy.
I also snuck in a bug fix where the workaround for buggy CephFS mounts
disabled copy_file_range() permanently.
Fixes: https://github.com/libuv/libuv/issues/3322
Commit e9c524aa from pull request https://github.com/libuv/libuv/pull/3149
introduced a hard dependency on `GetHostnameW`, which isn't declared
yet in mingw distributions (see
https://github.com/msys2/MINGW-packages/issues/9667).
This prevents the current version of libuv from building on many mingw
distributions, until such time the next version of mingw is released with
the correct definition for `GetHostnameW`, preventing a lot of projects
depending on libuv from building on mingw properly, as not all
distributions will update to head immediately anyway.
Instead of waiting, let's find the definition ourselves using
`GetProcAddress` and use the pointer instead.
PR-URL: https://github.com/libuv/libuv/pull/3340
Just like the Unix counterpart, uv_fs_read() and uv_fs_write() should
throw an EBADF instead of throwing an EPERM when the passed fd has not
been opened with the right flags.
Signed-off-by: Darshan Sen <darshan.sen@postman.com>
This assertion was added when req->write_buffer was a pointer. It was
then checking that write_buffer itself was not NULL. Checking that .base
is not NULL is superfluous because WriteFile will return error 998
(ERROR_NO_ACCESS) if the input buffer is invalid. This assertion fires
on zero-length writes when base==NULL&&len==0.
Fix a logic error where calling uv_fs_event_stop() from the event
callback tripped on a `handle->dir_handle != INVALID_HANDLE_VALUE`
assert in uv_fs_event_queue_readdirchanges().
Fixes: https://github.com/libuv/libuv/issues/3258
PR-URL: https://github.com/libuv/libuv/pull/3259
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
sendmmsg returns with number of packets sent which can
be less than number of packets requested to be sent. Do
not flush entire write queue and use the returned info
to partially clear the write queue.
Refs: https://github.com/libuv/libuv/issues/3129 (fixes one issue listed)
PR-URL: https://github.com/libuv/libuv/pull/3265
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Years ago, we found that various kernels (linux, macOS) were known to
fail if they try to deliver a signal during this syscall, so we prevent
that from happening. They may have fixed those issues, but it is
generally just a bad time for signals to arrive (glibc blocks them here,
for example, including some more internal ones that it won't let us
touch here).
We try to be a bit conservative, and leave many signals unblocked which
could happen during normal execution and should terminate the process if
they do. There is a small race window after the child starts before we
clear the old handlers, if the user was to send an fake signal from
elsewhere, but that should be quite unlikely.
PR-URL: https://github.com/libuv/libuv/pull/3251
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The sunos platform currently covers at least the Solaris and illumos
operating systems. Although these diverged 11 years ago they still share
some common features such as support for event ports.
illumos also has a compatibility wrapper for epoll but this is not
recommended for use over event ports. From the NOTES section of
https://illumos.org/man/5/epoll:
The epoll facility is implemented for purposes of offering
compatibility to and portability of Linux-borne
applications; native applications should continue to prefer
using event ports... In particular, use of epoll in a
multithreaded environment is fraught with peril...
Restore the event ports code so that libuv can continue to be used
on Solaris, and to avoid the problems that come with using epoll()
on illumos. The separation of epoll into src/unix/epoll.c has been
retained.
Fixes: https://github.com/libuv/libuv/issues/3241
PR-URL: https://github.com/libuv/libuv/pull/3242
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
`strnlen` was not available on Solaris 10, so provide a fallback
implementation for it.
PR-URL: https://github.com/libuv/libuv/pull/3152
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Don't use x86 inline assembly in these cases, but fall back to
__sync_fetch_and_or, similar to _InterlockedOr8 in the MSVC case.
This corresponds to what is done in src/unix/atomic-ops.h, where
ARM/AArch64 cases end up implementing cmpxchgi with
__sync_val_compare_and_swap.
PR-URL: https://github.com/libuv/libuv/pull/3236
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
While most users will likely typically call uv_close in their
uv_shutdown callback, some callers (notable nodejs) do not always do
so. This can result in libuv keeping the loop active, even though there
are no outstanding reqs left to handle.
This bug was added in 80f2f826bf, where
the premise of that commit appears to have simply been incorrect, as
demonstrated by the added test.
Refs: https://github.com/libuv/libuv/issues/3202
PR-URL: https://github.com/libuv/libuv/pull/3233
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Prior to this patch a race condition may occur in case a thread tries
to destroy the barrier while other awaiting threads were not notified.
Since the internal mutex and condition variables are destroyed this may
cause an undefined behavior as described by the man pages.
So in order to prevent such scenarios the detroy function will not wait
until all awaiting threads are finished before proceeding.
Fixes: https://github.com/libuv/libuv/issues/3102
PR-URL: https://github.com/libuv/libuv/pull/3162
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
uv_tty_set_mode() allows a tty device to be set to raw mode with
UV_TTY_MODE_RAW, which correctly sets MIN and TIME to appropriate
values for character input. When UV_TTY_MODE_IO is passed, on illumos
systems a compatibility implementation of cfmakeraw() is used that does
_not_ set MIN or TIME. As a result, consumers of IO mode will block
until a minimum of 4 bytes is available on the tty instead of just 1 as
is expected.
PR-URL: https://github.com/libuv/libuv/pull/3219
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
libuv was vulnerable to out-of-bounds reads in the uv__idna_toascii()
function which is used to convert strings to ASCII. This is called by
the DNS resolution function and can lead to information disclosures or
crashes.
Reported by Eric Sesterhenn in collaboration with Cure53 and ExpressVPN.
Reported-By: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Fixes: https://github.com/libuv/libuv/issues/3147
PR-URL: https://github.com/libuv/libuv-private/pull/1
Refs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22918
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
We also tell the compiler it is not allowed to reorder the PAUSE
instruction relative to other instructions. It is a mostly theoretical
issue, but better safe than sorry.
PR-URL: https://github.com/libuv/libuv/pull/2590
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This is an attempt to fix some resource management issues on Windows.
Win32 sockets have an issue where it sends an RST packet if there is an
outstanding overlapped calls. We can avoid that by being certain to
explicitly cancel our read and write requests first.
This also removes some conditional cleanup code, since we might as well
clean it up eagerly (like unix). Otherwise, it looks to me like these
might cause the accept callbacks to be run after the endgame had freed
the memory for them.
The comment here seems mixed up between send and recv buffers. The
default behavior on calling `closesocket` is already to do a graceful
shutdown (see
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-closesocket
with default l_onoff=zero) if it is the last open handle. The expected
behavior if there are pending reads in flight is to send an RST packet,
notifying the client that the server connection was destroyed before
acknowledging the EOF.
Additionally, we need to cancel writes explicitly: we need to notify
Win32 that it is okay to cancel these writes (so it doesn't also
generate an RST packet on the wire).
Refs: https://github.com/libuv/libuv/pull/3035
Refs: https://github.com/nodejs/node/pull/35946
Refs: https://github.com/nodejs/node/issues/35904
Fixes: https://github.com/libuv/libuv/issues/3034
PR-URL: https://github.com/libuv/libuv/pull/3036
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
These functions are declared with one set of conditionals in the
header, and defined with another set of conditionals in the c file.
This commit makes all decisions regarding `uv__{nonblock,cloexec}_ioctl`
depend on a boolean macro instead.
There's one function that expects `uv__nonblock_ioctl` to be defined,
so that bit of the function is also conditionally compiled.
PR-URL: https://github.com/libuv/libuv/pull/3163
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Still returns ENOSYS, until the send/recv functions are implemented.
PR-URL: https://github.com/libuv/libuv/pull/3040
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Just like the unix counterpart, uv_fs_read and uv_fs_write should throw
an EBADF instead of manually throwing an EPERM when the passed fd has
not been opened with the right access flags.
PR-URL: https://github.com/libuv/libuv/pull/3180
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
`uv_try_write2(stream, bufs, nbufs, send_handle)` acts like
`uv_try_write()` and extended write function for sending handles over a
pipe like `uv_write2`. It always returns `UV_EAGAIN` instead of
`UV_ENOSYS` on Windows so we can easily write cross-platform code
without special treatment.
PR-URL: https://github.com/libuv/libuv/pull/3183
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Windows API gethostname(buffer, size) return unicode string in char
array. It will cause garbled code if the host name contains non ascii
characters without cast into multi byte char.
This change keep the same encoding with the implementation on
Unix/macOS platform, which is utf-8.
Requires Windows 8 / Server 2012.
Fixes: https://github.com/libuv/libuv/issues/3148
PR-URL: https://github.com/libuv/libuv/pull/3149
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This is more clear about the intended semantics with multiple threads.
PR-URL: https://github.com/libuv/libuv/pull/3124
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
