aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-28net: fill in MODULE_DESCRIPTION()s in kuba@'s modulesJakub Kicinski2-0/+2
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Fill it in for the modules I maintain. Acked-by: Kalle Valo <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-10-28platform/chrome: cros_ec_lpc: Separate host command and irq disableLalith Rajendran3-26/+116
Both cros host command and irq disable were moved to suspend prepare stage from late suspend recently. This is causing EC to report MKBP event timeouts during suspend stress testing. When the MKBP event timeouts happen during suspend, subsequent wakeup of AP by EC using MKBP doesn't happen properly. Move the irq disabling part back to late suspend stage which is a general suggestion from the suspend kernel documentaiton to do irq disable as late as possible. Fixes: 4b9abbc132b8 ("platform/chrome: cros_ec_lpc: Move host command to prepare/complete") Signed-off-by: Lalith Rajendran <[email protected]> Link: https://lore.kernel.org/r/20231027160221.v4.1.I1725c3ed27eb7cd9836904e49e8bfa9fb0200a97@changeid Signed-off-by: Tzung-Bi Shih <[email protected]>
2023-10-27Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds3-14/+36
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Three fixes, one for the clk framework and two for clk drivers: - Avoid an oops in possible_parent_show() by checking for no parent properly when a DT index based lookup is used - Handle errors returned from divider_ro_round_rate() in clk_stm32_composite_determine_rate() - Fix clk_ops::determine_rate() implementation of socfpga's gateclk_ops that was ruining uart output because the divider was forgotten about" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: stm32: Fix a signedness issue in clk_stm32_composite_determine_rate() clk: Sanitize possible_parent_show to Handle Return Value of of_clk_get_parent_name clk: socfpga: gate: Account for the divider in determine_rate
2023-10-27Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds3-3/+3
Pull misc filesystem fixes from Al Viro: "Assorted fixes all over the place: literally nothing in common, could have been three separate pull requests. All are simple regression fixes, but not for anything from this cycle" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lock io_uring: kiocb_done() should *not* trust ->ki_pos if ->{read,write}_iter() failed sparc32: fix a braino in fault handling in csum_and_copy_..._user()
2023-10-27clk: Fix clk gate kunit test on big-endian CPUsStephen Boyd1-15/+15
The clk gate kunit test checks that the implementation of the basic clk gate reads and writes the proper bits in an MMIO register. The implementation of the basic clk gate type uses writel() and readl() which operate on little-endian registers. This test fails on big-endian CPUs because the clk gate implementation writes to 'fake_reg' with writel(), which converts the value to be written to little-endian before storing the value in the fake register. When the test checks the bits in the fake register on a big-endian machine it falsely assumes the format of the register is also big-endian, when it is really always little-endian. Suffice to say things don't work very well. Mark 'fake_reg' as __le32 and push through endian accessor fixes wherever the value is inspected to make this test endian agnostic. There's a CLK_GATE_BIG_ENDIAN flag for big-endian MMIO devices, which this test isn't using. A follow-up patch will test with and without that flag. Reported-by: Boqun Feng <[email protected]> Closes: https://lore.kernel.org/r/ZTLH5o0GlFBYsAHq@boqun-archlinux Tested-by: Boqun Feng <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-28tracing/kprobes: Fix symbol counting logic by looking at modules as wellAndrii Nakryiko1-4/+20
Recent changes to count number of matching symbols when creating a kprobe event failed to take into account kernel modules. As such, it breaks kprobes on kernel module symbols, by assuming there is no match. Fix this my calling module_kallsyms_on_each_symbol() in addition to kallsyms_on_each_match_symbol() to perform a proper counting. Link: https://lore.kernel.org/all/[email protected]/ Cc: Francis Laniel <[email protected]> Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Steven Rostedt <[email protected]> Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols") Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Song Liu <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
2023-10-27ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lockAl Viro1-1/+1
Use of dget() after we'd dropped ->d_lock is too late - dentry might be gone by that point. Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Al Viro <[email protected]>
2023-10-27io_uring: kiocb_done() should *not* trust ->ki_pos if ->{read,write}_iter() ↵Al Viro1-1/+1
failed ->ki_pos value is unreliable in such cases. For an obvious example, consider O_DSYNC write - we feed the data to page cache and start IO, then we make sure it's completed. Update of ->ki_pos is dealt with by the first part; failure in the second ends up with negative value returned _and_ ->ki_pos left advanced as if sync had been successful. In the same situation write(2) does not advance the file position at all. Reviewed-by: Christian Brauner <[email protected]> Reviewed-by: Jens Axboe <[email protected]> Signed-off-by: Al Viro <[email protected]>
2023-10-27Merge tag 'io_uring-6.6-2023-10-27' of git://git.kernel.dk/linuxLinus Torvalds2-15/+12
Pull io_uring fixes from Jens Axboe: "Fix for an issue reported where reading fdinfo could find a NULL thread as we didn't properly synchronize, and then a disable for the IOCB_DIO_CALLER_COMP optimization as a recent reported highlighted how that could lead to deadlocks if the task issued async O_DIRECT writes and then proceeded to do sync fallocate() calls" * tag 'io_uring-6.6-2023-10-27' of git://git.kernel.dk/linux: io_uring/rw: disable IOCB_DIO_CALLER_COMP io_uring/fdinfo: lock SQ thread while retrieving thread cpu/pid
2023-10-27sparc32: fix a braino in fault handling in csum_and_copy_..._user()Al Viro1-1/+1
Fault handler used to make non-trivial calls, so it needed to set a stack frame up. Used to be save ... - grab a stack frame, old %o... become %i... .... ret - go back to address originally in %o7, currently %i7 restore - switch to previous stack frame, in delay slot Non-trivial calls had been gone since ab5e8b331244 and that code should have become retl - go back to address in %o7 clr %o0 - have return value set to 0 What it had become instead was ret - go back to address in %i7 - return address of *caller* clr %o0 - have return value set to 0 which is not good, to put it mildly - we forcibly return 0 from csum_and_copy_{from,to}_iter() (which is what the call of that thing had been inlined into) and do that without dropping the stack frame of said csum_and_copy_..._iter(). Confuses the hell out of the caller of csum_and_copy_..._iter(), obviously... Reviewed-by: Sam Ravnborg <[email protected]> Fixes: ab5e8b331244 "sparc32: propagate the calling conventions change down to __csum_partial_copy_sparc_generic()" Signed-off-by: Al Viro <[email protected]>
2023-10-27Merge tag 'block-6.6-2023-10-27' of git://git.kernel.dk/linuxLinus Torvalds1-0/+6
Pull block fix from Jens Axboe: "Just a single fix for a potential divide-by-zero, introduced in this cycle" * tag 'block-6.6-2023-10-27' of git://git.kernel.dk/linux: blk-throttle: check for overflow in calculate_bytes_allowed
2023-10-27Merge tag 'ata-6.6-final' of ↵Linus Torvalds4-7/+58
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata Pull ATA fix from Damien Le Moal: "A single patch to fix a regression introduced by the recent suspend/resume fixes. The regression is that ATA disks are not stopped on system shutdown, which is not recommended and increases the disks SMART counters for unclean power off events. This patch fixes this by refining the recent rework of the scsi device manage_xxx flags" * tag 'ata-6.6-final' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: scsi: sd: Introduce manage_shutdown device flag
2023-10-27Merge tag 'platform-drivers-x86-v6.6-6' of ↵Linus Torvalds1-0/+73
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fix from Hans de Goede: "A single patch to extend the AMD PMC driver DMI quirk list for laptops which need special handling to avoid NVME s2idle suspend/resume errors" * tag 'platform-drivers-x86-v6.6-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: Add s2idle quirk for more Lenovo laptops
2023-10-27net: pcs: xpcs: Add 2500BASE-X case in get state for XPCS driversRaju Lakkaraju2-0/+31
Add DW_2500BASEX case in xpcs_get_state( ) to update speed, duplex and pause Signed-off-by: Raju Lakkaraju <[email protected]> Reviewed-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: bpf: Use sockopt_lock_sock() in ip_sock_set_tos()Yonghong Song1-2/+2
With latest sync from net-next tree, bpf-next has a bpf selftest failure: [root@arch-fb-vm1 bpf]# ./test_progs -t setget_sockopt ... [ 76.194349] ============================================ [ 76.194682] WARNING: possible recursive locking detected [ 76.195039] 6.6.0-rc7-g37884503df08-dirty #67 Tainted: G W OE [ 76.195518] -------------------------------------------- [ 76.195852] new_name/154 is trying to acquire lock: [ 76.196159] ffff8c3e06ad8d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: ip_sock_set_tos+0x19/0x30 [ 76.196669] [ 76.196669] but task is already holding lock: [ 76.197028] ffff8c3e06ad8d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_listen+0x21/0x70 [ 76.197517] [ 76.197517] other info that might help us debug this: [ 76.197919] Possible unsafe locking scenario: [ 76.197919] [ 76.198287] CPU0 [ 76.198444] ---- [ 76.198600] lock(sk_lock-AF_INET); [ 76.198831] lock(sk_lock-AF_INET); [ 76.199062] [ 76.199062] *** DEADLOCK *** [ 76.199062] [ 76.199420] May be due to missing lock nesting notation [ 76.199420] [ 76.199879] 2 locks held by new_name/154: [ 76.200131] #0: ffff8c3e06ad8d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_listen+0x21/0x70 [ 76.200644] #1: ffffffff90f96a40 (rcu_read_lock){....}-{1:2}, at: __cgroup_bpf_run_filter_sock_ops+0x55/0x290 [ 76.201268] [ 76.201268] stack backtrace: [ 76.201538] CPU: 4 PID: 154 Comm: new_name Tainted: G W OE 6.6.0-rc7-g37884503df08-dirty #67 [ 76.202134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 76.202699] Call Trace: [ 76.202858] <TASK> [ 76.203002] dump_stack_lvl+0x4b/0x80 [ 76.203239] __lock_acquire+0x740/0x1ec0 [ 76.203503] lock_acquire+0xc1/0x2a0 [ 76.203766] ? ip_sock_set_tos+0x19/0x30 [ 76.204050] ? sk_stream_write_space+0x12a/0x230 [ 76.204389] ? lock_release+0xbe/0x260 [ 76.204661] lock_sock_nested+0x32/0x80 [ 76.204942] ? ip_sock_set_tos+0x19/0x30 [ 76.205208] ip_sock_set_tos+0x19/0x30 [ 76.205452] do_ip_setsockopt+0x4b3/0x1580 [ 76.205719] __bpf_setsockopt+0x62/0xa0 [ 76.205963] bpf_sock_ops_setsockopt+0x11/0x20 [ 76.206247] bpf_prog_630217292049c96e_bpf_test_sockopt_int+0xbc/0x123 [ 76.206660] bpf_prog_493685a3bae00bbd_bpf_test_ip_sockopt+0x49/0x4b [ 76.207055] bpf_prog_b0bcd27f269aeea0_skops_sockopt+0x44c/0xec7 [ 76.207437] __cgroup_bpf_run_filter_sock_ops+0xda/0x290 [ 76.207829] __inet_listen_sk+0x108/0x1b0 [ 76.208122] inet_listen+0x48/0x70 [ 76.208373] __sys_listen+0x74/0xb0 [ 76.208630] __x64_sys_listen+0x16/0x20 [ 76.208911] do_syscall_64+0x3f/0x90 [ 76.209174] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 ... Both ip_sock_set_tos() and inet_listen() calls lock_sock(sk) which caused a dead lock. To fix the issue, use sockopt_lock_sock() in ip_sock_set_tos() instead. sockopt_lock_sock() will avoid lock_sock() if it is in bpf context. Fixes: 878d951c6712 ("inet: lock the socket in ip_sock_set_tos()") Suggested-by: Martin KaFai Lau <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: mana: Use xdp_set_features_flag instead of direct assignmentKonstantin Taranov1-2/+3
This patch uses a helper function for assignment of xdp_features. This change simplifies backports. Signed-off-by: Konstantin Taranov <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27vxlan: Cleanup IFLA_VXLAN_PORT_RANGE entry in vxlan_get_size()Benjamin Poirier1-2/+2
This patch is basically a followup to commit 4e4b1798cc90 ("vxlan: Add missing entries to vxlan_get_size()"). All of the attributes in vxlan_get_size() appear in the same order that they are filled in vxlan_fill_info() except for IFLA_VXLAN_PORT_RANGE. For consistency, move that entry to match its order and add a comment, like for all other entries. Signed-off-by: Benjamin Poirier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27Merge branch 'intel-wired-lan-driver-updates-for-2023-10-23-iavf'Jakub Kicinski6-900/+28
Jacob Keller says: ==================== Intel Wired LAN Driver Updates for 2023-10-23 (iavf) This series includes iAVF driver cleanups from Michal Schmidt. Michal removes and updates stale comments, fixes some locking anti-patterns, improves handling of resets when the PF is slow, avoids unnecessary duplication of netdev state, refactors away some duplicate code, and finally removes the never-actually-used client interface. Changes since v1: * Dropped patch ("iavf: in iavf_down, disable queues when removing the driver") which was applied directly to net. * Fixed a merge conflict due to 7db311104388 ("iavf: initialize waitqueues before starting watchdog_task"). V1 was originally posted at: https://lore.kernel.org/netdev/[email protected]/T/#mfadbdb39313eeccc616fdee80a4fdd6bda7e2822 ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: delete the iavf client interfaceMichal Schmidt6-871/+1
The iavf client interface was added in 2017 by commit ed0e894de7c1 ("i40evf: add client interface"), but there have never been any in-tree callers. It's not useful for future development either. The Intel out-of-tree iavf and irdma drivers instead use an auxiliary bus, which is a better solution. Remove the iavf client interface code. Also gone are the client_task work and the client_lock mutex. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: add a common function for undoing the interrupt schemeMichal Schmidt1-11/+15
Add a new function iavf_free_interrupt_scheme that does the inverse of iavf_init_interrupt_scheme. Symmetry is nice. And there will be three callers already. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: use unregister_netdevMichal Schmidt1-3/+1
Use unregister_netdev, which takes rtnl_lock for us. We don't have to check the reg_state under rtnl_lock. There's nothing to race with. We have just cancelled the finish_config work. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: rely on netdev's own registered stateMichal Schmidt2-7/+3
The information whether a netdev has been registered is already present in the netdev itself. There's no need for a driver flag with the same meaning. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: fix the waiting time for initial resetMichal Schmidt1-1/+1
Every time I create VFs on ice, I receive at least one "Device is still in reset (-16), retrying" message per VF. It recovers fine, but typical usecases should not trigger scary-looking messages. The waiting for reset is too short. It makes no sense to check every 10 microseconds. Typical reset waiting times are at least tens of milliseconds and can be several seconds. I suspect the polling interval was meant to be 10 milliseconds all along. IAVF_RESET_WAIT_COMPLETE_COUNT is defined as 2000, so the total waiting time could be over 20 seconds. I have seen resets take 5 seconds (with 128 VFs on ice). The added benefit of not triggering the "Device is still in reset" path is that we avoid going through the __IAVF_INIT_FAILED state, which would take a full second before retrying. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: in iavf_down, don't queue watchdog_task if comms failedMichal Schmidt1-2/+4
The reason for queueing watchdog_task is to have it process the aq_required flags that are being set here. If comms failed, there's nothing to do, so return early. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: simplify mutex_trylock+sleep loopsMichal Schmidt1-4/+2
This pattern appears in two places in the iavf source code: while (!mutex_trylock(...)) usleep_range(...); That's just mutex_lock with extra steps. The pattern is a leftover from when iavf used bit flags instead of mutexes for locking. Commit 5ac49f3c2702 ("iavf: use mutexes for locking of critical sections") replaced test_and_set_bit with !mutex_trylock, preserving the pattern. Simplify it to mutex_lock. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27iavf: fix comments about old bit locksMichal Schmidt1-2/+2
Bit lock __IAVF_IN_CRITICAL_TASK does not exist anymore since commit 5ac49f3c2702 ("iavf: use mutexes for locking of critical sections"). Adjust the comments accordingly. Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27doc/netlink: Update schema to support cmd-cnt-name and cmd-max-nameDavide Caratti6-8/+24
allow specifying cmd-cnt-name and cmd-max-name in netlink specs, in accordance with Documentation/userspace-api/netlink/c-code-gen.rst. Use cmd-cnt-name and attr-cnt-name in the mptcp yaml spec and in the corresponding uAPI headers, to preserve the #defines we had in the past and avoid adding new ones. v2: - squash modification in mptcp.yaml and MPTCP uAPI headers Suggested-by: Jakub Kicinski <[email protected]> Signed-off-by: Davide Caratti <[email protected]> Link: https://lore.kernel.org/r/12d4ed0116d8883cf4b533b856f3125a34e56749.1698415310.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27tools: ynl: introduce option to process unknown attributes or typesJiri Pirko2-12/+39
In case the kernel sends message back containing attribute not defined in family spec, following exception is raised to the user: $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/devlink.yaml --do trap-get --json '{"bus-name": "netdevsim", "dev-name": "netdevsim1", "trap-name": "source_mac_is_multicast"}' Traceback (most recent call last): File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 521, in _decode attr_spec = attr_space.attrs_by_val[attr.type] ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ KeyError: 132 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jiri/work/linux/./tools/net/ynl/cli.py", line 61, in <module> main() File "/home/jiri/work/linux/./tools/net/ynl/cli.py", line 49, in main reply = ynl.do(args.do, attrs, args.flags) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 731, in do return self._op(method, vals, flags) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 719, in _op rsp_msg = self._decode(decoded.raw_attrs, op.attr_set.name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 525, in _decode raise Exception(f"Space '{space}' has no attribute with value '{attr.type}'") Exception: Space 'devlink' has no attribute with value '132' Introduce a command line option "process-unknown" and pass it down to YnlFamily class constructor to allow user to process unknown attributes and types and print them as binaries. $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/devlink.yaml --do trap-get --json '{"bus-name": "netdevsim", "dev-name": "netdevsim1", "trap-name": "source_mac_is_multicast"}' --process-unknown {'UnknownAttr(129)': {'UnknownAttr(0)': b'\x00\x00\x00\x00\x00\x00\x00\x00', 'UnknownAttr(1)': b'\x00\x00\x00\x00\x00\x00\x00\x00', 'UnknownAttr(2)': b'\x0e\x00\x00\x00\x00\x00\x00\x00'}, 'UnknownAttr(132)': b'\x00', 'UnknownAttr(133)': b'', 'UnknownAttr(134)': {'UnknownAttr(0)': b''}, 'bus-name': 'netdevsim', 'dev-name': 'netdevsim1', 'trap-action': 'drop', 'trap-group-name': 'l2_drops', 'trap-name': 'source_mac_is_multicast'} Signed-off-by: Jiri Pirko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27ipvlan: properly track tx_errorsEric Dumazet2-4/+5
Both ipvlan_process_v4_outbound() and ipvlan_process_v6_outbound() increment dev->stats.tx_errors in case of errors. Unfortunately there are two issues : 1) ipvlan_get_stats64() does not propagate dev->stats.tx_errors to user. 2) Increments are not atomic. KCSAN would complain eventually. Use DEV_STATS_INC() to not miss an update, and change ipvlan_get_stats64() to copy the value back to user. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Eric Dumazet <[email protected]> Cc: Mahesh Bandewar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27netdevsim: Block until all devices are releasedIdo Schimmel1-0/+12
Like other buses, devices on the netdevsim bus have a release callback that is invoked when the reference count of the device drops to zero. However, unlike other buses such as PCI, the release callback is not necessarily built into the kernel, as netdevsim can be built as a module. The above is problematic as nothing prevents the module from being unloaded before the release callback has been invoked, which can happen asynchronously. One such example can be found in commit a380687200e0 ("devlink: take device reference for devlink object") where devlink calls put_device() from an RCU callback. The issue is not theoretical and the reproducer in [1] can reliably crash the kernel. The conclusion of this discussion was that the issue should be solved in netdevsim, which is what this patch is trying to do. Add a reference count that is increased when a device is added to the bus and decreased when a device is released. Signal a completion when the reference count drops to zero and wait for the completion when unloading the module so that the module will not be unloaded before all the devices were released. The reference count is initialized to one so that completion is only signaled when unloading the module. With this patch, the reproducer in [1] no longer crashes the kernel. [1] https://lore.kernel.org/netdev/[email protected]/ Fixes: a380687200e0 ("devlink: take device reference for devlink object") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27nfp: using napi_build_skb() to replace build_skb()Fei Qin2-2/+2
The napi_build_skb() can reuse the skb in skb cache per CPU or can allocate skbs in bulk, which helps improve the performance. Signed-off-by: Fei Qin <[email protected]> Signed-off-by: Louis Peens <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: ksz9477: Fix spelling mistake "Enery" -> "Energy"Colin Ian King1-1/+1
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27Merge branch 'net-dsa-microchip-provide-wake-on-lan-support-part-2'Jakub Kicinski6-24/+200
Oleksij Rempel says: ==================== net: dsa: microchip: provide Wake on LAN support (part 2) This patch series introduces extensive Wake on LAN (WoL) support for the Microchip KSZ9477 family of switches, coupled with some code refactoring and error handling enhancements. The principal aim is to enable and manage Wake on Magic Packet and other PHY event triggers for waking up the system, whilst ensuring that the switch isn't reset during a shutdown if WoL is active. The Wake on LAN functionality is optional and is particularly beneficial if the PME pins are connected to the SoC as a wake source or to a PMIC that can enable or wake the SoC. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: Ensure Stable PME Pin State for Wake-on-LANOleksij Rempel4-1/+55
Ensures a stable PME (Power Management Event) pin state by disabling PME on system start and enabling it on shutdown only if WoL (Wake-on-LAN) is configured. This is needed to avoid issues with some PMICs (Power Management ICs). Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: Refactor switch shutdown routine for WoL preparationOleksij Rempel4-8/+22
Centralize the switch shutdown routine in a dedicated function, ksz_switch_shutdown(), to enhance code maintainability and reduce redundancy. This change abstracts the common shutdown operations previously duplicated in ksz9477_i2c_shutdown() and ksz_spi_shutdown(). This refactoring is a preparatory step for an upcoming patch to avoid reset on shutdown if Wake-on-LAN (WoL) is enabled. Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: Add error handling for ksz_switch_macaddr_get()Oleksij Rempel1-3/+13
Enhance the ksz_switch_macaddr_get() function to handle errors that may occur during the call to ksz_write8(). Specifically, this update checks the return value of ksz_write8(), which may fail if regmap ranges validation is not passed and returns the error code. Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: Refactor comment for ksz_switch_macaddr_get() functionOleksij Rempel1-6/+14
Update the comment to follow kernel-doc format. Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27net: dsa: microchip: ksz9477: Add Wake on Magic Packet supportOleksij Rempel3-7/+97
Introduce Wake on Magic Packet (WoL) functionality to the ksz9477 driver. Major changes include: 1. Extending the `ksz9477_handle_wake_reason` function to identify Magic Packet wake events alongside existing wake reasons. 2. Updating the `ksz9477_get_wol` and `ksz9477_set_wol` functions to handle WAKE_MAGIC alongside the existing WAKE_PHY option, and to program the switch's MAC address register accordingly when Magic Packet wake-up is enabled. This change will prevent WAKE_MAGIC activation if the related port has a different MAC address compared to a MAC address already used by HSR or an already active WAKE_MAGIC on another port. 3. Adding a restriction in `ksz_port_set_mac_address` to prevent MAC address changes on ports with active Wake on Magic Packet, as the switch's MAC address register is utilized for this feature. Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-27of: overlay: unittest: overlay_bad_unresolved: Spelling s/ok/okay/Geert Uytterhoeven1-1/+1
While "ok" is recognized, the proper status value for an operational device is "okay". Fixes: eb38b9529aefa344 ("of: overlay: unittest: Add test for unresolved symbol") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/923f4f605b86f23d001c6efc9c2237ab449d447d.1698228277.git.geert+renesas@glider.be Signed-off-by: Rob Herring <[email protected]>
2023-10-27of: address: Consolidate bus .map() functionsRob Herring1-43/+11
The bus .map() functions vary only by checking the flag cells values and skipping over any flag cells to read the addresses. Otherwise they all do the same reading 'ranges' address and size and returning the address's offset if it is within the 'ranges' entry. Refactor all the .map() functions to pass in the flag cell size so that each bus can check the bus specific flags and then call a common function to do everything else. Acked-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2023-10-27of: address: Store number of bus flag cells rather than boolRob Herring1-9/+5
It is more useful to know how many flags cells a bus has rather than whether a bus has flags or not as ultimately the number of cells is the information used. Replace 'has_flags' boolean with 'flag_cells' count. Acked-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2023-10-27of: unittest: Add tests for address translationsHerve Codina2-0/+178
Add tests to exercise address translations based on ranges properties. Tests added cover "default" (2cell) address translations, "default flags" (3cell) address translations and PCI address translations. They also cover PCI BAR translations introduced in commit 407d1a51921e ("PCI: Create device tree node for bridge"). Signed-off-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2023-10-27ASoC: Merge up workaround for CODECs that play noise on stopped streamMark Brown7-11/+34
This was sent too late to actually make it for v6.6 but was sent against v6.6 so merge it up here.
2023-10-27hte: Use kasprintf() instead of fixed buffer formattingAndy Shevchenko1-9/+4
Improve readability and maintainability by replacing a hardcoded string allocation and formatting by the use of the kasprintf() helper. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Dipen Patel <[email protected]> Signed-off-by: Dipen Patel <[email protected]>
2023-10-27hte: tegra: Fix missing error code in tegra_hte_test_probe()Harshit Mogalapalli1-1/+3
The value of 'ret' is zero when of_hte_req_count() fails to get number of entitties to timestamp. And returning success(zero) on this failure path is incorrect. Fixes: 9a75a7cd03c9 ("hte: Add Tegra HTE test driver") Signed-off-by: Harshit Mogalapalli <[email protected]> Reviewed-by: Dipen Patel <[email protected]> Signed-off-by: Dipen Patel <[email protected]>
2023-10-27KVM: x86: Service NMI requests after PMI requests in VM-Enter pathMingwei Zhang1-4/+4
Service NMI and SMI requests after PMI requests in vcpu_enter_guest() so that KVM does not need to cancel and redo the VM-Enter if the guest configures its PMIs to be delivered as NMIs (likely) or SMIs (unlikely). Because APIC emulation "injects" NMIs via KVM_REQ_NMI, handling PMI requests after NMI requests (the likely case) means KVM won't detect the pending NMI request until the final check for outstanding requests. Detecting requests at the final stage is costly as KVM has already loaded guest state, potentially queued events for injection, disabled IRQs, dropped SRCU, etc., most of which needs to be unwound. Note that changing the order of request processing doesn't change the end result, as KVM's final check for outstanding requests prevents entering the guest until all requests are serviced. I.e. KVM will ultimately coalesce events (or not) regardless of the ordering. Using SPEC2017 benchmark programs running along with Intel vtune in a VM demonstrates that the following code change reduces 800~1500 canceled VM-Enters per second. Some glory details: Probe the invocation to vmx_cancel_injection(): $ perf probe -a vmx_cancel_injection $ perf stat -a -e probe:vmx_cancel_injection -I 10000 # per 10 seconds Partial results when SPEC2017 with Intel vtune are running in the VM: On kernel without the change: 10.010018010 14254 probe:vmx_cancel_injection 20.037646388 15207 probe:vmx_cancel_injection 30.078739816 15261 probe:vmx_cancel_injection 40.114033258 15085 probe:vmx_cancel_injection 50.149297460 15112 probe:vmx_cancel_injection 60.185103088 15104 probe:vmx_cancel_injection On kernel with the change: 10.003595390 40 probe:vmx_cancel_injection 20.017855682 31 probe:vmx_cancel_injection 30.028355883 34 probe:vmx_cancel_injection 40.038686298 31 probe:vmx_cancel_injection 50.048795162 20 probe:vmx_cancel_injection 60.069057747 19 probe:vmx_cancel_injection Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Mingwei Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] [sean: hoist PMU/PMI above SMI too, massage changelog] Signed-off-by: Sean Christopherson <[email protected]>
2023-10-27ASoC: Intel: avs: Add support for rt5514 codecMark Brown4-0/+208
Merge series from Amadeusz Sławiński <[email protected]>: There are machines which use codec rt5514 as DMIC, add support for them.
2023-10-27Merge tag 'qcom-clk-for-6.7' of ↵Stephen Boyd33-317/+7235
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into clk-qcom Pull Qualcomm clk driver updates from Bjorn Andersson: - Initial support for the SM4450 Global Clock Controller and RPMh clock controllers - Drop CLK_SET_RATE_PARENT for clocks with fixed-rate GPLLs across a variety of IPQ platforms - Add missing parent of APCS PLL on IPQ6018 - Add I2C QUP6 clk on IPQ6018 but mark it critical to avoid problems with RPM - Implement safe source switching for a53pll and use on IPQ5332 - Add support for Stromer Plus PLLs - Switch SM8550 Video and GPU clock controllers to use OLE PLL configure method - Non critical fixes to halt bit checks - Add SMMU GDSC for MSM8998 - Fix possible integer overflow in RCG frequency calculation code - Remove RPM managed clks from MSM8996 GCC driver - Add Camera Clock Controller on SM8550 - Add HFPLL configuration for the three HFPLLs in MSM8976 - Switch MSM8996 CBF clock driver's remove function to return void * tag 'qcom-clk-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (36 commits) clk: qcom: apss-ipq6018: add the GPLL0 clock also as clock provider clk: qcom: ipq5332: drop the CLK_SET_RATE_PARENT flag from GPLL clocks clk: qcom: ipq9574: drop the CLK_SET_RATE_PARENT flag from GPLL clocks clk: qcom: ipq5018: drop the CLK_SET_RATE_PARENT flag from GPLL clocks clk: qcom: ipq6018: drop the CLK_SET_RATE_PARENT flag from PLL clocks clk: qcom: ipq8074: drop the CLK_SET_RATE_PARENT flag from PLL clocks clk: qcom: gcc-ipq6018: add QUP6 I2C clock clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll clk: qcom: clk-alpha-pll: introduce stromer plus ops clk: qcom: config IPQ_APSS_6018 should depend on QCOM_SMEM clk: qcom: videocc-sm8550: switch to clk_lucid_ole_pll_configure clk: qcom: gpucc-sm8550: switch to clk_lucid_ole_pll_configure clk: qcom: Replace of_device.h with explicit includes clk: qcom: smd-rpm: Move CPUSS_GNoC clock to interconnect clk: qcom: cbf-msm8996: Convert to platform remove callback returning void clk: qcom: gcc-sm8150: Fix gcc_sdcc2_apps_clk_src clk: qcom: Add GCC driver support for SM4450 dt-bindings: clock: qcom: Add GCC clocks for SM4450 ...
2023-10-27clk: si521xx: Increase stack based print buffer size in probeMarek Vasut1-2/+2
Increase the size of temporary print buffer on stack to fix the following warnings reported by LKP. Since all the input parameters of snprintf() are under control of this driver, it is not possible to trigger and overflow here, but since the print buffer is on stack and discarded once driver probe() finishes, it is not an issue to increase it by 10 bytes and fix the warning in the process. Make it so. " drivers/clk/clk-si521xx.c: In function 'si521xx_probe': >> drivers/clk/clk-si521xx.c:318:26: warning: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=] snprintf(name, 6, "DIFF%d", i); ^~ drivers/clk/clk-si521xx.c:318:21: note: directive argument in the range [0, 2147483647] snprintf(name, 6, "DIFF%d", i); ^~~~~~~~ drivers/clk/clk-si521xx.c:318:3: note: 'snprintf' output between 6 and 15 bytes into a destination of size 6 snprintf(name, 6, "DIFF%d", i); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " Fixes: edc12763a3a2 ("clk: si521xx: Clock driver for Skyworks Si521xx I2C PCIe clock generators") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Marek Vasut <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2023-10-27x86/tsc: Defer marking TSC unstable to a workerThomas Gleixner1-1/+9
Tetsuo reported the following lockdep splat when the TSC synchronization fails during CPU hotplug: tsc: Marking TSC unstable due to check_tsc_sync_source failed WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. ffffffff8cfa1c78 (watchdog_lock){?.-.}-{2:2}, at: clocksource_watchdog+0x23/0x5a0 {IN-HARDIRQ-W} state was registered at: _raw_spin_lock_irqsave+0x3f/0x60 clocksource_mark_unstable+0x1b/0x90 mark_tsc_unstable+0x41/0x50 check_tsc_sync_source+0x14f/0x180 sysvec_call_function_single+0x69/0x90 Possible unsafe locking scenario: lock(watchdog_lock); <Interrupt> lock(watchdog_lock); stack backtrace: _raw_spin_lock+0x30/0x40 clocksource_watchdog+0x23/0x5a0 run_timer_softirq+0x2a/0x50 sysvec_apic_timer_interrupt+0x6e/0x90 The reason is the recent conversion of the TSC synchronization function during CPU hotplug on the control CPU to a SMP function call. In case that the synchronization with the upcoming CPU fails, the TSC has to be marked unstable via clocksource_mark_unstable(). clocksource_mark_unstable() acquires 'watchdog_lock', but that lock is taken with interrupts enabled in the watchdog timer callback to minimize interrupt disabled time. That's obviously a possible deadlock scenario, Before that change the synchronization function was invoked in thread context so this could not happen. As it is not crucical whether the unstable marking happens slightly delayed, defer the call to a worker thread which avoids the lock context problem. Fixes: 9d349d47f0e3 ("x86/smpboot: Make TSC synchronization function call based") Reported-by: Tetsuo Handa <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Tetsuo Handa <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/87zg064ceg.ffs@tglx
Powered by cgit, Gruvboxed by Blaster4385.