On October 12, 2025 7:20:16 AM PDT, Sasha Levin <sashal(a)kernel.org> wrote:
>This is a note to let you know that I've just added the patch titled
>
> x86/vdso: Fix output operand size of RDPID
>
>to the 6.16-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
>The filename of the patch is:
> x86-vdso-fix-output-operand-size-of-rdpid.patch
>and it can be found in the queue-6.16 subdirectory.
>
>If you, or anyone else, feels it should not be added to the stable tree,
>please let <stable(a)vger.kernel.org> know about it.
>
>
>
>commit 9e09c5e5e76f1bb0480722f36d5a266d2faaf00d
>Author: Uros Bizjak <ubizjak(a)gmail.com>
>Date: Mon Jun 16 11:52:57 2025 +0200
>
> x86/vdso: Fix output operand size of RDPID
>
> [ Upstream commit ac9c408ed19d535289ca59200dd6a44a6a2d6036 ]
>
> RDPID instruction outputs to a word-sized register (64-bit on x86_64 and
> 32-bit on x86_32). Use an unsigned long variable to store the correct size.
>
> LSL outputs to 32-bit register, use %k operand prefix to always print the
> 32-bit name of the register.
>
> Use RDPID insn mnemonic while at it as the minimum binutils version of
> 2.30 supports it.
>
> [ bp: Merge two patches touching the same function into a single one. ]
>
> Fixes: ffebbaedc861 ("x86/vdso: Introduce helper functions for CPU and node number")
> Signed-off-by: Uros Bizjak <ubizjak(a)gmail.com>
> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de>
> Link: https://lore.kernel.org/20250616095315.230620-1-ubizjak@gmail.com
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
>diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
>index 77d8f49b92bdd..f59ae7186940a 100644
>--- a/arch/x86/include/asm/segment.h
>+++ b/arch/x86/include/asm/segment.h
>@@ -244,7 +244,7 @@ static inline unsigned long vdso_encode_cpunode(int cpu, unsigned long node)
>
> static inline void vdso_read_cpunode(unsigned *cpu, unsigned *node)
> {
>- unsigned int p;
>+ unsigned long p;
>
> /*
> * Load CPU and node number from the GDT. LSL is faster than RDTSCP
>@@ -254,10 +254,10 @@ static inline void vdso_read_cpunode(unsigned *cpu, unsigned *node)
> *
> * If RDPID is available, use it.
> */
>- alternative_io ("lsl %[seg],%[p]",
>- ".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */
>+ alternative_io ("lsl %[seg],%k[p]",
>+ "rdpid %[p]",
> X86_FEATURE_RDPID,
>- [p] "=a" (p), [seg] "r" (__CPUNODE_SEG));
>+ [p] "=r" (p), [seg] "r" (__CPUNODE_SEG));
>
> if (cpu)
> *cpu = (p & VDSO_CPUNODE_MASK);
What the actual hell?!
Doesn't *anyone* know that x86 zero-extends a 32-bit value to 64 bits?
All this code does is put a completely unnecessary REX prefix on RDPID.
Greetings future partner.
My name is Mr. David Wright. I write to request your cooperation in my desire to find a foreign partner who will assist me in the relocation and investment of funds. I am offering you 50:50 of the total sum after the transfer.The entire plan of this transaction will be forwarded to you as soon as I receive your positive response. I assure you that there is no risk attached to you in this transaction.
I await your positive response.
May God bless you.
Kind regards,
Mr. David Wright
Tel:+447418603273.
Whatsapp:+447886787422
This series fixes an issue with DMABUF support in the IIO subsystem where
the wrong DMA device could be used for buffer mapping operations. This
becomes critical on systems like Xilinx/AMD ZynqMP Ultrascale where memory
can be mapped above the 32-bit address range.
Problem:
--------
The current IIO DMABUF implementation assumes it can use the parent device
of the IIO device for DMA operations. However, this device may not have
the appropriate DMA mask configuration for accessing high memory addresses.
On systems where memory is mapped above 32-bits, this leads to the use of
bounce buffers through swiotlb, significantly impacting performance.
Solution:
---------
This series introduces a new .get_dma_dev() callback in the buffer access
functions that allows buffer implementations to specify the correct DMA
device that should be used for DMABUF operations. The DMA buffer
infrastructure implements this callback to return the device that actually
owns the DMA channel, ensuring proper memory mapping without bounce buffers.
Changes:
--------
1. Add .get_dma_dev() callback to iio_buffer_access_funcs and update core
DMABUF code to use it when available
2. Implement the callback in the DMA buffer infrastructure
3. Wire up the callback in the dmaengine buffer implementation
This ensures that DMABUF operations use the device with the correct DMA
configuration, eliminating unnecessary bounce buffer usage and improving
performance on high-memory systems.
(AI generated cover. I would not be this formal but I guess is not
that bad :))
---
Changes in v3:
- Patch 1
* Add a new iio_buffer_get_dma_dev() helper to get the DMA dev.
- Link to v2: https://lore.kernel.org/r/20251006-fix-iio-dmabuf-get-dma-device-v2-0-d960b…
---
Nuno Sá (3):
iio: buffer: support getting dma channel from the buffer
iio: buffer-dma: support getting the DMA channel
iio: buffer-dmaengine: enable .get_dma_dev()
drivers/iio/buffer/industrialio-buffer-dma.c | 6 ++++++
drivers/iio/buffer/industrialio-buffer-dmaengine.c | 2 ++
drivers/iio/industrialio-buffer.c | 21 ++++++++++++++++-----
include/linux/iio/buffer-dma.h | 1 +
include/linux/iio/buffer_impl.h | 2 ++
5 files changed, 27 insertions(+), 5 deletions(-)
---
base-commit: b9700f87939f0f477e5c00db817f54ab8a97702b
change-id: 20250930-fix-iio-dmabuf-get-dma-device-339ac70543db
--
Thanks!
- Nuno Sá
This series fixes an issue with DMABUF support in the IIO subsystem where
the wrong DMA device could be used for buffer mapping operations. This
becomes critical on systems like Xilinx/AMD ZynqMP Ultrascale where memory
can be mapped above the 32-bit address range.
Problem:
--------
The current IIO DMABUF implementation assumes it can use the parent device
of the IIO device for DMA operations. However, this device may not have
the appropriate DMA mask configuration for accessing high memory addresses.
On systems where memory is mapped above 32-bits, this leads to the use of
bounce buffers through swiotlb, significantly impacting performance.
Solution:
---------
This series introduces a new .get_dma_dev() callback in the buffer access
functions that allows buffer implementations to specify the correct DMA
device that should be used for DMABUF operations. The DMA buffer
infrastructure implements this callback to return the device that actually
owns the DMA channel, ensuring proper memory mapping without bounce buffers.
Changes:
--------
1. Add .get_dma_dev() callback to iio_buffer_access_funcs and update core
DMABUF code to use it when available
2. Implement the callback in the DMA buffer infrastructure
3. Wire up the callback in the dmaengine buffer implementation
This ensures that DMABUF operations use the device with the correct DMA
configuration, eliminating unnecessary bounce buffer usage and improving
performance on high-memory systems.
(AI generated cover. I would not be this formal but I guess is not
that bad :))
---
Changes in v2:
- Dropped Fixes tags on the first two patches and Cc stable them instead
(as prerequisites for the third patch).
- Link to v1: https://lore.kernel.org/r/20251002-fix-iio-dmabuf-get-dma-device-v1-0-c1c99…
---
Nuno Sá (3):
iio: buffer: support getting dma channel from the buffer
iio: buffer-dma: support getting the DMA channel
iio: buffer-dmaengine: enable .get_dma_dev()
drivers/iio/buffer/industrialio-buffer-dma.c | 6 +++++
drivers/iio/buffer/industrialio-buffer-dmaengine.c | 2 ++
drivers/iio/industrialio-buffer.c | 28 +++++++++++++++++-----
include/linux/iio/buffer-dma.h | 1 +
include/linux/iio/buffer_impl.h | 2 ++
5 files changed, 33 insertions(+), 6 deletions(-)
---
base-commit: b9700f87939f0f477e5c00db817f54ab8a97702b
change-id: 20250930-fix-iio-dmabuf-get-dma-device-339ac70543db
--
Thanks!
- Nuno Sá
From: Celeste Liu <uwu(a)coelacanthus.name>
The gs_usb driver supports USB devices with more than 1 CAN channel.
In old kernel before 3.15, it uses net_device->dev_id to distinguish
different channel in userspace, which was done in commit
acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id").
But since 3.15, the correct way is populating net_device->dev_port.
And according to documentation, if network device support multiple
interface, lack of net_device->dev_port SHALL be treated as a bug.
Fixes: acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id")
Cc: stable(a)vger.kernel.org
Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name>
Link: https://patch.msgid.link/20250930-gs-usb-populate-net_device-dev_port-v1-1-…
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/usb/gs_usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index 9fb4cbbd6d6d..69b8d6da651b 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -1245,6 +1245,7 @@ static struct gs_can *gs_make_candev(unsigned int channel,
netdev->flags |= IFF_ECHO; /* we support full roundtrip echo */
netdev->dev_id = channel;
+ netdev->dev_port = channel;
/* dev setup */
strcpy(dev->bt_const.name, KBUILD_MODNAME);
--
2.51.0
From: Celeste Liu <uwu(a)coelacanthus.name>
This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD
converter[1]. The original developers may have only 3 interfaces
device to test so they write 3 here and wait for future change.
During the HSCanT development, we actually used 4 interfaces, so the
limitation of 3 is not enough now. But just increase one is not
future-proofed. Since the channel index type in gs_host_frame is u8,
just make canch[] become a flexible array with a u8 index, so it
naturally constraint by U8_MAX and avoid statically allocate 256
pointer for every gs_usb device.
[1]: https://github.com/cherry-embedded/HSCanT-hardware
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org>
Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name>
Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant…
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/usb/gs_usb.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index c9482d6e947b..9fb4cbbd6d6d 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -289,11 +289,6 @@ struct gs_host_frame {
#define GS_MAX_RX_URBS 30
#define GS_NAPI_WEIGHT 32
-/* Maximum number of interfaces the driver supports per device.
- * Current hardware only supports 3 interfaces. The future may vary.
- */
-#define GS_MAX_INTF 3
-
struct gs_tx_context {
struct gs_can *dev;
unsigned int echo_id;
@@ -324,7 +319,6 @@ struct gs_can {
/* usb interface struct */
struct gs_usb {
- struct gs_can *canch[GS_MAX_INTF];
struct usb_anchor rx_submitted;
struct usb_device *udev;
@@ -336,9 +330,11 @@ struct gs_usb {
unsigned int hf_size_rx;
u8 active_channels;
+ u8 channel_cnt;
unsigned int pipe_in;
unsigned int pipe_out;
+ struct gs_can *canch[] __counted_by(channel_cnt);
};
/* 'allocate' a tx context.
@@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb)
}
/* device reports out of range channel id */
- if (hf->channel >= GS_MAX_INTF)
+ if (hf->channel >= parent->channel_cnt)
goto device_detach;
dev = parent->canch[hf->channel];
@@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb)
/* USB failure take down all interfaces */
if (rc == -ENODEV) {
device_detach:
- for (rc = 0; rc < GS_MAX_INTF; rc++) {
+ for (rc = 0; rc < parent->channel_cnt; rc++) {
if (parent->canch[rc])
netif_device_detach(parent->canch[rc]->netdev);
}
@@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf,
icount = dconf.icount + 1;
dev_info(&intf->dev, "Configuring for %u interfaces\n", icount);
- if (icount > GS_MAX_INTF) {
+ if (icount > type_max(parent->channel_cnt)) {
dev_err(&intf->dev,
"Driver cannot handle more that %u CAN interfaces\n",
- GS_MAX_INTF);
+ type_max(parent->channel_cnt));
return -EINVAL;
}
- parent = kzalloc(sizeof(*parent), GFP_KERNEL);
+ parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL);
if (!parent)
return -ENOMEM;
+ parent->channel_cnt = icount;
+
init_usb_anchor(&parent->rx_submitted);
usb_set_intfdata(intf, parent);
@@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf)
return;
}
- for (i = 0; i < GS_MAX_INTF; i++)
+ for (i = 0; i < parent->channel_cnt; i++)
if (parent->canch[i])
gs_destroy_candev(parent->canch[i]);
base-commit: 2c95a756e0cfc19af6d0b32b0c6cf3bada334998
--
2.51.0