aboutsummaryrefslogtreecommitdiff
path: root/sys
Commit message (Collapse)AuthorAgeFilesLines
...
* LinuxKPI: 802.11: Management MIC element can have 8 or 16 octets MICBjoern A. Zeeb11 days1-3/+11
| | | | | | | | | Management MIC element (MME) can have 8 or 16 octets MIC. Add a second structure used by at least iwlwifi and update reference to latest standard version. Sponsored by: The FreeBSD Foundation MFC after: 3 days
* rpctls_impl.c: Use a direct cast to uintptr_t instead of __DECONSTJohn Baldwin11 days1-1/+1
| | | | | | | | | | | | | | | This fixes the build on CHERI architectures where the compiler warns about a direct cast between uint64_t and const void * inside of __DECONST. However, GCC would also complain about this on 32-bit kernels due to uint64_t not being the same size as a pointer. Also, a direct cast to uintptr_t to right-size the cookie value is more direct than using __DECONST given that there is no "const" pointer involved in the expression. Reviewed by: brooks, glebius Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54797
* dpaa2: cleanupMichael Tuexen12 days1-20/+4
| | | | | | | | No functional change intended. Reviewed by: bz, dsl MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54805
* powerpc/mpc85xx: Fix PCI attach error cleanupJustin Hibbits12 days1-2/+17
| | | | | | | | | If an error occurs during attach after ofw_pcib_init() runs, the device is torn down, leaving the rmans embedded in the softc attached to the rman list, thus corrupting the rman list. Fix this by undoing everything that was done by this point. MFC after: 1 week
* powerpc/mpc85xx: Set pc_hwref to the primary thread IDJustin Hibbits12 days1-2/+14
| | | | | | On multithreaded cores (e6500) the CPU ID in the device tree (reg[0]) is the primary core, which may not match the cpuid, until Book-E threading is added.
* dpaa: Simplify CPU binding for bman and qmanJustin Hibbits12 days2-61/+18
| | | | | | | If cpu-handle property doesn't exist simply iterate and assign the CPUs in sequence rather than following the convoluted search which may not bear fruit in some cases. If cpu-handle doesn't exist for one portal it probably doesn't exist for any of them.
* nfscl: Fix the buildRick Macklem12 days1-1/+2
| | | | Fixes: f2155a6fb568 ("nfscl: Fix handling of case insensitive file systems")
* nfscl: Fix handling of case insensitive file systemsRick Macklem12 days3-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Name caching must be handled somewhat differently for case insensitive file systems. Negative name caching does not work and, for rename, all names associated with the rename'd vnode must be disabled. For a case insensitive ZFS file system that is exported, the unpatched code did work, since the change in mtime or ctime of the directory when other case names were created or rename'd would disable the false name cache hit. However, an export of an msdosfs file system breaks the NFS client, because it only works if ctime/mtime is changed whenever a name is added/removed. Depending on what the server file system is, this may not happen, due to clock resolution or lack of support for these attributes. This patch checks to see if the server file system is case insensitive and modifies the name caching to handle this. There is still a problem if a case insensitive file system is a subtree of a non-case insensitive is exported by the NFSv4 server. This can be fixed someday, when the NFSv4 client gets support for submounts within the mount. Suggested by: kib MFC after: 2 weeks
* ktrace: do not enqueue request if the process' ktrioparams are freedKonstantin Belousov12 days1-2/+8
| | | | | | | | | | | | | The p_ktrioparms are freed on termination of tracing. Any ktr requests added to the queue after that would hang there and leak on the struct proc recycling, or trigger an assert in the process destructor for debug builds. Reported and tested by: pho Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54804
* LinuxKPI: 802.11: fix build for non-debug kernelsBjoern A. Zeeb12 days1-0/+2
| | | | | | | | | | | | | lkpi_nl80211_band_name() is only available under LINUXKPI_DEBUG_80211. IMPROVE in theory should be as well or defined to nothing but we cannot do that in cfg80211.h mac80211.h where we possibly (re-)define this. Put an #ifdef around the IMPROVE call for now (untested). Sponsored by: The FreeBSD Foundation MFC after: 3 days Fixes: 768332d61948 Reported by: CI
* sctp: support bridge interfacesMichael Tuexen12 days1-0/+1
| | | | | | Reported by: Timo Völker Tested by: Timo Völker MFC after: 3 days
* net80211: correct return code for ieee80211_ampdu_request()Bjoern A. Zeeb12 days1-5/+13
| | | | | | | | | | | | We used to return the result of (*ic_send_action) directly but ieee80211_ampdu_request() returns 1 on success and 0 on error, which is contrary to the result of (*ic_send_action). Deal with that accordingly and update the documentation of the function. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D54794
* LinuxKPI: 802.11: factor out rate logic for mandatory channelsBjoern A. Zeeb12 days3-27/+100
| | | | | | | | | | | | | | | I was looking at rate work for another problem and found more flags in ath9k (which we will likely never need). The documentation then revealed the "mandatory" flags as well and with discussions about cfg80211 going on I decided to use the momentum and split our "supp_rates" setup between lkpi_lsta_alloc() and wiphy_register(). There should be no functional change. While there also initialize max_rc_amsdu_len. Sponsored by: The FreeBSD Foundation MFC after: 3 days
* sys/abi_compat.h: fix UB for bintime32 handlingKonstantin Belousov12 days2-2/+2
| | | | | | | | | | | Do not cast and then access potentially unaligned uint64_t in the BT_CP() macro. Use freebsd32_uint64_t type and FU64_CP() for the frac member. Noted by: des Reviewed by: des, emaste Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54663
* compat32: provide a type and a macro for (u)int64_t handling on non-x86 archesKonstantin Belousov12 days2-1/+18
| | | | | | | | | | | | uint64_t is 4-byte aligned on i386, but is 8-bytes aligned on all other 32bit arches FreeBSD supports. Provide the freebsd32_uint64_t type and the FU64_CP() macro, which are intended to be used where 32bit ABI uses (u)int64_t type, and do proper layout and copying for the aggregate type. Reviewed by: des, emaste Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54663
* ip: improve deferred computation of checksumsTimo Völker13 days2-9/+29
| | | | | | | | | | | | | | | | | | | | This patch adds the same functionality for the IPv4 header checksum as was done erlier for the SCTP/TCP/UDP transport checksum. When the IP implementation sends a packet, it does not compute the corresponding checksum but defers that. It will determine whether the network interface selected for the packet has the requested capability and computes the checksum in software, if the selected network interface does not have the requested capability. Do this not only for packets being sent by the local IP stack, but also when forwarding packets. Furthermore, when such packets are delivered to a local IP stack, do not compute or validate the checksum, since such packets have never been on the wire. This allows to support checksum offloading also in the case of local virtual machines or jails. Support for epair interfaces will be added in a separate commit. Reviewed by: pouria, tuexen MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54455
* dwc: cleanupMichael Tuexen13 days1-10/+6
| | | | | | | | No functional change intended. Reviewed by: Timo Völker MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54788
* jail(3): fix common usage after mac.label supportKyle Evans13 days1-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Nobody else's mac.conf(5) has any entries for jails, so they get a trivial ENOENT and we fail before we can fetch any jail parameters. Most notably, this breaks `jls -s` / `jls -n` if you do not have any loaded policy that applies jail labels. Add an entry that works for everyone, and hardcode that as an ENOENT fallback in libjail to provide a smoother transition. This is probably not harmful to leave in long-term, since mac.conf(5) will override it. This unearthed one additional issue, in that mac_get_prison() in the MAC framework handled the no-label-policies bit wrong. We don't want to break jail utilities enumerating jail parameters automatically, so we must ingest the label in all cases -- we can still use it as a small optimization to avoid trying to copy out any label. We will break things if a non-optional element is specified in the copied in label, but that's expected. The APIs dedicated to jaildescs remain unphased, since they won't be used in the same way. Fixes: db3b39f063d9f05 ("libjail: extend struct handlers [...]") Fixes: bd55cbb50c58876 ("kern: add a mac.label jail parameter") Reported by: jlduran (on behalf of Jenkins) Reviewed by: jlduran Differential Revision: https://reviews.freebsd.org/D54786
* pfctl(8): change default limiter action from no-match to blockKristof Provost13 days1-0/+2
| | | | | | | | | | | | | | | | | pf(4) users who use limiters in current should update the rules accordingly to reflect the change in default behavior. The existing rule which reads as follows: pass in from any to any state limiter test needs to be changed to: pass in from any to any state limiter test (no-match) OK dlg@ Obtained from: OpenBSD, sashan <sashan@openbsd.org>, c600931321 Sponsored by: Rubicon Communications, LLC ("Netgate")
* sctp: improve compilation as moduleMichael Tuexen13 days1-1/+0
| | | | | | | | | | | When compiling SCTP as a module, don't compile sctp_crc32.c into the module. This avoids code and variable duplication since sctp_crc32.c is compiled into the kernel. In particular, the variable system_base_info is not duplicated. This fixes the handling of the statistic counters sctps_sendhwcrc and sctps_sendswcrc when using sctp_delayed_cksum. MFC after: 3 days
* amd64/vmm: remove unused static function vcpu_state2str()Konstantin Belousov13 days1-20/+0
| | | | | | | | | It is guarded by #ifdef KTR, so the warning does not show up under usual kernel configs. Fixes: ed85203fb7a0334041db6da07e45ddda4caef13d Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D54781
* acpi: Fix not calling AcpiLeaveSleepState() in S3 pathAymeric Wibo13 days1-6/+3
| | | | | | | | | | | | | | | | | | | | | | When resuming from ACPI suspend, the ACPI_SS_SLP_PREP bit in slp_state was being checked and subsequently unset when calling resumeclock(). This bit was also being checked for the AcpiLeaveSleepState() call in the non-s2idle path, but having just been unset, it was never actually being called. Change this so that resumeclock() is always being called (since we never goto breakout between suspendclock() and resumeclock() anyway) and ACPI_SS_SLP_PREP is purely used for AcpiEnterSleepStatePrep() and AcpiLeaveSleepState() in the non-s2idle paths. PR: 292568 Reported by: Marek Zarychta Reviewed by: olce Tested by: Marek Zarychta Approved by: olce Fixes: 7669cbd0f064 (“acpi: Suspend-to-idle support (s2idle)”) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54777
* x86/local_apic.c: Properly calculate the number of LVT entriesKonstantin Belousov13 days2-3/+11
| | | | | | | | | | | | | | | First, the CMCI entry index is APIC_LVT_MAX, so it was excluded unconditionall [1]. Second, the number of entries is reported by the version register, and we must not access past the last reported entry. Reported by: olivier [1] Fixes: 11f954b021a1aadde1d03d40ed5d6b529e14da98 Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54773
* x86/local_apic.c: add lapic_maxlvt() helperKonstantin Belousov13 days1-5/+15
| | | | | | | | | | that calculates the max index of the present LVT entry from the value of the LAPIC version register. Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54773
* sys: do not allow entering vm_fault() on boot until VM is initializedKonstantin Belousov13 days3-5/+20
| | | | | | | | | | | | On amd64, a hack sets td_critnest to 1 in hammer_time(), and then clear it before returning from hammer_time(), which is too early. Instead, set TDP_NOFAULTING for thread0, and clear the flag after vm_init() finished. Noted by: adrian Reviewed by: adrian (previous version), markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54768
* iflib: null out freed mbuf in iflib_txsd_freeAndrew Gallatin13 days1-0/+1
| | | | | | | | | | | | When adding the IFLIB_GET_MBUF/FLAGS, I neglected to NULL out the mbuf in the descriptor ring. I didn't think this should matter as the I thought this code was only used when the ring was about to be freed. But I was wrong, and leaving a stale mbuf in there can cause panics. Reported by: Marek Zarychta (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292547) Fixes: 14d93f612f26 Sponsored by: Netflix
* vmm: Avoid clobbering errors from vmm_modinit()Mark Johnston14 days1-3/+5
| | | | | | | Reported by: novel Reviewed by: bnovkov Fixes: e758074458df ("vmm: Move the module load handler to vmm_dev.c") Differential Revision: https://reviews.freebsd.org/D54750
* modules: iwlwifi/rtw89 allow standalone buildBjoern A. Zeeb2026-01-182-0/+4
| | | | | | | | | | | | | | The KERN_OPTS:MDEV_ACPI checks are fine for as long as we are building modules along the kernel. If one wants to just build the module standalone out of the module directory this would fail. Add the missing include for kmod.opts.mk (as was done for tcp in 1319a76179682). Sponsored by: The FreeBSD Foundation Reported by: Tassilo Philipp (tphilipp potion-studios.com) Fixes: f5a77dc8f8df ("improve module Makefile dependency on ACPI") Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D54769
* x86: mask all LAPIC vectors early, before BSP interrupts are enabledKonstantin Belousov2026-01-181-0/+28
| | | | | | | | | | | | | If APIC is left in somewhat bad state, with some source hot (not masked and active, e.g. timers after kexec or due to BIOS bug), we get the interrupt too early. Reported by: jmg Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54543
* x88/local_apic.c: for each lvt element, add LVT register indexKonstantin Belousov2026-01-181-0/+12
| | | | | | | | Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54543
* x86/local_apic.c: convert lvts[] and elvts[] arrays to designated initializersKonstantin Belousov2026-01-181-13/+92
| | | | | | | | Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54543
* ipfw: fix !VIMAGE buildGleb Smirnoff2026-01-181-1/+1
| | | | NB: Rest of ipfw(4) sources get sx.h via vnet.h, which isn't perfect.
* dwc: add receive checksum offload for IPv6Michael Tuexen2026-01-173-6/+6
| | | | | | | | | | | This patch adds support for receive checksum offload for TCP/IPv6 and UDP/IPv6. Since receive checksum offload can't be configured separately for IPv4 and IPv6, IFCAP_RXCSUM and IFCAP_RXCSUM_IPV6 can't be changed independently. Reviewed by: Timo Völker MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54756
* dwc: add transmit checksum offload for IPv6Michael Tuexen2026-01-172-3/+9
| | | | | | | | | This patch adds support for transmit checksum offload for TCP/IPv6 and UDP/IPv6. Reviewed by: Timo Völker MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54754
* netpfil/ipfw: Fix a typo in a source code commentGordon Bergling2026-01-171-1/+1
| | | | | | - s/vaues/values/ MFC after: 5 days
* rockship: Fix a typo in a source code commentGordon Bergling2026-01-171-1/+1
| | | | | | - s/vaues/values/ MFC after: 5 days
* dwc: prepare for IPv6 transmit checksum offloadingMichael Tuexen2026-01-161-3/+3
| | | | | | No functional change intended. MFC after: 3 days
* aq: remove from NOTES; it's unfortunately amd64 onlyAdrian Chadd2026-01-171-2/+0
| | | | | | | | Unfortunately the aq driver is using readl/writel calls instead of bus space routines. This broke, well, everything else. Fixes: c75eff16ef54aaae7b5dc52ed894cc73a855f469
* powerpc: Add ISA 2.06 sub-word atomic set/clearJustin Hibbits2026-01-171-26/+56
| | | | | | | Add atomic_set/clear_short/char for doing 8-bit and 16-bit operations more efficiently on "newer" architectures (POWER7 and later). Piggybacks on b31abc95eb.
* ipfw: refactor how we store bpf tap pointsGleb Smirnoff2026-01-175-36/+49
| | | | | | | | | | | | | | | Make the tap database belong to ip_fw_chain, but leave the default "ipfw0" tap per-vnet. This is only slightly better than keeping the database per- vnet, as the bpf name space is per-vnet. However, we yet have only single ipfw chain. Whenever multiple chains will coexist, this needs to be addressed. Require the chain lock to make modifications to the database. Move tap allocation to a later ruleset build stage, when all rule numbers are known already. This fixes a panic introduced by 3daae1ac1d82. Fixes: 3daae1ac1d82ecdcd855101bab5206e914b12350
* ipfw: in a vnet destructor use NET_EPOCH_WAIT()Gleb Smirnoff2026-01-171-5/+5
| | | | | | | The lock grab & drop predates epoch(9) introduction to the network stack and it doesn't provide a true guarantee that all threads that may use ipfw configuration have finished. Also the lock prevented from sleepable operations when freeing the rules.
* vm/swap_pager.c: silence compiler warningKonstantin Belousov2026-01-171-1/+1
| | | | | | | | | | Initialize pindex in swap_pager_getpages_locked() before the loop actually calculating it by skipping bogus pages. Compiler is worried that loop might never assign to it, which actually cannot happen. Sponsored by: The FreeBSD Foundation Fixes: d198ad51ea73bbb162336923a387f52b0b1c1f1d MFC after: 1 week
* aq: Add to amd64 GENERIC and to sys/conf/NOTESBrad Smith2026-01-172-0/+3
| | | | | Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D54633
* swap_pager_getpages(): some pages from ma[] might be bogusKonstantin Belousov2026-01-171-8/+29
| | | | | | | | | | | | | | | | | | | | | | | Same as vnode_pager_generic_getpages_async(), swap_pager_getpages() must handle a possibility of the provided page run to include bogus_page on some positions, when called from sendfile_swapin(). The swap pager is used for tmpfs vnodes. In particular, the bogus page must not be used for pindex calculation, we better not update the flags on it or wait for the flag clearing, and we must not call vm_page_valid() because the function expects busy page. This was bisected down to 72ddb6de1028426 (unix: increase net.local.(stream|seqpacket).(recv|send)space to 64 KiB), which is somewhat surprising, but apparently reasonable because it allowed the run of more than one page for page-in from the swap pager, which now might include valid pages replaced by bogus one. In collaboration with: pho Reviewed by: glebius, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54713
* swap_pager_getpages(): assert that bp->b_pages[] is accessed in boundsKonstantin Belousov2026-01-171-0/+3
| | | | | | | | Reviewed by: glebius, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54713
* sendfile: remove calculation of unused bsizeKonstantin Belousov2026-01-171-6/+3
| | | | | | | | Reviewed by: glebius, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54713
* ipfw: remove locking workarounds in the table codeGleb Smirnoff2026-01-173-373/+68
| | | | | | | | | Before the "upper half lock" became sleepable the table manipulation code needed sophisticated workarounds to recover from races, where the lock is temporarily dropped to do malloc(M_WAITOK). Remove all these workarounds as they are no longer needed. Differential Revision: https://reviews.freebsd.org/D54580
* ipfw: make the upper half lock sleepableGleb Smirnoff2026-01-178-153/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The so called upper half ipfw lock is not used in the forwarding path. It is used only during configuration changes and servicing system events like interface arrival/departure or vnet creation. The original code drops the lock before malloc(M_WAITOK) and then goes into great efforts to recover from possible races. But the races still exist, e.g. create_table() would first check for table existence, but then drop the lock. The change also fixes unlock leak in check_table_space() in a branch that apparently was never entered. Changing to a sleepable lock we can reduce a lot of existing complexity associated with race recovery, and as use the lock to cover other configuration time allocations, like recently added per-rule bpf(4) taps. This change doesn't remove much of a race recovery code, to ease bisection in case of a regression. This will be done in a separate commit. This change just removes lock drops during configuration events. The only reduction is removal of get_map(), which is a straightforward reduce to a simple malloc(9). The only sleepable context where the lock was acquired was dyn_tick(). The comment said it is done to prevent parallel execution of dyn_expire_states(). However, there is proper internal locking in there and function should be safe to execute in parallel. The real problem is dyn_expire_states() called via userland to race with dyn_grow_hashtable() called via dyn_tick(). Protect against this condition with the main chain lock. Differential Revision: https://reviews.freebsd.org/D54535
* net: on interface detach purge all its routes before detaching protocolsGleb Smirnoff2026-01-171-2/+2
| | | | | | | | | | | | | | | | Otherwise, a forwarding thread may use the interface being detached. This is a regression from 0d469d23715d, which manifests itself as a reliably reproducible panic in in6_selecthlim(). Note that there are old bug reports about such a panic, and I believe this change will not fix them, as their nature is not due to a screwed up detach sequence, but due to lack of proper epoch(9) based synchronization between the detach and forwarding. Reviewed by: pouria Reported & tested by: jhibbits PR: 292162 Fixes: 0d469d23715d690b863787ebfa51529e1f6a9092 Differential Revision: https://reviews.freebsd.org/D54721
* mxge(4): avoid clang 21 warning in NO-IP configurationDimitry Andric2026-01-161-1/+1
| | | | | | | | | | | | | | | | Building the LINT-NOIP kernel on amd64 with clang 21 results in a -Werror warning similar to: sys/dev/mxge/if_mxge.c:1846:44: error: variable 'sum' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 1846 | cksum_offset, sizeof(sum), (caddr_t)&sum); | ^~~ Indeed, if both `INET` and `INET6` are undefined, `sum` is never initialized. Initialize it to zero to silence the warning. Reviewed by: jhibbits MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54730
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-02 02:37:11 +0000