It is used only once, and the name is supposed to suggest "device that
is not based on the filesystem". This intended meaning is clearer if
we just replace is_auto_device() by its definition at the place where
it's used.
The sigpending mechanism failed to check if the pending signal was a
process-wide signal, or a signal for the curent thread. Fix that by
adding a matching conditional to wait_sig's __SIGPENDING code.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far sig_send's return type is int. The problem with this is
that sig_send returns a sigset_t on __SIGPENDING, and sigset_t
is defined as long type. So the function only returns the lower
32 bit of sigset_t, which is fine on 32 bit, but casts away the
pending RT signals on 64 bit.
Fix this by changing the return type of sig_send to sigset_t, so
as not to narrow down the sigset when returning from handling
__SIGPENDING. Make sure to cast correctly in all invocations
of sig_send.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Have sched_getaffinity() interface like glibc's, and provide an
undocumented internal interface __sched_getaffinity_sys() like the Linux
kernel's sched_getaffinity() for benefit of taskset(1).
Add a function timerfd_tracker::enter_critical_section_cancelable,
which is like enter_critical_section but honors a cancel event. Call
this when a timer expires while the timerfd thread is in its inner
loop. This avoids a deadlock if timerfd_tracker::dtor has entered its
critical section and is trying to cancel the thread. See
https://cygwin.com/ml/cygwin/2019-06/msg00096.html.
This patch set implements the Linux syscalls sched_getaffinity,
sched_setaffinity, pthread_getaffinity_np, and pthread_setaffinity_np.
Linux has a straightforward view of the cpu sets used in affinity masks.
They are simply long (1024-bit) bit masks. This code emulates that view
while internally dealing with Windows' distribution of available CPUs among
processor groups.
Make it a manual reset event. It's only used once to allow a reader
to open, and there's no reason to ever reset it. Defensively set it
when a client connection is recorded, even though it should be set by
the writer that connected.
Call NtReadFile directly instead of calling fhandler_base::raw_read.
In addition to being simpler, this gives us access to the return value
from NtReadFile.
Add a method fifo_client_handler::pipe_state that queries Windows for
the state of a pipe instance. Use this to help terminate the
listen_client thread cleanly.
If the last client handler is useless, delete it instead of declaring
it invalid.
fhandler_fifo::close could be called from a signal handler or another
thread at a time when another function is holding the fifo_client
lock. This could prevent the listen_client thread from acting on the
thread termination event. Avoid a deadlock by calling
fifo_client_unlock at the beginning of fhandler_fifo::close.
libX11 provides <X11/Xlocale.h>. The build of libX11 itself adds
include/X11 to the compiler's include path. This results in a name
collision with /usr/include/xlocale.h on case-insensitive filesystems.
Commit 90e35b1eb3 renamed sys/_locale.h to xlocale.h in March 2017 under
the assumption that we should provide the locale_t type in the same file
as on Linux, FreeBSD, and Darwin.
A few weeks later (June 2017), glibc removed the xlocale.h file in favor
of bits/types/locale_t.h, which shouldn't be included directly anyway.
For reference and the reasoning, see
https://sourceware.org/git/?p=glibc.git;a=commit;h=f0be25b6336d
Given the above, revert 90e35b1eb3 and
fix additional usage of xlocale.h.
32 bit Cygwin performs a POSIX-compatible mapping after EOF which
is not supported in this form on Windows. The 64 bit Windows
kernel never supported the AT_ROUND_TO_PAGE mapping flag, so we
couldn't page-aligned map the space right after the file's EOF.
So mapping beyond EOF was disabled in 64 bit Windows and WOW64.
However, if mmap works, a matching munmap should work as well,
*and* it should not accidentally unmap unrelated memory.
Therefore we enable mapping beyond EOF on 64 bit as well. Since
that mapping is always 64K aligned, the are between the last file
page and the next 64K allocation boundary will be unallocated.
There's no way around that.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When using NtCreateFile when creating a directory that already exists,
it will correctly return 'STATUS_OBJECT_NAME_COLLISION'.
However using this function to create a directory (and all its parents)
a normal use would be to start with mkdir(‘/cygdrive/c’) which translates
to ‘C:\’ for which it'll instead return ‘STATUS_ACCESS_DENIED’.
64 bit Windows started out with a 44 bit address space due to a
restriction of the AMD64 CPUs at the time. Starting with Windows
8.1, these CPUs are not supported anymore and Windows switched to
the full 48 bit address space supported by AMD64.
Cygwin didn't follow suit yet so mmaps are still restricted to
the lower 44 bit address space. Fix that by using a system-specific
upper address for mmap allocations, 44 bit up to Windows 8, 48 bit
starting with Windows 8.1.
While at it, move the heap by another 8 Gigs to leave some space
for a potential extension of DLL address space, and restrict the
mmap lower address so the heap can grow to 32 Gigs before colliding
with mmaps.
Do not remember the child before it was successfully initialized, or we
would need more sophisticated cleanup on child initialization failure,
like cleaning up the process table and suppressing SIGCHILD delivery
with multiple threads ("waitproc") involved. Compared to that, the
potential slowdown due to an extra yield () call should be negligible.
Pause the child process after performing fork fixups even if there were
no dynamically loaded dlls with extra data/bss transfers to wait for.
This allows the parent process to cancel the current fork call even if
the child process was successfully initialized already.
This is a preparation for when the parent does remember the child no
earlier than after successful child initialization.
Querying the ntlength and existence of the /var/run/cygfork directory in
the very first Cygwin process should not use nt_max_path_buf, as that
one is used by dll_list::alloc already.
NtQueryVirtualMemory for MemorySectionName may return some old path even
if the process was just started, for when some directory in between was
renamed - maybe because the NT file cache is hot for the old path still.
This was seen during gcc bootstrap, returning a MemorySectionName of
".../gcc/xgcc.exe" even if started as ".../prev-gcc/xgcc.exe", where the
directory rename from "gcc" to "prev-gcc" was done the moment before.
As we stat the module's real file right after loading now, there is no
point in using NtQueryVirtualMemory with MemorySectionName any more, and
we can use what GetModuleFileName returned instead.
-Add vendor identification
-Support in get_cpu_cache
Background:
Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture
between AMD and Haiguang Information Technology Co.,Ltd., aims at
providing high performance x86 processor for China server market.
Its first generation processor codename is Dhyana, which
originates from AMD technology and shares most of the
architecture with AMD's family 17h, but with different CPU Vendor
ID("HygonGenuine")/Family series number(Family 18h).
Related Hygon kernel patch can be found on:
http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.puwen@hygon.cn
Signed-off-by: Jinke Fan <fanjinke@hygon.cn>
There's no longer a need to consider the connect_evt after fork/exec.
After stopping the listen_client thread, all client handlers should be
in the fc_connected or fc_invalid states, so their connect_evt members
won't be used again.
Also remove code in fhandler_fifo::dup that just repeats things
already done in stop_listen_client.
Add a method fhandler_fifo::check_listen_client_thread that checks
whether the thread is running. Use it in raw_read instead of just
testing the handle listen_client_thr.
On exit from the listen_client thread, make sure there's no pending
FSCTL_PIPE_LISTEN request. Otherwise we might get a client connection
after restarting the thread, and we won't have a handle for
communicating with that client.
Remove the retry loop in the case of STATUS_PIPE_LISTENING; that case
shouldn't occur.
Remove the now-unused fc_connecting value from
fifo_client_connect_state.
It's now up to the caller to pass a handle to open_pipe and, if
desired, to call set_handle on return.
This will be useful for a future commit, in which we will open a
client connection without setting an io_handle.
When opening a duplexer, open a client connection to the first client
handler. Previously we gave the duplexer a bogus write handle, which
was just a duplicate of the first client handler's handle. This meant
that we had a pipe server with no clients connected, and all I/O
attempts failed with STATUS_PIPE_LISTENING.
Extend the last fcntl change to duplexers.
Remove a now unused fifo_client_handler constructor, as well as the
long unusued method fifo_client_handler::connect.
Don't create the pipe in duplex mode; the server handle will only be
used for reading.
NtQueryVirtualMemory for MemorySectionName does not reliable return the
changed dll file name when another process does move the file around,
and we may end up creating forkable hardlinks to wrong dll files.
So query the file id when loading the dll rather than before fork.
Make stat_real_file_once a method of struct dll, to be more flexible on
where to use. Also, debug print memory section name queried for a dll.
This is a preparation to query the file id when loading the dll.
The blocking mode of the Windows pipe underlying a writer is set to
match that of the writer itself when the latter is opened. Define
fhandler_fifo::fcntl to keep the pipe and the writer in sync if the
blocking mode is changed via fcntl.
Use 'waitret' instead of 'ret' for the return value of cygwait, since
there is already a different 'ret' variable in use. The previous
double use of 'ret' was legal because of scoping rules, but possibly
confusing.
Commit debdfb8b, "Cygwin: AF_UNIX: Rework internal methods to return
HANDLEs", removed a set_handle call. As a result, the attempt to
exchange socket info fails with "Invalid Handle".
Fix this by moving the send_sock_info call into a new 'xchg_sock_info'
method, which is then invoked by the callers of open_pipe if
necessary, after they have called set_handle.
Also, call recv_peer_info in addition to send_sock_info when
exchanging socket information.
Remove the last argument of open_pipe, which is no longer needed.
Adjust all callers.
- Return HANDLE value of just opened/created objects
- open_pipe does not set the fhandler io_handle. The caller
is now resonsible how to use the handle.
- Rename create_file/open_file to create_socket/open_socket
- Drop sockaddr_in validity check from connect. It's performed
in open_socket anyway.
* Change default fallback for failed winsock error -> POSIX error
mappings to EACCES, which is a valid errno for more socket-related
syscalls.
* Added a few previously missing entries to the wsock_errmap table
that have obvious POSIX errno.h analogues.
Add methods need_fixup_before, init_fixup_before, and
fixup_before_fork_exec to accomplish this. Stopping the thread makes
sure that the client handler lists of the parent and child remain in
sync while the forking/execing is in progress.
Don't use the same i/o handle for the first client handler as is used
for the fhandler itself; this can lead to a later attempt to close the
same handle twice. Instead use a duplicate.
* Pre-release version still reporting kernel version 6.4.
* Windows 10 1511 is out of support since 2017-10-10.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Define fhandler:fifo::fixup_after_exec, which sets listen_client_thr
and lct_termination_evt to NULL. This forces the listen_client thread
to restart on the first attempt to read after an exec. Previously the
exec'd process could hang in fhandler_fifo::raw_read.
Remove fifo_client_handler::connect and move its code into
listen_client_thread. That way we can check the return status when a
client handler's connect_evt is signaled. Previously we incorrectly
assumed there was a successful connection.
Also simplify listen_client_thread in the following ways:
- Replace fhandler_fifo::disconnect_and_reconnect by a new
delete_client_handler method. Now we just delete invalid client
handlers rather than trying to re-use them.
- Try to maintain a client handler list that consists of connected
client handlers and exactly one that is listening for a connection.
This allows us to call WaitForMultipleObjects with only two wait
objects.
- Remove 'dummy_evt' from the fifo_client_handler struct; it is no
longer needed.
- On exit from listen_client_thread, delete the "extra" (listening)
client handler. Otherwise there could be a connection that doesn't
get recorded in the client handler list. This could happen when a
file descriptor is being duplicated.
Don't set the write end of the pipe to non-blocking mode if the FIFO
is opened in blocking mode.
In fhandler_fifo::raw_write in blocking mode, wait for the write to
complete rather than returning -1 with EAGAIN.
If the amount to write is large, write in smaller chunks (of size
determined by a new data member max_atomic_write), as in
fhandler_base_overlapped.
For convenience, add two new NTSTATUS codes, STATUS_THREAD_SIGNALED
and STATUS_THREAD_CANCELED, to ntdll.h.
After copyto is called, make the new fhandler's pipe_name point to the
new fhandler's pipe_name_buf, which is a *copy* of the old fhandler's
pipe_name_buf. Previously, get_pipe_name would return the wrong
result after a clone/dup, causing create_pipe_instance and open_pipe
to fail.
Also, stop the listen_client thread when cloning. Otherwise the
thread can keep accepting connections that the cloned fhandler won't
know about.
Do this via a new method fhandler_fifo::stop_listen_client, extracted
from fhandler_fifo::close.
Make read_ready a manual reset event. It should always be set shortly
after startup of the listen_client thread and remain set until the
thread terminates. (We don't want writers to connect without being
recorded in the client handler list.)
Remove the unnecessary code that checks for read_ready when a reader
is opening.
Add data members 'reader', 'writer', and 'duplexer' to the
fhandler_fifo class. Set them in fhandler_fifo::open. ('duplexer'
replaces the previous '_duplexer'.)
This will be useful in later commits.
The word "client" suggests something that holds a handle to the client
side of the pipe (in Windows terminology). But our
fifo_client_handlers hold a handle the server side of the pipe, and
they *connect* to clients.
Rather than newest last write time of all dlls loaded, use the forking
process' windows pid and windows thread id as directory name to create
the forkable hardlinks into. While this may create hardlinks more
often, it does avoid conflicts between dlls not having the newest last
write time.
* Changes error handling to allow /proc/[pid]/ virtual files to be
empty in some cases (in this case the file's formatter should return
-1 upon error, not 0).
* Better error handling of /proc/[pid]/stat for zombie processes:
previously trying to open this file on zombie processes resulted
in an EINVAL being returned by open(). Now the file can be read,
and fields that can no longer be read are just zeroed.
* Similarly for /proc/[pid]/statm for zombie processes.
* Similarly for /proc/[pid]/maps for zombie processes (in this case the
file can be read but is zero-length, which is consistent with observed
behavior on Linux.
- After 24 bit color support patch, arrow keys and function keys
do not work properly in native console applications if they
are started in cygwin console. This patch fixes this issue.
In case SA_SIGINFO flag is given, the signal handler may change
the context and the application is supposed to pick up from the
changed context. So far we don't do that, so the context given
to the signal handler is basically read-only, unless the signal
handler calls setcontext or swapcontext.
For a start, restore the thread's signal mask from the uc_sigmask
value of the context given to the signal handler.
If that's feasible for Cygwin, we restore the entire context from
the context changed by the signal handler in a followup patch.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
commit d1be0a59d4,
"Cygwin: winpids: Fix getting process multiple times"
fixed duplicate processes in ps -W output, but it fixed
the symptom, not the cause. It also didn't fix the problem
that the `ps' process itself may show up twice in its own
output.
This patch fixes it. The spawn worker only deleted the
"winpid.PID" symlink of the current process if the child is
a non-Cygwin process, under the assumption that the exec'ing
process exits anyway. However, the Window in which both
winpid.PID symlinks point to the same cygpid.PID area is just
too long. The spawn worker now also deletes its own winpid.PID
symlink if the exec'ed process is a Cygwin process.
Additionally the fix from d1be0a59d4
is now performed on the calling process, too.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Ken Brown
Corinna Vinschen
Mark Geisert
Ben Wijen
Michael Haubenwallner
Jinke Fan
Erik M. Bray
Takashi Yano