When using the processor ID value we mask off the low and high bits that
should be zero. Unfortunatly we don't shift the ID value so it won't be
affected. Add the shift when reading the ID as this will need to align
with the address based target value.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
ctx (and thus ctx.flags) is stack garbage at the start of this
function, so initialize ctx.flags to an explicit value instead of
using binary operations on the garbage.
Reported by: gcc9
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23368
This construction used some relatively slow design involving SHA2; even if
it were fed real entropy (unclear; external to the design), it did not
handle fork in a safe way, and it was difficult to audit for correctness.
So just rip it out and use the very simple and known-correct arc4random(3)
interface in its place.
ahd_inb() returns type uint8_t. The shift left by untyped 24 implicitly
promotes the result to type (signed) int. Then the binary OR with uint64_t
values sign-extends the integer. If bit 31 of the read value happened to be
set, the 64-bit result would have all upper 32 bits set to 1 due to OR. This
is clearly not intended.
Reported by: Coverity
CID: 980473 (old one!)
In apr_vformatter, the variable buf was declared inside a limited scope
region, but a pointer to it is leaked outside of that region and used
later. This is undefined behavior. Fix by moving the buf variable to
function scope.
Reported by: Coverity
CID: 1192541
Make completion event path mostly lockless using EPOCH(9).
Implement a mechanism using EPOCH(9) which allows us to make
the callback path for completion events mostly lockless.
Simplify draining callback events using epoch_wait().
While at it make sure all receive completion callbacks are
covered by the network EPOCH(9), because this is required
when calling if_input() and ether_input() after r357012.
Sponsored by: Mellanox Technologies
Software interrupt handlers are allowed to sleep. In swi_net() there
is a read lock behind NETISR_RLOCK() which in turn ends up calling
msleep() which means the whole of swi_net() cannot be protected by an
EPOCH(9) section. By default the NETISR_LOCKING feature is disabled.
This issue was introduced by r357004. This is a preparation step for
replacing the functionality provided by r357004.
Found by: kib@
Sponsored by: Mellanox Technologies
ThinkPad PrivacyGuard is a built-in toggleable privacy filter that
restricts viewing angles when on. It is an available on some new
ThinkPad models such as the X1 Carbon 7th gen (as an optional HW
upgrade).
The privacy filter can be enabled/disabled via an ACPI call. This commit
adds a sysctl under dev.acpi_ibm that allows for getting and setting the
PrivacyGuard state.
Submitted by: Kamila Součková <kamila@ksp.sk>
Reviewed By: cem, philip
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D23370
Make sure all occurrences of ieee80211_input_xxx() in sys/dev are
covered by a network epoch section. Do not depend on the interrupt
handler nor any taskqueues being in a network epoch section.
This patch should unbreak the PCI WLAN drivers after r357004.
Pointy hat: glebius@
Sponsored by: Mellanox Technologies
fflush_unlocked is currently desired in ports by sysutils/metalog, and
redefined as the locked fflush.
fputc_unlocked, fputs_unlocked, fread_unlocked, and fwrite_unlocked are
currently desired in ports by devel/elfutils, and redefined as the locked
fputs, fread, and fwrite respectively.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23336
This cuts out a large chunk of duplicated *.ucl files that just needed
dependencies tacked on, and gives generate-ucl.sh some leeway in case a
future pkg may need more than one dependency.
Run-through to determine which ones could simply be removed done with for i
in *.ucl; do diff -U3 template.ucl ${i}; done | less and inspecting for any
differences beyond just adding deps at the end. The remaining ucl files are
basically all differently-licensed, require scripts, or are marked vital.
I've opted to remove %PKGDEPS% entirely without regard for third-party ucl,
as pkgbase is not yet considered production. However, I do not hold a strong
position on this and there is approximately 0 chance it will return.
clibs should have been added previously in generate-ucl.sh as one that
doesn't have any dependencies, but do so now that we would otherwise be
tacking on the runtime dependency.
Reviewed by: manu, bapt (earlier version)
Differential Revision: https://reviews.freebsd.org/D23415
ZFS tracks if anything denies VEXEC to allow for a quick check for the
common case of path traversal. Use it.
Differential Revision: https://reviews.freebsd.org/D22224
With this change having the listmtx lock held postpones dooming the vnode.
Use this fact to simplify iteration over the lazy list. It also allows
filters to safely access ->v_data.
Reviewed by: kib (early version)
Differential Revision: https://reviews.freebsd.org/D23397
if_vlan grew a dependency on opt_inet6.h in r356993
if_lagg and if_vlan both grew a dependency on opt_kern_tls.h in r351522
This is needed for standalone module builds of these guys.
MAC is also almost universally a default; every GENERIC includes it, and
it's std.armv[67]. mips is again the oddball here with it only being
included in ERL/OCTEON1.
The only module currently working around this one is mac_veriexec, but it
looks like nothing it builds actually uses the MAC definition. Downstream
consumers enabling MAC in mips using mac_veriexec may be advised to do
something differently here in config.mk.
Fix the following -Werror warning from clang 10.0.0 in bsnmpd:
usr.sbin/bsnmpd/modules/snmp_bridge/bridge_port.c:1235:43: error: overlapping comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
begemotBridgeStpPortEnable_enabled ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
Work around it by casting the enum values to the type of val->v.integer.
MFC after: 3 days
usr.sbin/bsnmpd/modules/snmp_bridge/bridge_port.c:1235:43: error: overlapping comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
begemotBridgeStpPortEnable_enabled ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
Work around it by casting the enum values to the type of val->v.integer.
MFC after: 3 days
Fix the following -Werror warning from clang 10.0.0 in tip:
usr.bin/tip/tip/tip.c:428:4: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (gch == EOF)
^
usr.bin/tip/tip/tip.c:426:5: note: previous statement is here
} else if (!cumode && gch == character(value(FORCE)))
^
The intent was to have the EOF check grouped with the getchar() call
just above it. This was accidentally introduced in r354624.
MFC after: 3 days
Fix the following -Werror warning from clang 10.0.0 in procstat:
usr.bin/procstat/procstat_sigs.c:79:3: error: misleading indentation; statement is not part of the previous 'else' [-Werror,-Wmisleading-indentation]
xo_close_container(name);
^
usr.bin/procstat/procstat_sigs.c:77:4: note: previous statement is here
} else
^
The intent was to group the xo_close_container() call to the previous
snprintf() call.
MFC after: 3 days
usr.bin/tip/tip/tip.c:428:4: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (gch == EOF)
^
usr.bin/tip/tip/tip.c:426:5: note: previous statement is here
} else if (!cumode && gch == character(value(FORCE)))
^
The intent was to have the EOF check grouped with the getchar() call
just above it. This was accidentally introduced in r354624.
MFC after: 3 days
For untied module builds, we'll generate opt_foo headers if they're included
in SRCS. However, options that would normally be represented in opt_global.h
aren't properly represented.
Start generating opt_global.h with #define VIMAGE for !mips since it's
almost universally a project default and right now kmods must hack it in
themselves in order to be properly compiled for the default kernel. For
example, ^/sys/modules/pf/Makefile
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23345
The original intention for caroot was to be packaged separately, perhaps so
that users can have a more/less conservative upgrade policy for this
separated from the rest of base.
secure/caroot/Makefile doesn't have anything interesting to package, but its
subdirectories might. Move the PACKAGE= to Makefile.inc so both blacklisted
and trusted get packaged consistently into the correct one rather than the
default -utilities. Also tag the directories for package=caroot, as they
could also be empty; blacklisted is empty by default, but trusted is not.
Add a post-install script to do certctl rehash, along with a note should we
eventually come up with a way to detect that files have been added or
removed that requires a rehash.
-caroot gets a dependency on -utilities, as that's where we provide certctl
at the moment. We can perhaps reconsider this and put certctl into this
package in the future, but there are some bits within -utilities that
unconditionally invoke certctl so let's hold off for now.
Reviewed by: manu (earlier version, before -utilities dep added)
Differential Revision: https://reviews.freebsd.org/D23352
On some POWER8 machines, 'ibm,associativity' property may have 6
cells, which would overflow the 5 cells buffer being used.
There was also an issue with the "check if node is root" part,
that have been fixed too.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D23414
usr.bin/procstat/procstat_sigs.c:79:3: error: misleading indentation; statement is not part of the previous 'else' [-Werror,-Wmisleading-indentation]
xo_close_container(name);
^
usr.bin/procstat/procstat_sigs.c:77:4: note: previous statement is here
} else
^
The intent was to group the xo_close_container() call to the previous
snprintf() call.
MFC after: 3 days
[ELF] Map the ELF header at imageBase
If there is no readonly section, we map:
* The ELF header at imageBase+maxPageSize
* Program headers at imageBase+maxPageSize+sizeof(Ehdr)
* The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)
Due to the interaction between Writer<ELFT>::fixSectionAlignments and
LinkerScript::allocateHeaders,
`alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`.
The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal:
```
// PHDR at 0x401034, should be 0x400034
PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4
// R PT_LOAD contains just Ehdr and program headers.
// At 0x401000, should be 0x400000
LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000
LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000
```
* createPhdrs allocates the headers to the R PT_LOAD.
* fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text
* allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text)
* allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize`
The main observation is that when the SECTIONS command is not used, we
don't have to call allocateHeaders. This requires an assumption that
the presence of PT_PHDR and addresses of headers can be decided
regardless of address information.
This may seem natural because dot is not manipulated by a linker script.
The other thing is that we have to drop the special rule for -T<section>
in `getInitialDot`. If -Ttext is smaller than the image base, the headers
will not be allocated with the old behavior (allocateHeaders is called)
but always allocated with the new behavior.
The behavior change is not a problem. Whether and where headers are
allocated can vary among linkers, or ld.bfd across different versions
(--enable-separate-code or not). It is thus advised to use a linker
script with the PHDRS command to have a consistent behavior across
linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler
alternative.
Differential Revision: https://reviews.llvm.org/D67325
llvm-svn: 371957
This causes "ld: error: output file too large: 18446744073707016908
bytes" when linking our loader_4th and loader_lua. Clearly, something
is wrong when using -Ttext 0x0: I will file an upstream bug report for
this.
These are just direct copies of the template. If they don't exist but are
attempted to be used, generate-ucl.sh will simply fallback to the template
anyways. Let it do so to reduce potential maintenance burden.
The SD bit is defined as the MSB of the sstatus register, meaning its
position will vary depending on the CSR's length. Previously, there were
two (unused) defines for this, for the 32 and 64-bit cases, but their
definitions were swapped.
Consolidate these into one define: SSTATUS_SD, and make the definition
dependent on the value of __riscv_xlen.
Reviewed by: br
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D23402
It doesn't exist in mainline dts due to the issues related
with detaching and reattaching USB3 devices as mentioned in
https://patchwork.kernel.org/patch/10853381/
In case of FreeBSD, as a temporary workaround "usbconfig reset"
command can fix the problem.
Reviewed by: manu
Right now OOM is initiated unconditionally on the page allocation
failure, after the wait.
Reported by: Mark Millard <marklmi@yahoo.com>
Reviewed by: cy, markj
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D23409
In this path, we used va_start() without pairing it with va_end(). Add the
va_end(). (va_start() without paired va_end() is undefined behavior per the C
standard.)
"In many implementations, [va_end] is a do-nothing operation; but those
implementations that need it probably need it badly." - Rationale for the ANSI
C Programming Language, § 4.8.1.3.
Reported by: Coverity
CID: 1340539
While here, clean up magic numbers.
The memset(,0,) (and M_ZERO!) can just be removed; the bit_alloc() API already
zeros the allocation.
No functional change.
Reported by: Coverity
CID: 1378286
All of these uses of sizeof() were on the wrong type in relation to the pointer
passed to SYSCTL_ADD_PROC as arg1. Fortunately, none of the handlers actually
use arg2. So just don't pass a (non-zero) arg2.
Reported by: Coverity
CID: 1007701