The code was easier to read without __DECONST and clang didn't report
any error. I thought the cast was enough...
MFC after: 3 days
X-MFC-With: r258549
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.
Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.
This bug triggered an infinite loop in KDE/xserver:
1. KDE has a kded module called "randrmonitor" which queries xserver
for current monitors at startup and then listens to RandR
notifications from xserver.
2. xserver handles the query from "randrmonitor" by polling the
video device using the "drm_mode_getconnector()" ioctl. This
ioctl returns a list of connectors and, for those with a
connected monitor, the available modes. Each modes list is sorted
by the kernel before returning. When xserver gets the connectors
list, it sorts the modes lists again.
In the case of this bug, when two modes are equal (in xserver's
compare function PoV), their order is kept stable (ie. the
kernel order is kept for those two modes). And because the list
was shuffled by the kernel, the order of two equal modes was
frequently changed in the final modes list in xserver.
3. xserver compares the returned connectors list with the list
obtained earlier. In particular, it compares the sorted
modes lists for each connector. If a property of a connector
changes (eg. modes), xserver sends a "RRNotify_OutputChange"
notification.
Because of the change of order between equal modes, xserver sent
a notification after each polling of the connectors.
4. "randrmonitor" receives a notification, triggered by its query. The
notification doesn't contain the new connectors list, therefore, it
asks for the new list using the same function: go back to step #2.
MFC after: 3 days
option, unbreak the lock tracing release semantic by embedding
calls to LOCKSTAT_PROFILE_RELEASE_LOCK() direclty in the inlined
version of the releasing functions for mutex, rwlock and sxlock.
Failing to do so skips the lockstat_probe_func invokation for
unlocking.
- As part of the LOCKSTAT support is inlined in mutex operation, for
kernel compiled without lock debugging options, potentially every
consumer must be compiled including opt_kdtrace.h.
Fix this by moving KDTRACE_HOOKS into opt_global.h and remove the
dependency by opt_kdtrace.h for all files, as now only KDTRACE_FRAMES
is linked there and it is only used as a compile-time stub [0].
[0] immediately shows some new bug as DTRACE-derived support for debug
in sfxge is broken and it was never really tested. As it was not
including correctly opt_kdtrace.h before it was never enabled so it
was kept broken for a while. Fix this by using a protection stub,
leaving sfxge driver authors the responsibility for fixing it
appropriately [1].
Sponsored by: EMC / Isilon storage division
Discussed with: rstone
[0] Reported by: rstone
[1] Discussed with: philip
It turned out that on pSeries machines the call into OF modified the trap
vectors and this made further behaviour unpredictable.
With this commit I'm now able to boot multi user on a network booted
environment on my IntelliStation 285. This is a POWER5+ machine.
Discussed with: nwhitehorn
MFC after: 1 week
to inject edge triggered legacy interrupts into the guest.
Start using the new API in device models that use edge triggered interrupts:
viz. the 8254 timer and the LPC/uart device emulation.
Submitted by: Tycho Nightingale (tycho.nightingale@pluribusnetworks.com)
where "m" is number of source nodes and "n" is number of states. Thus,
on heavy loaded router its processing consumed a lot of CPU time.
Reimplement it with O(m+n) complexity. We first scan through source
nodes and disconnect matching ones, putting them on the freelist and
marking with a cookie value in their expire field. Then we scan through
the states, detecting references to source nodes with a cookie, and
disconnect them as well. Then the freelist is passed to pf_free_src_nodes().
In collaboration with: Kajetan Staszkiewicz <kajetan.staszkiewicz innogames.de>
PR: kern/176763
Sponsored by: InnoGames GmbH
Sponsored by: Nginx, Inc.
- Removed pf_remove_src_node().
- Introduce pf_unlink_src_node() and pf_unlink_src_node_locked().
These function do not proceed with freeing of a node, just disconnect
it from storage.
- New function pf_free_src_nodes() works on a list of previously
disconnected nodes and frees them.
- Utilize new API in pf_purge_expired_src_nodes().
In collaboration with: Kajetan Staszkiewicz <kajetan.staszkiewicz innogames.de>
Sponsored by: InnoGames GmbH
Sponsored by: Nginx, Inc.
This is a port from amd64 of r258436, and is intended to make diffs
(against amd64 and for future UEFI work) easier to review.
Reviewed by: jhb@
Sponsored by: The FreeBSD Foundation
so they can be used in the userspace version of ipfw/dummynet
(normally using netmap for the I/O path).
This is the first of a few commits to ease compiling the
ipfw kernel code in userspace.
The purpose of the PMBR is to have the disk appear in use to GPT
unaware utilities (like fdisk). However, if the PMBR has been changed
by a GPT unaware utlity then we must assume that this was deliberate
(as it involved removal of the special slice) and we should not treat
the unmodified GPT-specific sectors as being valid. By lowering the
probe priority in that case, the MBR scheme will take precedence and
the kernel will end up using the MBR and not the GPT. We will still
use the GPT if the kernel does not support the MBR scheme.
Extracted from the projects/uefi branch, this change is a reasonable
cleanup and will reduce the diffs to review when bringing in the
UEFI work.
Reviewed by: kib@
Sponsored by: The FreeBSD Foundation
The page presence memory test takes a long time on large memory systems
and has little value on contemporary amd64 hardware.
Sponsored by: The FreeBSD Foundation
ibm,dma-window properties. This is especially a concern when
#ibm,dma-address-cells is not specified and we have to use the regular
#address-cells property.
MFC after: 1 week
context switch just to call the done callback... On my machine, this
improves geli/gzero decrypt performance by ~27% from 550MB/sec to
~700MB/sec...
MFC after: 3 days
compiler interprets this as an undefined behaviour. Instead, ensure
that the sum of uio_offset and uio_resid is below OFF_MAX using the
operation which cannot overflow.
Reported and tested by: pho
Discussed with: bde
Approved by: des (pseudofs maintainer)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
enables data cache and other chip-specific features. It was previously
done via an early SYSINIT, but it was being done after pmap and vm setup,
and those setups need to use mutexes. On some modern ARM platforms,
the ldrex/strex instructions that implement mutexes require the data cache
to be enabled.
A nice side effect of enabling caching earlier is that it eliminates the
multi-second pause that used to happen early in boot while physical memory
and pmap and vm were being set up. On boards with 1 GB or more of ram
this pause was very noticible, sometimes 5-6 seconds.
PR: arm/183740
big chunk of kernel memory. Validate size of data. Add error handling to
avoid calling copyout() when data has not been read correctly.
Reviewed by: zbb
Reported by: x90c <geinblues@gmail.com>
MFC after: 2 days
