This reverts commit fa03d37432.
This commit caused us to not send IGMP leave messages if the inpcb went
away. In other words: we freed pending packets whenever the socket
closed rather than when the interface (or address) goes away.
Reviewed by: glebius
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43032
In del_mfc() we try to find the forwarding entry, but that fails to find
the entry if mfc_stall_ring is not empty.
We should find the entry anyway, and destroy it (and any pending
messages) on delete.
Reviewed by: glebius
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43031
Note that relbase is always 0 for DSOs so its omission for __KLD_SHARED
architectures was not a bug in practice.
Whilst here, also parenthesise the dest offset for where to avoid
transiently creating an out-of-bounds pointer, which is UB (though even
on CHERI architectures, where capability bounds compression can result
in that creating invalid capabilities that will trap on dereference,
optimisation will reassociate to the correct form in practice and thus
work just fine).
Most all of the memory used by the cards in the mpr(4) and mps(4)
drivers is required, according to the specs and Broadcom developers,
to be within a 4GB segment of memory.
This includes:
System Request Message Frames pool
Reply Free Queues pool
ReplyDescriptorPost Queues pool
Chain Segments pool
Sense Buffers pool
SystemReply message pool
We got a bug report from Dwight Engen, who ran into data corruption
in the BAE port of FreeBSD:
> We have a port of the FreeBSD mpr driver to our kernel and recently
> I found an issue under heavy load where a DMA may go to the wrong
> address. The test system is a Supermicro X10SRH-CLN4F with the
> onboard SAS3008 controller setup with 2 enterprise Micron SSDs in
> RAID 0 (striped). I have debugged the issue and narrowed down that
> the errant DMA is one that has a segment that crosses a 4GB
> physical boundary. There are more details I can provide if you'd
> like, but with the attached patch in place I can no longer
> re-create the issue.
> I'm not sure if this is a known limit of the card (have not found a
> datasheet/programming docs for the chip) or our system is just
> doing something a bit different. Any helpful info or insight would
> be welcome.
> Anyway, just thought this might be helpful info if you want to
> apply a similar fix to FreeBSD. You can ignore/discard the commit
> message as it is my internal commit (blkio is our own tool we use
> to write/read every block of a device with CRC verification which
> is how I found the problem).
The commit message was:
> [PATCH 8/9] mpr: fix memory corrupting DMA when sg segment crosses
> 4GB boundary
> Test case was two SSD's in RAID 0 (stripe). The logical disk was
> then partitioned into two partitions. One partition had lots of
> filesystem I/O and the other was initially filled using blkio with
> CRCable data and then read back with blkio CRC verify in a loop.
> Eventually blkio would report a bad CRC block because the physical
> page being read-ahead into didn't contain the right data. If the
> physical address in the arq/segs was for example 0x500003000 the
> data would actually be DMAed to 0x400003000.
The original patch was against mpr(4) before busdma templates were
introduced, and only affected the buffer pool (sc->buffer_dmat) in
the mpr(4) driver. After some discussion with Dwight and the
LSI/Broadcom developers and looking through the driver, it looks
like most of the queues in the driver are ok, because they limit
the memory used to memory below 4GB. The buffer queue and the chain
frames seem to be the exceptions.
This is pretty much the same between the mpr(4) and mps(4) drivers.
So, apply a 4GB boundary limitation for the buffer and chain frame pools
in the mpr(4) and mps(4) drivers.
Reported by: Dwight Engen <dwight.engen@gmail.com>
Reviewed by: imp
Obtained from: Dwight Engen <dwight.engen@gmail.com>
Differential Revision: <https://reviews.freebsd.org/D43008>
This accidentally got left out of 0f4467ce44.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans, allanjude
Differential Revision: https://reviews.freebsd.org/D43067
Surprisingly, kldxref does not currently support arm, and unhelpfully
this means it silently does nothing rather than give an error, so the
linker.hints entry added to the METALOG for -DNO_ROOT builds (and
pkgbase ones) refers to a file that doesn't exist. Ideally it would be
supported (and ideally the METALOG handling would be less fragile, but
without integrating it into kldxref the only real option would be to
just run find(1) to get the list of linker.hints files, which feels a
little backwards), but for now just paper over this by skipping the
build step on arm.
Reported by: bapt
Fixes: ff7c12c1f1 ("Make kldxref a bootstrap tool and use unconditionally")
R_PPC_RELATIVE lost its 32-bit handling in the libelf conversion.
Reported by: bapt
Fixes: 0299afdff1 ("kldxref: Make use of libelf to be a portable cross tool")
If the destination file exists but we decide unlink it, set the dne
flag. This means we don't need to re-check the conditions that would
have caused us to delete the file when we later need to decide whether
to create or replace it.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43064
- The HLPR flags are grouped together at the beginning because they are
the standard flags for programs using FTS. Move the N flag out from
among them to its correct place in the sequence.
- The Pflag variable isn't used outside main(), but moving it out lets
us skip initialization and keeps it with its friends H, L and R.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43063
This test case tests two different things: first, that copying a symlink
results in a file with the same contents as the target of the symlink,
rather than a second symlink, and second, that cp will refuse to copy a
file to itself, or to a link to itself, or a link to its target. Leave
the first part in basic_symlink, move the second part to a new test case
named samefile, and slightly expand both cases.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43062
Unlike bwi(4), bwn(4) does not rely on ic_headroom (despite having it
set) but splits the bwn_txhdr (first) segment into its own transaction.
Remove ic_headroom to avoid net80211 troubles with not enough space in
the mbuf around ieee80211_mbuf_adjust().
PR: 275616
MFC after: 3 days
Rewrite `copy_file()` so the lflag and sflag are handled as early as
possible instead of constantly checking that they're not set and then
handling them at the end. This also opens the door to changing the
failure logic at some future point (for instance, we might decide to
fall back to copying if `errno` indicates that the file system does not
support links).
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans, allanjude
Differential Revision: https://reviews.freebsd.org/D43055
Now that kldxref is a generic cross tool and can be built on non-FreeBSD
we can bootstrap it during the build and thus remove the condition for
whether it exists. We also need to make sure to add it to the METALOG
for -DNO_ROOT builds.
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D43051
Currently IMAKE_INSTALL, which includes -M METALOG, is enough for the
sub-makes to work, but using kldxref for -DNO_ROOT builds will require
manually adding linker.hints to the METALOG, and thus both METALOG
itself and DISTBASE need to be exposed directly to the sub-makes, so do
so.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D43050
This is needed for kldxref, which will shortly become a bootstrap tool.
Linux can use the same one as FreeBSD (provided the cross-building
sys/cdefs.h is augmented appropriately), whilst macOS needs its own
Mach-O-specific implementation.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D43049
OpenZFS upstream refactored the asm versions of sha2 to be usable on all
32-bit arm flavors, so it is not necessary to limit this to armv6 and
armv7.
Suggested by: jhb
[Why]
The amdgpu DRM driver started to use it in Linux 5.18.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43020
[Why]
The i915 DRM driver in Linux 5.18 relies on this indirect include.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43030
[Why]
This header and str_yes_no() are now used by the i915 DRM driver in
Linux 5.18.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43014
This was already handled in ObsoleteFiles.inc (see the 20230622 entry),
but some people never run "make delete-old", or want to upgrade directly
from a revision that still had libc++ 15 to the most recent revision.
They would then encounter a failure during installworld, similar to:
install: target directory `/usr/include/c++/v1/__tuple/' does not exist
Therefore, clean it up in the distrib-cleanup phase, similar to the
earlier instance of the libc++ __string header file that became a
directory.
PR: 273753
MFC after: 1 month
[Why]
This callback is being used by the amdgpu DRM driver in Linux 5.18.
[How]
The callback is called after `suspend_late()`.
Reviewed by: emaste, manu
Approved by: emaste, manu
Differential Revision: https://reviews.freebsd.org/D43029
[Why]
This header is being used by DRM drivers in Linux 5.18.
Reviewed by: emaste, manu
Approved by: emaste, manu
Differential Revision: https://reviews.freebsd.org/D43028
[Why]
The passed structure may not have a `.store` field. This is the case in
the amdgpu DRM driver starting with Linux 5.18.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43023
[Why]
The amdgpu DRM driver started to use it in Linux 5.18.
[How]
The function is a no-op as I'm not sure how to implement this with
sysctls yet.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43022
[Why]
The amdgpu DRM driver started to use it in Linux 5.18.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43021
[Why]
`linux_compat.c` is already too long. I will need to add `struct kset`
in a follow-up commit, so let's move the existing `struct kobject` code
to its own file.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43019
[Why]
This is consistent with Linux.
[How]
The definition is moved from <linux/shmem_fs.h> to <linux/pagemap.h> and
the latter is included from the former. This is how it is done on Linux.
Prototypes are also expanded with argument names. I got a build failure
in the DRM 5.18 drivers because the compiler considered that the
`pgoff_t` argument was there twice.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43018
The sha256 and sha512 binaries are used when building release images.
Bootstrapping them used to be gated on MK_BOOT, which wasn't quite right
but in practice worked, at least in our use cases downstream. Add back
bootstrapping sbin/md5 and its aliases for this purpose to fix building
release images on Linux and macOS.
Fixes: f213da893c ("Makefile.inc1: Remove beri straggler")
The `kernel` env var provides the default kernel, usually "kernel". It
may be the case that the user doesn't have a "kernel" kernel, just
"kernel.*" kernels, but have left `kernel` to the default because we
autodetect entries by default anyways.
If we're doing autodetection, take note of whether the default kernel
exists or not and remove it from the list if it doesn't and we had found
any other kernels. We avoid it in the #kernels == 1 case because
something fishy has likely happened and we should just trust the
configuration.
Reviewed by: imp, manu
Differential Revision: https://reviews.freebsd.org/D42967
Some callers are using print_mask_arg() when they should be using
print_mask_arg0(); the latter should be used when all flags are optional
and there's not a flag to be decoded with a 0-mask. This turns:
nmount(0x6991e009000,0x8,0<><invalid>0)
into:
nmount(0x6991e009000,0x8,0)
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D43007
Updated pkg is now in quarterly and there is no need to forcibly
install a specific version.
This reverts commit 1c376684c7.
This reverts commit 3c097b06a7.
Reported by: bapt
Sponsored by: The FreeBSD Foundation
This allows kldxref to operate on kernel objects from any
architecture, not just the native architecture. In particular, this
will permit generating linker.hints files as part of a cross-arch
release build.
- elf.c is a new file that includes various wrappers around libelf
including routines to read ELF data structures such as program and
section headers and ELF relocations into the "generic" forms
described in <gelf.h>. This file also provides routines for
converting a linker set into an array of addresses (GElf_Addr)
as well as reading architecture-specific mod_* structures and
converting them into "generic" Gmod_* forms where pointers are
replaced with addresses.
- The various architecture-specific reloc handlers now use GElf_*
types for most values (including GElf_Rel and GElf_Rela for
relocation structures) and use routines from <sys/endian.h> to read
and write target values. A new linker set matches reloc handlers
to specific ELF (class, encoding, machine) tuples.
- The bits of kldxref.c that write out linker.hints now use the
encoding (ELFDATA2[LM]SB) of the first file encountered in a
directory to set the endianness of the output file. Input files
with a different architecture in the same directory are skipped with
a warning. In addition, the initial version record for the file
must be deferred until the first record is finished since the
architecture of the output file is not known until then.
- Various places that used 'sizeof(void *)' throughout now use
'elf_pointer_size()' to determine the size of a pointer in the
target architecture.
Tested by: amd64 binary on both amd64 and i386 /boot/kernel
Reviewed by: imp
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42966
- Add a free_pnp_list to complement parse_pnp_list. Add freeing
of 'new_desc' which was previously leaked.
- Move body of loop that checked a single pnp list element against a
table entry into a parse_pnp_entry function to reduce indentation
and split parse_entry into a smaller function.
- Similarly, split out a record_pnp_info function from parse_entry
which builds the pnp_list and walks a table.
Reviewed by: imp
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42965
This was originally used (along with FREEBSD_AOUT) to prefer the use
of ELF in various tools instead of a.out as part of the a.out to ELF
transition in the 3.x days. The last use of it was removed from
<link.h> in commit 66422f5b7a back in
2002, but various files still #define it.
Reviewed by: kevans, imp, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42964
This uses the statement from other files in kldxref when the tool was
first imported in commit 9c6f92408c.
Reviewed by: kevans
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42963
This patch refactors the existing Intel-specific single-stepping
mechanism in bhyve's GDB stub to work with both AMD and Intel CPUs.
Reviewed by: jhb
Sponsored by: Google, Inc. (GSoC 2022)
Differential Revision: https://reviews.freebsd.org/D42298
It appears that the only user of this macro was removed
with support for building a.out binaries in 2002 by commit
66422f5b7a.
Reviewed by: imp, kib
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42997
This has not been a univerally available interface since it was removed
from amd64 by commit efbef97de9 in 2004.
I removed the last consumers in 2016 when I replaced pipe(2) with
pipe2(2) in commit b60998c633.
Reviewed by: imp, jhibbits
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D42996