At least for SAS that we only support now disks are typically
connected to the same bus as the enclosure. Limiting the search
scope makes it much faster on systems with multiple buses and
thousands of disks.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D32305
Remove *_MATCH_NONE enums, making no sense and so never used. Make
*_MATCH_ANY enums 0 (no any match flags set), previously used by
*_MATCH_NONE. Bump CAM_VERSION to 0x1a reflecting those changes and
add compat shims.
When traversing through buses and devices do not descend if we can
already see that requested pattern does not match the bus or device.
It allows to save significant amount of time on system with thousands
of disks when doing limited searches.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D32304
This function is actively used by sbuf_vprintf(), so this simple
inlining in half reduces time of kern.geom.confxml generation.
MFC after: 2 weeks
Sponsored by: iXsystem, Inc.
These files came from a prior commit to contrib/bc and seem to have
been placed in the top of the source tree by a failed git rebase.
Reported by: markj
In some contexts it is illegal to wait for memory allocation, causing
kernel panic. By default sbuf_new passes M_WAITOK to malloc,
which caused crashes when sdhci_dumpcaps or sdhci_dumpregs was callend in
non sutiable context.
Add SBUF_NOWAIT flag to sbuf_new to fix this.
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D32075
The descriptions may be more elaborated of course, but this is a good
step at starting providing any useful information in our man page, at all.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D32243
Describe internal allocations, mention problems with the use of global
malloc(3) and the reasons for internal allocator existence.
Document shared objects implementation and describe shortcomings of the
chosen approach, as well as the rationale why it was done that way.
Reviewed by: markj
Discussed with: jilles
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D32243
- Ensure that the computed MFT record size isn't negative or larger than
maxphys before trying to read $Volume.
- Guard against truncated records in volume metadata.
- Ensure that the record length is large enough to contain the volume
name.
- Verify that the (UTF-16-encoded) volume name's length is a multiple of
two.
PR: 258833, 258914
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
This version adds options and functions that allow to print numbers
in the open interval (-1 .. 1) with or without a leading 0 digit.
Additionally, an option has been added to prevent line wrap and
allows to print arbitrarily long results on a single line.
Merge commit '5d58a51571721190681c50d4bd3a1f45e6282d72'
This version adds options and functions that allow to print numbers
in the open interval (-1 .. 1) with or without a leading 0 digit.
Additionally, an option has been added to prevent line wrap and
allows to print arbitrarily long results on a single line.
RPCINFO on macOS behaves different compared to other linux clients and
doesn't provide request address in rpcb structure of the
RPCBPROC_GETADDRLIST call which doesn't seem to be forbidden.
In this case RPCBIND uses RPC call's source address and picks a
closest corresponding local address. If there are no addresses in the
same subnet as the source address, return of RPCBIND may vary
depending on the order of addresses returned in getifaddrs. If a link
local precedes global address it may be returned even if the request
comes from neither a link local nor from link local in a different
scope, which will prevent services like nfs from working in tpc6
scenario on macOS clients. Issue can be seen only on FreeBSD rpcbind
port due to changes in workflow of addrmerge call.
Submitted by: Dmitry Ovsyannikov (Dmitry.Ovsyannikov@dell.com)
Reviewers: dab
Differential Revision: https://reviews.freebsd.org/D31491
Sponsored by: Dell EMC
MFC to: stable/12, stable/13
MFC after: 1 week
When copying a struct or union from one CTF container to another,
ctf_add_type() checks whether it matches an existing type in the
destination container. It does so by looking for a type with the same
name and kind as the new type, and if one exists, it iterates over all
members of the source type and checks whether a member with matching
name and offset exists in the matched destination type. This can
produce false positives, for example because member types are not
compared, but this is not expected to arise in practice. If the match
fails, ctf_add_type() returns an error.
The procedure used for member comparison breaks down in the face of
anonymous struct and union members. ctf_member_iter() visits each
member in the source definition and looks up the corresponding member in
the desination definition by name using ctf_member_info(), but this
function will descend into anonymous members and thus fail to match.
Fix the problem by introducing a custom comparison routine which does
not assume member names are unique. This should also be faster for
types with many members; in the previous scheme, membcmp() would perform
a linear scan of the desination type's members to perform a lookup by
name. The new routine steps through the members of both types in a
single loop.
PR: 258763
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
after the split, curses.h is now generated by tinfo Makefile, but
still used for a file generated in ncurses lib. Adjust the path to
make sure curses.h is always found
many external program expects libncurses to not be provided as a single
library. Instead of fixing all ports, distribute ncurses the way
upstream distributes it
Turn libncursesw.so into a ldscript which will link automatically as
needed to libtinfow so so this change is seamless at compile time.
Differential Revision: https://reviews.freebsd.org/D32098
The tests that come with version 5.0.2 have been extended to cover the
line editing functions. It has been found that these tests generate
false negative results in FreeBSD, most likely due to an issue in the
pexpect functionality used.
These history tests are skipped on systems that do not have python and
py-pexpect installed (and thus are unlikely to cause CI test failures),
but in order to not cause irritating failures on systems were these
packages are in fact installed, I temporarily disconnect them.
I had planned to skip this version due to the issue with the history
tests, but some committer has asked me to go ahead since the currently
used version 5.0.0 contains a macro name that collides with a project
he is working on.
No MFC of this version is planned. A version 5.0.3 is expected to be
released soon, and that version will allow to reconnect the tests and
will be MFCed.
A number of files have been removed from the release distribution of
this bc implementation. They were mostly relevant for pre release
testing and benchmarking to identify regressions. The Markdown
sources of the man pages are only relevant for combinations of build
options not used in FreeBSD and need non-default conversion tools
(available as ports in FreeBSD).
All the omitted files can be found in the upstream git repository,
and they are fetched when building this software as a port. But they
have never been used in the FreeBSD base system.
Prior to this commit, the loader would perform readaheads of up to
128 kB; when booting on a UFS filesystem this resulted in a series
of 160 kB reads (32 kB request + 128 kB readahead).
This commit allows readaheads to be longer, subject to a total I/O
size limit of 256 kB; i.e. 32 kB read requests will have added
readaheads of up to 224 kB.
In my testing on an EC2 c5.xlarge instance, this change reduces the
boot time by roughly 80 ms.
Reviewed by: tsoome
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32251
The loader bcache attempts to determine whether readahead is useful,
increasing or decreasing its readahead length based on whether a
read could be serviced out of the cache. This resulted in two
unfortunate behaviours:
1. A series of consecutive 32 kB reads are requested and bcache
performs 16 kB readaheads. For each read, bcache determines that,
since only the first 16 kB is already in the cache, the readahead
was not useful, and keeps the readahead at the minimum (16 kB) level.
2. A series of consecutive 32 kB reads are requested and bcache
starts with a 32 kB readahead resulting in a 64 kB being read on
the first request. The second 32 kB request can be serviced out of
the cache, and bcache responds by doubling its readahead length to
64 kB. The third 32 kB request cannot be serviced out of the cache,
and bcache reduces its readahead length back down to 32 kB.
The first syndrome converts a series of 32 kB reads into a series of
(misaligned) 32 kB reads, while the second syndrome converts a series
of 32 kB reads into a series of 64 kB reads; in both cases we do not
increase the readahead length to its limit (currently 128 kB) no
matter how many consecutive read requests are made.
This change avoids this problem by tracking the "unconsumed
readahead" length; readahead is deemed to be useful (and the
read-ahead length is potentially increased) not only if a request was
completely serviced out of the cache, but also if *any* of the request
was serviced out of the cache and that length matches the amount of
unconsumed readahead. Conversely, we now only reduce the readahead
length in cases where there was unconsumed readahead data.
In my testing on an EC2 c5.xlarge instance, this change reduces the
boot time by roughly 120 ms.
Reviewed by: imp, tsoome
MFC after: 1 week
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32250
This is the same underlying problem as 2624598064, just for bus ranges
rather than windows. SiFive's HiFive Unmatched has the following
topology:
Root Port <---> Bridge <---> Bridge <-+-> Bridge <---> (Unused)
(pcib0) (pcib1) (pcib2) | (pcib3)
+-> Bridge <---> xHCI
| (pcib4)
+-> Bridge <---> M.2 E-key
| (pcib5)
+-> Bridge <---> M.2 M-key
| (pcib6)
+-> Bridge <---> x16 slot
(pcib7)
If a device is plugged into the x16 slot that itself has a bridge, such
as many graphics cards, we currently fail to allocate a bus number for
its child bus (and so pcib_attach_child skips adding a child bus for
further enumeration) as, when the new child bridge attaches, it attempts
to allocate a bus number from its parent (pcib7) which in turn attempts
to grow its own bus range by calling bus_adjust_resource on its own
parent (pcib2) whose bus rman cannot accommodate the request and needs
to itself be extended by calling its own parent (pcib1). Note that
pcib3-7 do not face the same issue when they attach since pcib1 ends up
managing bus numbers 1-255 from the beginning and so never needs to grow
its own range.
Reviewed by: jhb, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32011
No in-tree drivers are supported for RISC-V (given it supports UEFI we
could enable the EFI framebuffer, but U-Boot has very limited hardware
support and EDK2 remains a work in progress), but drm-kmod exists with
drivers for video cards that can be used with the HiFive Unmatched.
Reviewed by: imp, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32001
One of the three uses is already guarded; this guards the remaining ones
to support architectures like riscv that do not provide write-combining,
and is needed to build drm-kmod on riscv.
Reviewed by: hselasky, manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31999
The corresponding 32-bit int and 128-bit int functions were added in
790a6be5a1, as were all combinations of the float to int functions,
but these two were overlooked. __floatditf is needed to build curl for
riscv as there's a signed 64-bit int to 128-bit float conversion in
lib/progress.c's trspeed as of 7.77.0.
Reviewed by: dim
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31997
pmap_change_attr is required by drm-kmod so we need the function to
exist. Since the Svpbmt extension is on the horizon we will likely end
up with a real implementation of it, so this stub implementation does
all the necessary page table walking to validate the input, ensuring
that no new errors are returned once it's implemented fully (other than
due to out of memory conditions when demoting L2 entries) and providing
a skeleton for that future implementation.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31996
These began to become obsolete in d6d64f0f2c (r137739) and the deal
was later sealed in 003e18aef4 (r137801) when vfs.fifofs.fops was
dropped and vop-bypass for pipes became mandatory.
PR: 225934
Suggested by: markj
Reviewe by: kib, markj
Differential Revision: https://reviews.freebsd.org/D32270
Callout c_time is always bigger or equal than the scheduled time. It
is also smaller than sbinuptime() and can't change while the callback
is running. So we reliably can use it instead of sbinuptime() here.
In case there was a race and the callout was rescheduled to the later
time, the callback will be called again.
According to profiles it saves ~5% of the timer interrupt time even
with fast TSC timecounter.
MFC after: 1 month
The fsckpid mount option was introduced in 927a12ae16 along with a
couple sysctl's to support SU+J with snapshots. However, those sysctl's
were never used and eventually removed in f2620e9ceb.
There are no in-tree consumers of this mount option.
Reviewed by: mckusick, kib
Differential Revision: https://reviews.freebsd.org/D32015
For a pNFS server configuration, an NFSv4.2 Deallocate operation
is proxied to the DS(s). The code that parsed the reply for the
proxy RPC is broken and did not process the pre-operation attributes.
This patch fixes this problem.
This bug would only affect pNFS servers built from recent main/FreeBSD14
sources.
