Right now we're casting uint64_t's to native pointers. This isn't
causing any problems right now, but if we want to provide a 32-bit
compatibility layer that works on 64-bit systems as well, this will
cause problems. Casting a uint32_t to a 64-bit pointer throws a compiler
error.
Introduce a TO_PTR() macro that casts the value to uintptr_t before
casting it to a pointer.
Though uio_resid is of type ssize_t, we need to take into account that
this source file contains an implementation specific to a certain
userspace pointer size. If this file provided 32-bit implementations,
this should have used INT32_MAX, even when running a 64-bit kernel.
This change has no effect, but is simply in preparation for adding
support for running 32-bit CloudABI executables.
On 32-bit platforms, our 64-bit timestamps need to be split up across
two registers. A simple assignment to td_retval[0] will cause the top 32
bits to get lost. By using memcpy(), we will automatically either use 1
or 2 registers depending on the size of register_t.
The reason why the old vDSOs were written in C using inline assembly was
purely because they were embedded in the C library directly as static
inline functions. This was practical during development, because it
meant you could invoke system calls without any library dependencies.
The vDSO was simply a copy of these functions.
Now that we require the use of the vDSO, there is no longer any need for
embedding them in C code directly. Rewriting them in assembly has the
advantage that they are closer to ideal (less useless branching, less
assumptions about registers remaining unclobbered by the kernel, etc).
They are also easier to build, as they no longer depend on the C type
information for CloudABI.
Obtained from: https://github.com/NuxiNL/cloudabi
This was .. an interesting headache.
There are two halves:
* The earlier IRIX stuff (yes, early) occasionally would do dead
code removal and generate multiple consecutive LO16 entries.
If this is done for REL entries then it's fine - there's no
state kept between them. But gcc 5.x seems to do this for
RELA entries.
eg:
HI1 LO1 HI2 LO2 LO3 HI4 LO4
.. in this instance, LO2 should affect HI2, but LO3 doesn't at all
affect anything. The matching HI3 was in code that was deleted
as "dead code".
Then, the next one:
* A "GCC extension" allows for multiple HI entries before a LO entry;
and all of those HI entries use the first LO entry as their basis
for RELA offset calculations.
It does this so GCC can also do dead code deletion without necessarily
having to geneate fake relocation entries for balanced HI/LO RELA
entries.
eg:
HI1 LO1 HI2 HI3 HI4 LO4 LO5 HI6 LO6 LO7
in this instance, HI{2,3,4} are the same relocation as LO4 (eg .bss)
and need to be buffered until LO4 - then the RELA offset is applied
from LO4 to HI{2,3,4} calculations.
/And/, the AHL from HI4 is used during the LO4 relocation calculation,
just like in the normal (ie, before this commit) implementation.
Then, LO5 doesn't trigger anything - the HI "buffer" is empty,
so there are no HI relocations to flush out.
HI6/LO6 are normal, and LO7 doesn't trigger any HI updates.
Tested:
* AR9344 SoC, kernel modules, using gcc-5.3 (mips-gcc-5.3.0 package)
Notes:
* Yes, I do feel dirty having written this code.
Reviewed by: imp (after a handful of "this should be on fire" moments wrt gcc and this code)
The default value of the tunable introduced in r304436 couldn't be
effectively overrided on VIMAGE kernels, because instead of being
accessed via the appropriate VNET() accessor macro, it was accessed
via the VNET_NAME() macro, which resolves to the (should-be) read-only
master template of initial values of per-VNET data. Hence, while the
value of udp_require_l2_bcast could be altered on per-VNET basis, the
code in udp_input() would ignore it as it would always read the default
value (one) from the VNET master template.
Silence from: rstone
The ip6_output routine is missing L2 cache invalication as done
in ip_output. Even with that code, some problems with UDP over
IPv6 have been reported. Diabling L2 cache for that problem works
around the problem for now.
PR: 211872 211926
Reviewed by: gnn
Approved by: gnn (mentor)
MFC after: immediate
(NB: This was likely a mismerge from XNU in audit support, where the
text argument to setlogin(2) is captured -- but as a text token,
whereas this change uses the dedicated login-name field in struct
audit_record.)
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
ftruncate(2) system call. This was not required by the Common
Criteria, which needed only open-time audit.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
strings provided by user/config files. This update is replacing sprintf with
snprintf for cases the command_errbuf is built from dynamic content.
PR: 211958
Reported by: ecturt@gmail.com
Reviewed by: imp, allanjude
Approved by: imp (mentor), allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D7563
This driver only supports 10Mb Ethernet using PIO (the hardware supports
DMA, but the driver only does PIO). There are not any PCCard adapters
supported by this driver, only ISA cards. In addition, it does not use
bus_space but instead uses bcopy with volatile pointers triggering a
host of warnings. (if_ie.c is one of 3 files always built with
-Wno-error)
Relnotes: yes
to generate one. This is was U-Boot does to generate a random MAC so we end
up with the same MAC address as if U-Boot did generate it.
MFC after: 1 week
This hardware is not present on any modern systems. The driver is quite
hackish (raw inb/outb instead of bus_space, and raw inb/outb to random
I/O ports to enable ACPI since it predated proper ACPI support).
Relnotes: yes
The wl(4) driver supports pre-802.11 PCCard wireless adapters that
are slower than 802.11b. They do not work with any of the 802.11
framework and the driver hasn't been reported to actually work in a
long time.
Relnotes: yes
The si(4) driver supported multiport serial adapters for ISA, EISA, and
PCI buses. This driver does not use bus_space, instead it depends on
direct use of the pointer returned by rman_get_virtual(). It is also
still locked by Giant and calls for patch testing to convert it to use
bus_space were unanswered.
Relnotes: yes
Currently boot parameters (r0 - r3) are forgotten in ARM trampoline code.
This patch save them at startup and restore them before jumping into kernel
_start() routine.
This is usefull when booting with Linux ABI and/or custom bootloader.
Submitted by: Grégory Soutadé <soutade@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D7395
Such processes are stopped synchronously by a direct call to
ptracestop(SIGTRAP) upon exec. P2_PTRACE_FSTP causes the exec()ing thread
to suspend itself while waiting for a SIGSTOP that never arrives.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D7576
This permits a single early return for VF devices in the routines that
add sysctl nodes.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7512
Specifically, the FW_PORT_CMD may or may not work for a VF (the PF
driver can choose whether or not to permit access to this command),
so don't attempt to fetch port information on a VF if permission is
denied by the PF.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7511
While here, mark which parameters are PF-specific and which are
VF-specific.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7508
Now that we've switched over to using the vDSO on CloudABI, it becomes a
lot easier for us to phase out old features. System call numbering is no
longer something that's part of the ABI. It's fully based on names. As
long as the numbering used by the kernel and the vDSO is consistent
(which it always is), it's all right.
Let's put this to the test by removing a system call (thread_tcb_set())
that's already unused for quite some time now, but was only left intact
to serve as a placeholder. Sync in the new system call table that uses
alphabetic sorting of system calls.
Obtained from: https://github.com/NuxiNL/cloudabi
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.
Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493
And don't recreate RXBUF for each primary channel open, it is now
created in device_attach DEVMETHOD and destroyed in device_detach
DEVMETHOD.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7556
[set] notation. This fixes pattern matching for recently added drives
that would set the NCQ Trim being broken incorrectly.
PR: 210686
Tested-by: Tomoaki AOKI
MFC After: 3 days
in_broadcast() was iterating over the ifnet address list without
first taking an IF_ADDR_RLOCK. This could cause a panic if a
concurrent operation modified the list.
Reviewed by: bz
MFC after: 2 months
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7227
in_broadcast() can be quite expensive, so skip calling it if the
incoming mbuf wasn't sent to a broadcast L2 address in the first
place.
Reviewed by: gnn
MFC after: 2 months
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7309
For almost every packet that is transmitted through ip_output(),
a call to in_broadcast() was made to decide if the destination
IP was a broadcast address. in_broadcast() iterates over the
ifnet's address to find a source IP matching the subnet of the
destination IP, and then checks if the IP is a broadcast in that
subnet.
This is completely redundant as we have already performed the
route lookup, so the source IP is already known. Just use that
address to directly check whether the destination IP is a
broadcast address or not.
MFC after: 2 months
Sponsored By: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7266
On the first switch we previously released the newly allocated keyboard
instead of the old one. Keyboard state was very confused afterwards for
further keyboard switches.
Submitted by: bde
