FreeBSD DD utility has not had support for the O_DIRECT flag, which
is useful to bypass local caching, e.g. for unconditionally issuing
NFS IO requests during testing.
Eric Joyner [Thu, 4 Jun 2020 20:39:28 +0000 (20:39 +0000)]
em(4): Add support for Comet Lake Mobile Platform, update shared code
This change introduces Comet Lake Mobile Platform support in the e1000
driver along with shared code patches described below.
- Cast return value of e1000_ltr2ns() to higher type to avoid overflow
- Remove useless statement of assigning act_offset
- Add initialization of identification LED
- Fix flow control setup after connected standby:
After connected standby the driver blocks resets during
"AdapterStart" and skips flow control setup. This change adds
condition in e1000_setup_link_ich8lan() to always setup flow control
and to setup physical interface only when there is no need to block
resets.
John Baldwin [Thu, 4 Jun 2020 20:12:34 +0000 (20:12 +0000)]
Use separate output buffers for OCF requests in KTLS.
KTLS encryption requests for file-backed data such as from sendfile(2)
require the encrypted data to be stored in a separate buffer from the
unencrypted file input data. Previously the OCF backend for KTLS
manually copied the data from the input buffer to the output buffer
before queueing the crypto request. Now the OCF backend will use a
separate output buffer for such requests and avoid the copy. This
mostly helps when an async co-processor is used by saving CPU cycles
used on the copy.
Mitchell Horne [Thu, 4 Jun 2020 19:21:41 +0000 (19:21 +0000)]
Update edk2 headers to stable202005
We use these to compile libefivar. The particular motivation for this update is
the inclusion of the RISC-V machine definitions that allow us to build the
library on the platform. This support could easily have been submitted as a
small local diff, but the timing of the release coincided with this work, and
it has been over 3 years since these sources were initially imported.
Note that this comes with a license change from regular BSD 2-clause to the
BSD+Patent license. This has been approved by core@ for this particular
project [1].
As with the original import, we retain only the subset of headers that we
actually need to build libefivar. I adapted imp@'s process slightly for this
update:
# Generate list of the headers needed to build
cp -r ../vendor/edk2/dist/MdePkg/Include sys/contrib/edk2
cd lib/libefivar
make
pushd `make -V .OBJDIR`
cat .depend*.o | grep sys/contrib | cut -d' ' -f 3 |
sort -u | sed -e 's=/full/path/sys/contrib/edk2/==' > /tmp/xxx
popd
# Merge the needed files
cd ../../sys/contrib/edk2
svn revert -R .
for i in `cat /tmp/xxx`; do
svn merge -c VendorRevision svn+ssh://repo.freebsd.org/base/vendor/edk2/dist/MdePkg/$i $i
done
svn merge -c VendorRevision svn+ssh://repo.freebsd.org/base/vendor/edk2/dist/MdePkg/MdePkg.dec MdePkg.dec
Kyle Evans [Thu, 4 Jun 2020 18:17:25 +0000 (18:17 +0000)]
vfs: add restrictions to read(2) of a directory [2/2]
This commit adds the priv(9) that waters down the sysctl to make it only
allow read(2) of a dirfd by the system root. Jailed root is not allowed, but
jail policy and superuser policy will abstain from allowing/denying it so
that a MAC module can fully control the policy.
Such a MAC module has been written, and can be found at:
https://people.freebsd.org/~kevans/mac_read_dir-0.1.0.tar.gz
It is expected that the MAC module won't be needed by many, as most only
need to do such diagnostics that require this behavior as system root
anyways. Interested parties are welcome to grab the MAC module above and
create a port or locally integrate it, and with enough support it could see
introduction to base. As noted in mac_read_dir.c, it is released under the
BSD 2 clause license and allows the restrictions to be lifted for only
jailed root or for all unprivileged users.
Kyle Evans [Thu, 4 Jun 2020 18:09:55 +0000 (18:09 +0000)]
vfs: add restrictions to read(2) of a directory [1/2]
Historically, we've allowed read() of a directory and some filesystems will
accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed by
Warner: <<EOF
pdp-7 unix seemed to allow reading directories, but they were weird, special
things there so I'm unsure (my pdp-7 assembler sucks).
1st Edition's sources are lost, mostly. The kernel allows it. The
reconstructed sources from 2nd or 3rd edition read it though.
V6 to V7 changed the filesystem format, and should have been a warning, but
reading directories weren't materially changed.
4.1b BSD introduced readdir because of UFS. UFS broke all directory reading
programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and
friends were introduced here.
SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 updated
all the directory reading programs in 1988 because different filesystem
types were introduced.
In the 90s, these interfaces became completely ubiquitous as PDP-11s running
V7 faded from view and all the folks that initially started on V7 upgraded
to SysV. Linux never supported this (though I've not done the software
archeology to check) because it has always had a pathological diversity of
filesystems.
EOF
Disallowing read(2) on a directory has the side-effect of masking
application bugs from relying on other implementation's behavior
(e.g. Linux) of rejecting these with EISDIR across the board, but allowing
it has been a vector for at least one stack disclosure bug in the past[0].
By POSIX, this is implementation-defined whether read() handles directories
or not. Popular implementations have chosen to reject them, and this seems
sensible: the data you're reading from a directory is not structured in some
unified way across filesystem implementations like with readdir(2), so it is
impossible for applications to portably rely on this.
With this patch, we will reject most read(2) of a dirfd with EISDIR. Users
that know what they're doing can conscientiously set
bsd.security.allow_read_dir=1 to allow read(2) of directories, as it has
proven useful for debugging or recovery. A future commit will further limit
the sysctl to allow only the system root to read(2) directories, to make it
at least relatively safe to leave on for longer periods of time.
While we're adding logic pertaining to directory vnodes to vn_io_fault, an
additional assertion has also been added to ensure that we're not reaching
vn_io_fault with any write request on a directory vnode. Such request would
be a logical error in the kernel, and must be debugged rather than allowing
it to potentially silently error out.
Commented out shell aliases have been placed in root's chsrc/shrc to promote
awareness that grep may become noisy after this change, depending on your
usage.
A tentative MFC plan has been put together to try and make it as trivial as
possible to identify issues and collect reports; note that this will be
strongly re-evaluated. Tentatively, I will MFC this knob with the default as
it is in HEAD to improve our odds of actually getting reports. The future
priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the knob
will be a faithful reversion on stable/12. We will go into the merge
acknowledging that the sysctl default may be flipped back to restore
historical behavior at *any* point if it's warranted.
Conrad Meyer [Thu, 4 Jun 2020 16:04:19 +0000 (16:04 +0000)]
Restrict default /root permissions
Remove world-readability from the root directory. Sensitive information may be
stored in /root and we diverge here from normative administrative practice, as
well as installation defaults of other Unix-alikes. The wheel group is still
permitted to read the directory.
750 is no more restrictive than defaults for the rest of the open source
Unix-alike world. In particular, Ben Woods surveyed DragonFly, NetBSD,
OpenBSD, ArchLinux, CentOS, Debian, Fedora, Slackware, and Ubuntu. None have a
world-readable /root by default.
Eugene Grosbein [Thu, 4 Jun 2020 14:44:44 +0000 (14:44 +0000)]
ifconfig(8): make it possible to filter output by interface group.
Now options -g/-G allow to select/unselect interfaces by groups
in the "ifconfig -a" output just like already existing -d/-u.
Examples:
to exclude loopback from the list: ifconfig -a -G lo
to show vlan interfaces only: ifconfig -a -g vlan
to show tap interfaces that are up: ifconfig -aug tap
Arguments to -g/-G may be shell patterns and both may be specified.
Later options -g/-G override previous ones.
The rule 5 matches nothing without the fix if n>=32769.
With the fix, it works:
# telnet localhost 10001
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Permission denied
telnet: Unable to connect to remote host
Andriy Gapon [Thu, 4 Jun 2020 13:18:21 +0000 (13:18 +0000)]
superio: do not assume that current LDN cannot change after config exit
That assumption should be true when superio(4) uses the hardware
exlusively. But it turns out to not hold on some real systems.
So, err on the side of correctness rather than performance.
Clear current_ldn in sio_conf_exit.
Andriy Gapon [Thu, 4 Jun 2020 13:06:49 +0000 (13:06 +0000)]
ifconfig.8: fix cpability and flag descriptions for list scan / sta
Some capability descriptions under list scan actually described flags.
Some capability descriptions were missing.
Some flag descriptions under list sta actually described capabilites.
Reviewed by: adrian
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25014
UFS: write inode block for fdatasync(2) if pointers in inode where allocated
The fdatasync() description in POSIX specifies that
all I/O operations shall be completed as defined for synchronized I/O
data integrity completion.
and then the explanation of Synchronized I/O Data Integrity Completion says
The write is complete only when the data specified in the write
request is successfully transferred and all file system
information required to retrieve the data is successfully
transferred.
For UFS this means that all pointers must be on disk. Indirect
pointers already contribute to the list of dirty data blocks, so only
direct blocks and root pointers to indirect blocks, both of which
reside in the inode block, should be taken care of. In ffs_balloc(),
mark the inode with the new flag IN_IBLKDATA that specifies that
ffs_syncvnode(DATA_ONLY) needs a call to ffs_update() to flush the
inode block.
Reviewed by: mckusick
Discussed with: tmunro
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25072
Rick Macklem [Thu, 4 Jun 2020 00:28:20 +0000 (00:28 +0000)]
Fix mountd to handle getgrouplist() not returning groups[0] == groups[1].
Prior to r174547, getgrouplist(3) always returned a groups list with
element 0 and 1 set to the basegid argument, so long as ngroups was > 1.
Post-r174547 this is not the case. r328304 disabled the deduplication that
removed the duplicate, but the duplicate still does not occur unless the
group for a user in the password database is also entered in the group
database.
This patch fixes mountd so that it handles the case where a user specified
with the -maproot or -mapall exports option has a getgrouplist(3) groups
list where groups[0] != groups[1].
Found while testing another mountd patch.
Adrian Chadd [Wed, 3 Jun 2020 22:30:44 +0000 (22:30 +0000)]
[run] Fix up tx/rx frame size.
This specifically fixes that TX frames are large enough now to hold a 3900 odd
byte AMSDU (the little ones); me flipping it on earlier messed up transmit!
Tested:
* if_run, STA mode, TX/RX TCP/UDP iperf. TCP is now back to normal and
correctly does ~ 3200 byte AMSDU/fast frames (2x1600ish byte MSDUs).
Adrian Chadd [Wed, 3 Jun 2020 20:25:02 +0000 (20:25 +0000)]
[otus] enable 802.11n for 2GHz and 5GHz.
This flips on basic 11n for 2GHz/5GHz station operation.
* It flips on HT20 and MCS rates;
* It enables A-MPDU decap - the payload format is a bit different;
* It does do some basic checks for HT40 but I haven't yet flipped on
HT40 support;
* It enables software A-MSDU transmit; I honestly don't want to make
A-MPDU TX work and there are apparently issues with QoS and A-MPDU TX.
So I totally am ignoring A-MPDU TX;
* MCS rate transmit is fine.
I haven't:
* A-MPDU TX, as I said above;
* made radiotap work fully;
* HT40;
* short-GI support;
* lots of other stuff that honestly no-one is likely to use.
But! Hey, this is another ye olde 11n USB NIC that now works pretty OK
in 11n rates. A-MPDU receive seems fine enough given it's a draft-n
device from before 2010.
Tested:
* Ye olde UB82 Test NIC (AR9170 + AR9104) - 2GHz/5GHz
Kyle Evans [Wed, 3 Jun 2020 18:29:32 +0000 (18:29 +0000)]
lualoader: drop the filename and word "LUA" from errors
The filename is nearly always wrong since it's /boot/lua/loader.lua, which
is not useful for diagnostics. The actual errmsg will include a lua filename
if this is relevant.
Dropping "LUA" while we're here because that's almost universally
irrelevant to whatever error follows, unless the error states that it's
actually a lua problem.
Both of these are minor nits that just detract from identifying the
pertinent information.
This change prevents a race that happens when rxsync dequeues
N-1 rx packets (with N being the size of the netmap rx ring).
In this situation, the loop exits without re-enabling the
rx interrupts, thus causing the VQ to stall.
netmap: vtnet: add vtnrx_nm_refill index to receive queues
The new index tracks the next netmap slot that is going
to be enqueued into the virtqueue. The index is necessary
to prevent the receive VQ and the netmap rx ring from going
out of sync, considering that we never enqueue N slots, but
at most N-1. This change fixes a bug that causes the VQ
and the netmap ring to go out of sync after N-1 packets
have been received.
Mitchell Horne [Wed, 3 Jun 2020 16:38:16 +0000 (16:38 +0000)]
gptboot.efi: align secbuf to 4K
The u-boot EFI implementation of the ReadBlocks and WriteBlocks methods
requires that the provided buffer meet the IO alignment requirements of
the underlying disk. Unlike loader.efi, gptboot.efi doesn't check this
requirement, and therefore fails to perform a successful read. Adjust
secbuf's alignment to 4K in hopes that we will always meet this
requirement.
Randall Stewart [Wed, 3 Jun 2020 14:16:40 +0000 (14:16 +0000)]
We should never allow either the broadcast or IN_ADDR_ANY to be
connected to or sent to. This was fond when working with Michael
Tuexen and Skyzaller. Skyzaller seems to want to use either of
these two addresses to connect to at times. And it really is
an error to do so, so lets not allow that behavior.
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D24852
Randall Stewart [Wed, 3 Jun 2020 14:07:31 +0000 (14:07 +0000)]
This fixes a couple of skyzaller crashes. Most
of them have to do with TFO. Even the default stack
had one of the issues:
1) We need to make sure for rack that we don't advance
snd_nxt beyond iss when we are not doing fast open. We
otherwise can get a bunch of SYN's sent out incorrectly
with the seq number advancing.
2) When we complete the 3-way handshake we should not ever
append to reassembly if the tlen is 0, if TFO is enabled
prior to this fix we could still call the reasemmbly. Note
this effects all three stacks.
3) Rack like its cousin BBR should track if a SYN is on a
send map entry.
4) Both bbr and rack need to only consider len incremented on a SYN
if the starting seq is iss, otherwise we don't increment len which
may mean we return without adding a sendmap entry.
This work was done in collaberation with Michael Tuexen, thanks for
all the testing!
Sponsored by: Netflix Inc
Differential Revision: https://reviews.freebsd.org/D25000
Michael Tuexen [Wed, 3 Jun 2020 13:51:53 +0000 (13:51 +0000)]
Restrict enabling TCP-FASTOPEN to end-points in CLOSED or LISTEN state
Enabling TCP-FASTOPEN on an end-point which is in a state other than
CLOSED or LISTEN, is a bug in the application. So it should not work.
Also the TCP code does not (and needs not to) handle this.
While there, also simplify the setting of the TF_FASTOPEN flag.
Add if_reassing method to all tunneling interfaces.
After r339550 tunneling interfaces have started handle appearing and
disappearing of ingress IP address on the host system.
When such interfaces are moving into VNET jail, they lose ability to
properly handle ifaddr_event_ext event. And this leads to need to
reconfigure tunnel to make it working again.
Since moving an interface into VNET jail leads to removing of all IP
addresses, it looks consistent, that tunnel configuration should also
be cleared. This is what will do if_reassing method.
Reported by: John W. O'Brien <john saltant com>
MFC after: 1 week
Ryan Moeller [Wed, 3 Jun 2020 09:38:51 +0000 (09:38 +0000)]
tmpfs: Preserve alignment of struct fid fields
On 64-bit platforms, the two short fields in `struct tmpfs_fid` are padded to
the 64-bit alignment of the long field. This pushes the offsets of the
subsequent fields by 4 bytes and makes `struct tmpfs_fid` bigger than
`struct fid`. `tmpfs_vptofh()` casts a `struct fid *` to `struct tmpfs_fid *`,
causing 4 bytes of adjacent memory to be overwritten when the struct fields are
set. Through several layers of indirection and embedded structs, the adjacent
memory for one particular call to `tmpfs_vptofh()` happens to be the stack
canary for `nfsrvd_compound()`. Half of the canary ends up being clobbered,
going unnoticed until eventually the stack check fails when `nfsrvd_compound()`
returns and a panic is triggered.
Instead of duplicating fields of `struct fid` in `struct tmpfs_fid`, narrow the
struct to cover only the unique fields for tmpfs and assert at compile time
that the struct fits in the allotted space. This way we don't have to
replicate the offsets of `struct fid` fields, we just use them directly.
The netmap_rx_irq() function normally wakes up user-space threads
waiting for more packets. In this case, it is not necessary to
call it under the driver queue lock. However, if the interface is
attached to a VALE switch, netmap_rx_irq() ends up calling rxsync
on the interface (see netmap_bwrap_intr_notify()). Although
concurrent rxsyncs are serialized through the kring lock
(see nm_kr_tryget()), the lock acquire operation is not blocking.
As a result, it may happen that netmap_rx_irq() is called on
an RX ring while another instance is running, causing the
second call to fail, and received packets stall in the receive VQ.
We fix this issue by calling netmap_irx_irq() under the VQ lock.
The netmap_rx_irq() function may return NM_IRQ_RESCHED to inform the
driver that more work is pending, and that netmap expects netmap_rx_irq()
to be called again as soon as possible.
This change implements this behaviour in the vtnet driver.
When I did some bus_dma cleanup in r320528, I brought forward some sketchy
WITNESS checks from the prior x86 busdma wrappers, instead of recognizing
them as technical debt and just dropping them. Two of these were removed in
r346351 and r346851, but one remains in bounce_bus_dmamem_alloc(). This check
could be constrained to only apply in the BUS_DMA_NOWAIT case, but it's cleaner
to simply remove it and rely on the checks already present in the sleepable
allocation paths used by this function.
While here, remove another unnecessary witness check in bus_dma_tag_create
(the tag is always allocated with M_NOWAIT), and fix a couple of typos.
Reported by: cem
Reviewed by: kib, cem
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25107
Doug Moore [Tue, 2 Jun 2020 17:18:16 +0000 (17:18 +0000)]
Remove from RB_REMOVE_COLOR some null checks where the pointer checked
is provably never null. Restructure the surrounding code just enough
to make the non-nullness obvious.
Adrian Chadd [Tue, 2 Jun 2020 16:40:58 +0000 (16:40 +0000)]
[run] Add 11NA flags for 5G NICs that support HT.
Now that I'm a proud owner of an ASUS USB-N66, I can test 2G/5G and
3-stream configurations.
For now, just flip on 5G HT rates. I've tested this in both
5G HT20 and 5G 11a modes. It's still one stream for now until
we verify that the number of streams reported (ie the MIMO below)
is actually the number of 11n streams, NOT the number of antennas.
(They don't have to match! You can have more antennas than MIMO
streams!)
Do not allow to load ET_DYN object with DF_1_PIE flag set.
Linkers are supposed to mark PIE binaries with DF_1_PIE, such binary
cannot be correctly and usefully loaded neither by dlopen(3) nor as a
dependency of other object. For instance, we cannot do anything
useful with COPY relocations, among other things.
Glibc already added similar restriction.
Requested and reviewed by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25086
When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf that
conflict, and hilarity ensues. There's currently three different places that
we might install mailer.conf:
- ^/etc/Makefile (package=runtime, contingent on MK_MAIL != no)
- ^/libexec/dma/dmagent/Makefile (package=dma, contingent on MK_SENDMAIL !=
no)
- ^/usr.sbin/mailwrapper/Makefile (package=utilities, contingent on
not-installed)
The mailwrapper installation will effectively never happen because the ^/etc
one will first.
This patch simplifies the whole situation; remove the ^/etc/Makefile version
and install it primarily in mailwrapper if MK_MAILWRAPPER != "no". The
scenarios covered in mailwrapper are:
- sendmail(8) is installed, dma(8) may or may not be installed
- neither sendmail(8) nor dma(8) is installed
In the first scenario, sendmail(8) is dominant so we can go ahead and
install the version in ^/etc/mail. In the unlisted scenario, sendmail(8) is
not installed but dma(8) is, we'll let ^/libexec/dma/dmagent do the
installation. In the second listed scenario, we still want to install an
example mailer.conf so just install the base sendmail(8) version.
vt(4): reset scrollback and cursor position after clearing history buffer
r361601 implemented basic support for cleaing the console history buffer.
But after clearing the history buffer, it's not especially useful to be
able to scroll back through that buffer, or for the cursor position to
remain at (very likely) the bottom of the screen.
Kyle Evans [Tue, 2 Jun 2020 00:32:36 +0000 (00:32 +0000)]
modules: don't build ipsec/tcpmd5 if the kernel is configured for IPSEC
IPSEC_SUPPORT can currently only cope with either IPSEC || IPSEC_SUPPORT,
not both. Refrain from building if IPSEC is set, as the resulting module
won't be able to load anyways if it's built into the kernel.
KERN_OPTS is safe here; for tied modules, it will reflect the kernel
configuration. For untied modules, it will defer to whatever is set in
^/sys/conf/config.mk, which doesn't set IPSEC for modules. The latter
situation has some risk to it for uncommon scenarios, but such is the life
of untied kernel modules.
Reported by: jenkins (a lot), O. Hartmann (once)
Generally discussed with: imp, jhb
Kyle Evans [Mon, 1 Jun 2020 23:26:37 +0000 (23:26 +0000)]
lualoader: improve drawer error handling
At least one user has landed in a scenario where logo files appear to be
misnamed, and we failed to find them. Our fallback for missing logodefs is
orb/orbbw, based on the color status. In a scenario where we can't locate
the logos, though, this is not ideal. Add in one more layer of fallback
to properly just don't draw any logo if the fan has been jam packed with
foreign material.
Currently there is no easy way of subscribing for the routing table changes.
The only existing way is to set ifa_rtrequest callback in the each protocol
ifaddr, which is not convenient or extandable.
This change provides generic notification subscription mechanism, that will
replace current ifa_rtrequest one and allow other applications such as
accelerated routing lookup modules subscribe for the changes.
In particular, this change provides 2 hooks: 1) synchronous one
(RIB_NOTIFY_IMMEDIATE), called under RIB_WLOCK, which ensures exact
ordering of the changes and 2) async one, (RIB_NOTIFY_DELAYED)
that is called after the change w/o holding locks. The latter one does not
provide any notification ordering guarantee.
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism.
Currently callers guess the operation data based on the rtentry structure
returned in case of successful operation result. There are two problems with
this appoach. First is that it doesn't provide enough information for the
upcoming multipath changes, where rtentry refers to a new nexthop group,
and there is no way of guessing which paths were added during the change.
Second is that some rtentry fields can change during notification and
protecting from it by requiring customers to unlock rtentry is not desired.
Additionally, as the consumers such as rtsock do know which operation they
request in advance, making explicit add/change/del versions of the functions
makes sense, especially given the functions don't share a lot of code.
With that in mind, introduce rib_cmd_info notification structure and
rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer.
It will be used in upcoming generalized notifications.
* Move definitions of the new functions and some other functions/structures
used for the routing table manipulation to a separate header file,
net/route/route_ctl.h. net/route.h is a frequently used file included in
~140 places in kernel, and 90% of the users don't need these definitions.
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism.
Currently callers guess the operation data based on the rtentry structure
returned in case of successful operation result. There are two problems with
this appoach. First is that it doesn't provide enough information for the
upcoming multipath changes, where rtentry refers to a new nexthop group,
and there is no way of guessing which paths were added during the change.
Second is that some rtentry fields can change during notification and
protecting from it by requiring customers to unlock rtentry is not desired.
Additionally, as the consumers such as rtsock do know which operation they
request in advance, making explicit add/change/del versions of the functions
makes sense, especially given the functions don't share a lot of code.
With that in mind, introduce rib_cmd_info notification structure and
rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer.
It will be used in upcoming generalized notifications.
* Move definitions of the new functions and some other functions/structures
used for the routing table manipulation to a separate header file,
net/route/route_ctl.h. net/route.h is a frequently used file included in
~140 places in kernel, and 90% of the users don't need these definitions.
Brandon Bergren [Mon, 1 Jun 2020 19:40:59 +0000 (19:40 +0000)]
[PowerPC] Fix build-id note on powerpc64 kernel
Due to the ordering of the powerpc64 linker script, we were discarding
all notes before emitting .note.gnu.build-id. This had the effect of
generating an empty build id section and breaking the kern.build_id
sysctl added in r348611.
powerpc and powerpcspe are uneffected.
PR: 246430
MFC after: 3 days
Sponsored by: Tag1 Consulting, Inc.
Kristof Provost [Mon, 1 Jun 2020 19:26:16 +0000 (19:26 +0000)]
bridge tests: Avoid building a switching loop
Enable STP before bringing the bridges up. This avoids a switching loop,
which has a tendency to drown out progress in userspace processes,
especially on single-core systems.
Only check that we have indeed shut down one of the looped interfaces
Tijl Coosemans [Mon, 1 Jun 2020 18:58:09 +0000 (18:58 +0000)]
Install 32-bit libcrypto engines in /usr/lib32/engines instead of
/usr/lib32 and let 32-bit libcrypto search that location instead of
/usr/lib/engines.
netmap assumes the one "slot" is left unused to distinguish
the empty ring and full ring conditions. This assumption was
violated by vtnet_netmap_rxq_populate().
The vtnet_netmap_rxq_populate() function erroneously assumed
that kring->nr_hwcur = 0, i.e. the kring was in the initial
state. However, this is not always the case: for example,
when a vtnet reinit is triggered by some changes in the
interface flags or capenable.
This patch changes the behaviour of vtnet_netmap_kring_refill()
so that it always starts publishing the netmap buffers starting
from the current value of kring->nr_hwcur.
Mark Johnston [Mon, 1 Jun 2020 15:32:13 +0000 (15:32 +0000)]
cap_fileargs: Fix a descriptor leak in the service process.
The service handler for fileargs_open() tries to pre-open multiple files
and pass descriptors for each back to the sandboxed process in a single
message. This is to amortize the cost of round-trips between the two
processes.
The service process adds a "cache" nvlist to the reply to "open",
containing file descriptors for pre-opened files. However, when adding
that nvlist to the reply, it was making a copy, effectively leaking the
cached descriptors.
While here, fix spelling in a local variable name.
PR: 241226
Reviewed by: oshogbo
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25095
Dimitry Andric [Mon, 1 Jun 2020 10:08:18 +0000 (10:08 +0000)]
Follow-up r361678 (update apr to 1.7.0) by also regenerating the apr
internal headers through the upstream configure script, with some minor
custom tweaks.
Adrian Chadd [Mon, 1 Jun 2020 06:10:25 +0000 (06:10 +0000)]
[ath] Don't re-program the beacon timers if we miss a beacon in software-beacon STA mode.
This is something I added a few years ago to handle resyncing the beacon if
we miss a beacon or need to sync after association/reassociation/powersave.
However, if we're doing STA+AP mode (eg DWDS) then we don't want
to reprogram the beacons here; this may upset normal AP operation.
I missed checking for the sc->sc_swbmiss flag so I was reinitialising
the beacon timers after every beacon miss / TSFOOR option, and
that isn't likely good.
This plus ensuring that STA's are created with "-beacon" to disable
BMISS/TSFOOR processing will hopefully quieten some of the issues
I've seen with missed beacons / TSFOOR (out of range) interrupts
coming in when operating in STA mode.
projects / FreeBSD / FreeBSD.git / log