Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1 |
|
#
c0b79d00 |
| 07-Aug-2021 |
Sascha Wildner <saw@online.de> |
Add some necessary #include's in signal related headers.
|
Revision tags: v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2 |
|
#
1530d07c |
| 25-Jul-2020 |
Sascha Wildner <saw@online.de> |
<machine/*.h>: Use our __aligned() macro in various cases.
No functional change.
|
Revision tags: v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3 |
|
#
b2e7ce7d |
| 10-Nov-2019 |
Sascha Wildner <saw@online.de> |
#include <sys/cdefs.h> in a number of headers that use macros from it.
All these are public headers and check some kind of __*_VISIBLE macro with #if but were not making sure that these macros are a
#include <sys/cdefs.h> in a number of headers that use macros from it.
All these are public headers and check some kind of __*_VISIBLE macro with #if but were not making sure that these macros are available and set correctly.
show more ...
|
Revision tags: v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1 |
|
#
11ba7f73 |
| 10-Aug-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Lower VM_MAX_USER_ADDRESS to finalize work-around for Ryzen bug
* Reduce VM_MAX_USER_ADDRESS by 2MB, effectively making the top 2MB of the user address space unmappable. The user stack n
kernel - Lower VM_MAX_USER_ADDRESS to finalize work-around for Ryzen bug
* Reduce VM_MAX_USER_ADDRESS by 2MB, effectively making the top 2MB of the user address space unmappable. The user stack now starts 2MB down from where it did before. Theoretically we only need to reduce the top of the user address space by 4KB, but doing it by 2MB may be more useful for future page table optimizations.
* As per AMD, Ryzen has an issue when the instruction pre-fetcher crosses from canonical to non-canonical address space. This can only occur at the top of the user stack.
In DragonFlyBSD, the signal trampoline resides at the top of the user stack and an IRETQ into it can cause a Ryzen box to lockup and destabilize due to this action. The bug case was, basically two cpu threads on the same core, one in a cpu-bound loop of some sort while the other takes a normal UNIX signal (causing the IRETQ into the signal trampoline). The IRETQ microcode freezes until the cpu-bound loop terminates, preventing the cpu thread from being able to take any interrupt or IPI whatsoever for the duration, and the cpu may destabilize afterwords as well.
* The pre-fetcher is somewhat heuristical, so just moving the trampoline down is no guarantee if the top 4KB of the user stack is mapped or mappable. It is better to make the boundary unmappable by userland.
* Bug first tracked down by myself in early 2017. AMD validated the bug and determined that unmapping the boundary page completely solves the issue.
* Also retain the code which places the signal trampoline in its own page so we can maintain separate protection settings for the code, and make it read-only (R+X).
show more ...
|
#
da1e1cb6 |
| 06-Aug-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Move sigtramp even lower
* Attempt to work around a Ryzen cpu bug by moving sigtramp even lower than we have already.
|
Revision tags: v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2 |
|
#
2c64e990 |
| 25-Jan-2016 |
zrj <rimvydas.jasinskas@gmail.com> |
Remove advertising header from sys/
Correct BSD License clause numbering from 1-2-4 to 1-2-3.
Some less clear cases taken as it was done of FreeBSD.
|
Revision tags: v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3 |
|
#
d3240feb |
| 01-Jan-2015 |
Sascha Wildner <saw@online.de> |
<signal.h>: Sanitize the feature tests.
* Generally, in our headers, we don't check the (user-settable) _POSIX_SOURCE and _ANSI_SOURCE, but instead __XSI_VISIBLE, __POSIX_VISIBLE and __BSD_VISIB
<signal.h>: Sanitize the feature tests.
* Generally, in our headers, we don't check the (user-settable) _POSIX_SOURCE and _ANSI_SOURCE, but instead __XSI_VISIBLE, __POSIX_VISIBLE and __BSD_VISIBLE, which are set by <sys/cdefs.h> based on what the user chose. Do the same in the CPU specific signal headers.
* psignal() is now a standard function (per 200809).
* Add missing __restrict qualifiers.
show more ...
|
Revision tags: v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0 |
|
#
e6e019a8 |
| 13-Jan-2013 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Fix signal FP save/restore issues when AVX is enabled
* The kernel was not saving/restoring the full FP context when entering into or returning from a signal, leading to corrupt FP regist
kernel - Fix signal FP save/restore issues when AVX is enabled
* The kernel was not saving/restoring the full FP context when entering into or returning from a signal, leading to corrupt FP registers even when AVX is not used, when AVX is enabled in the kernel.
ANY SIGNAL COULD CORRUPT THE FP STATE.
* Fixed by adjusting the on-user-stack fpsave area sizes and operation.
* This unfortunately changes a number of user visible structures. ucontext_t, mcontext_t, sigcontext, sigframe.
It is POSSIBLE that most userland use cases will be unaffected, but I'm not holding my breath.
Major-Sleuthing-by: ftigeot Testing-by: ftigeot, dillon
show more ...
|
Revision tags: v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0 |
|
#
86d7f5d3 |
| 26-Nov-2011 |
John Marino <draco@marino.st> |
Initial import of binutils 2.22 on the new vendor branch
Future versions of binutils will also reside on this branch rather than continuing to create new binutils branches for each new version.
|
Revision tags: v2.12.0, v2.13.0, v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0 |
|
#
b2b3ffcd |
| 04-Nov-2009 |
Simon Schubert <corecode@dragonflybsd.org> |
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and rename all of the architecture files and references. This will hopefully make pkgsrc build
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and rename all of the architecture files and references. This will hopefully make pkgsrc builds less painful.
Discussed-with: dillon@
show more ...
|
#
c1543a89 |
| 04-Nov-2009 |
Simon Schubert <corecode@dragonflybsd.org> |
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and rename all of the architecture files and references. This will hopefully make pkgsrc build
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and rename all of the architecture files and references. This will hopefully make pkgsrc builds less painful.
Discussed-with: dillon@
show more ...
|
#
f2642d5a |
| 19-Dec-2009 |
Alex Hornung <ahornung@gmail.com> |
signal - Introduce si_code codes
* Introduce si_code codes #defines for signals.
* Assign proper si_code for most traps.
* Get rid of x86_64-only si_code code #defines.
* This also fixes build of
signal - Introduce si_code codes
* Introduce si_code codes #defines for signals.
* Assign proper si_code for most traps.
* Get rid of x86_64-only si_code code #defines.
* This also fixes build of pkgsrc devel/boost-libs
Dragonfly-bug: http://bugs.dragonflybsd.org/issue1313
show more ...
|