Include <stdarg.h> instead of <machine/stdarg.h> when compiled as
part of libsbuf. The former is the standard header, and allows us
to compile libsbuf on macOS/linux.
r314397 (by scottl):
Implement sbuf_prf(), which takes an sbuf and outputs it
to stdout in the non-kernel case and to the console+log
in the kernel case. For the kernel case it hooks the
putbuf() machinery underneath printf(9) so that the buffer
is written completely atomically and without a copy into
another temporary buffer. This is useful for fixing
compound console/log messages that become broken and
interleaved when multiple threads are competing for the
console.
r314399 (by scottl):
Add prototype for sbuf_putbuf()
r314419 (by jkim):
Include stdio.h to fix libsbuf build.
r314420 (by scottl):
Provide a comment on why stdio.h needs to be included.
r314533 (by scottl):
Expose the sbuf_putbuf() symbol to libsbuf. There are a few other symbols
that are present but not exposed, like get/set/clear flags, not sure if they
need to be exposed at this point.
r316553:
sbuf(3): expose sbuf_{clear,get,set}_flags(3) via libsbuf
These functions were added to sbuf(9) in r279992, but never
exposed to userspace. Expose them now so they can be used/tested.
The testcase fails today, so mark it with atf_expect_fail: in
particular, the target (B) isn't being unlinked and the documentation
doesn't suggest special handling for directories. Thus, there's either
a doc or an implementation bug in ln(1) that needs to be resolved.
MFC with: r319714, r319854, r319855
PR: 219943
r320172:
ln(1): fix -F behavior
When '-F' option is used, the target directory needs to be unlinked.
Currently, the modified target ("target/source") is being unlinked, and
since it doesn't yet exist, the original target isn't removed.
This is fixed by skipping the block where target is modified to
"target/source" when '-F' option is set.
Hence, a symbolic link (with the same name as of the original target) to
the source_file is produced.
Update the test for ln(1) to reflect fix for option '-F'
PR: 219943
r320173:
Don't expect :sF_flag to fail anymore
While here, also add a check to verify that the link target
is updated in the testcase
The tests exercise -f (f_flag), -n (n_flag), and no arguments (basic).
r319841:
Add initial tests for stat(1)
Testcases for -H, -L, and -f haven't been implemented yet, in part due
to additional complexity needed to validate the features:
* -H and -f will require an external "helper" program to display/modify
the state/permissions for a given path.
* -L is being covered partially via the -n testcase today.
r320723:
Use %e instead of %d with x_output_date(..)
stat -x doesn't 0-fill days so %d is inappropriate. %e is correct.
MFC with: r319841
r320724:
:l_flag:: be more aggressive when normalizing whitespace
Save output from ls -ldT and stat -l, then normalize all repeating whitespace using
sed to single column spaces.
This makes the test flexible with single-digit days, etc, similar to r320723. This
approach is just a bit more of a hammer approach because of how the columns are
ordered/spaced in both ls and stat.
Start writing up some basic feature tests for procstat
These tests query a running process for information related to the -b,
-c, -e, and -f flags; the -f testcase is largely stubbed out, pending
additional work to determine a good, deterministic descriptor.
Core file test support is coming soon--it requires a bit more effort
due to the fact that:
- coredumps can be disabled (kern.coredump=0).
- corefiles can be put in different directories than the current
directory, or be named something other than `<prog>.core`
(`kern.corefile`).
MFC: r320458
Fix an NFSv3 client case that probably never happens.
If an NFSv3 server were to reply with weak cache consistency attributes,
but not post operation attributes, the client would use garbage attributes
from memory. This was spotted during work on the code for the NFSv4.1 client.
I have never seen evidence that this happens and it wouldn't make sense
for an NFSv3 server to do this, so this patch is basically "theoretical",
but does fix the problem if a server were to do the above.
MFC: r320345
Add support to the NFSv4.1/pNFS client for commits through the DS.
A NFSv4.1/pNFS server using File Layout can specify that Commit operations
are to be done against the DS instead of MDS. Since no extant pNFS
server did this, the code was untested and "#ifdef notyet".
The FreeBSD pNFS server I am developing does specify that Commits be done
through the DS, so the code has been enabled/tested.
This patch should only affect the case of a pNFS server that specfies
Commits through the DS.
Move the SCTP syscalls to netinet with the rest of the SCTP code. The
syscalls themselves are tightly coupled with the network stack and
therefore should not be in the generic socket code.
The following four syscalls have been marked as NOSTD so they can be
dynamically registered in sctp_syscalls_init() function:
sys_sctp_peeloff
sys_sctp_generic_sendmsg
sys_sctp_generic_sendmsg_iov
sys_sctp_generic_recvmsg
The syscalls are also set up to be dynamically registered when COMPAT32
option is configured.
As a side effect of moving the SCTP syscalls, getsock_cap needs to be
made available outside of the uipc_syscalls.c source file. A proper
prototype has been added to the sys/socketvar.h header file.
API tests from the SCTP reference implementation have been run to ensure
compatibility. (http://code.google.com/p/sctp-refimpl/source/checkout)
Modify kern___getcwd() to take max pathlen limit as an additional
argument. This will be used for the Linux emulation layer - for Linux,
PATH_MAX is 4096 and not 1024.
MFC r320876:
Make sure the mlx4en RX DMA ring gets stamped with software ownership
in order to prevent the flow of QP to error in the firmware once
UPDATE_QP is called.
MFC r300761, r300762:
r300761:
Disconnect the AZURE target from the CLOUDWARE list.
Microsoft has graciously overtaken publication of FreeBSD
on Azure since 10.3-RELEASE.
Many thanks to Microsoft for their support of FreeBSD on
Azure.
r300762:
Disconnect the OPENSTACK target from the CLOUDWARE list.
This was reported to not work as expected, and feedback
following the report was never received. In addition, we
do not publish these anywhere publicly.
MFC r320906: MFV r320905: Import upstream fix for CVE-2017-11103.
In _krb5_extract_ticket() the KDC-REP service name must be obtained from
encrypted version stored in 'enc_part' instead of the unencrypted version
stored in 'ticket'. Use of the unecrypted version provides an
opportunity for successful server impersonation and other attacks.
marius [Tue, 11 Jul 2017 21:52:11 +0000 (21:52 +0000)]
MFC: r320577, r320620
Retry up to 2 ms to enable bus power as at least with some Intel
SDHCI/eMMC controllers the first attempt after a D3 to D0 transition,
i. e. when the firmware has put the devices into D3 state before,
can fail.
Remove waiters check from the inline rw wunlock routine.
This is a direct commit to stable/10.
r310979 is a merge of depessimisation of locking primitives.
The important part was getting rid of an attempt to grab the lock in the
slow path immediately after the fast path failed. In addition to that
temporary checks were added before all atomic ops. They have no impact on
semantic nor correctness, they only avoid an atomic operation which is
likely to fail.
After the addition of atomic_fcmpset and further changes said checks
became pessimal and got removed. This may get merged to stable/10.
Reports started showing up about a crash in all branches having extra
checks. The codepath is:
.. -> vm_map_delete -> __rw_wunlock_hard -> turnstile_broadcast
The kernel crashed trying to wake up nonexistent waiters. The lock value
as found in the vmcore matches the panicking thread, so in particular
there was no waiters bit set. The bit can only be cleared by the current
owner.
A debug patch was provided, which reportedly had a side effect of getting
rid of the issue.
Also one of the reporters said that reverting the patch which adds the
extra checks makes the crash go away.
It was also reported that head with the fcmpset changes (explicit checks
removed) also stops crashing.
Finally, one user tested crashing stable/10 variant with just the rw
wunlock check removed.
The common case in all but one reports was an Intel Atom cpu. Claiming
a cpu bug at this point is bold and I'm going to refrain from it, but
right now apart from cpu-specific optimisation made by the compiler on
custom kernel compiles I don't see how this can be a software bug.
This will have to be investigated more.
Meanwhile, restore rw wunlock to pre-r310979 state.
MFC r320408:
ext2fs: Support e2di_uid_high and e2di_gid_high.
The fields exist on all versions of the filesystem and using them is a mount
option on linux. For FreeBSD, the corresponding i_uid and i_gid are always
long enough so use them by default.
We have support for reading ext4 "huge" files but we can't write
(anything) on ext4. and some filesystem. Formally enable the feature
so that we can mount such filesystems.
MFC 320675: Add deprecation notices for gdb and kgdb.
Even though gdb and kgdb may not be removed for 12.0 on some architectures,
the notice is unconditional as these tools will likely be removed at some
point in the future when adequate replacements are available (gdb in ports
or lldb in base).
MFC: r320208
Ensure that the credentials field of the NFSv4 client open structure is
initialized.
bdrewery@ has reported panics "newnfs_copycred: negative nfsc_ngroups".
The only way I can see that this occurs is that the credentials field of
the open structure gets used before being filled in.
I am not sure quite how this happens, but for the file create case, the
code is serialized via the vnode lock on the directory. If, somehow, a
link to the same file gets created just after file creation, this might
occur.
This patch ensures that the credentials field is initialized to a reasonable
set of credentials before the structure is linked into any list, so I
this should ensure it is initialized before use.
I am committing the patch now, since bdrewery@ notes that the panics
are intermittent and it may be months before he knows if the patch fixes
his problem.
If /etc/bootparams contains a line with an excessively long pathname, and a
client asks for that path, then bootparamd will overflow a buffer and crash
while parsing that line. This is not remotely exploitable since it requires
a malformed /etc/bootparams file.
Verify that echo(1) does not...
- ... print the trailing newline character with option '-n'.
- ... print the trailing newline character when '\c' is appended to
the end of the string.
PACKAGE support doesn't exist on ^/stable/10, so FILES must be used instead.
Furthermore, BINDIR isn't automatically set to ${TESTSDIR} on this branch.
MFC r320599:
Fix Vagrant image upload after recent API changes.
- Update ATLAS_UPLOAD_URL to avoid various regular expressions
from failing to match due to redirections.
- Use ATLAS_UPLOAD_URL throughout the script.
- Adjust several regular expression patterns.
MFC: r320062, r320070, r320126
This is a partial merge of only the NFS changes and not the maxbcachebuf
tunable.
The NFS client changes make the code handle different I/O sizes more
correctly. However, with the limit at 64K, they are not actually
necessary.
This MFC is mainly being done so that subsequent MFCs to the NFS
code will merge easily.
MFC r319699
When allocating swap blocks, if the available number of free blocks in a
subtree is already zero, then setting the "largest contiguous free block"
hint for that subtree to anything other than zero makes no sense. (To be
clear, assigning a value to the hint that is too large is not a correctness
problem, only a pessimization.)
MFC r319755
blist_fill()'s return type is too narrow. blist_fill() accepts a 64-bit
quantity as the size of the range to fill, but returns a 32-bit quantity
as the number of blocks that were allocated to fill that range. This
revision corrects that mismatch.
MFC r319793
Remove an unnecessary field from struct blist. (The comment describing
what this field represented was also inaccurate.)
In r178792, blist_create() grew a malloc flag, allowing M_NOWAIT to be
specified. However, blist_create() was not modified to handle the
possibility that a malloc() call failed. Address this omission.
Increase the width of the local variable "radix" to 64 bits. This
matches the width of the corresponding field in struct blist.
ken [Mon, 3 Jul 2017 15:34:19 +0000 (15:34 +0000)]
MFC r320421:
------------------------------------------------------------------------
r320421 | ken | 2017-06-27 13:26:02 -0600 (Tue, 27 Jun 2017) | 37 lines
Fix a panic in camperiphfree().
If a peripheral driver (e.g. da, sa, cd) is added or removed from the
peripheral driver list while an unrelated peripheral driver instance (e.g.
da0, sa5, cd2) is going away and is inside camperiphfree(), we could
dereference an invalid pointer.
When peripheral drivers are added or removed (see periphdriver_register()
and periphdriver_unregister()), the peripheral driver array is resized
and existing entries are moved.
Although we hold the topology lock while we traverse the peripheral driver
list, we retain a pointer to the location of the peripheral driver pointer
and then drop the topology lock. So we are still vulnerable to the list
getting moved around while the lock is dropped.
To solve the problem, cache a copy of the peripheral driver pointer. If
its storage location in the list changes while we have the lock dropped, it
won't have any effect.
This doesn't solve the issue that peripheral drivers ("da", "cd", as opposed
to individual instances like "da0", "cd0") are not generally part of a
reference counting scheme to guard against deregistering them while there
are instances active. The caller (generally the person unloading a module)
has to be aware of active drivers and not unload something that is in use.
sys/cam/cam_periph.c:
In camperiphfree(), cache a pointer to the peripheral driver
instance to avoid holding a pointer to an invalid memory location
in the event that the peripheral driver list changes while we have
the topology lock dropped.
MFC r320049
Pages that are passed to swap_pager_putpages() should already be fully
dirty. Assert that they are fully dirty rather than redundantly calling
vm_page_dirty() on them.
jilles [Fri, 30 Jun 2017 21:32:48 +0000 (21:32 +0000)]
MFC r315005: sh: Fix executing wrong command with ${x#$(y)}$(z).
The parsed internal representation of words consists of a byte string with a
list of nodes (commands in command substitution). Each unescaped CTLBACKQ or
CTLBACKQ | CTLQUOTE byte corresponds to an entry in the list.
If param in ${param#%##%%word} is not set, the word is not expanded (in a
deviation of POSIX shared with other ash variants and ksh93). Erroneously,
the pointer in the list of commands (argbackq) was not advanced. This caused
the wrong command to be executed later if the outer word contained another
command substitution.
Example:
echo "${unsetvar#$(echo a)}$(echo b)"
wrote "a" but should write "b".
avg [Fri, 30 Jun 2017 09:34:50 +0000 (09:34 +0000)]
MFC r308782:
After some ZIL changes 6 years ago zil_slog_limit got partially broken
due to zl_itx_list_sz not updated when async itx'es upgraded to sync.
Actually because of other changes about that time zl_itx_list_sz is not
really required to implement the functionality, so this patch removes
some unneeded broken code and variables.
Original idea of zil_slog_limit was to reduce chance of SLOG abuse by
single heavy logger, that increased latency for other (more latency critical)
loggers, by pushing heavy log out into the main pool instead of SLOG. Beside
huge latency increase for heavy writers, this implementation caused double
write of all data, since the log records were explicitly prepared for SLOG.
Since we now have I/O scheduler, I've found it can be much more efficient
to reduce priority of heavy logger SLOG writes from ZIO_PRIORITY_SYNC_WRITE
to ZIO_PRIORITY_ASYNC_WRITE, while still leave them on SLOG.
Existing ZIL implementation had problem with space efficiency when it
has to write large chunks of data into log blocks of limited size. In some
cases efficiency stopped to almost as low as 50%. In case of ZIL stored on
spinning rust, that also reduced log write speed in half, since head had to
uselessly fly over allocated but not written areas. This change improves
the situation by offloading problematic operations from z*_log_write() to
zil_lwb_commit(), which knows real situation of log blocks allocation and
can split large requests into pieces much more efficiently. Also as side
effect it removes one of two data copy operations done by ZIL code WR_COPIED
case.
While there, untangle and unify code of z*_log_write() functions.
Also zfs_log_write() alike to zvol_log_write() can now handle writes crossing
block boundary, that may also improve efficiency if ZPL is made to do that.
alc [Wed, 28 Jun 2017 04:23:20 +0000 (04:23 +0000)]
MFC r314310
Refine the fix from r312954. Specifically, add a new PDE-only flag,
PG_PROMOTED, that indicates whether lingering 4KB page mappings might
need to be flushed on a PDE change that restricts or destroys a 2MB
page mapping. This flag allows the pmap to avoid range invalidations
that are both unnecessary and costly.
ken [Mon, 26 Jun 2017 15:23:12 +0000 (15:23 +0000)]
MFC r320123:
Fix a potential sleep while holding a mutex in the sa(4) driver.
If the user issues a MTIOCEXTGET ioctl, and the tape drive in question has
a serial number that is longer than 80 characters, we malloc a buffer in
saextget() to hold the output of cam_strvis().
Since a mutex is held in that codepath, doing a M_WAITOK malloc could lead
to sleeping while holding a mutex. Change it to a M_NOWAIT malloc and bail
out if we fail to allocate the memory. Devices with serial numbers longer
than 80 bytes are very rare (I don't recall seeing one), so this
should be a very unusual case to hit. But it is a bug that should be fixed.
sys/cam/scsi/scsi_sa.c:
In saextget(), if we need to malloc a buffer to hold the output of
cam_strvis(), don't wait for the memory. Fail and return an error
if we can't allocate the memory immediately.
As per https://datacenter.iers.org/eop/-/somos/5Rgv/latest/16:
INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS)
SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE
SERVICE DE LA ROTATION TERRESTRE
OBSERVATOIRE DE PARIS
61, Av. de l'Observatoire 75014 PARIS (France)
Tel. : 33 (0) 1 40 51 23 35
FAX : 33 (0) 1 40 51 22 91
Internet : services.iers@obspm.fr
Paris, 9 January 2017
Bulletin C 53
To authorities responsible
for the measurement and
distribution of time
INFORMATION ON UTC - TAI
NO leap second will be introduced at the end of June 2017.
The difference between Coordinated Universal Time UTC and the
International Atomic Time TAI is :
from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s
Leap seconds can be introduced in UTC at the end of the months of December
or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
six months, either to announce a time step in UTC, or to confirm that there
will be no time step at the next possible date.
Christian BIZOUARD
Director
Earth Orientation Center of IERS
Observatoire de Paris, France
sephe [Mon, 26 Jun 2017 02:33:59 +0000 (02:33 +0000)]
MFC 320184
hyperv/storvsc: Reduce log verbosity
On some windows hosts TEST_UNIT_READY command will return
SRB_STATUS_ERROR and sense data "NOT READY asc:3a,1 (Medium
not present - tray closed)", this occurs periodically, and
not hurt anything else. So, we prefer to ignore this kind
of errors.
PR: 219973
Submitted by: Hongjiang Zhang <hongzhan microsoft com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11271
delphij [Sun, 25 Jun 2017 05:46:03 +0000 (05:46 +0000)]
MFC r320216: Fix use-after-free introduced in r300388.
In r300388, endnetconfig() was called on nc_handle which would release
the associated netconfig structure, which means tmpnconf->nc_netid
would be a use-after-free.
Solve this by doing endnetconfig() in return paths instead.