| Age | Commit message (Collapse) | Author |
|---|
|
This fixes the following warnings:
net/bluetooth/hci_core.c: In function ‘hci_register_dev’:
net/bluetooth/hci_core.c:2620:54: warning: ‘%d’ directive output may
be truncated writing between 1 and 10 bytes into a region of size 5
[-Wformat-truncation=]
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~
net/bluetooth/hci_core.c:2620:50: note: directive argument in the range
[0, 2147483647]
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~~~~~~
net/bluetooth/hci_core.c:2620:9: note: ‘snprintf’ output between 5 and
14 bytes into a destination of size 8
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
While executing the Android 13 CTS Verifier Secure Server test on a
ChromeOS device, it was observed that the Bluetooth host initiates
authentication for an RFCOMM connection after SSP completes.
When this happens, some Intel Bluetooth controllers, like AC9560, would
disconnect with "Connection Rejected due to Security Reasons (0x0e)".
Historically, BlueZ did not mandate this authentication while an
authenticated combination key was already in use for the connection.
This behavior was changed since commit 7b5a9241b780
("Bluetooth: Introduce requirements for security level 4").
So, this patch addresses the aforementioned disconnection issue by
restoring the previous behavior.
Signed-off-by: Ying Hsu <yinghsu@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
iso_listen_cis shall only return -EADDRINUSE if the listening socket has
the destination set to BDADDR_ANY otherwise if the destination is set to
a specific address it is for broadcast which shall be ignored.
Fixes: f764a6c2c1e4 ("Bluetooth: ISO: Add broadcast support")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Syzbot found a bug "BUG: sleeping function called from invalid context
at kernel/locking/mutex.c:580". It is because hci_link_tx_to holds an
RCU read lock and calls hci_disconnect which would hold a mutex lock
since the commit a13f316e90fd ("Bluetooth: hci_conn: Consolidate code
for aborting connections"). Here's an example call trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xfc/0x174 lib/dump_stack.c:106
___might_sleep+0x4a9/0x4d3 kernel/sched/core.c:9663
__mutex_lock_common kernel/locking/mutex.c:576 [inline]
__mutex_lock+0xc7/0x6e7 kernel/locking/mutex.c:732
hci_cmd_sync_queue+0x3a/0x287 net/bluetooth/hci_sync.c:388
hci_abort_conn+0x2cd/0x2e4 net/bluetooth/hci_conn.c:1812
hci_disconnect+0x207/0x237 net/bluetooth/hci_conn.c:244
hci_link_tx_to net/bluetooth/hci_core.c:3254 [inline]
__check_timeout net/bluetooth/hci_core.c:3419 [inline]
__check_timeout+0x310/0x361 net/bluetooth/hci_core.c:3399
hci_sched_le net/bluetooth/hci_core.c:3602 [inline]
hci_tx_work+0xe8f/0x12d0 net/bluetooth/hci_core.c:3652
process_one_work+0x75c/0xba1 kernel/workqueue.c:2310
worker_thread+0x5b2/0x73a kernel/workqueue.c:2457
kthread+0x2f7/0x30b kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
This patch releases RCU read lock before calling hci_disconnect and
reacquires it afterward to fix the bug.
Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
Signed-off-by: Ying Hsu <yinghsu@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires
periodic restarts of the scanning procedure as the controller would
consider device previously found as duplicated despite of RSSI changes,
but in order to set the scan timeout properly set le_scan_restart needs
to be synchronous so it shall not use hci_cmd_sync_queue which defers
the command processing to cmd_sync_work.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t
Fixes: 27d54b778ad1 ("Bluetooth: Rework le_scan_restart for hci_sync")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
We should send hci reset command before bt turn off, which can reset bt
firmware status.
Signed-off-by: Rocky Liao <quic_rjliao@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
hci_req_prepare_suspend() has been deprecated in favor of
hci_suspend_sync().
Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier")
Signed-off-by: Yao Xiao <xiaoyao@rock-chips.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of fixes, plus a new device ID for Intel Granite
Rapids systems.
The fix for the i.MX driver is fairly urgent, it's fixing a data
corruption issue when bits per word isn't 8.
There's also one fix which was queued but not sent for v6.4 due to
being minor and arriving at the end of the release"
* tag 'spi-fix-v6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: imx: Take in account bits per word instead of assuming 8-bits
spi: intel-pci: Add support for Granite Rapids SPI serial flash
spi: stm32: add a delay before SPI disable
spi: nxp-fspi: reset the FLSHxCR1 registers
spi: zynqmp-gqspi: fix clock imbalance on probe failure
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One fix for the tps6287x driver which was incorrectly specifying the
field for voltage range selection leading to incorrect voltages being
set"
* tag 'regulator-fix-v6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix voltage range selection
|
|
This reverts commit ffb6cf19e06334062744b7e3493f71e500964f8e.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit 50e9ceef1d4f644ee0049e82e360058a64ec284c.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit 0269b585868e59b6a2ecc6ea685d39310e4fc18b.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit e44df2664746aed8b6dd5245eb711a0ce33c5cf5.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit d48c3397291690c3576d6c983b0a86ecbc203cac.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.6
Quite a large collection of fixes, with numbers boosted by multiple
vendors sending multi-patch serieses. Nothing super major, and also one
device quirk.
|
|
When making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y,
modprobe handshake-test and then rmmmod handshake-test, the below memory
leak is detected.
The struct socket_alloc which is allocated by alloc_inode_sb() in
__sock_create() is not freed. And the struct dentry which is allocated
by __d_alloc() in sock_alloc_file() is not freed.
Since fput() will call file->f_op->release() which is sock_close() here and
it will call __sock_release(). and fput() will call dput(dentry) to free
the struct dentry. So replace sock_release() with fput() to fix the
below memory leak. After applying this patch, the following memory leak is
never detected.
unreferenced object 0xffff888109165840 (size 768):
comm "kunit_try_catch", pid 1852, jiffies 4294685807 (age 976.262s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0209ba2>] 0xffffffffa0209ba2
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810f472008 (size 192):
comm "kunit_try_catch", pid 1852, jiffies 4294685808 (age 976.261s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 08 20 47 0f 81 88 ff ff ......... G.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0209bbb>] 0xffffffffa0209bbb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810958e580 (size 224):
comm "kunit_try_catch", pid 1852, jiffies 4294685808 (age 976.261s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0209bbb>] 0xffffffffa0209bbb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926dc88 (size 192):
comm "kunit_try_catch", pid 1854, jiffies 4294685809 (age 976.271s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 88 dc 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208fdc>] 0xffffffffa0208fdc
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a241380 (size 224):
comm "kunit_try_catch", pid 1854, jiffies 4294685809 (age 976.271s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208fdc>] 0xffffffffa0208fdc
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109165040 (size 768):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.269s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0208860>] 0xffffffffa0208860
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926d568 (size 192):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.269s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 68 d5 26 09 81 88 ff ff ........h.&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208879>] 0xffffffffa0208879
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240580 (size 224):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.347s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208879>] 0xffffffffa0208879
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164c40 (size 768):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0208541>] 0xffffffffa0208541
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926cd18 (size 192):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 18 cd 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa020855a>] 0xffffffffa020855a
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240200 (size 224):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa020855a>] 0xffffffffa020855a
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164840 (size 768):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa02093e2>] 0xffffffffa02093e2
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926cab8 (size 192):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 b8 ca 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02093fb>] 0xffffffffa02093fb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240040 (size 224):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02093fb>] 0xffffffffa02093fb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109166440 (size 768):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa02097c1>] 0xffffffffa02097c1
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926c398 (size 192):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 98 c3 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02097da>] 0xffffffffa02097da
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107e0b8c0 (size 224):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02097da>] 0xffffffffa02097da
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164440 (size 768):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.487s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa020824e>] 0xffffffffa020824e
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810f4cf698 (size 192):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.501s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 98 f6 4c 0f 81 88 ff ff ..........L.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208267>] 0xffffffffa0208267
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107e0b000 (size 224):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.501s)
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 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208267>] 0xffffffffa0208267
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
Fixes: 88232ec1ec5e ("net/handshake: Add Kunit tests for the handshake consumer API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In mark_chain_precision() logic, when we reach the entry to a global
func, it is expected that R1-R5 might be still requested to be marked
precise. This would correspond to some integer input arguments being
tracked as precise. This is all expected and handled as a special case.
What's not expected is that we'll leave backtrack_state structure with
some register bits set. This is because for subsequent precision
propagations backtrack_state is reused without clearing masks, as all
code paths are carefully written in a way to leave empty backtrack_state
with zeroed out masks, for speed.
The fix is trivial, we always clear register bit in the register mask, and
then, optionally, set reg->precise if register is SCALAR_VALUE type.
Reported-by: Chris Mason <clm@meta.com>
Fixes: be2ef8161572 ("bpf: allow precision tracking for programs with subprogs")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230918210110.2241458-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
before check 'hwdev'
'hwdev' is checked too late and hwdev will not be NULL, so remove the check
Fixes: 2acf960e3be6 ("net: hinic: Add support for configuration of rx-vlan-filter by ethtool")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202309112354.pikZCmyk-lkp@intel.com/
Signed-off-by: Cai Huoqing <cai.huoqing@linux.dev>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Kyle Zeng reported that there is a race between IPSET_CMD_ADD and IPSET_CMD_SWAP
in netfilter/ip_set, which can lead to the invocation of `__ip_set_put` on a
wrong `set`, triggering the `BUG_ON(set->ref == 0);` check in it.
The race is caused by using the wrong reference counter, i.e. the ref counter instead
of ref_netlink.
Fixes: 24e227896bbf ("netfilter: ipset: Add schedule point in call_ad().")
Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
Closes: https://lore.kernel.org/netfilter-devel/ZPZqetxOmH+w%2Fmyc@westworld/#r
Tested-by: Kyle Zeng <zengyhkyle@gmail.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
When more than 255 elements expired we're supposed to switch to a new gc
container structure.
This never happens: u8 type will wrap before reaching the boundary
and nft_trans_gc_space() always returns true.
This means we recycle the initial gc container structure and
lose track of the elements that came before.
While at it, don't deref 'gc' after we've passed it to call_rcu.
Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
nft -f -<<EOF
add table ip t
add table ip t { flags dormant; }
add chain ip t c { type filter hook input priority 0; }
add table ip t
EOF
Triggers a splat from nf core on next table delete because we lose
track of right hook register state:
WARNING: CPU: 2 PID: 1597 at net/netfilter/core.c:501 __nf_unregister_net_hook
RIP: 0010:__nf_unregister_net_hook+0x41b/0x570
nf_unregister_net_hook+0xb4/0xf0
__nf_tables_unregister_hook+0x160/0x1d0
[..]
The above should have table in *active* state, but in fact no
hooks were registered.
Reject on/off/on games rather than attempting to fix this.
Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
Reported-by: "Lee, Cherie-Anne" <cherie.lee@starlabs.sg>
Cc: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Cc: info@starlabs.sg
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
There are some attributes added by vxlan_fill_info() which are not
accounted for in vxlan_get_size(). Add them.
I didn't find a way to trigger an actual problem from this miscalculation
since there is usually extra space in netlink size calculations like
if_nlmsg_size(); but maybe I just didn't search long enough.
Fixes: 3511494ce2f3 ("vxlan: Group Policy extension")
Fixes: e1e5314de08b ("vxlan: implement GPE")
Fixes: 0ace2ca89cbd ("vxlan: Use checksum partial with remote checksum offload")
Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
before dereferencing it as rdma_set_service_type() argument
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: fd261ce6a30e ("rds: rdma: update rdma transport for tos")
Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fix 'tr' dereferencing bug when CONFIG_BPF_JIT is turned off.
When CONFIG_BPF_JIT is turned off, 'bpf_trampoline_get()' returns NULL,
which is same as the cases when CONFIG_BPF_JIT is turned on.
Closes: https://lore.kernel.org/r/202309131936.5Nc8eUD0-lkp@intel.com/
Fixes: f7b12b6fea00 ("bpf: verifier: refactor check_attach_btf_id()")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230917153846.88732-1-hffilwlqm@gmail.com
|
|
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x82/0x150
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x26/0x30
? vlan_dev_hard_header+0x35/0x140 [8021q]
? vlan_dev_hard_header+0x8e/0x140 [8021q]
neigh_connected_output+0xb2/0x100
ip6_finish_output2+0x1cb/0x520
? nf_hook_slow+0x43/0xc0
? ip6_mtu+0x46/0x80
ip6_finish_output+0x2a/0xb0
mld_sendpack+0x18f/0x250
mld_ifc_work+0x39/0x160
process_one_work+0x1e6/0x3f0
worker_thread+0x4d/0x2f0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan->real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.
Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
Suggested-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20230918123011.1884401-1-william.xuanziyang@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
New platform SSID:0x231f.
0x17 was only speaker pin, DAC assigned will be 0x03. Headphone
assigned to 0x02.
Playback via headphone will get EQ filter processing.
So, it needs to swap DAC.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/8d63c6e360124e3ea2523753050e6f05@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Use RUNTIME_PM_OPS() instead of the old SET_RUNTIME_PM_OPS().
This means we don't need __maybe_unused on the functions.
Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230919081153.19793-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This fix was originally queued at the end of the 6.4 cycle but as it was
minor it never actually got sent.
|
|
syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]
This function can run from multiple cpus without mutual exclusion.
Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
Handles updates to dev->stats.tx_dropped while we are at it.
[1]
BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
run_ksoftirqd+0x17/0x20 kernel/softirq.c:921
smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
do_softirq+0x5e/0x90 kernel/softirq.c:454
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
spin_unlock_bh include/linux/spinlock.h:396 [inline]
batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356
batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560
process_one_work kernel/workqueue.c:2630 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
worker_thread+0x525/0x730 kernel/workqueue.c:2784
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
value changed: 0x00000000000d7190 -> 0x00000000000d7191
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0
Fixes: 1c29fc4989bc ("[BRIDGE]: keep track of received multicast packets")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Roopa Prabhu <roopa@nvidia.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Cc: bridge@lists.linux-foundation.org
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20230918091351.1356153-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Jijie Shao says:
====================
There are some bugfix for the HNS3 ethernet driver
====================
Link: https://lore.kernel.org/r/20230918074840.2650978-1-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently the reset process in hns3 and firmware watchdog init process is
asynchronous. we think firmware watchdog initialization is completed
before hns3 clear the firmware interrupt source. However, firmware
initialization may not complete early.
so we add delay before hns3 clear firmware interrupt source and 5 ms delay
is enough to avoid second firmware reset interrupt.
Fixes: c1a81619d73a ("net: hns3: Add mailbox interrupt handling to PF driver")
Signed-off-by: Jie Wang <wangjie125@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Firmware does not respond driver commands during reset
Therefore, rule will fail to delete while the firmware is resetting
So, if failed to delete rule, set rule state to TO_DEL,
and the rule will be deleted when periodic task being scheduled.
Fixes: 0205ec041ec6 ("net: hns3: add support for hw tc offload of tc flower")
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently, the driver will enable unicast promisc for the function
once configure mac address fail. It's unreasonable when the failure
is caused by using same mac address with other functions. So only
enable unicast promisc when mac table full.
Fixes: c631c696823c ("net: hns3: refactor the promisc mode setting")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The device_version V3 hardware can't offload the checksum for IP in GRE
packets, but can do it for NvGRE. So default to disable the checksum and
GSO offload for GRE, but keep the ability to enable it when only using
NvGRE.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Jie Wang <wangjie125@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When the vf cmdq is disabled, there is no need to keep these task running.
So this patch skip these task when the cmdq is disabled.
Fixes: ff200099d271 ("net: hns3: remove unnecessary work in hclgevf_main")
Signed-off-by: Jie Wang <wangjie125@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Song Liu says:
====================
s390/bpf: Fix arch_prepare_bpf_trampoline
While working on trampoline, I found s390's arch_prepare_bpf_trampoline
returns 0 on success, which breaks struct_ops. However, the CI doesn't
catch this issue. Turns out test_progs:bpf_tcp_ca doesn't really test
members of a struct_ops are actually called via the trampolines.
1/2 fixes arch_prepare_bpf_trampoline for s390.
2/2 adds a check to test_progs:bpf_tcp_ca to verify bpf_cubic_acked() is
indeed called by the trampoline. Without 1/2, this check would fail on
s390.
====================
Link: https://lore.kernel.org/r/20230919060258.3237176-1-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Test bpf_tcp_ca (in test_progs) checks multiple tcp_congestion_ops.
However, there isn't a test that verifies functions in the
tcp_congestion_ops is actually called. Add a check to verify that
bpf_cubic_acked is actually called during the test.
Suggested-by: Martin KaFai Lau <martin.lau@kernel.org>
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Link: https://lore.kernel.org/r/20230919060258.3237176-3-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
arch_prepare_bpf_trampoline() for s390 currently returns 0 on success. This
is not a problem for regular trampoline. However, struct_ops relies on the
return value to advance "image" pointer:
bpf_struct_ops_map_update_elem() {
...
for_each_member(i, t, member) {
...
err = bpf_struct_ops_prepare_trampoline();
...
image += err;
}
}
When arch_prepare_bpf_trampoline returns 0 on success, all members of the
struct_ops will point to the same trampoline (the last one).
Fix this by returning the program size in arch_prepare_bpf_trampoline (on
success). This is the same behavior as other architectures.
Signed-off-by: Song Liu <song@kernel.org>
Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()")
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Link: https://lore.kernel.org/r/20230919060258.3237176-2-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
commit 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics
where necessary") caused one regression as found by Uwe, the backtrace
looks like:
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc1-00449-g133466c3bbe1-dirty #21
Hardware name: STM32 (Device Tree Support)
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x60/0x90
dump_stack_lvl from register_lock_class+0x98c/0x99c
register_lock_class from __lock_acquire+0x74/0x293c
__lock_acquire from lock_acquire+0x134/0x398
lock_acquire from stmmac_get_stats64+0x2ac/0x2fc
stmmac_get_stats64 from dev_get_stats+0x44/0x130
dev_get_stats from rtnl_fill_stats+0x38/0x120
rtnl_fill_stats from rtnl_fill_ifinfo+0x834/0x17f4
rtnl_fill_ifinfo from rtmsg_ifinfo_build_skb+0xc0/0x144
rtmsg_ifinfo_build_skb from rtmsg_ifinfo+0x50/0x88
rtmsg_ifinfo from __dev_notify_flags+0xc0/0xec
__dev_notify_flags from dev_change_flags+0x50/0x5c
dev_change_flags from ip_auto_config+0x2f4/0x1260
ip_auto_config from do_one_initcall+0x70/0x35c
do_one_initcall from kernel_init_freeable+0x2ac/0x308
kernel_init_freeable from kernel_init+0x1c/0x138
kernel_init from ret_from_fork+0x14/0x2c
The reason is the rxq|txq_stats structures are not what expected
because stmmac_open() -> __stmmac_open() the structure is overwritten
by "memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));"
This causes the well initialized syncp member of rxq|txq_stats is
overwritten unexpectedly as pointed out by Johannes and Uwe.
Fix this issue by moving rxq|txq_stats back to stmmac_extra_stats. For
SMP cache friendly, we also mark stmmac_txq_stats and stmmac_rxq_stats
as ____cacheline_aligned_in_smp.
Fixes: 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics where necessary")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230917165328.3403-1-jszhang@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The recent enablement of -Wformat-truncation leads to a false-positive
warning for mixer_scarlett_gen2.c.
For suppressing the warning, replace snprintf() with scnprintf().
As stated in the above, truncation doesn't matter.
Fixes: 78bd8f5126f8 ("ALSA: usb-audio: scarlett_gen2: Fix -Wformat-truncation warning")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230919071205.10684-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The commit in Fixes has removed an fwnode_graph_get_endpoint_by_id() call
in mipi_csis_subdev_init().
So the reference that was taken should not be released anymore in the
error handling path of the probe and in the remove function.
Remove the now incorrect fwnode_handle_put() calls.
Fixes: 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode matching")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
`efi_loader_signature` has space for 4 bytes. We are copying "Xen" (3 bytes)
plus a NUL-byte which makes 4 total bytes. With that being said, there is
currently not a bug with the current `strncpy()` implementation in terms of
buffer overreads but we should favor a more robust string interface
either way.
A suitable replacement is `strscpy` [2] due to the fact that it guarantees
NUL-termination on the destination buffer while being functionally the
same in this case.
Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230911-strncpy-arch-x86-xen-efi-c-v1-1-96ab2bba2feb@google.com
Signed-off-by: Juergen Gross <jgross@suse.com>
|
|
When running as a paravirtualized guest under Xen, Linux is using
"lazy mode" for issuing hypercalls which don't need to take immediate
effect in order to improve performance (examples are e.g. multiple
PTE changes).
There are two different lazy modes defined: MMU and CPU lazy mode.
Today it is not possible to nest multiple lazy mode sections, even if
they are of the same kind. A recent change in memory management added
nesting of MMU lazy mode sections, resulting in a regression when
running as Xen PV guest.
Technically there is no reason why nesting of multiple sections of the
same kind of lazy mode shouldn't be allowed. So add support for that
for fixing the regression.
Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()")
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20230913113828.18421-4-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
|
|
Only Xen is using the paravirt lazy mode code, so it can be moved to
Xen specific sources.
This allows to make some of the functions static or to merge them into
their only call sites.
While at it do a rename from "paravirt" to "xen" for all moved
specifiers.
No functional change.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20230913113828.18421-3-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
|
|
include/xen/arm/hypervisor.h contains definitions related to paravirt
lazy mode, which are used nowhere in the code.
All paravirt lazy mode related users are in x86 code, so remove the
definitions on Arm side.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20230913113828.18421-2-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
|
|
There are several functions involved for performing the functionality
of evtchn_do_upcall():
- __xen_evtchn_do_upcall() doing the real work
- xen_hvm_evtchn_do_upcall() just being a wrapper for
__xen_evtchn_do_upcall(), exposed for external callers
- xen_evtchn_do_upcall() calling __xen_evtchn_do_upcall(), too, but
without any user
Simplify this maze by:
- removing the unused xen_evtchn_do_upcall()
- removing xen_hvm_evtchn_do_upcall() as the only left caller of
__xen_evtchn_do_upcall(), while renaming __xen_evtchn_do_upcall() to
xen_evtchn_do_upcall()
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Juergen Gross <jgross@suse.com>
|
|
Pull NFS client fixes from Anna Schumaker:
"Various O_DIRECT related fixes from Trond:
- Error handling
- Locking issues
- Use the correct commit info for joining page groups
- Fixes for rescheduling IO
Sunrpc bad verifier fixes:
- Report EINVAL errors from connect()
- Revalidate creds that the server has rejected
- Revert "SUNRPC: Fail faster on bad verifier"
Misc:
- Fix pNFS session trunking when MDS=DS
- Fix zero-value filehandles for post-open getattr operations
- Fix compiler warning about tautological comparisons
- Revert 'SUNRPC: clean up integer overflow check' before Trond's fix"
* tag 'nfs-for-6.6-2' of git://git.linux-nfs.org/projects/anna/linux-nfs:
SUNRPC: Silence compiler complaints about tautological comparisons
Revert "SUNRPC: clean up integer overflow check"
NFSv4.1: fix zero value filehandle in post open getattr
NFSv4.1: fix pnfs MDS=DS session trunking
Revert "SUNRPC: Fail faster on bad verifier"
SUNRPC: Mark the cred for revalidation if the server rejects it
NFS/pNFS: Report EINVAL errors from connect() to the server
NFS: More fixes for nfs_direct_write_reschedule_io()
NFS: Use the correct commit info in nfs_join_page_group()
NFS: More O_DIRECT accounting fixes for error paths
NFS: Fix O_DIRECT locking issues
NFS: Fix error handling for O_DIRECT write scheduling
|
|
If a network filesystem using netfs implements a clamp_length()
function, it can set subrequest lengths smaller than a page size.
When we loop through the folios in netfs_rreq_unlock_folios() to
set any folios to be written back, we need to make sure we only
call folio_start_fscache() once for each folio.
Otherwise, this simple testcase:
mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs
dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s
echo 3 > /proc/sys/vm/drop_caches
cat /mnt/nfs/file.bin > /dev/null
will trigger an oops similar to the following:
page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))
------------[ cut here ]------------
kernel BUG at include/linux/netfs.h:44!
...
CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5
...
RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]
...
Call Trace:
netfs_rreq_assess+0x497/0x660 [netfs]
netfs_subreq_terminated+0x32b/0x610 [netfs]
nfs_netfs_read_completion+0x14e/0x1a0 [nfs]
nfs_read_completion+0x2f9/0x330 [nfs]
rpc_free_task+0x72/0xa0 [sunrpc]
rpc_async_release+0x46/0x70 [sunrpc]
process_one_work+0x3bd/0x710
worker_thread+0x89/0x610
kthread+0x181/0x1c0
ret_from_fork+0x29/0x50
Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers"
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2210612
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/20230608214137.856006-1-dwysocha@redhat.com/ # v1
Link: https://lore.kernel.org/r/20230915185704.1082982-1-dwysocha@redhat.com/ # v2
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 fixes from Andreas Gruenbacher:
- Fix another freeze/thaw hang
- Fix glock cache shrinking
- Fix the quota=quiet mount option
* tag 'gfs2-v6.6-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
gfs2: Fix quota=quiet oversight
gfs2: fix glock shrinker ref issues
gfs2: Fix another freeze/thaw hang
|
|
Skip non-existent ALARM attribute to avoid a shift-out-of-bounds
dmesg warning.
Reported-by: Doug Smythies <dsmythies@telus.net>
Closes: https://lore.kernel.org/linux-hwmon/ZQVzdlHgWdFhOVyQ@debian.me/T/#mc69b690660eb50734a6b07506d74a119e0266f1b
Fixes: b7f1f7b2523a ("hwmon: (nct6775) Additional TEMP registers for nct6799")
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230918184722.2033225-1-ahmad@khalifa.ws
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
