that they still work. These utilities have become out of sync with the
code in the kernel and need work to bring them back into shape.
Most people test on real systems or VMs on real networks.
Suggested by: glebius
that they still work. These utilities have become out of sync with the
code in the kernel and need work to bring them back into shape.
Most people test on real systems or VMs on real networks.
Sugested by: glebius
- unconditionally enable BUS_DMA on non-x86 architectures
- speed up rxd zeroing via customized function
- support out of order updates to rxd's
- add prefetching to hardware descriptor rings
- only prefetch on 10G or faster hardware
- add seperate tx queue intr function
- preliminary rework of NETMAP interfaces, WIP
Submitted by: Matt Macy <mmacy@nextbsd.org>
Sponsored by: Limelight Networks
This was introduced on accident in r165243, when return sites were unified
to add a lock around LibAliasProxyRule().
PR: 217749
Submitted by: Svyatoslav <razmyslov at viva64.com>
Sponsored by: Viva64 (PVS-Studio)
out of order addresses
Move `port->transport` initialization before the TAILQ_FOREACH(..) loop
to ensure that the value is properly initialized before it's inserted
into the TAILQ.
MFC after: 1 week
PR: 217760
Submitted by: eugen
Sponsored by: Dell EMC Isilon
This ensures the storage isn't leaked when non-NULL and the function
returns early, prior to the `free(vendor)` later on in the function.
MFC after: 1 week
Reported by: Coverity
CID: 1007111-1007113
Reviewed by: cem
Sponsored by: Dell EMC Isilon
Differential Revision: D9993
- Add comma before and after 'e.g.'; remove surrounding parentheses
that were unnecessary after this change [1].
- Add .Mt when referencing ken and Peter Dufault's email addresses
[2].
- Sprinkle around .An use where proper [2].
Bump .Dd for the change
MFC after: 1 week
Reported by: igor [1], manlint [2]
Reviewed by: imp
Sponsored by: Dell EMC Isilon
Differential Revision: D9968
The memory stored by `lease` would have previously been leaked if an
unterminated lease declaration was found in an early-return code path.
MFC after: 1 week
Reported by: clang static analyzer, Coverity
CID: 1007114
Submitted by: Tom Rix <trix@juniper.net>
Sponsored by: Dell EMC Isilon; Juniper, Inc
Differential Revision: D9992
As part of (eventual) p2p/tdls/multi-STA support, a lot of global configuration
parameters (WME, ERP (slot, preamble), channel width, HT protmode, etc are the
biggest offenders) should be per-VAP.
For multi-BSS VAP operation they may be linked, but for p2p/TDLS
operation that can be off-channel they can definitely be different
(think: 2GHz STA, 5GHz p2p.)
The global configuration view of these is mostly a "configure the current
non-smart-firmware NIC" view. This should be split up into per-VAP state,
then a global non-smart-firmware-NIC management layer to handle channel
changes and such in software.
This is step one in a loooong road for this. It should be a big non-functional
change for everyone.
* create a per-VAP WME update call.
* call it if its set, and call the global callback if it isn't
This still uses global WME state - it's just preparation for a future change
which will make the WME state per-VAP and fall through to a shared WME
configuration for hostap operation.
Note: this requires a full kernel recompile; the internal net80211 ABI has changed.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9986
This allows me to accurately test this scenario, and for others to rely
on the behavior, instead of relying on knowledge obtained via code
inspection.
Wording borrowed from free(3).
MFC after: 1 week
Requested by: ken (D9928)
Reviewed by: imp
Sponsored by: Dell EMC Isilon
Differential Revision: D9969
The netipsec headers are referenced via netipsec/..., not ./... .
Thus, assuming that the netipsec/... is nested under ${SRCTOP}/sys/netipsec
is wrong.
This tripped up some individuals building ^/head on systems pre-r314812.
MFC after: 1 week
Reported by: Roberto Rodriguez Jr <rob.rodz.jr9@gmail.com>
Sponsored by: Dell EMC Isilon
Make sure that uinput state field reflects actual state by checking
evdev_register result for errors
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
Differential Revision: https://reviews.freebsd.org/D9320
Prefer SRCTOP over CURDIR/../../contrib, etc. However, retain the "up
one level" instances of ../ because they are really relative to this
part of the tree and not a means to find the root of the tree. As
such, it's better to leave them since that further the goal of being
able to move directories if watned to in the future.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)
Transition to SRCTOP. Also, standardize of {} instead of () variable
deliminators while I'm here.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)
Use SRCTOP in place of .CURDIR/.. as appropriate. The hand-crafted
relative paths for the "links" option remain, though, since those are
relative to /usr/include/sys/<blah> not to the source tree.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)
Prefer ${SRCTOP}/ to ${.CURDIR}/../ and ${.CURDIR}/../../ as appropriate.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)
Prefer ${SRCTOP}/foo over ${.CURDIR}/../../foo and ${SRCTOP}/usr.bin/foo
over ${.CURDIR}/../foo for paths in Makefiles.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence on: arch@ (twice)
libpam: extra bounds checking through reallocarray(3).
It appears to be causing brokenness when reporting PAM_* environment
variables. This requires more investigation.
Reported by: lstewart
reallocarray(3) is a non portable extension that originated in OpenBSD.
Given that it is already in FreeBSD's libc it is useful for the cases
where reallocation involves a multiplication.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9955
