This is useful when a wireless driver is stopped or started in response
to events like an RF Kill button press. Applications like
wpa_supplicant depend on such events to have a correct view of interface
state.
Reviewed by: adrian, cy, melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24925
First of all, znode_phys_t hasn't been used for storing file attributes
for a long time now. Modern ZFS versions use a System Attribute table
with a flexible layout. But more importantly all the required
information is available in znode_t itself.
It's not easy to include zfs_znode.h in userland without breaking code
because the most interesting parts of the header are kernel-only. And
hardcoding field offsets is too fragile. So, I created a new
compilation unit that includes zfs_znode.h using some mild kludges to
get it and its dependencies to compile in userland. The compilation
unit exports interesting field offsets and does not have any other code.
PR: 194117
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Panzura
Differential Revision: https://reviews.freebsd.org/D24941
Keep link_map l_addr binary layout compatible, rename l_addr to l_base
where rtld returns map base. Provide relocbase in newly added l_addr.
This effectively reverts the patch to the initial version of D24918.
Reported by: antoine (portmgr)
Reviewed by: jhb, markj
Tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24946
In mixed ECN marking and loss scenarios it was found, that
the alpha value of DCTCP is updated two times. The second
update happens with freshly initialized counters indicating
to ECN loss. Overall this leads to alpha not adjusting as
quickly as expected to ECN markings, and therefore lead to
excessive loss.
Reported by: Cheng Cui
Reviewed by: chengc_netapp.com, rrs, tuexen (mentor)
Approved by: tuexen (mentor)
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D24817
Overly conservative data receivers may ignore the CWR flag
on other packets, and keep ECE latched. This can result in
continous reduction of the congestion window, and very poor
performance when ECN is enabled.
Reviewed by: rgrimes (mentor), rrs
Approved by: rgrimes (mentor), tuexen (mentor)
MFC after: 3 days
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D23364
When receiving a parallel SYN in SYN-SENT state, remove all the
options only we supported locally before sending the SYN,ACK.
This addresses a consistency issue on parallel opens.
Also, on such a parallel open, the stack could be coaxed into
running with timestamps enabled, even if administratively disabled.
Reviewed by: tuexen (mentor)
Approved by: tuexen (mentor)
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D23371
While testing simultaneous open TCP with ECN, found that
negotiation fails to arrive at the expected final state.
Reviewed by: tuexen (mentor)
Approved by: tuexen (mentor), rgrimes (mentor)
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D23373
Update unbound 1.9.6 --> 1.10.1.
Bug Fixes:
- CVE-2020-12662 Unbound can be tricked into amplifying an incoming
query into a large number of queries directed to a target.
- CVE-2020-12663 Malformed answers from upstream name servers can be
used to make Unbound unresponsive.
Reported by: emaste
MFC after: 3 days
Relnotes: yes
Security: CVE-2020-12662, CVE-2020-12663
The rcu_work function helps to queue some work after waiting for a grace
period.
This is needed by DRM drivers.
Sponsored-by: The FreeBSD Foundation
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D24942
Recent changes have caused the vmspace objects to start coming from KVA
instead of direct-mapped memory on powerpc. As far as I can tell, this is
not actually a problem, so we should stop arbitrarily asserting that it is.
I do not know why this was not being triggered before.
Approved by: jhibbits
Sponsored by: Tag1 Consulting, Inc.
Highlights:
- CLICOLOR in the environment should imply --color=auto to maintain
compatibility with historical behavior
- -G should set CLICOLOR and imply --color=auto
The manpage has been updated to draw the connection between -G and --color;
the former is in-fact a sort of compromise between --color=always and
--color=auto, where we'll output color regardless of the environment lacking
CLICOLOR/COLORTERM assuming stdout is a tty.
X-MFC-With: r361318
This seems to have been broken since r247602 (from year 2013!).
Can be easily tested with
fstat -N /boot/kernel/kernel -M /var/crash/vmcore.last
MFC after: 1 week
Sponsored by: Panzura
hardware, the registers appear like there's two cores, but the second
core does not work, so base the number of cores upon the chip id.
Tested on a XC7Z007S.
also, previous commit was suppose to be D14429.
Submitted by: Thomas Skibo
Differential Revision: https://reviews.freebsd.org/D14429
node to replace the one being removed, restructure to first remove the
replacement node and correct the parent pointers around it, and then
let the all-cases code at the end deal with the parent of the deleted
node, making it point to the replacement node. This removes one or two
conditional branches.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D24845
This is all very long-standing bug stuff that is touchy and still poorly
documented. Ok, here goes.
The basic bug:
* deleting a VAP causes the RX path (and TX path too) to be restarted
without a full chip reset, which causes RX hangs on the AR9380 and later.
(ie, the ones with the newer DMA engine.)
The basic fix:
* do an RX flush when stopping RX in ath_vap_delete() to match what happens
when RX is stopped elsewhere. This ensures any pending frames are completed
and we restart at the right spot; it also ensures we don't push new RX buffers
into the hardware if we're stopping receive.
The other issues I found:
* Don't bother checking the RX packet ring in the deferred read taskqueue;
that's specifically supposed to be for completing frames rather than
just yanking them off the receive ring.
* Cancel/drain any pending deferred read taskqueue. This isn't done inside
any locks so we should be super careful here. This stops the hardware
being reprogrammed at the same time in another thread/CPU whilst we're
stopping RX.
* .. (yes, this should be better serialised, but that's for another day. maybe.)
* Add more debugging to trace what's going on here.
And the fun bit:
* Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just
reset. I noticed that after all the above was done I was STILL seeing RXEOL.
RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames
(ie a ping where it'd be transmitted but never received) so I was not being
spammed by RXEOL. So, as long as stuff is stopped, restart it.
This seems to be doing the right thing in both AP and STA modes.
What I should do next, if I ever get time:
* as I said above, serialise the receive stop/start to include taskqueues
* monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just
go do a full chip reset to get things back on track. It sucks, but it
is better than nothing.
Tested:
* AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX
queue stop/start; whilst also running an iperf through it. Lots of times.
Lots. Of.. Times.
I have to dig into why I'm seeing it on chips as late as the AR9380 era
stuff (as it's marked as an AR5416 bug, but who knows!) but i'm seeing
aggregate TX frames complete with no blockack bit set. So, everything
should be treated as a failure and do a hardware reset for good measure.
Tested:
* AR9380, STA mode
* AR9580 (5GHz), AP mode
I wasn't enforcing the maximum packet length when using static rates
so although the driver was enforcing it itself OK, the statistics were
sometimes going into the wrong bin.
Tested:
* AR9380, STA mode
The regression is in-fact that I flipped the default from never to auto. The
incorrect impression was based on an alias that I failed to notice,
installed by the Linux distribution that I used for testing compatibility
here. Users that want the old default should be doing so with a shell alias
as is done elsewhere, rather than making this decision in ls(1).
Many thanks to rgrimes for pointing out the alias that I clearly overlooked
that resulted in this; if you despised colors in your terminal from this,
consider buying him a beer at the next venue that you see him at.
MFC after: 1 week
Relnotes: yes
Instead of crashing the user process when a D-ERAT multihit is detected, try
to flush the ERAT, and continue. This machine check indicates a likely PMAP
invalidation shortcoming that will need to be addressed, but it's
recoverable, so just recover. The recovery is pmap-specific to flush the
ERAT, so add a pmap function to do so, currently only implemented by the
POWER9 radix pmap.
This is consistent with what we are doing for close(2) and it makes
it a bit easier to follow when debugging file descriptor operations.
i.e. many other syscalls are decoding fds as integers rather than
base 16 numbers.
MFC after: 1 week
Comparing fsid_t objects requires internal knowledge of the fsid structure
and yet this is duplicated across a number of places in the code.
Simplify by creating a fsidcmp function (macro).
Reviewed by: mjg, rmacklem
Approved by: mav (mentor)
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D24749
Changes since 20181221 are mostly portability related
hence the large gap in versions imported.
There are however some bug fixes, and a rework of filemon handling.
In NetBSD make/filemon/filemon_ktrace.c allows use of fktrace
and elimination of filemon(4) which has not had the TLC it needs.
FreeBSD filemon(4) is in much better shape, so bmake/filemon/filemon_dev.c
allows use of that, with a bit less overhead than the ktrace model.
Summary of changes from ChangeLog
o str.c: empty string does not match % pattern
plus unit-test changes
o var.c: import handling of old sysV style modifier using '%'
o str.c: refactor brk_string
o meta.c: meta_oodate, CHECK_VALID_META is too aggressive for CMD
a blank command is perfectly valid.
o meta.c: meta_oodate, check for corrupted meta file
earlier and more often.
* meta.c: meta_compat_parent check for USE_FILEMON
patch from Soeren Tempel
o meta.c: fix compat mode, need to call meta_job_output()
o job.c: extra fds for meta mode not needed if using filemon_dev
o meta.c: avoid passing NULL to filemon_*() when meta_needed()
returns FALSE.
o filemon/filemon_{dev,ktrace}.c: allow selection of
filemon implementation. filemon_dev.c uses the kernel module
while filemon_ktrace.c leverages the fktrace api available in
NetBSD. filemon_ktrace.c can hopefully form the basis for
adding support for other tracing mechanisms such as strace on
Linux.
o meta.c: when target is out-of-date per normal make rules
record value of .OODATE in meta file.
o parse.c: don't pass NULL to realpath(3)
some versions cannot handle it.
o parse.c: ParseDoDependency: free paths rather than assert
plus more unit-tests
- Use enc_xform_aes_xts.setkey() directly instead of duplicating the code
now that it no longer calls malloc().
- Rather than bringing back all of xform_userland.h, add a conditional
#include of <stand.h> to xform_enc.h.
- Update calls to encrypt/decrypt callbacks in enc_xform_aes_xts for
separate input/output pointers.
Pointy hat to: jhb
It previously returned the object map base address, while all other
ELF operating systems return load offset, i.e. the difference between
map base and the link base.
Explain the meaning of the field in the man page.
Stop filling the mips-only l_offs member, which is apparently unused.
PR: 246561
Requested by: Damjan Jovanovic <damjan.jov@gmail.com>
Reviewed by: emaste, jhb, cem (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24918
The flush is needed to prevent cross-process ret2spec, which is not handled
on kernel entry if IBPB is enabled but SMEP is present.
While there, add i386 RSB flush.
Reported by: Anthony Steinhauser <asteinhauser@google.com>
Reviewed by: markj, Anthony Steinhauser
Discussed with: philip
admbugs: 961
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Consistently use 'void *' for key schedules / key contexts instead
of a mix of 'caddr_t', 'uint8_t *', and 'void *'.
- Add a ctxsize member to enc_xform similar to what auth transforms use
and require callers to malloc/zfree the context. The setkey callback
now supplies the caller-allocated context pointer and the zerokey
callback is removed. Callers now always use zfree() to ensure
key contexts are zeroed.
- Consistently use C99 initializers for all statically-initialized
instances of 'struct enc_xform'.
- Change the encrypt and decrypt functions to accept separate in and
out buffer pointers. Almost all of the backend crypto functions
already supported separate input and output buffers and this makes
it simpler to support separate buffers in OCF.
- Remove xform_userland.h shim to permit transforms to be compiled in
userland. Transforms no longer call malloc/free directly.
Reviewed by: cem (earlier version)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24855
Match other architectures and print CPU information during
cpu_startup(). In particular, this prints the information after the
message buffer is initialized which allows it to be retrieved after
boot via dmesg(8).
While here, add some extern declarations to <machine/md_var.h> in
place of duplicated declarations in various source files.
Reviewed by: brooks
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24936
Rather than walking all of cpu_switch looking for the sequence of
instructions to patch, add a global label at the location that needs
the patch applied.
Reviewed by: brooks, Alfredo Mazzinghi <alfredo.mazzinghi_cl.cam.ac.uk>
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24931
Some time after r338418, I believe with -Os/-Oz -ffunction-sections
-fdata-sections, the bootprog_interp variable that held our "$Interpreter:"
marker started getting strip from all loaders, with exception to userboot
since it used bootprog_interp to determine what flavor of userboot it was.
At some point, it had been brought to my attention that this was no longer
working and I had worked up some potential solutions to use the variable
that involved printing it out. My vague recollection is that this was
rejected, and I forgot to explore the alternatives; I cannot find records of
this discussion anymore.
Fast forward to present day, Andrew reported that it was non-functional and
offered (effectively) this patch (sans comment) to stop the compiler from
optimizing it out by assigning it to a volatile variable. This removes
concerns about user-facing change while retaining the interpreter marker.
Furthermore, it could certainly be uglier.
Reported and tested by: Andrew Gierth <andrew_tao173.riddles.org.uk>
MFC after: 3 days
Update libarchive to 3.4.3
Relevant vendor changes:
PR #1352: support negative zstd compression levels
PR #1359: improve zstd version checking
PR #1348: support RHT.security.selinux from GNU tar
PR #1357: support for archives compressed with pzstd
PR #1367: fix issues in acl tests
PR #1372: child handling cleanup
PR #1378: fix memory leak from passphrase callback
These functions were added in 2001 and are currently unused.
copyinfrom() looks to have never been used. copyinstrfrom() was used
for two weeks before the code was refactored to remove it's sole use.
Reviewed by: brooks, kib
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24928
-development is long and awkward, and is also inconsistent with prior art
from the Linux world, which uses -dev (Debian) or -devel (Red Hat). Follow
the Debian convention, and similarly for debug info packages.
Also remove redundant pkgbase development tag from includes. We already tag
include files with package=runtime,dev; there is no need to separately tag
them as dev.
Discussed with: bapt
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24139
Changes since 20181221 are mostly portability related
hence the large gap in versions imported.
There are however some bug fixes, and a rework of filemon handling.
In NetBSD make/filemon/filemon_ktrace.c allows use of fktrace
and elimination of filemon(4) which has not had the TLC it needs.
FreeBSD filemon(4) is in much better shape, so bmake/filemon/filemon_dev.c
allows use of that, with a bit less overhead than the ktrace model.
Summary of changes from ChangeLog
o str.c: empty string does not match % pattern
plus unit-test changes
o var.c: import handling of old sysV style modifier using '%'
o str.c: refactor brk_string
o meta.c: meta_oodate, CHECK_VALID_META is too aggressive for CMD
a blank command is perfectly valid.
o meta.c: meta_oodate, check for corrupted meta file
earlier and more often.
* meta.c: meta_compat_parent check for USE_FILEMON
patch from Soeren Tempel
o meta.c: fix compat mode, need to call meta_job_output()
o job.c: extra fds for meta mode not needed if using filemon_dev
o meta.c: avoid passing NULL to filemon_*() when meta_needed()
returns FALSE.
o filemon/filemon_{dev,ktrace}.c: allow selection of
filemon implementation. filemon_dev.c uses the kernel module
while filemon_ktrace.c leverages the fktrace api available in
NetBSD. filemon_ktrace.c can hopefully form the basis for
adding support for other tracing mechanisms such as strace on
Linux.
o meta.c: when target is out-of-date per normal make rules
record value of .OODATE in meta file.
o parse.c: don't pass NULL to realpath(3)
some versions cannot handle it.
o parse.c: ParseDoDependency: free paths rather than assert
plus more unit-tests
After r358443 the vnode object lock no longer synchronizes concurrent
zfs_getpages() and zfs_write() (which must update vnode pages to
maintain coherence). This created a potential deadlock between ZFS
range locks and VM page busy locks: a fault on a mapped file will cause
the fault page to be busied, after which zfs_getpages() locks a range
around the file offset in order to map adjacent, resident pages;
zfs_write() locks the range first, and then must busy vnode pages when
synchronizing.
Solve this by adding a non-blocking mode for ZFS range locks, and using
it in zfs_getpages(). If zfs_getpages() fails to acquire the range
lock, only the fault page will be populated.
Reported by: bdrewery
Reviewed by: avg
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24839
