December 2023 - Linux-stable-mirror

[Regression] 6.1.66, 6.6.5 - wifi: cfg80211: fix CQM for non-range use

by Philip Müller

Hi Johannes, hi Greg, Any tree that back-ported 7e7efdda6adb wifi: cfg80211: fix CQM for non-range use that does not contain 076fc8775daf wifi: cfg80211: remove wdev mutex (which does not apply cleanly to 6.6.y or 6.6.1) will be affected. You can find a downstream bug report at Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/17 So we should either revert 7e7efdda6adb or backport the needed to those kernel series. 6.7.y is reported to work with 6.7.0-rc4. -- Best, Philip

4 months, 2 weeks

4
19
0 0

[PATCH net 0/2] mptcp: new reviewer and prevent a warning

by Matthieu Baerts

Patch 1 adds MPTCP long time contributor -- Geliang Tang -- as a new reviewer for the project. Thanks! Patch 2 prevents a warning when TCP Diag is used to close internal MPTCP listener subflows. This is a correction for a patch introduced in v6.4 which was fixing an issue from v5.17. Signed-off-by: Matthieu Baerts <matttbe(a)kernel.org> --- Matthieu Baerts (1): MAINTAINERS: add Geliang as reviewer for MPTCP Paolo Abeni (1): mptcp: prevent tcp diag from closing listener subflows MAINTAINERS | 1 + net/mptcp/subflow.c | 13 +++++++++++++ 2 files changed, 14 insertions(+) --- base-commit: dff90e4a092b771354287fbe55e557467c9da620 change-id: 20231226-upstream-net-20231226-mptcp-prevent-warn-24f9494bb2a0 Best regards, -- Matthieu Baerts <matttbe(a)kernel.org>

4 months, 2 weeks

2
2
0 0

[PATCH] drm/vmwgfx: Unmap the surface before resetting it on a plane state

by Zack Rusin

Switch to a new plane state requires unreferencing of all held surfaces. In the work required for mob cursors the mapped surfaces started being cached but the variable indicating whether the surface is currently mapped was not being reset. This leads to crashes as the duplicated state, incorrectly, indicates the that surface is mapped even when no surface is present. That's because after unreferencing the surface it's perfectly possible for the plane to be backed by a bo instead of a surface. Reset the surface mapped flag when unreferencing the plane state surface to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 </TASK> Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ end trace 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4") Reported-by: Stefan Hoffmeister <stefan.hoffmeister(a)econos.de> Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/34 Cc: Martin Krastev <martin.krastev(a)broadcom.com> Cc: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Cc: Ian Forbes <ian.forbes(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.19+ --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 65ed9b061753..e7bbe4b05233 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -693,6 +693,10 @@ vmw_du_cursor_plane_prepare_fb(struct drm_plane *plane, int ret = 0; if (vps->surf) { + if (vps->surf_mapped) { + vmw_bo_unmap(vps->surf->res.guest_memory_bo); + vps->surf_mapped = false; + } vmw_surface_unreference(&vps->surf); vps->surf = NULL; } -- 2.40.1

4 months, 2 weeks

4
3
0 0

[PATCH net] rtnetlink: allow to set iface down before enslaving it

by Nicolas Dichtel

The below commit adds support for: > ip link set dummy0 down > ip link set dummy0 master bond0 up but breaks the opposite: > ip link set dummy0 up > ip link set dummy0 master bond0 down Let's add a workaround to have both commands working. Cc: stable(a)vger.kernel.org Fixes: a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> --- net/core/rtnetlink.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index e8431c6c8490..dd79693c2d91 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -2905,6 +2905,14 @@ static int do_setlink(const struct sk_buff *skb, call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } + /* Backward compat: enable to set interface down before enslaving it */ + if (!(ifm->ifi_flags & IFF_UP) && ifm->ifi_change & IFF_UP) { + err = dev_change_flags(dev, rtnl_dev_combine_flags(dev, ifm), + extack); + if (err < 0) + goto errout; + } + if (tb[IFLA_MASTER]) { err = do_set_master(dev, nla_get_u32(tb[IFLA_MASTER]), extack); if (err) -- 2.39.2

4 months, 2 weeks

3
5
0 0

[PATCH v1] usb: typec: class: fix typec_altmode_put_partner to put plugs

by RD Babiera

When releasing an Alt Mode, typec_altmode_release called by a plug device will not release the plug Alt Mode, meaning that a port will hold a reference to a plug Alt Mode even if the port partner is unregistered. As a result, typec_altmode_get_plug() can return an old plug altmode. Currently, typec_altmode_put_partner does not raise issues when unregistering a partner altmode. Looking at the current implementation: > static void typec_altmode_put_partner(struct altmode *altmode) > { > struct altmode *partner = altmode->partner; When called by the partner Alt Mode, then partner evaluates to the port's Alt Mode. When called by the plug Alt Mode, this also evaluates to the port's Alt Mode. > struct typec_altmode *adev; > > if (!partner) > return; > > adev = &partner->adev; This always evaluates to the port's typec_altmode > if (is_typec_plug(adev->dev.parent)) { > struct typec_plug *plug = to_typec_plug(adev->dev.parent); > > partner->plug[plug->index] = NULL; If the routine is called to put the plug's Alt mode and altmode refers to the plug, then adev referring to the port can never be a typec_plug. If altmode refers to the port, adev will always refer to the port partner, which runs the block below. > } else { > partner->partner = NULL; > } > put_device(&adev->dev); > } When calling typec_altmode_set_partner, a registration always calls get_device() on the port partner or the plug being registered, therefore typec_altmode_put_partner should put_device() the same device. By changing adev to altmode->adev, we make sure to put the correct device and properly unregister plugs. The reason port partners are always properly unregistered is because even when adev refers to the port, the port partner gets nullified in the else block. The port device currently gets put(). Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- drivers/usb/typec/class.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c index 2e0451bd336e..803be1943445 100644 --- a/drivers/usb/typec/class.c +++ b/drivers/usb/typec/class.c @@ -267,7 +267,7 @@ static void typec_altmode_put_partner(struct altmode *altmode) if (!partner) return; - adev = &partner->adev; + adev = &altmode->adev; if (is_typec_plug(adev->dev.parent)) { struct typec_plug *plug = to_typec_plug(adev->dev.parent); base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86 -- 2.43.0.rc1.413.gea7ed67945-goog

4 months, 2 weeks

3
4
0 0

[PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as invalid

by Johan Hovold

A recent commit restored the original (and still documented) semantics for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address is considered invalid unless an address is provided by firmware. This specifically means that this flag must only be set for devices with invalid addresses, but the Broadcom BCM4377 driver has so far been setting this flag unconditionally. Fortunately the driver already checks for invalid addresses during setup and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be replaced with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default address is invalid but can be overridden by firmware (long term, this should probably just always be allowed). Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk") Cc: stable(a)vger.kernel.org # 6.5 Reported-by: Felix Zhang <mrman(a)mrman314.tech> Link: https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel@mr… Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_bcm4377.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c index a61757835695..9a7243d5db71 100644 --- a/drivers/bluetooth/hci_bcm4377.c +++ b/drivers/bluetooth/hci_bcm4377.c @@ -1417,7 +1417,7 @@ static int bcm4377_check_bdaddr(struct bcm4377_data *bcm4377) bda = (struct hci_rp_read_bd_addr *)skb->data; if (!bcm4377_is_valid_bdaddr(bcm4377, &bda->bdaddr)) - set_bit(HCI_QUIRK_INVALID_BDADDR, &bcm4377->hdev->quirks); + set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &bcm4377->hdev->quirks); kfree_skb(skb); return 0; @@ -2368,7 +2368,6 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id) hdev->set_bdaddr = bcm4377_hci_set_bdaddr; hdev->setup = bcm4377_hci_setup; - set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); if (bcm4377->hw->broken_mws_transport_config) set_bit(HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG, &hdev->quirks); if (bcm4377->hw->broken_ext_scan) -- 2.41.0

4 months, 2 weeks

5
5
0 0

[PATCH v6 1/7] serial: Do not hold the port lock when setting rx-during-tx GPIO

by Lino Sanfilippo

Both the imx and stm32 driver set the rx-during-tx GPIO in rs485_config(). Since this function is called with the port lock held, this can be an problem in case that setting the GPIO line can sleep (e.g. if a GPIO expander is used which is connected via SPI or I2C). Avoid this issue by moving the GPIO setting outside of the port lock into the serial core and thus making it a generic feature. Also reset old GPIO settings in case that changing the RS485 configuration failed. Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO") Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO") Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: stable(a)vger.kernel.org Reviewed-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/imx.c | 4 ---- drivers/tty/serial/serial_core.c | 26 ++++++++++++++++++++++++-- drivers/tty/serial/stm32-usart.c | 5 +---- 3 files changed, 25 insertions(+), 10 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 708b9852a575..9cffeb23112b 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1943,10 +1943,6 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio rs485conf->flags & SER_RS485_RX_DURING_TX) imx_uart_start_rx(port); - if (port->rs485_rx_during_tx_gpio) - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, - !!(rs485conf->flags & SER_RS485_RX_DURING_TX)); - return 0; } diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index f1348a509552..d155131f221d 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1402,6 +1402,16 @@ static void uart_set_rs485_termination(struct uart_port *port, !!(rs485->flags & SER_RS485_TERMINATE_BUS)); } +static void uart_set_rs485_rx_during_tx(struct uart_port *port, + const struct serial_rs485 *rs485) +{ + if (!(rs485->flags & SER_RS485_ENABLED)) + return; + + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, + !!(rs485->flags & SER_RS485_RX_DURING_TX)); +} + static int uart_rs485_config(struct uart_port *port) { struct serial_rs485 *rs485 = &port->rs485; @@ -1413,12 +1423,17 @@ static int uart_rs485_config(struct uart_port *port) uart_sanitize_serial_rs485(port, rs485); uart_set_rs485_termination(port, rs485); + uart_set_rs485_rx_during_tx(port, rs485); uart_port_lock_irqsave(port, &flags); ret = port->rs485_config(port, NULL, rs485); uart_port_unlock_irqrestore(port, flags); - if (ret) + if (ret) { memset(rs485, 0, sizeof(*rs485)); + /* unset GPIOs */ + gpiod_set_value_cansleep(port->rs485_term_gpio, 0); + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, 0); + } return ret; } @@ -1457,6 +1472,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port, return ret; uart_sanitize_serial_rs485(port, &rs485); uart_set_rs485_termination(port, &rs485); + uart_set_rs485_rx_during_tx(port, &rs485); uart_port_lock_irqsave(port, &flags); ret = port->rs485_config(port, &tty->termios, &rs485); @@ -1468,8 +1484,14 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port, port->ops->set_mctrl(port, port->mctrl); } uart_port_unlock_irqrestore(port, flags); - if (ret) + if (ret) { + /* restore old GPIO settings */ + gpiod_set_value_cansleep(port->rs485_term_gpio, + !!(port->rs485.flags & SER_RS485_TERMINATE_BUS)); + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, + !!(port->rs485.flags & SER_RS485_RX_DURING_TX)); return ret; + } if (copy_to_user(rs485_user, &port->rs485, sizeof(port->rs485))) return -EFAULT; diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c index 3048620315d6..ec9a72a5bea9 100644 --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -226,10 +226,7 @@ static int stm32_usart_config_rs485(struct uart_port *port, struct ktermios *ter stm32_usart_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit)); - if (port->rs485_rx_during_tx_gpio) - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, - !!(rs485conf->flags & SER_RS485_RX_DURING_TX)); - else + if (!port->rs485_rx_during_tx_gpio) rs485conf->flags |= SER_RS485_RX_DURING_TX; if (rs485conf->flags & SER_RS485_ENABLED) { -- 2.43.0

4 months, 2 weeks

3
3
0 0

FAILED: patch "[PATCH] dm-integrity: don't modify bio's immutable bio_vec in" 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 b86f4b790c998afdbc88fe1aa55cfe89c4068726 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123001-profusely-reassign-059b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: b86f4b790c99 ("dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata()") 86a3238c7b9b ("dm: change "unsigned" to "unsigned int"") 7533afa1d27b ("dm: send just one event on resize, not two") 5cd6d1d53a1f ("dm integrity: Remove bi_sector that's only used by commented debug code") 22c40e134c4c ("dm cache: Add some documentation to dm-cache-background-tracker.h") 86e4d3e8d183 ("dm-crypt: provide dma_alignment limit in io_hints") c3adefb5baf3 ("Merge tag 'for-6.0/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b86f4b790c998afdbc88fe1aa55cfe89c4068726 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Tue, 5 Dec 2023 16:39:16 +0100 Subject: [PATCH] dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata() __bio_for_each_segment assumes that the first struct bio_vec argument doesn't change - it calls "bio_advance_iter_single((bio), &(iter), (bvl).bv_len)" to advance the iterator. Unfortunately, the dm-integrity code changes the bio_vec with "bv.bv_len -= pos". When this code path is taken, the iterator would be out of sync and dm-integrity would report errors. This happens if the machine is out of memory and "kmalloc" fails. Fix this bug by making a copy of "bv" and changing the copy instead. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c index e85c688fd91e..c5f03aab4552 100644 --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -1755,11 +1755,12 @@ static void integrity_metadata(struct work_struct *w) sectors_to_process = dio->range.n_sectors; __bio_for_each_segment(bv, bio, iter, dio->bio_details.bi_iter) { + struct bio_vec bv_copy = bv; unsigned int pos; char *mem, *checksums_ptr; again: - mem = bvec_kmap_local(&bv); + mem = bvec_kmap_local(&bv_copy); pos = 0; checksums_ptr = checksums; do { @@ -1768,7 +1769,7 @@ static void integrity_metadata(struct work_struct *w) sectors_to_process -= ic->sectors_per_block; pos += ic->sectors_per_block << SECTOR_SHIFT; sector += ic->sectors_per_block; - } while (pos < bv.bv_len && sectors_to_process && checksums != checksums_onstack); + } while (pos < bv_copy.bv_len && sectors_to_process && checksums != checksums_onstack); kunmap_local(mem); r = dm_integrity_rw_tag(ic, checksums, &dio->metadata_block, &dio->metadata_offset, @@ -1793,9 +1794,9 @@ static void integrity_metadata(struct work_struct *w) if (!sectors_to_process) break; - if (unlikely(pos < bv.bv_len)) { - bv.bv_offset += pos; - bv.bv_len -= pos; + if (unlikely(pos < bv_copy.bv_len)) { + bv_copy.bv_offset += pos; + bv_copy.bv_len -= pos; goto again; } }

4 months, 2 weeks

2
1
0 0

[PATCH v2] usb: core: Add quirk for Logitech Rallybar

by Ricardo Ribalda

Logitech Rallybar devices, despite behaving as UVC camera, they have a different power management system than the rest of the other Logitech cameras. USB_QUIRK_RESET_RESUME causes undesired USB disconnects, that make the device unusable. These are the only two devices that have this behavior, and we do not have the list of devices that require USB_QUIRK_RESET_RESUME, so lets create a new lit for them that un-apply the USB_QUIRK_RESET_RESUME quirk. Fixes: e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams") Cc: stable(a)vger.kernel.org Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Tested with a Rallybar Mini with an Acer Chromebook Spin 513 --- Changes in v2: - Add Fixes tag - Add UVC maintainer as Cc - Link to v1: https://lore.kernel.org/r/20231222-rallybar-v1-1-82b2a4d3106f@chromium.org --- drivers/usb/core/quirks.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 15e9bd180a1d..8fa8de50e7f0 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -553,6 +553,14 @@ static const struct usb_device_id usb_interface_quirk_list[] = { { } /* terminating entry must be last */ }; +static const struct usb_device_id usb_interface_unsupported_quirk_list[] = { + /* Logitech Rallybar VC systems*/ + { USB_DEVICE(0x046d, 0x089b), .driver_info = USB_QUIRK_RESET_RESUME }, + { USB_DEVICE(0x046d, 0x08d3), .driver_info = USB_QUIRK_RESET_RESUME }, + + { } /* terminating entry must be last */ +}; + static const struct usb_device_id usb_amd_resume_quirk_list[] = { /* Lenovo Mouse with Pixart controller */ { USB_DEVICE(0x17ef, 0x602e), .driver_info = USB_QUIRK_RESET_RESUME }, @@ -718,6 +726,8 @@ void usb_detect_interface_quirks(struct usb_device *udev) u32 quirks; quirks = usb_detect_static_quirks(udev, usb_interface_quirk_list); + quirks &= ~usb_detect_static_quirks(udev, + usb_interface_unsupported_quirk_list); if (quirks == 0) return; --- base-commit: c0f65a7c112b3cfa691cead54bcf24d6cc2182b5 change-id: 20231222-rallybar-19ce0c64d5e6 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

4 months, 2 weeks

3
3
0 0

[PATCH] firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards

by Takashi Sakamoto

VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI I/O space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. Well, this commit suppresses the system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable(a)vger.kernel.org Reported-by: Jiri Slaby <jirislaby(a)kernel.org> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello <mario.limonciello(a)amd.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher <tobias-lists(a)23.gs> Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- drivers/firewire/ohci.c | 49 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 7e88fd489741..62af3fa39a70 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -279,6 +279,8 @@ static char ohci_driver_name[] = KBUILD_MODNAME; #define QUIRK_TI_SLLZ059 0x20 #define QUIRK_IR_WAKE 0x40 +#define QUIRK_REBOOT_BY_CYCLE_TIMER_READ 0x80000000 + /* In case of multiple matches in ohci_quirks[], only the first one is used. */ static const struct { unsigned short vendor, device, revision, flags; @@ -1724,6 +1726,11 @@ static u32 get_cycle_time(struct fw_ohci *ohci) s32 diff01, diff12; int i; +#if IS_ENABLED(CONFIG_X86) + if (ohci->quirks & QUIRK_REBOOT_BY_CYCLE_TIMER_READ) + return 0; +#endif + c2 = reg_read(ohci, OHCI1394_IsochronousCycleTimer); if (ohci->quirks & QUIRK_CYCLE_TIMER) { @@ -3527,6 +3534,45 @@ static const struct fw_card_driver ohci_driver = { .stop_iso = ohci_stop_iso, }; +// On PCI Express Root Complex in any type of AMD Ryzen machine, VIA VT6306/6307/6308 with Asmedia +// ASM1083/1085 brings an inconvenience that read accesses to 'Isochronous Cycle Timer' register +// (at offset 0xf0 in PCI I/O space) often causes unexpected system reboot. The mechanism is not +// clear, since the read access to the other registers is enough safe; e.g. 'Node ID' register, +// while it is probable due to detection of any type of PCIe error. +#if IS_ENABLED(CONFIG_X86) + +#define PCI_DEVICE_ID_ASMEDIA_ASM108X 0x1080 + +static bool detect_vt630x_with_asm1083_on_amd_ryzen_machine(const struct pci_dev *pdev, + struct fw_ohci *ohci) +{ + const struct pci_dev *pcie_to_pci_bridge; + const struct cpuinfo_x86 *cinfo = &cpu_data(0); + + // Detect any type of AMD Ryzen machine. + if (cinfo->x86_vendor != X86_VENDOR_AMD || cinfo->x86 < 0x17) + return false; + + // Detect VIA VT6306/6307/6308. + if (pdev->vendor != PCI_VENDOR_ID_VIA) + return false; + if (pdev->device != PCI_DEVICE_ID_VIA_VT630X) + return false; + + // Detect Asmedia ASM1083/1085. + pcie_to_pci_bridge = pdev->bus->self; + if (pcie_to_pci_bridge->vendor != PCI_VENDOR_ID_ASMEDIA) + return false; + if (pcie_to_pci_bridge->device != PCI_DEVICE_ID_ASMEDIA_ASM108X) + return false; + + return true; +} + +#else +#define detect_vt630x_with_asm1083_on_amd_ryzen_machine(pdev) false +#endif + #ifdef CONFIG_PPC_PMAC static void pmac_ohci_on(struct pci_dev *dev) { @@ -3630,6 +3676,9 @@ static int pci_probe(struct pci_dev *dev, if (param_quirks) ohci->quirks = param_quirks; + if (detect_vt630x_with_asm1083_on_amd_ryzen_machine(dev, ohci)) + ohci->quirks |= QUIRK_REBOOT_BY_CYCLE_TIMER_READ; + /* * Because dma_alloc_coherent() allocates at least one page, * we save space by using a common buffer for the AR request/ -- 2.39.2

4 months, 2 weeks

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023