The disk_* and part_* api is using 64bit values for media size and
offsets. However, the current api is using off_t type, which is signed
64-bit int.
In this context the signed media size does not make any sense, and
the offsets are used to mark absolute, not relative locations.
Also, the data from GPT partition table and some other sources is
already using uint64_t data type, so using signed off_t can cause sign
issues.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D8710
for EVFILT_READ at the point of the check not when the event is registers.
This fixes a problem with asio when accepting a connection.
Reviewed by: kib@, Scott Mitchell
Since we have dedicated libefi/env.c file for variable support, the following
changes are done:
Simple cstyle changes in env.c
Moved efi variable related commands from loader/main.c to libefi/env.c
Did create function to set "efi-version" environment variable in env.c.
This function does serve two purposes: for first a small clean up of the
loader main(), and for second, it does replace the otherwise unused
efi_variable_support hack.
A bit of cleanup of ficl backend functions. The TEST_MAIN has no meaning,
and removed few memory leaks.
The forth code is updated to use "efi-version" variable, instead of ficl
environment check.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D9165
atomic_fcmpset_*() is analogous to atomic_cmpset(), but saves off the
read value from the target memory location into the 'old' pointer.
Reviewed by: imp, brooks
Requested by: mjg
Differential Revision: https://reviews.freebsd.org/D9391
Freescale added the E.D profile to e500mc and derivative cores. From
Freescale's EREF reference manual this is enabled by a bit in HID0 and should
otherwise default to traditional debug. However, none of the Freescale cores
support that bit, and instead always use E.D. This results in kernel panics
using the standard debug on e500mc+ cores.
Enhanced debug allows debugging of interrupts, including critical interrupts,
as it uses a different save/restore registers (srr*). At this time we don't use
this ability, so instead share the core of the debug handler code between both
handlers.
MFC after: 3 weeks
space available for chunks. This unbreaks the handling of
ICMPV6 packets indicating "packet too big". It just worked
for IPv4 since we are overbooking for IPv4.
MFC after: 1 week
Flags
- IEEE80211_F_ASCAN
- IEEE80211_F_SIBSS
- IEEE80211_F_IBSSON
are not used since r170530 (old WI compatibility ioctls removal)
and r178354 (removed from other places).
IEEE80211_F_TXPOW_FIXED was never utilized; initially added with
IEEE80211_F_TXPOW_AUTO / IEEE80211_F_TXPOW_OFF flags,
which were replaced with IEEE80211_C_TXPMGT capability check in r138568.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9369
- Check for Chelsio vendor ID in probe routines.
- Fail attach instead of faulting if pci_find_dbsf() doesn't find a
device.
PR: 216539
Reported by: asomers
Tested by: Dave Baukus <daveb@spectralogic.com>
MFC after: 3 days
Sponsored by: Chelsio Communications
structure:
if_gethwtsomax(), if_sethwtsomax() - if_hw_tsomax
if_gethwtsomaxsegcount(), if_sethwtsomaxsegcount() - if_hw_tsomaxsegcount
if_gethwtsomaxsegsize(), if_sethwtsomaxsegsize() - if_hw_tsomaxsegsize
Update em and vnic drivers which had already been coverted to use accessor
functions for the other ifnet structure members.
Reviewed by: erj
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8544
of their sys_*() counterparts. The svr4 is left unchanged.
Reviewed by: kib@
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9379
The desired behavior of atomic_fcmpset_() is to always exit on error. Instead
of retrying on lost reservation, leave the retry to the caller, and return
error.
Reported by: kib
Derived from an implementation by Mark Adler.
The fast loop performs three simultaneous CRCs over subsets of the data
before composing them. This takes advantage of certain properties of
the CRC32 implementation in Intel hardware. (The CRC instruction takes 1
cycle but has 2-3 cycles of latency.)
The CRC32 instruction does not manipulate FPU state.
i386 does not have the crc32q instruction, so avoid it there. Otherwise
the implementation is identical to amd64.
Add basic userland tests to verify correctness on a variety of inputs.
PR: 216467
Reported by: Ben RUBSON <ben.rubson at gmail.com>
Reviewed by: kib@, markj@ (earlier version)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D9342
* Clang/llvm does not (yet) support -m(no-)spe, so make it gcc-only
* Clang now supports -msoft-float, and does not appear to recognize
"-disable-ppc-float-in-variadic", which appears to have been a crutch until
soft-float was implemented. It's now implemented for both 32- and 64-bit.
* Clang/llvm use a 'medium' code model by default for powerpc64, supporting up
to 4GB TOC, and does not support the '-mminimal-toc' option. Given both of
these, make -mminimal-toc gcc-only.
MFC after: 2 weeks
Ideally we'd have a top level hwpmc module with the shared bits, then
cpu specific glue as needed. However, on the MIPS side, there's no
probe code - {mips24k, mips74k, octeon} implement a set of methods
that hwpmc_mips.c expects.
So this populates separate modules with duplicate code.
Ew, but it does work.
This gets me off the hook - these work fine as copied into the relevant
mfsroot for mips24k/mips74k systems.
TODO:
* do it the "right" way in the future. Note that modules/hwpmc/ does
build fine on MIPS, it jusn't DO anything. So it'd be nice to
maybe call that "hwpmc_core" and then "hwpmc" can be the CPU/arch glue.
Thought it's difficult to reproduce, I think this variable was responsible
for a use-after-free panic when a SATA disk timed out responding to a SATA
identify command during boot.
Submitted by: slm
Reviewed by: slm
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9364
We can iterate over consecutive resident pages in the top-level object
using the object's page list rather than by performing lookups in the
object radix tree. This extends one of the optimizations in r312208 to the
case where a shadow chain is present.
Suggested by: alc
Reviewed by: alc, kib (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9282
The checks have quadratic complexity over a number of advisory locks
active for a file and that could be a lot. What's the worse is that the
checks are done while holding ls_lock. That could lead to a long a very
long backlog and performance degradation even if all requested locks are
compatible (e.g. all shared locks).
The checks used to be under INVARIANTS.
Discussed with: kib
MFC after: 2 weeks
Sponsored by: Panzura
instead of their sys_*() counterparts in various compats. The svr4
is left untouched, because there's no point.
Reviewed by: ed@, kib@
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9367
This would enqueue an event to send the gratuitous arp on a dying lagg
interface without any physical ports attached to it.
Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too
late, when the ifp data structure is already freed. Fix that too.
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
There are no alternatives defined, so there's no point in keeping them. Also,
they weren't around every inline asm block anyway. Without __GNUCLIKE_ASM
defined, the guarded functions return garbage.
Reported by: Andrew Thompson
Clang complains about the shift of (1 << 7) into a int8_t changing the value:
warning: implicit conversion from 'int' to 'int8_t' (aka 'signed char') changes
value from 128 to -128 [-Wconstant-conversion]
Squash this warning by forcing clang to see it as an unsigned bit.
This seems odd, given that it's still a conversion of 128->-128, but I'm
guessing the explicit unsigned attribute notifies clang that sign really doesn't
matter in this case.
Reported by: Mark Millard <markmi AT dsl-only DOT net>
MFC after: 2 weeks
Summary:
Clang throws the following warning in powerpc intr_machdep:
/usr/src/sys/powerpc/powerpc/intr_machdep.c:454:15: warning: comparison of
constant -1 with expression of type 'enum intr_trigger' is always false
[-Wtautological-constant-out-of-range-compare]
if (i->trig == -1)
~~~~~~~ ^ ~~
This may lead to legitimate problems with aggressive optimizations, if not now
then in the future. To avoid this, add a new enum, INTR_TRIG_INVALID, set to
-1, and use this new enumeration in these checks.
Test Plan: Compile test.
Reviewed By: jhb, kib
Differential Revision: https://reviews.freebsd.org/D9300
Summary:
atomic_fcmpset_*() is analogous to atomic_cmpset(), but saves off the read value
from the target memory location into the 'old' pointer in the case of failure.
Requested by: mjg
Differential Revision: https://reviews.freebsd.org/D9325
After some digging and looking at packet traces, it looks like the
sequence number allocation being done by net80211 doesn't meet
802.11-2012.
Specifically, group addressed frames (broadcast, multicast) have
sequence numbers allocated from a separate pool, even if they're
QoS frames.
This patch starts to try and address this, both on transmit and
receive.
* When receiving, don't throw away multicast frames for now.
It's sub-optimal, but until we correctly track group addressed
frames via another TID counter, this is the best we can do.
* When doing A-MPDU checks, don't include group addressed frames
in the sequence number checks.
* When transmitting, don't allocate group frame sequence numbers
from the TID, instead use the NONQOS TID for allocation.
This may fix iwn(4) 11n because I /think/ this was one of the
handful of places where ni_txseqs[] was being assigned /outside/
of the driver itself.
This however doesn't completely fix things - notably the way that
TID assignment versus WME assignment for driver hardware queues
will mess up multicast ordering. For example, if all multicast
QoS frames come from one sequence number space but they're
expected to obey the QoS value assigned, they'll end up in
different queues in the hardware and go out in different
orders.
I can't fix that right now and indeed fixing it will require some
pretty heavy lifting of both the WME<->TID QoS assignment, as well
as figuring out what the correct way for drivers to behave.
For example, both iwn(4) and ath(4) shouldn't put QoS multicast
traffic into the same output queue as aggregate traffic, because
the sequence numbers are all wrong. So perhaps the correct thing
to do there is ignore the WME/TID for QoS traffic and map it all
to the best effort queue or something, and ensure it doesn't
muck up the TID/blockack window tracking. However, I'm /pretty/
sure that is still going to happen.
.. maybe I should disable multicast QoS frames in general as well,
but I don't know what that'll do for whatever the current state
of 802.11s mesh support is.
Tested:
* STA mode, ath10k NIC
* AP mode, AR9344/AR9580 AP
* iperf tcp/udp tests with concurrent multicast QoS traffic.
Before this, iperfs would fail pretty quickly because the sending
AP would start sending out QoS multicast frames that would be
out of order from the rest of the TID traffic, causing the blockack
window to get way, way out of sync.
This now doesn't occur.
TODO:
* verify which QoS frames SHOULD be tagged as M_AMPDU_MPDU.
For example, QoS NULL frames shouldn't be tagged!
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9357
protection change.
On superpage promotion, x86 pmaps do not invalidate existing 4K
entries for the superpage range, because they are compatible with the
promoted 2/4M entry. But the invalidation on superpage removal or
protection change only did single INVLPG with the base address of the
superpage. This reliably flushed superpage TLB entry, and 4K entry
for the first page of the superpage, potentially leaving other 4K TLB
entries lingering. Do the invalidation of the whole superpage range
to correct the problem.
Note that the precise invalidation is done by x86 code for kernel_pmap
only, for user pmaps whole (per-AS) TLB is flushed. This made the bug
well hidden, because promotions of the kernel mappings require
specific load.
Reported and tested by: Jonathan Looney <jtl@netflix.com> (previous version)
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
convention for interfaces, because only one stf(4) interface can exist
in the system.
This disallow the use of unit numbers different than 0, however, it is
possible to create the clone without specify the unit number (wildcard).
In the wildcard case we must update the interface name before return.
This fix an infinite recursion in pf code that keeps track of network
interfaces and groups:
1 - a group for the cloned type of the interface is added (stf in this
case);
2 - the system will now try to add an interface named stf (instead of
stf0) to stf group;
3 - when pfi_kif_attach() tries to search for an already existing 'stf'
interface, the 'stf' group is returned and thus the group is added
as an interface of itself;
This will now cause a crash at the first attempt to traverse the groups
which the stf interface belongs (which loops over itself).
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
in the i386 pmap.
The curcpu macro loads the per-cpu data pointer as its first step,
so the remaining steps of pcpu_find(curcpu) are circular.
get_pcpu() is already implemented for arm, arm64, and risc-v.
My plan is to implement it for the remaining architectures and use
it to replace several instances of pcpu_find(curcpu) in MI code.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9370
-G0 is sufficent except on old version of clang (<3.8) and such versions
are unlikely to be generally useful on mips64.
Reported by: sbruno
Sponsored by: DARPA, AFRL
