October 2024 - Linux-stable-mirror

[PATCH] HID: plantronics: Update to map micmute controls

by Wade Wang

telephony page of Plantronics headset is ignored currently, it caused micmute button no function, Now follow native HID key mapping for telephony page map, telephony micmute key is enabled by default Cc: stable(a)vger.kernel.org Signed-off-by: Wade Wang <wade.wang(a)hp.com> --- drivers/hid/hid-plantronics.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-plantronics.c b/drivers/hid/hid-plantronics.c index 2a19f3646ecb..2d17534fce61 100644 --- a/drivers/hid/hid-plantronics.c +++ b/drivers/hid/hid-plantronics.c @@ -77,10 +77,10 @@ static int plantronics_input_mapping(struct hid_device *hdev, } } /* handle standard types - plt_type is 0xffa0uuuu or 0xffa2uuuu */ - /* 'basic telephony compliant' - allow default consumer page map */ + /* 'basic telephony compliant' - allow default consumer & telephony page map */ else if ((plt_type & HID_USAGE) >= PLT_BASIC_TELEPHONY && (plt_type & HID_USAGE) != PLT_BASIC_EXCEPTION) { - if (PLT_ALLOW_CONSUMER) + if (PLT_ALLOW_CONSUMER || (usage->hid & HID_USAGE_PAGE) == HID_UP_TELEPHONY) goto defaulted; } /* not 'basic telephony' - apply legacy mapping */ -- 2.34.1

2 months, 4 weeks

4
8
0 0

FAILED: patch "[PATCH] net: ethernet: cortina: Restore TSO support" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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-4.19.y git checkout FETCH_HEAD git cherry-pick -x 2942dfab630444d46aaa37fb7d629b620abbf6ba # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101406-matted-figure-a255@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 2942dfab6304 ("net: ethernet: cortina: Restore TSO support") ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2942dfab630444d46aaa37fb7d629b620abbf6ba Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Mon, 27 May 2024 21:26:44 +0200 Subject: [PATCH] net: ethernet: cortina: Restore TSO support An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 5f0c9e1771db..7ebd61a3a49b 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -79,7 +79,8 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT) #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \ - NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM) + NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \ + NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) /** * struct gmac_queue_page - page buffer per-page info @@ -1148,13 +1149,25 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, skb_frag_t *skb_frag; dma_addr_t mapping; void *buffer; + u16 mss; int ret; - /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; word3 = SOF_BIT; - if (skb->len >= ETH_FRAME_LEN) { + mss = skb_shinfo(skb)->gso_size; + if (mss) { + /* This means we are dealing with TCP and skb->len is the + * sum total of all the segments. The TSO will deal with + * chopping this up for us. + */ + /* The accelerator needs the full frame size here */ + mss += skb_tcp_all_headers(skb); + netdev_dbg(netdev, "segment offloading mss = %04x len=%04x\n", + mss, skb->len); + word1 |= TSS_MTU_ENABLE_BIT; + word3 |= mss; + } else if (skb->len >= ETH_FRAME_LEN) { /* Hardware offloaded checksumming isn't working on frames * bigger than 1514 bytes. A hypothesis about this is that the * checksum buffer is only 1518 bytes, so when the frames get @@ -1169,7 +1182,9 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, return ret; } word1 |= TSS_BYPASS_BIT; - } else if (skb->ip_summed == CHECKSUM_PARTIAL) { + } + + if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] net: ethernet: cortina: Restore TSO support" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 2942dfab630444d46aaa37fb7d629b620abbf6ba # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101404-contently-large-e751@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 2942dfab6304 ("net: ethernet: cortina: Restore TSO support") ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2942dfab630444d46aaa37fb7d629b620abbf6ba Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Mon, 27 May 2024 21:26:44 +0200 Subject: [PATCH] net: ethernet: cortina: Restore TSO support An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 5f0c9e1771db..7ebd61a3a49b 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -79,7 +79,8 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT) #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \ - NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM) + NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \ + NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) /** * struct gmac_queue_page - page buffer per-page info @@ -1148,13 +1149,25 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, skb_frag_t *skb_frag; dma_addr_t mapping; void *buffer; + u16 mss; int ret; - /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; word3 = SOF_BIT; - if (skb->len >= ETH_FRAME_LEN) { + mss = skb_shinfo(skb)->gso_size; + if (mss) { + /* This means we are dealing with TCP and skb->len is the + * sum total of all the segments. The TSO will deal with + * chopping this up for us. + */ + /* The accelerator needs the full frame size here */ + mss += skb_tcp_all_headers(skb); + netdev_dbg(netdev, "segment offloading mss = %04x len=%04x\n", + mss, skb->len); + word1 |= TSS_MTU_ENABLE_BIT; + word3 |= mss; + } else if (skb->len >= ETH_FRAME_LEN) { /* Hardware offloaded checksumming isn't working on frames * bigger than 1514 bytes. A hypothesis about this is that the * checksum buffer is only 1518 bytes, so when the frames get @@ -1169,7 +1182,9 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, return ret; } word1 |= TSS_BYPASS_BIT; - } else if (skb->ip_summed == CHECKSUM_PARTIAL) { + } + + if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] net: ethernet: cortina: Restore TSO support" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 2942dfab630444d46aaa37fb7d629b620abbf6ba # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101403-widget-outpour-ede3@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 2942dfab6304 ("net: ethernet: cortina: Restore TSO support") ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2942dfab630444d46aaa37fb7d629b620abbf6ba Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Mon, 27 May 2024 21:26:44 +0200 Subject: [PATCH] net: ethernet: cortina: Restore TSO support An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 5f0c9e1771db..7ebd61a3a49b 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -79,7 +79,8 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT) #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \ - NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM) + NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \ + NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) /** * struct gmac_queue_page - page buffer per-page info @@ -1148,13 +1149,25 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, skb_frag_t *skb_frag; dma_addr_t mapping; void *buffer; + u16 mss; int ret; - /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; word3 = SOF_BIT; - if (skb->len >= ETH_FRAME_LEN) { + mss = skb_shinfo(skb)->gso_size; + if (mss) { + /* This means we are dealing with TCP and skb->len is the + * sum total of all the segments. The TSO will deal with + * chopping this up for us. + */ + /* The accelerator needs the full frame size here */ + mss += skb_tcp_all_headers(skb); + netdev_dbg(netdev, "segment offloading mss = %04x len=%04x\n", + mss, skb->len); + word1 |= TSS_MTU_ENABLE_BIT; + word3 |= mss; + } else if (skb->len >= ETH_FRAME_LEN) { /* Hardware offloaded checksumming isn't working on frames * bigger than 1514 bytes. A hypothesis about this is that the * checksum buffer is only 1518 bytes, so when the frames get @@ -1169,7 +1182,9 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, return ret; } word1 |= TSS_BYPASS_BIT; - } else if (skb->ip_summed == CHECKSUM_PARTIAL) { + } + + if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] net: ethernet: cortina: Restore TSO support" 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 2942dfab630444d46aaa37fb7d629b620abbf6ba # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101401-skinless-commodity-1b95@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 2942dfab6304 ("net: ethernet: cortina: Restore TSO support") ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2942dfab630444d46aaa37fb7d629b620abbf6ba Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Mon, 27 May 2024 21:26:44 +0200 Subject: [PATCH] net: ethernet: cortina: Restore TSO support An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 5f0c9e1771db..7ebd61a3a49b 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -79,7 +79,8 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT) #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \ - NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM) + NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \ + NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) /** * struct gmac_queue_page - page buffer per-page info @@ -1148,13 +1149,25 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, skb_frag_t *skb_frag; dma_addr_t mapping; void *buffer; + u16 mss; int ret; - /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; word3 = SOF_BIT; - if (skb->len >= ETH_FRAME_LEN) { + mss = skb_shinfo(skb)->gso_size; + if (mss) { + /* This means we are dealing with TCP and skb->len is the + * sum total of all the segments. The TSO will deal with + * chopping this up for us. + */ + /* The accelerator needs the full frame size here */ + mss += skb_tcp_all_headers(skb); + netdev_dbg(netdev, "segment offloading mss = %04x len=%04x\n", + mss, skb->len); + word1 |= TSS_MTU_ENABLE_BIT; + word3 |= mss; + } else if (skb->len >= ETH_FRAME_LEN) { /* Hardware offloaded checksumming isn't working on frames * bigger than 1514 bytes. A hypothesis about this is that the * checksum buffer is only 1518 bytes, so when the frames get @@ -1169,7 +1182,9 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, return ret; } word1 |= TSS_BYPASS_BIT; - } else if (skb->ip_summed == CHECKSUM_PARTIAL) { + } + + if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] mptcp: fallback when MPTCP opts are dropped after 1st data" 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 119d51e225febc8152476340a880f5415a01e99e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101443-lunchroom-refinish-4251@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 119d51e225fe ("mptcp: fallback when MPTCP opts are dropped after 1st data") ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") 4cf86ae84c71 ("mptcp: strict local address ID selection") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 119d51e225febc8152476340a880f5415a01e99e Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Tue, 8 Oct 2024 13:04:54 +0200 Subject: [PATCH] mptcp: fallback when MPTCP opts are dropped after 1st data As reported by Christoph [1], before this patch, an MPTCP connection was wrongly reset when a host received a first data packet with MPTCP options after the 3wHS, but got the next ones without. According to the MPTCP v1 specs [2], a fallback should happen in this case, because the host didn't receive a DATA_ACK from the other peer, nor receive data for more than the initial window which implies a DATA_ACK being received by the other peer. The patch here re-uses the same logic as the one used in other places: by looking at allow_infinite_fallback, which is disabled at the creation of an additional subflow. It's not looking at the first DATA_ACK (or implying one received from the other side) as suggested by the RFC, but it is in continuation with what was already done, which is safer, and it fixes the reported issue. The next step, looking at this first DATA_ACK, is tracked in [4]. This patch has been validated using the following Packetdrill script: 0 socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // 3WHS is OK +0.0 < S 0:0(0) win 65535 <mss 1460, sackOK, nop, nop, nop, wscale 6, mpcapable v1 flags[flag_h] nokey> +0.0 > S. 0:0(0) ack 1 <mss 1460, nop, nop, sackOK, nop, wscale 8, mpcapable v1 flags[flag_h] key[skey]> +0.1 < . 1:1(0) ack 1 win 2048 <mpcapable v1 flags[flag_h] key[ckey=2, skey]> +0 accept(3, ..., ...) = 4 // Data from the client with valid MPTCP options (no DATA_ACK: normal) +0.1 < P. 1:501(500) ack 1 win 2048 <mpcapable v1 flags[flag_h] key[skey, ckey] mpcdatalen 500, nop, nop> // From here, the MPTCP options will be dropped by a middlebox +0.0 > . 1:1(0) ack 501 <dss dack8=501 dll=0 nocs> +0.1 read(4, ..., 500) = 500 +0 write(4, ..., 100) = 100 // The server replies with data, still thinking MPTCP is being used +0.0 > P. 1:101(100) ack 501 <dss dack8=501 dsn8=1 ssn=1 dll=100 nocs, nop, nop> // But the client already did a fallback to TCP, because the two previous packets have been received without MPTCP options +0.1 < . 501:501(0) ack 101 win 2048 +0.0 < P. 501:601(100) ack 101 win 2048 // The server should fallback to TCP, not reset: it didn't get a DATA_ACK, nor data for more than the initial window +0.0 > . 101:101(0) ack 601 Note that this script requires Packetdrill with MPTCP support, see [3]. Fixes: dea2b1ea9c70 ("mptcp: do not reset MP_CAPABLE subflow on mapping errors") Cc: stable(a)vger.kernel.org Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/518 [1] Link: https://datatracker.ietf.org/doc/html/rfc8684#name-fallback [2] Link: https://github.com/multipath-tcp/packetdrill [3] Link: https://github.com/multipath-tcp/mptcp_net-next/issues/519 [4] Reviewed-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20241008-net-mptcp-fallback-fixes-v1-3-c6fb8e93e55… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index e1046a696ab5..25dde81bcb75 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1282,7 +1282,7 @@ static bool subflow_can_fallback(struct mptcp_subflow_context *subflow) else if (READ_ONCE(msk->csum_enabled)) return !subflow->valid_csum_seen; else - return !subflow->fully_established; + return READ_ONCE(msk->allow_infinite_fallback); } static void mptcp_subflow_fail(struct mptcp_sock *msk, struct sock *ssk)

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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-6.1.y git checkout FETCH_HEAD git cherry-pick -x 18fd04ad856df07733f5bb07e7f7168e7443d393 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101446-approve-rants-581d@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 18fd04ad856d ("Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 18fd04ad856df07733f5bb07e7f7168e7443d393 Mon Sep 17 00:00:00 2001 From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Date: Wed, 2 Oct 2024 11:17:26 -0400 Subject: [PATCH] Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30 Cc: stable(a)vger.kernel.org Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index d083117ee36c..c4c74b82ed21 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -289,6 +289,9 @@ static int hci_enhanced_setup_sync(struct hci_dev *hdev, void *data) kfree(conn_handle); + if (!hci_conn_valid(hdev, conn)) + return -ECANCELED; + bt_dev_dbg(hdev, "hcon %p", conn); configure_datapath_sync(hdev, &conn->codec);

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" 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 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101425-pug-throwback-22c7@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101424-skinning-tightness-ecf1@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

2 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101412-stipulate-plentiful-20b6@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

2 months, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024