eugen [Mon, 6 Nov 2017 11:10:43 +0000 (11:10 +0000)]
MFC r324364: ftpd(8): fix user context handling
Apply authenticated user context after update of wtmp(5) at start of session,
so that ftpd process is not killed by kernel with SIGXFSZ when user has
"filesize" limit lower than size of system wtmp file. Same applies
to session finalization: revert to super-user context before update of wtmp.
If ftpd hits limit while writing a file at user request,
do not get killed with SIGXFSZ instantly but apparently ignore the signal,
process error and report it to the user, and continue with the session.
pfg [Sat, 4 Nov 2017 14:44:07 +0000 (14:44 +0000)]
MFC r325066:
Fix out-of-bounds read in libc/regex.
The bug is an out-of-bounds read detected with address sanitizer that
happens when 'sp' in p_b_coll_elems() includes NUL byte[s], e.g. if it's
equal to "GS\x00". In that case len will be equal to 4, and the
strncmp(cp->name, sp, len) call will succeed when cp->name is "GS" but the
cp->name[len] == '\0' comparison will cause the read to go out-of-bounds.
Checking the length using strlen() instead eliminates the issue.
The bug was found in LLVM with oss-fuzz:
https://reviews.llvm.org/D39380
Obtained from: Vlad Tsyrklevich through posting on openbsd-tech
jilles [Fri, 3 Nov 2017 22:41:31 +0000 (22:41 +0000)]
MFC r325017: libnv: Fix strict-aliasing violation with cookie
In r323851 (MFC'ed to stable/11 as r324831), some casts were adjusted in
calls to nvlist_next() and nvlist_get_pararr() in order to make scan-build
happy. I think these changes just confused scan-build into not reporting
the strict-aliasing violation.
For example, nvlist_xdescriptors() is causing nvlist_next() to write to its
local variable nvp of type nvpair_t * using the lvalue *cookiep of type
void *, which is not allowed. Given the APIs of nvlist_next(),
nvlist_get_parent() and nvlist_get_pararr(), one possible fix is to create a
local void *cookie in nvlist_xdescriptors() and other places, and to convert
the value to nvpair_t * when necessary. This patch implements that fix.
rmacklem [Thu, 2 Nov 2017 20:28:53 +0000 (20:28 +0000)]
MFC: r324639
Fix the client IP address reported by nfsdumpstate for 64bit arch and NFSv4.1.
The client IP address was not being reported for some NFSv4 mounts by
nfsdumpstate. Upon investigation, two problems were found for mounts
using IPv4. One was that the code (originally written and tested on i386)
assumed that a "u_long" was a "uint32_t" and would exactly store an
IPv4 host address. Not correct for 64bit arches.
Also, for NFSv4.1 mounts, the field was not being filled in. This was
basically correct, because NFSv4.1 does not use a callback address.
However, it meant that nfsdumpstate could not report the client IP addr.
This patch should fix both of these issues.
For IPv6, the address will still not be reported. The original NFSv4 RFC
only specified IPv4 callback addresses. I think this has changed and, if so,
a future commit to fix reporting of IPv6 addresses will be needed.
jkim [Thu, 2 Nov 2017 18:20:05 +0000 (18:20 +0000)]
MFC: r316607 (andrew)
Fix linking with lld by marking OPENSSL_armcap_P as hidden.
Linking with lld fails as it contains a relative address, however the data
this address is for may be relocated from the shared object to the main
executable.
Fix this by adding the hidden attribute. This stops moving this value to
the main executable. It seems this is implicit upstream as it uses a
version script.
mav [Thu, 2 Nov 2017 10:38:09 +0000 (10:38 +0000)]
MFC r324752: Relax per-ifnet cif_vrs list double locking in carp(4).
In all cases where cif_vrs list is modified, two locks are held: per-ifnet
CIF_LOCK and global carp_sx. It means to read that list only one of them
is enough to be held, so we can skip CIF_LOCK when we already have carp_sx.
This fixes kernel panic, caused by attempts of copyout() to sleep while
holding non-sleepable CIF_LOCK mutex.
mmel [Thu, 2 Nov 2017 07:08:13 +0000 (07:08 +0000)]
MFC r324660:
Save VFP state in getcontext(3) on ARM. This is a last followup of r315974,
which fixes userland part of VFP save/restore problems described in PR
217611.
Evaluate packet size after the firewall had its chance in the ip6 fast path
Defer the packet size check until after the firewall has had a look at it. This
means that the firewall now has the opportunity to (re-)fragment an oversized
packet.
This mirrors what the slow path does.
Anticongestion refinements for ntpd rc script. This checks if ntp
leapfile needs fetching before entering into the anticongestion sleep.
Unfortunately some ports still use their own sleeps so, this commit
doesn't address the complete problem which is compounded by every
port that uses its own anticongestion mechanism.
FreeBSD notes:
- this MFV reverts FreeBSD commit r314549 to make the merge easier
- at present our emulation of cv_timedwait_hires is rather poor,
so I elected to use cv_timedwait_sbt directly
Please see the differential revision for details.
Unfortunately, I did not get any positive reviews, so there could be
bugs in the FreeBSD-specific piece of the merge.
Hence, the long MFC timeout.
https://www.illumos.org/issues/8585
The current implementation of zil_commit() can introduce significant
latency, beyond what is inherent due to the latency of the underlying
storage. The additional latency comes from two main problems:
1. When there's outstanding ZIL blocks being written (i.e. there's
already a "writer thread" in progress), then any new calls to
zil_commit() will block waiting for the currently oustanding ZIL
blocks to complete. The blocks written for each "writer thread" is
coined a "batch", and there can only ever be a single "batch" being
written at a time. When a batch is being written, any new ZIL
transactions will have to wait for the next batch to be written,
which won't occur until the current batch finishes.
As a result, the underlying storage may not be used as efficiently
as possible. While "new" threads enter zil_commit() and are blocked
waiting for the next batch, it's possible that the underlying
storage isn't fully utilized by the current batch of ZIL blocks. In
that case, it'd be better to allow these new threads to generate
(and issue) a new ZIL block, such that it could be serviced by the
underlying storage concurrently with the other ZIL blocks that are
being serviced.
2. Any call to zil_commit() must wait for all ZIL blocks in its "batch"
to complete, prior to zil_commit() returning. The size of any given
batch is proportional to the number of ZIL transaction in the queue
at the time that the batch starts processing the queue; which
doesn't occur until the previous batch completes. Thus, if there's a
lot of transactions in the queue, the batch could be composed of
many ZIL blocks, and each call to zil_commit() will have to wait for
all of these writes to complete (even if the thread calling
zil_commit() only cared about one of the transactions in the batch).
Reviewed by: Brad Lewis <brad.lewis@delphix.com>
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Prakash Surya <prakash.surya@delphix.com>
cy [Sun, 29 Oct 2017 04:33:50 +0000 (04:33 +0000)]
Sync (make same) the offsetof macro definition in include/ with the
definition of the same in sys/sys/. The problem was discovered while
working on implementing a new C11 gets_s() for libc. (The new gets_s()
requires rsize_t found in include/stddef.h.) The solution to sync the two
definitions was suggested by ed@ while discussing D12667.
rmacklem [Wed, 25 Oct 2017 19:27:12 +0000 (19:27 +0000)]
MFC: r324506
Fix forced dismount when a pNFS mount is hung on a DS.
When a "pnfs" NFSv4.1 mount is hung because of an unresponsive DS,
a forced dismount wouldn't work, because the RPC socket for the DS
was not being closed. This patch fixes this.
This will only affect "pnfs" mounts where the pNFS server's DS
is unresponsive (crashed or network partitioned or...).
Found during testing of the pNFS server.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: Igor Kozhukhov <igor@dilos.org>
Reviewed by: Andrew Stormont <andyjstormont@gmail.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Yuri Pankov <yuri.pankov@nexenta.com>
https://www.illumos.org/issues/3871
GCC 4.5.3 on Gentoo Linux did not like a few of the changes made in the issue
3604 patch. It printed an error and a couple of warnings:
../../cmd/zdb/zdb.c: In function 'dump_bpobj':
../../cmd/zdb/zdb.c:1257:3: error: 'for' loop initial declarations are only
allowed in C99 mode
../../cmd/zdb/zdb.c:1257:3: note: use option -std=c99 or -std=gnu99 to compile
your code
../../cmd/zdb/zdb.c: In function 'dump_deadlist':
../../cmd/zdb/zdb.c:1323:8: warning: too many arguments for format
../../cmd/zdb/zdb.c:1323:8: warning: too many arguments for format
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: Richard Yao <ryao@gentoo.org>
https://www.illumos.org/issues/6866
Need this for #6865.
To be generally more scripting-friendly, overload this issue with adding '-q'
option which should skip printing any label information.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: John Kennedy <john.kennedy@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Yuri Pankov <yuri.pankov@nexenta.com>
https://www.illumos.org/issues/7280
zdb is very handy for diagnosing problems with a pool in a safe and
quick way. When a pool is in a bad shape, we often want to disable some
fail-safes, or adjust some tunables in order to open them. In the
kernel, this is done by changing public variables in mdb. The goal of
this feature is to add the same capability to zdb and ztest, so that
they can change libzpool tuneables from the command line.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Pavel Zakharov <pavel.zakharov@delphix.com>
jch [Tue, 24 Oct 2017 08:56:11 +0000 (08:56 +0000)]
MFC r324179, r324193:
r324179:
Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has
been destroyed before its tcptw with INVARIANTS undefined.
This is a symmetric change of r307551:
A INP_TIMEWAIT inp should not be destroyed before its tcptw, and INVARIANTS
will catch this case. If INVARIANTS is undefined it will emit a log(LOG_ERR)
and avoid a hard to debug infinite loop in tcp_tw_2msl_scan().
Reported by: Ben Rubson, hselasky
Submitted by: hselasky
Tested by: Ben Rubson, jch
Sponsored by: Verisign, inc
Differential Revision: https://reviews.freebsd.org/D12267
r324193:
Forgotten bits in r324179: Include sys/syslog.h if INVARIANTS is not defined
dim [Tue, 24 Oct 2017 06:49:06 +0000 (06:49 +0000)]
MFC r324826:
Pull in r316035 from upstream llvm trunk (by Tim Northover):
AArch64: account for possible frame index operand in compares.
If the address of a local is used in a comparison, AArch64 can fold
the address-calculation into the comparison via "adds".
Unfortunately, a couple of places (both hit in this one test) are not
ready to deal with that yet and just assume the first source operand
is a register.
This should fix an assertion failure while building the test suite of
www/firefox for AArch64.
bdrewery [Tue, 24 Oct 2017 00:51:11 +0000 (00:51 +0000)]
MFC r318246,r324566,r324668,r324701:
r318246:
Add a regression test for r318191.
r324566:
Fix shadowed variable hidden by WARNS changing to 3 in r313006.
r324668:
This child is expected to exit on SIGTRAP, don't leave a core behind.
r324701:
Add a test for r324671 along with some other masked tests.
emaste [Tue, 24 Oct 2017 00:32:20 +0000 (00:32 +0000)]
MFC r324683: write.2: correct maximum nbytes size for EINVAL error
In FreeBSD 11 and later debug.iosize_max_clamp defaults to 0, and the
maximum nbytes count for write(2) is SSIZE_MAX. Update the man page to
document this, and mention the sysctl that can be set to obtain the
previous behaviour.
bdrewery [Mon, 23 Oct 2017 18:25:21 +0000 (18:25 +0000)]
MFC r316286:
Add support for capturing 'struct ptrace_lwpinfo' for signals resulting in a
process dumping core in the corefile.
Direct stable changed: Padding added to struct thread and td_si added to end
with explicit bzeroing when forking/initializing a thread to preserve KBI.
kib [Sun, 22 Oct 2017 08:47:13 +0000 (08:47 +0000)]
MFC r323772, r324302-r324308, r324310, r324313, r324315, r324326, r324330,
r324334, r324354-r324355, r324366, r324432-r324433, r324437-r324439:
Fixes and improvements for x86 LDT handling.
oshogbo [Sat, 21 Oct 2017 19:37:25 +0000 (19:37 +0000)]
MFC r323858:
IMHO it is possible that failure will be treated as success because we don't
initialize nvp on every loop iteration and the code under 'fail'(!) label
detects success by checking of nvp != NULL.
oshogbo [Sat, 21 Oct 2017 19:34:54 +0000 (19:34 +0000)]
MFC r323851:
Remove redundant initialization. Don't use variable - just return the value.
Make scan-build happy by casting to 'void *' instead of 'void **'.
Submitted by: pjd@
Found by: scan-build and cppcheck
Sponsored by: Wheel Systems
oshogbo [Sat, 21 Oct 2017 19:33:31 +0000 (19:33 +0000)]
MFC r323854:
Because nvp wasn't initialized on every loop iteration once we jumped
to 'fail' on error it was treated as success, because nvp!=NULL. Fix this
by not handling success under 'fail' label and by using separate variable
for parent nvpair.
If we succeeded to allocate nvlist, but failed to allocated nvpair we
would leak nvls[ii] on return. Destroy it when we cannot allocate nvpair,
before we goto fail.
Submitted by: pjd@ and oshogbo@ (minor changes)
Found by: scan-build
Sponsored by: Wheel Systems
oshogbo [Sat, 21 Oct 2017 19:30:33 +0000 (19:30 +0000)]
MFC r323852:
The 'while (array != NULL) { }' suggests scan-build that array may be
initially NULL, which is not possible. Change the loop to
'do {} while (array != NULL)' to satisfy scan-build and assert that
array really cannot be NULL just in case.
Submitted by: pjd@
Found by: scan-build
MFC after: 1 month
Sponsored by: Wheel Systems
hselasky [Fri, 20 Oct 2017 10:04:43 +0000 (10:04 +0000)]
MFC r324445:
When showing the sleepqueues from the in-kernel debugger,
properly dump all the sleepqueues and not just the first one
History:
It appears that in the commit which introduced the code,
r165272, the array indexes of "sq_blocked[0]" and "td_name[i]"
were interchanged. In r180927 "td_name[i]" was corrected to
"td_name[0]", but "sq_blocked[0]" was left unchanged.
projects / FreeBSD / FreeBSD.git / log