This will be used in kern_copy_file_range(), which needs to lock two
offsets.
Reviewed by: kib, rmacklem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49440
(cherry picked from commit 12ecb0fe0afda8c051605045e446371ddd34741f)
whu@ cannot reproduce the assertion failure which led to these ifdefs
being added in the first place, and since they appear wrong, i.e., the
assertions ought to apply to all platforms, let's remove them.
This reverts commits 0af5a0cd27 and
6f7b1310b6.
PR: 285681
Tested by: whu
MFC after: 2 weeks
(cherry picked from commit 54a3920dc9b3b5a47cdaaa3132b4fcf1c448a737)
- The BUS_DMA_KEEP_PG_OFFSET flag is needed, since
storvsc_xferbuf_prepare() assumes that only the first segment may have
a non-zero offset, and that all following segments are page-sized and
-aligned.
- storvsc_xferbuf_prepare() handles 64-bit bus addresses, so avoid
unneeded bouncing on i386.
PR: 285681
Reported by: dim
Tested by: dim, whu
MFC after: 2 weeks
(cherry picked from commit a319ba694538a38429115aaaf1d4b3946ea3a8b5)
This seems a bit preferable to open-coding it. No functional change
intended.
Reviewed by: kp, glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49518
(cherry picked from commit 27f70efebf1d9424462f291e9d04e62272083aa7)
The entry added in pmap_bootstrap() is guaranteed to be covered by that
added in pmap_cold(). This apparently went unnoticed until commit
8a14ddcc1d8e ("vm_phys: Check for overlap when adding a segment").
PR: 285415
Tested by: dim
MFC after: 2 weeks
(cherry picked from commit e173855c9f6b3b87c975418d0acf1c22ac4f1626)
Add a default ctloutput handler and remove various NULL checks. This
fixes a problem wherein the generic SO_SETFIB handler did not check
whether the protocol has a ctloutput implementation before calling the
function pointer.
Reported by: syzkaller
Reviewed by: glebius
Fixes: caccbaef8e26 ("socket: Move SO_SETFIB handling to protocol layers")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49436
(cherry picked from commit 590b45036ee16163f9eb8c34791d197e76de502d)
On some EC2 instances, there is a race between removing a device from
the system and making the PCI bus stop reporting the presence of the
device. As a result, a PCI BUS_RESCAN performed immediately after
the _EJ0 method returns "sees" the device which is being ejected, which
then causes problems later (e.g. we won't recognize a new device being
plugged into that slot because we never knew it was vacant).
On other operating systems the bus is synchronously marked as needing
to be rescanned but the rescan does not occur until O(1) seconds later.
Create a new ACPI_Q_DELAY_BEFORE_EJECT_RESCAN quirk and set it in EC2
AMIs, and add a 10 ms DELAY between _EJ0 and BUS_RESCAN when tht quirk
is set.
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49252
(cherry picked from commit 55c3348ed78fb1d0891e8bb51a8948f95da3560b)
This change makes NG_ABI_VERSION depend on INVARIANTS
in addition to NETGRAPH_DEBUG.
PR: 257876
(cherry picked from commit 93b4a54456589e78dcd37f2db8333baff3f3f0b2)
Fix a copy-and-paste error in acpi_pcib_request_feature where the
child device was passed into acpi_pcib_osc rather than the pcib
device.
Reviewed by: garga, jhb
Fixes: ba1904937d9a ("acpica: Extract _OSC parsing to a common file")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48285
(cherry picked from commit b714eacb790551f35de03831b88ad7b7e1502102)
Previously, we would accept only ':' as the separator, which makes
parsing of the rule specification harder for humans, especially those
people that are used to UNIX systems where ':' is used as the separator
in PATH. With ':', the <from> and <to> parts can look like two
different elements that are unrelated, especially to these eyes.
Change parse_single_rule() so that '>' is also accepted as a separator
between <from> and <to>, and promote it as the one to use. During
a transition period, we will still allow the use of ':' for backwards
compatibility.
The manual page update comes from separate revision D49628. ':' has
been completely removed from it on purpose.
Reviewed by: bapt, manpages (ziaee)
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49627
(cherry picked from commit f01d26dec67fb6597438ed765269b85d1099a6fa)
This is to fix slowdowns with drm-kmod that get worse over time as
physical memory become more fragmented (and probably also depending on
other factors).
Based on information posted in this bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277476
By default, linux_alloc_pages() retries failed allocations by calling
vm_page_reclaim_contig() to attempt to free contiguous physical memory
pages. vm_page_reclaim_contig() does not always succeed and calling it
can be very slow even when it fails. When physical memory is very
fragmented, vm_page_reclaim_contig() can end up being called (and
failing) after every allocation attempt. This could cause very
noticeable graphical desktop hangs (which could last seconds).
The drm-kmod code in question attempts to allocate multiple contiguous
pages at once but does not actually require them to be contiguous. It
can fallback to doing multiple smaller allocations when larger
allocations fail. It passes alloc_pages() the __GFP_NORETRY flag in this
case.
This patch makes linux_alloc_pages() fail early (without retrying) when
this flag is passed.
[olce: The problem this patch fixes is longer and longer GUI freezes as
a machine's memory gets filled and becomes fragmented, when using amdgpu
from DRM kmod 5.15 and DRM kmod 6.1 (DRM kmod 5.10 is unaffected; newer
Linux kernel introduced an "optimization" by which a pool of pages is
filled preferentially with contiguous pages, which triggered the problem
for us). The original commit message above evokes freezes lasting
seconds, but I occasionally witnessed some lasting tens of minutes,
rendering a machine completely useless.
The patch has been reviewed for its potential impacts to other LinuxKPI
parts and our existing DRM kmods' code. In particular, there is no
other user of __GFP_NORETRY/GFP_NORETRY with Linux's alloc_pages*()
functions in our tree or DRM kmod ports.
It has also been tested extensively, by me for months against 14-STABLE
and sporadically on -CURRENT on a RX580, and by several others as
reported below and as is visible in more details in the quoted bugzilla
PR and in the initial drm-kmod issue at
https://github.com/freebsd/drm-kmod/issues/302, on a variety of other
AMD GPUs (several RX580, RX570, Radeon Pro WX5100, Green Sardine 5600G,
Ryzen 9 4900H with embedded Renoir).]
PR: 277476
Reported by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
Reviewed by: olce
Tested by: many (olce, Pierre Pronchery, Evgenii Khramtsov, chaplina, rk)
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation (review and part of testing)
(cherry picked from commit 718d1928f8748fe4429c011296f94f194d63c695)
bcd2bin() must not be called with a value greater or equal to
LIBKERN_LEN_BCD2BIN.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 516e24e57987d184cce70e7f31443653aa1a5e63)
Using printf() with '%s' can lead to arbitrary long printing (although,
usually, a NUL byte should appear quite quickly) and trying to print
unprintable characters.
Instead, print in hexadecimal the exact bytes that are compared to the
expected signature.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit bb04712e37723d112b2fad28af4b035ef35a25be)
This helps figuring out quickly why no SMBIOS device appears in this case.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit fdf08ac1e9f9baac4fcf4af8f3bf7a34d3ea0009)
Only allow the length tolerance (0x1e instead of 0x1f) for a 32-bit
entry point, as there was no 64-bit entry point in the erroneous SMBIOS
v2.1 standard and assigning the length with 0x1f does not make sense in
this case.
While here, fix accessing the major/minor versions via 'eps' even in the
64-bit entry point case (not causing any practical problem thus far as
the entry point length is greater than any SMBIOS revisions in
existence, so the comparison guarding the fixup would not pass).
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f6cbd6b6d2ccd672e4807128ce0d07db333d4335)
Consistently with what the probe and attach methods are doing.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 3907feff7ab732b918ba3f5993e7a6718fffea14)
While here, de-indent most of the code by simply bailing out if 'addr'
is still 0 after the various detection methods have been tried.
Reviewed by: emaste, imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49180
(cherry picked from commit 67d510f0c07afd89e51e337e5abec47f4483ecd9)
Additionally, on verbose boot, print the entry point revision as
a diagnostic/debugging help.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
(cherry picked from commit e421a6615dc257b71ac5255336dddf5c99cd12aa)
When booted from BIOS (i.e., not EFI), also search for a 64-bit version
of the SMBIOS Entry Point.
This allows us to detect and report the proper SMBIOS version with
BIOSes that only provide the v3 table, as happens on Hetzner virtual
machines.
For machines that provide both, leverage the v3 table in priority
consistently with the EFI case.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Relnotes: yes
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
(cherry picked from commit bc7f6508363c5cf4544044e00bbaf71de8f0168d)
Get smbios working on arm64 where it seems to be
exclusively smbios version 3.x
The "interesting" thing here is that the smbios table seems to be
RAM in the EFI runtime services table. This makes it owned by "ram0",
and not io memory. That prevents bus_alloc_resource() from being able
to claim it, since ram0 already owns it. According to jhb, this is
how things are supposed to work. Eg, bus_alloc_resource() is meant
to be used with IO memory, not physical memory. Following his
suggestion, I converted the driver to simply use pmap_mapbios().
This is a prerequisite for getting IPMI to attach via the SSIF
attachment on arm64 servers, where all IPMI that I've seen
uses SSIF.
Note that this change is based on initial work by Allan Jude in
https://reviews.freebsd.org/D28739.
Reviewed by: imp
Sponsored by: Netflix, Ampere Computing LLC (D28739)
Differential Revision: https://reviews.freebsd.org/D42592
(cherry picked from commit ba0e4d7971e05ee64281a4fc49a2fb408c8ad816)
In this case, the domain from which the memory to back the VM page array
is allocated does not matter, so just let vm_phys_early_alloc() choose
a suitable domain.
Reviewed by: jhibbits, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48888
(cherry picked from commit 0ebd9cf85d3627e50e6a7330b67719fce4d1a5fe)
Change the comment before this block of code, and separate the latter
from the preceding one by an empty line.
Move the loop on phys_avail[] to compute the minimum and maximum memory
physical addresses closer to the initialization of 'low_avail' and
'high_avail', so that it's immediately clear why the loop starts at
2 (and remove the related comment).
While here, fuse the additional loop in the VM_PHYSSEG_DENSE case that
is used to compute the exact physical memory size.
This change suppresses one occurence of detecting whether at least one
of VM_PHYSSEG_DENSE or VM_PHYSSEG_SPARSE is defined at compile time, but
there is still another one in PHYS_TO_VM_PAGE().
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48632
(cherry picked from commit 16317a174a5288f0377f8d40421b5c7821d57ac2)
Previously, such requests would lead to a panic. The only caller so far
(vm_phys_early_startup()) actually faces the case where some address can
be one of the chunk's boundaries and has to test it by hand. Moreover,
a later commit will introduce vm_phys_early_alloc_ex(), which will also
have to deal with such boundary cases.
Consequently, make this function handle boundaries by not splitting the
chunk and returning EJUSTRETURN instead of 0 to distinguish this case
from the "was split" result.
While here, expand the panic message when the address to split is not in
the passed chunk with available details.
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48630
(cherry picked from commit e1499bfff8b8c128d7b3d330f95e0c67d7c1fa77)
On improper termination of phys_avail[] (two consecutive 0 starting at
an even index), this function would (unnecessarily) continue searching
for the termination markers even if the index was out of bounds.
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48629
(cherry picked from commit 291b7bf071e8b50f2b7877213b2d3307ae5d3e38)
Segments are passed by machine-dependent routines, so explicit checks
will make debugging much easier on very weird machines or when someone
is tweaking these machine-dependent routines. Additionally, this
operation is not performance-sensitive.
For the same reasons, test that we don't reach the maximum number of
physical segments (the compile-time of the internal storage) in
production kernels (replaces the existing KASSERT()).
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48628
(cherry picked from commit 8a14ddcc1d8e4384d8ad77c5536c916c6e9a7d65)
A bad specification is if 'start' is strictly greater than 'end', or
bounds are not page aligned.
The latter was already tested under INVARIANTS, but now will be also on
production kernels. The reason is that vm_phys_early_startup() pours
early segments into the final phys_segs[] array via vm_phys_add_seg(),
but vm_phys_early_add_seg() did not check their validity. Checking
segments once and for all in vm_phys_add_seg() avoids duplicating
validity tests and is possible since early segments are not used before
being poured into phys_segs[]. Finally, vm_phys_add_seg() is not
performance critical.
Allow empty segments and discard them (silently, unless 'bootverbose' is
true), as vm_page_startup() was testing for this case before calling
vm_phys_add_seg(), and we felt the same test in vm_phys_early_startup()
was due before calling vm_phys_add_seg(). As a consequence, remove the
empty segment test from vm_page_startup().
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48627
(cherry picked from commit f30309abcce4cec891413da5cba2db92dd6ab0d7)
The passed index must be the start of a chunk in phys_avail[], so must
be even. Test for that and print a separate panic message.
While here, fix panic messages: In one, the wrong chunk boundary was
printed, and in another, the desired but not the actual condition was
printed, possibly leading to confusion.
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48626
(cherry picked from commit 125ef4e041fed40fed2d00b0ddd90fa0eb7b6ac3)
This flag is used in field 'cr_flags', which is never directly visible
outside the kernel. That field is however exported through 'struct
kinfo_proc' objects (field 'ki_cr_flags'), either from the kernel via
sysctls or from libkvm, and is supposed to contain exported flags
prefixed with KI_CRF_ (currently, KI_CRF_CAPABILITY_MODE and
KI_CRF_GRP_OVERFLOW, this second one being a purely userland one
signaling overflow of 'ki_groups').
Make sure that KI_CRF_CAPABILITY_MODE is the flag actually exported and
tested by userland programs, and hide the internal CRED_FLAG_CAPMODE.
As both flags are currently defined to the same value, this doesn't
change the KBI, but of course does change the KPI. A code search via
GitHub and Google fortunately doesn't reveal any outside uses for
CRED_FLAG_CAPMODE.
While here, move assignment of 'ki_uid' to a more logical place in
kvm_proclist(), and definition of XU_NGROUPS as well in 'sys/ucred.h'
(no functional/interface changes intended).
Reviewed by: mhorne
Approved by: markj (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46909
(cherry picked from commit 09290c3a0c82524138973b14f393379edf733753)
A ports exp-run (PR 283410) showed one port to be affected
(sysutils/procs), which has been fixed upstream and in the ports tree.
All additional indirect references to CRED_FLAG_CAPMODE we found after
the code search mentioned in the original commit message are
automatically generated from our headers by FFI mechanisms, so
automatically disappear at recompilation (and the KBI is not changed, as
explained above, so recompilation is not needed).
struct tcp_log_rack is not used, therefore remove it.
Reviewed by: Peter Lei
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49669
(cherry picked from commit b1c62081feec535a4f2eeb4f8deb58913d9e281c)
The sendfile black box logging struct is much smaller than the
encompassing stack specific logging union. Be sure to clear the
trailing unused memory when logging.
Reviewed by: tuexen
Sponsored by: Netflix, Inc.
(cherry picked from commit 3bd1e85fc13cb90853046300dcaa31d63b45ee21)
Initialize the fields in the tcp_log_buffer in the sequence they
appear in the structure and add the initialization of tlb_flex1,
tlb_flex2, and _pad[].
Reviewed by: rrs, Peter Lei
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49652
(cherry picked from commit 94acddd2ad0142221124c3fb7fe3778a5a1f8036)
Thanks to glebius@ for pointing to the problem.
Reported by: syzbot+1d5c164f1c10de84ad8a@syzkaller.appspotmail.com
Fixes: 2d5c48eccd ("sctp: Tighten up locking around sctp_aloc_assoc()")
(cherry picked from commit e8623834ca29b562687db945bdd12a3e2fe4aeb1)
