The RFC for this finally got published and, therefore,
now has a number. This patch puts this RFC number
in the man page.
This is a content change.
MFC after: 1 week
Add methods for setting and removing the description from the interface,
so the external users can manage it without using ioctl API.
MFC after: 2 weeks
Factor cloner ifp addition/deletion into separate functions and
make them public. This change simlifies the current cloner code
and paves the way to the other upcoming cloner / epair changes.
MFC after: 2 weeks
The vn_rlimit_fsizex() function:
- checks that the write does not exceed RLIMIT_FSIZE limit and fs
maximum supported file size
- truncates write length if it exceeds the RLIMIT_FSIZE or max file size,
but there are some bytes to write
- sends SIGXFSZ if RLIMIT_FSIZE would be exceed otherwise
POSIX mandates the truncated write in case when some bytes can be
written but whole write request fails the RLIMIT_FSIZE check.
The function is supposed to be used from VOP_WRITE()s. Due to
pecularity in the VFS generic write syscall layer, uio_resid must
correctly reflect the written amount (noted by markj). Provide the dual
vn_rlimit_fsizex_res() function to correct uio_resid after the clamp
done in vn_rlimit_fsizex() on VOP_WRITE() return.
PR: 164793
Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D36625
Use 'td' as the local thread name.
Wrap long lines.
Remove unneeded blank lines.
Reviewed by: asomers, jah, markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D36625
This assertion can be triggered by usermode since vm_map_madvise()
doesn't force advice to be applied to an entire largepage mapping. I
can't see any reason not to permit it, however, since MADV_DONTNEED and
_FREE are advisory and we can simply do nothing when a 1GB mapping is
encountered.
Reviewed by: alc, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36675
This code path can be triggered by applying MADV_WILLNEED to a 1GB
mapping.
Reviewed by: alc, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36674
pmap_growkernel() may be called when mapping a region above KERNBASE,
typically for a kernel module. If we have enough PTPs left over from
bootstrap, pmap_growkernel() does nothing. However, it's possible to
run out, and in this case pmap_growkernel() will try to grow the kernel
map all the way from kernel_vm_end to somewhere past KERNBASE, which can
easily run the system out of memory. This happens with large kernel
modules such as the nvidia GPU driver. There is also a WIP dtrace
provider which needs to map KVA in the region above KERNBASE (to provide
trampolines which allow a copy of traced kernel instruction to be
executed), and its allocations could potentially trigger this scenario.
This change modifies pmap_growkernel() to manage the two regions
separately, allowing them to grow independently. The end of the
KERNBASE region is tracked by modifying "nkpt".
PR: 265019
Reviewed by: alc, imp, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36673
smr_enter() must publish its observed read sequence number before
issuing any subsequent memory operations. The ordering provided by
atomic_add_acq_int() is insufficient on some platforms, at least on
arm64, because it permits reordering of subsequent loads with the store
to c_seq.
Thus, use atomic_thread_fence_seq_cst() to issue a store-load barrier
after publishing the read sequence number.
On x86, take advantage of the fact that memory operations are not
reordered with locked instructions to improve code density: we can store
the observed read sequence and provide a store-load barrier with a
single operation.
Based on a patch from Pierre Habouzit <pierre@habouzit.net>.
PR: 265974
Reviewed by: alc
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36370
When a thread switching off-CPU is migrating to a remote CPU,
sched_switch() may trigger a rescheduling of the thread currently
running on that CPU. When doing so, it must ensure that that thread is
locked before modifying thread state. If the thread's lock is not the
scheduler lock, then the thread is in the process of switching off-CPU
and no extra effort is needed, and the initiator does not hold the
thread's lock and thus should not modify any thread state.
Reported and tested by: Steve Kargl
MFC after: 1 week
The RFC for this finally got published and, therefore,
now has a number. This patch puts this RFC number
in the man page.
This is a content change.
MFC after: 1 week
The RFC for this finally got published and, therefore,
now has a number. This patch puts this RFC number
in the man page.
This is a content change.
MFC after: 1 week
strchr returns a pointer to the ',', so if the first option in the list
isn't available, we need to step over the , to look at the next
option. So if kern.cfg.order="acpi,fdt" and we have no acpi, we'd loop
forever with order=',fdt'.
Sponsored by: Netflix
Reviewed by: andrew, jhb
Differential Revision: https://reviews.freebsd.org/D36682
The maximum CPU number of a cpuset_t is determined by CPU_SETSIZE. In
the kernel this is MAXCPU, but in userspace it is CPU_MAXSIZE unless
CPU_SETSIZE is defined before including sys/_cpuset.h. CPU_MAXSIZE is
256 and in userspace MAXCPU is generally 1 because it being set to a
larger MD value is gated on SMP being defined (not generally the case in
userspace).
Reported by: Nathaniel Wesley Filardo <nwfilardo@gmail.com>
Reviewed by: cem, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D36679
Traditionally, we've used /boot/msdos for the MBR mount point for the SD
images that we produced. For GPT and bsdinstall, we've used
/boot/efi. Migrate to using /boot/efi for MBR as well and add a
/boot/msdos -> /boot/efi symlink for compatibility (which may disappear
before 14.0, but will remain on the stable branches).
When we first created the arm images, there was no EFI booting and the
FAT partion on an MBR image was used to hold the firmware, uboot.bin,
SoC config files and ubldr. When we transitioned to uboot with EFI, we
put the loader files in the same partition. Later we standardized on
/boot/efi at about the same time we added GPT support to the RE produced
images. We left the MRB case as /boot/msdos for legacy reasons and since
it wasn't always EFI. Later, we dropped support of non-EFI booting on
the RE produced images, so the duality of /boot/msdos diminished even
more. Since so little secondary meaning remains, putting it all in
/boot/efi standardizes the location and reflects the RE images
better as using efi-only booting.
In addition, always label the msdosfs partion 'efi'. While a small
misnomer on some systems that store other files in the ESP, it was
requested in review for more consistency for similar reasons to the
mountpoint rename. There was no way to have an 'alias' or 'second label'
here, so this breaks compatibility. Since the images are self-contained,
this was judged to be an acceptable change.
Sponsored by: Netflix
Reviewed by: manu, allanjude, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D36635
As with the GICv1/2 driver teach the GICv3 driver to translate memory
ranges of children. This allows us to create a common
bus_alloc_resource implementation for bot hACPI and FDT attachments.
Sponsored by: The FreeBSD Foundation
Fixes: eec02418d8 Remove support for FDDI and token ring media types in userland utilities.
Reviewed by: brooks, gjb, imp
Approved by: brooks (src), gjb (mentor, src), imp (src)
Differential Revision: https://reviews.freebsd.org/D36668
MFC after: 3 days
When an internal or other error occurs during the listing of a pool,
return an error code when extiting ippool(8). Printing an error to
stderr without returning an error code is useless in shell scripts.
MFC after: 2 weeks
Add an ippool(8) option to dump a copy of the inm-memory ippool tables
in an ippool(5) format so that it can be reloaded using ippool -f.
MFC after: 2 weeks
This matches the return type of pmap_mapdev/bios.
Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548
Coverity flagged this in its latest run but it is not a problem in
practice as the card's core clock would have to be > 4.2GHz for any
overflow to occur.
CID 1498303: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
Potentially overflowing expression "sc->params.vpd.cclk * 1000U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned).
Reported by: Coverity Scan (CID 1498303)
Sponsored by: Chelsio Communications
Factor out parts of pcim_iomap_regions_request_all() into
pcim_iomap_regions() now needed for a driver.
Sponsored by: The FreeBSD Foundation
MFC after: 7 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36654
In addition to the ones added last year add more found in modern
drivers.
Sponsored by: The FreeBSD Foundation
MFC after: 7 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36656
Constify "*from" arguments and add __ioread32_copy() and
__ioread64_copy() based on the already existing implementations.
Sponsored by: The FreeBSD Foundation
MFC after: 7 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36657
Add the devres version dmam_alloc_coherent() of dma_alloc_coherent()
along with the ancillary free function.
Sponsored by: The FreeBSD Foundation
MFC after: 7 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36661
Add some more defines used in drivers to make it easier to compile.
MFC after: 7 days
Reviewed by: hselasky, emaste
Differential Revision: https://reviews.freebsd.org/D36660
