dim [Tue, 22 Sep 2015 22:07:42 +0000 (22:07 +0000)]
MFC r286699:
In gcc's libcpp, stop using the INTTYPE_MAXIMUM() macro, which relies on
undefined behavior. The code used this macro to avoid problems on some
broken systems which define SSIZE_MAX incorrectly, but this is not
needed on FreeBSD, obviously.
MFC r287238:
Set DMA alignment constraint of status, TX and RX LEs(List Elements
in Marvell terms) to 32768. 32768 looks overkill but it will
ensure correct DMAed update. This change addresses occasional
watchdog timeouts reported on 10.2-RELEASE.
MFC r287320:
- uri is expected to be nul-terminated (strchr used later),
so use strlcpy instead of strncpy.
- replace the other two cases of strncpy+\0 with strlcpy.
MFC r286887: Using the error return code documented in the comment.
Though there is no direct midi_uninit() caller amongst existing drivers
at this moment, a quick experiment indicates that EBUSY gives users more
precise error message once drivers start to honour this result. For example,
emu_midi_detach() should check the result of mpu401_uninit() and block
module unloading if there is any MIDI I/O in progress.
ed [Mon, 14 Sep 2015 09:31:00 +0000 (09:31 +0000)]
MFC r286798 and r286827:
Stop parsing digits if the value already exceeds UINT_MAX / 100.
There is no need for us to support parsing values that are larger than
the maximum terminal window size. In this case that would be the maximum
of unsigned short.
The problem with parsing larger values is that they can cause integer
overflows when adjusting the cursor position, leading to all sorts of
failing assertions.
MFC r286981 and r287098:
Don't truncate cursor arithmetic to 16 bits.
When updating the row number when the cursor position escape sequence is
issued, we should make sure to store the intermediate result in a 32-bit
integer. If we fail to do this, the cursor may be set above the origin
region, which is bad.
This could cause libteken to crash when INVARIANTS is enabled, due to
the strict set of assertions that libteken has.
MFC 287440:
Currently the Linux character device mmap handling only supports mmap
operations that map a single page that has an associated vm_page_t.
This does not permit mapping larger regions (such as a PCI memory
BAR) and it does not permit mapping addresses beyond the top of RAM
(such as a 64-bit BAR located above the top of RAM).
Instead of using a single OBJT_DEVICE object and passing the physaddr via
the offset as a hack, create a new sglist and OBJT_SG object for each
mmap request. The requested memory attribute is applied to the object
thus affecting all pages mapped by the request.
MFC 283281,283282,283562,286158:
Various fixes to orphan handling which also fix issues with following
forks. Unlike the changes in HEAD, this merge does not include the
changes to the ATF ptrace test since ATF is not present in 9.
283281:
Always set p_oppid when attaching to an existing process via procfs
tracing. This matches the behavior of ptrace(PT_ATTACH). Also,
the procfs detach request assumes p_oppid is always set.
283282:
Only reparent a traced process to its old parent if the tracing process is
not the old parent. Otherwise, proc_reap() will leave the zombie in place
resulting in the process' status being returned twice to its parent.
283562:
Do not allow a process to reap an orphan (a child currently being
traced by another process such as a debugger). The parent process does
need to check for matching orphan pids to avoid returning ECHILD if an
orphan has exited, but it should not return the exited status for the
child until after the debugger has detached from the orphan process
either explicitly or implicitly via wait().
286158:
Clear P_TRACED before reparenting a detached process back to its
original parent. Otherwise the debugee will be set as an orphan of
the debugger.
MFC 269656,270024,270443,270993:
Fix problems with orphan handling. Note that to preserve KBI, p_treeflag
has been added to the end of struct proc and is explicitly zero'd during
fork.
269656:
Correct the problems with the ptrace(2) making the debuggee an orphan.
One problem is inferior(9) looping due to the process tree becoming a
graph instead of tree if the parent is traced by child. Another issue
is due to the use of p_oppid to restore the original parent/child
relationship, because real parent could already exited and its pid
reused (noted by mjg).
Add the function proc_realparent(9), which calculates the parent for
given process. It uses the flag P_TREE_FIRST_ORPHAN to detect the head
element of the p_orphan list and than stepping back to its container
to find the parent process. If the parent has already exited, the
init(8) is returned.
Move the P_ORPHAN and the new helper flag from the p_flag* to new
p_treeflag field of struct proc, which is protected by proctree lock
instead of proc lock, since the orphans relationship is managed under
the proctree_lock already.
The remaining uses of p_oppid in ptrace(PT_DETACH) and process
reapping are replaced by proc_realparent(9).
270024:
Correct the order of arguments passed to LIST_INSERT_AFTER().
270443:
Properly reparent traced processes when the tracer dies.
Previously they were uncoditionally reparented to init. In effect
it was possible that tracee was never returned to original parent.
270993:
Fix up proc_realparent to always return correct process.
Prior to the change it would always return initproc for non-traced
processes.
MFC 281941:
Watchdog drivers need to support rearming the watchdog in contexts which
are not permitted to sleep. Only use the IPMI watchdog with backends
which poll driver-initiated requests to meet this requirement.
In practice this means that watchdogs will no longer be used on systems
that use the SSIF backend.
MFC 248705,253812,253813:
- Unlock IPMI sc while performing requests via KCS and SMIC interfaces.
- empirical testing showed that 3 seconds is just too slow for GET_DEVICE_ID
to return on newer Dell hardware. Bump to 6 second timeouts until someone
has a better idea on how to handle this
- Check for ipmi_attached in ipmi_isa_probe as a suggested alternative to
ipmi_isa_attach. This keeps unintended but harmless noise about "ipmi1"
from appearing in the boot up sequence.
hselasky [Sat, 29 Aug 2015 06:17:39 +0000 (06:17 +0000)]
MFC r286799:
Fix race in USB PF which can happen if we stop tracing exactly when
the kernel is tapping an USB transfer. This leads to a NULL pointer
access. The solution is to only trace while the USB bus lock is
locked.
delphij [Wed, 19 Aug 2015 18:33:25 +0000 (18:33 +0000)]
Instant-MFC r286933:
Issue warning and refuse to proceed further if the configured
repository signature_type is unsupported by bootstrap pkg(7).
Previously, when signature_type specified an unsupported method,
the bootstrap pkg(7) would proceed like when signature_type is
"none". MITM attackers may be able to use this vulnerability and
bypass validation and install their own versions of pkg(8).
At this time, only fingerprint and none are supported by the
bootstrap pkg(7).
FreeBSD's official pkg(8) repository uses the fingerprint method
and is therefore unaffected.
edwin [Fri, 14 Aug 2015 00:00:24 +0000 (00:00 +0000)]
MFC of 286750,tzdata9:
Update to tzdata2015f:
Changes affecting future time stamps
North Korea switches to +0830 on 2015-08-15. (Thanks to Steffen Thorsen.)
The abbreviation remains "KST". (Thanks to Robert Elz.)
Uruguay no longer observes DST. (Thanks to Steffen Thorsen and Pablo Camargo.)
Changes affecting past and future time stamps
Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC. (Thanks to Roman Tudos.)
pfg [Thu, 13 Aug 2015 01:04:26 +0000 (01:04 +0000)]
MFC r286074:
GCC: Add a new option "-fstack-protector-strong"
This includes additional functions to be protected: those that
have local array definitions, or have references to local frame
addresses. This is a new option in GCC-4.9 that was relicensed
by Han Shen from Google under GPLv2.
rmacklem [Mon, 10 Aug 2015 22:30:13 +0000 (22:30 +0000)]
MFC: r285260
Since the case where secflavor < 0 indicates the security flavor is
to be negotiated, it could be a Kerberized mount. As such, filling
in the "principal" argument using the canonized host name makes sense.
If it is negotiated as AUTH_SYS, the "principal" argument is meaningless
but harmless.
rmacklem [Mon, 10 Aug 2015 22:26:14 +0000 (22:26 +0000)]
MFC: r285113
If a "principal" argument isn't provided for a Kerberized NFS mount,
the kernel would generate a bogus one with a ":/<path>" suffix.
This would only occur for the case where there was no explicit
"principal" argument and the getaddrinfo() call in mount_nfs.c failed to a
return a cannonical name for the server.
This patch fixes this unusual case.
rmacklem [Sun, 9 Aug 2015 22:33:51 +0000 (22:33 +0000)]
MFC: r286046
This patch fixes a problem where, if the NFSv4 server has a previous
unconfirmed clientid structure for the same client on the last hash list,
this old entry would not be removed/deleted. I do not think this bug would have
caused serious problems, since the new entry would have been before the old one
on the list. This old entry would have eventually been scavenged/removed.
rmacklem [Sun, 9 Aug 2015 22:29:10 +0000 (22:29 +0000)]
MFC: r284531
Document that a forced dismount of an NFSv3 mount when the
NLM (rpc.lockd) is running can crash the system.
Unfortunately this is not easy to fix, but I have left
PR#200585 open.
rmacklem [Sun, 9 Aug 2015 22:07:52 +0000 (22:07 +0000)]
MFC: r283273
The NFS client wasn't handling getdirentries(2) requests for sizes
that are not an exact multiple of DIRBLKSIZ correctly. Fortunately
readdir(3) always uses an exact multiple of DIRBLKSIZ, so few applications
were affected. This patch fixes this problem by reducing the size
of the directory read to an exact multiple of DIRBLKSIZ.
pfg [Wed, 5 Aug 2015 18:55:26 +0000 (18:55 +0000)]
MFC r285720:
libusb: Fix minor warning.
Fix a warning triggered by the gcc + FORTIFY_SOURCE patches:
In function 'libusb20_parse_config_desc': lib/libusb/libusb20_desc.c:141:
warning: passing argument 1 of 'memcpy' discards qualifiers from pointer
target type
davidcs [Wed, 5 Aug 2015 02:19:38 +0000 (02:19 +0000)]
MFC r285973
- Avoid lock contention in the if_transmit callback by using trylock and
enqueueing the frames when it fails. This way there is some latency
removed from the transmitting path.
- If IFF_DRV_OACTIVE is set (and also if IFF_DRV_RUNNING is not) just
enqueue the desired frames and return successful transmit. This way we
avoid to return errors on transmit side and resulting in
possible out-of-order frames. Please note that IFF_DRV_OACTIVE is set
everytime we get the threshold ring hit, so this can be happening quite
often.
marius [Thu, 30 Jul 2015 02:06:34 +0000 (02:06 +0000)]
MFC: r285839
o Revert the other functional half of r239864 (MFCed to stable/9 in r241681),
i. e. the merge of r134227 from x86 to use smp_ipi_mtx spin lock not only
for smp_rendezvous_cpus() but also for the MD cache invalidation, TLB
demapping and remote register reading IPIs due to the following reasons:
- The cross-IPI SMP deadlock x86 otherwise is subject to can't happen on
sparc64. That's because on sparc64, spin locks don't disable interrupts
completely but only raise the processor interrupt level to PIL_TICK. This
means that IPIs still get delivered and direct dispatch IPIs such as the
cache invalidation etc. IPIs in question are still executed.
- In smp_rendezvous_cpus(), smp_ipi_mtx is held not only while sending an
IPI_RENDEZVOUS, but until all CPUs have processed smp_rendezvous_action().
Consequently, smp_ipi_mtx may be locked for an extended amount of time as
queued IPIs (as opposed to the direct ones) such as IPI_RENDEZVOUS are
scheduled via a soft interrupt. Moreover, given that this soft interrupt
is only delivered at PIL_RENDEZVOUS, processing of smp_rendezvous_action()
on a target may be interrupted by f. e. a tick interrupt at PIL_TICK, in
turn leading to the target in question trying to send an IPI by itself
while IPI_RENDEZVOUS isn't fully handled, yet, and, thus, resulting in a
deadlock.
o As mentioned in the commit message of r245850, on least some sun4u platforms
concurrent sending of IPIs by different CPUs is fatal. Therefore, hold the
reintroduced MD ipi_mtx also while delivering cross-traps via MI helpers,
i. e. ipi_{all_but_self,cpu,selected}().
o Akin to x86, let the last CPU to process cpu_mp_bootstrap() set smp_started
instead of the BSP in cpu_mp_unleash(). This ensures that all APs actually
are started, when smp_started is no longer 0.
o In all MD and MI IPI helpers, check for smp_started == 1 rather than for
smp_cpus > 1 or nothing at all. This avoids races during boot causing IPIs
trying to be delivered to APs that in fact aren't up and running, yet.
While at it, move setting of the cpu_ipi_{selected,single}() pointers to
the appropriate delivery functions from mp_init() to cpu_mp_start() where
it's better suited and allows to get rid of the global isjbus variable.
o Given that now concurrent IPI delivery no longer is possible, also nuke
the delays before completely disabling interrupts again in the CPU-specific
cross-trap delivery functions, previously giving other CPUs a window for
sending IPIs on their part. Actually, we now should be able to entirely get
rid of completely disabling interrupts in these functions. Such a change
needs more testing, though.
o In {s,}tick_get_timecount_mp(), make the {s,}tick variable static. While not
necessary for correctness, this avoids page faults when accessing the stack
of a foreign CPU as {s,}tick now is locked into the TLBs as part of static
kernel data. Hence, {s,}tick_get_timecount_mp() always execute as fast as
possible, avoiding jitter.
marius [Thu, 30 Jul 2015 00:28:32 +0000 (00:28 +0000)]
MFC: r284447, r284552
Merge from NetBSD:
o rev. 1.10: Nuke trailing whitespace.
o rev. 1.15: Fix typo in comment.
o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22:
- PSE control register (0x0b)
- PSE status register (0x0c)
- MMD access control register (0x0d)
- MMD access address data register (0x0e)
o rev. 1.17 (comments only): The bit location of link ability is different
between 1000Base-X and others (see Annex 28B.2 and 28D).
o rev. 1.18: Nuke dupe word.
dim [Wed, 29 Jul 2015 19:37:32 +0000 (19:37 +0000)]
Merge r286033 from stable/10:
Reapply r286007, modified to compile with pre-C++11 compilers:
Pull in r219009 from upstream llvm trunk (by Adam Nemet):
[ISel] Keep matching state consistent when folding during X86 address match
In the X86 backend, matching an address is initiated by the 'addr' complex
pattern and its friends. During this process we may reassociate and-of-shift
into shift-of-and (FoldMaskedShiftToScaledMask) to allow folding of the
shift into the scale of the address.
However as demonstrated by the testcase, this can trigger CSE of not only the
shift and the AND which the code is prepared for but also the underlying load
node. In the testcase this node is sitting in the RecordedNode and MatchScope
data structures of the matcher and becomes a deleted node upon CSE. Returning
from the complex pattern function, we try to access it again hitting an assert
because the node is no longer a load even though this was checked before.
Now obviously changing the DAG this late is bending the rules but I think it
makes sense somewhat. Outside of addresses we prefer and-of-shift because it
may lead to smaller immediates (FoldMaskAndShiftToScale is an even better
example because it create a non-canonical node). We currently don't recognize
addresses during DAGCombiner where arguably this canonicalization should be
performed. On the other hand, having this in the matcher allows us to cover
all the cases where an address can be used in an instruction.
I've also talked a little bit to Dan Gohman on llvm-dev who added the RAUW for
the new shift node in FoldMaskedShiftToScaledMask. This RAUW is responsible
for initiating the recursive CSE on users
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076903.html) but it
is not strictly necessary since the shift is hooked into the visited user. Of
course it's safer to keep the DAG consistent at all times (e.g. for accurate
number of uses, etc.).
So rather than changing the fundamentals, I've decided to continue along the
previous patches and detect the CSE. This patch installs a very targeted
DAGUpdateListener for the duration of a complex-pattern match and updates the
matching state accordingly. (Previous patches used HandleSDNode to detect the
CSE but that's not practical here). The listener is only installed on X86.
I tested that there is no measurable overhead due to this while running
through the spec2k BC files with llc. The only thing we pay for is the
creation of the listener. The callback never ever triggers in spec2k since
this is a corner case.
dim [Wed, 29 Jul 2015 13:14:34 +0000 (13:14 +0000)]
Merge r286007 from stable/10:
Pull in r219009 from upstream llvm trunk (by Adam Nemet):
[ISel] Keep matching state consistent when folding during X86 address match
In the X86 backend, matching an address is initiated by the 'addr' complex
pattern and its friends. During this process we may reassociate and-of-shift
into shift-of-and (FoldMaskedShiftToScaledMask) to allow folding of the
shift into the scale of the address.
However as demonstrated by the testcase, this can trigger CSE of not only the
shift and the AND which the code is prepared for but also the underlying load
node. In the testcase this node is sitting in the RecordedNode and MatchScope
data structures of the matcher and becomes a deleted node upon CSE. Returning
from the complex pattern function, we try to access it again hitting an assert
because the node is no longer a load even though this was checked before.
Now obviously changing the DAG this late is bending the rules but I think it
makes sense somewhat. Outside of addresses we prefer and-of-shift because it
may lead to smaller immediates (FoldMaskAndShiftToScale is an even better
example because it create a non-canonical node). We currently don't recognize
addresses during DAGCombiner where arguably this canonicalization should be
performed. On the other hand, having this in the matcher allows us to cover
all the cases where an address can be used in an instruction.
I've also talked a little bit to Dan Gohman on llvm-dev who added the RAUW for
the new shift node in FoldMaskedShiftToScaledMask. This RAUW is responsible
for initiating the recursive CSE on users
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076903.html) but it
is not strictly necessary since the shift is hooked into the visited user. Of
course it's safer to keep the DAG consistent at all times (e.g. for accurate
number of uses, etc.).
So rather than changing the fundamentals, I've decided to continue along the
previous patches and detect the CSE. This patch installs a very targeted
DAGUpdateListener for the duration of a complex-pattern match and updates the
matching state accordingly. (Previous patches used HandleSDNode to detect the
CSE but that's not practical here). The listener is only installed on X86.
I tested that there is no measurable overhead due to this while running
through the spec2k BC files with llc. The only thing we pay for is the
creation of the listener. The callback never ever triggers in spec2k since
this is a corner case.
dim [Tue, 28 Jul 2015 09:19:04 +0000 (09:19 +0000)]
MFC r285340:
Fix swapped copyin(9) arguments in cxgb's iwch_arm_cq() function.
Detected by clang 3.7.0 with the warning:
sys/dev/cxgb/ulp/iw_cxgb/iw_cxgb_provider.c:309:18: error: variable
'rptr' is uninitialized when used here [-Werror,-Wuninitialized]
chp->cq.rptr = rptr;
^~~~
MFC r285735:
lseek() allows an offset to be set beyond the end of file. Using
it to check that partition has enough space to write bootcode doesn't
work. Use the known size of provider instead.
MFC r285663, r285664, r285667:
Ensure that locstat_nsecs() has no effect when lockstat probes are not
enabled or when the profiled lock carries the LO_NOPROFILE flag.
MFC r285088:
Fix broken implementation of "kvasprintf()" function by adding missing
kmalloc() call. Make function global instead of static inline to fix
compiler warnings about passing variable argument lists to inline
functions.
MFC r285253 (hrs):
- Add IPv6 support in quota(1). While rpc.rquotad has supported
PF_INET6 for a long time, quota(1) utility supported only PF_INET.
- Clean up confusing changes in f_mntfromname.
- Add an entry for rquotad with rpc/udp6 to inetd.conf.
By default, sendmail 8.15 uses uncompressed IPv6 addresses. Keep
current FreeBSD 10 and earlier behavior of using compressed IPv6
addresses in configuration, maps, rulesets, etc. (FreeBSD 11 and
later will use the new default of uncompressed IPv6 addresses.)
Allow parameters listed on the command line to override the -v option,
instead of crashing.
MFC r279083:
Fix the logic for skipping parameters (with -s) that have "jailsys"
parents (such as host.hostname); these were being skipped all the time.
That it went this long without anyone noticing is a sign that this feature
isn't actually used by anyone, but it's there so it might as well work.
MFC r279123:
Allow for parameters added with the JP_OPT flag to not exist.
That's why the flag exists in the first place.
* jail_setv will leak a parameter name if jailparam_import fails.
* jailparam_all loses the jailparam pointer on realloc error
(a clear freshman mistake).
* If jailparam_init fails, the caller doesn't need to jailparam_free
the buffer. That's not really clear, so set things to NULL allowing
jailparam_free to work without error (though it's still not required).
MFC r284593: MFV r284412: 5911 ZFS "hangs" while deleting file
illumos/illumos-gate@46e1baa6cf6d5432f5fd231bb588df8f9570c858
https://www.illumos.org/issues/5911
Sometimes ZFS appears to hang while deleting a file. It is actually
making slow progress at the file deletion, but other operations
(administrative and writes via the data path) "hang" until the file
removal completes, which can take a long time if the file has many
blocks. The deletion (or most of it) happens in a single txg, and the
sync thread spends most of its time reading indirect blocks...
Reviewed by: Bayard Bell <buffer.g.overflow@gmail.com>
Reviewed by: Alek Pinchuk <alek@nexenta.com>
Reviewed by: Simon Klinkert <simon.klinkert@gmail.com>
Reviewed by: Dan McDonald <danmcd@omniti.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
Author: Matthew Ahrens <mahrens@delphix.com>
marius [Sun, 5 Jul 2015 20:16:45 +0000 (20:16 +0000)]
MFC: r281337
Don't enable RX and TX before their initial configuration is done, i. e.
after setting up interrupt moderation but before turning interrupts on.
This matches what Realtek's r8168 Linux driver does as of version 8.039.00
and fixes problems with certain incarnations of certain MAC revisions
like the interface requiring an extra up/down-cycle after boot to start
working or DMA configuration not being adhered to.
marius [Sun, 5 Jul 2015 19:33:30 +0000 (19:33 +0000)]
MFC: r281751
Refine the workaround for Intel HSD131 [1] added in r269052 (MFCed to
stable/9 in r269593):
- Use the full mask described by the erratum as with a sufficiently high
number of these false-positives, the overflow bit (bit 62) additionally
gets set [7].
- HSD131 has been brought into several other Haswell-derived CPUs including
to the next generation, i. e. Intel Broadwell. Thus, also skip reporting of
these benign errors by default on CPU models affected by HSM142, HSW131 and
BDM48 [2 - 5], describing the HSD131 silicon bug for additional models.
Also, Celeron 2955U with a CPU ID of 0x45 have been reported to be covered
by this fault [6], with the specification update concerned with HSM142 [2]
only referring to 0x3c and 0x46.
Submitted by: David Froehlich [7]
Approved by: re (kib)