sense and were trying to hide a real bug, which is, that there is for some
reason a wrong stack alignment that causes FXSAVE to fault in
fpuinit_mxcsr_mask. As seen in current-users@ yesterday, rdi % 16 = 8. And
as seen several months ago, as well.
The rest of the changes in XSAVE are wrong too, but I'll let him fix these
ones.
With approval from bouyer@ and acceptance, sometimes grudgingly, from
others I have removed the AGP lines from the XEN3_DOM0 config. I have
left a note in the PR suggesting that if it ever gets a proper fix that
those lines can be considered for re-inclusion.
The path variable is assigned with an allocation on the heap with
strdup(3). Later this pointer is changed with strsep(3) and this caused
invalid free(3).
Store the original pointer in a new helper variable opath and pass it to
free(3). With this change, the problem is going away.
Detected with MKSANITIZER=yes with AddressSanitizer.
so it can be called separately from sata_reset_interface()
do not treat PHY offline as an error, it's pretty normal when there
is no device actually connected
debugging aid for PR kern/52372
* fixed compile issues with prior release
* fixed carrier loss not being detected for IPv4
* UUID based DUID is used where available and no prior DUID exists
This option cannot be set in distrib/common/Makefile.distrib as it's too
late, after including <bsd.own.mk> that will set MKSANITIZER.
This makes generation of ramdisk for amd64 with MKSANITIZER=yes successful.
Introduce a new variable SANITIZERFLAGS that contains all the sanitizer
specific flags. These flags are designed to be passed to CFLAGS, CXXFLAGS
and LDFLAGS.
Pass SANITIZERFLAGS in bsd.prog.mk rules to CFLAGS, CXXFLAGS and LDFLAGS.
Pass SANITIZERFLAGS in bsd.lib.mk rules to *_pic.a build flags. The *_pic.a
libraries are designed to construct .so libraries. All .so libraries with
few exceptions are expected to be prebuilt with a sanitizer. Another
purpuse of *_pic.a files can be constructing static PIE programs, however
they are not supported as of now and there is no sanitization of static
programs either.
Once MKSTATICPIE will be supported, it will be initially incompatible with
MKSANITIZER.
This change also makes it easier to build other targets like kernel and
kernel modules without userland sanitizers.
No functional change intended for MKSANITIZER=no users.
Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER.
These options are incompatible with the current design of sanitizers,
because they cause duplication of symbols into programs and thus symbols
from the interceptors from sanitizers cannot be linked.
This change makes effectively mounting /usr required for dhcp programs like
dhclient(8).
As of today typical sanitizers require dynamic executables, while
crunchgen(1) programs are produced with static properties.
Lack of specified -s will:
- generate a Makefile file with NOSANITIZER=
- build programs that are dependencies with NOSANITIZER=
In future there is an option to handle sanitization in statically linked
programs.
An idea with -s LGTM by <christos>
These utilities (elf32, elf32_compat, elf64, liblldb) share code with the
ELF dynamic loader that is not being sanitized and its symbols are
installed into sanitized programs (in particular __tls_get_addr()).
Additionally libldd is used in rescue that is not expected to be sanitized
as of today.
When rip_input() is called as inetsw[].pr_input, rip_iput() is always called
with holding softnet_lock, that is, in case of !defined(NET_MPSAFE) it is
acquired in ipintr(), otherwise(defined(NET_MPSAFE)) it is acquire in
PR_WRAP_INPUT macro.
However, some function calls rip_input() directly without holding softnet_lock.
That causes assertion failure in sbappendaddr().
rip6_input() and icmp6_rip6_input() are also required softnet_lock for the same
reason.
XSAVE as it should be, only xen case checks the flag now; need to
investigate further why exactly the fault happens for the xen
no-xsave case
pointed out by maxv
