Reported by: Matthew D. Fuller (fullermd over-yonder.net),
Kevin Bowling (kevin.bowling kev009.com)
MFC after: 13 days
X-MFC with: r292601
Sponsored by: The FreeBSD Foundation
If the zfs module is not present and not loadable, report an error
to the user instead of crashing
Reviewed by: mahrens
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D4691
I realize that these tests could be run before mac_bsdextended is loaded, but
it would overcomplicate things to special case handle the testcases before doing
the mac_bsdextended(4) feature check
The testcases will be split up so they can be run separately in the near future
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
vim overzealously removed some trailing `+' and I didn't check the
diff
MFC after: 1 week
X-MFC with: r292640
Pointyhat to: ngie
Sponsored by: EMC / Isilon Storage Division
greater than len_on_bd, before invoking the routine to handle jumbo over SGL
(bxe_service_rxsgl()).
Add counters for number of jumbo_over_SGL packets (rx_bxe_service_rxsgl) and
erroneous jumbo_over_SGL packets (rx_erroneous_jumbo_sge_pkts)
Fix formatting in bxe_sysctl_state()
MFC after:5 days
close and close due to revoke(2)-like operation.
A new FLASTCLOSE flag indicates that this is last close. FREVOKE is
set for revokes, and FNONBLOCK is also set, same as is already done
for VOP_CLOSE() call from vgonel().
The flags reuse user open(2) flags which are never stored in f_flag,
to not consume bit space in the ABI visible way. Assert this with the
static check.
Requested and reviewed by: bde
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
i386 is the only current FreeBSD architecture that ever used a.out
format.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D4687
sysdecode_ioctlname() function. This function matches the behavior
of the truss variant in that it returns a pointer to a string description
for known ioctls. The caller is responsible for displaying unknown
ioctl requests. For kdump this meant moving the logic to handle unknown
ioctl requests out of the generated function and into an ioctlname()
function in kdump.c instead.
Differential Revision: https://reviews.freebsd.org/D4610
This variable was added to sys/x86/include/x86_var.h recently.
This unbreaks building kernel source that #includes both md_var.h and x86_var.h
with gcc 4.2.1 on amd64
Differential Revision: https://reviews.freebsd.org/D4686
Reviewed by: kib
X-MFC with: r291949
Sponsored by: EMC / Isilon Storage Division
The existing implementations of POSIX tsearch() and tdelete() don't
attempt to perform any balancing at all. Testing reveals that inserting
100k nodes into a tree sequentially takes approximately one minute on my
system.
Though most other BSDs also don't use any balanced tree internally, C
libraries like glibc and musl do provide better implementations. glibc
uses a red-black tree and musl uses an AVL tree.
Red-black trees have the advantage over AVL trees that they only require
O(1) rotations after insertion and deletion, but have the disadvantage
that the tree has a maximum depth of 2*log2(n) instead of 1.44*log2(n).
My take is that it's better to focus on having a lower maximum depth,
for the reason that in the case of tsearch() the invocation of the
comparator likely dominates the running time.
This change replaces the tsearch() and tdelete() functions by versions
that create an AVL tree. Compared to musl's implementation, this version
is different in two different ways:
- We don't keep track of heights; just balances. This is sufficient.
This has the advantage that it reduces the number of nodes that are
being accessed. Storing heights requires us to also access all of the
siblings along the path.
- Don't use any recursion at all. We know that the tree cannot 2^64
elements in size, so the height of the tree can never be larger than
96. Use a 128-bit bitmask to keep track of the path that is computed.
This allows us to iterate over the same path twice, meaning we can
apply rotations from top to bottom.
Inserting 100k nodes into a tree now only takes 0.015 seconds. Insertion
seems to be twice as fast as glibc, whereas deletion has about the same
performance. Unlike glibc, it uses a fixed amount of memory.
I also experimented with both recursive and iterative bottom-up
implementations of the same algorithm. This iterative top-down version
performs similar to the recursive bottom-up version in terms of speed
and code size.
For some reason, the iterative bottom-up algorithm was actually 30%
faster for deletion, but has a quadratic memory complexity to keep track
of all the parent pointers.
Reviewed by: jilles
Obtained from: https://github.com/NuxiNL/cloudlibc
Differential Revision: https://reviews.freebsd.org/D4412
This will allow maintainers to be notified of
any reviews or commits affecting parts of the
tree which they maintain.
Reviewed by: jhb, emaste, allanjude
Differential Revision: https://reviews.freebsd.org/D4623
breakpoint. The value doesn't need to be adjusted as it is already
correctly returned from the kernel.
This allows lldb to set breakpoints, and stop on them, however more work
is needed, for example single stepping fails to stop.
Discussed with: emaste
epair(4), we may hit if_detach_internal() without holding a lock and by
the time we aquire it the interface might be gone.
We should not panic() in this case as it is our fault for not holding
the lock all the way. It is not ideal to return silently without error
to user space, but other callers will all ignore the return values so
do not change the entire KPI for little benefit for now.
The ifp will be dealt with one way or another still.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: gnn
Differential Revision: https://reviews.freebsd.org/D4529
creation will print extra lines on the console. We are generally not
interested in this (repeated) information for each VNET. Thus only
print it for the default VNET. Virtual interfaces on the base system
will remain printing information, but e.g. each loopback in each vnet
will no longer cause a "bpf attached" line.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: gnn
Differential Revision: https://reviews.freebsd.org/D4531
initialization.
Mfp4 @180384,180385:
There is no need for a dedicated SYSINIT here. The
list can be initialized statically.
Sponsored by: CK Software GmbH
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: gnn
Differential Revision: https://reviews.freebsd.org/D4528
on vnet enabled jail shutdown. Call the provided cleanup
routines for IP versions 4 and 6 to plug these leaks.
Sponsored by: The FreeBSD Foundation
MFC atfer: 2 weeks
Reviewed by: gnn
Differential Revision: https://reviews.freebsd.org/D4530
if the memory wasn't allocated again later on
Reported by: Coverity
Submitted by: Miles Ohlrich <miles.ohlrich@isilon.com>
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
Examine each cmdline arg and if it contains an '=' convert it to ascii and
pass it to putenv(). This allows var=value settings to come in on the
command line.
This will allow overriding dhcp server-provided data in loader(8), as
discussed in PR 202098
PR: 202098
Differential Revision: https://reviews.freebsd.org/D4561
variables in loader(8) and other libstand applications.
Sometimes a dhcp server provides incorrect information along with the IP
address. It would be useful to have a way to override this with
locally-supplied information, such as command line parameters passed from a
prior-stage bootloader. This change allows pre-existing env vars to take
precedence over values delivered by the dhcp or bootp server.
The bootp/dhcp code in libstand automatically creates environment variables
from the data provided by the server (dhcp.root-path, dhcp.domain-name,
etc). It also transcribes the values to some global variables such as
'rootpath' and 'hostname'.
This change does two things:
When adding dhcp.* vars to the environment, don't replace existing
vars/values.
When setting the global vars rootpath and hostname, use the
dhcp.root-path and dhcp.host-name env var values if they exist.
This allows the platform-specific part of loader(8) to obtain override
values in some platform-specific way and store them in the environment
before opening the network device. The set of values that can be overriden
is currently limited to just string options. The values that are delivered
as binary data are things that probably shouldn't be overridden (IP,
netmask, gateway, etc).
The original patch this evolved from was submitted by martymac@
PR: 202098
Differential Revision: https://reviews.freebsd.org/D4559
grep'able in /bin/sh
This fixes the situation where the OS has been rebranded to something other
than `FreeBSD`
MFC after: 1 week
Obtained from: Isilon OneFS (^/onefs/head@r511419)
Reviewed by: cem, Daniel O'Connor <darius@dons.net.au>
Sponsored by: EMC / Isilon Storage Division