lagg_bcast_start appeared to have a bug in that was using the last
lagg port structure after exiting the epoch that was keeping that
structure alive. However, upon further inspection, the epoch was
already entered by the caller (lagg_transmit), so the epoch enter/exit
in lagg_bcast_start was actually unnecessary.
This commit generally removes uses of the net epoch via LAGG_RLOCK to
protect the list of ports when the list of ports was already protected
by an existing LAGG_RLOCK in a caller, or the LAGG_XLOCK.
It also adds a missing epoch enter/exit in lagg_snd_tag_alloc while
accessing the lagg port structures. An ifp is still accessed via an
unsafe reference after the epoch is exited, but that is true in the
current code and will be fixed in a future change.
Reviewed by: gallatin
MFC after: 1 month
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D19718
and use the space to make the "tps" one character longer.
It makes the iostat(8) output a bit less messed up.
Reviewed by: allanjude
MFC after: 2 weeks
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D19710
This makes it easier for googletest users to leverage googletest, instead of
forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in
unnecessary duplication).
I will be following this up with a more proper fix in src.libnames.mk, as
src.libnames.mk should be automatically adding this directory to
CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result
in mismatches between base-provided private library's and ports-provided
library's headers.
While here, tweak the comment to clarify what the intent is behind spamming
CXXFLAGS.
MFC after: 5 weeks
MFC with: r345203
Reported by: asomers
Reviewed by: asomers
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D19731
It started truncating its color arg to 8 bits using plot() in r229415.
The version in r229415 is also more than 3 times slower in segmented
modes, by doing more syscalls to move the window.
segmented modes.
Also fix some style bugs in the 2 changed lines. libvgl uses a very non-KNF
style with 2-column indentation with no tabs except for regressions.
Highlights:
- Bugfix for order in which /delete-node/ and /delete-property/ are
processed [0]
- /omit-if-no-ref/ support has been added (used only by U-Boot at this
point, in theory)
- GPL dtc compat version bumped to 1.4.7
- Various small fixes and compatibility improvements
Reported by: strejda [0]
MFC after: 1 week
Consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 and
transmitted by bridge0 through em1 gets accounted for in IPACKETS/IBYTES
and bridge0 bpf -- assuming it's not unicast traffic destined for em1.
Unicast traffic destined for em1 traffic is not accounted for by any
mechanism, and isn't pushed through bridge0's bpf machinery as any other
packets that pass over the bridge do.
Fix this and simplify GRAB_OUR_PACKETS by bailing out early if it was rx'd
by the interface that it was addressed for. Everything else there is
relevant for any traffic that came in from one member that's being directed
at another member of the bridge.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19614
r345620 by kib@ fixed the rtld issue that caused a crash at startup
during resolution of libc's ifuncs with BIND_NOW.
PR: 233333
Sponsored by: The FreeBSD Foundation
It looks like some DIMMs claim to have a TSOD, but actually don't. Some
claim they weren't able to change the SPD page, but they did. Neither of
those should be fatal errors.
PR: 235944
Submitted by: Greg V <greg@unrelenting.technology>
Reported by: Greg V <greg@unrelenting.technology>
Reviewed by: cem
MFC after: 1 weeks
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D19681
r322369's use of basename(3) was incorrect and worked by accident so
long as the pidfile path was absolute or consisted of a single
component. Fix the basename() usage and add a regression test.
Reported by: 0mp
Reviewed by: cem
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D19728
We were doing so as a workaround for the problem addressed by r345593, so
it's no longer necessary.
Reviewed by: jhb
Discussed with: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19705
Relative directories may appear in the line number program for a CPU if
files were included via a relative path, for instance with "-I.".
Previously, dwarf_srclines(3) and dwarf_srcfiles(3) would return the
relative path, so addr2line, for instance, would do the same. However,
we can get an absolute path by prepending the compilation directory, so
change libdwarf to do that to improve compatibility with GNU binutils
and since it is more useful in general.
Reviewed by: jhb
Discussed with: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19705
Reading of single pixels didn't look under the cursor.
Copying of 1x1 bitmaps didn't look under the cursor for either reading
or writing.
Copying of larger bitmaps looked under the cursor for at most the
destination.
Copying of larger bitmaps looked under a garbage cursor (for the Display
bitmap) when the destination is a MEMBUF. The results are not used, so
this only wasted time and flickered the cursor.
Writing of single pixels looked under a garbage cursor for MEMBUF
destinations, as above except this clobbered the current cursor and
didn't update the MEMBUF. Writing of single pixels is not implemented
yet in depths > 8. Otherwise, writing of single pixels worked. It was
the only working case for accessing pixels under the cursor.
Clearing of MEMBUFs wasted time freezing the cursor in the Display bitmap.
The fixes abuse the top bits in the color arg to the cursor freezing
function to control the function. Also clear the top 8 bits so that
applications can't clobber the control bits or create 256 aliases for
every 24-bit pixel value in depth 32.
Races fixed:
Showing and hiding the cursor only tried to avoid races with the mouse
event signal handler for internal operations. There are still many
shorter races from not using volatile or sig_atomic_t for the variable
to control this. This variable also controls freezes, and has more
complicated states than before.
The internal operation of unfreezing the cursor opened a race window
by unsetting the signal/freeze variable before showing the cursor.
RISC-V timer has no dedicated DTS node and we have to get timer
frequency from cpus node.
Tested on Government Furnished Equipment (GFE) cores synthesized
on Xilinx VCU118.
Reviewed by: markj
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D19727
upstream: when checking that filenames sent by the server side
match what the client requested, be prepared to handle shell-style brace
alternations, e.g. "{foo,bar}".
"looks good to me" millert@ + in snaps for the last week courtesy
deraadt@
OpenBSD-Commit-ID: 3b1ce7639b0b25b2248e3a30f561a548f6815f3e
Discussed with: des
Obtained from: OpenSSH-portable 3d896c157c722bc47adca51a58dca859225b5874
upstream: when checking that filenames sent by the server side
match what the client requested, be prepared to handle shell-style brace
alternations, e.g. "{foo,bar}".
"looks good to me" millert@ + in snaps for the last week courtesy
deraadt@
OpenBSD-Commit-ID: 3b1ce7639b0b25b2248e3a30f561a548f6815f3e
Discussed with: des
depths for the source and target are not supported. The bits for higher
numbered planes (mostly for red) were either not copied or were copied to
lower numbered planes for nearby pixels.
Quick fix for creation of mouse cursor bitmaps in all depths. This fix is
only complete for the default lightwhite cursor with a black frame.
Even the lightwhite and black colors are hard to find. The templates
use 0xff for lightwhite, but that means brightblue in the simplest mode
(Truecolor depth 24). Other modes are even more complicated -- they are
singly or doubly indirect throught palette(s) and changing of the palettes
by applications is supported.
Details:
Replicate the template value for Truecolor modes to fill out the target
depth (and more for depths not a multiple of 8). Do this for every
drawing of the cursor so that it sort of works for mouse cursor bitmaps
set by applications.
Use 0xf for lightwhite in most other modes. Only do this for the
default cursor so that it doesn't affect mouse cursor bitmaps set by
applications. 0xf mostly works because it was originally for CGA
lightwhite and is emulated using 1 or 2 indirections on EGA and VGA.
0x3f (EGA white) and 0xff (VGA black) direct palette indexes mostly
don't work since backwards compatibility inhibits or prevents them
representing lightwhite. But 0x3f (EGA white) must be used for mode
37 (VGA_MODEX) (320x240x8 V) since this mode is closer to EGA than VGA.
Remove redundant npxsave_core definition while here.
Suggested by: Anton Rang
Reviewed by: kib, Anton Rang <rang AT acm.org>
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D19665
The WITH_PORT_BASE_{BINUTILS,GCC} options are used to prevent 'make check-old'
and 'make delete-old' from deleting files installed by the base/binutils
and base/gcc packages as normally one disables the in-tree variants
(e.g. WITHOUT_BINUTILS) when using these packages.
Reviewed by: bapt (earlier version)
Differential Revision: https://reviews.freebsd.org/D19483
This was missed in r342139 when timed(8) was removed and fixes a
warning when running makeman to regenerate src.conf.5.
Differential Revision: https://reviews.freebsd.org/D19486
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS.
Note that in some cases there are small differences in the generated
output, so CLANG_NO_IAS should be removed only after testing (or after
finding no differences in the output). For zfsldr I compared objdump
output between GNU as- and Clang IAS-built zfsldr and .text was
identical (changes were limited to the object's ELF headers and debug
info).
Sponsored by: The FreeBSD Foundation
Direct /etc/rc exec was introduced in r337321, with a fallback to
passing it to sh if direct exec fails. "Can't exec" is slightly
misleading in this case (the script is still executed, just not
directly).
In most cases kernel.bootfile is populated from the information
provided by loader(8). There are certain scenarios when loader
is not available, for instance when kernel is loaded by u-boot
or some other BootROM directly. In this case the default value
"/kernel" points to invalid location and breaks some functinality,
like using installkernel on self-hosted system or dtrace's CTF
lookup. This can be fixed by setting the value manually but the
default that reflects correct location is better than default that
points to invalid one.
Current default was set around FreeBSD 1, when "/kernel" was the
actual path. Transition to /boot/kernel/kernel happened circa FreeBSD 3.
PR: 221550
Reviewed by: ian, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18902
CAM_RESRC_UNAVAIL instead of CAM_REQUEUE_REQ. This makes CAM delay a bit
before retrying, so that the retries actually get a chance to succeed.
Reviewed by: sbruno
MFC after: 2 weeks
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D19696
It makes the code slightly easier to follow, and might make
it easier to fix the resouce accounting to also account for
the interpreter.
The PROC_UNLOCK() is moved earlier - I don't see anything
it should protect; the lim_max() is a wrapper around lim_rlimit(),
and that, differently from lim_rlimit_proc(), doesn't require
the proc lock to be held.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D19689
was unlocked and yet the bucket-unlock flag was not
changed to false. This can cause a panic if INVARIANTS
is on and we go through the right path (though rare).
Reported by: syzbot+179a1ad49f3c4c215fa2@syzkaller.appspotmail.com
Reviewed by: tuexen@
MFC after: 1 week
