The close_range(2) syscall is available since Linux kernel v5.9,
with additional functionality of CLOSE_RANGE_CLOEXEC since v5.11.
No tests are required since this is a bare syscall.
Change-Id: I410470e3713e2005cc7acf24d1347938fe05ef63
Reviewed-on: https://go-review.googlesource.com/c/sys/+/301409
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Occassionaly TestPoll fails on some builders due to Poll getting
interrupted:
--- FAIL: TestPoll (0.00s)
syscall_unix_test.go:516: Poll: unexpected error: interrupted system call
FAIL
FAIL golang.org/x/sys/unix 0.956s
Fix this by retrying Poll in case of EINTR, same as CL 207861 did in
TestSelect.
Change-Id: I78ada14d7409e6cde852d76abd5a9a1b1bb645d2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298189
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Alex copied this from a temporary thing I had written for the runtime
package. In runtime, you can't really access other packages like
syscall, so everything has to be very manual. But in x/sys, we can do
things properly. So this reimplements the function in a more straight
forward way.
Change-Id: I1634904bb1e10f33252954ce02d4b17ae56592e5
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298830
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In anticipation of the next commit which adds win32 pipe APIs, add some
of the foundational NT APIs for that, which will be required for making
a robust Go pipe library. Also add a simple test case.
Change-Id: I898bd6c5265a8939a7f05a24c4d9b22941dc56b7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298171
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It turns out that the proc thread update function doesn't actually
allocate new memory for its arguments and instead just copies the
pointer values into the preallocated memory. Since we were allocating
that memory as []byte, the garbage collector didn't scan it for pointers
to Go allocations and freed them. We _could_ fix this by requiring that
all users of this use runtime.KeepAlive for everything they pass to the
update function, but that seems harder than necessary. Instead, we can
just do the allocation as []unsafe.Pointer, which means the GC can
operate as intended and not free these from beneath our feet. In order
to ensure this remains true, we also add a test for this.
Updates golang/go#44662.
Change-Id: Iaa8b694a6682cc1876879632c7ba068e47b8666d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/297331
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The prior function updated the TEB's LastStatus member, which is not
what we want to be doing here. It's also not consistent with Microsoft's
own Go code for their pipe library, which properly uses the "NoTeb"
variant like this commit.
For good measure, we add a simple test case to make sure these paths are
being exercised.
Change-Id: I4080898f704bdc93a6048001b06ffce516fb412d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298169
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
All references to "Errno" go through the syscalldot function, which
prepends "syscall." if the generation target is not in the syscall
package. Similarly so, we need a windowsdot function to prepend
"windows." to NTStatus.
Change-Id: I86affcf0155632ed5848ebabca97d175a041c6c3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298170
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The same symbol name might be defined multiple times with different
function names or signatures. In that case, it's an error to redefine
the proc variable. So deduplicate these before printing.
Change-Id: I7a636cd44fb1ea6f51840ef3924d6316e266faa0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/288332
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The native NT API returns error values from a different namespace as the
usual Win32 one. This means it needs to be typed differently. This
commit adds broad support for using NTSTATUS values in a new type called
NTStatus.
First we add the type as a basic uint32. Then we add all of the
predefined constants from ntstatus.h, by augmenting mkerrors.bash to do
automatic extraction. There's a convenece way to convert an NT error to
a Win32 error, so we add the NTStatus.Errno() function. Since NTStatus
is an error type, we define an Error() function that returns a string by
asking ntdll.dll for its contents, in the exact same way that
syscall.Errno.Error() does, by calling FormatMessage. Since functions
need to actually use this, we add the rule that if a `//sys` declaration
returns an error value called "ntstatus", then the type underlying the
error interface is an NTStatus instead of an Errno. Finally we fix one
function that was returning an error interface of an Errno rather than
an NTStatus.
Change-Id: I06296b9563bbec526759d12a19f13ac6ad46dcc3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/297330
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test introduced in CL 284352 breaks on several builders, either
with IoctlFileDedupeRange returning ENOTTY (as already seen for android
in the TryBot run) or returning EINVAL in the FileDedupeRange.Status
field. Both seem to indicate that the underlying filesystem doesn't
support deduplication, so skip the test in these cases.
Also rename the test to indicate the func it is testing.
Change-Id: I29553a5fc95f98335cb233f05d4c2dfb5640dc4c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/295911
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
The pipe2 on dragonfly still expects an fds array as an argument, but
does not use it to return the file descriptors. Just pass the argument
but ignore its value. This way the flags argument will be respected
correctly.
Change-Id: Id340653040999f31074eae01e9be4ea2088abae5
Reviewed-on: https://go-review.googlesource.com/c/sys/+/295870
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
Updates golang/go#44538.
Change-Id: Ie1f66de11001cf9c8195afaa61f003a86f821a95
Reviewed-on: https://go-review.googlesource.com/c/sys/+/295174
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change adds (most) of the ioctl API for the Linux HIDRAW interface.
Reading and writing non-numbered HID reports is done using the read and
write system calls respectively.
Some of the HIDIOC* request numbers are exported directly while others
are kept unexported. This is because some of the #defines require a len
attribute that doesn't have a specific well defined value.
Wrapper types are added for most of the request numbers as is standard.
No wrapper is added for HIDIOCGRDESCSIZE as it would just be
IoctlGetUint32.
The HIDIOC[GS]FEATURE, HIDIOC[GS]INPUT and HIDIOC[GS]OUTPUT request
numbers, which are required for numbered HID reports, are entirely
ommitted as the len attribute has to be a runtime variable. These could
be added later by doing something like
`HIDIOCGFEATURE(0) | (len << _IOC_SIZESHIFT)`,
with care taken that len doesn't overflow _IOC_XSIZEMASK.
Outdated documentation for the HIDRAW interface is available at:
https://www.kernel.org/doc/Documentation/hid/hidraw.txt.
Change-Id: I2ae5060f0f46150f6fb52959c2e55f50927c1f69
Reviewed-on: https://go-review.googlesource.com/c/sys/+/289169
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
There is some inconsistent use of tabs and spaces in the //sys and
//sysnb lines. However, the large majority is using tabs, so use these
consistently.
Also change the regexp in mksyscall*.go to only accept tabs going
forward.
Change-Id: I78944e88b5fec11c1bd1d103cea894bc5109da56
Reviewed-on: https://go-review.googlesource.com/c/sys/+/283596
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This fixes the name of a struct to match Microsoft's documentation.
It also reverts a change I made in the last patchset of CL 285714. The
idea there was that a Go bool would suffice for a win32 BOOL, because of
little endian. But in fact, a value of 0xff000000 would be treated as
false by Go but true by C, which is a problem. So this changes to using
a vanilla int32 type, which matches the C "int" used in the Microsoft
headers.
Change-Id: Id7cd306e916b3754e8dfe32bf11ec30cad3a13b4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/285717
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
