Coverity warned that the switch statement fell through. While this was
intentional, the pattern wasn't especially clear. I just changed it to a
conventional if pattern.
Reported by: Coverity
CIDs: 1375851 (false positive), 1375853
Sponsored by: Dell EMC Isilon
The ICMP6 packets might not be contained in a single mbuf. So don't
assume this. Keep the IPv4 and IPv6 code in sync and make explicit
that the syncache code only need the TCP sequence number, not the
complete TCP header.
MFC after: 3 days
Sponsored by: Netflix, Inc.
Split the postive and negative parts into separate test cases. The positive
test case can only run on ZFS, because only ZFS supports files that large.
PR: 219757
Reported by: ngie
MFC after: 18 days
X-MFC-with: 319339
pmap_enter() by implementing a single return path. Otherwise, the
duplication will only increase with the upcoming support for psind == 1.
Reviewed by: kib (some time ago)
could be overridden in the SoC specific code, but this would break GENERIC
as it is likely to be incorrect.
Remove the versatile implementation of cpu_initclocks as it's unneeded.
host.
Problems start appearing when there are several threads all doing
operations on a UFS volume and the SU workqueue needs a cleanup. It is
possible that each thread calling softdep_request_cleanup() owns the
lock for some dirty vnode (e.g. all of them are executing mkdir(2),
mknod(2), creat(2) etc) and all vnodes which must be flushed are locked
by corresponding thread. Then, we get all the threads simultaneously
entering softdep_request_cleanup().
There are two problems:
- Several threads execute MNT_VNODE_FOREACH_ALL() loops in parallel. Due
to the locking, they quickly start executing 'in phase' with the speed
of the slowest thread.
- Since each thread already owns the lock for a dirty vnode, other threads
non-blocking attempt to lock the vnode owned by other thread fail,
and loops executing without making the progress.
Retry logic does not allow the situation to recover. The result is
a livelock.
Fix these problems by making the following changes:
- Allow only one thread to enter MNT_VNODE_FOREACH_ALL() loop per mp.
A new flag FLUSH_RC_ACTIVE guards the loop.
- If there were failed locking attempts during the loop, abort retry
even if there are still work items on the mp work list. An
assumption is that the items will be cleaned when other thread
either fsyncs its vnode, or unlock and allow yet another thread to
make the progress.
It is possible now that some calls would get undeserved ENOSPC from
ffs_alloc(), because the cleanup is not aggressive enough. But I do
not see how can we reliably clean up workitems if calling
softdep_request_cleanup() while still owning the vnode lock. I thought
about scheme where ffs_alloc() returns ERESTART and saves the retry
counter somewhere in struct thread, to return to the top level, unlock
the vnode and retry. But IMO the very rare (and unproven) spurious
ENOSPC is not worth the complications.
Reported and tested by: pho
Style and comments by: mckusick
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Add a new sysdecode_getrusage_who() which decodes the RUSAGE_* constant
passed as the first argument to getrusage(). Use this function in both
kdump and truss to decode the first argument to getrusage().
PR: 215448
Submitted by: Anton Yuzhaninov <citrin+pr@citrin.ru>
MFC after: 1 month
the last step of ffs_unmount().
It is possible that the mount point is recorded for cleanup in AST
context while softdep flush is executed during unmount. The workitems
are flushed by other means for the unmount, but the stray reference to
struct mount blocks destruction of mount. Check for the situation and
manually call vfs_rel() before returning from ffs_unmount().
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
This may be refined upstream.
Reviewed by: dim
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11034
-fPIC has no effect on linking although it seems to be ignored by
GNU ld.bfd. However, it causes ld.lld to terminate with an invalid
argument error.
This is equivalent to r296057 but for the kernel (not modules) case.
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
This somewhat simplifies use of msdosfs code in userland (for makefs),
reduces diffs with NetBSD and is standard C as of C89.
Reviewed by: imp
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11014
kqueue() does not set non-blocking I/O mode for event driven read of
file descriptors. This means the LinuxKPI internal kqueue read and
write event flags must be updated before the next read and/or write
system call. Else the read and/or write system call may block. This
can happen when there is no more data to read following a previous
read event. Then the application also gets blocked from processing
other events. This situation can also be solved by the applications
setting and using non-blocking I/O mode.
MFC after: 1 week
Sponsored by: Mellanox Technologies
character devices. In Linux the FIONBIO IOCTL is handled by the kernel
and not the drivers. Also need return success for the FIOASYNC ioctl
due to existing logic in kern_fcntl() even though it is not supported
currently.
MFC after: 1 week
Sponsored by: Mellanox Technologies
no need to.
- Remove pmap_is_current(), pmap_[pte|l3]_valid_cacheable as there were only
used to know if we had to write back pages.
- In pmap_remove_pages(), don't bother invalidating each page in the TLB,
we're about to flush the whole TLB anyway.
This makes make world 8-9% faster on my hardware.
Reviewed by: andrew
The stdout-path chosen property may include the serial connection details,
e.g. the baud rate. When passing the device to OF_finddevice we need to
strip off this information as it will cause the lookup to fail.
Reviewed by: emaste, manu
Differential Revision: https://reviews.freebsd.org/D6846
is the same as the old MTU. In particular, on Amazon EC2 "T2" instances
without this change, the network interface is reinitialized every 30
minutes due to the MTU being (re)set when a new DHCP lease is obtained,
causing packets to be dropped, along with annoying syslog messages about
the link state changing.
As a side note, the behaviour this commit fixes was responsible for
exposing the locking problems fixed via r318523 and r318631.
Maintainers of other network interface drivers may wish to consider making
the corresponding change; the handling of SIOCSIFMTU does not seem to
exhibit a great deal of consistency between drivers.
MFC after: 1 week
The documentation moved to section 3 several years ago, but
'man cap_rights_get' pulls up cap_rights_limit(2) (which is
MLINKed to cap_rights_get.2) instead of cap_rights_get(3).
MFC after: 1 week
This is undocumented to match GNU diff where -H is also undocumented.
Some existing software (such as kompare) uses this option by default.
Reviewed by: emaste, rpokala
Differential Revision: https://reviews.freebsd.org/D11022
