Commit graph

1,399,042 commits

Author SHA1 Message Date
Jinjie Ruan
16a0a69244 soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()
If request_irq() fails in sr_late_init(), there is no need to enable
the irq, and if it succeeds, disable_irq() after request_irq() still has
a time gap in which interrupts can come.

request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when
request IRQ.

Fixes: 1279ba5916 ("OMAP3+: SR: disable interrupt by default")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20240912034147.3014213-1-ruanjinjie@huawei.com
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2024-10-04 14:25:48 -07:00
Rob Herring (Arm)
47048d5bcf ARM: dts: ti/omap: Fix at24 EEPROM node names
at24.yaml defines the node name for at24 EEPROMs as 'eeprom'.

Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: hns@goldelico.com # for GTA04
Link: https://lore.kernel.org/r/20240910215942.824137-1-robh@kernel.org
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2024-10-04 14:17:36 -07:00
Luiz Augusto von Dentz
610712298b Bluetooth: btusb: Don't fail external suspend requests
Commit 4e0a1d8b06
("Bluetooth: btusb: Don't suspend when there are connections")
introduces a check for connections to prevent auto-suspend but that
actually ignored the fact the .suspend callback can be called for
external suspend requests which
Documentation/driver-api/usb/power-management.rst states the following:

 'External suspend calls should never be allowed to fail in this way,
 only autosuspend calls.  The driver can tell them apart by applying
 the :c:func:`PMSG_IS_AUTO` macro to the message argument to the
 ``suspend`` method; it will return True for internal PM events
 (autosuspend) and False for external PM events.'

In addition to that align system suspend with USB suspend by using
hci_suspend_dev since otherwise the stack would be expecting events
such as advertising reports which may not be delivered while the
transport is suspended.

Fixes: 4e0a1d8b06 ("Bluetooth: btusb: Don't suspend when there are connections")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Kiran K <kiran.k@intel.com>
2024-10-04 16:54:25 -04:00
Luiz Augusto von Dentz
18fd04ad85 Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync
This checks if the ACL connection remains valid as it could be destroyed
while hci_enhanced_setup_sync is pending on cmd_sync leading to the
following trace:

BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60
Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37

CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 ? hci_enhanced_setup_sync+0x91b/0xa60
 print_report+0x152/0x4c0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 ? __virt_addr_valid+0x1fa/0x420
 ? hci_enhanced_setup_sync+0x91b/0xa60
 kasan_report+0xda/0x1b0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 hci_enhanced_setup_sync+0x91b/0xa60
 ? __pfx_hci_enhanced_setup_sync+0x10/0x10
 ? __pfx___mutex_lock+0x10/0x10
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 ? __pfx_lock_acquire+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? assign_work+0x167/0x240
 worker_thread+0x5b7/0xf60
 ? __kthread_parkme+0xac/0x1c0
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x293/0x360
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x70
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Allocated by task 34:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __hci_conn_add+0x187/0x17d0
 hci_connect_sco+0x2e1/0xb90
 sco_sock_connect+0x2a2/0xb80
 __sys_connect+0x227/0x2a0
 __x64_sys_connect+0x6d/0xb0
 do_syscall_64+0x71/0x140
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 37:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x101/0x160
 kfree+0xd0/0x250
 device_release+0x9a/0x210
 kobject_put+0x151/0x280
 hci_conn_del+0x448/0xbf0
 hci_abort_conn_sync+0x46f/0x980
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 worker_thread+0x5b7/0xf60
 kthread+0x293/0x360
 ret_from_fork+0x2f/0x70
 ret_from_fork_asm+0x1a/0x30

Cc: stable@vger.kernel.org
Fixes: e07a06b4eb ("Bluetooth: Convert SCO configure_datapath to hci_sync")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-10-04 16:54:17 -04:00
Luiz Augusto von Dentz
08d1914293 Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Reported-by: syzbot+d7ce59b06b3eb14fd218@syzkaller.appspotmail.com
Tested-by: syzbot+d7ce59b06b3eb14fd218@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218
Fixes: 3241ad820d ("[Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-10-04 16:54:10 -04:00
Kory Maincent
dda3529d2e net: pse-pd: Fix enabled status mismatch
PSE controllers like the TPS23881 can forcefully turn off their
configuration state. In such cases, the is_enabled() and get_status()
callbacks will report the PSE as disabled, while admin_state_enabled
will show it as enabled. This mismatch can lead the user to attempt
to enable it, but no action is taken as admin_state_enabled remains set.

The solution is to disable the PSE before enabling it, ensuring the
actual status matches admin_state_enabled.

Fixes: d83e13761d ("net: pse-pd: Use regulator framework within PSE framework")
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241002121706.246143-1-kory.maincent@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 13:14:18 -07:00
Kacper Ludwinski
9f49d14ec4 selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids() test
Currently, the second bridge command overwrites the first one.
Fix this by adding this VID to the interface behind $swp2.

The one_bridge_two_pvids() test intends to check that there is no
leakage of traffic between bridge ports which have a single VLAN - the
PVID VLAN.

Because of a typo, port $swp1 is configured with a PVID twice (second
command overwrites first), and $swp2 isn't configured at all (and since
the bridge vlan_default_pvid property is set to 0, this port will not
have a PVID at all, so it will drop all untagged and priority-tagged
traffic).

So, instead of testing the configuration that was intended, we are
testing a different one, where one port has PVID 2 and the other has
no PVID. This incorrect version of the test should also pass, but is
ineffective for its purpose, so fix the typo.

This typo has an impact on results of the test,
potentially leading to wrong conclusions regarding
the functionality of a network device.

The tests results:

TEST: Switch ports in VLAN-aware bridge with different PVIDs:
	Unicast non-IP untagged   [ OK ]
	Multicast non-IP untagged   [ OK ]
	Broadcast non-IP untagged   [ OK ]
	Unicast IPv4 untagged   [ OK ]
	Multicast IPv4 untagged   [ OK ]
	Unicast IPv6 untagged   [ OK ]
	Multicast IPv6 untagged   [ OK ]
	Unicast non-IP VID 1   [ OK ]
	Multicast non-IP VID 1   [ OK ]
	Broadcast non-IP VID 1   [ OK ]
	Unicast IPv4 VID 1   [ OK ]
	Multicast IPv4 VID 1   [ OK ]
	Unicast IPv6 VID 1   [ OK ]
	Multicast IPv6 VID 1   [ OK ]
	Unicast non-IP VID 4094   [ OK ]
	Multicast non-IP VID 4094   [ OK ]
	Broadcast non-IP VID 4094   [ OK ]
	Unicast IPv4 VID 4094   [ OK ]
	Multicast IPv4 VID 4094   [ OK ]
	Unicast IPv6 VID 4094   [ OK ]
	Multicast IPv6 VID 4094   [ OK ]

Fixes: 476a4f05d9 ("selftests: forwarding: add a no_forwarding.sh test")
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Kacper Ludwinski <kac.ludwinski@icloud.com>
Link: https://patch.msgid.link/20241002051016.849-1-kac.ludwinski@icloud.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 13:13:02 -07:00
Tejun Heo
ec010333ce sched_ext: scx_cgroup_exit() may be called without successful scx_cgroup_init()
568894edbe ("sched_ext: Add scx_cgroup_enabled to gate cgroup operations
and fix scx_tg_online()") assumed that scx_cgroup_exit() is only called
after scx_cgroup_init() finished successfully. This isn't true.
scx_cgroup_exit() can be called without scx_cgroup_init() being called at
all or after scx_cgroup_init() failed in the middle.

As init state is tracked per cgroup, scx_cgroup_exit() can be used safely to
clean up in all cases. Remove the incorrect WARN_ON_ONCE().

Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 568894edbe ("sched_ext: Add scx_cgroup_enabled to gate cgroup operations and fix scx_tg_online()")
2024-10-04 10:12:11 -10:00
Tejun Heo
cc9877fb76 sched_ext: Improve error reporting during loading
When the BPF scheduler fails, ops.exit() allows rich error reporting through
scx_exit_info. Use scx.exit() path consistently for all failures which can
be caused by the BPF scheduler:

- scx_ops_error() is called after ops.init() and ops.cgroup_init() failure
  to record error information.

- ops.init_task() failure now uses scx_ops_error() instead of pr_err().

- The err_disable path updated to automatically trigger scx_ops_error() to
  cover cases that the error message hasn't already been generated and
  always return 0 indicating init success so that the error is reported
  through ops.exit().

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>
Cc: Daniel Hodges <hodges.daniel.scott@gmail.com>
Cc: Changwoo Min <multics69@gmail.com>
Cc: Andrea Righi <andrea.righi@linux.dev>
Cc: Dan Schatzberg <schatzberg.dan@gmail.com>
2024-10-04 10:11:43 -10:00
Michael Kelley
c86ab60b92 hv_netvsc: Don't assume cpu_possible_mask is dense
Current code allocates the pcpu_sum array with size num_possible_cpus().
This code assumes the cpu_possible_mask is dense, which is not true in
the general case per [1]. If cpu_possible_mask is sparse, the array
might be indexed by a value beyond the size of the array.

However, the configurations that Hyper-V provides to guest VMs on x86
and ARM64 hardware, in combination with how architecture specific code
assigns Linux CPU numbers, *does* always produce a dense cpu_possible_mask.
So the dense assumption is not currently causing failures. But for
robustness against future changes in how cpu_possible_mask is populated,
update the code to no longer assume dense.

The correct approach is to allocate and initialize the array using size
"nr_cpu_ids". While this leaves unused array entries corresponding to
holes in cpu_possible_mask, the holes are assumed to be minimal and hence
the amount of memory wasted by unused entries is minimal.

[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/

Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20241003035333.49261-6-mhklinux@outlook.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 13:09:20 -07:00
Daniel Zahka
5c2ab978f9 ethtool: rss: fix rss key initialization warning
This warning is emitted when a driver does not default populate an rss
key when one is not provided from userspace. Some devices do not
support individual rss keys per context. For these devices, it is ok
to leave the key zeroed out in ethtool_rxfh_context. Do not warn on
zeroed key when ethtool_ops.rxfh_per_ctx_key == 0.

Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20241003162310.1310576-1-daniel.zahka@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 12:34:13 -07:00
Jakub Kicinski
00110c5eeb Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue
Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2024-10-01 (ice)

This series contains updates to ice driver only.

Karol cleans up current PTP GPIO pin handling, fixes minor bugs,
refactors implementation for all products, introduces SDP (Software
Definable Pins) for E825C and implements reading SDP section from NVM
for E810 products.

Sergey replaces multiple aux buses and devices used in the PTP support
code with struct ice_adapter holding the necessary shared data.

* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
  ice: Drop auxbus use for PTP to finalize ice_adapter move
  ice: Use ice_adapter for PTP shared data instead of auxdev
  ice: Initial support for E825C hardware in ice_adapter
  ice: Add ice_get_ctrl_ptp() wrapper to simplify the code
  ice: Introduce ice_get_phy_model() wrapper
  ice: Enable 1PPS out from CGU for E825C products
  ice: Read SDP section from NVM for pin definitions
  ice: Disable shared pin on E810 on setfunc
  ice: Cache perout/extts requests and check flags
  ice: Align E810T GPIO to other products
  ice: Add SDPs support for E825C
  ice: Implement ice_ptp_pin_desc
====================

Link: https://patch.msgid.link/20241001201702.3252954-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 12:30:18 -07:00
Linus Torvalds
ac30860956 arm64 fixes for 6.12-rc2:
- Expand the speculative SSBS workaround to cover Cortex-A715,
   Neoverse-N3 and Microsoft Azure Cobalt 100
 
 - Force position-independent veneers - in some kernel configurations,
   the LLD linker generates position-dependent veneers for otherwise
   position-independent code, resulting in early boot-time failures
 
 - Fix Kconfig selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS so that it is
   not enabled when not supported by the combination of clang and GNU ld
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmcAFR0ACgkQa9axLQDI
 XvGnjQ//UMjvCdyx5fvy10B/epEu3EKUUgvGs6VBlwEo5qgryzgxjJjXDkv7tD85
 xGyXKrsq3dsZlKG3D90a8/Xu8BBkrQ4jcZTUI8j6b/fKhO+cj46bjv9Q+24fhoFw
 lj/8CaL/VNpH2ZoKiG9rZilVOz0Qo5VE9QD083Li7uoglNfBu4Cpeq3WcqPj942V
 bNFy9dpLyRRpVRw3LKl2Zprx830wnlIpcPca9ooaFdmuBG/yUY6cLPIGARM7pcUj
 IVicLma93gg9NmBwSLedLF1c26hIhnxzwUNVrOd4vUmwAIt9dnS/YnMrF4eGzOUw
 C2PyUMqQz8s5R3aEJNTBnNw2sIcaBT3yisDNQVQh4dMHANvWchr3Y9XEvCekHJzr
 F7FIcgOHANxYwrWDGIS1eUJsiRhHY0zd0s5AQ/FIV7DuhfhKZrdlLla8mscvcUa/
 JRiEW3W+95tEDJ7yLbRd7jDUkmlF1A5k2j/7//Ei5qIh/PArWAxBMClqIaOGhZWk
 1XzFBxIi+heyBSr+aIqCv/V1ozfx3LOPk8qFy7IjtxgL/TbSh3XpDl/ZnNeMr4oS
 NnRiYDjtifMNutVCgLjwAm8jTo4yHDpgYmM9HvZWW747iZumkw0HmkufMc1RLjIR
 7hA9cJrBS9wINmcx/+EtT4c5ed43GGyeADFryJT/W9Wxo1X8Ii8=
 =lj80
 -----END PGP SIGNATURE-----

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 fixes from Catalin Marinas:
 "A couple of build/config issues and expanding the speculative SSBS
  workaround to more CPUs:

   - Expand the speculative SSBS workaround to cover Cortex-A715,
     Neoverse-N3 and Microsoft Azure Cobalt 100

   - Force position-independent veneers - in some kernel configurations,
     the LLD linker generates position-dependent veneers for otherwise
     position-independent code, resulting in early boot-time failures

   - Fix Kconfig selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS so that it
     is not enabled when not supported by the combination of clang and
     GNU ld"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386
  arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS
  arm64: errata: Expand speculative SSBS workaround once more
  arm64: cputype: Add Neoverse-N3 definitions
  arm64: Force position-independent veneers
2024-10-04 12:20:09 -07:00
Linus Torvalds
7943f06cfc RISC-V Fixes for 6.12-rc2
* PERF_TYPE_BREAKPOINT now returns -EOPNOTSUPP instead of -ENOENT, which
   aligns to other ports and is a saner value.
 * The KASAN-related stack size increasing logic has been moved to a
   C header, to avoid dependency issues.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEKzw3R0RoQ7JKlDp6LhMZ81+7GIkFAmb/+C8THHBhbG1lckBk
 YWJiZWx0LmNvbQAKCRAuExnzX7sYicPGD/4z/Z2Jk8h0nQY4E+dr6OIRuHHzrghx
 BzZSI41eFbfw//SjGmr4s0lFhr7MNYiXMvnIwATpJ8iemBmGdutVnKE/wtkrYmCg
 FCoduapfhKpzbrIeOZVKcw0w33DVnoBSZ8kaT+soazCk3j8isBemSqu9bY9/wWbW
 u7SZmSbusd7DNWYSkm+pF0wWUgJ+dgeo8eDSbMB8zgLQvnFvJVGqMpE14N1PatFd
 BCyNZLhWUVoLf17tm0tcPNu/ZblV1La0wt6QLTum30IXrq70RI0QnSifw+l26P+x
 ABcDt/AwDunEX9GopbfV2LL/sgoYyfOff7RhR5v5dNc8V+rAY83efCyzLuz9gJ8N
 GepHz9sY5nm2w0bqL6T9SyakYiULAqoy6uhWUTfQTXGOejuV8JLY9YdHJ1t31sFP
 iO9BAN/7pOuB48Q20zTfMJ1SBrYH17SeP6fuEeoI9QWZ5mWeEx4RCGfAM4XfA6W7
 yQFIvKBel0x6bO8pJ3xJ1U+K1Dza/zJSVdnzcPRRPNIN9TF8E4wbnKZ2/fsLoqRi
 bmiKx8ZCk6YHKUuGb6aGYk+UgT+V5/Zegkt9n3fNnIacxBhKkxUnwtSbX2qQNlin
 CYOOo9EmtmjIpCsMHe6Edn3wFhBQKWzai7B+PjqutydG3bRnJ2fHh5djC0H9XNG2
 J+k/1IOV2IYmzg==
 =kB+2
 -----END PGP SIGNATURE-----

Merge tag 'riscv-for-linus-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull RISC-V fixes from Palmer Dabbelt:

 - PERF_TYPE_BREAKPOINT now returns -EOPNOTSUPP instead of -ENOENT,
   which aligns to other ports and is a saner value

 - The KASAN-related stack size increasing logic has been moved to a C
   header, to avoid dependency issues

* tag 'riscv-for-linus-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: Fix kernel stack size when KASAN is enabled
  drivers/perf: riscv: Align errno for unsupported perf event
2024-10-04 12:16:51 -07:00
Linus Torvalds
622a3ed1ac Various fixes for tracing:
- Fix tp_printk command line option crashing the kernel
 
   With the code that can handle a buffer from a previous boot, the
   trace_check_vprintf() needed access to the delta of the address
   space used by the old buffer and the current buffer. To do so,
   the trace_array (tr) parameter was used. But when tp_printk is
   enabled on the kernel command line, no trace buffer is used and
   the trace event is sent directly to printk(). That meant the tr
   field of the iterator descriptor was NULL, and since tp_printk still
   uses trace_check_vprintf() it caused a NULL dereference.
 
 - Add ptrace.h include to x86 ftrace file for completeness
 
 - Fix rtla installation when done with out-of-tree build
 
 - Fix the help messages in rtla that were incorrect
 
 - Several fixes to fix races with the timerlat and hwlat code
 
   Several locking issues were discovered with the coordination
   between timerlat kthread creation and hotplug. As timerlat has
   callbacks from hotplug code to start kthreads when CPUs come online.
   There are also locking issues with grabbing the cpu_read_lock()
   and the locks within timerlat.
 -----BEGIN PGP SIGNATURE-----
 
 iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCZwAUghQccm9zdGVkdEBn
 b29kbWlzLm9yZwAKCRAp5XQQmuv6qmMCAP9Z+0sN/Tx+F+5LmrXV1R9UxRPykmpm
 4NeZYEp+hAQSegD+MdHsEJLIDfmsZnGOBivmzfepuv35GMLrqQMIhhWQOA0=
 =/OQq
 -----END PGP SIGNATURE-----

Merge tag 'trace-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull tracing fixes from Steven Rostedt:

 - Fix tp_printk command line option crashing the kernel

   With the code that can handle a buffer from a previous boot, the
   trace_check_vprintf() needed access to the delta of the address space
   used by the old buffer and the current buffer. To do so, the
   trace_array (tr) parameter was used. But when tp_printk is enabled on
   the kernel command line, no trace buffer is used and the trace event
   is sent directly to printk(). That meant the tr field of the iterator
   descriptor was NULL, and since tp_printk still uses
   trace_check_vprintf() it caused a NULL dereference.

 - Add ptrace.h include to x86 ftrace file for completeness

 - Fix rtla installation when done with out-of-tree build

 - Fix the help messages in rtla that were incorrect

 - Several fixes to fix races with the timerlat and hwlat code

   Several locking issues were discovered with the coordination between
   timerlat kthread creation and hotplug. As timerlat has callbacks from
   hotplug code to start kthreads when CPUs come online. There are also
   locking issues with grabbing the cpu_read_lock() and the locks within
   timerlat.

* tag 'trace-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  tracing/hwlat: Fix a race during cpuhp processing
  tracing/timerlat: Fix a race during cpuhp processing
  tracing/timerlat: Drop interface_lock in stop_kthread()
  tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline
  x86/ftrace: Include <asm/ptrace.h>
  rtla: Fix the help text in osnoise and timerlat top tools
  tools/rtla: Fix installation from out-of-tree build
  tracing: Fix trace_check_vprintf() when tp_printk is used
2024-10-04 12:11:06 -07:00
Ba Jing
1c5e11b3ee tools/rv: Correct the grammatical errors in the comments
The word "trace" begins with a consonant sound,
so "a" should be used instead of "an".

Link: https://lore.kernel.org/20240903003019.8969-1-bajing@cmss.chinamobile.com
Signed-off-by: Ba Jing <bajing@cmss.chinamobile.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-10-04 15:07:24 -04:00
Ba Jing
f88b8871c7 tools/rv: Correct the grammatical errors in the comments
The form of "print" should be consistent with "parses".

Link: https://lore.kernel.org/20240902233408.8684-1-bajing@cmss.chinamobile.com
Signed-off-by: Ba Jing <bajing@cmss.chinamobile.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-10-04 15:06:18 -04:00
Linus Torvalds
f6785e0ccf slab fixes for 6.12-rc1
-----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEEe7vIQRWZI0iWSE3xu+CwddJFiJoFAmb/8bcACgkQu+CwddJF
 iJoApwf5AWWhKFbbYwFUCXDi7+/Xr7T7c9H9q+GAEOQiDLsDxihEAo1KYQ+DLl+h
 Vp1ddRYIKMIUfllW3bcD4O6C8L46OX3XPHhTHnksEfvtn3fQGjcU3jKH8n0eL01J
 s9eUdvduNSJorAWqjFPPRrGuLJTXmervrDYYPJLaXGITHHMOxMjKfLAxtXehvARv
 mVQV1F0NTvvNqieuibUCM5XqJs37lrmqB39pLun7bQDU48z4OR1L3nkJxTFF1bGm
 EcvAPayTiNybMt08QSVHIwqfSs+e0HmyKqjvSLpJPImDrfSrWOJvBCJxI4DU+1aw
 UiHyWYLaxWZ7DoJgtZuHV2//8wOWww==
 =EXEA
 -----END PGP SIGNATURE-----

Merge tag 'slab-for-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab

Pull slab fixes from Vlastimil Babka:
 "Fixes for issues introduced in this merge window: kobject memory leak,
  unsupressed warning and possible lockup in new slub_kunit tests,
  misleading code in kvfree_rcu_queue_batch()"

* tag 'slab-for-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab:
  slub/kunit: skip test_kfree_rcu when the slub kunit test is built-in
  mm, slab: suppress warnings in test_leak_destroy kunit test
  rcu/kvfree: Refactor kvfree_rcu_queue_batch()
  mm, slab: fix use of SLAB_SUPPORTS_SYSFS in kmem_cache_release()
2024-10-04 12:05:39 -07:00
Jakub Kicinski
500257db81 Merge branch 'ibmvnic-fix-for-send-scrq-direct'
Nick Child says:

====================
ibmvnic: Fix for send scrq direct

This is a v2 of a patchset (now just patch) which addresses a
bug in a new feature which is causing major link UP issues with
certain physical cards.

For a full summary of the issue:
  1. During vnic initialization we get the following values from vnic
     server regarding "Transmit / Receive Descriptor Requirement" (see
      PAPR Table 584. CAPABILITIES Commands):
    - LSO Tx frame = 0x0F , header offsets + L2, L3, L4 headers required
    - CSO Tx frame = 0x0C , header offsets + L2 header required
    - standard frame = 0x0C , header offsets + L2 header required
  2. Assume we are dealing with only "standard frames" from now on (no
     CSO, no LSO)
  3. When using 100G backing device, we don't hand vnic server any header
     information and TX is successful
  4. When using 25G backing device, we don't hand vnic server any header
    information and TX fails and we get "Adapter Error" transport events.
The obvious issue here is that vnic client should be respecting the 0X0C
header requirement for standard frames.  But 100G cards will also give
0x0C despite the fact that we know TX works if we ignore it. That being
said, we still must respect values given from the managing server. Will
need to work with them going forward to hopefully get 100G cards to
return 0x00 for this bitstring so the performance gains of using
send_subcrq_direct can be continued.
====================

Link: https://patch.msgid.link/20241001163200.1802522-1-nnac123@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 12:04:12 -07:00
Nick Child
de390657b5 ibmvnic: Inspect header requirements before using scrq direct
Previously, the TX header requirement for standard frames was ignored.
This requirement is a bitstring sent from the VIOS which maps to the
type of header information needed during TX. If no header information,
is needed then send subcrq direct can be used (which can be more
performant).

This bitstring was previously ignored for standard packets (AKA non LSO,
non CSO) due to the belief that the bitstring was over-cautionary. It
turns out that there are some configurations where the backing device
does need header information for transmission of standard packets. If
the information is not supplied then this causes continuous "Adapter
error" transport events. Therefore, this bitstring should be respected
and observed before considering the use of send subcrq direct.

Fixes: 74839f7a82 ("ibmvnic: Introduce send sub-crq direct")
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241001163200.1802522-2-nnac123@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 12:04:09 -07:00
Linus Torvalds
e1043b6765 ACPI updates for 6.12-rc2
- Add a quirk for Dell OptiPlex 5480 AIO to the ACPI backlight (video)
    driver (Hans de Goede).
 
  - Prevent the ACPI battery driver from crashing when unregistering a
    battery hook and simplify battery hook locking in it (Armin Wolf).
 
  - Fix up the ACPI IRQ override quirk list and add quirks for Asus
    Vivobook X1704VAP and Asus ExpertBook B2502CVA to it (Hans de Goede).
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmcAJUISHHJqd0Byand5
 c29ja2kubmV0AAoJEILEb/54YlRxUuAP/j+HbIc+2wgCZKQlbdJVU/L/ZTUwKQ6i
 C6HeaTH7zEy226OVkwwOxqoQMIS/UdBa+lum2b7H8XXBokLzv3wAIvjORkrQWBHm
 +xHhywHeQkp1ysYbBD5moxqKQyE+cpPLd+L1ck2vZlixo5pJkXhatGNP7Ew8MwmQ
 +mquDyt14swi8M8TiMxoHpEKBIaSqxb+cVYQZ+XdhfhbADCV8DbdVmPfvGLZ/2td
 uFlBt5CdUxgMN/us4ZQmsB9myWqSRhpgDyckhurRaNzJmFKhWtHldXFsJwACsdvb
 YJIan+c3OAq3GkyLPYRMSekCKJVxQKPD9R3v6QWc6az45sS4YlD028qGHYm30UxM
 VJZfnJWm/IfDMYol27+I41LSeTEWk125Gv0yRnht7jw0xNuSnha0Gi3USgXwQpKc
 aN2pxpoz4PpHVxsfjO7wB5IjXv7JbSnFwFMkN//3QhYk1wApOQ/KwpxP5TgWj8OC
 Jmt09bdOSesSNCGIi2gCSCQ4YDEUNYGJkNPtHIPcf2KbIjcbNYLBEGl+gl32wreT
 vahgTS0SakmotvXPaY6cvgc8Ab2+cQUeSVPV+Hhc/s+JXSPesdBvLaLdtIx4CzYf
 ulKMLofWiKyZ9jaMwOmVoHOgAdeVlpOgcuSGw1ATOhY8YIkJE7mMm75WLPGNVIhp
 v4nhRQp+Fu57
 =EzOq
 -----END PGP SIGNATURE-----

Merge tag 'acpi-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI fixes from Rafael Wysocki:
 "These fix up the ACPI IRQ override quirk list and add two new entries
  to it, add a new quirk to the ACPI backlight (video) driver, and fix
  the ACPI battery driver.

  Specifics:

   - Add a quirk for Dell OptiPlex 5480 AIO to the ACPI backlight
     (video) driver (Hans de Goede)

   - Prevent the ACPI battery driver from crashing when unregistering a
     battery hook and simplify battery hook locking in it (Armin Wolf)

   - Fix up the ACPI IRQ override quirk list and add quirks for Asus
     Vivobook X1704VAP and Asus ExpertBook B2502CVA to it (Hans de
     Goede)"

* tag 'acpi-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI: battery: Fix possible crash when unregistering a battery hook
  ACPI: battery: Simplify battery hook locking
  ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO
  ACPI: resource: Add Asus ExpertBook B2502CVA to irq1_level_low_skip_override[]
  ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]
  ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA
  ACPI: resource: Remove duplicate Asus E1504GAB IRQ override
2024-10-04 11:59:36 -07:00
Linus Torvalds
5d18081de2 Power management fixes for 6.12-rc2
- Fix CPU device node reference counting in the cpufreq core (Miquel
    Sabaté Solà).
 
  - Turn the spinlock used by the intel_pstate driver in hard IRQ
    context into a raw one to prevent the driver from crashing when
    PREEMPT_RT is enabled (Uwe Kleine-König).
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmcAJMUSHHJqd0Byand5
 c29ja2kubmV0AAoJEILEb/54YlRx4o0P/2eVuEGFIOurheROyFs7UrYRwODvWpgd
 omE2iyihyi+E85IhOD3pPhwv8G156MhfGQ17Bwmt15jczzAs+j9ijPoX9tNxYMlh
 oUq9lsF3B+1sF2VD31iRK6oUjwSQIrjoCzlEuKfW/2VQKmHFFNbj1oj6gYhtWJnb
 0NfozwDMVeN+hqRAZ1TNXnQcohgpQJjkaalHJccTgSNlTJ6J3nCvamdrBRMbBJLU
 DbqYWkLHw26AzARxV3isTj8dFb9R/ng6g/uCBuHGID9JbYCpQS72n2H/9yff7Msf
 wHnRpaDYaAniJPFXlZDyct/LYR9JI477nYIO8jJenfNLr1640hFGBF8DyM7EREcU
 ACnnbQTY5omGyhNoTRrEnSdwa54ukzABlNcldCLn1ilIvWqFrR3YFwX/tNsyBYFL
 Y2HGwfEHpFoKYdUXs3wLN0prnaV0ILr71Kv9OR+d2lB/KmPCSMvYvJSpYVMrl93R
 hsOkZUprd0DXZCRDr4mSFbUZcNzOwMi7c1QgueRcdJuoG8rXzi0nq3RrtV2rgoTz
 beOnxUieEzWrl4OVTtbiBu2H2o2N0VM7znaNxr1hWjwzHeXpxs0ChmQRwmY450fW
 bvOpqhEkrrBTGuQ0xgn41KpIV0G/X0ULrjsC9W9bmf4Oi6aUxQvtRTTvYDjH9pil
 Gy3P1hPfPUkb
 =mgVf
 -----END PGP SIGNATURE-----

Merge tag 'pm-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These fix two cpufreq issues, one in the core and one in the
  intel_pstate driver:

   - Fix CPU device node reference counting in the cpufreq core (Miquel
     Sabaté Solà)

   - Turn the spinlock used by the intel_pstate driver in hard IRQ
     context into a raw one to prevent the driver from crashing when
     PREEMPT_RT is enabled (Uwe Kleine-König)"

* tag 'pm-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: Avoid a bad reference count on CPU node
  cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock
2024-10-04 11:57:15 -07:00
Jakub Kicinski
69ea1d4ac9 Merge branch 'netfilter-br_netfilter-fix-panic-with-metadata_dst-skb'
Andy Roulin says:

====================
netfilter: br_netfilter: fix panic with metadata_dst skb

There's a kernel panic possible in the br_netfilter module when sending
untagged traffic via a VxLAN device. Traceback is included below.
This happens during the check for fragmentation in br_nf_dev_queue_xmit
if the MTU on the VxLAN device is not big enough.

It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded

This case was never supported in the first place, so the first patch drops
such packets.

A regression selftest is added as part of the second patch.

PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[  176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[  176.292101] Mem abort info:
[  176.292184]   ESR = 0x0000000096000004
[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
[  176.292530]   SET = 0, FnV = 0
[  176.292709]   EA = 0, S1PTW = 0
[  176.292862]   FSC = 0x04: level 0 translation fault
[  176.293013] Data abort info:
[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[  176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[  176.296314] Hardware name: linux,dummy-virt (DT)
[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[  176.297636] sp : ffff800080003630
[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[  176.300889] Call trace:
[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[  176.301703]  nf_hook_slow+0x48/0x124
[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[  176.303359]  nf_hook_slow+0x48/0x124
[  176.303803]  __br_forward+0xc4/0x194 [bridge]
[  176.304013]  br_flood+0xd4/0x168 [bridge]
[  176.304300]  br_handle_frame_finish+0x1d4/0x5c4 [bridge]
[  176.304536]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.304978]  br_nf_pre_routing_finish+0x29c/0x494 [br_netfilter]
[  176.305188]  br_nf_pre_routing+0x250/0x524 [br_netfilter]
[  176.305428]  br_handle_frame+0x244/0x3cc [bridge]
[  176.305695]  __netif_receive_skb_core.constprop.0+0x33c/0xecc
[  176.306080]  __netif_receive_skb_one_core+0x40/0x8c
[  176.306197]  __netif_receive_skb+0x18/0x64
[  176.306369]  process_backlog+0x80/0x124
[  176.306540]  __napi_poll+0x38/0x17c
[  176.306636]  net_rx_action+0x124/0x26c
[  176.306758]  __do_softirq+0x100/0x26c
[  176.307051]  ____do_softirq+0x10/0x1c
[  176.307162]  call_on_irq_stack+0x24/0x4c
[  176.307289]  do_softirq_own_stack+0x1c/0x2c
[  176.307396]  do_softirq+0x54/0x6c
[  176.307485]  __local_bh_enable_ip+0x8c/0x98
[  176.307637]  __dev_queue_xmit+0x22c/0xd28
[  176.307775]  neigh_resolve_output+0xf4/0x1a0
[  176.308018]  ip_finish_output2+0x1c8/0x628
[  176.308137]  ip_do_fragment+0x5b4/0x658
[  176.308279]  ip_fragment.constprop.0+0x48/0xec
[  176.308420]  __ip_finish_output+0xa4/0x254
[  176.308593]  ip_finish_output+0x34/0x130
[  176.308814]  ip_output+0x6c/0x108
[  176.308929]  ip_send_skb+0x50/0xf0
[  176.309095]  ip_push_pending_frames+0x30/0x54
[  176.309254]  raw_sendmsg+0x758/0xaec
[  176.309568]  inet_sendmsg+0x44/0x70
[  176.309667]  __sys_sendto+0x110/0x178
[  176.309758]  __arm64_sys_sendto+0x28/0x38
[  176.309918]  invoke_syscall+0x48/0x110
[  176.310211]  el0_svc_common.constprop.0+0x40/0xe0
[  176.310353]  do_el0_svc+0x1c/0x28
[  176.310434]  el0_svc+0x34/0xb4
[  176.310551]  el0t_64_sync_handler+0x120/0x12c
[  176.310690]  el0t_64_sync+0x190/0x194
[  176.311066] Code: f9402e61 79402aa2 927ff821 f9400023 (f9408860)
[  176.315743] ---[ end trace 0000000000000000 ]---
[  176.316060] Kernel panic - not syncing: Oops: Fatal exception in
interrupt
[  176.316371] Kernel Offset: 0x37e0e3000000 from 0xffff800080000000
[  176.316564] PHYS_OFFSET: 0xffff97d780000000
[  176.316782] CPU features: 0x0,88000203,3c020000,0100421b
[  176.317210] Memory Limit: none
[  176.317527] ---[ end Kernel panic - not syncing: Oops: Fatal
Exception in interrupt ]---\
====================

Link: https://patch.msgid.link/20241001154400.22787-1-aroulin@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:54:57 -07:00
Andy Roulin
bc4d22b72a selftests: add regression test for br_netfilter panic
Add a new netfilter selftests to test against br_netfilter panics when
VxLAN single-device is used together with untagged traffic and high MTU.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20241001154400.22787-3-aroulin@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:54:52 -07:00
Andy Roulin
f9ff7665cd netfilter: br_netfilter: fix panic with metadata_dst skb
Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.

It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded

When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.

Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.

The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst->dev, thus the crash.

This case was never supported in the first place, so drop the packet
instead.

PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[  176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[  176.292101] Mem abort info:
[  176.292184]   ESR = 0x0000000096000004
[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
[  176.292530]   SET = 0, FnV = 0
[  176.292709]   EA = 0, S1PTW = 0
[  176.292862]   FSC = 0x04: level 0 translation fault
[  176.293013] Data abort info:
[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[  176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[  176.296314] Hardware name: linux,dummy-virt (DT)
[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[  176.297636] sp : ffff800080003630
[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[  176.300889] Call trace:
[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[  176.301703]  nf_hook_slow+0x48/0x124
[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[  176.303359]  nf_hook_slow+0x48/0x124
[  176.303803]  __br_forward+0xc4/0x194 [bridge]
[  176.304013]  br_flood+0xd4/0x168 [bridge]
[  176.304300]  br_handle_frame_finish+0x1d4/0x5c4 [bridge]
[  176.304536]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.304978]  br_nf_pre_routing_finish+0x29c/0x494 [br_netfilter]
[  176.305188]  br_nf_pre_routing+0x250/0x524 [br_netfilter]
[  176.305428]  br_handle_frame+0x244/0x3cc [bridge]
[  176.305695]  __netif_receive_skb_core.constprop.0+0x33c/0xecc
[  176.306080]  __netif_receive_skb_one_core+0x40/0x8c
[  176.306197]  __netif_receive_skb+0x18/0x64
[  176.306369]  process_backlog+0x80/0x124
[  176.306540]  __napi_poll+0x38/0x17c
[  176.306636]  net_rx_action+0x124/0x26c
[  176.306758]  __do_softirq+0x100/0x26c
[  176.307051]  ____do_softirq+0x10/0x1c
[  176.307162]  call_on_irq_stack+0x24/0x4c
[  176.307289]  do_softirq_own_stack+0x1c/0x2c
[  176.307396]  do_softirq+0x54/0x6c
[  176.307485]  __local_bh_enable_ip+0x8c/0x98
[  176.307637]  __dev_queue_xmit+0x22c/0xd28
[  176.307775]  neigh_resolve_output+0xf4/0x1a0
[  176.308018]  ip_finish_output2+0x1c8/0x628
[  176.308137]  ip_do_fragment+0x5b4/0x658
[  176.308279]  ip_fragment.constprop.0+0x48/0xec
[  176.308420]  __ip_finish_output+0xa4/0x254
[  176.308593]  ip_finish_output+0x34/0x130
[  176.308814]  ip_output+0x6c/0x108
[  176.308929]  ip_send_skb+0x50/0xf0
[  176.309095]  ip_push_pending_frames+0x30/0x54
[  176.309254]  raw_sendmsg+0x758/0xaec
[  176.309568]  inet_sendmsg+0x44/0x70
[  176.309667]  __sys_sendto+0x110/0x178
[  176.309758]  __arm64_sys_sendto+0x28/0x38
[  176.309918]  invoke_syscall+0x48/0x110
[  176.310211]  el0_svc_common.constprop.0+0x40/0xe0
[  176.310353]  do_el0_svc+0x1c/0x28
[  176.310434]  el0_svc+0x34/0xb4
[  176.310551]  el0t_64_sync_handler+0x120/0x12c
[  176.310690]  el0t_64_sync+0x190/0x194
[  176.311066] Code: f9402e61 79402aa2 927ff821 f9400023 (f9408860)
[  176.315743] ---[ end trace 0000000000000000 ]---
[  176.316060] Kernel panic - not syncing: Oops: Fatal exception in
interrupt
[  176.316371] Kernel Offset: 0x37e0e3000000 from 0xffff800080000000
[  176.316564] PHYS_OFFSET: 0xffff97d780000000
[  176.316782] CPU features: 0x0,88000203,3c020000,0100421b
[  176.317210] Memory Limit: none
[  176.317527] ---[ end Kernel panic - not syncing: Oops: Fatal
Exception in interrupt ]---\

Fixes: 11538d039a ("bridge: vlan dst_metadata hooks in ingress and egress paths")
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20241001154400.22787-2-aroulin@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:54:52 -07:00
Jakub Kicinski
a73f214e89 Merge branch 'add-option-to-provide-opt_id-value-via-cmsg'
Vadim Fedorenko says:

====================
Add option to provide OPT_ID value via cmsg

SOF_TIMESTAMPING_OPT_ID socket option flag gives a way to correlate TX
timestamps and packets sent via socket. Unfortunately, there is no way
to reliably predict socket timestamp ID value in case of error returned
by sendmsg. For UDP sockets it's impossible because of lockless
nature of UDP transmit, several threads may send packets in parallel. In
case of RAW sockets MSG_MORE option makes things complicated. More
details are in the conversation [1].
This patch adds new control message type to give user-space
software an opportunity to control the mapping between packets and
values by providing ID with each sendmsg.

The first patch in the series adds all needed definitions and implements
the function for UDP sockets. The explicit check of socket's type is not
added because subsequent patches in the series will add support for other
types of sockets. The documentation is also included into the first
patch.

Patch 2/4 adds support for TCP sockets. This part is simple and straight
forward.

Patch 3/4 adds support for RAW sockets. It's a bit tricky because
sock_tx_timestamp functions has to be refactored to receive full socket
cookie information to fill in ID. The commit b534dc46c8 ("net_tstamp:
add SOF_TIMESTAMPING_OPT_ID_TCP") did the conversion of sk_tsflags to
u32 but sock_tx_timestamp functions were not converted and still receive
16b flags. It wasn't a problem because SOF_TIMESTAMPING_OPT_ID_TCP was
not checked in these functions, that's why no backporting is needed.

Patch 4/4 adds selftests for new feature.

[1] https://lore.kernel.org/netdev/CALCETrU0jB+kg0mhV6A8mrHfTE1D1pr1SD_B9Eaa9aDPfgHdtA@mail.gmail.com/
====================

Link: https://patch.msgid.link/20241001125716.2832769-1-vadfed@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:52:23 -07:00
Vadim Fedorenko
a89568e9be selftests: txtimestamp: add SCM_TS_OPT_ID test
Extend txtimestamp test to run with fixed tskey using
SCM_TS_OPT_ID control message for all types of sockets.

Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
Link: https://patch.msgid.link/20241001125716.2832769-4-vadfed@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:52:20 -07:00
Vadim Fedorenko
822b5bc6db net_tstamp: add SCM_TS_OPT_ID for RAW sockets
The last type of sockets which supports SOF_TIMESTAMPING_OPT_ID is RAW
sockets. To add new option this patch converts all callers (direct and
indirect) of _sock_tx_timestamp to provide sockcm_cookie instead of
tsflags. And while here fix __sock_tx_timestamp to receive tsflags as
__u32 instead of __u16.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
Link: https://patch.msgid.link/20241001125716.2832769-3-vadfed@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:52:19 -07:00
Vadim Fedorenko
4aecca4c76 net_tstamp: add SCM_TS_OPT_ID to provide OPT_ID in control message
SOF_TIMESTAMPING_OPT_ID socket option flag gives a way to correlate TX
timestamps and packets sent via socket. Unfortunately, there is no way
to reliably predict socket timestamp ID value in case of error returned
by sendmsg. For UDP sockets it's impossible because of lockless
nature of UDP transmit, several threads may send packets in parallel. In
case of RAW sockets MSG_MORE option makes things complicated. More
details are in the conversation [1].
This patch adds new control message type to give user-space
software an opportunity to control the mapping between packets and
values by providing ID with each sendmsg for UDP sockets.
The documentation is also added in this patch.

[1] https://lore.kernel.org/netdev/CALCETrU0jB+kg0mhV6A8mrHfTE1D1pr1SD_B9Eaa9aDPfgHdtA@mail.gmail.com/

Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
Link: https://patch.msgid.link/20241001125716.2832769-2-vadfed@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:52:19 -07:00
Mike Snitzer
76f5af9952 nfsd/localio: fix nfsd_file tracepoints to handle NULL rqstp
Otherwise nfsd_file_acquire, nfsd_file_insert_err, and
nfsd_file_cons_err will hit a NULL pointer when they are enabled and
LOCALIO used.

Example trace output (note xid is 0x0 and LOCALIO flag set):
 nfsd_file_acquire: xid=0x0 inode=0000000069a1b2e7
 may_flags=WRITE|LOCALIO ref=1 nf_flags=HASHED|GC nf_may=WRITE
 nf_file=0000000070123234 status=0

Fixes: c63f0e48fe ("nfsd: add nfsd_file_acquire_local()")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
2024-10-04 14:52:04 -04:00
Linus Torvalds
cc70ce8fcc gpio fixes for v6.12-rc2
- fix a potential NULL-pointer dereference in gpiolib core
 - fix a probe() regression from the v6.12 merge window and an older bug
   leading to missed interrupts in gpio-davinci
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmb/+PwACgkQEacuoBRx
 13KLAg//e5/DUfObPKOLR+8Oox1aZmR76L5bUU301u+bQsMykqzK2dd10c9z1JJM
 2Uax0Ye0+tLVYCsVulhuhiYGp5v+6j7aiKg54PIBSXDTTjDQWYh02LilKFXaZga4
 //t0SyZQ4RlU+smasitPh41y71IUmuCiVazTkW/oHfrNdD5fv101PTLJQ53lgV+9
 nHWelUa4e30gXv7ruIa2KafW3opH0PG25eB1IFpUbwklB1Qhd+eu68lcjoVfiYOW
 roNhE9Mgkn2fkKyigOqSqF8GsCIgoAS1Yxaf7OQwGD5Zgla9AoP27N2S8EL9yJA9
 QqczFxioCBny66VggXe7HktqkzGwNvDVDOGhB1xGC7etoIxz+TniACj9yX2LXe3P
 lA3/5tuuXN9SNk5tmcLkZmNWkAu64rK5YbKFV9aqY/cnz6e0R2kycjNivFYI843N
 69hSl7NZe6JJOOvUfzC+RD+8TV6vXQ+uBqx0sYloyj6zW3k6+hUeLbIeeL1IxZY2
 sKNZc9XSQ0RuqZZEpVcv3wdG/g3PMWXDMmkBCPqIoaz5N/EcpUNR8DXEteJKDbX2
 O2THrAJGSgFhe1pPBYwbJ3p1/BXQKIljDcEj22DdzDEnYyHFqD/zEpMj2WDrduLE
 ZTHrIEPenr+EQD5SYUPDEWHWjKQHE3aWnBhWDSBoccYQf743J8Q=
 =JlY/
 -----END PGP SIGNATURE-----

Merge tag 'gpio-fixes-for-v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull gpio fixes from Bartosz Golaszewski:

 - fix a potential NULL-pointer dereference in gpiolib core

 - fix a probe() regression from the v6.12 merge window and an older bug
   leading to missed interrupts in gpio-davinci

* tag 'gpio-fixes-for-v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()
  gpio: davinci: Fix condition for irqchip registration
  gpio: davinci: fix lazy disable
2024-10-04 11:50:38 -07:00
Jakub Kicinski
34ea1df802 Merge branch 'net-mlx5-hw-counters-refactor'
Tariq Toukan says:

====================
net/mlx5: hw counters refactor

This is a patchset re-post, see:
https://lore.kernel.org/20240815054656.2210494-7-tariqt@nvidia.com

In this patchset, Cosmin refactors hw counters and solves perf scaling
issue.

Series generated against:
commit c824deb1a8 ("cxgb4: clip_tbl: Fix spelling mistake "wont" -> "won't"")

HW counters are central to mlx5 driver operations. They are hardware
objects created and used alongside most steering operations, and queried
from a variety of places. Most counters are queried in bulk from a
periodic task in fs_counters.c.

Counter performance is important and as such, a variety of improvements
have been done over the years. Currently, counters are allocated from
pools, which are bulk allocated to amortize the cost of firmware
commands. Counters are managed through an IDR, a doubly linked list and
two atomic single linked lists. Adding/removing counters is a complex
dance between user contexts requesting it and the mlx5_fc_stats_work
task which does most of the work.

Under high load (e.g. from connection tracking flow insertion/deletion),
the counter code becomes a bottleneck, as seen on flame graphs. Whenever
a counter is deleted, it gets added to a list and the wq task is
scheduled to run immediately to actually delete it. This is done via
mod_delayed_work which uses an internal spinlock. In some tests, waiting
for this spinlock took up to 66% of all samples.

This series refactors the counter code to use a more straight-forward
approach, avoiding the mod_delayed_work problem and making the code
easier to understand. For that:

- patch #1 moves counters data structs to a more appropriate place.
- patch #2 simplifies the bulk query allocation scheme by using vmalloc.
- patch #3 replaces the IDR+3 lists with an xarray. This is the main
  patch of the series, solving the spinlock congestion issue.
- patch #4 removes an unnecessary cacheline alignment causing a lot of
  memory to be wasted.
- patches #5 and #6 are small cleanups enabled by the refactoring.
====================

Link: https://patch.msgid.link/20241001103709.58127-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:48 -07:00
Cosmin Ratiu
d1c9cffe4b net/mlx5: hw counters: Remove mlx5_fc_create_ex
It no longer serves any purpose and is identical to mlx5_fc_create upon
which it was originally based of.

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-7-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:47 -07:00
Cosmin Ratiu
4a67ebf85f net/mlx5: hw counters: Don't maintain a counter count
num_counters is only used for deciding whether to grow the bulk query
buffer, which is done once more counters than a small initial threshold
are present. After that, maintaining num_counters serves no purpose.

This commit replaces that with an actual xarray traversal to count the
counters. This appears expensive at first sight, but is only done when
the number of counters is less than the initial threshold (8) and only
once every sampling interval. Once the number of counters goes above the
threshold, the bulk query buffer is grown to max size and the xarray
traversal is never done again.

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-6-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:46 -07:00
Cosmin Ratiu
d95f77f119 net/mlx5: hw counters: Drop unneeded cacheline alignment
The mlx5_fc struct has a cache for values queried from hw, which is
cacheline aligned. On x86_64, this results in:

struct mlx5_fc {
        u32                    id;                   /*     0     4 */
        bool                   aging;                /*     4     1 */

        /* XXX 3 bytes hole, try to pack */

        struct mlx5_fc_bulk *  bulk;                 /*     8     8 */

        /* XXX 48 bytes hole, try to pack */

        /* --- cacheline 1 boundary (64 bytes) --- */
        struct mlx5_fc_cache   cache __attribute__((__aligned__(64)));
	/*    64    24 */
        u64                    lastpackets;          /*    88     8 */
        u64                    lastbytes;            /*    96     8 */

        /* size: 128, cachelines: 2, members: 6 */
        /* sum members: 53, holes: 2, sum holes: 51 */
        /* padding: 24 */
        /* forced aligns: 1, forced holes: 1, sum forced holes: 48 */
} __attribute__((__aligned__(64)));

(output from pahole).

...So a 48+24=72 byte waste. As far as I can determine, this serves no
purpose other than maybe making sure that the values in the cache do not
span two cachelines in the worst case scenario, but that's not a valid
enough reason to waste 72 bytes per counter, especially since this code
is not performance-critical. There could potentially be hundreds of
thousands of counters (e.g. for connection-tracking), so this quickly
adds up to multiple MB wasted.

This commit removes the alignment, resulting in:
struct mlx5_fc {
        [...]
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 53, holes: 1, sum holes: 3 */
        /* last cacheline: 56 bytes */
};

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-5-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:46 -07:00
Cosmin Ratiu
918af0219a net/mlx5: hw counters: Replace IDR+lists with xarray
Previously, managing counters was a complicated affair involving an IDR,
a sorted double linked list, two single linked lists and a complex dance
between a non-periodic wq task and users adding/deleting counters.

Adding was done by inserting new counters into the IDR and into a single
linked list, leaving the wq to process the list and actually add the
counters into the double linked list, maintained sorted with the IDR.

Deleting involved adding the counter into another single linked list,
leaving the wq to actually unlink the counter from the other structures
and release it.

Dumping the counters is done with the bulk query API, which relies on
the counter list being sorted and unmutable during querying to
efficiently retrieve cached counter values.

Finally, the IDR data struct is deprecated.

This commit replaces all of that with an xarray.

Adding is now done directly, by using xa_lock.
Deleting is also done directly, under the xa_lock.

Querying is done from a periodic task running every sampling_interval
(default 1s) and uses the bulk query API for efficiency.
It works by iterating over the xarray:
- when a new bulk needs to be started, the bulk information is computed
  under the xa_lock.
- the xa iteration state is saved and the xa_lock dropped.
- the HW is queried for bulk counter values.
- the xa_lock is reacquired.
- counter caches with ids covered by the bulk response are updated.

Querying always requests the max bulk length, for simplicity.

Counters could be added/deleted while the HW is queried. This is safe,
as the HW API simply returns unknown values for counters not in HW, but
those values won't be accessed. Only counters present in xarray before
bulk query will actually read queried cache values.

This cuts down the size of mlx5_fc by 4 pointers (88->56 bytes), which
amounts to ~3MB / 100K counters.
But more importantly, this solves the wq spinlock congestion issue seen
happening on high-rate counter insertion+deletion.

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-4-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:46 -07:00
Cosmin Ratiu
10cd92df83 net/mlx5: hw counters: Use kvmalloc for bulk query buffer
The bulk query buffer starts out small (see [1]) and as soon as the
number of counters goes past the initial threshold grows to max
size (32K entries, 512KB) with a retry scheme.

This commit switches to using kvmalloc for the buffer, which has a near
zero likelihood of failing, and thus the explicit retry scheme becomes
superfluous and is taken out. On the low chance the allocation fails, it
will still be retried every sampling_interval, when the wq task runs.

[1] commit b247f32aec ("net/mlx5: Dynamically resize flow counters
query buffer")

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:46 -07:00
Cosmin Ratiu
5acd957a98 net/mlx5: hw counters: Make fc_stats & fc_pool private
The mlx5_fc_stats and mlx5_fc_pool structs are only used from
fs_counters.c. As such, make them private there.

mlx5_fc_pool is not used or referenced at all outside fs_counters.

mlx5_fc_stats is referenced from mlx5_core_dev, so instead of having it
as a direct member (which requires exporting it from fs_counters), store
a pointer to it, allocate it on init and clear it on destroy.
One caveat is that a simple container_of to get from a 'work' struct to
the outermost mlx5_core_dev struct directly no longer works, so an extra
pointer had to be added to mlx5_fc_stats back to the parent dev.

Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20241001103709.58127-2-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:33:46 -07:00
Linus Torvalds
2f91ff27b0 sound fixes for 6.12-rc2
Slightly high amount of changes in this round, partly because of my
 vacation in the last weeks.  But all changes are small and nothing
 looks worrisome.
 
 The biggest LOCs is MAINTAINERS updates, and there is a core change
 for card-ID string creation for non-ASCII inputs.  Others are rather
 device-specific, such as new quirks and device IDs for ASoC, usual
 HD-audio and USB-audio quirks and fixes, as well as regression fixes
 in HD-audio HDMI audio and Conexant codec.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmb/sxIOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE8UyQ/7Bv69vQ0mqUffm3cLczGLxopWJmVFXfYF4EHW
 XWPjpupiQfzQGmD1bTVj8UPRUb3ECjHZdJlunVOgJMkHZRfm7pwjYUDaDbazu50O
 i1ZL6+MAI025fIgIAyk2fsvBs9lQlPZx8kB54v4OGM2j8xXRfchSVkAHSuFT0jFG
 qyD7Cy9AMWLrtk92l6L+Nn+1mIpnADOo27ePaz5SIg9JBvdDd4n0lEcUCgY1xZKL
 am+cLeRRJqpsyJtBOjEhNT/87kcjpRiJG9Cm+CQ94jo+1KEvXavSTL1Hpe7P6RVJ
 hKelo10ZUhBw0jYHxkzWSOV0hU91ReS6niW2VTca2JUdcC7MhXtkvvMnliZnUUtA
 uBHWh03jSbz12wImdcMxkYlbNgNlia0KDJ4i6CHacdsoTeN+oTlNo278cc6uTqz9
 1N2B3k2F2BZT/lg6241JK9i1x0V/7Euzt+WV7Zuxt4KNbRQcG0xWH1PgLjtU/5Ed
 T3r2gSLUhfONWfoJWlBiHDTIVWdgHk+/pfAiHivL97/aXVzZ2Yfje4mYtyT124ih
 AXW7fVF0OFS5z5UWMpyK3k9RIwnd0otT0lRt5UZ1lnZbGcOU8lRneA4PH6zWE91+
 VbkbqUhPUDZmwe2mzieLlkSUfIIzX0B/LfY6YulxnZ45eFZyE9G2Zy3KKQM8Hzvs
 eFCOBAw=
 =RpGO
 -----END PGP SIGNATURE-----

Merge tag 'sound-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Slightly high amount of changes in this round, partly because of my
  vacation in the last weeks. But all changes are small and nothing
  looks worrisome.

  The biggest LOCs is MAINTAINERS updates, and there is a core change
  for card-ID string creation for non-ASCII inputs. Others are rather
  device-specific, such as new quirks and device IDs for ASoC, usual
  HD-audio and USB-audio quirks and fixes, as well as regression fixes
  in HD-audio HDMI audio and Conexant codec"

* tag 'sound-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (39 commits)
  ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin
  ALSA: line6: add hw monitor volume control to POD HD500X
  ALSA: gus: Fix some error handling paths related to get_bpos() usage
  ALSA: hda: Add missing parameter description for snd_hdac_stream_timecounter_init()
  ALSA: usb-audio: Add native DSD support for Luxman D-08u
  ALSA: core: add isascii() check to card ID generator
  MAINTAINERS: ALSA: use linux-sound@vger.kernel.org list
  Revert "ALSA: hda: Conditionally use snooping for AMD HDMI"
  ASoC: intel: sof_sdw: Add check devm_kasprintf() returned value
  ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m
  ASoC: dt-bindings: davinci-mcasp: Fix interrupts property
  ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string
  ASoC: dt-bindings: qcom,sm8250: add qrb4210-rb2-sndcard
  ALSA: hda: fix trigger_tstamp_latched
  ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200
  ALSA: hda/generic: Drop obsoleted obey_preferred_dacs flag
  ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs
  ALSA: silence integer wrapping warning
  ASoC: Intel: soc-acpi: arl: Fix some missing empty terminators
  ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item
  ...
2024-10-04 11:29:46 -07:00
Linus Torvalds
fe6fceceae drm fixes for 6.12-rc2
atomic:
 - Use correct type when reading damage rectangles
 
 display:
 - Fix kernel docs
 
 dp-mst:
 - Fix DSC decompression detection
 
 hdmi:
 - Fix infoframe size
 
 sched:
 - Update maintainers
 - Fix race condition whne queueing up jobs
 - Fix locking in drm_sched_entity_modify_sched()
 - Fix pointer deref if entity queue changes
 
 sysfb:
 - Disable sysfb if framebuffer parent device is unknown
 
 amdgpu:
 - DML2 fix
 - DSC fix
 - Dispclk fix
 - eDP HDR fix
 - IPS fix
 - TBT fix
 
 i915:
 - One fix for bitwise and logical "and" mixup in PM code
 
 xe:
 - Restore pci state on resume
 - Fix locking on submission, queue and vm
 - Fix UAF on queue destruction
 - Fix resource release on freq init error path
 - Use rw_semaphore to reduce contention on ASID->VM lookup
 - Fix steering for media on Xe2_HPM
 - Tuning updates to Xe2
 - Resume TDR after GT reset to prevent jobs running forever
 - Move id allocation to avoid userspace using a guessed number
   to trigger UAF
 - Fix OA stream close preventing pbatch buffers to complete
 - Fix NPD when migrating memory on LNL
 - Fix memory leak when aborting binds
 
 panthor:
 - Fix locking
 - Set FOP_UNSIGNED_OFFSET in fops instance
 - Acquire lock in panthor_vm_prepare_map_op_ctx()
 - Avoid uninitialized variable in tick_ctx_cleanup()
 - Do not block scheduler queue if work is pending
 - Do not add write fences to the shared BOs
 
 vbox:
 - Fix VLA handling
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmb/YwgACgkQDHTzWXnE
 hr6VbxAAoq9FYTAdRPWzfG1HYpG96UyTh+IT6lz1bk/Hblxhi7oRdfmRy/bVPQYh
 vj+Q2xrnyS6JYhyfeDT2nU75tD3gvR1V/qSamxXS7c1nrqcb431DaMzuSQ5ST6MZ
 jrmob2TxlbXDDw70dxtiGCmSu0a9QInbelEamJQySKOdun0Il5C0LRZIBMpicDGc
 7Y3eSpCIwgTSU6bnApGyOchppvzptiqBWGmhoIuACMOgXI8eaLUPqbROKEHlPe5g
 JIG603rRK7cf+on/KEwvgrd2ZO59fJZvmwFrM5yY5bOsDCwTIJ6mHhOmutUNQvmd
 G5n6ZFnVxlBRSVWCAqPRBgA405s/0wi2IQprilaPCu2qAXToBXAUpIHuuat5I/8b
 BVwurVRAGV/GSeg7E51H3o8cu/fcQr4aGNW4Ul6fS1G123ZuUISpcUp9IEnqG7nB
 5PSnHapadb5Pu+7kwhbWUD4kONp16oEacZPhymlN+74Q6X3v8UVlK/YSyD6wq4fj
 2s4TBWUmXmNxztNEkgJhyJORYQhZeBaD0PtPq8kSzMUCFj3Q7Wf0bAODhbnmdCw1
 iPgxRd9+38IpfW621AROJUoTcyCaLtlSUvHWgFfska5CYnbtbKuNPBW6baQxeEHe
 Rhns01dZhNTIbKNEw37cfOf2DqcjpmRm4cVJj4xjZawxWYlNldk=
 =wcmz
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2024-10-04' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "Weekly fixes, xe and amdgpu lead the way, with panthor, and few core
  components getting various fixes. Nothing seems too out of the
  ordinary.

  atomic:
   - Use correct type when reading damage rectangles

  display:
   - Fix kernel docs

  dp-mst:
   - Fix DSC decompression detection

  hdmi:
   - Fix infoframe size

  sched:
   - Update maintainers
   - Fix race condition whne queueing up jobs
   - Fix locking in drm_sched_entity_modify_sched()
   - Fix pointer deref if entity queue changes

  sysfb:
   - Disable sysfb if framebuffer parent device is unknown

  amdgpu:
   - DML2 fix
   - DSC fix
   - Dispclk fix
   - eDP HDR fix
   - IPS fix
   - TBT fix

  i915:
   - One fix for bitwise and logical "and" mixup in PM code

  xe:
   - Restore pci state on resume
   - Fix locking on submission, queue and vm
   - Fix UAF on queue destruction
   - Fix resource release on freq init error path
   - Use rw_semaphore to reduce contention on ASID->VM lookup
   - Fix steering for media on Xe2_HPM
   - Tuning updates to Xe2
   - Resume TDR after GT reset to prevent jobs running forever
   - Move id allocation to avoid userspace using a guessed number to
     trigger UAF
   - Fix OA stream close preventing pbatch buffers to complete
   - Fix NPD when migrating memory on LNL
   - Fix memory leak when aborting binds

  panthor:
   - Fix locking
   - Set FOP_UNSIGNED_OFFSET in fops instance
   - Acquire lock in panthor_vm_prepare_map_op_ctx()
   - Avoid uninitialized variable in tick_ctx_cleanup()
   - Do not block scheduler queue if work is pending
   - Do not add write fences to the shared BOs

  vbox:
   - Fix VLA handling"

* tag 'drm-fixes-2024-10-04' of https://gitlab.freedesktop.org/drm/kernel: (41 commits)
  drm/xe: Fix memory leak when aborting binds
  drm/xe: Prevent null pointer access in xe_migrate_copy
  drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close
  drm/xe/queue: move xa_alloc to prevent UAF
  drm/xe/vm: move xa_alloc to prevent UAF
  drm/xe: Clean up VM / exec queue file lock usage.
  drm/xe: Resume TDR after GT reset
  drm/xe/xe2: Add performance tuning for L3 cache flushing
  drm/xe/xe2: Extend performance tuning to media GT
  drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM
  drm/xe: Use helper for ASID -> VM in GPU faults and access counters
  drm/xe: Convert to USM lock to rwsem
  drm/xe: use devm_add_action_or_reset() helper
  drm/xe: fix UAF around queue destruction
  drm/xe/guc_submit: add missing locking in wedged_fini
  drm/xe: Restore pci state upon resume
  drm/amd/display: Fix system hang while resume with TBT monitor
  drm/amd/display: Enable idle workqueue for more IPS modes
  drm/amd/display: Add HDR workaround for specific eDP
  drm/amd/display: avoid set dispclk to 0
  ...
2024-10-04 11:25:14 -07:00
Vladimir Oltean
1f9fc48fd3 net: dsa: sja1105: fix reception from VLAN-unaware bridges
The blamed commit introduced an unexpected regression in the sja1105
driver. Packets from VLAN-unaware bridge ports get received correctly,
but the protocol stack can't seem to decode them properly.

For ds->untag_bridge_pvid users (thus also sja1105), the blamed commit
did introduce a functional change: dsa_switch_rcv() used to call
dsa_untag_bridge_pvid(), which looked like this:

	err = br_vlan_get_proto(br, &proto);
	if (err)
		return skb;

	/* Move VLAN tag from data to hwaccel */
	if (!skb_vlan_tag_present(skb) && skb->protocol == htons(proto)) {
		skb = skb_vlan_untag(skb);
		if (!skb)
			return NULL;
	}

and now it calls dsa_software_vlan_untag() which has just this:

	/* Move VLAN tag from data to hwaccel */
	if (!skb_vlan_tag_present(skb)) {
		skb = skb_vlan_untag(skb);
		if (!skb)
			return NULL;
	}

thus lacks any skb->protocol == bridge VLAN protocol check. That check
is deferred until a later check for skb->vlan_proto (in the hwaccel area).

The new code is problematic because, for VLAN-untagged packets,
skb_vlan_untag() blindly takes the 4 bytes starting with the EtherType
and turns them into a hwaccel VLAN tag. This is what breaks the protocol
stack.

It would be tempting to "make it work as before" and only call
skb_vlan_untag() for those packets with the skb->protocol actually
representing a VLAN.

But the premise of the newly introduced dsa_software_vlan_untag() core
function is not wrong. Drivers set ds->untag_bridge_pvid or
ds->untag_vlan_aware_bridge_pvid presumably because they send all
traffic to the CPU reception path as VLAN-tagged. So why should we spend
any additional CPU cycles assuming that the packet may be VLAN-untagged?
And why does the sja1105 driver opt into ds->untag_bridge_pvid if it
doesn't always deliver packets to the CPU as VLAN-tagged?

The answer to the latter question is indeed more interesting: it doesn't
need to. This got done in commit 884be12f85 ("net: dsa: sja1105: add
support for imprecise RX"), because I thought it would be needed, but I
didn't realize that it doesn't actually make a difference.

As explained in the commit message of the blamed patch, ds->untag_bridge_pvid
only makes a difference in the VLAN-untagged receive path of a bridge port.
However, in that operating mode, tag_sja1105.c makes use of VLAN tags
with the ETH_P_SJA1105 TPID, and it decodes and consumes these VLAN tags
as if they were DSA tags (aka tag_8021q operation). Even if commit
884be12f85 ("net: dsa: sja1105: add support for imprecise RX") added
this logic in sja1105_bridge_vlan_add():

	/* Always install bridge VLANs as egress-tagged on the CPU port. */
	if (dsa_is_cpu_port(ds, port))
		flags = 0;

that was for _bridge_ VLANs, which are _not_ committed to hardware
in VLAN-unaware mode (aka the mode where ds->untag_bridge_pvid does
anything at all). Even prior to that change, the tag_8021q VLANs
were always installed as egress-tagged on the CPU port, see
dsa_switch_tag_8021q_vlan_add():

	u16 flags = 0; // egress-tagged, non-PVID

	if (dsa_port_is_user(dp))
		flags |= BRIDGE_VLAN_INFO_UNTAGGED |
			 BRIDGE_VLAN_INFO_PVID;

	err = dsa_port_do_tag_8021q_vlan_add(dp, info->vid,
					     flags);
	if (err)
		return err;

Whether the sja1105 driver needs the new flag, ds->untag_vlan_aware_bridge_pvid,
rather than ds->untag_bridge_pvid, is a separate discussion. To fix the
current bug in VLAN-unaware bridge mode, I would argue that the sja1105
driver should not request something it doesn't need, rather than
complicating the core DSA helper. Whereas before the blamed commit, this
setting was harmless, now it has caused breakage.

Fixes: 93e4649efa ("net: dsa: provide a software untagging function on RX for VLAN-aware bridges")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20241001140206.50933-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:19:50 -07:00
Riyan Dhiman
c55ff46aee octeontx2-af: Change block parameter to const pointer in get_lf_str_list
Convert struct rvu_block block to const struct rvu_block *block in
get_lf_str_list() function parameter. This improves efficiency by
avoiding structure copying and reflects the function's read-only
access to block.

Signed-off-by: Riyan Dhiman <riyandhiman14@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241001110542.5404-2-riyandhiman14@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:12:28 -07:00
Aleksander Jan Bajkowski
8389cdb5c1 net: macb: Adding support for Jumbo Frames up to 10240 Bytes in SAMA5D2
As per the SAMA5D2 device specification it supports Jumbo frames.
But the suggested flag and length of bytes it supports was not updated
in this driver config_structure.
The maximum jumbo frames the device supports:
10240 bytes as per the device spec.

While changing the MTU value greater than 1500, it threw error:
sudo ifconfig eth1 mtu 9000
SIOCSIFMTU: Invalid argument

Add this support to driver so that it works as expected and designed.

Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://patch.msgid.link/20241003171941.8814-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-04 11:11:12 -07:00
Linus Torvalds
360c1f1f24 block-6.12-20241004
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmcAA+4QHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgprKuD/99KWHNFwDyhwPVRlK8ZiCo556DWJ9sT6aJ
 ICt0MAehx2KUgjQTcOoAE0gPAd2ASJA+hisvY5yiMtXNvOgyYXcUfH+UqYoFWSO8
 O7vm7/w/YK3jvuwRwTDSH2s3+L/j3oROHZQSZVAkoi9KcbAaPt5FbFbpqWmAuBgJ
 ymsGWybW27GSOCDh55Jnm4IDaHMUfpcsvEg8Ryl6DyD2C0ZkMy64DmGiopUKCyML
 ceeiVUboNzWYg9qeZswKm1OVSSzZWocy4zDbJYjueVPmr7juvQ4ILxHDqKhTOZpO
 JHBnI1c3i6pOyZqtyaU3Eb/I0b3ZebwFhY3p1+CxkW1FIatrML86/b0ZIxowEiJO
 a8tRHkk2fXaTyuaxTPlkaE9P5cIK/BpEvxn/v8mddVPTwjAAAULINfZAYoGhwWyF
 cSQuN+BOJnxU6DUp66OVKlxhLiZAttBy+kyCPaLUVLyJX7w/VaQz2PwQjzHybjy7
 zNz7M4x4/06bFC3ykmLgIRM+Hqo+El0SE6wx/GHi70GuC+cqkHnfUL4Yscj1t6SD
 Uadul3PYaxVBZ7lcdHy09iD8JxdF1wYxyqiGULi7DPyUqBJ2r4e/TH2x2MxZ3sKA
 CEWBVHZ8yNdfckhybLArbdkQYd+GaiFna/ySUvMjrAdF2Hes42uo9eF4L5tAFtxq
 pKg3IPp0oA==
 =ujN7
 -----END PGP SIGNATURE-----

Merge tag 'block-6.12-20241004' of git://git.kernel.dk/linux

Pull block fixes from Jens Axboe:

 - Fix another use-after-free in aoe

 - Fixup wrong nested non-saving irq disable/restore in blk-iocost

 - Fixup a kerneldoc complaint introduced by a merge window patch

* tag 'block-6.12-20241004' of git://git.kernel.dk/linux:
  aoe: fix the potential use-after-free problem in more places
  blk_iocost: remove some duplicate irq disable/enables
  block: fix blk_rq_map_integrity_sg kernel-doc
2024-10-04 10:43:44 -07:00
Eder Zulian
3a546a67a4 rtla: use the definition for stdout fd when calling isatty()
Use the STDOUT_FILENO definition when testing whether the standard
output file descriptor refers to a terminal (for better redability).

Link: https://lore.kernel.org/20240813142338.376039-1-ezulian@redhat.com
Signed-off-by: Eder Zulian <ezulian@redhat.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-10-04 13:42:22 -04:00
Linus Torvalds
43454e8391 io_uring-6.12-20241004
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmcAA94QHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgpt6sD/41WkjlY9R/ezyaMHEXEcLfQyioZRMP53o0
 aYUkS6bEsca5yPsp0Z/Y3ewCtZIol7aGMwleF/we6d7XkcTQaRWO20wPSxwmHEaG
 r+5DvBz+yHpXBVaniZIzz49kP72pHdUxtgqZi2fRv2xC2rqPvZGrjozV370wd2oS
 hc+UVtXe8d3nYnQ8QLvDLoFJ8D2fP/wpBNHlQP6YTXpgjNXTu+siwV7hpIXPD13G
 gka0qCCyGDWB8+jpB5MaodLkl/Sj0xC3ZMBzC1B2u8uCLKGHL1mDEI7uvF6jSY9h
 fvt+Le0Y7knIVZY9Xhq5PzHHdCjzbTArNKW8CwO2a0kVfT0Z339+wPEbXCST+og8
 w0XMYlONAvTBkhK1XIm7YXOupi8yECB/lQreWzNFRrhIY9RtpirzEu/As0Gxx0Q5
 SueYqB8GNXV6buNLkKBJagN4Bvz1fyYmJhGPi6Tlvp5Ek3YKX6/3YLLwuRkjVhF1
 wERdYdhCplkdIIbCNc3a9lekQEhYFy2XkwYuIs+f31T1tk6eRV4swpU/Wtqd1yrP
 Kw82SNK+lHCxF9DXYL20IyoBQqI5fD+C7cIfVTNuM1Hgf30vl5p6VXDzoa6fMyDR
 GC1MxXjl9v/Z9xsvrD9Ek/iNiR+oWY2Reqd0ZAtZdOKmFrMR2T+p8S+h12b1I+sx
 Q5EaPdgT6Q==
 =ubMb
 -----END PGP SIGNATURE-----

Merge tag 'io_uring-6.12-20241004' of git://git.kernel.dk/linux

Pull io_uring fixes from Jens Axboe:

 - Fix an error path memory leak, if one part fails to allocate.
   Obviously not something that'll generally hit without error
   injection.

 - Fix an io_req_flags_t cast to make sparse happier.

 - Improve the recv multishot termination. Not a bug now, but could be
   one in the future. This makes it do the same thing that recvmsg does
   in terms of when to terminate a request or not.

* tag 'io_uring-6.12-20241004' of git://git.kernel.dk/linux:
  io_uring/net: harden multishot termination case for recv
  io_uring: fix casts to io_req_flags_t
  io_uring: fix memory leak when cache init fail
2024-10-04 10:39:36 -07:00
Linus Torvalds
e02f08e217 \n
-----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEEq1nRK9aeMoq1VSgcnJ2qBz9kQNkFAmb//Q8ACgkQnJ2qBz9k
 QNlBoQf8CwTW4/BTbt8Pq3RIKHYH8HFyFurwxrlnKXoB/4E4QNAfd/iDbwxqkILJ
 mbKHGVyk96St83PH5H9b2MYnwQ6PP6WEHIe7RZjxOrfrrLTSwuuOwdNR9RZbRWPd
 rLQ1/nbnLiTWPR29RLZVbhFAhDiw1hyag8YKPklEw+7SQ/wSxFUTJ8DTQ8TZYq8f
 O8SoTTJACulAP1CfoNwPlhm472JBe5jJP8WygaYeKg5wky6RPQYn8J+JSUmHs+rZ
 qNY+RuxLZ/HauXA+vBgae34G1GAdWc3sqUEU2TrGBuy/x28K/Di84+eEdQXA74sr
 +8+ACt6RRlm/w+FrjvgxJ0JUV/OAMA==
 =CoCV
 -----END PGP SIGNATURE-----

Merge tag 'fsnotify_for_v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

Pull fsnotify fixes from Jan Kara:
 "Fixes for an inotify deadlock and a data race in fsnotify"

* tag 'fsnotify_for_v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  inotify: Fix possible deadlock in fsnotify_destroy_mark
  fsnotify: Avoid data race between fsnotify_recalc_mask() and fsnotify_object_watched()
2024-10-04 10:31:59 -07:00
Linus Torvalds
4770119d63 \n
-----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEEq1nRK9aeMoq1VSgcnJ2qBz9kQNkFAmb//cYACgkQnJ2qBz9k
 QNmrxAgApRJqSQ0Koilm4Mtz+6k7CAM6MR/+JKRQLoJwl27cA4syw9REBPPdcNJP
 9Gbvlcenf8ISrtZStZehw/eyOuNvE9uBzjjmRcMc3+0esDfgFqfteDCanJ/MQDdZ
 NX3OB8pSMxwTtcf9iXJUyD/hvFIq58H378r8eOKAwI9S673r2zDZ5qGmske3S6DM
 gyMwfWepzPigKOYhwt1Frih4GmjOaD3637bSoGBfRdhT1PvAH9bJaKCFtwucNP7Y
 MG+on/JLrpPgegzbWQe2u4WTzQihkRDnEfhC+52Erdhb+Z4rv3IJUarVO2iIKzwF
 3CS7q3NyArbYN3QbvOiIKR+rORNnZg==
 =gbY2
 -----END PGP SIGNATURE-----

Merge tag 'fs_for_v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

Pull UDF fixes from Jan Kara:
 "A couple of UDF error handling fixes for issues spotted by syzbot"

* tag 'fs_for_v6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  udf: fix uninit-value use in udf_get_fileshortad
  udf: refactor inode_bmap() to handle error
  udf: refactor udf_next_aext() to handle error
  udf: refactor udf_current_aext() to handle error
2024-10-04 10:24:06 -07:00
Linus Torvalds
a3a37691e6 A fix from Patrick for a variety of CephFS lockup scenarios caused by
a regression in cap handling which sneaked in through the netfs helper
 library in 5.18 (marked for stable) and an unrelated one-line cleanup.
 -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCAAxFiEEydHwtzie9C7TfviiSn/eOAIR84sFAmcACf8THGlkcnlvbW92
 QGdtYWlsLmNvbQAKCRBKf944AhHzi3DiCACDP9ZubGLZ2GKv3fEyXEURnOyrSBAd
 M4Ci3cc31W0Q1rWtQndGxW9QF/9smcp4kN/xgelWfSZc6FJ1HLR1RHUPjMJpBPx2
 dQs+RaaBTIe0coVaMmiDnBQ1wnfuNhEZH8opnLonjHygANnoR2aYZpyIxpgYD7eZ
 KHfk1F/2rmE+QzYGB+tE7sCpRs3bhbtL2xa/2yQJyw+EWfgyJUjPW1cZe0liiWHi
 dXTMxJqfZLLUW2otLdGnaaZS+7yF3ItcoAWh6cUoiZ9cpqDu43B0RGXOV7Kegui1
 2e8W0sK3QIIYbUKoHo/4VPqrmN4puSjeNteumDvpZE4SgG8BfKWzQnmh
 =3OKU
 -----END PGP SIGNATURE-----

Merge tag 'ceph-for-6.12-rc2' of https://github.com/ceph/ceph-client

Pull ceph fixes from Ilya Dryomov:
 "A fix from Patrick for a variety of CephFS lockup scenarios caused by
  a regression in cap handling which sneaked in through the netfs helper
  library in 5.18 (marked for stable) and an unrelated one-line cleanup"

* tag 'ceph-for-6.12-rc2' of https://github.com/ceph/ceph-client:
  ceph: fix cap ref leak via netfs init_request
  ceph: use struct_size() helper in __ceph_pool_perm_get()
2024-10-04 10:10:23 -07:00
Rafael J. Wysocki
3be5c17102 Merge branches 'acpi-video' and 'acpi-battery'
Merge an ACPI backlight (video) quirk and ACPI battery driver fix and
cleanup for 6.12-rc2:

 - Add a quirk for Dell OptiPlex 5480 AIO to the ACPI backlight (video)
   driver (Hans de Goede).

 - Prevent the ACPI battery driver from crashing when unregistering a
   battery hook and simplify battery hook locking in it (Armin Wolf).

* acpi-video:
  ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO

* acpi-battery:
  ACPI: battery: Fix possible crash when unregistering a battery hook
  ACPI: battery: Simplify battery hook locking
2024-10-04 19:06:44 +02:00