A very early WIP of an update to libpcap #10
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
the last commit before the upstream release/16.x branch was created.
…40-gfbd2950d8d0d.
…ba6a9c9f65b (aka 15.0.0 release).
Discussed with: melifaro MFC after: 3 days
Reported by: ceri Sponsored by: Junpier Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: pstef Differential Revision: https://reviews.freebsd.org/D38399
Reported by: markj Sponsored by: Juniper Networks, Inc. Sponsored bu: Klara, Inc. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D38400
Reported by: kib Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D38401
Security: CVE-2023-25136 Obtained from: OpenSSH-portable commit 12da78233364 Sponsored by: The FreeBSD Foundation
its first argument unless it was one of the special keywords "any" or "none". Obtained from: OpenSSH-portable commit b3daa8dc5823 Sponsored by: The FreeBSD Foundation
This driver is based of the enic (Cisco VIC) DPDK driver. It provides basic ethernet functionality. Has been run with various VIC cards to do UEFI PXE boot with NFS root.
PR: 266863 MFC after: 1 week Reviewed by: allanjude, cperciva, des Differential Revision: https://reviews.freebsd.org/D38372
While there, remove .Tn from man pages. Also remove an obsolete comment about the 80386. MFC after: 1 week Sponsored by: Klara, Inc. Reviewed by: kevans, allanjude Differential Revision: https://reviews.freebsd.org/D38373
never write a name with bad characters to a known_hosts file. replace recently-added valid_domain() check for hostnames going to known_hosts with a more relaxed check for bad characters. Obtained from: OpenSSH-portable commit 445363433ba2 Obtained from: OpenSSH-portable commit 3cae9f92a318 Sponsored by: The FreeBSD Foundation
Remove debug flags, old FreeBSD tag info and old include info.
Summary: Add 2 new APIs for supporting recent mbuf changes: * 36e0a36 added the m_snd_tag_alloc() wrapper around if_snd_tag_alloc(). Push this down to the ifnet level. * 4d7a136 adds the m_rcvif_serialize()/m_rcvif_restore() KPIs to serialize and restore an ifnet pointer. Add the necessary wrapper to get the index generation for this. Reviewed By: jhb Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D38340
Sponsored by: Juniper Networks, Inc.
Use the if_getcounter() IfAPI instead of accessing the ifnet directly. Sponsored by: Juniper Networks, Inc.
Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D37805
Changing cursor, screenmap and setting blanktime doesn't work when booted with vt(4) and UEFI so add a special case for those depending on machdep.bootmethods. I have no way to test if this can work with vt(4) and bios boot so just in case keep calling those for this. Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D38293
This fixes kernel build with nodevice bpf [1]. [1] https://lists.freebsd.org/archives/freebsd-current/2023-February/003178.html Reported by: Gary Jennejohn <[email protected]> Reviewed by: jhibbits Fixes: 950cc1f bpf: Add "_if" tap APIs Differential Revision: https://reviews.freebsd.org/D38432
* The sparsity check was ineffective: it compared the apparent size in bytes to the actual size in blocks. Instead, write a tool that reliably detects sparseness. * Some of the seq commands were missing an argument. * Based on empirical evidence, 1 MB holes are not necessarily large enough to be preserved by the underlying filesystem. Increase the hole size to 16 MB. MFC after: 1 week Sponsored by: Klara, Inc. Reviewed by: cracauer Differential Revision: https://reviews.freebsd.org/D38414
In iommu_gas.c, domain->start_gap points to one of the nodes on either side of the first free, unallocated range. In iommu_gas_init_domain, it is initialized to point to the node after the single free range. Change it to point to the node before that free range, so that, when 'lowaddr' is within the initial free range, the first allocation search for free space below 'lowaddr' does not begin and end at an address above 'lowaddr'. This fixes problems on a machine with Intel DMAR enabled. Reported by: jah Reviewed by: dougm Tested by: jah Obtained from: jah Fixes: commit db151ca iommu_gas: start space search from 1st free space MFC after: 1 day
Merge commit '755d9301ca89f02956fd17858b9d4d821ab5c972' from the vendor branch. This updates us from lua 5.4.2 to 5.4.4. In addition, it switches around how we flavor liblua for the boot loader and flua. This is done to reduce diffs with upstream and make it easier to import new versions (the current method has too many conflicts to resolve by hand): we include luaconf.local.h from luaconf.h (the only change to this file is now that #include at the end). We then define what we need to: for flua (which does very little) and one for stand (which creates the new FLOAT type out of int64). Sponsored by: Netflix
GELI allows to read a user key from a standard input. However if user initialize multiple providers at once, the standard input will be empty for the second and next providers. This caused GELI to encrypt a master key with an empty key file. This commits initialize the HMAC with the key file, and then reuse the finalized structure to generate different encryption keys for different providers. Reported by: Nathan Dorfman Tested by: philip Security: FreeBSD-SA-23:01.geli Security: CVE-2023-0751
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15-init-15358-g53dc0f10787. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15-init-16436-g18a6ab5b8d1f. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15-init-17485-ga3e38b4a206b. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before the upstream release/16.x branch was created. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15.0.0-rc2-40-gfbd2950d8d0d. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15.0.0-9-g1c73596d3454. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15.0.2-10-gf3c5289e7846. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15.0.6-0-g088f33605d8a. PR: 265425 MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15.0.7-0-g8dfdcc7b7bf6. PR: 265425 MFC after: 2 weeks
PR: 265425 MFC after: 2 weeks
The variable expansion as written will never match anything but 'amd64/.8' in OBJDIR. The original intention behind the construct remains unclear, but "as is" it serves no other purpose but to generate the warning. Remove it altogether. Fixes: df90aea Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D38440
Clear the rings before reset to avoid a HW hang. Inspired by em-7.7.8 and DPDK (1fc9701238edcf0541289b9ae15565b6d9d7ab30) Reviewed by: erj MFC after: 2 weeks Sponsored by: BBOX.io Pull Request: freebsd#540
Incrementing these to avoid confusion in users; we are on par with these out of tree versions. Reviewed by: erj MFC after: 2 weeks Sponsored by: BBOX.io Pull Request: freebsd#540
This program prints the number of CPU threads it can run on, while respecting cpusets (or not, depending on switches). It aims to be compatible with nproc as found in GNU coreutils. Reviewed by: des Reviewed by: pstef Differential Revision: https://reviews.freebsd.org/D38386
emaste
pushed a commit
that referenced
this pull request
Apr 3, 2023
Under certain loads, the following panic is hit:
panic: page fault
KDB: stack backtrace:
#0 0xffffffff805db025 at kdb_backtrace+0x65
#1 0xffffffff8058e86f at vpanic+0x17f
#2 0xffffffff8058e6e3 at panic+0x43
#3 0xffffffff808adc15 at trap_fatal+0x385
#4 0xffffffff808adc6f at trap_pfault+0x4f
#5 0xffffffff80886da8 at calltrap+0x8
#6 0xffffffff80669186 at vgonel+0x186
#7 0xffffffff80669841 at vgone+0x31
#8 0xffffffff8065806d at vfs_hash_insert+0x26d
#9 0xffffffff81a39069 at sfs_vgetx+0x149
#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
freebsd#11 0xffffffff8065a28c at lookup+0x45c
freebsd#12 0xffffffff806594b9 at namei+0x259
freebsd#13 0xffffffff80676a33 at kern_statat+0xf3
freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f
freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c
freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8
The page fault occurs because vgonel() will call VOP_CLOSE() for active
vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While
here, define vop_open for consistency.
After adding the necessary vop, the bug progresses to the following
panic:
panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1)
cpuid = 17
KDB: stack backtrace:
#0 0xffffffff805e29c5 at kdb_backtrace+0x65
#1 0xffffffff8059620f at vpanic+0x17f
#2 0xffffffff81a27f4a at spl_panic+0x3a
#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40
#4 0xffffffff8066fdee at vinactivef+0xde
#5 0xffffffff80670b8a at vgonel+0x1ea
#6 0xffffffff806711e1 at vgone+0x31
#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d
#8 0xffffffff81a39069 at sfs_vgetx+0x149
#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
#10 0xffffffff80661c2c at lookup+0x45c
freebsd#11 0xffffffff80660e59 at namei+0x259
freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3
freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f
freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c
freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8
This is caused by a race condition that can occur when allocating a new
vnode and adding that vnode to the vfs hash. If the newly created vnode
loses the race when being inserted into the vfs hash, it will not be
recycled as its usecount is greater than zero, hitting the above
assertion.
Fix this by dropping the assertion.
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700
Reviewed-by: Andriy Gapon <[email protected]>
Reviewed-by: Mateusz Guzik <[email protected]>
Reviewed-by: Alek Pinchuk <[email protected]>
Reviewed-by: Ryan Moeller <[email protected]>
Signed-off-by: Rob Wing <[email protected]>
Co-authored-by: Rob Wing <[email protected]>
Submitted-by: Klara, Inc.
Sponsored-by: rsync.net
Closes #14501
emaste
pushed a commit
that referenced
this pull request
Jul 17, 2023
Under certain loads, the following panic is hit:
panic: page fault
KDB: stack backtrace:
#0 0xffffffff805db025 at kdb_backtrace+0x65
#1 0xffffffff8058e86f at vpanic+0x17f
#2 0xffffffff8058e6e3 at panic+0x43
#3 0xffffffff808adc15 at trap_fatal+0x385
#4 0xffffffff808adc6f at trap_pfault+0x4f
#5 0xffffffff80886da8 at calltrap+0x8
#6 0xffffffff80669186 at vgonel+0x186
#7 0xffffffff80669841 at vgone+0x31
#8 0xffffffff8065806d at vfs_hash_insert+0x26d
#9 0xffffffff81a39069 at sfs_vgetx+0x149
#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
freebsd#11 0xffffffff8065a28c at lookup+0x45c
freebsd#12 0xffffffff806594b9 at namei+0x259
freebsd#13 0xffffffff80676a33 at kern_statat+0xf3
freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f
freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c
freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8
The page fault occurs because vgonel() will call VOP_CLOSE() for active
vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While
here, define vop_open for consistency.
After adding the necessary vop, the bug progresses to the following
panic:
panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1)
cpuid = 17
KDB: stack backtrace:
#0 0xffffffff805e29c5 at kdb_backtrace+0x65
#1 0xffffffff8059620f at vpanic+0x17f
#2 0xffffffff81a27f4a at spl_panic+0x3a
#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40
#4 0xffffffff8066fdee at vinactivef+0xde
#5 0xffffffff80670b8a at vgonel+0x1ea
#6 0xffffffff806711e1 at vgone+0x31
#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d
#8 0xffffffff81a39069 at sfs_vgetx+0x149
#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
#10 0xffffffff80661c2c at lookup+0x45c
freebsd#11 0xffffffff80660e59 at namei+0x259
freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3
freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f
freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c
freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8
This is caused by a race condition that can occur when allocating a new
vnode and adding that vnode to the vfs hash. If the newly created vnode
loses the race when being inserted into the vfs hash, it will not be
recycled as its usecount is greater than zero, hitting the above
assertion.
Fix this by dropping the assertion.
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700
Reviewed-by: Andriy Gapon <[email protected]>
Reviewed-by: Mateusz Guzik <[email protected]>
Reviewed-by: Alek Pinchuk <[email protected]>
Reviewed-by: Ryan Moeller <[email protected]>
Signed-off-by: Rob Wing <[email protected]>
Co-authored-by: Rob Wing <[email protected]>
Submitted-by: Klara, Inc.
Sponsored-by: rsync.net
Closes #14501
emaste
pushed a commit
that referenced
this pull request
Jul 31, 2023
Avoid locking issues when if_allmulti() calls the driver's if_ioctl, because that may acquire sleepable locks (while we hold a non-sleepable rwlock). Fortunately there's no pressing need to hold the mroute lock while we do this, so we can postpone the call slightly, until after we've released the lock. This avoids the following WITNESS warning (with iflib drivers): lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff82f64960 IPv4 multicast forwarding (IPv4 multicast forwarding, rw) @ /usr/src/sys/netinet/ip_mroute.c:1050 2nd 0xfffff8000480f180 iflib ctx lock (iflib ctx lock, sx) @ /usr/src/sys/net/iflib.c:4525 lock order IPv4 multicast forwarding -> iflib ctx lock attempted at: #0 0xffffffff80bbd6ce at witness_checkorder+0xbbe #1 0xffffffff80b56d10 at _sx_xlock+0x60 #2 0xffffffff80c9ce5c at iflib_if_ioctl+0x2dc #3 0xffffffff80c7c395 at if_setflag+0xe5 #4 0xffffffff82f60a0e at del_vif_locked+0x9e #5 0xffffffff82f5f0d5 at X_ip_mrouter_set+0x265 #6 0xffffffff80bfd402 at sosetopt+0xc2 #7 0xffffffff80c02105 at kern_setsockopt+0xa5 #8 0xffffffff80c02054 at sys_setsockopt+0x24 #9 0xffffffff81046be8 at amd64_syscall+0x138 #10 0xffffffff8101930b at fast_syscall_common+0xf8 See also: https://redmine.pfsense.org/issues/12079 Reviewed by: mjg Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D41209
emaste
pushed a commit
that referenced
this pull request
Sep 16, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl freebsd#11 get_operstate_ether freebsd#12 get_operstate freebsd#13 dump_iface freebsd#14 rtnl_handle_ifevent freebsd#15 rtnl_handle_ifnet_event freebsd#16 rt_ifmsg freebsd#17 if_unroute freebsd#18 if_down freebsd#19 if_detach_internal freebsd#20 if_detach freebsd#21 ether_ifdetach freebsd#22 cxgbe_vi_detach freebsd#23 cxgbe_detach freebsd#24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications
emaste
pushed a commit
that referenced
this pull request
Oct 13, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl freebsd#11 get_operstate_ether freebsd#12 get_operstate freebsd#13 dump_iface freebsd#14 rtnl_handle_ifevent freebsd#15 rtnl_handle_ifnet_event freebsd#16 rt_ifmsg freebsd#17 if_unroute freebsd#18 if_down freebsd#19 if_detach_internal freebsd#20 if_detach freebsd#21 ether_ifdetach freebsd#22 cxgbe_vi_detach freebsd#23 cxgbe_detach freebsd#24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications (cherry picked from commit 3814249)
emaste
pushed a commit
that referenced
this pull request
Oct 25, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl freebsd#11 get_operstate_ether freebsd#12 get_operstate freebsd#13 dump_iface freebsd#14 rtnl_handle_ifevent freebsd#15 rtnl_handle_ifnet_event freebsd#16 rt_ifmsg freebsd#17 if_unroute freebsd#18 if_down freebsd#19 if_detach_internal freebsd#20 if_detach freebsd#21 ether_ifdetach freebsd#22 cxgbe_vi_detach freebsd#23 cxgbe_detach freebsd#24 DEVICE_DETACH Sponsored by: Chelsio Communications Approved by: re (kib) (cherry picked from commit 3814249) (cherry picked from commit 3287f64)
emaste
added a commit
that referenced
this pull request
Aug 21, 2024
A number of people have reported panics with it enabled by default, possibly due to broken ACPI tables, which we do not handle well. D46382 is a potential fix for this issue. Additionally DMAR is currently not compatible with bhyve passthrough (see comment #10 in PR280817), with a draft patch to address that in D25672. Revert to disabling DMAR by default pending the resolution of those two issues. This reverts commit 3192fc3. PR: 280817 Sponsored by: The FreeBSD Foundation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.