dd(1): Enable access to SIZE_T_MAX character devices
On machines where SIZE_T_MAX exceeds OFF_MAX (signed 64-bit), permit seeking
character devices to negative off_t values. This enables dd(1) to interact
with kernel KVA in /dev/kmem on amd64, for example.
r319339 (by asomers):
Fix integer overflow detection in dd
dd(1) tried to detect whether the seek offset would overflow, but it failed
to account for the case where the provided argument was negative and the
file was a regular file (negative seeks are allowed for character devices).
I fixed it, and added a regression test.
Don't explicitly get the class to PART in gctl_test_helper.c
This will allow the tool to be used with arbitrary geom(4) classes, like GEOM.
Specify class=PART explicitly in the tester to keep existing behavior.
r319806:
Improve handling with system state
- Always unlink $cmd after exit via END block.
- The tests don't function well if kern.geom.debugflags != 0. Save debugflags,
then restore them at the end of the test.
Add missing braces around MCAST_EXCLUDE check when KTR support is
compiled into the kernel
This ensures that .iss_asm (the number of ASM listeners) isn't incorrectly
decremented for MLD-layer source datagrams when inspecting im*s_st[1]
(the second state in the structure).
getbsize(3): clarify that underflow/overflow warnings in regard to $BLOCKSIZE
gets output via warnx(3)
This helps set expectations for how one might deal with those messages, i.e.,
mute output from /dev/stderr today, since that's where vwarn(3) outputs messages
to today.
Add positive and negative testcases for cam_get_device(3)
r319845:
Remove stdlib.h #include added in r319844
A previous iteration of the tests I added in r319844 involved free(3), but
that attempt didn't pan out, so I switched to stack allocated buffers instead
of heap allocated ones, making the #include unnecessary.
Add sys/types.h #include to EXAMPLE to provide a complete functional
standalone example program
r316550:
sbuf(9): convert SYNOPSIS section from .Fn entries to .Fo/.Fa/.Fc entries
This shortens the column count on many lines considerably.
While here, add "(void)" to sbuf_new_auto(3) for consistency with style(9)
recommendations.
r316551:
sbuf(9): clarify kernel-only APIs
- move sbuf_bcopyin(9) and sbuf_copyin(9) near sbuf_new_for_sysctl(9), as
all three functions are kernel-only APIs.
- add #ifdef _KERNEL around sbuf_*copyin and sbuf_new_for_sysctl(9) to
make it visually clear that they are kernel-only APIs.
r316554:
sbuf(9): add MLINKS for sbuf_{clear,get,set}_flags(9)
Add a new flag, SBUF_INCLUDENUL, and new get/set/clear functions for flags.
The SBUF_INCLUDENUL flag causes the nulterm byte at the end of the string
to be counted in the length of the data. If copying the data using the
sbuf_data() and sbuf_len() functions, or if writing it automatically with
a drain function, the net effect is that the nulterm byte is copied along
with the rest of the data.
r280149 (by ian):
Update an sbuf assertion to allow for the new SBUF_INCLUDENUL flag. If
INCLUDENUL is set and sbuf_finish() has been called, the length has been
incremented to count the nulterm byte, and in that case current length is
allowed to be equal to buffer size, otherwise it must be less than.
Add a predicate macro to test for SBUF_INCLUDENUL, and use it in tests, to
be consistant with the style in the rest of this file.
r280193 (by ian):
The minimum sbuf buffer size is 2 bytes (a byte plus a nulterm), assert that.
Values smaller than two lead to strange asserts that have nothing to do
with the actual problem (in the case of size=0), or to writing beyond the
end of the allocated buffer in sbuf_finish() (in the case of size=1).
r288223 (by cem):
sbuf: Process more than one char at a time
Revamp sbuf_put_byte() to sbuf_put_bytes() in the obvious fashion and
fixup callers.
Add a thin shim around sbuf_put_bytes() with the old ABI to avoid ugly
changes to some callers.
Obtained from: Dan Sledz
r288484 (by phk):
Fail the sbuf if vsnprintf(3) fails.
r321109:
Fix whitespace regression accidentally checked in via ^/head@r280149
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.
projects / FreeBSD / stable / 10.git / log