summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-10-19openvswitch: Use kmalloc_size_roundup() to match ksize() usageKees Cook
Round up allocations with kmalloc_size_roundup() so that openvswitch's use of ksize() is always accurate and no special handling of the memory is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. Cc: Pravin B Shelar <pshelar@ovn.org> Cc: dev@openvswitch.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221018090628.never.537-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19cifs: update internal module numberSteve French
To 2.40 Signed-off-by: Steve French <stfrench@microsoft.com>
2022-10-19cifs: fix memory leaks in session setupPaulo Alcantara
We were only zeroing out the ntlmssp blob but forgot to free the allocated buffer in the end of SMB2_sess_auth_rawntlmssp_negotiate() and SMB2_sess_auth_rawntlmssp_authenticate() functions. This fixes below kmemleak reports: unreferenced object 0xffff88800ddcfc60 (size 96): comm "mount.cifs", pid 758, jiffies 4294696066 (age 42.967s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d0beeb29>] __kmalloc+0x39/0xa0 [<00000000e3834047>] build_ntlmssp_smb3_negotiate_blob+0x2c/0x110 [cifs] [<00000000e85f5ab2>] SMB2_sess_auth_rawntlmssp_negotiate+0xd3/0x230 [cifs] [<0000000080fdb897>] SMB2_sess_setup+0x16c/0x2a0 [cifs] [<000000009af320a8>] cifs_setup_session+0x13b/0x370 [cifs] [<00000000f15d5982>] cifs_get_smb_ses+0x643/0xb90 [cifs] [<00000000fe15eb90>] mount_get_conns+0x63/0x3e0 [cifs] [<00000000768aba03>] mount_get_dfs_conns+0x16/0xa0 [cifs] [<00000000cf1cf146>] cifs_mount+0x1c2/0x9a0 [cifs] [<000000000d66b51e>] cifs_smb3_do_mount+0x10e/0x710 [cifs] [<0000000077a996c5>] smb3_get_tree+0xf4/0x200 [cifs] [<0000000094dbd041>] vfs_get_tree+0x23/0xc0 [<000000003a8561de>] path_mount+0x2d3/0xb50 [<00000000ed5c86d6>] __x64_sys_mount+0x102/0x140 [<00000000142142f3>] do_syscall_64+0x3b/0x90 [<00000000e2b89731>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff88801437f000 (size 512): comm "mount.cifs", pid 758, jiffies 4294696067 (age 42.970s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d0beeb29>] __kmalloc+0x39/0xa0 [<00000000004f53d2>] build_ntlmssp_auth_blob+0x4f/0x340 [cifs] [<000000005f333084>] SMB2_sess_auth_rawntlmssp_authenticate+0xd4/0x250 [cifs] [<0000000080fdb897>] SMB2_sess_setup+0x16c/0x2a0 [cifs] [<000000009af320a8>] cifs_setup_session+0x13b/0x370 [cifs] [<00000000f15d5982>] cifs_get_smb_ses+0x643/0xb90 [cifs] [<00000000fe15eb90>] mount_get_conns+0x63/0x3e0 [cifs] [<00000000768aba03>] mount_get_dfs_conns+0x16/0xa0 [cifs] [<00000000cf1cf146>] cifs_mount+0x1c2/0x9a0 [cifs] [<000000000d66b51e>] cifs_smb3_do_mount+0x10e/0x710 [cifs] [<0000000077a996c5>] smb3_get_tree+0xf4/0x200 [cifs] [<0000000094dbd041>] vfs_get_tree+0x23/0xc0 [<000000003a8561de>] path_mount+0x2d3/0xb50 [<00000000ed5c86d6>] __x64_sys_mount+0x102/0x140 [<00000000142142f3>] do_syscall_64+0x3b/0x90 [<00000000e2b89731>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: a4e430c8c8ba ("cifs: replace kfree() with kfree_sensitive() for sensitive data") Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Steve French <stfrench@microsoft.com>
2022-10-19cifs: drop the lease for cached directories on rmdir or renameRonnie Sahlberg
When we delete or rename a directory we must also drop any cached lease we have on the directory. Fixes: a350d6e73f5e ("cifs: enable caching of directories for which a lease is held") Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2022-10-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Missing flowi uid field in nft_fib expression, from Guillaume Nault. This is broken since the creation of the fib expression. 2) Relax sanity check to fix bogus EINVAL error when deleting elements belonging set intervals. Broken since 6.0-rc. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: relax NFTA_SET_ELEM_KEY_END set flags requirements netfilter: rpfilter/fib: Set ->flowic_uid correctly for user namespaces. ==================== Link: https://lore.kernel.org/r/20221019065225.1006344-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19MAINTAINERS: Update Kishon's email address in PCI endpoint subsystemKishon Vijay Abraham I
Update Kishon's email address in PCI endpoint subsystem maintainer entry and mark him as reviewer. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-10-19genetlink: fix kdoc warningsJakub Kicinski
Address a bunch of kdoc warnings: include/net/genetlink.h:81: warning: Function parameter or member 'module' not described in 'genl_family' include/net/genetlink.h:243: warning: expecting prototype for struct genl_info. Prototype was for struct genl_dumpit_info instead include/net/genetlink.h:419: warning: Function parameter or member 'net' not described in 'genlmsg_unicast' include/net/genetlink.h:438: warning: expecting prototype for gennlmsg_data(). Prototype was for genlmsg_data() instead include/net/genetlink.h:244: warning: Function parameter or member 'op' not described in 'genl_dumpit_info' Link: https://lore.kernel.org/r/20221018231310.1040482-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19Merge branch 'netlink-formatted-extacks'Jakub Kicinski
Edward Cree says: ==================== netlink: formatted extacks Currently, netlink extacks can only carry fixed string messages, which is limiting when reporting failures in complex systems. This series adds the ability to return printf-formatted messages, and uses it in the sfc driver's TC offload code. Formatted extack messages are limited in length to a fixed buffer size, currently 80 characters. If the message exceeds this, the full message will be logged (ratelimited) to the console and a truncated version returned over netlink. There is no change to the netlink uAPI; only internal kernel changes are needed. ==================== Link: https://lore.kernel.org/r/cover.1666102698.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19sfc: remove 'log-tc-errors' ethtool private flagEdward Cree
It no longer does anything now that we're using formatted extacks instead. So we can remove the driver's whole get/set priv_flags implementation. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19sfc: use formatted extacks instead of efx_tc_err()Edward Cree
Since we can now get a formatted message back to the user with NL_SET_ERR_MSG_FMT_MOD(), there's no need for our special logging. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19netlink: add support for formatted extack messagesEdward Cree
Include an 80-byte buffer in struct netlink_ext_ack that can be used for scnprintf()ed messages. This does mean that the resulting string can't be enumerated, translated etc. in the way NL_SET_ERR_MSG() was designed to allow. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-19i2c: qcom-cci: Fix ordering of pm_runtime_xx and i2c_add_adapterBryan O'Donoghue
When we compile-in the CCI along with the imx412 driver and run on the RB5 we see that i2c_add_adapter() causes the probe of the imx412 driver to happen. This probe tries to perform an i2c xfer() and the xfer() in i2c-qcom-cci.c fails on pm_runtime_get() because the i2c-qcom-cci.c::probe() function has not completed to pm_runtime_enable(dev). Fix this sequence by ensuring pm_runtime_xxx() calls happen prior to adding the i2c adapter. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-19io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()Harshit Mogalapalli
Syzkaller produced the below call trace: BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0 Write of size 8 at addr 0000000000000070 by task repro/16399 CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_msg_ring+0x3cb/0x9f0 kasan_report+0xbc/0xf0 ? io_msg_ring+0x3cb/0x9f0 kasan_check_range+0x140/0x190 io_msg_ring+0x3cb/0x9f0 ? io_msg_ring_prep+0x300/0x300 io_issue_sqe+0x698/0xca0 io_submit_sqes+0x92f/0x1c30 __do_sys_io_uring_enter+0xae4/0x24b0 .... RIP: 0033:0x7f2eaf8f8289 RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289 RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004 RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0 R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: panic_on_warn set ... We don't have a NULL check on file_ptr in io_msg_send_fd() function, so when file_ptr is NUL src_file is also NULL and get_file() dereferences a NULL pointer and leads to above crash. Add a NULL check to fix this issue. Fixes: e6130eba8a84 ("io_uring: add support for passing fixed file descriptors") Reported-by: syzkaller <syzkaller@googlegroups.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20221019171218.1337614-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-10-19i2c: xiic: Add platform module aliasMartin Tůma
The missing "platform" alias is required for the mgb4 v4l2 driver to load the i2c controller driver when probing the HW. Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-19ACPI: scan: Fix DMA range assignmentRobin Murphy
Assigning the device's dma_range_map from the iterator variable after the loop means it always points to the empty terminator at the end of the map, which is not what we want. Similarly, freeing the iterator on error when it points to somwhere in the middle of the allocated array won't work either. Fix this. Fixes: bf2ee8d0c385 ("ACPI: scan: Support multiple DMA windows with different offsets") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Jianmin Lv <lvjianmin@loongson.cn> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Tested-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-19MAINTAINERS: Add Vignesh Raghavendra as maintainer of TI DRA7XX/J721E PCI driverKishon Vijay Abraham I
Add Vignesh Raghavendra as maintainer of TI DRA7XX/J721E PCI driver. Link: https://lore.kernel.org/r/20220928093105.23073-1-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-10-19smb3: interface count displayed incorrectlySteve French
The "Server interfaces" count in /proc/fs/cifs/DebugData increases as the interfaces are requeried, rather than being reset to the new value. This could cause a problem if the server disabled multichannel as the iface_count is checked in try_adding_channels to see if multichannel still supported. Also fixes a coverity warning: Addresses-Coverity: 1526374 ("Concurrent data access violations (MISSING_LOCK)") Cc: <stable@vger.kernel.org> Reviewed-by: Bharath SM <bharathsm@microsoft.com> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2022-10-19selinux: enable use of both GFP_KERNEL and GFP_ATOMIC in convert_context()GONG, Ruiqi
The following warning was triggered on a hardware environment: SELinux: Converting 162 SID table entries... BUG: sleeping function called from invalid context at __might_sleep+0x60/0x74 0x0 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 5943, name: tar CPU: 7 PID: 5943 Comm: tar Tainted: P O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xe8/0x15c ___might_sleep+0x168/0x17c __might_sleep+0x60/0x74 __kmalloc_track_caller+0xa0/0x7dc kstrdup+0x54/0xac convert_context+0x48/0x2e4 sidtab_context_to_sid+0x1c4/0x36c security_context_to_sid_core+0x168/0x238 security_context_to_sid_default+0x14/0x24 inode_doinit_use_xattr+0x164/0x1e4 inode_doinit_with_dentry+0x1c0/0x488 selinux_d_instantiate+0x20/0x34 security_d_instantiate+0x70/0xbc d_splice_alias+0x4c/0x3c0 ext4_lookup+0x1d8/0x200 [ext4] __lookup_slow+0x12c/0x1e4 walk_component+0x100/0x200 path_lookupat+0x88/0x118 filename_lookup+0x98/0x130 user_path_at_empty+0x48/0x60 vfs_statx+0x84/0x140 vfs_fstatat+0x20/0x30 __se_sys_newfstatat+0x30/0x74 __arm64_sys_newfstatat+0x1c/0x2c el0_svc_common.constprop.0+0x100/0x184 do_el0_svc+0x1c/0x2c el0_svc+0x20/0x34 el0_sync_handler+0x80/0x17c el0_sync+0x13c/0x140 SELinux: Context system_u:object_r:pssp_rsyslog_log_t:s0:c0 is not valid (left unmapped). It was found that within a critical section of spin_lock_irqsave in sidtab_context_to_sid(), convert_context() (hooked by sidtab_convert_params.func) might cause the process to sleep via allocating memory with GFP_KERNEL, which is problematic. As Ondrej pointed out [1], convert_context()/sidtab_convert_params.func has another caller sidtab_convert_tree(), which is okay with GFP_KERNEL. Therefore, fix this problem by adding a gfp_t argument for convert_context()/sidtab_convert_params.func and pass GFP_KERNEL/_ATOMIC properly in individual callers. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20221018120111.1474581-1-gongruiqi1@huawei.com/ [1] Reported-by: Tan Ninghao <tanninghao1@huawei.com> Fixes: ee1a84fdfeed ("selinux: overhaul sidtab to fix bug and improve performance") Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> [PM: wrap long BUG() output lines, tweak subject line] Signed-off-by: Paul Moore <paul@paul-moore.com>
2022-10-19net: ethernet: adi: adin1110: Fix SPI transfersAlexandru Tachici
No need to use more than one SPI transfer for reads. Use only one from now as ADIN1110/2111 does not tolerate CS changes during reads. The BCM2711/2708 SPI controllers worked fine, but the NXP IMX8MM could not keep CS lowered during SPI bursts. This change aims to make the ADIN1110/2111 driver compatible with both SPI controllers, without any loss of bandwidth/other capabilities. Fixes: bc93e19d088b ("net: ethernet: adi: Add ADIN1110 support") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19Merge branch 'qdisc-ingress-success'David S. Miller
Paul Blakey says: ==================== net: Fix return value of qdisc ingress handling on success Fix patch + self-test with the currently broken scenario. v4->v3: Removed new line in self test and rebase (Paolo). v2->v3: Added DROP return to TC_ACT_SHOT case (Cong). v1->v2: Changed blamed commit Added self-test ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19selftests: add selftest for chaining of tc ingress handling to egressPaul Blakey
This test runs a simple ingress tc setup between two veth pairs, then adds a egress->ingress rule to test the chaining of tc ingress pipeline to tc egress piepline. Signed-off-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: Fix return value of qdisc ingress handling on successPaul Blakey
Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. This causes a problem in the kernel tcp stack when having a egress tc rule forwarding to a ingress tc rule. The tcp stack sending packets on the device having the egress rule will see the packets as not successfully transmitted (although they actually were), will not advance it's internal state of sent data, and packets returning on such tcp stream will be dropped by the tcp stack with reason ack-of-unsent-data. See reproduction in [0] below. Fix that by setting the return value to RX success if the packet was handled successfully. [0] Reproduction steps: $ ip link add veth1 type veth peer name peer1 $ ip link add veth2 type veth peer name peer2 $ ifconfig peer1 5.5.5.6/24 up $ ip netns add ns0 $ ip link set dev peer2 netns ns0 $ ip netns exec ns0 ifconfig peer2 5.5.5.5/24 up $ ifconfig veth2 0 up $ ifconfig veth1 0 up #ingress forwarding veth1 <-> veth2 $ tc qdisc add dev veth2 ingress $ tc qdisc add dev veth1 ingress $ tc filter add dev veth2 ingress prio 1 proto all flower \ action mirred egress redirect dev veth1 $ tc filter add dev veth1 ingress prio 1 proto all flower \ action mirred egress redirect dev veth2 #steal packet from peer1 egress to veth2 ingress, bypassing the veth pipe $ tc qdisc add dev peer1 clsact $ tc filter add dev peer1 egress prio 20 proto ip flower \ action mirred ingress redirect dev veth1 #run iperf and see connection not running $ iperf3 -s& $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1 #delete egress rule, and run again, now should work $ tc filter del dev peer1 egress $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1 Fixes: f697c3e8b35c ("[NET]: Avoid unnecessary cloning for ingress filtering") Signed-off-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19Merge branch 'net-bridge-mc-cleanups'David S. Miller
Ido Schimmel says: ==================== bridge: A few multicast cleanups Clean up a few issues spotted while working on the bridge multicast code and running its selftests. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19bridge: mcast: Simplify MDB entry creationIdo Schimmel
Before creating a new MDB entry, br_multicast_new_group() will call br_mdb_ip_get() to see if one exists and return it if so. Therefore, simply call br_multicast_new_group() and omit the call to br_mdb_ip_get(). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19bridge: mcast: Use spin_lock() instead of spin_lock_bh()Ido Schimmel
IGMPv3 / MLDv2 Membership Reports are only processed from the data path with softIRQ disabled, so there is no need to call spin_lock_bh(). Use spin_lock() instead. This is consistent with how other IGMP / MLD packets are processed. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19selftests: bridge_igmp: Remove unnecessary address deletionIdo Schimmel
The test group address is added and removed in v2reportleave_test(). There is no need to delete it again during cleanup as it results in the following error message: # bash -x ./bridge_igmp.sh [...] + cleanup + pre_cleanup [...] + ip address del dev swp4 239.10.10.10/32 RTNETLINK answers: Cannot assign requested address + h2_destroy Solve by removing the unnecessary address deletion. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19selftests: bridge_vlan_mcast: Delete qdiscs during cleanupIdo Schimmel
The qdiscs are added during setup, but not deleted during cleanup, resulting in the following error messages: # ./bridge_vlan_mcast.sh [...] # ./bridge_vlan_mcast.sh Error: Exclusivity flag on, cannot modify. Error: Exclusivity flag on, cannot modify. Solve by deleting the qdiscs during cleanup. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19Merge branch 'qdisc-null-deref'David S. Miller
Zhengchao Shao says: ==================== net: fix null pointer access issue in qdisc These three patches fix the same type of problem. Set the default qdisc, and then construct an init failure scenario when the dev qdisc is configured on mqprio to trigger the reset process. NULL pointer access may occur during the reset process. --- v2: for fq_codel, revert the patch --- ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: sched: sfb: fix null pointer access issue when sfb_init() failsZhengchao Shao
When the default qdisc is sfb, if the qdisc of dev_queue fails to be inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK> sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19Revert "net: sched: fq_codel: remove redundant resource cleanup in ↵Zhengchao Shao
fq_codel_init()" This reverts commit 494f5063b86cd6e972cb41a27e083c9a3664319d. When the default qdisc is fq_codel, if the qdisc of dev_queue fails to be inited during mqprio_init(), fq_codel_reset() is invoked to clear resources. In this case, the flow is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() fq_codel_init() ... q->flows_cnt = 1024; ... q->flows = kvcalloc(...) --->failed, q->flows is NULL ... qdisc_put() ... fq_codel_reset() ... flow = q->flows + i --->q->flows is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:fq_codel_reset+0x14d/0x350 Call Trace: <TASK> qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fd272b22d04 </TASK> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: sched: cake: fix null pointer access issue when cake_init() failsZhengchao Shao
When the default qdisc is cake, if the qdisc of dev_queue fails to be inited during mqprio_init(), cake_reset() is invoked to clear resources. In this case, the tins is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:cake_dequeue_one+0xc9/0x3c0 Call Trace: <TASK> cake_reset+0xb1/0x140 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f89e5122d04 </TASK> Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19ethernet: marvell: octeontx2 Fix resource not freed after mallocManank Patel
fix rxsc and txsc not getting freed before going out of scope Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Manank Patel <pmanank200502@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19Merge branch 'dpaa-phylink'David S. Miller
Sean Anderson says: ==================== net: dpaa: Convert to phylink This series converts the DPAA driver to phylink. I have tried to maintain backwards compatibility with existing device trees whereever possible. However, one area where I was unable to achieve this was with QSGMII. Please refer to patch 2 for details. All mac drivers have now been converted. I would greatly appreciate if anyone has T-series or P-series boards they can test/debug this series on. I only have an LS1046ARDB. Everything but QSGMII should work without breakage; QSGMII needs patches 7 and 8. For this reason, the last 4 patches in this series should be applied together (and should not go through separate trees). Changes in v7: - provide phylink_validate_mask_caps() helper - Fix oops if memac_pcs_create returned -EPROBE_DEFER - Fix using pcs-names instead of pcs-handle-names - Fix not checking for -ENODATA when looking for sgmii pcs - Fix 81-character line - Simplify memac_validate with phylink_validate_mask_caps Changes in v6: - Remove unnecessary $ref from renesas,rzn1-a5psw - Remove unnecessary type from pcs-handle-names - Add maxItems to pcs-handle - Fix 81-character line - Fix uninitialized variable in dtsec_mac_config Changes in v5: - Add Lynx PCS binding Changes in v4: - Use pcs-handle-names instead of pcs-names, as discussed - Don't fail if phy support was not compiled in - Split off rate adaptation series - Split off DPAA "preparation" series - Split off Lynx 10G support - t208x: Mark MAC1 and MAC2 as 10G - Add XFI PCS for t208x MAC1/MAC2 Changes in v3: - Expand pcs-handle to an array - Add vendor prefix 'fsl,' to rgmii and mii properties. - Set maxItems for pcs-names - Remove phy-* properties from example because dt-schema complains and I can't be bothered to figure out how to make it work. - Add pcs-handle as a preferred version of pcsphy-handle - Deprecate pcsphy-handle - Remove mii/rmii properties - Put the PCS mdiodev only after we are done with it (since the PCS does not perform a get itself). - Remove _return label from memac_initialization in favor of returning directly - Fix grabbing the default PCS not checking for -ENODATA from of_property_match_string - Set DTSEC_ECNTRL_R100M in dtsec_link_up instead of dtsec_mac_config - Remove rmii/mii properties - Replace 1000Base... with 1000BASE... to match IEEE capitalization - Add compatibles for QSGMII PCSs - Split arm and powerpcs dts updates Changes in v2: - Better document how we select which PCS to use in the default case - Move PCS_LYNX dependency to fman Kconfig - Remove unused variable slow_10g_if - Restrict valid link modes based on the phy interface. This is easier to set up, and mostly captures what I intended to do the first time. We now have a custom validate which restricts half-duplex for some SoCs for RGMII, but generally just uses the default phylink validate. - Configure the SerDes in enable/disable - Properly implement all ethtool ops and ioctls. These were mostly stubbed out just enough to compile last time. - Convert 10GEC and dTSEC as well - Fix capitalization of mEMAC in commit messages - Add nodes for QSGMII PCSs - Add nodes for QSGMII PCSs ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19arm64: dts: layerscape: Add nodes for QSGMII PCSsSean Anderson
Now that we actually read registers from QSGMII PCSs, it's important that we have the correct address (instead of hoping that we're the MAC with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII PCSs. The exact mapping of QSGMII to MACs depends on the SoC. Since the first QSGMII PCSs share an address with the SGMII and XFI PCSs, we only add new nodes for PCSs 2-4. This avoids address conflicts on the bus. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19powerpc: dts: qoriq: Add nodes for QSGMII PCSsSean Anderson
Now that we actually read registers from QSGMII PCSs, it's important that we have the correct address (instead of hoping that we're the MAC with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII PCSs. They have the same addresses on all SoCs (e.g. if QSGMIIA is present it's used for MACs 1 through 4). Since the first QSGMII PCSs share an address with the SGMII and XFI PCSs, we only add new nodes for PCSs 2-4. This avoids address conflicts on the bus. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19powerpc: dts: t208x: Mark MAC1 and MAC2 as 10GSean Anderson
On the T208X SoCs, MAC1 and MAC2 support XGMII. Add some new MAC dtsi fragments, and mark the QMAN ports as 10G. Fixes: da414bb923d9 ("powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)") Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: dpaa: Convert to phylinkSean Anderson
This converts DPAA to phylink. All macs are converted. This should work with no device tree modifications (including those made in this series), except for QSGMII (as noted previously). The mEMAC configuration is one of the tricker areas. I have tried to capture all the restrictions across the various models. Most of the time, we assume that if the serdes supports a mode or the phy-interface-mode specifies it, then we support it. The only place we can't do this is (RG)MII, since there's no serdes. In that case, we rely on a (new) devicetree property. There are also several cases where half-duplex is broken. Unfortunately, only a single compatible is used for the MAC, so we have to use the board compatible instead. The 10GEC conversion is very straightforward, since it only supports XAUI. There is generally nothing to configure. The dTSEC conversion is broadly similar to mEMAC, but is simpler because we don't support configuring the SerDes (though this can be easily added) and we don't have multiple PCSs. From what I can tell, there's nothing different in the driver or documentation between SGMII and 1000BASE-X except for the advertising. Similarly, I couldn't find anything about 2500BASE-X. In both cases, I treat them like SGMII. These modes aren't used by any in-tree boards. Similarly, despite being mentioned in the driver, I couldn't find any documented SoCs which supported QSGMII. I have left it unimplemented for now. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: fman: memac: Use lynx pcs driverSean Anderson
Although not stated in the datasheet, as far as I can tell PCS for mEMACs is a "Lynx." By reusing the existing driver, we can remove the PCS management code from the memac driver. This requires calling some PCS functions manually which phylink would usually do for us, but we will let it do that soon. One problem is that we don't actually have a PCS for QSGMII. We pretend that each mEMAC's MDIO bus has four QSGMII PCSs, but this is not the case. Only the "base" mEMAC's MDIO bus has the four QSGMII PCSs. This is not an issue yet, because we never get the PCS state. However, it will be once the conversion to phylink is complete, since the links will appear to never come up. To get around this, we allow specifying multiple PCSs in pcsphy. This breaks backwards compatibility with old device trees, but only for QSGMII. IMO this is the only reasonable way to figure out what the actual QSGMII PCS is. Additionally, we now also support a separate XFI PCS. This can allow the SerDes driver to set different addresses for the SGMII and XFI PCSs so they can be accessed at the same time. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: fman: memac: Add serdes supportSean Anderson
This adds support for using a serdes which has to be configured. This is primarly in preparation for phylink conversion, which will then change the serdes mode dynamically. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19net: phylink: provide phylink_validate_mask_caps() helperRussell King (Oracle)
Provide a helper that restricts the link modes according to the phylink capabilities. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [rebased on net-next/master and added documentation] Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19dt-bindings: net: fman: Add additional interface propertiesSean Anderson
At the moment, mEMACs are configured almost completely based on the phy-connection-type. That is, if the phy interface is RGMII, it assumed that RGMII is supported. For some interfaces, it is assumed that the RCW/bootloader has set up the SerDes properly. This is generally OK, but restricts runtime reconfiguration. The actual link state is never reported. To address these shortcomings, the driver will need additional information. First, it needs to know how to access the PCS/PMAs (in order to configure them and get the link status). The SGMII PCS/PMA is the only currently-described PCS/PMA. Add the XFI and QSGMII PCS/PMAs as well. The XFI (and 10GBASE-KR) PCS/PMA is a c45 "phy" which sits on the same MDIO bus as SGMII PCS/PMA. By default they will have conflicting addresses, but they are also not enabled at the same time by default. Therefore, we can let the XFI PCS/PMA be the default when phy-connection-type is xgmii. This will allow for backwards-compatibility. QSGMII, however, cannot work with the current binding. This is because the QSGMII PCS/PMAs are only present on one MAC's MDIO bus. At the moment this is worked around by having every MAC write to the PCS/PMA addresses (without checking if they are present). This only works if each MAC has the same configuration, and only if we don't need to know the status. Because the QSGMII PCS/PMA will typically be located on a different MDIO bus than the MAC's SGMII PCS/PMA, there is no fallback for the QSGMII PCS/PMA. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19dt-bindings: net: Add Lynx PCS bindingSean Anderson
This binding is fairly bare-bones for now, since the Lynx driver doesn't parse any properties (or match based on the compatible). We just need it in order to prevent the PCS nodes from having phy devices attached to them. This is not really a problem, but it is a bit inefficient. This binding is really for three separate PCSs (SGMII, QSGMII, and XFI). However, the driver treats all of them the same. This works because the SGMII and XFI devices typically use the same address, and the SerDes driver (or RCW) muxes between them. The QSGMII PCSs have the same register layout as the SGMII PCSs. To do things properly, we'd probably do something like ethernet-pcs@0 { #pcs-cells = <1>; compatible = "fsl,lynx-pcs"; reg = <0>, <1>, <2>, <3>; }; but that would add complexity, and we can describe the hardware just fine using separate PCSs for now. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19dt-bindings: net: Expand pcs-handle to an arraySean Anderson
This allows multiple phandles to be specified for pcs-handle, such as when multiple PCSs are present for a single MAC. To differentiate between them, also add a pcs-handle-names property. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-19ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()Rafael J. Wysocki
Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed to reference count the device returned by acpi_get_pci_dev() as expected by its callers which in some cases may cause device objects to be dropped prematurely. Add the missing get_device() to acpi_get_pci_dev(). Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-19drm/amdgpu: use DRM_SCHED_FENCE_DONT_PIPELINE for VM updatesChristian König
Make sure that we always have a CPU round trip to let the submission code correctly decide if a TLB flush is necessary or not. Signed-off-by: Christian König <christian.koenig@amd.com> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2113#note_1579296 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014081553.114899-2-christian.koenig@amd.com
2022-10-19nvmet: fix invalid memory reference in nvmet_subsys_attr_qid_max_showDaniel Wagner
The item passed into nvmet_subsys_attr_qid_max_show is not a member of struct nvmet_port, it is part of nvmet_subsys. Hence, don't try to dereference it as struct nvme_ctrl pointer. Fixes: 3e980f5995e0 ("nvmet: Expose max queues to configfs") Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Link: https://lore.kernel.org/r/20220913064203.133536-1-dwagner@suse.de Signed-off-by: Daniel Wagner <dwagner@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Acked-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-10-19nvmet: fix workqueue MEM_RECLAIM flushing dependencySagi Grimberg
The keep alive timer needs to stay on nvmet_wq, and not modified to reschedule on the system_wq. This fixes a warning: ------------[ cut here ]------------ workqueue: WQ_MEM_RECLAIM nvmet-wq:nvmet_rdma_release_queue_work [nvmet_rdma] is flushing !WQ_MEM_RECLAIM events:nvmet_keep_alive_timer [nvmet] WARNING: CPU: 3 PID: 1086 at kernel/workqueue.c:2628 check_flush_dependency+0x16c/0x1e0 Reported-by: Yi Zhang <yi.zhang@redhat.com> Fixes: 8832cf922151 ("nvmet: use a private workqueue instead of the system workqueue") Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-10-19nvme-hwmon: kmalloc the NVME SMART log bufferSerge Semin
Recent commit 52fde2c07da6 ("nvme: set dma alignment to dword") has caused a regression on our platform. It turned out that the nvme_get_log() method invocation caused the nvme_hwmon_data structure instance corruption. In particular the nvme_hwmon_data.ctrl pointer was overwritten either with zeros or with garbage. After some research we discovered that the problem happened even before the actual NVME DMA execution, but during the buffer mapping. Since our platform is DMA-noncoherent, the mapping implied the cache-line invalidations or write-backs depending on the DMA-direction parameter. In case of the NVME SMART log getting the DMA was performed from-device-to-memory, thus the cache-invalidation was activated during the buffer mapping. Since the log-buffer isn't cache-line aligned, the cache-invalidation caused the neighbour data to be discarded. The neighbouring data turned to be the data surrounding the buffer in the framework of the nvme_hwmon_data structure. In order to fix that we need to make sure that the whole log-buffer is defined within the cache-line-aligned memory region so the cache-invalidation procedure wouldn't involve the adjacent data. One of the option to guarantee that is to kmalloc the DMA-buffer [1]. Seeing the rest of the NVME core driver prefer that method it has been chosen to fix this problem too. Note after a deeper researches we found out that the denoted commit wasn't a root cause of the problem. It just revealed the invalidity by activating the DMA-based NVME SMART log getting performed in the framework of the NVME hwmon driver. The problem was here since the initial commit of the driver. [1] Documentation/core-api/dma-api-howto.rst Fixes: 400b6a7b13a3 ("nvme: Add hardware monitoring support") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-10-19nvme-hwmon: consistently ignore errors from nvme_hwmon_initChristoph Hellwig
An NVMe controller works perfectly fine even when the hwmon initialization fails. Stop returning errors that do not come from a controller reset from nvme_hwmon_init to handle this case consistently. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2022-10-19drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flagChristian König
Setting this flag on a scheduler fence prevents pipelining of jobs depending on this fence. In other words we always insert a full CPU round trip before dependent jobs are pushed to the pipeline. Signed-off-by: Christian König <christian.koenig@amd.com> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2113#note_1579296 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014081553.114899-1-christian.koenig@amd.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-01 01:00:21 +0000