Take extra reference to security policy before calling crypto_dispatch().
Currently we perform crypto requests for IPSEC synchronous for most of
crypto providers (software, aesni) and only VIA padlock calls crypto
callback asynchronous. In synchronous mode it is possible, that security
policy will be removed during the processing crypto request. And crypto
callback will release the last reference to SP. Then upon return into
ipsec[46]_process_packet() IPSECREQUEST_UNLOCK() will be called to already
freed request. To prevent this we will take extra reference to SP.
Have lockstat(1) trace locks by name rather than by address.
Previously, lockstat(1) would use a lock's address as its identifier when
consuming data describing lock contention and hold events. After collecting
the requested data, it would use ksyms(4) to resolve lock addresses to
names. Of course, this doesn't work too well for locks contained in
dynamically-allocated memory. This change modifies lockstat(1) to trace the
lock names obtained from the base struct lock_object instead, leading to
output that is generally much more useful.
This change also removes the -c option, which is used to coalesce data for
locks in an array. It's not possible to support this option without also
tracing lock addresses, and since lock arrays in which the lock names are
distinct are not very common in FreeBSD, it's simpler to just remove the
option.
adrian [Wed, 30 Sep 2015 05:19:16 +0000 (05:19 +0000)]
modify the rssi logic a bit to actually return a useful rssi.
The fullmac firmware doesn't seem to populate a useful rssi indicator
in the RX descriptor, so if one plotted said values, they'd basically
look like garbage.
The reference driver implements a "get current rssi" firmware command
which I guess is really meant for station operation only (as hostap
operation would need rssi per station, not a single firmware read.)
So:
* populate sc_currssi during each calibration run;
* use this in the RX path instead of trying to reconstruct the RSSI
value and passing it around as a pointer;
* do up a quick hack to map the rssi hardware value to some useful
signal level;
* the survey results provide an RSSI value between 0..100, so just
do another quick hack to map it into some usefulish signal level;
* supply a faked noise floor - I haven't yet found how to pull it
out of the firmware.
The scan results and the station RSSI information is now more useful
for indicating signal strength / distance.
Stop hard-coding a 32-bit data model for USDT tests, and just use the native
model. This was causing many of the tests to fail on amd64 since USDT
support for 32-bit programs is currently non-functional.
When processing ICMP need frag message, ignore the suggested MTU unless it
is smaller than the current one for this connection. This is behavior
specified by RFC 1191, and this is how original BSD stack behaved, but this
was unintentionally regressed in r182851.
Reported & tested by: Richard Russo <russor whatsapp.com>
Differential Revision: D3567
Sponsored by: Nginx, Inc.
When stopping ugidfw, it is not enough to just try unloading the module. If
the module is built-in to the kernel then the kldunload will fail. Rather
than do this just check if there are rules and then remove them all.
Add requirement on FILESYSTEMS to ensure /usr is present for /usr/sbin/ugidfw
and /usr/bin/xargs. This was already effectively the ordering from rcorder(8).
The Sun RPC framework uses a netbuf structure to represent the
transport specific form of a universal transport address. The
structure is expected to be opaque to consumers. In the current
implementation, the structure contains a pointer to a buffer
that holds the actual address.
In rpcbind(8), netbuf structures are copied directly, which would
result in two netbuf structures that reference to one shared
address buffer. When one of the two netbuf structures is freed,
access to the other netbuf structure would result in an undefined
result that may crash the rpcbind(8) daemon.
Fix this by making a copy of the buffer that is going to be freed
instead of doing a shallow copy.
In addition to the ubldr file, also copy ubldr.bin to the
MS-DOS partition. This will help with transitioning to
a single arm/armv6 userland build which could be used for
all FreeBSD/armv6 images without UBLDR_LOADADDR being set
for each board (ultimately requiring a separate buildworld
for each currently).
Requested by: ian
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
When XSAVE support was added on amd64, the FPU save area was moved
out of 'struct pcb' and into a variable-sized region after the
structure. The kgdb code currently only reads the pcb. It does not
read in the FPU save area but instead passes stack garbage as the
FPU's saved context. Fixing this would mean determining the proper
size of the area and fetching it. However, this state is not saved
for running CPUs in stoppcbs[], so the callback would also have to
know to ignore those pcbs. Instead, just remove the call since it is
of limited usefulness. It results in kgdb reporting the state of the
FPU/SIMD registers in userland, not their current values in the kernel.
In particular, it does not report the correct state for any code in
the kernel which does use the FPU and would report incorrect values
in that case.
std: it is important that func name is never an empty string
otherwise DTRACE_ANCHORED() returns false and that makes stack()
insert a bogus frame at the top.
For example:
dtrace -n 'test:dtrace_test::sdttest { stack(); }
This change is not really a solution, but just a work-around.
The real solution is to record the probe's call site and to use
that for resolving a function name.
adrian [Tue, 29 Sep 2015 06:56:00 +0000 (06:56 +0000)]
rsu(4): Add support for 1T2R and 2T2R NICs.
This logic is mostly crimed from the reference driver and the linux
r92su driver.
I verified that it (a) worked on the rsu hardware I have, and (b)
did traffic testing whilst watching what ath(4) sent as a hostap.
It successfully sent MCS8..15 rates (which requires 2-stream reception)
as well as MCS0..7 (which is 1-stream.)
adrian [Tue, 29 Sep 2015 05:03:24 +0000 (05:03 +0000)]
urtwn driver fixes - missing include, free node references, shut down xfers first
* include opt_wlan.h like a good little wlan driver;
* add a function to free the mbufq /and/ the node references on it, or we will leak
said node references;
* free the mbufq upon NIC shutdown otherwise we may end up with a full list that
we never begin transmit work on, and thus never drain it;
* .. which frees it upon NIC detach too;
* ensure urtwn_start() gets called after the completion of frame TX even if the
pending queue is empty, otherwise transmit will stall. It's highly unlikely that
the usb tx queue would be empty whilst the incoming send queue is full, but hey,
who knows.
This passes some iperf testing with and without the NIC being actively removed during
said active iperf test.
Tested:
* urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R ; STA mode
adrian [Mon, 28 Sep 2015 01:09:48 +0000 (01:09 +0000)]
if_otus fixes; add fast-frames support.
Fast-frames:
* include opt_wlan.h ; tsk to not doing it earlier;
* add a tx pending tracking counter for seeing how deep
the hardware TX queue is;
* add the frame aging code from if_ath;
* add fast-frames capability to the driver setup.
Bugs:
* free the buffers (and node references) before
detaching net80211 state. This prevents a use-after-free in
the node free path where we've destroyed net80211 underneath it.
adrian [Mon, 28 Sep 2015 00:59:07 +0000 (00:59 +0000)]
Migrate the fast-frames transmit support away from using the txa_private
field and into a separate fast-frames staging pointer in ieee80211_node.
The A-MPDU TX path allows txa_private to be used by drivers. So it will
clash with any attempt to use fast-frames. Now, fast-frames is not really
anything special - it's just a custom ethernet frame type that contains
two MSDUs into one MPDU. So all the NIC has to support doing is transmitting
up to a 4KiB frame with an arbitrary ethertype and bam! Fast-frames.
However, using txa_private means we can /either/ do fast-frames or A-MPDU TX,
so fast frames has been turned off in the Atheros HAL for 11n chipsets.
This is a bit silly - it actually means that 802.11 performance to/from
11abg Atheros chips is actually better than between an 11abg atheros device
and an 11n Atheros device.
So:
* create a new mbuf staging queue for fast frames. It only queues a single
frame in the staging queue (and there's a top-level ic staging queue
used for expiry/tracking) so it's just an mbuf pointer per TID.
* Still use the ampdu TX packet counter to determine whether to do
aggregation or not. It'll double count if we start doing both A-MPDU TX
and fast frames, but that's not all that important right now.
* Initialise the pps tracker so ticks isn't zero. This ensures that
fast-frames actually gets used - without it, the ticks math overflows
and the pps math always sets txa_pps=0. This is the same bug that
plagued A-MPDU TX starting logic.
This actually allows fast-frames transmit to occur between the AR9331
(in 11n HT/20 mode) and AR9170 (if_otus) in 11bg mode.
Now, this is a great big no-op on atheros 11n hardware, so don't worry.
It may mean you start seeing more reliable fast-frames transmission on
11abg hardware which may expose some more amusing bugs.
TODO:
* further testing and debugging of all of this before flipping on
fast-frames in if_ath (for 11n) and if_otus.
adrian [Mon, 28 Sep 2015 00:17:51 +0000 (00:17 +0000)]
Abstract out the ampdu TX pps initialisation code so it can be reused
in the superg fast-frames code.
This harks back to an earlier commit (r280349) where I found that
initialising the pps code with ticks=0 would cause hilariously bad
hz ticks wraparound failures, leading to never actually aggregating
traffic. This is still true for the superg path and so I have to
do the same thing there.
This is a big no-op; a subsequent commit will flip this on so it
works with the fast-frames transmit path.
Tested:
* AR9170, otus(4) - STA mode, 11bg operation
* AR9331, AP mode
fnmatch(): Remove exponential behaviour as in sh r229201.
The old code was exponential in the number of asterisks in the pattern.
However, once a match has been found upto the next asterisk, the previous
asterisks are no longer relevant.
Initially function was introduced in r53541 (KAME initial commit) to
"provide hints from upper layer protocols that indicate a connection
is making "forward progress"" (quote from RFC 2461 7.3.1 Reachability
Confirmation).
However, it was converted to do nothing (e.g. just return) in r122922
(tcp_hostcache implementation) back in 2003. Some defines were moved
to tcp_var.h in r169541. Then, it was broken (for non-corner cases)
by r186119 (L2<>L3 split) in 2008 (NULL ifp in nd6_lookup). So,
right now this code is broken and has no "real" base users.
jeff [Sun, 27 Sep 2015 05:16:06 +0000 (05:16 +0000)]
- Collapse vfs_vmio_truncate & vfs_vmio_release into a single function.
- Allow vfs_vmio_invalidate() to free the pages, leaving us with a
single loop and bufobj lock when B_NOCACHE/B_INVAL is used.
- Eliminate the special B_ASYNC handling on free that has not been
relevant for some time.
- Remove the extraneous page busy from vfs_vmio_truncate().
rtsock requests for deleting interface address lles started to return EPERM
instead of old "ignore-and-return 0" in r287789. This broke arp -da /
ndp -cn behavior (they exit on rtsock command failure). Fix this by
translating LLE_IFADDR to RTM_PINNED flag, passing it to userland and
making arp/ndp ignore these entries in batched delete.
adrian [Sun, 27 Sep 2015 04:03:11 +0000 (04:03 +0000)]
Enforce consistent limits of daemons run from rc.subr:
* Allow the user to configure the login class to use in rc.conf
by using {daemon}_login_class, which;
* Use the daemon class by default;
* .. and then use 'limits' to set the login class so it works both
via init at startup (which runs this in 'daemon' class) and via
whichever root environment (eg command line, other daemons, etc.)
The conversion of kmem_alloc_attr() from operating on a vm map to a vmem
arena in r254025 introduced a bug in the case when an allocation is only
partially successful. Specifically, the vm object lock was not being
acquired before freeing the allocated pages. To address this bug, replace
the existing code by a call to kmem_unback().
Change the type of a variable in kmem_alloc_attr() so that an allocation
of two or more gigabytes won't fail.
Replace the error handling code in kmem_back() by a call to kmem_unback().
Exploit r288122 to address a cosmetic issue. Since the pages allocated
by noobj_alloc() don't belong to a vm object, they can't be paged out.
Since they can't be paged out, they are never enqueued in a paging queue.
Nonetheless, passing PQ_INACTIVE to vm_page_unwire() creates the appearance
that these pages are being enqueued in the inactive queue. As of r288122,
we can avoid giving this false impression by passing PQ_NONE.
Hookup mkcsmapper_static and mkesdb_static for all but install.
These are only handled as 'build-tools' in Makefile.inc1. This causes
'make clean' from the top of the tree to not clean the directories. It also
effectively has kept them disconnected and risks them bitrotting. The
buildworld process never cleans them either.
Connect them so they will always be built, cleaned, etc, but never installed.
Hookup mkcsmapper_static and mkesdb_static for all but install.
These are only handled as 'build-tools' in Makefile.inc1. This causes
'make clean' from the top of the tree to not clean the directories. It also
effectively has kept them disconnected and risks them bitrotting. The
buildworld process never cleans them either.
Connect them so they will always be built, cleaned, etc, but never installed.
projects / people / julieng / freebsd.git / log