February 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] mptcp: move __mptcp_error_report in protocol.c" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x d5fbeff1ab812b6c473b6924bee8748469462e2c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100421-divisible-bacterium-18b5@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d5fbeff1ab812b6c473b6924bee8748469462e2c Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Sat, 16 Sep 2023 12:52:46 +0200 Subject: [PATCH] mptcp: move __mptcp_error_report in protocol.c This will simplify the next patch ("mptcp: process pending subflow error on close"). No functional change intended. Cc: stable(a)vger.kernel.org # v5.12+ Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index a7fc16f5175d..915860027b1a 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -770,6 +770,42 @@ static bool __mptcp_ofo_queue(struct mptcp_sock *msk) return moved; } +void __mptcp_error_report(struct sock *sk) +{ + struct mptcp_subflow_context *subflow; + struct mptcp_sock *msk = mptcp_sk(sk); + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + int err = sock_error(ssk); + int ssk_state; + + if (!err) + continue; + + /* only propagate errors on fallen-back sockets or + * on MPC connect + */ + if (sk->sk_state != TCP_SYN_SENT && !__mptcp_check_fallback(msk)) + continue; + + /* We need to propagate only transition to CLOSE state. + * Orphaned socket will see such state change via + * subflow_sched_work_if_closed() and that path will properly + * destroy the msk as needed. + */ + ssk_state = inet_sk_state_load(ssk); + if (ssk_state == TCP_CLOSE && !sock_flag(sk, SOCK_DEAD)) + inet_sk_state_store(sk, ssk_state); + WRITE_ONCE(sk->sk_err, -err); + + /* This barrier is coupled with smp_rmb() in mptcp_poll() */ + smp_wmb(); + sk_error_report(sk); + break; + } +} + /* In most cases we will be able to lock the mptcp socket. If its already * owned, we need to defer to the work queue to avoid ABBA deadlock. */ diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 9bf3c7bc1762..2f40c23fdb0d 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1362,42 +1362,6 @@ void mptcp_space(const struct sock *ssk, int *space, int *full_space) *full_space = mptcp_win_from_space(sk, READ_ONCE(sk->sk_rcvbuf)); } -void __mptcp_error_report(struct sock *sk) -{ - struct mptcp_subflow_context *subflow; - struct mptcp_sock *msk = mptcp_sk(sk); - - mptcp_for_each_subflow(msk, subflow) { - struct sock *ssk = mptcp_subflow_tcp_sock(subflow); - int err = sock_error(ssk); - int ssk_state; - - if (!err) - continue; - - /* only propagate errors on fallen-back sockets or - * on MPC connect - */ - if (sk->sk_state != TCP_SYN_SENT && !__mptcp_check_fallback(msk)) - continue; - - /* We need to propagate only transition to CLOSE state. - * Orphaned socket will see such state change via - * subflow_sched_work_if_closed() and that path will properly - * destroy the msk as needed. - */ - ssk_state = inet_sk_state_load(ssk); - if (ssk_state == TCP_CLOSE && !sock_flag(sk, SOCK_DEAD)) - inet_sk_state_store(sk, ssk_state); - WRITE_ONCE(sk->sk_err, -err); - - /* This barrier is coupled with smp_rmb() in mptcp_poll() */ - smp_wmb(); - sk_error_report(sk); - break; - } -} - static void subflow_error_report(struct sock *ssk) { struct sock *sk = mptcp_subflow_ctx(ssk)->conn;

1 year, 7 months

3
2
0 0

[PATCH 6.1.y] mptcp: continue marking the first subflow as UNCONNECTED

by Matthieu Baerts (NGI0)

After the 'Fixes' commit mentioned below, which is a partial backport, the MPTCP worker was no longer marking the first subflow as "UNCONNECTED" when the socket was transitioning to TCP_CLOSE state. As a result, in v6.1, it was no longer possible to reconnect to the just disconnected socket. Continue to do that like before, only for the first subflow. A few refactoring have been done around the 'msk->subflow' in later versions, and it looks like this is not needed to do that there, but still needed in v6.1. Without that, the 'disconnect' tests from the mptcp_connect.sh selftest fail: they repeat the transfer 3 times by reconnecting to the server each time. Fixes: 7857e35ef10e ("mptcp: get rid of msk->subflow") Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Notes: - This is specific to the 6.1 version having the partial backport. --- net/mptcp/protocol.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index cdabb00648bd2..125825db642cc 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2440,6 +2440,8 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk, need_push = (flags & MPTCP_CF_PUSH) && __mptcp_retransmit_pending_data(sk); if (!dispose_it) { __mptcp_subflow_disconnect(ssk, subflow, flags); + if (msk->subflow && ssk == msk->subflow->sk) + msk->subflow->state = SS_UNCONNECTED; release_sock(ssk); goto out; -- 2.43.0

1 year, 8 months

2
1
0 0

[PATCH regression fix] misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume

by Hans de Goede

When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend(). Fixes: b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback") Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Closes: https://lore.kernel.org/regressions/5fc6da74-af0a-4aac-b4d5-a000b39a63a5@mo… Cc: stable(a)vger.kernel.org Cc: regressions(a)lists.linux.dev Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c index c6eb27d46cb0..15119584473c 100644 --- a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c +++ b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c @@ -198,8 +198,14 @@ static int lis3lv02d_i2c_suspend(struct device *dev) struct i2c_client *client = to_i2c_client(dev); struct lis3lv02d *lis3 = i2c_get_clientdata(client); - if (!lis3->pdata || !lis3->pdata->wakeup_flags) + /* Turn on for wakeup if turned off by runtime suspend */ + if (lis3->pdata && lis3->pdata->wakeup_flags) { + if (pm_runtime_suspended(dev)) + lis3lv02d_poweron(lis3); + /* For non wakeup turn off if not already turned off by runtime suspend */ + } else if (!pm_runtime_suspended(dev)) lis3lv02d_poweroff(lis3); + return 0; } @@ -208,13 +214,12 @@ static int lis3lv02d_i2c_resume(struct device *dev) struct i2c_client *client = to_i2c_client(dev); struct lis3lv02d *lis3 = i2c_get_clientdata(client); - /* - * pm_runtime documentation says that devices should always - * be powered on at resume. Pm_runtime turns them off after system - * wide resume is complete. - */ - if (!lis3->pdata || !lis3->pdata->wakeup_flags || - pm_runtime_suspended(dev)) + /* Turn back off if turned on for wakeup and runtime suspended*/ + if (lis3->pdata && lis3->pdata->wakeup_flags) { + if (pm_runtime_suspended(dev)) + lis3lv02d_poweroff(lis3); + /* For non wakeup turn back on if not runtime suspended */ + } else if (!pm_runtime_suspended(dev)) lis3lv02d_poweron(lis3); return 0; -- 2.43.0

1 year, 8 months

4
4
0 0

[PATCH] serial: 8250_dw: Do not reclock if already at correct rate

by Peter Collingbourne

When userspace opens the console, we call set_termios() passing a termios with the console's configured baud rate. Currently this causes dw8250_set_termios() to disable and then re-enable the UART clock at the same frequency as it was originally. This can cause corruption of any concurrent console output. Fix it by skipping the reclocking if we are already at the correct rate. Signed-off-by: Peter Collingbourne <pcc(a)google.com> Link: https://linux-review.googlesource.com/id/I2e3761d239cbf29ed41412e5338f30bff… Fixes: 4e26b134bd17 ("serial: 8250_dw: clock rate handling for all ACPI platforms") Cc: stable(a)vger.kernel.org --- drivers/tty/serial/8250/8250_dw.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index 2d1f350a4bea..c1d43f040c43 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -357,9 +357,9 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios, long rate; int ret; - clk_disable_unprepare(d->clk); rate = clk_round_rate(d->clk, newrate); - if (rate > 0) { + if (rate > 0 && p->uartclk != rate) { + clk_disable_unprepare(d->clk); /* * Note that any clock-notifer worker will block in * serial8250_update_uartclk() until we are done. @@ -367,8 +367,8 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios, ret = clk_set_rate(d->clk, newrate); if (!ret) p->uartclk = rate; + clk_prepare_enable(d->clk); } - clk_prepare_enable(d->clk); dw8250_do_set_termios(p, termios, old); } -- 2.44.0.rc1.240.g4c46232300-goog

1 year, 8 months

3
2
0 0

[PATCH v2] usb: port: Don't try to peer unused USB ports based on location

by Mathias Nyman

Unused USB ports may have bogus location data in ACPI PLD tables. This causes port peering failures as these unused USB2 and USB3 ports location may match. Due to these failures the driver prints a "usb: port power management may be unreliable" warning, and unnecessarily blocks port power off during runtime suspend. This was debugged on a couple DELL systems where the unused ports all returned zeroes in their location data. Similar bugreports exist for other systems. Don't try to peer or match ports that have connect type set to USB_PORT_NOT_USED. Fixes: 3bfd659baec8 ("usb: find internal hub tier mismatch via acpi") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218465 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218486 Tested-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Link: https://lore.kernel.org/linux-usb/5406d361-f5b7-4309-b0e6-8c94408f7d75@molg… Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- v1 -> v2 - Improve commit message - Add missing Fixes, Closes and Link tags - send this patch separately for easier picking to usb-linus drivers/usb/core/port.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c index c628c1abc907..4d63496f98b6 100644 --- a/drivers/usb/core/port.c +++ b/drivers/usb/core/port.c @@ -573,7 +573,7 @@ static int match_location(struct usb_device *peer_hdev, void *p) struct usb_hub *peer_hub = usb_hub_to_struct_hub(peer_hdev); struct usb_device *hdev = to_usb_device(port_dev->dev.parent->parent); - if (!peer_hub) + if (!peer_hub || port_dev->connect_type == USB_PORT_NOT_USED) return 0; hcd = bus_to_hcd(hdev->bus); @@ -584,7 +584,8 @@ static int match_location(struct usb_device *peer_hdev, void *p) for (port1 = 1; port1 <= peer_hdev->maxchild; port1++) { peer = peer_hub->ports[port1 - 1]; - if (peer && peer->location == port_dev->location) { + if (peer && peer->connect_type != USB_PORT_NOT_USED && + peer->location == port_dev->location) { link_peers_report(port_dev, peer); return 1; /* done */ } -- 2.25.1

1 year, 8 months

2
4
0 0

[PATCH] etnaviv: Restore some id values

by Christian Gmeiner

From: Christian Gmeiner <cgmeiner(a)igalia.com> The hwdb selection logic as a feature that allows it to mark some fields as 'don't care'. If we match with such a field we memcpy(..) the current etnaviv_chip_identity into ident. This step can overwrite some id values read from the GPU with the 'don't care' value. Fix this issue by restoring the affected values after the memcpy(..). As this is crucial for user space to know when this feature works as expected increment the minor version too. Fixes: 4078a1186dd3 ("drm/etnaviv: update hwdb selection logic") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Gmeiner <cgmeiner(a)igalia.com> --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 6228ce603248..9a2965741dab 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -494,7 +494,7 @@ static const struct drm_driver etnaviv_drm_driver = { .desc = "etnaviv DRM", .date = "20151214", .major = 1, - .minor = 3, + .minor = 4, }; /* diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c index 67201242438b..1e38d66702f1 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c @@ -265,6 +265,9 @@ static const struct etnaviv_chip_identity etnaviv_chip_identities[] = { bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu) { struct etnaviv_chip_identity *ident = &gpu->identity; + const u32 product_id = ident->product_id; + const u32 customer_id = ident->customer_id; + const u32 eco_id = ident->eco_id; int i; for (i = 0; i < ARRAY_SIZE(etnaviv_chip_identities); i++) { @@ -278,6 +281,17 @@ bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu) etnaviv_chip_identities[i].eco_id == ~0U)) { memcpy(ident, &etnaviv_chip_identities[i], sizeof(*ident)); + + /* Restore some id values if ~0U aka 'don't care' is used. */ + if (etnaviv_chip_identities[i].product_id == ~0U) + ident->product_id = product_id; + + if (etnaviv_chip_identities[i].customer_id == ~0U) + ident->customer_id = customer_id; + + if (etnaviv_chip_identities[i].eco_id == ~0U) + ident->eco_id = eco_id; + return true; } } -- 2.44.0

1 year, 8 months

3
3
0 0

RE: Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg

by Simon Kirby

Hi, I bisected a regression where reading from a Bluetooth device gets stuck in recvfrom() calls. The device here is a Wii Balance Board, using https://github.com/initialstate/beerfridge/blob/master/wiiboard_test.py; this worked fine in v6.6.1 and v6.6.8, but when I tried on a v6.6.14 build, the script no longer outputs any readings. 1d576c3a5af850bf11fbd103f9ba11aa6d6061fb is the first bad commit which maps to upstream commit 2e07e8348ea454615e268222ae3fc240421be768: Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg With this commit in place, as also in v6.7 and v6.7.6, the script does not output anything _unless_ I strace the process, in which case a bunch of recvmsg() syscalls are shown, and then it hangs again. If I ^C the strace and run it a few times, eventually the script will get enough data and output a reading. If I don't strace the script, a hung task warning appears: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u9:1 state:D stack:0 pid:121 tgid:121 ppid:2 flags:0x00004000 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> On 6.8-rc6 with lockdep enabled, I get the following output: [ 22.122337] wlan0: associated [ 4547.622339] INFO: task kworker/u9:1:3528 blocked for more than 30 seconds. [ 4547.622530] ===================================================== [ 4547.622531] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [ 4547.622535] 6.8.0-rc6-lemon #190 Not tainted [ 4547.622538] ----------------------------------------------------- [ 4547.622540] khungtaskd/39 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 4547.622546] ffff888101554cf8 ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0}, at: __flush_work+0x4b/0x3f0 [ 4547.622569] and this task is already holding: [ 4547.622571] ffffffff8367e600 (console_owner){....}-{0:0}, at: console_flush_all+0x1c9/0x4e0 [ 4547.622586] which would create a new lock dependency: [ 4547.622587] (console_owner){....}-{0:0} -> ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} [ 4547.622596] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 4547.622598] (&trans_pcie->irq_lock){+.-.}-{3:3} [ 4547.622601] ... which became SOFTIRQ-irq-safe at: [ 4547.622603] lock_acquire+0xb0/0x280 [ 4547.622611] _raw_spin_lock+0x2b/0x40 [ 4547.622618] iwl_pcie_napi_poll+0x7a/0x130 [ 4547.622627] __napi_poll.constprop.0+0x23/0x1e0 [ 4547.622634] net_rx_action+0x137/0x2a0 [ 4547.622639] __do_softirq+0xc7/0x402 [ 4547.622645] do_softirq+0x42/0xa0 [ 4547.622651] __local_bh_enable_ip+0xb8/0xd0 [ 4547.622657] iwl_pcie_irq_handler+0x539/0xb70 [ 4547.622665] irq_thread_fn+0x1b/0x60 [ 4547.622670] irq_thread+0xe0/0x190 [ 4547.622675] kthread+0xe3/0x120 [ 4547.622679] ret_from_fork+0x2c/0x50 [ 4547.622684] ret_from_fork_asm+0x1b/0x30 [ 4547.622692] to a SOFTIRQ-irq-unsafe lock: [ 4547.622694] ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} [ 4547.622698] ... which became SOFTIRQ-irq-unsafe at: [ 4547.622699] ... [ 4547.622700] lock_acquire+0xb0/0x280 [ 4547.622706] process_one_work+0x199/0x480 [ 4547.622713] worker_thread+0x1be/0x3b0 [ 4547.622719] kthread+0xe3/0x120 [ 4547.622722] ret_from_fork+0x2c/0x50 [ 4547.622725] ret_from_fork_asm+0x1b/0x30 [ 4547.622731] other info that might help us debug this: [ 4547.622732] Chain exists of: &trans_pcie->irq_lock --> console_owner --> (work_completion)(&(&ops->cursor_work)->work) [ 4547.622739] Possible interrupt unsafe locking scenario: [ 4547.622741] CPU0 CPU1 [ 4547.622742] ---- ---- [ 4547.622742] lock((work_completion)(&(&ops->cursor_work)->work)); [ 4547.622745] local_irq_disable(); [ 4547.622746] lock(&trans_pcie->irq_lock); [ 4547.622749] lock(console_owner); [ 4547.622751] <Interrupt> [ 4547.622752] lock(&trans_pcie->irq_lock); [ 4547.622754] *** DEADLOCK *** [ 4547.622755] 5 locks held by khungtaskd/39: [ 4547.622759] #0: ffffffff836f14e0 (rcu_read_lock){....}-{1:3}, at: watchdog+0xd8/0x7b0 [ 4547.622778] #1: ffffffff836ee820 (console_lock){+.+.}-{0:0}, at: _printk+0x47/0x50 [ 4547.622789] #2: ffffffff836ee870 (console_srcu){....}-{0:0}, at: console_flush_all+0x74/0x4e0 [ 4547.622800] #3: ffffffff8367e600 (console_owner){....}-{0:0}, at: console_flush_all+0x1c9/0x4e0 [ 4547.622810] #4: ffffffff837d8758 (printing_lock){....}-{3:3}, at: vt_console_print+0x47/0x430 [ 4547.622822] the dependencies between SOFTIRQ-irq-safe lock and the holding lock: [ 4547.622824] -> (&trans_pcie->irq_lock){+.-.}-{3:3} { [ 4547.622830] HARDIRQ-ON-W at: [ 4547.622833] lock_acquire+0xb0/0x280 [ 4547.622839] _raw_spin_lock_bh+0x33/0x40 [ 4547.622845] iwl_trans_pcie_alloc+0x2fd/0x990 [ 4547.622853] iwl_pci_probe+0x28/0x810 [ 4547.622859] pci_device_probe+0x94/0x120 [ 4547.622865] really_probe+0x15e/0x2f0 [ 4547.622872] __driver_probe_device+0x6e/0x110 [ 4547.622878] driver_probe_device+0x1a/0xe0 [ 4547.622884] __driver_attach+0x87/0x190 [ 4547.622890] bus_for_each_dev+0x66/0xb0 [ 4547.622894] bus_add_driver+0xea/0x1f0 [ 4547.622898] driver_register+0x54/0x100 [ 4547.622905] iwl_pci_register_driver+0x1a/0x40 [ 4547.622911] do_one_initcall+0x50/0x250 [ 4547.622918] kernel_init_freeable+0x243/0x3e0 [ 4547.622927] kernel_init+0x15/0x1a0 [ 4547.622931] ret_from_fork+0x2c/0x50 [ 4547.622935] ret_from_fork_asm+0x1b/0x30 [ 4547.622941] IN-SOFTIRQ-W at: [ 4547.622943] lock_acquire+0xb0/0x280 [ 4547.622948] _raw_spin_lock+0x2b/0x40 [ 4547.622953] iwl_pcie_napi_poll+0x7a/0x130 [ 4547.622961] __napi_poll.constprop.0+0x23/0x1e0 [ 4547.622966] net_rx_action+0x137/0x2a0 [ 4547.622971] __do_softirq+0xc7/0x402 [ 4547.622978] do_softirq+0x42/0xa0 [ 4547.622983] __local_bh_enable_ip+0xb8/0xd0 [ 4547.622989] iwl_pcie_irq_handler+0x539/0xb70 [ 4547.622996] irq_thread_fn+0x1b/0x60 [ 4547.623002] irq_thread+0xe0/0x190 [ 4547.623006] kthread+0xe3/0x120 [ 4547.623011] ret_from_fork+0x2c/0x50 [ 4547.623014] ret_from_fork_asm+0x1b/0x30 [ 4547.623020] INITIAL USE at: [ 4547.623022] lock_acquire+0xb0/0x280 [ 4547.623027] _raw_spin_lock_bh+0x33/0x40 [ 4547.623032] iwl_trans_pcie_alloc+0x2fd/0x990 [ 4547.623038] iwl_pci_probe+0x28/0x810 [ 4547.623043] pci_device_probe+0x94/0x120 [ 4547.623047] really_probe+0x15e/0x2f0 [ 4547.623053] __driver_probe_device+0x6e/0x110 [ 4547.623059] driver_probe_device+0x1a/0xe0 [ 4547.623064] __driver_attach+0x87/0x190 [ 4547.623070] bus_for_each_dev+0x66/0xb0 [ 4547.623073] bus_add_driver+0xea/0x1f0 [ 4547.623077] driver_register+0x54/0x100 [ 4547.623084] iwl_pci_register_driver+0x1a/0x40 [ 4547.623090] do_one_initcall+0x50/0x250 [ 4547.623096] kernel_init_freeable+0x243/0x3e0 [ 4547.623103] kernel_init+0x15/0x1a0 [ 4547.623107] ret_from_fork+0x2c/0x50 [ 4547.623110] ret_from_fork_asm+0x1b/0x30 [ 4547.623116] } [ 4547.623118] ... key at: [<ffffffff8502fe90>] __key.20+0x0/0x10 [ 4547.623129] -> (&trans_pcie->reg_lock){+...}-{3:3} { [ 4547.623134] HARDIRQ-ON-W at: [ 4547.623137] lock_acquire+0xb0/0x280 [ 4547.623142] _raw_spin_lock_bh+0x33/0x40 [ 4547.623147] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623151] iwl_pcie_set_hw_ready+0x1e/0xa0 [ 4547.623160] iwl_pcie_prepare_card_hw+0x33/0x100 [ 4547.623165] iwl_pci_probe+0x42/0x810 [ 4547.623171] pci_device_probe+0x94/0x120 [ 4547.623175] really_probe+0x15e/0x2f0 [ 4547.623181] __driver_probe_device+0x6e/0x110 [ 4547.623186] driver_probe_device+0x1a/0xe0 [ 4547.623192] __driver_attach+0x87/0x190 [ 4547.623197] bus_for_each_dev+0x66/0xb0 [ 4547.623201] bus_add_driver+0xea/0x1f0 [ 4547.623205] driver_register+0x54/0x100 [ 4547.623211] iwl_pci_register_driver+0x1a/0x40 [ 4547.623217] do_one_initcall+0x50/0x250 [ 4547.623223] kernel_init_freeable+0x243/0x3e0 [ 4547.623229] kernel_init+0x15/0x1a0 [ 4547.623233] ret_from_fork+0x2c/0x50 [ 4547.623236] ret_from_fork_asm+0x1b/0x30 [ 4547.623242] INITIAL USE at: [ 4547.623244] lock_acquire+0xb0/0x280 [ 4547.623249] _raw_spin_lock_bh+0x33/0x40 [ 4547.623254] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623257] iwl_pcie_set_hw_ready+0x1e/0xa0 [ 4547.623266] iwl_pcie_prepare_card_hw+0x33/0x100 [ 4547.623271] iwl_pci_probe+0x42/0x810 [ 4547.623277] pci_device_probe+0x94/0x120 [ 4547.623281] really_probe+0x15e/0x2f0 [ 4547.623286] __driver_probe_device+0x6e/0x110 [ 4547.623292] driver_probe_device+0x1a/0xe0 [ 4547.623297] __driver_attach+0x87/0x190 [ 4547.623303] bus_for_each_dev+0x66/0xb0 [ 4547.623306] bus_add_driver+0xea/0x1f0 [ 4547.623310] driver_register+0x54/0x100 [ 4547.623316] iwl_pci_register_driver+0x1a/0x40 [ 4547.623323] do_one_initcall+0x50/0x250 [ 4547.623328] kernel_init_freeable+0x243/0x3e0 [ 4547.623334] kernel_init+0x15/0x1a0 [ 4547.623338] ret_from_fork+0x2c/0x50 [ 4547.623342] ret_from_fork_asm+0x1b/0x30 [ 4547.623347] } [ 4547.623348] ... key at: [<ffffffff8502fe80>] __key.19+0x0/0x10 [ 4547.623358] ... acquired at: [ 4547.623359] _raw_spin_lock_bh+0x33/0x40 [ 4547.623364] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623368] iwl_pcie_apm_init+0x6e/0x1c0 [ 4547.623372] iwl_trans_pcie_start_fw+0x224/0x670 [ 4547.623377] iwl_mvm_load_ucode_wait_alive+0xd3/0x5a0 [ 4547.623383] iwl_run_init_mvm_ucode+0x8c/0x3a0 [ 4547.623387] iwl_mvm_start_get_nvm+0x87/0x210 [ 4547.623393] iwl_op_mode_mvm_start+0x962/0xb30 [ 4547.623399] _iwl_op_mode_start.isra.0+0x72/0xb0 [ 4547.623403] iwl_opmode_register+0x6a/0xe0 [ 4547.623408] iwl_mvm_init+0x21/0x60 [ 4547.623413] do_one_initcall+0x50/0x250 [ 4547.623419] kernel_init_freeable+0x243/0x3e0 [ 4547.623425] kernel_init+0x15/0x1a0 [ 4547.623429] ret_from_fork+0x2c/0x50 [ 4547.623432] ret_from_fork_asm+0x1b/0x30 [ 4547.623441] -> (console_owner){....}-{0:0} { [ 4547.623446] INITIAL USE at: [ 4547.623452] lock_acquire+0xb0/0x280 [ 4547.623457] console_flush_all+0x1f2/0x4e0 [ 4547.623463] console_unlock+0x33/0x110 [ 4547.623469] vprintk_emit+0x9f/0x320 [ 4547.623475] _printk+0x47/0x50 [ 4547.623479] register_console+0x34b/0x4d0 [ 4547.623485] con_init+0x200/0x270 [ 4547.623494] console_init+0x4a/0x1e0 [ 4547.623504] start_kernel+0x2b9/0x660 [ 4547.623510] x86_64_start_reservations+0x18/0x30 [ 4547.623517] x86_64_start_kernel+0xad/0xc0 [ 4547.623522] secondary_startup_64_no_verify+0x170/0x17b [ 4547.623528] } [ 4547.623529] ... key at: [<ffffffff8367e600>] console_owner_dep_map+0x0/0x28 [ 4547.623538] ... acquired at: [ 4547.623540] console_flush_all+0x1f2/0x4e0 [ 4547.623545] console_unlock+0x33/0x110 [ 4547.623551] vprintk_emit+0x9f/0x320 [ 4547.623557] dev_vprintk_emit+0xce/0x160 [ 4547.623562] dev_printk_emit+0x3d/0x50 [ 4547.623566] _dev_info+0x5b/0x70 [ 4547.623572] __iwl_info+0x58/0x60 [ 4547.623576] iwl_pci_probe+0x11c/0x810 [ 4547.623582] pci_device_probe+0x94/0x120 [ 4547.623587] really_probe+0x15e/0x2f0 [ 4547.623592] __driver_probe_device+0x6e/0x110 [ 4547.623598] driver_probe_device+0x1a/0xe0 [ 4547.623603] __driver_attach+0x87/0x190 [ 4547.623609] bus_for_each_dev+0x66/0xb0 [ 4547.623612] bus_add_driver+0xea/0x1f0 [ 4547.623616] driver_register+0x54/0x100 [ 4547.623622] iwl_pci_register_driver+0x1a/0x40 [ 4547.623629] do_one_initcall+0x50/0x250 [ 4547.623634] kernel_init_freeable+0x243/0x3e0 [ 4547.623640] kernel_init+0x15/0x1a0 [ 4547.623644] ret_from_fork+0x2c/0x50 [ 4547.623648] ret_from_fork_asm+0x1b/0x30 [ 4547.623654] the dependencies between the lock to be acquired [ 4547.623655] and SOFTIRQ-irq-unsafe lock: [ 4547.623665] -> ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} { [ 4547.623670] HARDIRQ-ON-W at: [ 4547.623672] lock_acquire+0xb0/0x280 [ 4547.623677] process_one_work+0x199/0x480 [ 4547.623684] worker_thread+0x1be/0x3b0 [ 4547.623690] kthread+0xe3/0x120 [ 4547.623694] ret_from_fork+0x2c/0x50 [ 4547.623698] ret_from_fork_asm+0x1b/0x30 [ 4547.623704] SOFTIRQ-ON-W at: [ 4547.623705] lock_acquire+0xb0/0x280 [ 4547.623710] process_one_work+0x199/0x480 [ 4547.623716] worker_thread+0x1be/0x3b0 [ 4547.623722] kthread+0xe3/0x120 [ 4547.623725] ret_from_fork+0x2c/0x50 [ 4547.623729] ret_from_fork_asm+0x1b/0x30 [ 4547.623734] INITIAL USE at: [ 4547.623736] lock_acquire+0xb0/0x280 [ 4547.623741] process_one_work+0x199/0x480 [ 4547.623747] worker_thread+0x1be/0x3b0 [ 4547.623753] kthread+0xe3/0x120 [ 4547.623757] ret_from_fork+0x2c/0x50 [ 4547.623760] ret_from_fork_asm+0x1b/0x30 [ 4547.623766] } [ 4547.623767] ... key at: [<ffffffff850211b0>] __key.1+0x0/0x10 [ 4547.623775] ... acquired at: [ 4547.623777] lock_acquire+0xb0/0x280 [ 4547.623781] __flush_work+0x56/0x3f0 [ 4547.623789] __cancel_work_timer+0xd3/0x160 [ 4547.623796] fbcon_cursor+0x138/0x170 [ 4547.623802] hide_cursor+0x26/0xc0 [ 4547.623807] vt_console_print+0x41e/0x430 [ 4547.623814] console_flush_all+0x206/0x4e0 [ 4547.623820] console_unlock+0x33/0x110 [ 4547.623825] vprintk_emit+0x9f/0x320 [ 4547.623831] _printk+0x47/0x50 [ 4547.623834] watchdog+0x53a/0x7b0 [ 4547.623838] kthread+0xe3/0x120 [ 4547.623841] ret_from_fork+0x2c/0x50 [ 4547.623845] ret_from_fork_asm+0x1b/0x30 [ 4547.623851] stack backtrace: [ 4547.623854] CPU: 2 PID: 39 Comm: khungtaskd Not tainted 6.8.0-rc6-lemon #190 [ 4547.623860] Hardware name: LENOVO 80MK/VIUU4, BIOS C6CN29WW 09/02/2015 [ 4547.623862] Call Trace: [ 4547.623865] <TASK> [ 4547.623867] dump_stack_lvl+0x4a/0x80 [ 4547.623879] check_irq_usage+0x8aa/0xb10 [ 4547.623886] ? check_path.constprop.0+0x24/0x50 [ 4547.623896] ? check_noncircular+0x6d/0x120 [ 4547.623902] ? __lock_acquire+0x146a/0x25c0 [ 4547.623907] __lock_acquire+0x146a/0x25c0 [ 4547.623913] lock_acquire+0xb0/0x280 [ 4547.623918] ? __flush_work+0x4b/0x3f0 [ 4547.623925] ? __flush_work+0x4b/0x3f0 [ 4547.623932] __flush_work+0x56/0x3f0 [ 4547.623939] ? __flush_work+0x4b/0x3f0 [ 4547.623946] ? __lock_acquire+0x3ef/0x25c0 [ 4547.623952] __cancel_work_timer+0xd3/0x160 [ 4547.623960] fbcon_cursor+0x138/0x170 [ 4547.623965] hide_cursor+0x26/0xc0 [ 4547.623971] vt_console_print+0x41e/0x430 [ 4547.623977] ? lock_release+0xb5/0x230 [ 4547.623982] ? console_flush_all+0x1c9/0x4e0 [ 4547.623988] console_flush_all+0x206/0x4e0 [ 4547.623994] ? console_flush_all+0x1c9/0x4e0 [ 4547.624001] console_unlock+0x33/0x110 [ 4547.624007] vprintk_emit+0x9f/0x320 [ 4547.624013] _printk+0x47/0x50 [ 4547.624017] watchdog+0x53a/0x7b0 [ 4547.624021] ? __pfx_watchdog+0x10/0x10 [ 4547.624025] kthread+0xe3/0x120 [ 4547.624029] ? __pfx_kthread+0x10/0x10 [ 4547.624033] ret_from_fork+0x2c/0x50 [ 4547.624037] ? __pfx_kthread+0x10/0x10 [ 4547.624041] ret_from_fork_asm+0x1b/0x30 [ 4547.624049] </TASK> [ 4548.028173] Not tainted 6.8.0-rc6-lemon #190 [ 4548.029491] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4548.031047] task:kworker/u9:1 state:D stack:0 pid:3528 tgid:3528 ppid:2 flags:0x00004000 [ 4548.032620] Workqueue: hci0 hci_rx_work [ 4548.034099] Call Trace: [ 4548.035572] <TASK> [ 4548.036925] __schedule+0x427/0xd10 [ 4548.038382] ? schedule+0xf7/0x140 [ 4548.039822] schedule+0x45/0x140 [ 4548.041201] __lock_sock+0x86/0xf0 [ 4548.042601] ? __pfx_autoremove_wake_function+0x10/0x10 [ 4548.044030] lock_sock_nested+0x61/0x70 [ 4548.045390] l2cap_sock_recv_cb+0x21/0xa0 [ 4548.046842] l2cap_recv_frame+0x5be/0x2e70 [ 4548.048283] ? hci_rx_work+0x431/0x830 [ 4548.049701] ? lock_release+0xb5/0x230 [ 4548.051145] ? __mutex_unlock_slowpath+0x25/0x270 [ 4548.052524] hci_rx_work+0x457/0x830 [ 4548.053945] ? process_one_work+0x157/0x480 [ 4548.055460] process_one_work+0x1ca/0x480 [ 4548.056862] worker_thread+0x1be/0x3b0 [ 4548.058281] ? __pfx_worker_thread+0x10/0x10 [ 4548.059783] kthread+0xe3/0x120 [ 4548.061141] ? __pfx_kthread+0x10/0x10 [ 4548.062600] ret_from_fork+0x2c/0x50 [ 4548.064064] ? __pfx_kthread+0x10/0x10 [ 4548.065436] ret_from_fork_asm+0x1b/0x30 [ 4548.066867] </TASK> [ 4548.068313] INFO: lockdep is turned off. # cat /proc/3526/stack [<0>] __skb_wait_for_more_packets+0xfa/0x150 [<0>] __skb_recv_datagram+0x59/0xa0 [<0>] skb_recv_datagram+0x29/0x40 [<0>] bt_sock_recvmsg+0x42/0x1c0 [<0>] l2cap_sock_recvmsg+0x5d/0x170 [<0>] __sys_recvfrom+0x14e/0x160 [<0>] __x64_sys_recvfrom+0x1f/0x30 [<0>] do_syscall_64+0x75/0x150 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 This is on my laptop with iwlwifi, but at first I saw it on my desktop with Ethernet (and Intel 9260 Bluetooth). I can get another lockdep capture if that would be helpful. Simon-

1 year, 8 months

3
3
0 0

[PATCH v2] PM: suspend: Set mem_sleep_current during kernel command line setup

by Maulik Shah

psci_init_system_suspend() invokes suspend_set_ops() very early during bootup even before kernel command line for mem_sleep_default is setup. This leads to kernel command line mem_sleep_default=s2idle not working as mem_sleep_current gets changed to deep via suspend_set_ops() and never changes back to s2idle. Set mem_sleep_current along with mem_sleep_default during kernel command line setup as default suspend mode. Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") CC: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Maulik Shah <quic_mkshah(a)quicinc.com> --- Changes in v2: - Set mem_sleep_current during mem_sleep_default kernel command line setup - Update commit message accordingly - Retain Fixes: tag - Link to v1: https://lore.kernel.org/r/20240219-suspend_ops_late_init-v1-1-6330ca9597fa@… --- kernel/power/suspend.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c index 742eb26618cc..e3ae93bbcb9b 100644 --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -192,6 +192,7 @@ static int __init mem_sleep_default_setup(char *str) if (mem_sleep_labels[state] && !strcmp(str, mem_sleep_labels[state])) { mem_sleep_default = state; + mem_sleep_current = state; break; } --- base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118 change-id: 20240219-suspend_ops_late_init-27fb0b15baee Best regards, -- Maulik Shah <quic_mkshah(a)quicinc.com>

1 year, 8 months

3
2
0 0

[PATCH] ubi: eba: properly rollback inside self_check_eba

by Fedor Pchelkin

In case of a memory allocation failure in the volumes loop we can only process the already allocated scan_eba and fm_eba array elements on the error path - others are still uninitialized. Found by Linux Verification Center (linuxtesting.org). Fixes: 00abf3041590 ("UBI: Add self_check_eba()") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- drivers/mtd/ubi/eba.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 8d1f0e05892c..6f5eadb1598d 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -1557,6 +1557,7 @@ int self_check_eba(struct ubi_device *ubi, struct ubi_attach_info *ai_fastmap, GFP_KERNEL); if (!fm_eba[i]) { ret = -ENOMEM; + kfree(scan_eba[i]); goto out_free; } @@ -1592,7 +1593,7 @@ int self_check_eba(struct ubi_device *ubi, struct ubi_attach_info *ai_fastmap, } out_free: - for (i = 0; i < num_volumes; i++) { + while (--i >= 0) { if (!ubi->volumes[i]) continue; -- 2.43.2

1 year, 8 months

2
1
0 0

[PATCH -fixes v4 2/3] riscv: Add a custom ISA extension for the [ms]envcfg CSR

by Samuel Holland

The [ms]envcfg CSR was added in version 1.12 of the RISC-V privileged ISA (aka S[ms]1p12). However, bits in this CSR are defined by several other extensions which may be implemented separately from any particular version of the privileged ISA (for example, some unrelated errata may prevent an implementation from claiming conformance with Ss1p12). As a result, Linux cannot simply use the privileged ISA version to determine if the CSR is present. It must also check if any of these other extensions are implemented. It also cannot probe the existence of the CSR at runtime, because Linux does not require Sstrict, so (in the absence of additional information) it cannot know if a CSR at that address is [ms]envcfg or part of some non-conforming vendor extension. Since there are several standard extensions that imply the existence of the [ms]envcfg CSR, it becomes unwieldy to check for all of them wherever the CSR is accessed. Instead, define a custom Xlinuxenvcfg ISA extension bit that is implied by the other extensions and denotes that the CSR exists as defined in the privileged ISA, containing at least one of the fields common between menvcfg and senvcfg. This extension does not need to be parsed from the devicetree or ISA string because it can only be implemented as a subset of some other standard extension. Cc: <stable(a)vger.kernel.org> # v6.7+ Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> --- Changes in v4: - New patch for v4 arch/riscv/include/asm/hwcap.h | 2 ++ arch/riscv/kernel/cpufeature.c | 14 ++++++++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index 5340f818746b..1f2d2599c655 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -81,6 +81,8 @@ #define RISCV_ISA_EXT_ZTSO 72 #define RISCV_ISA_EXT_ZACAS 73 +#define RISCV_ISA_EXT_XLINUXENVCFG 127 + #define RISCV_ISA_EXT_MAX 128 #define RISCV_ISA_EXT_INVALID U32_MAX diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index c5b13f7dd482..dacffef68ce2 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -201,6 +201,16 @@ static const unsigned int riscv_zvbb_exts[] = { RISCV_ISA_EXT_ZVKB }; +/* + * While the [ms]envcfg CSRs were not defined until version 1.12 of the RISC-V + * privileged ISA, the existence of the CSRs is implied by any extension which + * specifies [ms]envcfg bit(s). Hence, we define a custom ISA extension for the + * existence of the CSR, and treat it as a subset of those other extensions. + */ +static const unsigned int riscv_xlinuxenvcfg_exts[] = { + RISCV_ISA_EXT_XLINUXENVCFG +}; + /* * The canonical order of ISA extension names in the ISA string is defined in * chapter 27 of the unprivileged specification. @@ -250,8 +260,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = { __RISCV_ISA_EXT_DATA(c, RISCV_ISA_EXT_c), __RISCV_ISA_EXT_DATA(v, RISCV_ISA_EXT_v), __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h), - __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), - __RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ), + __RISCV_ISA_EXT_SUPERSET(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts), + __RISCV_ISA_EXT_SUPERSET(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts), __RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR), __RISCV_ISA_EXT_DATA(zicond, RISCV_ISA_EXT_ZICOND), __RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR), -- 2.43.1

1 year, 8 months

4
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2024