6.18.19-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 300/333 iio: gyro: mpu3050-core: fix pm_runtime error handling
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antoniu Miclaus <[email protected]>
commit acc3949aab3e8094641a9c7c2768de1958c88378 upstream.
The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure.
In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.
--- drivers/iio/gyro/mpu3050-core.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
drivers/iio/gyro/mpu3050-core.c +13 -5
@@ -322,7 +322,9 @@ static int mpu3050_read_raw(struct iio_d }case IIO_CHAN_INFO_RAW :/* Resume device */ -pm_runtime_get_sync (mpu3050->dev); + ret =pm_runtime_resume_and_get (mpu3050->dev); +if (ret) +return ret;mutex_lock (&mpu3050->lock); ret =mpu3050_set_8khz_samplerate (mpu3050);
@@ -647,14 +649,20 @@ out_trigger_unlock:static int mpu3050_buffer_preenable (struct iio_dev *indio_dev) {struct mpu3050 *mpu3050 =iio_priv (indio_dev); +int ret; -pm_runtime_get_sync (mpu3050->dev); + ret =pm_runtime_resume_and_get (mpu3050->dev); +if (ret) +return ret;/* Unless we have OUR trigger active, run at full speed */ -if (!mpu3050->hw_irq_trigger) -return mpu3050_set_8khz_samplerate (mpu3050); +if (!mpu3050->hw_irq_trigger) { + ret =mpu3050_set_8khz_samplerate (mpu3050); +if (ret) +pm_runtime_put_autosuspend (mpu3050->dev); + } -return 0 ; +return ret; }static int mpu3050_buffer_postdisable (struct iio_dev *indio_dev)
Greg Kroah-Hartman
maintainerPATCH 301/333 iio: imu: adis: Fix NULL pointer dereference in adis_init
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radu Sabau <[email protected]>
commit 9990cd4f8827bd1ae3fb6eb7407630d8d463c430 upstream.
The adis_init() function dereferences adis->ops to check if the individual function pointers (write, read, reset) are NULL, but does not first check if adis->ops itself is NULL.
Drivers like adis16480, adis16490, adis16545 and others do not set custom ops and rely on adis_init() assigning the defaults. Since struct adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL when adis_init() is called, causing a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
pc : adis_init+0xc0/0x118
Call trace:
adis_init+0xc0/0x118
adis16480_probe+0xe0/0x670Fix this by checking if adis->ops is NULL before dereferencing it, falling through to assign the default ops in that case.
--- drivers/iio/imu/adis.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/imu/adis.c +1 -1
@@ -526,7 +526,7 @@ int adis_init(struct adis *adis, struct iio_dev *indio_dev, adis->spi = spi; adis->data = data; -if (!adis->ops->write && !adis->ops->read && !adis->ops->reset) +if (!adis->ops) adis->ops = &adis_default_ops;else if (!adis->ops->write || !adis->ops->read || !adis->ops->reset)return -EINVAL ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 302/333 iio: gyro: mpu3050-i2c: fix pm_runtime error handling
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antoniu Miclaus <[email protected]>
commit 91f950b4cbb1aa9ea4eb3999f1463e8044b717fb upstream.
The return value of pm_runtime_get_sync() is not checked, and the function always returns success. This allows I2C mux operations to proceed even when the device fails to resume.
Use pm_runtime_resume_and_get() and propagate its return value to properly handle resume failures.
--- drivers/iio/gyro/mpu3050-i2c.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/iio/gyro/mpu3050-i2c.c +1 -2
@@ -19,8 +19,7 @@ static int mpu3050_i2c_bypass_select(strstruct mpu3050 *mpu3050 =i2c_mux_priv (mux);/* Just power up the device, that is all that is needed */ -pm_runtime_get_sync (mpu3050->dev); -return 0 ; +return pm_runtime_resume_and_get (mpu3050->dev); }static int mpu3050_i2c_bypass_deselect (struct i2c_mux_core *mux,u32 chan_id)
Greg Kroah-Hartman
maintainerPATCH 303/333 iio: light: bh1780: fix PM runtime leak on error path
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antoniu Miclaus <[email protected]>
commit dd72e6c3cdea05cad24e99710939086f7a113fb5 upstream.
Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.
--- drivers/iio/light/bh1780.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/light/bh1780.c +1 -1
@@ -109,9 +109,9 @@ static int bh1780_read_raw(struct iio_decase IIO_LIGHT :pm_runtime_get_sync (&bh1780->client->dev); value =bh1780_read_word (bh1780,BH1780_REG_DLOW ); +pm_runtime_put_autosuspend (&bh1780->client->dev);if (value <0 )return value; -pm_runtime_put_autosuspend (&bh1780->client->dev); *val = value;return IIO_VAL_INT ;
Greg Kroah-Hartman
maintainerPATCH 304/333 iio: imu: inv_icm42600: fix odr switch to the same value
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean-Baptiste Maneyrol <[email protected]>
commit c9f3a593137d862d424130343e77d4b5260a4f5a upstream.
ODR switch is done in 2 steps when FIFO is on : change the ODR register value and acknowledge change when reading the FIFO ODR change flag. When we are switching to the same odr value, we end up waiting for a FIFO ODR flag that is never happening.
Fix the issue by doing nothing and exiting properly when we are switching to the same ODR value.
--- drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c | 2 ++ drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c +2 -0
@@ -651,6 +651,8 @@ static int inv_icm42600_accel_write_odr(return -EINVAL ; conf.odr = inv_icm42600_accel_odr_conv[idx /2 ]; +if (conf.odr == st->conf.accel.odr) +return 0 ;pm_runtime_get_sync (dev);mutex_lock (&st->lock);
drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c +2 -0
@@ -358,6 +358,8 @@ static int inv_icm42600_gyro_write_odr(sreturn -EINVAL ; conf.odr = inv_icm42600_gyro_odr_conv[idx /2 ]; +if (conf.odr == st->conf.gyro.odr) +return 0 ;pm_runtime_get_sync (dev);mutex_lock (&st->lock);
Greg Kroah-Hartman
maintainerPATCH 305/333 iio: imu: inv_icm42600: fix odr switch when turning buffer off
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean-Baptiste Maneyrol <[email protected]>
commit ffd32db8263d2d785a2c419486a450dc80693235 upstream.
ODR switch is done in 2 steps when FIFO is on : change the ODR register value and acknowledge change when reading the FIFO ODR change flag. When we are switching odr and turning buffer off just afterward, we are losing the FIFO ODR change flag and ODR switch is blocked.
Fix the issue by force applying any waiting ODR change when turning buffer off.
--- drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c +4 -0
@@ -371,6 +371,8 @@ static int inv_icm42600_buffer_predisablstatic int inv_icm42600_buffer_postdisable (struct iio_dev *indio_dev) {struct inv_icm42600_state *st =iio_device_get_drvdata (indio_dev); +struct inv_icm42600_sensor_state *sensor_st =iio_priv (indio_dev); +struct inv_sensors_timestamp *ts = &sensor_st->ts;struct device *dev =regmap_get_device (st->map);unsigned int sensor;unsigned int *watermark;
@@ -392,6 +394,8 @@ static int inv_icm42600_buffer_postdisabmutex_lock (&st->lock); +inv_sensors_timestamp_apply_odr (ts,0 ,0 ,0 ); + ret =inv_icm42600_buffer_set_fifo_en (st, st->fifo.en & ~sensor);if (ret) goto out_unlock;
Greg Kroah-Hartman
maintainerPATCH 306/333 iio: proximity: hx9023s: fix assignment order for __counted_by
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yasin Lee <[email protected]>
commit 585b90c0161ab77416fe3acdbdc55b978e33e16c upstream.
Initialize fw_size before copying firmware data into the flexible array member to match the __counted_by() annotation. This fixes the incorrect assignment order that triggers runtime safety checks.
--- drivers/iio/proximity/hx9023s.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/iio/proximity/hx9023s.c +1 -2
@@ -1034,9 +1034,8 @@ static int hx9023s_send_cfg(const structif (!bin)return -ENOMEM ; -memcpy (bin->data, fw->data, fw->size); - bin->fw_size = fw->size; +memcpy (bin->data, fw->data, bin->fw_size); bin->fw_ver = bin->data[FW_VER_OFFSET ]; bin->reg_count =get_unaligned_le16 (bin->data +FW_REG_CNT_OFFSET );
Greg Kroah-Hartman
maintainerPATCH 307/333 iio: proximity: hx9023s: Protect against division by zero in set_samp_freq
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yasin Lee <[email protected]>
commit a318cfc0853706f1d6ce682dba660bc455d674ef upstream.
Avoid division by zero when sampling frequency is unspecified.
--- drivers/iio/proximity/hx9023s.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/iio/proximity/hx9023s.c +3 -0
@@ -719,6 +719,9 @@ static int hx9023s_set_samp_freq(structstruct device *dev =regmap_get_device (data->regmap);unsigned int i, period_ms; +if (!val && !val2) +return -EINVAL ; + period_ms =div_u64 (NANO , (val *MEGA + val2));for (i =0 ; i <ARRAY_SIZE (hx9023s_samp_freq_table); i++) {
Greg Kroah-Hartman
maintainerPATCH 308/333 i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 4167b8914463132654e01e16259847d097f8a7f7 upstream.
The MIPI I3C HCI driver currently returns -ETIME for various timeout conditions, while other I3C master drivers consistently use -ETIMEDOUT for the same class of errors. Align the HCI driver with the rest of the subsystem by replacing all uses of -ETIME with -ETIMEDOUT.
--- drivers/i3c/master/mipi-i3c-hci/cmd_v1.c | 2 +- drivers/i3c/master/mipi-i3c-hci/cmd_v2.c | 2 +- drivers/i3c/master/mipi-i3c-hci/core.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-)
drivers/i3c/master/mipi-i3c-hci/cmd_v1.c +1 -1
@@ -336,7 +336,7 @@ static int hci_cmd_v1_daa(struct i3c_hci hci->io->queue_xfer (hci, xfer,1 );if (!wait_for_completion_timeout (&done,HZ ) && hci->io->dequeue_xfer (hci, xfer,1 )) { - ret = -ETIME ; + ret = -ETIMEDOUT ;break ; } if ((RESP_STATUS(xfer->response) == RESP_ERR_ADDR_HEADER ||
drivers/i3c/master/mipi-i3c-hci/cmd_v2.c +1 -1
@@ -277,7 +277,7 @@ static int hci_cmd_v2_daa(struct i3c_hci hci->io->queue_xfer (hci, xfer,2 );if (!wait_for_completion_timeout (&done,HZ ) && hci->io->dequeue_xfer (hci, xfer,2 )) { - ret = -ETIME ; + ret = -ETIMEDOUT ;break ; }if (RESP_STATUS (xfer[0 ].response) !=RESP_SUCCESS ) {
drivers/i3c/master/mipi-i3c-hci/core.c +3 -3
@@ -230,7 +230,7 @@ static int i3c_hci_send_ccc_cmd(struct i goto out;if (!wait_for_completion_timeout (&done,HZ ) && hci->io->dequeue_xfer (hci, xfer, nxfers)) { - ret = -ETIME ; + ret = -ETIMEDOUT ; goto out; }for (i = prefixed; i < nxfers; i++) {
@@ -309,7 +309,7 @@ static int i3c_hci_priv_xfers(struct i3c goto out;if (!wait_for_completion_timeout (&done,HZ ) && hci->io->dequeue_xfer (hci, xfer, nxfers)) { - ret = -ETIME ; + ret = -ETIMEDOUT ; goto out; }for (i =0 ; i < nxfers; i++) {
@@ -357,7 +357,7 @@ static int i3c_hci_i2c_xfers(struct i2c_ goto out;if (!wait_for_completion_timeout (&done, m->i2c.timeout) && hci->io->dequeue_xfer (hci, xfer, nxfers)) { - ret = -ETIME ; + ret = -ETIMEDOUT ; goto out; }for (i =0 ; i < nxfers; i++) {
Greg Kroah-Hartman
maintainerPATCH 309/333 i3c: mipi-i3c-hci: Factor out DMA mapping from queuing path
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit f3bcbfe1b8b0b836b772927f75f8cb6e759eb00a upstream.
Prepare for fixing a race in the DMA ring enqueue path when handling parallel transfers. Move all DMA mapping out of hci_dma_queue_xfer() and into a new helper that performs the mapping up front.
This refactoring allows the upcoming fix to extend the spinlock coverage around the enqueue operation without performing DMA mapping under the spinlock.
No functional change is intended in this patch.
--- drivers/i3c/master/mipi-i3c-hci/dma.c | 49 ++++++++++++++++++++++------------ 1 file changed, 33 insertions(+), 16 deletions(-)
drivers/i3c/master/mipi-i3c-hci/dma.c +33 -16
@@ -375,6 +375,33 @@ static void hci_dma_unmap_xfer(struct i3 } } +static struct i3c_dma *hci_dma_map_xfer (struct device *dev,struct hci_xfer *xfer) +{ +enum dma_data_direction dir = xfer->rnw ?DMA_FROM_DEVICE :DMA_TO_DEVICE ; +bool need_bounce =device_iommu_mapped (dev) && xfer->rnw && (xfer->data_len &3 ); + +return i3c_master_dma_map_single (dev, xfer->data, xfer->data_len, need_bounce, dir); +} + +static int hci_dma_map_xfer_list (struct i3c_hci *hci,struct device *dev, +struct hci_xfer *xfer_list,int n) +{ +for (int i =0 ; i < n; i++) { +struct hci_xfer *xfer = xfer_list + i; + +if (!xfer->data) +continue ; + + xfer->dma =hci_dma_map_xfer (dev, xfer); +if (!xfer->dma) { +hci_dma_unmap_xfer (hci, xfer_list, i); +return -ENOMEM ; + } + } + +return 0 ; +} +static int hci_dma_queue_xfer (struct i3c_hci *hci,struct hci_xfer *xfer_list,int n) {
@@ -382,6 +409,11 @@ static int hci_dma_queue_xfer(struct i3cstruct hci_rh_data *rh;unsigned int i, ring, enqueue_ptr;u32 op1_val, op2_val; +int ret; + + ret =hci_dma_map_xfer_list (hci, rings->sysdev, xfer_list, n); +if (ret) +return ret;/* For now we only use ring 0 */ ring =0 ;
@@ -392,9 +424,6 @@ static int hci_dma_queue_xfer(struct i3cfor (i =0 ; i < n; i++) {struct hci_xfer *xfer = xfer_list + i;u32 *ring_data = rh->xfer + rh->xfer_struct_sz * enqueue_ptr; -enum dma_data_direction dir = xfer->rnw ?DMA_FROM_DEVICE : -DMA_TO_DEVICE ; -bool need_bounce;/* store cmd descriptor */ *ring_data++ = xfer->cmd_desc[0 ];
@@ -413,18 +442,6 @@ static int hci_dma_queue_xfer(struct i3c/* 2nd and 3rd words of Data Buffer Descriptor Structure */ if (xfer->data) { - need_bounce =device_iommu_mapped (rings->sysdev) && - xfer->rnw && - xfer->data_len !=ALIGN (xfer->data_len,4 ); - xfer->dma =i3c_master_dma_map_single (rings->sysdev, - xfer->data, - xfer->data_len, - need_bounce, - dir); -if (!xfer->dma) { -hci_dma_unmap_xfer (hci, xfer_list, i); -return -ENOMEM ; - } *ring_data++ =lower_32_bits (xfer->dma->addr); *ring_data++ =upper_32_bits (xfer->dma->addr); }else {
@@ -447,7 +464,7 @@ static int hci_dma_queue_xfer(struct i3c op2_val =rh_reg_read (RING_OPERATION2 );if (enqueue_ptr ==FIELD_GET (RING_OP2_CR_DEQ_PTR , op2_val)) {/* the ring is full */ -hci_dma_unmap_xfer (hci, xfer_list, i +1 ); +hci_dma_unmap_xfer (hci, xfer_list, n);return -EBUSY ; } }
Greg Kroah-Hartman
maintainerPATCH 310/333 i3c: mipi-i3c-hci: Consolidate spinlocks
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit fa12bb903bc3ed1826e355d267fe134bde95e23c upstream.
The MIPI I3C HCI driver currently uses separate spinlocks for different contexts (PIO vs. DMA rings). This split is unnecessary and complicates upcoming fixes. The driver does not support concurrent PIO and DMA operation, and it only supports a single DMA ring, so a single lock is sufficient for all paths.
Introduce a unified spinlock in struct i3c_hci, switch both PIO and DMA code to use it, and remove the per-context locks.
No functional change is intended in this patch.
--- drivers/i3c/master/mipi-i3c-hci/core.c | 2 ++ drivers/i3c/master/mipi-i3c-hci/dma.c | 14 ++++++-------- drivers/i3c/master/mipi-i3c-hci/hci.h | 1 + drivers/i3c/master/mipi-i3c-hci/pio.c | 16 +++++++--------- 4 files changed, 16 insertions(+), 17 deletions(-)
drivers/i3c/master/mipi-i3c-hci/core.c +2 -0
@@ -631,6 +631,8 @@ static int i3c_hci_init(struct i3c_hci *if (ret)return ret; +spin_lock_init (&hci->lock); +/* * Now let's reset the hardware. * SOFT_RST must be clear before we write to it.
drivers/i3c/master/mipi-i3c-hci/dma.c +6 -8
@@ -133,7 +133,6 @@ struct hci_rh_data {unsigned int xfer_struct_sz, resp_struct_sz, ibi_status_sz, ibi_chunk_sz;unsigned int done_ptr, ibi_chunk_ptr;struct hci_xfer **src_xfers; -spinlock_t lock;struct completion op_done; };
@@ -240,7 +239,6 @@ static int hci_dma_init(struct i3c_hci * goto err_out; rh = &rings->headers[i]; rh->regs = hci->base_regs + offset; -spin_lock_init (&rh->lock);init_completion (&rh->op_done); rh->xfer_entries =XFER_RING_ENTRIES ;
@@ -470,12 +468,12 @@ static int hci_dma_queue_xfer(struct i3c }/* take care to update the hardware enqueue pointer atomically */ -spin_lock_irq (&rh->lock); +spin_lock_irq (&hci->lock); op1_val =rh_reg_read (RING_OPERATION1 ); op1_val &= ~RING_OP1_CR_ENQ_PTR ; op1_val |=FIELD_PREP (RING_OP1_CR_ENQ_PTR , enqueue_ptr);rh_reg_write (RING_OPERATION1 , op1_val); -spin_unlock_irq (&rh->lock); +spin_unlock_irq (&hci->lock);return 0 ; }
@@ -573,12 +571,12 @@ static void hci_dma_xfer_done(struct i3c }/* take care to update the software dequeue pointer atomically */ -spin_lock (&rh->lock); +spin_lock (&hci->lock); op1_val =rh_reg_read (RING_OPERATION1 ); op1_val &= ~RING_OP1_CR_SW_DEQ_PTR ; op1_val |=FIELD_PREP (RING_OP1_CR_SW_DEQ_PTR , done_ptr);rh_reg_write (RING_OPERATION1 , op1_val); -spin_unlock (&rh->lock); +spin_unlock (&hci->lock); } static int hci_dma_request_ibi(struct i3c_hci *hci, struct i3c_dev_desc *dev,
@@ -759,12 +757,12 @@ static void hci_dma_process_ibi(struct i done:/* take care to update the ibi dequeue pointer atomically */ -spin_lock (&rh->lock); +spin_lock (&hci->lock); op1_val =rh_reg_read (RING_OPERATION1 ); op1_val &= ~RING_OP1_IBI_DEQ_PTR ; op1_val |=FIELD_PREP (RING_OP1_IBI_DEQ_PTR , deq_ptr);rh_reg_write (RING_OPERATION1 , op1_val); -spin_unlock (&rh->lock); +spin_unlock (&hci->lock);/* update the chunk pointer */ rh->ibi_chunk_ptr += ibi_chunks;
drivers/i3c/master/mipi-i3c-hci/hci.h +1 -0
@@ -45,6 +45,7 @@ struct i3c_hci {const struct hci_io_ops *io;void *io_data;const struct hci_cmd_ops *cmd; +spinlock_t lock;atomic_t next_cmd_tid;u32 caps;unsigned int quirks;
drivers/i3c/master/mipi-i3c-hci/pio.c +7 -9
@@ -124,7 +124,6 @@ struct hci_pio_ibi_data { };struct hci_pio_data { -spinlock_t lock;struct hci_xfer *curr_xfer, *xfer_queue;struct hci_xfer *curr_rx, *rx_queue;struct hci_xfer *curr_tx, *tx_queue;
@@ -146,7 +145,6 @@ static int hci_pio_init(struct i3c_hci *return -ENOMEM ; hci->io_data = pio; -spin_lock_init (&pio->lock); size_val =pio_reg_read (QUEUE_SIZE ); dev_info(&hci->master.dev, "CMD/RESP FIFO = %ld entries\n",
@@ -609,7 +607,7 @@ static int hci_pio_queue_xfer(struct i3c xfer[i].data_left = xfer[i].data_len; } -spin_lock_irq (&pio->lock); +spin_lock_irq (&hci->lock); prev_queue_tail = pio->xfer_queue; pio->xfer_queue = &xfer[n -1 ];if (pio->curr_xfer) {
@@ -623,7 +621,7 @@ static int hci_pio_queue_xfer(struct i3cpio_reg_read (INTR_STATUS ), pio_reg_read(INTR_SIGNAL_ENABLE)); } -spin_unlock_irq (&pio->lock); +spin_unlock_irq (&hci->lock);return 0 ; }
@@ -694,14 +692,14 @@ static bool hci_pio_dequeue_xfer(structstruct hci_pio_data *pio = hci->io_data;int ret; -spin_lock_irq (&pio->lock); +spin_lock_irq (&hci->lock);dev_dbg (&hci->master.dev,"n=%d status=%#x/%#x" , n,pio_reg_read (INTR_STATUS ),pio_reg_read (INTR_SIGNAL_ENABLE ));dev_dbg (&hci->master.dev,"main_status = %#x/%#x" ,readl (hci->base_regs +0x20 ),readl (hci->base_regs +0x28 )); ret =hci_pio_dequeue_xfer_common (hci, pio, xfer, n); -spin_unlock_irq (&pio->lock); +spin_unlock_irq (&hci->lock);return ret; }
@@ -994,13 +992,13 @@ static bool hci_pio_irq_handler(struct istruct hci_pio_data *pio = hci->io_data;u32 status; -spin_lock (&pio->lock); +spin_lock (&hci->lock); status =pio_reg_read (INTR_STATUS );dev_dbg (&hci->master.dev,"PIO_INTR_STATUS %#x/%#x" , status, pio->enabled_irqs); status &= pio->enabled_irqs |STAT_LATENCY_WARNINGS ;if (!status) { -spin_unlock (&pio->lock); +spin_unlock (&hci->lock);return false; }
@@ -1036,7 +1034,7 @@ static bool hci_pio_irq_handler(struct ipio_reg_write (INTR_SIGNAL_ENABLE , pio->enabled_irqs);dev_dbg (&hci->master.dev,"PIO_INTR_STATUS %#x/%#x" ,pio_reg_read (INTR_STATUS ),pio_reg_read (INTR_SIGNAL_ENABLE )); -spin_unlock (&pio->lock); +spin_unlock (&hci->lock);return true; }
Greg Kroah-Hartman
maintainerPATCH 311/333 i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit b6d586431ae20d5157ee468d0ef62ad26798ef13 upstream.
The DMA dequeue path attempts to restart the ring after aborting an in-flight transfer, but the current sequence is incomplete. The controller must be brought out of the aborted state and the ring control registers must be programmed in the correct order: first clearing ABORT, then re-enabling the ring and asserting RUN_STOP to resume operation.
Add the missing controller resume step and update the ring control writes so that the ring is restarted using the proper sequence.
--- drivers/i3c/master/mipi-i3c-hci/dma.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/i3c/master/mipi-i3c-hci/dma.c +2 -0
@@ -528,7 +528,9 @@ static bool hci_dma_dequeue_xfer(struct }/* restart the ring */ +mipi_i3c_hci_resume (hci);rh_reg_write (RING_CONTROL ,RING_CTRL_ENABLE ); +rh_reg_write (RING_CONTROL ,RING_CTRL_ENABLE |RING_CTRL_RUN_STOP );return did_unqueue; }
Greg Kroah-Hartman
maintainerPATCH 312/333 i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit ec3cfd835f7c4bbd23bc9ad909d2fdc772a578bb upstream.
The internal control command descriptor used for no-op commands includes a Transaction ID (TID) field, but the no-op command constructed in hci_dma_dequeue_xfer() omitted it. As a result, the hardware receives a no-op descriptor without the expected TID.
This bug has gone unnoticed because the TID is currently not validated in the no-op completion path, but the descriptor format requires it to be present.
Add the missing TID field when generating a no-op descriptor so that its layout matches the defined command structure.
--- drivers/i3c/master/mipi-i3c-hci/cmd.h | 1 + drivers/i3c/master/mipi-i3c-hci/dma.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/i3c/master/mipi-i3c-hci/cmd.h +1 -0
@@ -17,6 +17,7 @@#define CMD_0_TOC W0_BIT_(31)#define CMD_0_ROC W0_BIT_(30)#define CMD_0_ATTR W0_MASK(2, 0) +#define CMD_0_TID W0_MASK(6, 3)/* * Response Descriptor Structure
drivers/i3c/master/mipi-i3c-hci/dma.c +1 -1
@@ -510,7 +510,7 @@ static bool hci_dma_dequeue_xfer(structu32 *ring_data = rh->xfer + rh->xfer_struct_sz * idx;/* store no-op cmd descriptor */ - *ring_data++ =FIELD_PREP (CMD_0_ATTR ,0x7 ); + *ring_data++ =FIELD_PREP (CMD_0_ATTR ,0x7 ) |FIELD_PREP (CMD_0_TID , xfer->cmd_tid); *ring_data++ =0 ;if (hci->cmd == &mipi_i3c_hci_cmd_v2) { *ring_data++ =0 ;
Greg Kroah-Hartman
maintainerPATCH 313/333 i3c: mipi-i3c-hci: Fix race in DMA ring dequeue
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 1dca8aee80eea76d2aae21265de5dd64f6ba0f09 upstream.
The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for multiple transfers that timeout around the same time. However, the function is not serialized and can race with itself.
When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes incomplete transfers, and then restarts the ring. If another timeout triggers a parallel call into the same function, the two instances may interfere with each other - stopping or restarting the ring at unexpected times.
Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to itself.
--- drivers/i3c/master/mipi-i3c-hci/core.c | 1 + drivers/i3c/master/mipi-i3c-hci/dma.c | 2 ++ drivers/i3c/master/mipi-i3c-hci/hci.h | 1 + 3 files changed, 4 insertions(+)
drivers/i3c/master/mipi-i3c-hci/core.c +1 -0
@@ -632,6 +632,7 @@ static int i3c_hci_init(struct i3c_hci *return ret;spin_lock_init (&hci->lock); +mutex_init (&hci->control_mutex);/* * Now let's reset the hardware.
drivers/i3c/master/mipi-i3c-hci/dma.c +2 -0
@@ -486,6 +486,8 @@ static bool hci_dma_dequeue_xfer(structunsigned int i;bool did_unqueue = false; +guard (mutex)(&hci->control_mutex); +/* stop the ring */ rh_reg_write (RING_CONTROL ,RING_CTRL_ABORT );if (wait_for_completion_timeout (&rh->op_done,HZ ) ==0 ) {
drivers/i3c/master/mipi-i3c-hci/hci.h +1 -0
@@ -46,6 +46,7 @@ struct i3c_hci {void *io_data;const struct hci_cmd_ops *cmd;spinlock_t lock; +struct mutex control_mutex;atomic_t next_cmd_tid;u32 caps;unsigned int quirks;
Greg Kroah-Hartman
maintainerPATCH 314/333 i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit b795e68bf3073d67bebbb5a44d93f49efc5b8cc7 upstream.
The logic used to abort the DMA ring contains several flaws:
1. The driver unconditionally issues a ring abort even when the ring has already stopped.
2. The completion used to wait for abort completion is never re-initialized, resulting in incorrect wait behavior.
3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which resets hardware ring pointers and disrupts the controller state.
4. If the ring is already stopped, the abort operation should be considered successful without attempting further action.
Fix the abort handling by checking whether the ring is running before issuing an abort, re-initializing the completion when needed, ensuring that RING_CTRL_ENABLE remains asserted during abort, and treating an already stopped ring as a successful condition.
--- drivers/i3c/master/mipi-i3c-hci/dma.c | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-)
drivers/i3c/master/mipi-i3c-hci/dma.c +16 -9
@@ -485,18 +485,25 @@ static bool hci_dma_dequeue_xfer(structstruct hci_rh_data *rh = &rings->headers[xfer_list[0 ].ring_number];unsigned int i;bool did_unqueue = false; +u32 ring_status;guard (mutex)(&hci->control_mutex); -/* stop the ring */ -rh_reg_write (RING_CONTROL ,RING_CTRL_ABORT ); -if (wait_for_completion_timeout (&rh->op_done,HZ ) ==0 ) { -/* -* We're deep in it if ever this condition is ever met. -* Hardware might still be writing to memory, etc. -*/ -dev_crit (&hci->master.dev,"unable to abort the ring\n" ); -WARN_ON (1 ); + ring_status =rh_reg_read (RING_STATUS ); +if (ring_status &RING_STATUS_RUNNING ) { +/* stop the ring */ +reinit_completion (&rh->op_done); +rh_reg_write (RING_CONTROL ,RING_CTRL_ENABLE |RING_CTRL_ABORT ); +wait_for_completion_timeout (&rh->op_done,HZ ); + ring_status =rh_reg_read (RING_STATUS ); +if (ring_status &RING_STATUS_RUNNING ) { +/* +* We're deep in it if ever this condition is ever met. +* Hardware might still be writing to memory, etc. +*/ +dev_crit (&hci->master.dev,"unable to abort the ring\n" ); +WARN_ON (1 ); + } }for (i =0 ; i < n; i++) {
Greg Kroah-Hartman
maintainerPATCH 315/333 cxl/acpi: Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keith Busch <[email protected]>
commit 93d0fcdddc9e7be9d4f42acbe57bc90dbb0fe75d upstream.
Commit e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko") moves devm_cxl_add_nvdimm_bridge() into the cxl_pmem file, which has independent config compile options for built-in or module. The call from cxl_acpi_probe() is guarded by IS_ENABLED(CONFIG_CXL_PMEM), which evaluates to true for both =y and =m.
When CONFIG_CXL_PMEM=m, a built-in cxl_acpi attempts to reference a symbol exported by a module, which fails to link. CXL_PMEM cannot simply be promoted to =y in this configuration because it depends on LIBNVDIMM, which may itself be =m.
Add a Kconfig dependency to prevent CXL_ACPI from being built-in when CXL_PMEM is a module. This contrains CXL_ACPI to =m when CXL_PMEM=m, while still allowing CXL_ACPI to be freely configured when CXL_PMEM is either built-in or disabled.
[ dj: Fix up commit reference formatting. ]
--- drivers/cxl/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/cxl/Kconfig +1 -0
@@ -58,6 +58,7 @@ config CXL_ACPI tristate "CXL ACPI: Platform Support" depends on ACPI depends on ACPI_NUMA + depends on CXL_PMEM || !CXL_PMEM default CXL_BUS select ACPI_TABLE_LIB select ACPI_HMAT
Greg Kroah-Hartman
maintainerPATCH 316/333 mm: Fix a hmm_range_fault() livelock / starvation problem
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellström <[email protected]>
commit b570f37a2ce480be26c665345c5514686a8a0274 upstream.
If hmm_range_fault() fails a folio_trylock() in do_swap_page, trying to acquire the lock of a device-private folio for migration, to ram, the function will spin until it succeeds grabbing the lock.
However, if the process holding the lock is depending on a work item to be completed, which is scheduled on the same CPU as the spinning hmm_range_fault(), that work item might be starved and we end up in a livelock / starvation situation which is never resolved.
This can happen, for example if the process holding the device-private folio lock is stuck in
migrate_device_unmap()->lru_add_drain_all()
sinc lru_add_drain_all() requires a short work-item to be run on all online cpus to complete.
A prerequisite for this to happen is:
a) Both zone device and system memory folios are considered in migrate_device_unmap(), so that there is a reason to call lru_add_drain_all() for a system memory folio while a folio lock is held on a zone device folio.
b) The zone device folio has an initial mapcount > 1 which causes at least one migration PTE entry insertion to be deferred to try_to_migrate(), which can happen after the call to lru_add_drain_all().
c) No or voluntary only preemption.
This all seems pretty unlikely to happen, but indeed is hit by the "xe_exec_system_allocator" igt test.
Resolve this by waiting for the folio to be unlocked if the folio_trylock() fails in do_swap_page().
Rename migration_entry_wait_on_locked() to softleaf_entry_wait_unlock() and update its documentation to indicate the new use-case.
Future code improvements might consider moving
the lru_add_drain_all() call in migrate_device_unmap() to be called *after* all pages have migration entries inserted. That would eliminate also b) above.
v2:
- Instead of a cond_resched() in hmm_range_fault(), eliminate the problem by waiting for the folio to be unlocked in do_swap_page() (Alistair Popple, Andrew Morton)
v3:
- Add a stub migration_entry_wait_on_locked() for the !CONFIG_MIGRATION case. (Kernel Test Robot)
v4:
- Rename migrate_entry_wait_on_locked() to softleaf_entry_wait_on_locked() and update docs (Alistair Popple)
v5:
- Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION
version of softleaf_entry_wait_on_locked().
- Modify wording around function names in the commit message (Andrew Morton)
--- include/linux/migrate.h | 8 ++++++++ mm/filemap.c | 13 +++++++++---- mm/memory.c | 3 ++- 3 files changed, 19 insertions(+), 5 deletions(-)
include/linux/migrate.h +8 -0
@@ -97,6 +97,14 @@ static inline int set_movable_ops(const return -ENOSYS; } +static inline void migration_entry_wait_on_locked (swp_entry_t entry,spinlock_t *ptl) +__releases (ptl) +{ +WARN_ON_ONCE (1 ); + +spin_unlock (ptl); +} +#endif /* CONFIG_MIGRATION */ #ifdef CONFIG_NUMA_BALANCING
mm/filemap.c +9 -4
@@ -1386,14 +1386,16 @@ repeat:#ifdef CONFIG_MIGRATION /** -* migration_entry_wait_on_locked - Wait for a migration entry to be removed -* @entry: migration swap entry. +* migration_entry_wait_on_locked - Wait for a migration entry or +* device_private entry to be removed. +* @entry: migration or device_private swap entry. * @ptl: already locked ptl. This function will drop the lock. * -* Wait for a migration entry referencing the given page to be removed. This is +* Wait for a migration entry referencing the given page, or device_private +* entry referencing a dvice_private page to be unlocked. This is * equivalent to folio_put_wait_locked(folio, TASK_UNINTERRUPTIBLE) except * this can be called without taking a reference on the page. Instead this -* should be called while holding the ptl for the migration entry referencing +* should be called while holding the ptl for @entry referencing * the page. * * Returns after unlocking the ptl.
@@ -1435,6 +1437,9 @@ void migration_entry_wait_on_locked(swp_* If a migration entry exists for the page the migration path must hold * a valid reference to the page, and it must take the ptl to remove the * migration entry. So the page is valid until the ptl is dropped. +* Similarly any path attempting to drop the last reference to a +* device-private page needs to grab the ptl to remove the device-private +* entry. */ spin_unlock (ptl);
mm/memory.c +2 -1
@@ -4642,7 +4642,8 @@ vm_fault_t do_swap_page(struct vm_faultunlock_page (vmf->page);put_page (vmf->page); }else { -pte_unmap_unlock (vmf->pte, vmf->ptl); +pte_unmap (vmf->pte); +migration_entry_wait_on_locked (entry, vmf->ptl); } }else if (is_hwpoison_entry (entry)) { ret =VM_FAULT_HWPOISON ;
Greg Kroah-Hartman
maintainerPATCH 317/333 drm/gud: rearrange gud_probe() to prepare for function splitting
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ruben Wauters <[email protected]>
[ Upstream commit b9e5e9d2c187b849e050d59823e8c834f78475ab ]
gud_probe() is currently very large and does many things, including pipeline setup and feature detection, as well as having USB functions.
This patch re-orders the code in gud_probe() to make it more organised and easier to split apart in the future.
Stable-dep-of: 7149be786da0 ("drm/gud: fix NULL crtc dereference on display disable")
--- drivers/gpu/drm/gud/gud_drv.c | 45 ++++++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 21 deletions(-)
drivers/gpu/drm/gud/gud_drv.c +24 -21
@@ -249,7 +249,7 @@ int gud_usb_set_u8(struct gud_device *gdreturn gud_usb_set (gdrm, request,0 , &val,sizeof (val)); } -static int gud_get_properties (struct gud_device *gdrm) +static int gud_plane_add_properties (struct gud_device *gdrm) {struct gud_property_req *properties;unsigned int i, num_properties;
@@ -463,10 +463,6 @@ static int gud_probe(struct usb_interfacreturn PTR_ERR (gdrm); drm = &gdrm->drm; - drm->mode_config.funcs = &gud_mode_config_funcs; - ret =drmm_mode_config_init (drm); -if (ret) -return ret; gdrm->flags =le32_to_cpu (desc.flags); gdrm->compression = desc.compression &GUD_COMPRESSION_LZ4 ;
@@ -483,11 +479,28 @@ static int gud_probe(struct usb_interfacif (ret)return ret; +usb_set_intfdata (intf, gdrm); + + dma_dev =usb_intf_get_dma_device (intf); +if (dma_dev) { +drm_dev_set_dma_dev (drm, dma_dev); +put_device (dma_dev); + }else { +dev_warn (dev,"buffer sharing not supported" );/* not an error */ + } + +/* Mode config init */ + ret =drmm_mode_config_init (drm); +if (ret) +return ret; + drm->mode_config.min_width =le32_to_cpu (desc.min_width); drm->mode_config.max_width =le32_to_cpu (desc.max_width); drm->mode_config.min_height =le32_to_cpu (desc.min_height); drm->mode_config.max_height =le32_to_cpu (desc.max_height); + drm->mode_config.funcs = &gud_mode_config_funcs; +/* Format init */ formats_dev =devm_kmalloc (dev,GUD_FORMATS_MAX_NUM ,GFP_KERNEL );/* Add room for emulated XRGB8888 */ formats =devm_kmalloc_array (dev,GUD_FORMATS_MAX_NUM +1 ,sizeof (*formats),GFP_KERNEL );
@@ -587,6 +600,7 @@ static int gud_probe(struct usb_interfacreturn -ENOMEM ; } +/* Pipeline init */ ret = drm_universal_plane_init(drm, &gdrm->plane, 0, &gud_plane_funcs, formats, num_formats,
@@ -598,12 +612,9 @@ static int gud_probe(struct usb_interfacdrm_plane_helper_add (&gdrm->plane, &gud_plane_helper_funcs);drm_plane_enable_fb_damage_clips (&gdrm->plane); -devm_kfree (dev, formats); -devm_kfree (dev, formats_dev); - - ret =gud_get_properties (gdrm); + ret =gud_plane_add_properties (gdrm);if (ret) { -dev_err (dev,"Failed to get properties (error=%d)\n" , ret); +dev_err (dev,"Failed to add properties (error=%d)\n" , ret);return ret; }
@@ -621,16 +632,7 @@ static int gud_probe(struct usb_interfac }drm_mode_config_reset (drm); - -usb_set_intfdata (intf, gdrm); - - dma_dev =usb_intf_get_dma_device (intf); -if (dma_dev) { -drm_dev_set_dma_dev (drm, dma_dev); -put_device (dma_dev); - }else { -dev_warn (dev,"buffer sharing not supported" );/* not an error */ - } +drm_kms_helper_poll_init (drm);drm_debugfs_add_file (drm,"stats" , gud_stats_debugfs,NULL );
@@ -638,7 +640,8 @@ static int gud_probe(struct usb_interfacif (ret)return ret; -drm_kms_helper_poll_init (drm); +devm_kfree (dev, formats); +devm_kfree (dev, formats_dev);drm_client_setup (drm,NULL );
Greg Kroah-Hartman
maintainerPATCH 318/333 drm/gud: fix NULL crtc dereference on display disable
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shenghao Yang <[email protected]>
[ Upstream commit 7149be786da012afc6bae293d38f8c1fff1fb90d ]
gud_plane_atomic_update() currently handles both crtc state and framebuffer updates - the complexity has led to a few accidental NULL pointer dereferences.
Commit dc2d5ddb193e ("drm/gud: fix NULL fb and crtc dereferences on USB disconnect") [1] fixed an earlier dereference but planes can also be disabled in non-hotplug paths (e.g. display disables via the desktop environment). The drm_dev_enter() call would not cause an early return in those and subsequently oops on dereferencing crtc:
BUG: kernel NULL pointer dereference, address: 00000000000005c8 CPU: 6 UID: 1000 PID: 3473 Comm: kwin_wayland Not tainted 6.18.2-200.vanilla.gud.fc42.x86_64 #1 PREEMPT(lazy) RIP: 0010:gud_plane_atomic_update+0x148/0x470 [gud] <TASK> drm_atomic_helper_commit_planes+0x28e/0x310 drm_atomic_helper_commit_tail+0x2a/0x70 commit_tail+0xf1/0x150 drm_atomic_helper_commit+0x13c/0x180 drm_atomic_commit+0xb1/0xe0 info ? __pfx___drm_printfn_info+0x10/0x10 drm_mode_atomic_ioctl+0x70f/0x7c0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xae/0x100 drm_ioctl+0x2a8/0x550 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x7e/0x7f0 ? __ct_user_enter+0x56/0xd0 ? do_syscall_64+0x158/0x7f0 ? __ct_user_enter+0x56/0xd0 ? do_syscall_64+0x158/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Split out crtc handling from gud_plane_atomic_update() into atomic_enable() and atomic_disable() functions to delegate crtc state transitioning work to the DRM helpers.
To preserve the gud state commit sequence [2], switch to the runtime PM version of drm_atomic_helper_commit_tail() which ensures that crtcs are enabled (hence sending the GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE requests) before a framebuffer update is sent.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://github.com/notro/gud/wiki/GUD-Protocol#display-state
--- drivers/gpu/drm/gud/gud_drv.c | 9 +++++- drivers/gpu/drm/gud/gud_internal.h | 4 ++ drivers/gpu/drm/gud/gud_pipe.c | 54 ++++++++++++++++++++++++------------- 3 files changed, 48 insertions(+), 19 deletions(-)
drivers/gpu/drm/gud/gud_drv.c +8 -1
@@ -339,7 +339,9 @@ static int gud_stats_debugfs(struct seq_ }static const struct drm_crtc_helper_funcs gud_crtc_helper_funcs = { - .atomic_check = drm_crtc_helper_atomic_check + .atomic_check = drm_crtc_helper_atomic_check, + .atomic_enable = gud_crtc_atomic_enable, + .atomic_disable = gud_crtc_atomic_disable, };static const struct drm_crtc_funcs gud_crtc_funcs = {
@@ -364,6 +366,10 @@ static const struct drm_plane_funcs gud_ DRM_GEM_SHADOW_PLANE_FUNCS, }; +static const struct drm_mode_config_helper_funcs gud_mode_config_helpers = { + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm, +}; +static const struct drm_mode_config_funcs gud_mode_config_funcs = { .fb_create = drm_gem_fb_create_with_dirty, .atomic_check = drm_atomic_helper_check,
@@ -499,6 +505,7 @@ static int gud_probe(struct usb_interfac drm->mode_config.min_height =le32_to_cpu (desc.min_height); drm->mode_config.max_height =le32_to_cpu (desc.max_height); drm->mode_config.funcs = &gud_mode_config_funcs; + drm->mode_config.helper_private = &gud_mode_config_helpers;/* Format init */ formats_dev =devm_kmalloc (dev,GUD_FORMATS_MAX_NUM ,GFP_KERNEL );
drivers/gpu/drm/gud/gud_internal.h +4 -0
@@ -62,6 +62,10 @@ int gud_usb_set_u8(struct gud_device *gdvoid gud_clear_damage (struct gud_device *gdrm);void gud_flush_work (struct work_struct *work); +void gud_crtc_atomic_enable (struct drm_crtc *crtc, +struct drm_atomic_state *state); +void gud_crtc_atomic_disable (struct drm_crtc *crtc, +struct drm_atomic_state *state);int gud_plane_atomic_check (struct drm_plane *plane,struct drm_atomic_state *state); void gud_plane_atomic_update(struct drm_plane *plane,
drivers/gpu/drm/gud/gud_pipe.c +36 -18
75 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 319/333 mmc: dw_mmc-rockchip: Add memory clock auto-gating support
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
[ Upstream commit ff6f0286c896f062853552097220dd93961be9c4 ]
Per design recommendations, the memory clock can be gated when there is no in-flight transfer, which helps save power. This feature is introduced alongside internal phase support, and this patch enables it.
Stable-dep-of: 6465a8bbb0f6 ("mmc: dw_mmc-rockchip: Fix runtime PM support for internal phase support")
--- drivers/mmc/host/dw_mmc-rockchip.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/mmc/host/dw_mmc-rockchip.c +6 -0
@@ -19,6 +19,8 @@#define RK3288_CLKGEN_DIV 2#define SDMMC_TIMING_CON0 0x130#define SDMMC_TIMING_CON1 0x134 +#define SDMMC_MISC_CON 0x138 +#define MEM_CLK_AUTOGATE_ENABLE BIT(5)#define ROCKCHIP_MMC_DELAY_SEL BIT(10)#define ROCKCHIP_MMC_DEGREE_MASK 0x3#define ROCKCHIP_MMC_DEGREE_OFFSET 1
@@ -470,6 +472,7 @@ static int dw_mci_rk3576_parse_dt(structstatic int dw_mci_rockchip_init (struct dw_mci *host) { +struct dw_mci_rockchip_priv_data *priv = host->priv;int ret, i;/* It is slot 8 on Rockchip SoCs */
@@ -494,6 +497,9 @@ static int dw_mci_rockchip_init(struct ddev_warn (host->dev,"no valid minimum freq: %d\n" , ret); } +if (priv->internal_phase) +mci_writel (host,MISC_CON ,MEM_CLK_AUTOGATE_ENABLE ); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 320/333 mmc: dw_mmc-rockchip: Fix runtime PM support for internal phase support
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
[ Upstream commit 6465a8bbb0f6ad98aeb66dc9ea19c32c193a610b ]
RK3576 is the first platform to introduce internal phase support, and subsequent platforms are expected to adopt a similar design. In this architecture, runtime suspend powers off the attached power domain, which resets registers, including vendor-specific ones such as SDMMC_TIMING_CON0, SDMMC_TIMING_CON1, and SDMMC_MISC_CON. These registers must be saved and restored, a requirement that falls outside the scope of the dw_mmc core.
--- drivers/mmc/host/dw_mmc-rockchip.c | 38 ++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
drivers/mmc/host/dw_mmc-rockchip.c +37 -1
@@ -36,6 +36,8 @@ struct dw_mci_rockchip_priv_data {int default_sample_phase;int num_phases;bool internal_phase; +int sample_phase; +int drv_phase; };/*
@@ -574,9 +576,43 @@ static void dw_mci_rockchip_remove(strucdw_mci_pltfm_remove (pdev); } +static int dw_mci_rockchip_runtime_suspend (struct device *dev) +{ +struct platform_device *pdev =to_platform_device (dev); +struct dw_mci *host =platform_get_drvdata (pdev); +struct dw_mci_rockchip_priv_data *priv = host->priv; + +if (priv->internal_phase) { + priv->sample_phase =rockchip_mmc_get_phase (host, true); + priv->drv_phase =rockchip_mmc_get_phase (host, false); + } + +return dw_mci_runtime_suspend (dev); +} + +static int dw_mci_rockchip_runtime_resume (struct device *dev) +{ +struct platform_device *pdev =to_platform_device (dev); +struct dw_mci *host =platform_get_drvdata (pdev); +struct dw_mci_rockchip_priv_data *priv = host->priv; +int ret; + + ret =dw_mci_runtime_resume (dev); +if (ret) +return ret; + +if (priv->internal_phase) { +rockchip_mmc_set_phase (host, true, priv->sample_phase); +rockchip_mmc_set_phase (host, false, priv->drv_phase); +mci_writel (host,MISC_CON ,MEM_CLK_AUTOGATE_ENABLE ); + } + +return ret; +} +static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = { SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) -RUNTIME_PM_OPS (dw_mci_runtime_suspend, dw_mci_runtime_resume,NULL ) +RUNTIME_PM_OPS (dw_mci_rockchip_runtime_suspend, dw_mci_rockchip_runtime_resume,NULL ) };static struct platform_driver dw_mci_rockchip_pltfm_driver = {
Greg Kroah-Hartman
maintainerPATCH 321/333 KVM: arm64: gic: Set vgic_model before initing private IRQs
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sascha Bischoff <[email protected]>
[ Upstream commit 9435c1e1431003e23aa34ef8e46c30d09c3dbcb5 ]
Different GIC types require the private IRQs to be initialised differently. GICv5 is the culprit as it supports both a different number of private IRQs, and all of these are PPIs (there are no SGIs). Moreover, as GICv5 uses the top bits of the interrupt ID to encode the type, the intid also needs to computed differently.
Up until now, the GIC model has been set after initialising the private IRQs for a VCPU. Move this earlier to ensure that the GIC model is available when configuring the private IRQs. While we're at it, also move the setting of the in_kernel flag and implementation revision to keep them grouped together as before.
Stable-dep-of: ac6769c8f948 ("KVM: arm64: Eagerly init vgic dist/redist on vgic creation")
--- arch/arm64/kvm/vgic/vgic-init.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/kvm/vgic/vgic-init.c +4 -4
@@ -140,6 +140,10 @@ int kvm_vgic_create(struct kvm *kvm, u32 goto out_unlock; } + kvm->arch.vgic.in_kernel = true; + kvm->arch.vgic.vgic_model = type; + kvm->arch.vgic.implementation_rev =KVM_VGIC_IMP_REV_LATEST ; +kvm_for_each_vcpu (i, vcpu, kvm) { ret =vgic_allocate_private_irqs_locked (vcpu, type);if (ret)
@@ -156,10 +160,6 @@ int kvm_vgic_create(struct kvm *kvm, u32 goto out_unlock; } - kvm->arch.vgic.in_kernel = true; - kvm->arch.vgic.vgic_model = type; - kvm->arch.vgic.implementation_rev =KVM_VGIC_IMP_REV_LATEST ; - kvm->arch.vgic.vgic_dist_base =VGIC_ADDR_UNDEF ; aa64pfr0 =kvm_read_vm_id_reg (kvm,SYS_ID_AA64PFR0_EL1 ) & ~ID_AA64PFR0_EL1_GIC ;
Greg Kroah-Hartman
maintainerPATCH 322/333 KVM: arm64: Eagerly init vgic dist/redist on vgic creation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
[ Upstream commit ac6769c8f948dff33265c50e524aebf9aa6f1be0 ]
If vgic_allocate_private_irqs_locked() fails for any odd reason, we exit kvm_vgic_create() early, leaving dist->rd_regions uninitialised.
kvm_vgic_dist_destroy() then comes along and walks into the weeds trying to free the RDs. Got to love this stuff.
Solve it by moving all the static initialisation early, and make sure that if we fail halfway, we're in a reasonable shape to perform the rest of the teardown. While at it, reset the vgic model on failure, just in case...
--- arch/arm64/kvm/vgic/vgic-init.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-)
arch/arm64/kvm/vgic/vgic-init.c +16 -16
@@ -143,6 +143,21 @@ int kvm_vgic_create(struct kvm *kvm, u32 kvm->arch.vgic.in_kernel = true; kvm->arch.vgic.vgic_model = type; kvm->arch.vgic.implementation_rev =KVM_VGIC_IMP_REV_LATEST ; + kvm->arch.vgic.vgic_dist_base =VGIC_ADDR_UNDEF ; + + aa64pfr0 =kvm_read_vm_id_reg (kvm,SYS_ID_AA64PFR0_EL1 ) & ~ID_AA64PFR0_EL1_GIC ; + pfr1 =kvm_read_vm_id_reg (kvm,SYS_ID_PFR1_EL1 ) & ~ID_PFR1_EL1_GIC ; + +if (type ==KVM_DEV_TYPE_ARM_VGIC_V2 ) { + kvm->arch.vgic.vgic_cpu_base =VGIC_ADDR_UNDEF ; + }else { +INIT_LIST_HEAD (&kvm->arch.vgic.rd_regions); + aa64pfr0 |=SYS_FIELD_PREP_ENUM (ID_AA64PFR0_EL1 ,GIC ,IMP ); + pfr1 |=SYS_FIELD_PREP_ENUM (ID_PFR1_EL1 ,GIC , GICv3); + } + +kvm_set_vm_id_reg (kvm,SYS_ID_AA64PFR0_EL1 , aa64pfr0); +kvm_set_vm_id_reg (kvm,SYS_ID_PFR1_EL1 , pfr1);kvm_for_each_vcpu (i, vcpu, kvm) { ret =vgic_allocate_private_irqs_locked (vcpu, type);
@@ -157,25 +172,10 @@ int kvm_vgic_create(struct kvm *kvm, u32 vgic_cpu->private_irqs =NULL ; } + kvm->arch.vgic.vgic_model =0 ; goto out_unlock; } - kvm->arch.vgic.vgic_dist_base =VGIC_ADDR_UNDEF ; - - aa64pfr0 =kvm_read_vm_id_reg (kvm,SYS_ID_AA64PFR0_EL1 ) & ~ID_AA64PFR0_EL1_GIC ; - pfr1 =kvm_read_vm_id_reg (kvm,SYS_ID_PFR1_EL1 ) & ~ID_PFR1_EL1_GIC ; - -if (type ==KVM_DEV_TYPE_ARM_VGIC_V2 ) { - kvm->arch.vgic.vgic_cpu_base =VGIC_ADDR_UNDEF ; - }else { -INIT_LIST_HEAD (&kvm->arch.vgic.rd_regions); - aa64pfr0 |=SYS_FIELD_PREP_ENUM (ID_AA64PFR0_EL1 ,GIC ,IMP ); - pfr1 |=SYS_FIELD_PREP_ENUM (ID_PFR1_EL1 ,GIC , GICv3); - } - -kvm_set_vm_id_reg (kvm,SYS_ID_AA64PFR0_EL1 , aa64pfr0); -kvm_set_vm_id_reg (kvm,SYS_ID_PFR1_EL1 , pfr1); -if (type ==KVM_DEV_TYPE_ARM_VGIC_V3 ) kvm->arch.vgic.nassgicap =system_supports_direct_sgis ();
Greg Kroah-Hartman
maintainerPATCH 323/333 KVM: SVM: Limit AVIC physical max index based on configured max_vcpu_ids
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naveen N Rao <[email protected]>
[ Upstream commit 574ef752d4aea04134bc121294d717f4422c2755 ]
KVM allows VMMs to specify the maximum possible APIC ID for a virtual machine through KVM_CAP_MAX_VCPU_ID capability so as to limit data structures related to APIC/x2APIC. Utilize the same to set the AVIC physical max index in the VMCB, similar to VMX. This helps hardware limit the number of entries to be scanned in the physical APIC ID table speeding up IPI broadcasts for virtual machines with smaller number of vCPUs.
Unlike VMX, SVM AVIC requires a single page to be allocated for the Physical APIC ID table and the Logical APIC ID table, so retain the existing approach of allocating those during VM init.
Stable-dep-of: 87d0f901a9bd ("KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated")
--- arch/x86/kvm/svm/avic.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/x86/kvm/svm/avic.c +5 -2
@@ -161,6 +161,7 @@ static void avic_set_x2apic_msr_intercepstatic void avic_activate_vmcb (struct vcpu_svm *svm) {struct vmcb *vmcb = svm->vmcb01.ptr; +struct kvm *kvm = svm->vcpu.kvm; vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK |X2APIC_MODE_MASK ); vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK ;
@@ -176,7 +177,8 @@ static void avic_activate_vmcb(struct vc*/ if (x2avic_enabled &&apic_x2apic_mode (svm->vcpu.arch.apic)) { vmcb->control.int_ctl |=X2APIC_MODE_MASK ; - vmcb->control.avic_physical_id |=X2AVIC_MAX_PHYSICAL_ID ; + vmcb->control.avic_physical_id |=min (kvm->arch.max_vcpu_ids -1 , +X2AVIC_MAX_PHYSICAL_ID );/* Disabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception (svm, false); }else {
@@ -187,7 +189,8 @@ static void avic_activate_vmcb(struct vckvm_make_request (KVM_REQ_TLB_FLUSH_CURRENT , &svm->vcpu);/* For xAVIC and hybrid-xAVIC modes */ - vmcb->control.avic_physical_id |=AVIC_MAX_PHYSICAL_ID ; + vmcb->control.avic_physical_id |=min (kvm->arch.max_vcpu_ids -1 , +AVIC_MAX_PHYSICAL_ID );/* Enabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception (svm, true); }
Greg Kroah-Hartman
maintainerPATCH 324/333 KVM: SVM: Add a helper to look up the max physical ID for AVIC
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naveen N Rao <[email protected]>
[ Upstream commit f2f6e67a56dc88fea7e9b10c4e79bb01d97386b7 ]
To help with a future change, add a helper to look up the maximum physical ID depending on the vCPU AVIC mode. No functional change intended.
Stable-dep-of: 87d0f901a9bd ("KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated")
--- arch/x86/kvm/svm/avic.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-)
arch/x86/kvm/svm/avic.c +20 -6
@@ -158,13 +158,31 @@ static void avic_set_x2apic_msr_intercep svm->x2avic_msrs_intercepted = intercept; } +static u32 avic_get_max_physical_id (struct kvm_vcpu *vcpu) +{ +u32 arch_max; + +if (x2avic_enabled &&apic_x2apic_mode (vcpu->arch.apic)) + arch_max =X2AVIC_MAX_PHYSICAL_ID ; +else + arch_max =AVIC_MAX_PHYSICAL_ID ; + +/* +* Despite its name, KVM_CAP_MAX_VCPU_ID represents the maximum APIC ID +* plus one, so the max possible APIC ID is one less than that. +*/ +return min (vcpu->kvm->arch.max_vcpu_ids -1 , arch_max); +} +static void avic_activate_vmcb (struct vcpu_svm *svm) {struct vmcb *vmcb = svm->vmcb01.ptr; -struct kvm *kvm = svm->vcpu.kvm; +struct kvm_vcpu *vcpu = &svm->vcpu; vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK |X2APIC_MODE_MASK ); + vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK ; + vmcb->control.avic_physical_id |=avic_get_max_physical_id (vcpu); vmcb->control.int_ctl |=AVIC_ENABLE_MASK ;
@@ -177,8 +195,7 @@ static void avic_activate_vmcb(struct vc*/ if (x2avic_enabled &&apic_x2apic_mode (svm->vcpu.arch.apic)) { vmcb->control.int_ctl |=X2APIC_MODE_MASK ; - vmcb->control.avic_physical_id |=min (kvm->arch.max_vcpu_ids -1 , -X2AVIC_MAX_PHYSICAL_ID ); +/* Disabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception (svm, false); }else {
@@ -188,9 +205,6 @@ static void avic_activate_vmcb(struct vc*/ kvm_make_request (KVM_REQ_TLB_FLUSH_CURRENT , &svm->vcpu); -/* For xAVIC and hybrid-xAVIC modes */ - vmcb->control.avic_physical_id |=min (kvm->arch.max_vcpu_ids -1 , -AVIC_MAX_PHYSICAL_ID );/* Enabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception (svm, true); }
Greg Kroah-Hartman
maintainerPATCH 325/333 KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
[ Upstream commit 87d0f901a9bd8ae6be57249c737f20ac0cace93d ]
Explicitly set/clear CR8 write interception when AVIC is (de)activated to fix a bug where KVM leaves the interception enabled after AVIC is activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8 will remain intercepted in perpetuity.
On its own, the dangling CR8 intercept is "just" a performance issue, but combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:
Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging intercept is fatal to Windows guests as the TPR seen by hardware gets wildly out of sync with reality.
Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in KVM's world. I.e. there's no need to trigger update_cr8_intercept(), this is firmly an SVM implementation flaw/detail.
WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should never enter the guest with AVIC enabled and CR8 writes intercepted.
--- arch/x86/kvm/svm/avic.c | 7 +++++-- arch/x86/kvm/svm/svm.c | 7 ++++--- 2 files changed, 9 insertions(+), 5 deletions(-)
arch/x86/kvm/svm/avic.c +5 -2
@@ -180,12 +180,12 @@ static void avic_activate_vmcb(struct vcstruct kvm_vcpu *vcpu = &svm->vcpu; vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK |X2APIC_MODE_MASK ); - vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK ; vmcb->control.avic_physical_id |=avic_get_max_physical_id (vcpu); - vmcb->control.int_ctl |=AVIC_ENABLE_MASK ; +svm_clr_intercept (svm,INTERCEPT_CR8_WRITE ); +/* * Note: KVM supports hybrid-AVIC mode, where KVM emulates x2APIC MSR * accesses, while interrupt injection to a running vCPU can be
@@ -217,6 +217,9 @@ static void avic_deactivate_vmcb(struct vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK |X2APIC_MODE_MASK ); vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK ; +if (!sev_es_guest (svm->vcpu.kvm)) +svm_set_intercept (svm,INTERCEPT_CR8_WRITE ); +/* * If running nested and the guest uses its own MSR bitmap, there * is no need to update L0's msr bitmap
arch/x86/kvm/svm/svm.c +4 -3
@@ -1032,8 +1032,7 @@ static void init_vmcb(struct kvm_vcpu *vsvm_set_intercept (svm,INTERCEPT_CR0_WRITE );svm_set_intercept (svm,INTERCEPT_CR3_WRITE );svm_set_intercept (svm,INTERCEPT_CR4_WRITE ); -if (!kvm_vcpu_apicv_active (vcpu)) -svm_set_intercept (svm,INTERCEPT_CR8_WRITE ); +svm_set_intercept (svm,INTERCEPT_CR8_WRITE );set_dr_intercepts (svm);
@@ -2598,9 +2597,11 @@ static int dr_interception(struct kvm_vcstatic int cr8_write_interception (struct kvm_vcpu *vcpu) { +u8 cr8_prev =kvm_get_cr8 (vcpu);int r; -u8 cr8_prev =kvm_get_cr8 (vcpu); +WARN_ON_ONCE (kvm_vcpu_apicv_active (vcpu)); +/* instruction emulation calls kvm_set_cr8() */ r =cr_interception (vcpu);if (lapic_in_kernel (vcpu))
Greg Kroah-Hartman
maintainerPATCH 326/333 kbuild: Leave objtool binary around with make clean
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
[ Upstream commit fdb12c8a24a453bdd6759979b6ef1e04ebd4beb4 ]
The difference between 'make clean' and 'make mrproper' is documented in 'make help' as:
clean - Remove most generated files but keep the config and
enough build support to build external modules
mrproper - Remove all generated files + config + various backup files
After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean target"), running 'make clean' then attempting to build an external module with the resulting build directory fails with
$ make ARCH=x86_64 O=build clean
$ make -C build M=... MO=... ... /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory
as 'make clean' removes the objtool binary.
Split the objtool clean target into mrproper and clean like Kbuild does and remove all generated artifacts with 'make clean' except for the objtool binary, which is removed with 'make mrproper'. To avoid a small race when running the objtool clean target through both objtool_mrproper and objtool_clean when running 'make mrproper', modify objtool's clean up find command to avoid using find's '-delete' command by piping the files into 'xargs rm -f' like the rest of Kbuild does.
--- Makefile | 8 ++++---- tools/objtool/Makefile | 8 +++++--- 2 files changed, 9 insertions(+), 7 deletions(-)
Makefile +4 -4
@@ -1441,13 +1441,13 @@ ifneq ($(wildcard $(resolve_btfids_O)),) $(Q)$(MAKE) -sC $(srctree)/tools/bpf/resolve_btfids O=$(resolve_btfids_O) clean endif -PHONY += objtool_clean +PHONY += objtool_clean objtool_mrproper objtool_O = $(abspath $(objtree))/tools/objtool -objtool_clean: +objtool_clean objtool_mrproper: ifneq ($(wildcard $(objtool_O)),) - $(Q)$(MAKE) -sC $(abs_srctree)/tools/objtool O=$(objtool_O) srctree=$(abs_srctree) clean + $(Q)$(MAKE) -sC $(abs_srctree)/tools/objtool O=$(objtool_O) srctree=$(abs_srctree) $(patsubst objtool_%,%,$@) endif tools/: FORCE
@@ -1624,7 +1624,7 @@ PHONY += $(mrproper-dirs) mrproper $(mrproper-dirs): $(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@) -mrproper: clean $(mrproper-dirs) +mrproper: clean objtool_mrproper $(mrproper-dirs) $(call cmd,rmfiles) @find . $(RCS_FIND_IGNORE) \ \( -name '*.rmeta' \) \
tools/objtool/Makefile +5 -3
@@ -86,10 +86,12 @@ $(LIBSUBCMD)-clean: $(Q)$(RM) -r -- $(LIBSUBCMD_OUTPUT) clean: $(LIBSUBCMD)-clean - $(call QUIET_CLEAN, objtool) $(RM) $(OBJTOOL) - $(Q)find $(OUTPUT) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete + $(Q)find $(OUTPUT) \( -name '*.o' -o -name '\.*.cmd' -o -name '\.*.d' \) -type f -print | xargs $(RM) $(Q)$(RM) $(OUTPUT)arch/x86/lib/inat-tables.c $(OUTPUT)fixdep +mrproper: clean + $(call QUIET_CLEAN, objtool) $(RM) $(OBJTOOL) + FORCE: -.PHONY: clean FORCE +.PHONY: clean mrproper FORCE
Greg Kroah-Hartman
maintainerPATCH 327/333 smb: client: Compare MACs in constant time
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 26bc83b88bbbf054f0980a4a42047a8d1e210e4c upstream.
To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().
--- fs/smb/client/cifsencrypt.c | 3 ++- fs/smb/client/smb2transport.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-)
fs/smb/client/cifsencrypt.c +2 -1
@@ -26,6 +26,7 @@#include <crypto/arc4.h> #include <crypto/md5.h> #include <crypto/sha2.h> +#include <crypto/utils.h> static int cifs_sig_update (struct cifs_calc_sig_ctx *ctx,const u8 *data,size_t len)
@@ -277,7 +278,7 @@ int cifs_verify_signature(struct smb_rqs/* cifs_dump_mem("what we think it should be: ", what_we_think_sig_should_be, 16); */ -if (memcmp (server_response_sig, what_we_think_sig_should_be,8 )) +if (crypto_memneq (server_response_sig, what_we_think_sig_should_be,8 ))return -EACCES ;else return 0 ;
fs/smb/client/smb2transport.c +3 -1
@@ -20,6 +20,7 @@#include <linux/highmem.h> #include <crypto/aead.h> #include <crypto/sha2.h> +#include <crypto/utils.h> #include "cifsglob.h" #include "cifsproto.h" #include "smb2proto.h"
@@ -617,7 +618,8 @@ smb2_verify_signature(struct smb_rqst *rif (rc)return rc; -if (memcmp (server_response_sig, shdr->Signature,SMB2_SIGNATURE_SIZE )) { +if (crypto_memneq (server_response_sig, shdr->Signature, +SMB2_SIGNATURE_SIZE )) {cifs_dbg (VFS ,"sign fail cmd 0x%x message id 0x%llx\n" , shdr->Command, shdr->MessageId);return -EACCES ;
Greg Kroah-Hartman
maintainerPATCH 328/333 ksmbd: Compare MACs in constant time
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit c5794709bc9105935dbedef8b9cf9c06f2b559fa upstream.
To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().
--- fs/smb/server/Kconfig | 1 + fs/smb/server/auth.c | 4 +++- fs/smb/server/smb2pdu.c | 5 +++-- 3 files changed, 7 insertions(+), 3 deletions(-)
fs/smb/server/Kconfig +1 -0
@@ -13,6 +13,7 @@ config SMB_SERVER select CRYPTO_LIB_ARC4 select CRYPTO_LIB_DES select CRYPTO_LIB_SHA256 + select CRYPTO_LIB_UTILS select CRYPTO_SHA256 select CRYPTO_CMAC select CRYPTO_SHA512
fs/smb/server/auth.c +3 -1
@@ -13,6 +13,7 @@#include <linux/xattr.h> #include <crypto/hash.h> #include <crypto/aead.h> +#include <crypto/utils.h> #include <linux/random.h> #include <linux/scatterlist.h>
@@ -283,7 +284,8 @@ int ksmbd_auth_ntlmv2(struct ksmbd_conn goto out; } -if (memcmp (ntlmv2->ntlmv2_hash, ntlmv2_rsp,CIFS_HMAC_MD5_HASH_SIZE ) !=0 ) +if (crypto_memneq (ntlmv2->ntlmv2_hash, ntlmv2_rsp, +CIFS_HMAC_MD5_HASH_SIZE )) rc = -EINVAL ; out:if (ctx)
fs/smb/server/smb2pdu.c +3 -2
@@ -4,6 +4,7 @@* Copyright (C) 2018 Samsung Electronics Co., Ltd. */ +#include <crypto/utils.h> #include <linux/inetdevice.h> #include <net/addrconf.h> #include <linux/syscalls.h>
@@ -8881,7 +8882,7 @@ int smb2_check_sign_req(struct ksmbd_wor signature))return 0 ; -if (memcmp (signature, signature_req,SMB2_SIGNATURE_SIZE )) { +if (crypto_memneq (signature, signature_req,SMB2_SIGNATURE_SIZE )) {pr_err ("bad smb2 signature\n" );return 0 ; }
@@ -8969,7 +8970,7 @@ int smb3_check_sign_req(struct ksmbd_worif (ksmbd_sign_smb3_pdu (conn, signing_key, iov,1 , signature))return 0 ; -if (memcmp (signature, signature_req,SMB2_SIGNATURE_SIZE )) { +if (crypto_memneq (signature, signature_req,SMB2_SIGNATURE_SIZE )) {pr_err ("bad smb2 signature\n" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 329/333 lib/crypto: tests: Depend on library options rather than selecting them
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 4478e8eeb87120c11e90041864c2233238b2155a upstream.
The convention for KUnit tests is to have the test kconfig options visible only when the code they depend on is already enabled. This way only the tests that are relevant to the particular kernel build can be enabled, either manually or via KUNIT_ALL_TESTS.
Update lib/crypto/tests/Kconfig to follow that convention, i.e. depend on the corresponding library options rather than selecting them. This fixes an issue where enabling KUNIT_ALL_TESTS enabled non-test code.
This does mean that it becomes a bit more difficult to enable *all* the crypto library tests (which is what I do as a maintainer of the code), since doing so will now require enabling other options that select the libraries. Regardless, we should follow the standard KUnit convention. I'll also add a .kunitconfig file that does enable all these options.
Note: currently most of the crypto library options are selected by visible options in crypto/Kconfig, which can be used to enable them without too much trouble. If in the future we end up with more cases like CRYPTO_LIB_CURVE25519 which is selected only by WIREGUARD (thus making CRYPTO_LIB_CURVE25519_KUNIT_TEST effectively depend on WIREGUARD after this commit), we could consider adding a new kconfig option that enables all the library code specifically for testing.
--- lib/crypto/tests/Kconfig | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-)
lib/crypto/tests/Kconfig +7 -13
@@ -5,45 +5,41 @@ config CRYPTO_LIB_BLAKE2S_KUNIT_TEST depends on KUNIT default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - # No need to select CRYPTO_LIB_BLAKE2S here, as that option doesn't + # No need to depend on CRYPTO_LIB_BLAKE2S here, as that option doesn't # exist; the BLAKE2s code is always built-in for the /dev/random driver. help KUnit tests for the BLAKE2s cryptographic hash function. config CRYPTO_LIB_CURVE25519_KUNIT_TEST tristate "KUnit tests for Curve25519" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_CURVE25519 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_CURVE25519 help KUnit tests for the Curve25519 Diffie-Hellman function. config CRYPTO_LIB_MD5_KUNIT_TEST tristate "KUnit tests for MD5" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_MD5 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_MD5 help KUnit tests for the MD5 cryptographic hash function and its corresponding HMAC. config CRYPTO_LIB_POLY1305_KUNIT_TEST tristate "KUnit tests for Poly1305" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_POLY1305 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_POLY1305 help KUnit tests for the Poly1305 library functions. config CRYPTO_LIB_SHA1_KUNIT_TEST tristate "KUnit tests for SHA-1" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_SHA1 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_SHA1 help KUnit tests for the SHA-1 cryptographic hash function and its corresponding HMAC.
@@ -52,10 +48,9 @@ config CRYPTO_LIB_SHA1_KUNIT_TEST # included, for consistency with the naming used elsewhere (e.g. CRYPTO_SHA256). config CRYPTO_LIB_SHA256_KUNIT_TEST tristate "KUnit tests for SHA-224 and SHA-256" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_SHA256 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_SHA256 help KUnit tests for the SHA-224 and SHA-256 cryptographic hash functions and their corresponding HMACs.
@@ -64,10 +59,9 @@ config CRYPTO_LIB_SHA256_KUNIT_TEST # included, for consistency with the naming used elsewhere (e.g. CRYPTO_SHA512). config CRYPTO_LIB_SHA512_KUNIT_TEST tristate "KUnit tests for SHA-384 and SHA-512" if !KUNIT_ALL_TESTS - depends on KUNIT + depends on KUNIT && CRYPTO_LIB_SHA512 default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS select CRYPTO_LIB_BENCHMARK_VISIBLE - select CRYPTO_LIB_SHA512 help KUnit tests for the SHA-384 and SHA-512 cryptographic hash functions and their corresponding HMACs.
Greg Kroah-Hartman
maintainerPATCH 330/333 net/tcp-md5: Fix MAC comparison to be constant-time
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 46d0d6f50dab706637f4c18a470aac20a21900d3 upstream.
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
--- net/ipv4/tcp.c | 3 ++- net/ipv4/tcp_ipv4.c | 3 ++- net/ipv6/tcp_ipv6.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-)
net/ipv4/tcp.c +2 -1
@@ -244,6 +244,7 @@#define pr_fmt (fmt) "TCP: " fmt#include <crypto/hash.h> +#include <crypto/utils.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/types.h>
@@ -4899,7 +4900,7 @@ tcp_inbound_md5_hash(const struct sock *else genhash = tp->af_specific->calc_md5_hash (newhash, key,NULL , skb); -if (genhash ||memcmp (hash_location, newhash,16 ) !=0 ) { +if (genhash ||crypto_memneq (hash_location, newhash,16 )) {NET_INC_STATS (sock_net (sk),LINUX_MIB_TCPMD5FAILURE );trace_tcp_hash_md5_mismatch (sk, skb);return SKB_DROP_REASON_TCP_MD5FAILURE ;
net/ipv4/tcp_ipv4.c +2 -1
@@ -87,6 +87,7 @@#include <linux/skbuff_ref.h> #include <crypto/hash.h> +#include <crypto/utils.h> #include <linux/scatterlist.h> #include <trace/events/tcp.h>
@@ -840,7 +841,7 @@ static void tcp_v4_send_reset(const stru genhash =tcp_v4_md5_hash_skb (newhash, key,NULL , skb); -if (genhash ||memcmp (md5_hash_location, newhash,16 ) !=0 ) +if (genhash ||crypto_memneq (md5_hash_location, newhash,16 )) goto out; }
net/ipv6/tcp_ipv6.c +2 -1
@@ -68,6 +68,7 @@#include <linux/seq_file.h> #include <crypto/hash.h> +#include <crypto/utils.h> #include <linux/scatterlist.h> #include <trace/events/tcp.h>
@@ -1089,7 +1090,7 @@ static void tcp_v6_send_reset(const stru key.type =TCP_KEY_MD5 ; genhash =tcp_v6_md5_hash_skb (newhash, key.md5_key,NULL , skb); -if (genhash ||memcmp (md5_hash_location, newhash,16 ) !=0 ) +if (genhash ||crypto_memneq (md5_hash_location, newhash,16 )) goto out; }#endif
Greg Kroah-Hartman
maintainerPATCH 331/333 io_uring: ensure ctx->rings is stable for task work flags manipulation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 96189080265e6bb5dde3a4afbaf947af493e3f82 upstream.
If DEFER_TASKRUN | SETUP_TASKRUN is used and task work is added while the ring is being resized, it's possible for the OR'ing of IORING_SQ_TASKRUN to happen in the small window of swapping into the new rings and the old rings being freed.
Prevent this by adding a 2nd ->rings pointer, ->rings_rcu, which is protected by RCU. The task work flags manipulation is inside RCU already, and if the resize ring freeing is done post an RCU synchronize, then there's no need to add locking to the fast path of task work additions.
Note: this is only done for DEFER_TASKRUN, as that's the only setup mode that supports ring resizing. If this ever changes, then they too need to use the io_ctx_mark_taskrun() helper.
--- include/linux/io_uring_types.h | 1 + io_uring/io_uring.c | 25 ++++++++++++++++++++++--- io_uring/register.c | 11 +++++++++++ 3 files changed, 34 insertions(+), 3 deletions(-)
include/linux/io_uring_types.h +1 -0
@@ -372,6 +372,7 @@ struct io_ring_ctx {* regularly bounce b/w CPUs. */ struct { +struct io_rings __rcu *rings_rcu;struct llist_head work_llist;struct llist_head retry_llist;unsigned long check_cq;
io_uring/io_uring.c +22 -3
@@ -1238,6 +1238,21 @@ void tctx_task_work(struct callback_headWARN_ON_ONCE (ret); } +/* +* Sets IORING_SQ_TASKRUN in the sq_flags shared with userspace, using the +* RCU protected rings pointer to be safe against concurrent ring resizing. +*/ +static void io_ctx_mark_taskrun (struct io_ring_ctx *ctx) +{ +lockdep_assert_in_rcu_read_lock (); + +if (ctx->flags &IORING_SETUP_TASKRUN_FLAG ) { +struct io_rings *rings =rcu_dereference (ctx->rings_rcu); + +atomic_or (IORING_SQ_TASKRUN , &rings->sq_flags); + } +} +static void io_req_local_work_add (struct io_kiocb *req,unsigned flags) {struct io_ring_ctx *ctx = req->ctx;
@@ -1292,8 +1307,7 @@ static void io_req_local_work_add(struct*/ if (!head) { -if (ctx->flags &IORING_SETUP_TASKRUN_FLAG ) -atomic_or (IORING_SQ_TASKRUN , &ctx->rings->sq_flags); +io_ctx_mark_taskrun (ctx);if (ctx->has_evfd)io_eventfd_signal (ctx, false); }
@@ -1317,6 +1331,10 @@ static void io_req_normal_work_add(strucif (!llist_add (&req->io_task_work.node, &tctx->task_list))return ; +/* +* Doesn't need to use ->rings_rcu, as resizing isn't supported for +* !DEFER_TASKRUN. +*/ if (ctx->flags &IORING_SETUP_TASKRUN_FLAG )atomic_or (IORING_SQ_TASKRUN , &ctx->rings->sq_flags);
@@ -2774,6 +2792,7 @@ static void io_rings_free(struct io_ringio_free_region (ctx, &ctx->sq_region);io_free_region (ctx, &ctx->ring_region); ctx->rings =NULL ; +RCU_INIT_POINTER (ctx->rings_rcu,NULL ); ctx->sq_sqes =NULL ; }
@@ -3627,7 +3646,7 @@ static __cold int io_allocate_scq_uringsif (ret)return ret; ctx->rings = rings =io_region_get_ptr (&ctx->ring_region); - +rcu_assign_pointer (ctx->rings_rcu, rings);if (!(ctx->flags &IORING_SETUP_NO_SQARRAY )) ctx->sq_array = (u32 *)((char *)rings + sq_array_offset);
io_uring/register.c +11 -0
@@ -556,7 +556,15 @@ overflow: ctx->sq_entries = p.sq_entries; ctx->cq_entries = p.cq_entries; +/* +* Just mark any flag we may have missed and that the application +* should act on unconditionally. Worst case it'll be an extra +* syscall. +*/ +atomic_or (IORING_SQ_TASKRUN |IORING_SQ_NEED_WAKEUP , &n.rings->sq_flags); ctx->rings = n.rings; +rcu_assign_pointer (ctx->rings_rcu, n.rings); + ctx->sq_sqes = n.sq_sqes;swap_old (ctx, o, n, ring_region);swap_old (ctx, o, n, sq_region);
@@ -565,6 +573,9 @@ overflow: out:spin_unlock (&ctx->completion_lock);mutex_unlock (&ctx->mmap_lock); +/* Wait for concurrent io_ctx_mark_taskrun() */ +if (to_free == &o) +synchronize_rcu_expedited ();io_register_free_rings (ctx, &p, to_free);if (ctx->sq_data)
Greg Kroah-Hartman
maintainerPATCH 332/333 io_uring/eventfd: use ctx->rings_rcu for flags checking
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 177c69432161f6e4bab07ccacf8a1748a6898a6b upstream.
Similarly to what commit e78f7b70e837 did for local task work additions, use ->rings_rcu under RCU rather than dereference ->rings directly. See that commit for more details.
--- io_uring/eventfd.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
io_uring/eventfd.c +7 -3
@@ -76,11 +76,15 @@ void io_eventfd_signal(struct io_ring_ct {bool skip = false;struct io_ev_fd *ev_fd; - -if (READ_ONCE (ctx->rings->cq_flags) &IORING_CQ_EVENTFD_DISABLED ) -return ; +struct io_rings *rings;guard (rcu)(); + + rings =rcu_dereference (ctx->rings_rcu); +if (!rings) +return ; +if (READ_ONCE (rings->cq_flags) &IORING_CQ_EVENTFD_DISABLED ) +return ; ev_fd =rcu_dereference (ctx->io_ev_fd);/* * Check again if ev_fd exists in case an io_eventfd_unregister call
Greg Kroah-Hartman
maintainerPATCH 333/333 mm/damon/core: disallow non-power of two min_region_sz
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
[ Upstream commit c80f46ac228b48403866d65391ad09bdf0e8562a ]
DAMON core uses min_region_sz parameter value as the DAMON region alignment. The alignment is made using ALIGN() and ALIGN_DOWN(), which support only the power of two alignments. But DAMON core API callers can set min_region_sz to an arbitrary number. Users can also set it indirectly, using addr_unit.
When the alignment is not properly set, DAMON behavior becomes difficult to expect and understand, makes it effectively broken. It doesn't cause a kernel crash-like significant issue, though.
Fix the issue by disallowing min_region_sz input that is not a power of two. Add the check to damon_commit_ctx(), as all DAMON API callers who set min_region_sz uses the function.
This can be a sort of behavioral change, but it does not break users, for the following reasons. As the symptom is making DAMON effectively broken, it is not reasonable to believe there are real use cases of non-power of two min_region_sz. There is no known use case or issue reports from the setup, either.
In future, if we find real use cases of non-power of two alignments and we can support it with low enough overhead, we can consider moving the restriction. But, for now, simply disallowing the corner case should be good enough as a hot fix.
--- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/core.c +3 -0
@@ -1236,6 +1236,9 @@ int damon_commit_ctx(struct damon_ctx *d {int err; +if (!is_power_of_2 (src->min_sz_region)) +return -EINVAL ; + err =damon_commit_schemes (dst, src);if (err)return err;
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.18.19-rc1-g1bd1cbd8a3ff #1 SMP PREEMPT_DYNAMIC Tue Mar 17 20:05:02 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Am 17.03.2026 um 17:30 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Same build failure as in 6.19.9-rc1 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server:
LD vmlinux.unstripped
BTFIDS vmlinux.unstripped
WARN: resolve_btfids: unresolved symbol kthread_exit
and git revert 0507972c8244d6454cbfd242157e86bb01971bf2 (kthread: consolidate kthread exit paths to prevent use-after-free) makes the build error go away, but may keep the original bug the patch intended to fix?! Wentao Guan wrote in [1] that an additional backport is needed to make this patch work, but I didn't test this...
[1] https://lore.kernel.org/stable/[email protected]/
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Greg Kroah-Hartman
maintainerQuoted 19 lines · Peter Schneider
Am 17.03.2026 um 17:30 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Same build failure as in 6.19.9-rc1 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server:
LD vmlinux.unstripped
BTFIDS vmlinux.unstripped
WARN: resolve_btfids: unresolved symbol kthread_exitand git revert
0507972c8244d6454cbfd242157e86bb01971bf2(kthread:
consolidate kthread exit paths to prevent use-after-free) makes the build error go away, but may keep the original bug the patch intended to fix?! Wentao Guan wrote in [1] that an additional backport is needed to make this patch work, but I didn't test this...
Quoted 4 lines
Tested-by Peter Schneider <[email protected]>
I've queued up a fix for this and will push out a -rc2 soon.
thanks,
greg k-h
Quoted 8 lines · On Tue, 17 Mar 2026 17:30:29 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 19 Mar 2026 16:28:59 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel
hello,
Compiled and booted 6.18.19-rc1+
No new typical dmesg regressions
.
--
software engineer
rajagiri school of engineering and technology-
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 19 Mar 2026 16:28:59 +0000. Anything received after that time might be too late.
test_progs, test_progs-no_alu32, test_progs-cpuv4, test_maps, test_verifier in BPF selftests all passes[1] on x86_64.
1: https://github.com/shunghsiyu/libbpf/actions/runs/23211625016/job/67531397844
[...]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 19 Mar 2026 16:28:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.19-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.18:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 failLinux version: 6.18.19-rc1-g1bd1cbd8a3ff
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra234-p3737-0000+p3701-0000,
tegra234-p3768-0000+p3767-0005, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.19 release. There are 333 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 19 Mar 2026 16:28:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.19-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).