Fix section pattern code to exclude .rel.data.* sections from being
merged into .data. Otherwise relocations in those sections are lost
in final binary
Reviewed by: andrew
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9108
__bss_end should not be included in .bss zeroing code. Otherwise first 4
bytes of the section that follows .bss (in loader's case it's .sdata) are
overwritten by zero.
Reviewed by: andrew
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9108
Obtaining compat rtld lock in write mode sets process signal mask to
block all signals. Previous mask is stored in the global variable
oldsigmask. If a lock is write-locked while another lock is already
write-locked, oldsigmask is overwritten by the total mask and on the
last unlock, all signals except traps appear to be blocked.
Fix this by counting the write-lock nested level, and only storing to
oldsigmask/restoring from it at the outermost level.
Masking signals disables involuntary preemption for libc_r, and there
could be no voluntary context switches in the locked code
(dl_iterate_phdr(3) keeps a lock around user callback, but it was
added long after libc_r was renounced). Due to this, remembering the
level in the global variable after the lock is obtained should be
safe, because no two libc_r threads can acquire different write locks
in parallel.
PR: 215826
Reported by: kami
Tested by: yamagi@yamagi.org (previous version)
To be reviewed by: kan
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
In-tree objdump is too old to dump new ELF headers. But for example if we
use: `make CROSS_TOOLCHAIN=riscv64-gcc TARGET_ARCH=riscv64` and do not specify
CROSS_BINUTILS_PREFIX in env, embed_mfs.sh cannot find the correct objdump.
This patch just replaces using of objdump with elfdump to collect needed
information.
Later we may also put an ELFDUMP in CROSSENV and use it in embed_mfs.sh .
Reviewed by: emaste, br
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9062
a linuxkpi style device is expected. If OFED/linuxkpi actually starts
using this field then we'll have to figure out whether to create fake
devices for these drivers or have linuxkpi deal with NULL device.
This mismatch was first reported as part of D6585.
Unnecessary prefetch just loads HW prefetcher and displaces other
cache entries (which could be really useful).
If we parse mbuf for TSO early and use firmware-assisted TSO, we do not
expect mbuf data access when we compose firmware-assisted TSO (v1 or v2)
option descriptors. If packet header needs to be linearized or finally
FATSO cannot be used because of, for example, too big header, we do not
care about a bit more performance degradation because of prefetch
absence (it is better to optimize more common case).
Reviewed by: gnn
Sponsored by: Solarflare Communications, Inc.
MFC after: 2 days
Differential Revision: https://reviews.freebsd.org/D9120
in some arm64 hardware, for example the AMD Opteron A1100.
Reviewed by: mav
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8852
This is needed for two reasons:
* Drivers will need to know what the negotiated set of VHT capabilities
and rates are in order to configure (and reconfigure for opmode/chanwidth
changes) how to speak to a given peer; and
* Because some vendors are "special", we should be careful in what we announce
to them during peer association.
This isn't the complete solution, as I still need to make sure that when
sending out probe requests before we know what we want, we don't limit
the capabilities being announced. This is important for IBSS/mesh work
later on as probe request/response exchanges are the first hint at what
a peer supports. I'll look at adding that to the API soon.
- em(4) igb(4) and lem(4)
- deprecate the igb device from kernel configurations
- create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
Devices tested:
- 82574L
- I218-LM
- 82546GB
- 82579LM
- I350
- I217
Please report problems to freebsd-net@freebsd.org
Partial review from jhb and suggestions on how to *not* brick folks who
originally would have lost their igbX device.
Submitted by: mmacy@nextbsd.org
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Limelight Networks and Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8299
These have been tested back-to-back with Linux 3.x and a similar attachment
at the other end; a CDC EEM-like encapsulation can be used for emulated
Ethernet over udbp(4) with ng_ether.
potentially leading to fatal unaligned accesses on architectures with
strict alignment requirements. This change fixes dummynet(4) as far
as accesses to 64-bit members of struct dn_* are concerned, tripping
up on sparc64 with accesses to 32-bit members happening to be correctly
aligned there. In other words, this only fixes the tip of the iceberg;
larger parts of dummynet(4) still need to be rewritten in order to
properly work on all of !x86.
In principle, considering the amount of code in dummynet(4) that needs
this erroneous pattern corrected, an acceptable workaround would be to
declare all struct dn_* packed, forcing compilers to do byte-accesses
as a side-effect. However, given that the structs in question aren't
laid out well either, this would break ABI/KBI.
While at it, replace all existing bcopy(9) calls with memcpy(9) for
performance reasons, as there is no need to check for overlap in these
cases.
PR: 189219
MFC after: 5 days
If some process' nodes were accessed using procfs and the process
cannot exit properly at the time modunload event is reported to the
pseudofs-backed filesystem, the assertion in pfs_vncache_unload() is
triggered. Assertion is correct, the cache should be cleaned.
Approved by: des (pseudofs maintainer)
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Fix a clang 4.0.0 warning about taking the address of a packed member of
struct mfi_evt in mfiutil:
usr.sbin/mfiutil/mfi_evt.c:583:30: error: taking address of packed
member 'members' of class or structure 'mfi_evt' may result in an
unaligned pointer value [-Werror,-Waddress-of-packed-member]
if (parse_locale(optarg, &filter.members.locale) < 0) {
^~~~~~~~~~~~~~~~~~~~~
Use a local variable instead, and copy that into the struct.
Reviewed by: jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9069
