the data sheets leads me to believe these will just work. Those parts
with the various media readers on them may not have the required
FreeBSD drivers that will attach to the subdevices that will be seen
on some of these parts.
PCI 1515, 1530, 1620, 4520, 6411, 6420, 7410, 7510, 7610
Prompted by: Havard Eidnes
These are from the datasheets downloaded from TI's web site.
They describe the PCI[67]x[12]1 and PCI[67]x20 parts, with and without
the smartcard enabled.
kmem_alloc_pageable(). The difference between these is that an errant
memory access to the zone will be detected sooner with
kmem_alloc_nofault().
The following changes serve to eliminate the following lock-order
reversal reported by witness:
1st 0xc1a3c084 vm object (vm object) @ vm/swap_pager.c:1311
2nd 0xc07acb00 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1797
3rd 0xc1804bdc vm object (vm object) @ vm/uma_core.c:931
There is no potential deadlock in this case. However, witness is unable
to recognize this because vm objects used by UMA have the same type as
ordinary vm objects. To remedy this, we make the following changes:
- Add a mutex type argument to VM_OBJECT_LOCK_INIT().
- Use the mutex type argument to assign distinct types to special
vm objects such as the kernel object, kmem object, and UMA objects.
- Define a static swap zone object for use by UMA. (Only static
objects are assigned a special mutex type.)
individual file object implementations can optionally acquire Giant if
they require it:
- soo_close(): depends on debug.mpsafenet
- pipe_close(): Giant not acquired
- kqueue_close(): Giant required
- vn_close(): Giant required
- cryptof_close(): Giant required (conservative)
Notes:
Giant is still acquired in close() even when closing MPSAFE objects
due to kqueue requiring Giant in the calling closef() code.
Microbenchmarks indicate that this removal of Giant cuts 3%-3% off
of pipe create/destroy pairs from user space with SMP compiled into
the kernel.
The cryptodev and opencrypto code appears MPSAFE, but I'm unable to
test it extensively and so have left Giant over fo_close(). It can
probably be removed given some testing and review.
thread-local pointer, in practice that thread needs to be curthread. If
we're running with INVARIANTS, generate a warning if not. If we have
KDB compiled in, generate a stack trace. This doesn't fire at all in my
local test environment, but could be irritating if it fires frequently
for someone, so there will be motivation to fix things quickly when it
does.
the caller passes in a td that is curthread, and consistently pass 'td'
into vget(). Remove some bogus logic that passed in td or curthread
conditional on td being non-NULL, which seems redundant in the face of
the earlier assignment of td to curthread if td is NULL.
In devfs_symlink(), cache the passed thread in 'td' so we don't have
to keep retrieving it from the 'ap' structure, and assert that td is
curthread (since we dereference it to get thread-local td_ucred). Use
'td' in preference to curthread for later lockmgr calls, since they are
equal.
- 'savech' is only used if it is set a few lines above where
it is used, initialize it to silence warning.
- 'length' is either -1 or greater than 0, hence it is safe to cast it
to unsigned when comparing it here.
odsyntax.c:
- 'p' is assigned either (*argvp)[0] or (*argvp)[1] which both are
char *. 'num' and 'end' are assigned values based on 'p'.
Hence use char * instead of unsigned char * for these variables.
'&end' as the second argument to strtoll does not need to be casted
to char** any more.
This solves a
'dereferencing type-punned pointer will break strict-aliasing rules'
warning when compiling with -O2.
parse.c:
- 'prec' is only used when sokay == USEPREC and sokay = USEPREC
when 'prec' is assigned. Hence 'prec' is not used uninitialized,
initialize it to silence warning.
- The code involving 'nextpr' is hard to follow, but I belive
'nextpr' will not be used unless it is initialized.
Anyway, IF 'nextpr' is used uninitialized it is better to
get a consistant error (seg fault, when dereferencing a NULL pointer)
than potentially accessing some random memory.
The above changes makes hexdump WARNS=6 clean even when compiled with
-O2. Hence bump WARNS to keep it clean.
Tested by: CFLAGS='-O2 -pipe' make universe
to the PR failed, because the line skipping function is actually called
from two places in the code to do quite different things (this should
be two functions probably): in a false .if to skip to the next line
beginning with a dot and to collect .for loops. In the seconds case we
should not skip comments, because they are actually harder to handle than
we need for the .if case and should defer this to the main code.
PR: bin/25627
Submitted by: Seth Kingsley (original patch)
It does survive « make release ».
Uses an upcoming patch from the vendor branch (ntp-stable) of ntp-keygen.
Submitted by: Marius Strobl <marius@alchemy.franken.de>
and saved link register as per the ABI call sequence. Update code
that uses this (fork_trampoline etc) to use the correct genassym'd
offsets.
This fixes the 'invalid LR' message when backtracing kernel
threads in DDB.
being incomplete, it currently has to know how to drop and pick back
up the vm_object's mutex if it has to sleep and drop the page queue
mutex. The problem with this is that if the page is busy, while we
are sleeping, the page can be freed and object disappear. When trying
to lock m->object, we'd get a stale or NULL pointer and crash.
The object is now cached, but this makes the assumption that
the object is referenced in some manner and will not itself
disappear while it is unlocked. Since this only happens if
the object is locked, I had to remove an assumption earlier in
contigmalloc() that reversed the order of locking the object and
doing vm_page_sleep_if_busy(), not the normal order.
(WITNESS) for code paths that always call uma_zalloc_arg() shortly
after where the check was, because uma_zalloc_arg() already does
a similar check.
No objections from Alfred. Thanks Alfred.
RTF_BLACKHOLE as well.
To quote the submitter:
The uRPF loose-check implementation by the industry vendors, at least on Cisco
and possibly Juniper, will fail the check if the route of the source address
is pointed to Null0 (on Juniper, discard or reject route). What this means is,
even if uRPF Loose-check finds the route, if the route is pointed to blackhole,
uRPF loose-check must fail. This allows people to utilize uRPF loose-check mode
as a pseudo-packet-firewall without using any manual filtering configuration --
one can simply inject a IGP or BGP prefix with next-hop set to a static route
that directs to null/discard facility. This results in uRPF Loose-check failing
on all packets with source addresses that are within the range of the nullroute.
Submitted by: James Jun <james@towardex.com>
you've specified a directory. It is intended to be used in building
custom releases over NFS where locking may be unreliable at best and
there is no contention that the locking is designed to arbitrate.
Other uses of this flag are discouraged. Document same in usage and
man page (including the warning about unwise).
Sponsored by: Timing Solutions
(1) use strlcpy instead of strncpy since the use here of the latter
was incorrect.
(2) Move 'N' case into proper sorted order (sorted the same way that
ls sorts its args).
work very infrequently, and often results in a compound panic which
confuses debugging; locking/SMP have made the layering violation (and
risks) of this more obvious over time.
Discussed with: green, bde, et al.
