aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-10idpf: split &idpf_queue into 4 strictly-typed queue structuresAlexander Lobakin7-728/+1018
Currently, sizeof(struct idpf_queue) is 32 Kb. This is due to the 12-bit hashtable declaration at the end of the queue. This HT is needed only for Tx queues when the flow scheduling mode is enabled. But &idpf_queue is unified for all of the queue types, provoking excessive memory usage. The unified structure in general makes the code less effective via suboptimal fields placement. You can't avoid that unless you make unions each 2 fields. Even then, different field alignment etc., doesn't allow you to optimize things to the limit. Split &idpf_queue into 4 structures corresponding to the queue types: RQ (Rx queue), SQ (Tx queue), FQ (buffer queue), and CQ (completion queue). Place only needed fields there and shortcuts handy for hotpath. Allocate the abovementioned hashtable dynamically and only when needed, keeping &idpf_tx_queue relatively short (192 bytes, same as Rx). This HT is used only for OOO completions, which aren't really hotpath anyway. Note that this change must be done atomically, otherwise it's really easy to get lost and miss something. Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-07-10idpf: stop using macros for accessing queue descriptorsAlexander Lobakin5-50/+52
In C, we have structures and unions. Casting `void *` via macros is not only error-prone, but also looks confusing and awful in general. In preparation for splitting the queue structs, replace it with a union and direct array dereferences. Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Mina Almasry <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-07-10libeth: add cacheline / struct layout assertion helpersAlexander Lobakin1-0/+66
Add helpers to assert struct field layout, a bit more crazy and networking-specific than in <linux/cache.h>. They assume you have 3 CL-aligned groups (read-mostly, read-write, cold) in a struct you want to assert, and nothing besides them. For 64-bit with 64-byte cachelines, the assertions are as strict as possible, as the size can then be easily predicted. For the rest, make sure they don't cross the specified bound. Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-07-10page_pool: use __cacheline_group_{begin, end}_aligned()Alexander Lobakin2-11/+14
Instead of doing __cacheline_group_begin() __aligned(), use the new __cacheline_group_{begin,end}_aligned(), so that it will take care of the group alignment itself. Also replace open-coded `4 * sizeof(long)` in two places with a definition. Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-07-10cache: add __cacheline_group_{begin, end}_aligned() (+ couple more)Alexander Lobakin1-0/+59
__cacheline_group_begin(), unfortunately, doesn't align the group anyhow. If it is wanted, then you need to do something like __cacheline_group_begin(grp) __aligned(ALIGN) which isn't really convenient nor compact. Add the _aligned() counterparts to align the groups automatically to either the specified alignment (optional) or ``SMP_CACHE_BYTES``. Note that the actual struct layout will then be (on x64 with 64-byte CL): struct x { u32 y; // offset 0, size 4, padding 56 __cacheline_group_begin__grp; // offset 64, size 0 u32 z; // offset 64, size 4, padding 4 __cacheline_group_end__grp; // offset 72, size 0 __cacheline_group_pad__grp; // offset 72, size 0, padding 56 u32 w; // offset 128 }; The end marker is aligned to long, so that you can assert the struct size more strictly, but the offset of the next field in the structure will be aligned to the group alignment, so that the next field won't fall into the group it's not intended to. Add __LARGEST_ALIGN definition and LARGEST_ALIGN() macro. __LARGEST_ALIGN is the value to which the compilers align fields when __aligned_largest is specified. Sometimes, it might be needed to get this value outside of variable definitions. LARGEST_ALIGN() is macro which just aligns a value to __LARGEST_ALIGN. Also add SMP_CACHE_ALIGN(), similar to L1_CACHE_ALIGN(), but using ``SMP_CACHE_BYTES`` instead of ``L1_CACHE_BYTES`` as the former also accounts L2, needed in some cases. Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-07-10bcachefs: fix scheduling while atomic in break_cycle()Kent Overstreet3-4/+24
Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bpf: Remove tst_run from lwt_seg6local_prog_ops.Sebastian Andrzej Siewior1-1/+0
The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL. Suggested-by: Martin KaFai Lau <[email protected]> Reported-by: [email protected] Fixes: d1542d4ae4df ("seg6: Use nested-BH locking for seg6_bpf_srh_states.") Fixes: 004d4b274e2a ("ipv6: sr: Add seg6local action End.BPF") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]>
2024-07-10bcachefs: Fix RCU splatKent Overstreet2-1/+9
Reported-by: [email protected] Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10Merge tag 'platform-drivers-x86-v6.10-6' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fix from Hans de Goede: "One-liner fix for a dmi_system_id array in the toshiba_acpi driver not being terminated properly. Something which somehow has escaped detection since being introduced in 2022 until now" * tag 'platform-drivers-x86-v6.10-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: toshiba_acpi: Fix array out-of-bounds access
2024-07-10Merge tag 'acpi-6.10-rc8' of ↵Linus Torvalds1-21/+16
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Fix the sorting of _CST output data in the ACPI processor idle driver (Kuan-Wei Chiu)" * tag 'acpi-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
2024-07-10Merge tag 'pm-6.10-rc8' of ↵Linus Torvalds2-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "Fix two issues related to boost frequencies handling, one in the cpufreq core and one in the ACPI cpufreq driver (Mario Limonciello)" * tag 'pm-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: ACPI: Mark boost policy as enabled when setting boost cpufreq: Allow drivers to advertise boost enabled
2024-07-10Merge tag 'thermal-6.10-rc8' of ↵Linus Torvalds3-7/+17
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix a possible NULL pointer dereference in a thermal governor, fix up the handling of thermal zones enabled before their temperature can be determined and fix list sorting during thermal zone temperature updates. Specifics: - Prevent the Power Allocator thermal governor from dereferencing a NULL pointer if it is bound to a tripless thermal zone (Nícolas Prado) - Prevent thermal zones enabled too early from staying effectively dormant forever because their temperature cannot be determined initially (Rafael Wysocki) - Fix list sorting during thermal zone temperature updates to ensure the proper ordering of trip crossing notifications (Rafael Wysocki)" * tag 'thermal-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: core: Fix list sorting in __thermal_zone_device_update() thermal: core: Call monitor_thermal_zone() if zone temperature is invalid thermal: gov_power_allocator: Return early in manage if trip_max is NULL
2024-07-10Merge tag 'devicetree-fixes-for-6.10-2' of ↵Linus Torvalds1-14/+4
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fix from Rob Herring: - One fix for PASemi Nemo board interrupts * tag 'devicetree-fixes-for-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of/irq: Disable "interrupt-map" parsing for PASEMI Nemo
2024-07-10vfio/pci: Init the count variable in collecting hot-reset devicesYi Liu1-1/+1
The count variable is used without initialization, it results in mistakes in the device counting and crashes the userspace if the get hot reset info path is triggered. Fixes: f6944d4a0b87 ("vfio/pci: Collect hot-reset devices to local buffer") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219010 Reported-by: Žilvinas Žaltiena <[email protected]> Cc: Beld Zhang <[email protected]> Signed-off-by: Yi Liu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
2024-07-10platform/x86: toshiba_acpi: Fix array out-of-bounds accessArmin Wolf1-0/+1
In order to use toshiba_dmi_quirks[] together with the standard DMI matching functions, it must be terminated by a empty entry. Since this entry is missing, an array out-of-bounds access occurs every time the quirk list is processed. Fix this by adding the terminating empty entry. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Fixes: 3cb1f40dfdc3 ("drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models") Cc: [email protected] Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-07-10bcachefs: Add missing bch2_trans_begin()Kent Overstreet1-0/+2
this fixes a 'transaction should be locked' error in backpointers fsck Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Fix missing error check in journal_entry_btree_keys_validate()Kent Overstreet1-0/+2
Closes: https://syzkaller.appspot.com/bug?extid=8996d8f176cf946ef641 Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Warn on attempting a move with no replicasKent Overstreet1-0/+10
Instead of popping an assert in bch2_write(), WARN and print out some debugging info. Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: bch2_data_update_to_text()Kent Overstreet3-25/+39
Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Log mount failure error codeKent Overstreet1-0/+2
Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Fix undefined behaviour in eytzinger1_first()Kent Overstreet1-2/+4
Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Mark bch_inode_info as SLAB_ACCOUNTYouling Tang1-1/+2
After commit 230e9fc28604 ("slab: add SLAB_ACCOUNT flag"), we need to mark the inode cache as SLAB_ACCOUNT, similar to commit 5d097056c9a0 ("kmemcg: account for certain kmem allocations to memcg") Signed-off-by: Youling Tang <[email protected]> Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Fix bch2_inode_insert() race path for tmpfilesKent Overstreet1-0/+6
Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10closures: fix closure_sync + closure debuggingKent Overstreet2-0/+10
originally, stack closures were only used synchronously, and with the original implementation of closure_sync() the ref never hit 0; thus, closure_put_after_sub() assumes that if the ref hits 0 it's on the debug list, in debug mode. that's no longer true with the current implementation of closure_sync, so we need a new magic so closure_debug_destroy() doesn't pop an assert. Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10bcachefs: Fix journal getting stuck on a flush commitKent Overstreet1-4/+6
silly race Signed-off-by: Kent Overstreet <[email protected]>
2024-07-10ARM: davinci: Convert comma to semicolonChen Ni1-1/+1
Replace a comma between expression statements by a semicolon. Fixes: efc1bb8a6fd5 ("davinci: add power management support") Signed-off-by: Chen Ni <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2024-07-10Merge tag 'mt76-for-kvalo-2024-07-08' of https://github.com/nbd168/wirelessKalle Valo24-846/+2095
mt76 patches for 6.11 - mt7925 MLO support - mt7925 fix
2024-07-10wifi: mac80211: fix AP chandef capturing in CSAJohannes Berg1-3/+6
When the CSA is announced with only HT elements, the AP chandef isn't captured correctly, leading to crashes in the later code that checks for TPE changes during CSA. Capture the AP chandef correctly in both cases to fix this. Reported-by: Jouni Malinen <[email protected]> Fixes: 4540568136fe ("wifi: mac80211: handle TPE element during CSA") Link: https://patch.msgid.link/20240709160851.47805f24624d.I024091f701447f7921e93bb23b46e01c2f46347d@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-07-10wifi: iwlwifi: correctly reference TSO page informationBenjamin Berg1-2/+2
The code got copied from get_workaround_page, but here p->page is the correct way to reference the page. Signed-off-by: Benjamin Berg <[email protected]> Fixes: adc902ceada2 ("wifi: iwlwifi: keep the TSO and workaround pages mapped") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-10Merge branch 'aquantia-phy-aqr115c' into mainDavid S. Miller3-4/+42
Bartosz Golaszewski says: ==================== net: phy: aquantia: enable support for aqr115c This series addesses two issues with the aqr115c PHY on Qualcomm sa8775p-ride-r3 board and adds support for this PHY to the aquantia driver. While the manufacturer calls the 2.5G PHY mode OCSGMII, we reuse the existing 2500BASEX mode in the kernel to avoid extending the uAPI. It took me a while to resend because I noticed an issue with the PHY coming out of suspend with no possible interfaces listed and tracked it to the GLOBAL_CFG registers for different modes returning 0. A workaround has been added to the series. Unfortunately the HPG doesn't mention a proper way of doing it or even mention any such issue at all. Changes since v2: - add a patch that addresses an issue with GLOBAL_CFG registers returning 0 - reuse aqr113c_config_init() for aqr115c - improve commit messages, give more details on the 2500BASEX mode reuse Link to v2: https://lore.kernel.org/lkml/[email protected]/T/ Changes since v1: - split out the PHY patches into their own series - don't introduce new mode (OCSGMII) but use existing 2500BASEX instead - split the wait-for-FW patch into two: one renaming and exporting the relevant function and the second using it before checking the FW ID Link to v1: https://lore.kernel.org/linux-arm-kernel/[email protected]/T/ ==================== Signed-off-by: David S. Miller <[email protected]>
2024-07-10libceph: fix race between delayed_work() and ceph_monc_stop()Ilya Dryomov1-2/+12
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed Cc: [email protected] Link: https://tracker.ceph.com/issues/66857 Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Xiubo Li <[email protected]>
2024-07-10minixfs: Fix minixfs_rename with HIGHMEMMatthew Wilcox (Oracle)1-2/+1
minixfs now uses kmap_local_page(), so we can't call kunmap() to undo it. This one call was missed as part of the commit this fixes. Fixes: 6628f69ee66a (minixfs: Use dir_put_page() in minix_unlink() and minix_rename()) Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2024-07-10net: phy: aquantia: add support for aqr115cBartosz Golaszewski1-0/+26
Add support for a new model to the Aquantia driver. This PHY supports 2.5 gigabit speeds. The PHY mode is referred to by the manufacturer as Overclocked SGMII (OCSGMII) but this actually is just 2500BASEX without in-band signalling so reuse the existing mode to avoid changing the uAPI. Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-10net: phy: aquantia: wait for the GLOBAL_CFG to start returning real valuesBartosz Golaszewski1-1/+7
When the PHY is first coming up (or resuming from suspend), it's possible that although the FW status shows as running, we still see zeroes in the GLOBAL_CFG set of registers and cannot determine available modes. Since all models support 10M, add a poll and wait the config to become available. Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-10net: phy: aquantia: wait for FW reset before checking the vendor IDBartosz Golaszewski1-0/+4
Checking the firmware register before it complete the boot process makes no sense, it will report 0 even if FW is available from internal memory. Always wait for FW to boot before continuing or we'll unnecessarily try to load it from nvmem/filesystem and fail. Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-10net: phy: aquantia: rename and export aqr107_wait_reset_complete()Bartosz Golaszewski2-3/+5
This function is quite generic in this driver and not limited to aqr107. We will use it outside its current compilation unit soon so rename it and declare it in the header. Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-09bpf: relax zero fixed offset constraint on KF_TRUSTED_ARGS/KF_RCUMatt Bobrowski4-15/+12
Currently, BPF kfuncs which accept trusted pointer arguments i.e. those flagged as KF_TRUSTED_ARGS, KF_RCU, or KF_RELEASE, all require an original/unmodified trusted pointer argument to be supplied to them. By original/unmodified, it means that the backing register holding the trusted pointer argument that is to be supplied to the BPF kfunc must have its fixed offset set to zero, or else the BPF verifier will outright reject the BPF program load. However, this zero fixed offset constraint that is currently enforced by the BPF verifier onto BPF kfuncs specifically flagged to accept KF_TRUSTED_ARGS or KF_RCU trusted pointer arguments is rather unnecessary, and can limit their usability in practice. Specifically, it completely eliminates the possibility of constructing a derived trusted pointer from an original trusted pointer. To put it simply, a derived pointer is a pointer which points to one of the nested member fields of the object being pointed to by the original trusted pointer. This patch relaxes the zero fixed offset constraint that is enforced upon BPF kfuncs which specifically accept KF_TRUSTED_ARGS, or KF_RCU arguments. Although, the zero fixed offset constraint technically also applies to BPF kfuncs accepting KF_RELEASE arguments, relaxing this constraint for such BPF kfuncs has subtle and unwanted side-effects. This was discovered by experimenting a little further with an initial version of this patch series [0]. The primary issue with relaxing the zero fixed offset constraint on BPF kfuncs accepting KF_RELEASE arguments is that it'd would open up the opportunity for BPF programs to supply both trusted pointers and derived trusted pointers to them. For KF_RELEASE BPF kfuncs specifically, this could be problematic as resources associated with the backing pointer could be released by the backing BPF kfunc and cause instabilities for the rest of the kernel. With this new fixed offset semantic in-place for BPF kfuncs accepting KF_TRUSTED_ARGS and KF_RCU arguments, we now have more flexibility when it comes to the BPF kfuncs that we're able to introduce moving forward. Early discussions covering the possibility of relaxing the zero fixed offset constraint can be found using the link below. This will provide more context on where all this has stemmed from [1]. Notably, pre-existing tests have been updated such that they provide coverage for the updated zero fixed offset functionality. Specifically, the nested offset test was converted from a negative to positive test as it was already designed to assert zero fixed offset semantics of a KF_TRUSTED_ARGS BPF kfunc. [0] https://lore.kernel.org/bpf/[email protected]/ [1] https://lore.kernel.org/bpf/[email protected]/ Signed-off-by: Matt Bobrowski <[email protected]> Acked-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2024-07-09Merge branch 'fix-libbpf-bpf-skeleton-forward-backward-compat'Alexei Starovoitov2-45/+72
Andrii Nakryiko says: ==================== Fix libbpf BPF skeleton forward/backward compat Fix recently identified (but long standing) bug with handling BPF skeleton forward and backward compatibility. On libbpf side, even though BPF skeleton was always designed to be forward and backwards compatible through recording actual size of constrituents of BPF skeleton itself (map/prog/var skeleton definitions), libbpf implementation did implicitly hard-code those sizes by virtue of using a trivial array access syntax. This issue will only affect libbpf used as a shared library. Statically compiled libbpfs will always be in sync with BPF skeleton, bypassing this problem altogether. This patch set fixes libbpf, but also mitigates the problem for old libbpf versions by teaching bpftool to generate more conservative BPF skeleton, if possible (i.e., if there are no struct_ops maps defined). v1->v2: - fix SOB, add acks, typo fixes (Quentin, Eduard); - improve reporting of skipped map auto-attachment (Alan, Eduard). ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2024-07-09libbpf: improve old BPF skeleton handling for map auto-attachAndrii Nakryiko1-12/+14
Improve how we handle old BPF skeletons when it comes to BPF map auto-attachment. Emit one warn-level message per each struct_ops map that could have been auto-attached, if user provided recent enough BPF skeleton version. Don't spam log if there are no relevant struct_ops maps, though. This should help users realize that they probably need to regenerate BPF skeleton header with more recent bpftool/libbpf-cargo (or whatever other means of BPF skeleton generation). Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2024-07-09libbpf: fix BPF skeleton forward/backward compat handlingAndrii Nakryiko1-20/+27
BPF skeleton was designed from day one to be extensible. Generated BPF skeleton code specifies actual sizes of map/prog/variable skeletons for that reason and libbpf is supposed to work with newer/older versions correctly. Unfortunately, it was missed that we implicitly embed hard-coded most up-to-date (according to libbpf's version of libbpf.h header used to compile BPF skeleton header) sizes of those structs, which can differ from the actual sizes at runtime when libbpf is used as a shared library. We have a few places were we just index array of maps/progs/vars, which implicitly uses these potentially invalid sizes of structs. This patch aims to fix this problem going forward. Once this lands, we'll backport these changes in Github repo to create patched releases for older libbpfs. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Alan Maguire <[email protected]> Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support") Fixes: 430025e5dca5 ("libbpf: Add subskeleton scaffolding") Fixes: 08ac454e258e ("libbpf: Auto-attach struct_ops BPF maps in BPF skeleton") Co-developed-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2024-07-09bpftool: improve skeleton backwards compat with old buggy libbpfsAndrii Nakryiko1-14/+32
Old versions of libbpf don't handle varying sizes of bpf_map_skeleton struct correctly. As such, BPF skeleton generated by newest bpftool might not be compatible with older libbpf (though only when libbpf is used as a shared library), even though it, by design, should. Going forward libbpf will be fixed, plus we'll release bug fixed versions of relevant old libbpfs, but meanwhile try to mitigate from bpftool side by conservatively assuming older and smaller definition of bpf_map_skeleton, if possible. Meaning, if there are no struct_ops maps. If there are struct_ops, then presumably user would like to have auto-attaching logic and struct_ops map link placeholders, so use the full bpf_map_skeleton definition in that case. Acked-by: Quentin Monnet <[email protected]> Co-developed-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2024-07-09net: ethernet: lantiq_etop: fix double free in detachAleksander Jan Bajkowski1-2/+2
The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver") Reported-by: Joe Perches <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09netxen_nic: Use {low,upp}er_32_bits() helpersGeert Uytterhoeven1-5/+2
Use the existing {low,upp}er_32_bits() helpers instead of defining custom variants. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/319d4a5313ac75f7bbbb6b230b6802b18075c3e0.1720430602.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09Merge branch 'mlx5-misc-patches-2023-07-08'Jakub Kicinski4-6/+8
Tariq Toukan says: ==================== mlx5 misc patches 2023-07-08 This patchset contains features and small enhancements from the team to the mlx5 core and Eth drivers. ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09net/mlx5e: CT: Initialize err to 0 to avoid warningCosmin Ratiu1-1/+1
It is theoretically possible to return bogus uninitialized values from mlx5_tc_ct_entry_replace_rules, even though in practice this will never be the case as the flow rule will be part of at least the regular ct table or the ct nat table, if not both. But to reduce noise, initialize err to 0. Fixes: 49d37d05f216 ("net/mlx5: CT: Separate CT and CT-NAT tuple entries") Signed-off-by: Cosmin Ratiu <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09net/mlx5e: SHAMPO, Add missing aggregate counterDragos Tatulea1-0/+2
When the rx_hds_nodata_packets/bytes counters were added, the aggregate counters were omitted. This patch adds them. Fixes: e95c5b9e8912 ("net/mlx5e: SHAMPO, Add header-only ethtool counters for header data split") Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09net/mlx5: DR, Remove definer functions from SW Steering APIYevgeny Kliteynik2-5/+5
No need to expose definer get/put functions as part of SW Steering API - they are internal functions. Signed-off-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Alex Vesker <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09Merge branch 'mlxsw-improvements'Jakub Kicinski3-26/+35
Petr Machata says: ==================== mlxsw: Improvements This patchset contains assortments of improvements to the mlxsw driver. Please see individual patches for details. ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09mlxsw: pci: Lock configuration space of upstream bridge during resetIdo Schimmel1-0/+6
The driver triggers a "Secondary Bus Reset" (SBR) by calling __pci_reset_function_locked() which asserts the SBR bit in the "Bridge Control Register" in the configuration space of the upstream bridge for 2ms. This is done without locking the configuration space of the upstream bridge port, allowing user space to access it concurrently. Linux 6.11 will start warning about such unlocked resets [1][2]: pcieport 0000:00:01.0: unlocked secondary bus reset via: pci_reset_bus_function+0x51c/0x6a0 Avoid the warning and the concurrent access by locking the configuration space of the upstream bridge prior to the reset and unlocking it afterwards. [1] https://lore.kernel.org/all/171711746953.1628941.4692125082286867825.stgit@dwillia2-xfh.jf.intel.com/ [2] https://lore.kernel.org/all/20240531213150.GA610983@bhelgaas/ Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Link: https://patch.msgid.link/9937b0afdb50f2f2825945393c94c093c04a5897.1720447210.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-07-09mlxsw: core_thermal: Report valid current state during cooling device ↵Ido Schimmel1-26/+25
registration Commit 31a0fa0019b0 ("thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add()") changed the thermal core to read the current state of the cooling device as part of the cooling device's registration. This is incompatible with the current implementation of the cooling device operations in mlxsw, leading to initialization failure with errors such as: mlxsw_spectrum 0000:01:00.0: Failed to register cooling device mlxsw_spectrum 0000:01:00.0: cannot register bus device The reason for the failure is that when the get current state operation is invoked the driver tries to derive the index of the cooling device by walking a per thermal zone array and looking for the matching cooling device pointer. However, the pointer is returned from the registration function and therefore only set in the array after the registration. The issue was later fixed by commit 1af89dedc8a5 ("thermal: core: Do not fail cdev registration because of invalid initial state") by not failing the registration of the cooling device if it cannot report a valid current state during registration, although drivers are responsible for ensuring that this will not happen. Therefore, make sure the driver is able to report a valid current state for the cooling device during registration by passing to the registration function a per cooling device private data that already has the cooling device index populated. While at it, call thermal_cooling_device_unregister() unconditionally since the function returns immediately if the cooling device pointer is NULL. Reviewed-by: Vadim Pasternak <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Link: https://patch.msgid.link/c823c4678b6b7afb902c35b3551c81a053afd110.1720447210.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.