build(deps): bump idna from 3.4 to 3.7 in /drivers/gpu/drm/ci/xfails #6
Conversation
This file contains hidden or 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
Improves initial rate selection after connecting Signed-off-by: Felix Fietkau <[email protected]>
Avoid potentially reusing uninitialized data Signed-off-by: Felix Fietkau <[email protected]>
When queueing packets, only the MT76_RESET flag of the primary PHY is checked. If the primary PHY is scanning or changing channels, this can lead to packet loss for tx on the second PHY. Fix this by passing the phy to the .tx_queue_skb op and using it to check the correct flag. Signed-off-by: Felix Fietkau <[email protected]>
The mcu command format are different for mt7915 and mt7986. Fix the mt7915_mcu_wed_wa_tx_stats to support mt7915 and mt7986. Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Do not report measurements if the airtime counter was cleared since the last update (possibly by firmware) Signed-off-by: Henry Yen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Set correct beamformer capabilities for station vif in HE PHY capabilities IE. Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
The MT76_MCU_RESET flag is only read on the main phy. Signed-off-by: Bo Jiao <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
The MT76_MCU_RESET flag is only read on the main phy. Signed-off-by: Felix Fietkau <[email protected]>
Send an update to the MCU whenever the settings change Signed-off-by: MeiChia Chiu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Add pre-calibration for mt7986 and mt7916. It has different data size with mt7915. Group cal needs 54k and 94k for 2G + 5G and 2G + 6G, respectively. DPD cal needs 300k. Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: StanleyYP Wang <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
When pre-calibration data is missing, do not fail the driver probe. Instead, just print a warning and fall back to regular calibration. Signed-off-by: Felix Fietkau <[email protected]>
Use the correct WMM AC queue instead of the MGMT one to fix potential issues with aggregation sequence number tracking. Drop non-bufferable packets. Fixes: fca9615 ("mt76: mt7603: fix up hardware queue index for PS filtered packets") Signed-off-by: Felix Fietkau <[email protected]>
This flag is needed for the PSE client reset. Fixes watchdog reset issues. Fixes: c677dda ("wifi: mt76: mt7603: improve watchdog reset reliablity") Signed-off-by: Felix Fietkau <[email protected]>
The wcid can be NULL. It should be checked for validity before dereferencing it to avoid crash. Fixes: 098428c ("wifi: mt76: connac: set correct muar_idx for mt799x chipsets") Signed-off-by: Muhammad Usama Anjum <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Fixes issues with scanning and low power output at some rates. Fixes: f75e477 ("wifi: mt76: mt7996: add txpower setting support") Signed-off-by: Chad Monroe <[email protected]> Signed-off-by: Ryder Lee <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
mt7920e is a mt7921 series chipset with 802.11ax 2x2:2SS support. The major difference is in firmware side only, at this moment. This patch would add some mandatory changes for new chip id and firmware download control. Signed-off-by: Deren Wu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery. Signed-off-by: Leon Yen <[email protected]> Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Before sending suspend & wow command to FW, its length should be 4-bytes alignd. Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Set intr1 to 0 in mt7996_irq_tasklet() in order to avoid possible uninitialized variable usage if wed is not active for hif2. Fixes: 83eafc9 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Even if it is not a real issue at the moment since concurrent access to mcu message queue is protected by mcu mutex, make the code more robust and move mcu queue free space check inside queue spinlock critical section. Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Looks like this was missed in the initial patch that made the conversion to the emulated chanctx drivers. Fixes: 0a44dfc ("wifi: mac80211: simplify non-chanctx drivers") Tested-by: James Courtier-Dutton <[email protected]> Signed-off-by: Ben Greear <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
When a BMC wtbl of station interface is correctly set with peer address, HW will do rx header translation for broadcast data packets, which makes mac80211 unable to find the corresponding ieee80211_sta and drop the packets. To fix this, disable HW rx header translation for BMC entry. Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Set peer address and aid for the BMC wtbl of station interface. For some functions such as parsing MU_EDCA parameters from beacon, firmware will need the peer address to do correct parsing. Without this patch, MU uplink traffic would get suffered. Reported-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Set RCPI values in mt7996_mcu_sta_rate_ctrl_tlv(), which can make the FW rate control algorithm be initialized with a better MCS selection table. Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
For mt7996 chipsets, the HW CSO module can help to identify TCP traffic, which assists the firmware in adjusting algorithms to improve overall performance. Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Do not add UNI_BSS_INFO_11V_MBSSID tag when bssid_indicator is not set to avoid abnormal beaconing behavior in non-11v MBSS scenario. Signed-off-by: Henry Yen <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
…mperature Without this commit, reading chip temperature will cause memory leakage. Fixes: 6879b2e ("wifi: mt76: mt7996: add thermal sensor device support") Reported-by: Ryder Lee <[email protected]> Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
For mt7992 chipsets, critical packet mode should be properly configured to let the HW SDO module correctly fill the AC queue in TX descriptors of some higher priority packets such as ARP and ICMP. Without this patch, HW queues may hang when running MU traffic. Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Check if background radar is enabled or not before manually triggering it, and also add more checks in radar detected event. Signed-off-by: StanleyYP Wang <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
nbd168
pushed a commit
that referenced
this pull request
May 15, 2025
In ThinPro, we use the convention <upstream_ver>+hp<patchlevel> for
the kernel package. This does not have a dash in the name or version.
This is built by editing ".version" before a build, and setting
EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables:
echo 68 > .version
make -j<n> EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69
.deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb
Since commit 7d4f07d ("kbuild: deb-pkg: squash
scripts/package/deb-build-option to debian/rules"), this no longer
works. The deb build logic changed, even though, the commit message
implies that the logic should be unmodified.
Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did
not contain a dash. After the change KBUILD_BUILD_VERSION is always
set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname
output to look off:
(now) uname -a: version 6.12.2+hp ... #6.12.2+hp69
(expected) uname -a: version 6.12.2+hp ... #69
Update the debian/rules logic to restore the original behavior.
Fixes: 7d4f07d ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules")
Signed-off-by: Alexandru Gagniuc <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
nbd168
pushed a commit
that referenced
this pull request
May 15, 2025
syzkaller triggered an oversized kvmalloc() warning. Silence it by adding __GFP_NOWARN. syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 3782495 ("RDMA/odp: Use kvcalloc for the dma_list and page_list") Signed-off-by: Shay Drory <[email protected]> Link: https://patch.msgid.link/c6cb92379de668be94894f49c2cfa40e73f94d56.1742388096.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky <[email protected]>
nbd168
pushed a commit
that referenced
this pull request
May 15, 2025
Ido Schimmel says: ==================== vxlan: Convert FDB table to rhashtable The VXLAN driver currently stores FDB entries in a hash table with a fixed number of buckets (256), resulting in reduced performance as the number of entries grows. This patchset solves the issue by converting the driver to use rhashtable which maintains a more or less constant performance regardless of the number of entries. Measured transmitted packets per second using a single pktgen thread with varying number of entries when the transmitted packet always hits the default entry (worst case): Number of entries | Improvement ------------------|------------ 1k | +1.12% 4k | +9.22% 16k | +55% 64k | +585% 256k | +2460% The first patches are preparations for the conversion in the last patch. Specifically, the series is structured as follows: Patch #1 adds RCU read-side critical sections in the Tx path when accessing FDB entries. Targeting at net-next as I am not aware of any issues due to this omission despite the code being structured that way for a long time. Without it, traces will be generated when converting FDB lookup to rhashtable_lookup(). Patch #2-#5 simplify the creation of the default FDB entry (all-zeroes). Current code assumes that insertion into the hash table cannot fail, which will no longer be true with rhashtable. Patches #6-#10 add FDB entries to a linked list for entry traversal instead of traversing over them using the fixed size hash table which is removed in the last patch. Patches #11-#12 add wrappers for FDB lookup that make it clear when each should be used along with lockdep annotations. Needed as a preparation for rhashtable_lookup() that must be called from an RCU read-side critical section. Patch #13 treats dst cache initialization errors as non-fatal. See more info in the commit message. The current code happens to work because insertion into the fixed size hash table is slow enough for the per-CPU allocator to be able to create new chunks of per-CPU memory. Patch #14 adds an FDB key structure that includes the MAC address and source VNI. To be used as rhashtable key. Patch #15 does the conversion to rhashtable. ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
nbd168
pushed a commit
that referenced
this pull request
May 15, 2025
Commit 03df156 ("xdp: double protect netdev->xdp_flags with netdev->lock") introduces the netdev lock to xdp_set_features_flag(). The change includes a _locked version of the method, as it is possible for a driver to have already acquired the netdev lock before calling this helper. However, the same applies to xdp_features_(set|clear)_redirect_flags(), which ends up calling the unlocked version of xdp_set_features_flags() leading to deadlocks in GVE, which grabs the netdev lock as part of its suspend, reset, and shutdown processes: [ 833.265543] WARNING: possible recursive locking detected [ 833.270949] 6.15.0-rc1 #6 Tainted: G E [ 833.276271] -------------------------------------------- [ 833.281681] systemd-shutdow/1 is trying to acquire lock: [ 833.287090] ffff949d2b148c68 (&dev->lock){+.+.}-{4:4}, at: xdp_set_features_flag+0x29/0x90 [ 833.295470] [ 833.295470] but task is already holding lock: [ 833.301400] ffff949d2b148c68 (&dev->lock){+.+.}-{4:4}, at: gve_shutdown+0x44/0x90 [gve] [ 833.309508] [ 833.309508] other info that might help us debug this: [ 833.316130] Possible unsafe locking scenario: [ 833.316130] [ 833.322142] CPU0 [ 833.324681] ---- [ 833.327220] lock(&dev->lock); [ 833.330455] lock(&dev->lock); [ 833.333689] [ 833.333689] *** DEADLOCK *** [ 833.333689] [ 833.339701] May be due to missing lock nesting notation [ 833.339701] [ 833.346582] 5 locks held by systemd-shutdow/1: [ 833.351205] #0: ffffffffa9c89130 (system_transition_mutex){+.+.}-{4:4}, at: __se_sys_reboot+0xe6/0x210 [ 833.360695] #1: ffff93b399e5c1b8 (&dev->mutex){....}-{4:4}, at: device_shutdown+0xb4/0x1f0 [ 833.369144] #2: ffff949d19a471b8 (&dev->mutex){....}-{4:4}, at: device_shutdown+0xc2/0x1f0 [ 833.377603] #3: ffffffffa9eca050 (rtnl_mutex){+.+.}-{4:4}, at: gve_shutdown+0x33/0x90 [gve] [ 833.386138] #4: ffff949d2b148c68 (&dev->lock){+.+.}-{4:4}, at: gve_shutdown+0x44/0x90 [gve] Introduce xdp_features_(set|clear)_redirect_target_locked() versions which assume that the netdev lock has already been acquired before setting the XDP feature flag and update GVE to use the locked version. Fixes: 03df156 ("xdp: double protect netdev->xdp_flags with netdev->lock") Tested-by: Mina Almasry <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Reviewed-by: Harshitha Ramamurthy <[email protected]> Signed-off-by: Joshua Washington <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
nbd168
force-pushed
the
mt76
branch
4 times, most recently
from
a8afb17 to
e54b870
Compare
nbd168
pushed a commit
that referenced
this pull request
Jun 25, 2025
Subbaraya Sundeep says: ==================== CN20K silicon with mbox support CN20K is the next generation silicon in the Octeon series with various improvements and new features. Along with other changes the mailbox communication mechanism between RVU (Resource virtualization Unit) SRIOV PFs/VFs with Admin function (AF) has also gone through some changes. Some of those changes are - Separate IRQs for mbox request and response/ack. - Configurable mbox size, default being 64KB. - Ability for VFs to communicate with RVU AF instead of going through parent SRIOV PF. Due to more memory requirement due to configurable mbox size, mbox memory will now have to be allocated by - AF (PF0) for communicating with other PFs and all VFs in the system. - PF for communicating with it's child VFs. On previous silicons mbox memory was reserved and configured by firmware. This patch series add basic mbox support for AF (PF0) <=> PFs and PF <=> VFs. AF <=> VFs communication and variable mbox size support will come in later. Patch #1 Supported co-existance of bit encoding PFs and VFs in 16-bit hardware pcifunc format between CN20K silicon and older octeon series. Also exported PF,VF masks and shifts present in mailbox module to all other modules. Patch #2 Added basic mbox operation APIs and structures to support both CN20K and previous version of silicons. Patch #3 This patch adds support for basic mbox infrastructure implementation for CN20K silicon in AF perspective. There are few updates w.r.t MBOX ACK interrupt and offsets in CN20k. Patch #4 Added mbox implementation between NIC PF and AF for CN20K. Patch #5 Added mbox communication support between AF and AF's VFs. Patch #6 This patch adds support for MBOX communication between NIC PF and its VFs. ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
nbd168
force-pushed
the
mt76
branch
3 times, most recently
from
035ba65 to
336c7d6
Compare
nbd168
pushed a commit
that referenced
this pull request
Sep 4, 2025
These iterations require the read lock, otherwise RCU lockdep will splat: ============================= WARNING: suspicious RCU usage 6.17.0-rc3-00014-g31419c045d64 #6 Tainted: G O ----------------------------- drivers/base/power/main.c:1333 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 5 locks held by rtcwake/547: #0: 00000000643ab418 (sb_writers#6){.+.+}-{0:0}, at: file_start_write+0x2b/0x3a #1: 0000000067a0ca88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x181/0x24b #2: 00000000631eac40 (kn->active#3){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x191/0x24b #3: 00000000609a1308 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0xaf/0x30b #4: 0000000060c0fdb0 (device_links_srcu){.+.+}-{0:0}, at: device_links_read_lock+0x75/0x98 stack backtrace: CPU: 0 UID: 0 PID: 547 Comm: rtcwake Tainted: G O 6.17.0-rc3-00014-g31419c045d64 #6 VOLUNTARY Tainted: [O]=OOT_MODULE Stack: 223721b3a80 6089eac6 00000001 00000001 ffffff00 6089eac6 00000535 6086e528 721b3ac0 6003c294 00000000 60031fc0 Call Trace: [<600407ed>] show_stack+0x10e/0x127 [<6003c294>] dump_stack_lvl+0x77/0xc6 [<6003c2fd>] dump_stack+0x1a/0x20 [<600bc2f8>] lockdep_rcu_suspicious+0x116/0x13e [<603d8ea1>] dpm_async_suspend_superior+0x117/0x17e [<603d980f>] device_suspend+0x528/0x541 [<603da24b>] dpm_suspend+0x1a2/0x267 [<603da837>] dpm_suspend_start+0x5d/0x72 [<600ca0c9>] suspend_devices_and_enter+0xab/0x736 [...] Add the fourth argument to the iteration to annotate this and avoid the splat. Fixes: 0679963 ("PM: sleep: Make async suspend handle suppliers like parents") Fixes: ed18738 ("PM: sleep: Make async resume handle consumers like children") Signed-off-by: Johannes Berg <[email protected]> Link: https://patch.msgid.link/20250826134348.aba79f6e6299.I9ecf55da46ccf33778f2c018a82e1819d815b348@changeid Signed-off-by: Rafael J. Wysocki <[email protected]>
nbd168
force-pushed
the
mt76
branch
6 times, most recently
from
8620dfb to
901e082
Compare
nbd168
pushed a commit
that referenced
this pull request
Oct 13, 2025
Commit 0e2f80a("fs/dax: ensure all pages are idle prior to filesystem unmount") introduced the WARN_ON_ONCE to capture whether the filesystem has removed all DAX entries or not and applied the fix to xfs and ext4. Apply the missed fix on erofs to fix the runtime warning: [ 5.266254] ------------[ cut here ]------------ [ 5.266274] WARNING: CPU: 6 PID: 3109 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xff/0x260 [ 5.266294] Modules linked in: [ 5.266999] CPU: 6 UID: 0 PID: 3109 Comm: umount Tainted: G S 6.16.0+ #6 PREEMPT(voluntary) [ 5.267012] Tainted: [S]=CPU_OUT_OF_SPEC [ 5.267017] Hardware name: Dell Inc. OptiPlex 5000/05WXFV, BIOS 1.5.1 08/24/2022 [ 5.267024] RIP: 0010:truncate_folio_batch_exceptionals+0xff/0x260 [ 5.267076] Code: 00 00 41 39 df 7f 11 eb 78 83 c3 01 49 83 c4 08 41 39 df 74 6c 48 63 f3 48 83 fe 1f 0f 83 3c 01 00 00 43 f6 44 26 08 01 74 df <0f> 0b 4a 8b 34 22 4c 89 ef 48 89 55 90 e8 ff 54 1f 00 48 8b 55 90 [ 5.267083] RSP: 0018:ffffc900013f36c8 EFLAGS: 00010202 [ 5.267095] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 5.267101] RDX: ffffc900013f3790 RSI: 0000000000000000 RDI: ffff8882a1407898 [ 5.267108] RBP: ffffc900013f3740 R08: 0000000000000000 R09: 0000000000000000 [ 5.267113] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 5.267119] R13: ffff8882a1407ab8 R14: ffffc900013f3888 R15: 0000000000000001 [ 5.267125] FS: 00007aaa8b437800(0000) GS:ffff88850025b000(0000) knlGS:0000000000000000 [ 5.267132] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.267138] CR2: 00007aaa8b3aac10 CR3: 000000024f764000 CR4: 0000000000f52ef0 [ 5.267144] PKRU: 55555554 [ 5.267150] Call Trace: [ 5.267154] <TASK> [ 5.267181] truncate_inode_pages_range+0x118/0x5e0 [ 5.267193] ? save_trace+0x54/0x390 [ 5.267296] truncate_inode_pages_final+0x43/0x60 [ 5.267309] evict+0x2a4/0x2c0 [ 5.267339] dispose_list+0x39/0x80 [ 5.267352] evict_inodes+0x150/0x1b0 [ 5.267376] generic_shutdown_super+0x41/0x180 [ 5.267390] kill_block_super+0x1b/0x50 [ 5.267402] erofs_kill_sb+0x81/0x90 [erofs] [ 5.267436] deactivate_locked_super+0x32/0xb0 [ 5.267450] deactivate_super+0x46/0x60 [ 5.267460] cleanup_mnt+0xc3/0x170 [ 5.267475] __cleanup_mnt+0x12/0x20 [ 5.267485] task_work_run+0x5d/0xb0 [ 5.267499] exit_to_user_mode_loop+0x144/0x170 [ 5.267512] do_syscall_64+0x2b9/0x7c0 [ 5.267523] ? __lock_acquire+0x665/0x2ce0 [ 5.267535] ? __lock_acquire+0x665/0x2ce0 [ 5.267560] ? lock_acquire+0xcd/0x300 [ 5.267573] ? find_held_lock+0x31/0x90 [ 5.267582] ? mntput_no_expire+0x97/0x4e0 [ 5.267606] ? mntput_no_expire+0xa1/0x4e0 [ 5.267625] ? mntput+0x24/0x50 [ 5.267634] ? path_put+0x1e/0x30 [ 5.267647] ? do_faccessat+0x120/0x2f0 [ 5.267677] ? do_syscall_64+0x1a2/0x7c0 [ 5.267686] ? from_kgid_munged+0x17/0x30 [ 5.267703] ? from_kuid_munged+0x13/0x30 [ 5.267711] ? __do_sys_getuid+0x3d/0x50 [ 5.267724] ? do_syscall_64+0x1a2/0x7c0 [ 5.267732] ? irqentry_exit+0x77/0xb0 [ 5.267743] ? clear_bhb_loop+0x30/0x80 [ 5.267752] ? clear_bhb_loop+0x30/0x80 [ 5.267765] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 5.267772] RIP: 0033:0x7aaa8b32a9fb [ 5.267781] Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 e9 83 0d 00 f7 d8 [ 5.267787] RSP: 002b:00007ffd7c4c9468 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 5.267796] RAX: 0000000000000000 RBX: 00005a61592a8b00 RCX: 00007aaa8b32a9fb [ 5.267802] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005a61592b2080 [ 5.267806] RBP: 00007ffd7c4c9540 R08: 00007aaa8b403b20 R09: 0000000000000020 [ 5.267812] R10: 0000000000000001 R11: 0000000000000246 R12: 00005a61592a8c00 [ 5.267817] R13: 0000000000000000 R14: 00005a61592b2080 R15: 00005a61592a8f10 [ 5.267849] </TASK> [ 5.267854] irq event stamp: 4721 [ 5.267859] hardirqs last enabled at (4727): [<ffffffff814abf50>] __up_console_sem+0x90/0xa0 [ 5.267873] hardirqs last disabled at (4732): [<ffffffff814abf35>] __up_console_sem+0x75/0xa0 [ 5.267884] softirqs last enabled at (3044): [<ffffffff8132adb3>] kernel_fpu_end+0x53/0x70 [ 5.267895] softirqs last disabled at (3042): [<ffffffff8132b5f4>] kernel_fpu_begin_mask+0xc4/0x120 [ 5.267905] ---[ end trace 0000000000000000 ]--- Fixes: bde708f ("fs/dax: always remove DAX page-cache entries when breaking layouts") Signed-off-by: Yuezhang Mo <[email protected]> Reviewed-by: Friendy Su <[email protected]> Reviewed-by: Daniel Palmer <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Signed-off-by: Gao Xiang <[email protected]>
nbd168
pushed a commit
that referenced
this pull request
Oct 13, 2025
Petr Machata says: ==================== bridge: Allow keeping local FDB entries only on VLAN 0 The bridge FDB contains one local entry per port per VLAN, for the MAC of the port in question, and likewise for the bridge itself. This allows bridge to locally receive and punt "up" any packets whose destination MAC address matches that of one of the bridge interfaces or of the bridge itself. The number of these local "service" FDB entries grows linearly with number of bridge-global VLAN memberships, but that in turn will tend to grow quadratically with number of ports and per-port VLAN memberships. While that does not cause issues during forwarding lookups, it does make dumps impractically slow. As an example, with 100 interfaces, each on 4K VLANs, a full dump of FDB that just contains these 400K local entries, takes 6.5s. That's _without_ considering iproute2 formatting overhead, this is just how long it takes to walk the FDB (repeatedly), serialize it into netlink messages, and parse the messages back in userspace. This is to illustrate that with growing number of ports and VLANs, the time required to dump this repetitive information blows up. Arguably 4K VLANs per interface is not a very realistic configuration, but then modern switches can instead have several hundred interfaces, and we have fielded requests for >1K VLAN memberships per port among customers. FDB entries are currently all kept on a single linked list, and then dumping uses this linked list to walk all entries and dump them in order. When the message buffer is full, the iteration is cut short, and later restarted. Of course, to restart the iteration, it's first necessary to walk the already-dumped front part of the list before starting dumping again. So one possibility is to organize the FDB entries in different structure more amenable to walk restarts. One option is to walk directly the hash table. The advantage is that no auxiliary structure needs to be introduced. With a rough sketch of this approach, the above scenario gets dumped in not quite 3 s, saving over 50 % of time. However hash table iteration requires maintaining an active cursor that must be collected when the dump is aborted. It looks like that would require changes in the NDO protocol to allow to run this cleanup. Moreover, on hash table resize the iteration is simply restarted. FDB dumps are currently not guaranteed to correspond to any one particular state: entries can be missed, or be duplicated. But with hash table iteration we would get that plus the much less graceful resize behavior, where swaths of FDB are duplicated. Another option is to maintain the FDB entries in a red-black tree. We have a PoC of this approach on hand, and the above scenario is dumped in about 2.5 s. Still not as snappy as we'd like it, but better than the hash table. However the savings come at the expense of a more expensive insertion, and require locking during dumps, which blocks insertion. The upside of these approaches is that they provide benefits whatever the FDB contents. But it does not seem like either of these is workable. However we intend to clean up the RB tree PoC and present it for consideration later on in case the trade-offs are considered acceptable. Yet another option might be to use in-kernel FDB filtering, and to filter the local entries when dumping. Unfortunately, this does not help all that much either, because the linked-list walk still needs to happen. Also, with the obvious filtering interface built around ndm_flags / ndm_state filtering, one can't just exclude pure local entries in one query. One needs to dump all non-local entries first, and then to get permanent entries in another run filter local & added_by_user. I.e. one needs to pay the iteration overhead twice, and then integrate the result in userspace. To get significant savings, one would need a very specific knob like "dump, but skip/only include local entries". But if we are adding a local-specific knobs, maybe let's have an option to just not duplicate them in the first place. All this FDB duplication is there merely to make things snappy during forwarding. But high-radix switches with thousands of VLANs typically do not process much traffic in the SW datapath at all, but rather offload vast majority of it. So we could exchange some of the runtime performance for a neater FDB. To that end, in this patchset, introduce a new bridge option, BR_BOOLOPT_FDB_LOCAL_VLAN_0, which when enabled, has local FDB entries installed only on VLAN 0, instead of duplicating them across all VLANs. Then to maintain the local termination behavior, on FDB miss, the bridge does a second lookup on VLAN 0. Enabling this option changes the bridge behavior in expected ways. Since the entries are only kept on VLAN 0, FDB get, flush and dump will not perceive them on non-0 VLANs. And deleting the VLAN 0 entry affects forwarding on all VLANs. This patchset is loosely based on a privately circulated patch by Nikolay Aleksandrov. The patchset progresses as follows: - Patch #1 introduces a bridge option to enable the above feature. Then patches #2 to #5 gradually patch the bridge to do the right thing when the option is enabled. Finally patch #6 adds the UAPI knob and the code for when the feature is enabled or disabled. - Patches #7, #8 and #9 contain fixes and improvements to selftest libraries - Patch #10 contains a new selftest ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
nbd168
force-pushed
the
mt76
branch
2 times, most recently
from
9b651ae to
0960042
Compare
nbd168
force-pushed
the
mt76
branch
2 times, most recently
from
e0d810f to
53d1548
Compare
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.
Bumps idna from 3.4 to 3.7.
Release notes
Sourced from idna's releases.
Changelog
Sourced from idna's changelog.
Commits
1d365e1Release v3.7c1b3154Merge pull request #172 from kjd/optimize-contextj0394ec7Merge branch 'master' into optimize-contextjcd58a23Merge pull request #152 from elliotwutingfeng/dev5beb28bMore efficient resolution of joiner contexts1b12148Update ossf/scorecard-action to v2.3.1d516b87Update Github actions/checkout to v4c095c75Merge branch 'master' into dev60a0a4cFix typo in GitHub Actions workflow key5918a0eMerge branch 'master' into devDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.