6.14.7-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 142/197 usb: typec: tcpm: delay SNK_TRY_WAIT_DEBOUNCE to SRC_TRYWAIT transition
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: RD Babiera <[email protected]>
commit e918d3959b5ae0e793b8f815ce62240e10ba03a4 upstream.
This patch fixes Type-C Compliance Test TD 4.7.6 - Try.SNK DRP Connect SNKAS.
The compliance tester moves into SNK_UNATTACHED during toggling and expects the PUT to apply Rp after tPDDebounce of detection. If the port is in SNK_TRY_WAIT_DEBOUNCE, it will move into SRC_TRYWAIT immediately and apply Rp. This violates TD 4.7.5.V.3, where the tester confirms that the PUT attaches Rp after the transitions to Unattached.SNK for tPDDebounce.
Change the tcpm_set_state delay between SNK_TRY_WAIT_DEBOUNCE and SRC_TRYWAIT to tPDDebounce.
--- drivers/usb/typec/tcpm/tcpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/typec/tcpm/tcpm.c +1 -1
@@ -5965,7 +5965,7 @@ static void _tcpm_cc_change(struct tcpm_case SNK_TRY_WAIT_DEBOUNCE :if (!tcpm_port_is_sink (port)) { port->max_wait =0 ; -tcpm_set_state (port,SRC_TRYWAIT ,0 ); +tcpm_set_state (port,SRC_TRYWAIT ,PD_T_PD_DEBOUNCE ); }break ;case SRC_TRY_WAIT :
Greg Kroah-Hartman
maintainerPATCH 143/197 usb: typec: ucsi: displayport: Fix deadlock
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrei Kuchynski <[email protected]>
commit 364618c89d4c57c85e5fc51a2446cd939bf57802 upstream.
This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.
--- drivers/usb/typec/ucsi/displayport.c | 19 +++++++++++-------- drivers/usb/typec/ucsi/ucsi.c | 34 ++++++++++++++++++++++++++++++++++ drivers/usb/typec/ucsi/ucsi.h | 2 ++ 3 files changed, 47 insertions(+), 8 deletions(-)
drivers/usb/typec/ucsi/displayport.c +11 -8
@@ -54,7 +54,8 @@ static int ucsi_displayport_enter(structu8 cur =0 ;int ret; -mutex_lock (&dp->con->lock); +if (!ucsi_con_mutex_lock (dp->con)) +return -ENOTCONN ;if (!dp->override && dp->initialized) {const struct typec_altmode *p =typec_altmode_get_partner (alt);
@@ -100,7 +101,7 @@ static int ucsi_displayport_enter(structschedule_work (&dp->work); ret =0 ; err_unlock: -mutex_unlock (&dp->con->lock); +ucsi_con_mutex_unlock (dp->con);return ret; }
@@ -112,7 +113,8 @@ static int ucsi_displayport_exit(structu64 command;int ret =0 ; -mutex_lock (&dp->con->lock); +if (!ucsi_con_mutex_lock (dp->con)) +return -ENOTCONN ;if (!dp->override) {const struct typec_altmode *p =typec_altmode_get_partner (alt);
@@ -144,7 +146,7 @@ static int ucsi_displayport_exit(structschedule_work (&dp->work); out_unlock: -mutex_unlock (&dp->con->lock); +ucsi_con_mutex_unlock (dp->con);return ret; }
@@ -202,20 +204,21 @@ static int ucsi_displayport_vdm(struct tint cmd =PD_VDO_CMD (header);int svdm_version; -mutex_lock (&dp->con->lock); +if (!ucsi_con_mutex_lock (dp->con)) +return -ENOTCONN ;if (!dp->override && dp->initialized) {const struct typec_altmode *p =typec_altmode_get_partner (alt);dev_warn (&p->dev,"firmware doesn't support alternate mode overriding\n" ); -mutex_unlock (&dp->con->lock); +ucsi_con_mutex_unlock (dp->con);return -EOPNOTSUPP ; } svdm_version =typec_altmode_get_svdm_version (alt);if (svdm_version <0 ) { -mutex_unlock (&dp->con->lock); +ucsi_con_mutex_unlock (dp->con);return svdm_version; }
@@ -259,7 +262,7 @@ static int ucsi_displayport_vdm(struct tbreak ; } -mutex_unlock (&dp->con->lock); +ucsi_con_mutex_unlock (dp->con);return 0 ; }
drivers/usb/typec/ucsi/ucsi.c +34 -0
@@ -1923,6 +1923,40 @@ void ucsi_set_drvdata(struct ucsi *ucsi,EXPORT_SYMBOL_GPL (ucsi_set_drvdata);/** +* ucsi_con_mutex_lock - Acquire the connector mutex +* @con: The connector interface to lock +* +* Returns true on success, false if the connector is disconnected +*/ +bool ucsi_con_mutex_lock (struct ucsi_connector *con) +{ +bool mutex_locked = false; +bool connected = true; + +while (connected && !mutex_locked) { + mutex_locked =mutex_trylock (&con->lock) !=0 ; + connected =UCSI_CONSTAT (con,CONNECTED ); +if (connected && !mutex_locked) +msleep (20 ); + } + + connected = connected && con->partner; +if (!connected && mutex_locked) +mutex_unlock (&con->lock); + +return connected; +} + +/** +* ucsi_con_mutex_unlock - Release the connector mutex +* @con: The connector interface to unlock +*/ +void ucsi_con_mutex_unlock (struct ucsi_connector *con) +{ +mutex_unlock (&con->lock); +} + +/** * ucsi_create - Allocate UCSI instance * @dev: Device interface to the PPM (Platform Policy Manager) * @ops: I/O routines
drivers/usb/typec/ucsi/ucsi.h +2 -0
@@ -94,6 +94,8 @@ int ucsi_register(struct ucsi *ucsi);void ucsi_unregister (struct ucsi *ucsi);void *ucsi_get_drvdata (struct ucsi *ucsi);void ucsi_set_drvdata (struct ucsi *ucsi,void *data); +bool ucsi_con_mutex_lock (struct ucsi_connector *con); +void ucsi_con_mutex_unlock (struct ucsi_connector *con);void ucsi_connector_change (struct ucsi *ucsi,u8 num);
Greg Kroah-Hartman
maintainerPATCH 144/197 usb: typec: ucsi: displayport: Fix NULL pointer access
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrei Kuchynski <[email protected]>
commit 312d79669e71283d05c05cc49a1a31e59e3d9e0e upstream.
This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.
--- drivers/usb/typec/ucsi/displayport.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/typec/ucsi/displayport.c +2 -0
@@ -299,6 +299,8 @@ void ucsi_displayport_remove_partner(strif (!dp)return ; +cancel_work_sync (&dp->work); + dp->data.conf =0 ; dp->data.status =0 ; dp->initialized = false;
Greg Kroah-Hartman
maintainerPATCH 145/197 USB: usbtmc: use interruptible sleep in usbtmc_read
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 054c5145540e5ad5b80adf23a5e3e2fc281fb8aa upstream.
usbtmc_read() calls usbtmc_generic_read() which uses interruptible sleep, but usbtmc_read() itself uses uninterruptble sleep for mutual exclusion between threads. That makes no sense.
Both should use interruptible sleep.
--- drivers/usb/class/usbtmc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/class/usbtmc.c +5 -1
@@ -1380,7 +1380,10 @@ static ssize_t usbtmc_read(struct file *if (!buffer)return -ENOMEM ; -mutex_lock (&data->io_mutex); + retval =mutex_lock_interruptible (&data->io_mutex); +if (retval <0 ) + goto exit_nolock; +if (data->zombie) { retval = -ENODEV ; goto exit;
@@ -1503,6 +1506,7 @@ static ssize_t usbtmc_read(struct file * exit:mutex_unlock (&data->io_mutex); +exit_nolock:kfree (buffer);return retval; }
Greg Kroah-Hartman
maintainerPATCH 146/197 usb: usbtmc: Fix erroneous get_stb ioctl error returns
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit cac01bd178d6a2a23727f138d647ce1a0e8a73a1 upstream.
wait_event_interruptible_timeout returns a long
The return was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX resulting in random error returns.
Use a long return value and convert to int ioctl return only on error.
When the return value of wait_event_interruptible_timeout was <= INT_MAX the number of remaining jiffies was returned which has no meaning for the user. Return 0 on success.
--- drivers/usb/class/usbtmc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/usb/class/usbtmc.c +8 -4
@@ -482,6 +482,7 @@ static int usbtmc_get_stb(struct usbtmc_u8 *buffer;u8 tag;int rv; +long wait_rv;dev_dbg (dev,"Enter ioctl_read_stb iin_ep_present: %d\n" , data->iin_ep_present);
@@ -511,16 +512,17 @@ static int usbtmc_get_stb(struct usbtmc_ }if (data->iin_ep_present) { - rv =wait_event_interruptible_timeout ( + wait_rv =wait_event_interruptible_timeout ( data->waitq,atomic_read (&data->iin_data_valid) !=0 , file_data->timeout); -if (rv <0 ) { -dev_dbg (dev,"wait interrupted %d\n" , rv); +if (wait_rv <0 ) { +dev_dbg (dev,"wait interrupted %ld\n" , wait_rv); + rv = wait_rv; goto exit; } -if (rv ==0 ) { +if (wait_rv ==0 ) {dev_dbg (dev,"wait timed out\n" ); rv = -ETIMEDOUT ; goto exit;
@@ -539,6 +541,8 @@ static int usbtmc_get_stb(struct usbtmc_dev_dbg (dev,"stb:0x%02x received %d\n" , (unsigned int )*stb, rv); + rv =0 ; + exit:/* bump interrupt bTag */ data->iin_bTag +=1 ;
Greg Kroah-Hartman
maintainerPATCH 147/197 usb: usbtmc: Fix erroneous wait_srq ioctl return
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit a9747c9b8b59ab4207effd20eb91a890acb44e16 upstream.
wait_event_interruptible_timeout returns a long
The return was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX resulting in random error returns.
Use a long return value, converting to the int ioctl return only on error.
--- drivers/usb/class/usbtmc.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-)
drivers/usb/class/usbtmc.c +11 -12
@@ -606,9 +606,9 @@ static int usbtmc488_ioctl_wait_srq(stru {struct usbtmc_device_data *data = file_data->data;struct device *dev = &data->intf->dev; -int rv;u32 timeout;unsigned long expire; +long wait_rv;if (!data->iin_ep_present) {dev_dbg (dev,"no interrupt endpoint present\n" );
@@ -622,25 +622,24 @@ static int usbtmc488_ioctl_wait_srq(strumutex_unlock (&data->io_mutex); - rv =wait_event_interruptible_timeout ( - data->waitq, -atomic_read (&file_data->srq_asserted) !=0 || -atomic_read (&file_data->closing), - expire); + wait_rv =wait_event_interruptible_timeout ( + data->waitq, +atomic_read (&file_data->srq_asserted) !=0 || +atomic_read (&file_data->closing), + expire);mutex_lock (&data->io_mutex);/* Note! disconnect or close could be called in the meantime */ if (atomic_read (&file_data->closing) || data->zombie) - rv = -ENODEV ; +return -ENODEV ; -if (rv <0 ) { -/* dev can be invalid now! */ -pr_debug ("%s - wait interrupted %d\n" , __func__, rv); -return rv; +if (wait_rv <0 ) { +dev_dbg (dev,"%s - wait interrupted %ld\n" , __func__, wait_rv); +return wait_rv; } -if (rv ==0 ) { +if (wait_rv ==0 ) {dev_dbg (dev,"%s - wait timed out\n" , __func__);return -ETIMEDOUT ; }
Greg Kroah-Hartman
maintainerPATCH 148/197 usb: usbtmc: Fix erroneous generic_read ioctl return
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit 4e77d3ec7c7c0d9535ccf1138827cb9bb5480b9b upstream.
wait_event_interruptible_timeout returns a long
The return value was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX which resulted in random error returns.
Use a long return value, converting to the int ioctl return only on error.
--- drivers/usb/class/usbtmc.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
drivers/usb/class/usbtmc.c +12 -6
@@ -833,6 +833,7 @@ static ssize_t usbtmc_generic_read(strucunsigned long expire;int bufcount =1 ;int again =0 ; +long wait_rv;/* mutex already locked */
@@ -945,19 +946,24 @@ static ssize_t usbtmc_generic_read(strucif (!(flags &USBTMC_FLAG_ASYNC )) {dev_dbg (dev,"%s: before wait time %lu\n" , __func__, expire); - retval =wait_event_interruptible_timeout ( + wait_rv =wait_event_interruptible_timeout ( file_data->wait_bulk_in,usbtmc_do_transfer (file_data), expire); -dev_dbg (dev,"%s: wait returned %d\n" , - __func__, retval); +dev_dbg (dev,"%s: wait returned %ld\n" , + __func__, wait_rv); -if (retval <=0 ) { -if (retval ==0 ) - retval = -ETIMEDOUT ; +if (wait_rv <0 ) { + retval = wait_rv; goto error; } + +if (wait_rv ==0 ) { + retval = -ETIMEDOUT ; + goto error; + } + } urb =usb_get_from_anchor (&file_data->in_anchor);
Greg Kroah-Hartman
maintainerPATCH 149/197 iio: imu: bmi270: fix initial sampling frequency configuration
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo Silva <[email protected]>
[ Upstream commit 6d03811d7a99e08d5928f58120acb45b8ba22b08 ]
In the bmi270_configure_imu() function, the accelerometer and gyroscope configuration registers are incorrectly written with the mask BMI270_PWR_CONF_ADV_PWR_SAVE_MSK, which is unrelated to these registers.
As a result, the accelerometer's sampling frequency is set to 200 Hz instead of the intended 100 Hz.
Remove the mask to ensure the correct bits are set in the configuration registers.
--- drivers/iio/imu/bmi270/bmi270_core.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/iio/imu/bmi270/bmi270_core.c +2 -4
@@ -654,8 +654,7 @@ static int bmi270_configure_imu(struct bmi270_data *bmi270_device)FIELD_PREP (BMI270_ACC_CONF_ODR_MSK ,BMI270_ACC_CONF_ODR_100HZ ) |FIELD_PREP (BMI270_ACC_CONF_BWP_MSK , -BMI270_ACC_CONF_BWP_NORMAL_MODE ) | - BMI270_PWR_CONF_ADV_PWR_SAVE_MSK); + BMI270_ACC_CONF_BWP_NORMAL_MODE));if (ret)return dev_err_probe (dev, ret,"Failed to configure accelerometer" );
@@ -663,8 +662,7 @@ static int bmi270_configure_imu(struct bmi270_data *bmi270_device)FIELD_PREP (BMI270_GYR_CONF_ODR_MSK ,BMI270_GYR_CONF_ODR_200HZ ) |FIELD_PREP (BMI270_GYR_CONF_BWP_MSK , -BMI270_GYR_CONF_BWP_NORMAL_MODE ) | - BMI270_PWR_CONF_ADV_PWR_SAVE_MSK); + BMI270_GYR_CONF_BWP_NORMAL_MODE));if (ret)return dev_err_probe (dev, ret,"Failed to configure gyroscope" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 150/197 iio: accel: adxl367: fix setting odr for activity time update
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lothar Rubusch <[email protected]>
[ Upstream commit 38f67d0264929762e54ae5948703a21f841fe706 ]
Fix setting the odr value to update activity time based on frequency derrived by recent odr, and not by obsolete odr value.
The [small] bug: When _adxl367_set_odr() is called with a new odr value, it first writes the new odr value to the hardware register ADXL367_REG_FILTER_CTL.
Second, it calls _adxl367_set_act_time_ms(), which calls adxl367_time_ms_to_samples(). Here st->odr still holds the old odr value. This st->odr member is used to derrive a frequency value, which is applied to update ADXL367_REG_TIME_ACT. Hence, the idea is to update activity time, based on possibilities and power consumption by the current ODR rate.
Finally, when the function calls return, again in _adxl367_set_odr() the new ODR is assigned to st->odr.
The fix: When setting a new ODR value is set to ADXL367_REG_FILTER_CTL, also ADXL367_REG_TIME_ACT should probably be updated with a frequency based on the recent ODR value and not the old one. Changing the location of the assignment to st->odr fixes this.
--- drivers/iio/accel/adxl367.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
drivers/iio/accel/adxl367.c +3 -7
@@ -604,18 +604,14 @@ static int _adxl367_set_odr(struct adxl367_state *st, enum adxl367_odr odr)if (ret)return ret; + st->odr = odr; +/* Activity timers depend on ODR */ ret =_adxl367_set_act_time_ms (st, st->act_time_ms);if (ret)return ret; - ret =_adxl367_set_inact_time_ms (st, st->inact_time_ms); -if (ret) -return ret; - - st->odr = odr; - -return 0 ; +return _adxl367_set_inact_time_ms (st, st->inact_time_ms); }static int adxl367_set_odr (struct iio_dev *indio_dev,enum adxl367_odr odr)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 151/197 iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer.
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Cameron <[email protected]>
[ Upstream commit f79aeb6c631b57395f37acbfbe59727e355a714c ]
The trick of using __aligned(IIO_DMA_MINALIGN) ensures that there is no overlap between buffers used for DMA and those used for driver state storage that are before the marking. It doesn't ensure anything above state variables found after the marking. Hence move this particular bit of state earlier in the structure.
--- drivers/iio/temperature/maxim_thermocouple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/temperature/maxim_thermocouple.c +1 -1
@@ -121,9 +121,9 @@ static const struct maxim_thermocouple_chip maxim_thermocouple_chips[] = {struct maxim_thermocouple_data {struct spi_device *spi;const struct maxim_thermocouple_chip *chip; +char tc_type;u8 buffer[16 ]__aligned(IIO_DMA_MINALIGN) ; -char tc_type; }; static int maxim_thermocouple_read(struct maxim_thermocouple_data *data,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 152/197 iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Cameron <[email protected]>
[ Upstream commit 1bb942287e05dc4c304a003ea85e6dd9a5e7db39 ]
The IIO ABI requires 64-bit aligned timestamps. In this case insufficient padding would have been added on architectures where an s64 is only 32-bit aligned. Use aligned_s64 to enforce the correct alignment.
--- drivers/iio/accel/adxl355_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/accel/adxl355_core.c +1 -1
@@ -231,7 +231,7 @@ struct adxl355_data {u8 transf_buf[3 ];struct {u8 buf[14 ]; -s64 ts; +aligned_s64 ts; } buffer; }__aligned(IIO_DMA_MINALIGN) ; };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 153/197 iio: adc: dln2: Use aligned_s64 for timestamp
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Cameron <[email protected]>
[ Upstream commit 5097eaae98e53f9ab9d35801c70da819b92ca907 ]
Here the lack of marking allows the overall structure to not be sufficiently aligned resulting in misplacement of the timestamp in iio_push_to_buffers_with_timestamp(). Use aligned_s64 to force the alignment on all architectures.
--- drivers/iio/adc/dln2-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/dln2-adc.c +1 -1
@@ -467,7 +467,7 @@ static irqreturn_t dln2_adc_trigger_h(int irq, void *p)struct iio_dev *indio_dev = pf->indio_dev;struct {__le16 values[DLN2_ADC_MAX_CHANNELS ]; -int64_t timestamp_space; +aligned_s64 timestamp_space; } data;struct dln2_adc_get_all_vals dev_data;struct dln2_adc *dln2 =iio_priv (indio_dev);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 154/197 MIPS: Fix idle VS timer enqueue
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Crivellari <[email protected]>
[ Upstream commit 56651128e2fbad80f632f388d6bf1f39c928267a ]
MIPS re-enables interrupts on its idle routine and performs a TIF_NEED_RESCHED check afterwards before putting the CPU to sleep.
The IRQs firing between the check and the 'wait' instruction may set the TIF_NEED_RESCHED flag. In order to deal with this possible race, IRQs interrupting __r4k_wait() rollback their return address to the beginning of __r4k_wait() so that TIF_NEED_RESCHED is checked again before going back to sleep.
However idle IRQs can also queue timers that may require a tick reprogramming through a new generic idle loop iteration but those timers would go unnoticed here because __r4k_wait() only checks TIF_NEED_RESCHED. It doesn't check for pending timers.
Fix this with fast-forwarding idle IRQs return address to the end of the idle routine instead of the beginning, so that the generic idle loop handles both TIF_NEED_RESCHED and pending timers.
CONFIG_CPU_MICROMIPS has been removed along with the nop instructions. There, NOPs are 2 byte in size, so change the code with 3 _ssnop which are always 4 byte and remove the ifdef. Added ehb to make sure the hazard is always cleared.
--- arch/mips/include/asm/idle.h | 3 +- arch/mips/kernel/genex.S | 62 +++++++++++++++++++++--------------- arch/mips/kernel/idle.c | 7 ---- 3 files changed, 37 insertions(+), 35 deletions(-)
arch/mips/include/asm/idle.h +1 -2
@@ -6,8 +6,7 @@#include <linux/linkage.h> extern void (*cpu_wait)(void ); -extern void r4k_wait (void ); -extern asmlinkage void __r4k_wait(void); +extern asmlinkage void r4k_wait(void);extern void r4k_wait_irqoff (void );static inline int using_rollback_handler (void )
arch/mips/kernel/genex.S +36 -26
78 lines not on this page · raw message
arch/mips/kernel/idle.c +0 -7
@@ -35,13 +35,6 @@ static void __cpuidle r3081_wait(void)write_c0_conf (cfg |R30XX_CONF_HALT ); } -void __cpuidle r4k_wait(void) -{ -raw_local_irq_enable (); -__r4k_wait (); -raw_local_irq_disable (); -} -/* * This variant is preferable as it allows testing need_resched and going to * sleep depending on the outcome atomically. Unfortunately the "It is
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 155/197 MIPS: Move r4k_wait() to .cpuidle.text section
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Crivellari <[email protected]>
[ Upstream commit b713f27e32d87c35737ec942dd6f5ed6b7475f48 ]
Fix missing .cpuidle.text section assignment for r4k_wait() to correct backtracing with nmi_backtrace().
--- arch/mips/kernel/genex.S | 1 + 1 file changed, 1 insertion(+)
arch/mips/kernel/genex.S +1 -0
@@ -104,6 +104,7 @@ handle_vcei: __FINIT + .section .cpuidle.text,"ax" /* Align to 32 bytes for the maximum idle interrupt region size. */ .align 5 LEAF(r4k_wait)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 156/197 timekeeping: Prevent coarse clocks going backwards
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
[ Upstream commit b71f9804f66c2592d4c3a2397b7374a4039005a5 ]
Lei Chen raised an issue with CLOCK_MONOTONIC_COARSE seeing time inconsistencies. Lei tracked down that this was being caused by the adjustment:
tk->tkr_mono.xtime_nsec -= offset;
which is made to compensate for the unaccumulated cycles in offset when the multiplicator is adjusted forward, so that the non-_COARSE clockids don't see inconsistencies.
However, the _COARSE clockid getter functions use the adjusted xtime_nsec value directly and do not compensate the negative offset via the clocksource delta multiplied with the new multiplicator. In that case the caller can observe time going backwards in consecutive calls.
By design, this negative adjustment should be fine, because the logic run from timekeeping_adjust() is done after it accumulated approximately
multiplicator * interval_cycles
into xtime_nsec. The accumulated value is always larger then the
mult_adj * offset
value, which is subtracted from xtime_nsec. Both operations are done together under the tk_core.lock, so the net change to xtime_nsec is always always be positive.
However, do_adjtimex() calls into timekeeping_advance() as well, to apply the NTP frequency adjustment immediately. In this case, timekeeping_advance() does not return early when the offset is smaller then interval_cycles. In that case there is no time accumulated into xtime_nsec. But the subsequent call into timekeeping_adjust(), which modifies the multiplicator, subtracts from xtime_nsec to correct for the new multiplicator.
Here because there was no accumulation, xtime_nsec becomes smaller than before, which opens a window up to the next accumulation, where the _COARSE clockid getters, which don't compensate for the offset, can observe the inconsistency.
This has been tried to be fixed by forwarding the timekeeper in the case that adjtimex() adjusts the multiplier, which resets the offset to zero:
757b000f7b93 ("timekeeping: Fix possible inconsistencies in _COARSE clockids")
That works correctly, but unfortunately causes a regression on the adjtimex() side. There are two issues:
1) The forwarding of the base time moves the update out of the original period and establishes a new one.
2) The clearing of the accumulated NTP error is changing the behaviour as well.
User-space expects that multiplier/frequency updates are in effect, when the syscall returns, so delaying the update to the next tick is not solving the problem either.
Commit 757b000f7b93 was reverted so that the established expectations of user space implementations (ntpd, chronyd) are restored, but that obviously brought the inconsistencies back.
One of the initial approaches to fix this was to establish a separate storage for the coarse time getter nanoseconds part by calculating it from the offset. That was dropped on the floor because not having yet another state to maintain was simpler. But given the result of the above exercise, this solution turns out to be the right one. Bring it back in a slightly modified form.
Thus introduce timekeeper::coarse_nsec and store that nanoseconds part in it, switch the time getter functions and the VDSO update to use that value. coarse_nsec is set on operations which forward or initialize the timekeeper and after time was accumulated during a tick. If there is no accumulation the timestamp is unchanged.
This leaves the adjtimex() behaviour unmodified and prevents coarse time from going backwards.
[ jstultz: Simplified the coarse_nsec calculation and kept behavior so
coarse clockids aren't adjusted on each inter-tick adjtimex call, slightly reworked the comments and commit message ]
--- include/linux/timekeeper_internal.h | 8 +++-- kernel/time/timekeeping.c | 50 ++++++++++++++++++++++++----- kernel/time/vsyscall.c | 4 +-- 3 files changed, 49 insertions(+), 13 deletions(-)
include/linux/timekeeper_internal.h +5 -3
@@ -51,7 +51,7 @@ struct tk_read_base {* @offs_real: Offset clock monotonic -> clock realtime * @offs_boot: Offset clock monotonic -> clock boottime * @offs_tai: Offset clock monotonic -> clock tai -* @tai_offset: The current UTC to TAI offset in seconds +* @coarse_nsec: The nanoseconds part for coarse time getters * @tkr_raw: The readout base structure for CLOCK_MONOTONIC_RAW * @raw_sec: CLOCK_MONOTONIC_RAW time in seconds * @clock_was_set_seq: The sequence number of clock was set events
@@ -76,6 +76,7 @@ struct tk_read_base {* ntp shifted nano seconds. * @ntp_err_mult: Multiplication factor for scaled math conversion * @skip_second_overflow: Flag used to avoid updating NTP twice with same second +* @tai_offset: The current UTC to TAI offset in seconds * * Note: For timespec(64) based interfaces wall_to_monotonic is what * we need to add to xtime (or xtime corrected for sub jiffy times)
@@ -100,7 +101,7 @@ struct tk_read_base {* which results in the following cacheline layout: * * 0: seqcount, tkr_mono -* 1: xtime_sec ... tai_offset +* 1: xtime_sec ... coarse_nsec * 2: tkr_raw, raw_sec * 3,4: Internal variables *
@@ -121,7 +122,7 @@ struct timekeeper {ktime_t offs_real;ktime_t offs_boot;ktime_t offs_tai; -s32 tai_offset; +u32 coarse_nsec;/* Cacheline 2: */ struct tk_read_base tkr_raw;
@@ -144,6 +145,7 @@ struct timekeeper {u32 ntp_error_shift;u32 ntp_err_mult;u32 skip_second_overflow; +s32 tai_offset; };#ifdef CONFIG_GENERIC_TIME_VSYSCALL
kernel/time/timekeeping.c +42 -8
125 lines not on this page · raw message
kernel/time/vsyscall.c +2 -2
@@ -97,12 +97,12 @@ void update_vsyscall(struct timekeeper *tk)/* CLOCK_REALTIME_COARSE */ vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_REALTIME_COARSE ]; vdso_ts->sec = tk->xtime_sec; - vdso_ts->nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift; + vdso_ts->nsec = tk->coarse_nsec;/* CLOCK_MONOTONIC_COARSE */ vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_MONOTONIC_COARSE ]; vdso_ts->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; - nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift; + nsec = tk->coarse_nsec; nsec = nsec + tk->wall_to_monotonic.tv_nsec; vdso_ts->sec +=__iter_div_u64_rem (nsec,NSEC_PER_SEC , &vdso_ts->nsec);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 157/197 accel/ivpu: Separate DB ID and CMDQ ID allocations from CMDQ allocation
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karol Wachowski <[email protected]>
[ Upstream commit 950942b4813f8c44dbec683fdb140cf4a238516b ]
Move doorbell ID and command queue ID XArray allocations from command queue memory allocation function. This will allow ID allocations to be done without the need for actual memory allocation.
Stable-dep-of: 75680b7cd461 ("accel/ivpu: Correct mutex unlock order in job submission")
--- drivers/accel/ivpu/ivpu_job.c | 88 +++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 24 deletions(-)
drivers/accel/ivpu/ivpu_job.c +64 -24
@@ -83,23 +83,9 @@ static struct ivpu_cmdq *ivpu_cmdq_alloc(struct ivpu_file_priv *file_priv)if (!cmdq)return NULL ; - ret =xa_alloc_cyclic (&vdev->db_xa, &cmdq->db_id,NULL , vdev->db_limit, &vdev->db_next, -GFP_KERNEL ); -if (ret <0 ) { -ivpu_err (vdev,"Failed to allocate doorbell id: %d\n" , ret); - goto err_free_cmdq; - } - - ret =xa_alloc_cyclic (&file_priv->cmdq_xa, &cmdq->id, cmdq, file_priv->cmdq_limit, - &file_priv->cmdq_id_next,GFP_KERNEL ); -if (ret <0 ) { -ivpu_err (vdev,"Failed to allocate command queue id: %d\n" , ret); - goto err_erase_db_xa; - } - cmdq->mem =ivpu_bo_create_global (vdev,SZ_4K ,DRM_IVPU_BO_WC |DRM_IVPU_BO_MAPPABLE );if (!cmdq->mem) - goto err_erase_cmdq_xa; + goto err_free_cmdq; ret =ivpu_preemption_buffers_create (vdev, file_priv, cmdq);if (ret)
@@ -107,10 +93,6 @@ static struct ivpu_cmdq *ivpu_cmdq_alloc(struct ivpu_file_priv *file_priv)return cmdq; -err_erase_cmdq_xa: -xa_erase (&file_priv->cmdq_xa, cmdq->id); -err_erase_db_xa: -xa_erase (&vdev->db_xa, cmdq->db_id); err_free_cmdq:kfree (cmdq);return NULL ;
@@ -234,30 +216,88 @@ static int ivpu_cmdq_fini(struct ivpu_file_priv *file_priv, struct ivpu_cmdq *cmreturn 0 ; } +static int ivpu_db_id_alloc (struct ivpu_device *vdev,u32 *db_id) +{ +int ret; +u32 id; + + ret =xa_alloc_cyclic (&vdev->db_xa, &id,NULL , vdev->db_limit, &vdev->db_next,GFP_KERNEL ); +if (ret <0 ) +return ret; + + *db_id = id; +return 0 ; +} + +static int ivpu_cmdq_id_alloc (struct ivpu_file_priv *file_priv,u32 *cmdq_id) +{ +int ret; +u32 id; + + ret =xa_alloc_cyclic (&file_priv->cmdq_xa, &id,NULL , file_priv->cmdq_limit, + &file_priv->cmdq_id_next,GFP_KERNEL ); +if (ret <0 ) +return ret; + + *cmdq_id = id; +return 0 ; +} +static struct ivpu_cmdq *ivpu_cmdq_acquire (struct ivpu_file_priv *file_priv,u8 priority) { +struct ivpu_device *vdev = file_priv->vdev;struct ivpu_cmdq *cmdq; -unsigned long cmdq_id; +unsigned long id;int ret;lockdep_assert_held (&file_priv->lock); -xa_for_each (&file_priv->cmdq_xa, cmdq_id, cmdq) +xa_for_each (&file_priv->cmdq_xa, id, cmdq)if (cmdq->priority == priority)break ;if (!cmdq) { cmdq =ivpu_cmdq_alloc (file_priv); -if (!cmdq) +if (!cmdq) { +ivpu_err (vdev,"Failed to allocate command queue\n" );return NULL ; + } + + ret =ivpu_db_id_alloc (vdev, &cmdq->db_id); +if (ret) { +ivpu_err (file_priv->vdev,"Failed to allocate doorbell ID: %d\n" , ret); + goto err_free_cmdq; + } + + ret =ivpu_cmdq_id_alloc (file_priv, &cmdq->id); +if (ret) { +ivpu_err (vdev,"Failed to allocate command queue ID: %d\n" , ret); + goto err_erase_db_id; + } + cmdq->priority = priority; + ret =xa_err (xa_store (&file_priv->cmdq_xa, cmdq->id, cmdq,GFP_KERNEL )); +if (ret) { +ivpu_err (vdev,"Failed to store command queue in cmdq_xa: %d\n" , ret); + goto err_erase_cmdq_id; + } } ret =ivpu_cmdq_init (file_priv, cmdq, priority); -if (ret) -return NULL ; +if (ret) { +ivpu_err (vdev,"Failed to initialize command queue: %d\n" , ret); + goto err_free_cmdq; + }return cmdq; + +err_erase_cmdq_id: +xa_erase (&file_priv->cmdq_xa, cmdq->id); +err_erase_db_id: +xa_erase (&vdev->db_xa, cmdq->db_id); +err_free_cmdq: +ivpu_cmdq_free (file_priv, cmdq); +return NULL ; }void ivpu_cmdq_release_all_locked (struct ivpu_file_priv *file_priv)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 158/197 accel/ivpu: Correct mutex unlock order in job submission
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karol Wachowski <[email protected]>
[ Upstream commit 75680b7cd461b169c7ccd2a0fba7542868b7fce2 ]
The mutex unlock for vdev->submitted_jobs_lock was incorrectly placed before unlocking file_priv->lock. Change order of unlocks to avoid potential race conditions.
--- drivers/accel/ivpu/ivpu_job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/accel/ivpu/ivpu_job.c +1 -1
@@ -646,8 +646,8 @@ static int ivpu_job_submit(struct ivpu_job *job, u8 priority) err_erase_xa:xa_erase (&vdev->submitted_jobs_xa, job->job_id); err_unlock: -mutex_unlock (&vdev->submitted_jobs_lock);mutex_unlock (&file_priv->lock); +mutex_unlock (&vdev->submitted_jobs_lock);ivpu_rpm_put (vdev);return ret; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 159/197 MIPS: Fix MAX_REG_OFFSET
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thorsten Blum <[email protected]>
[ Upstream commit c44572e0cc13c9afff83fd333135a0aa9b27ba26 ]
Fix MAX_REG_OFFSET to point to the last register in 'pt_regs' and not to the marker itself, which could allow regs_get_register() to return an invalid offset.
--- arch/mips/include/asm/ptrace.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/mips/include/asm/ptrace.h +2 -1
@@ -65,7 +65,8 @@ static inline void instruction_pointer_set(struct pt_regs *regs,/* Query offset/name of register from its name/offset */ extern int regs_query_register_offset (const char *name); -#define MAX_REG_OFFSET (offsetof(struct pt_regs, __last)) +#define MAX_REG_OFFSET \ + (offsetof(struct pt_regs, __last) - sizeof(unsigned long))/** * regs_get_register() - get register value from its offset
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 160/197 riscv: misaligned: Add handling for ZCB instructions
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nylon Chen <[email protected]>
[ Upstream commit eb16b3727c05ed36420c90eca1e8f0e279514c1c ]
Add support for the Zcb extension's compressed half-word instructions (C.LHU, C.LH, and C.SH) in the RISC-V misaligned access trap handler.
--- arch/riscv/kernel/traps_misaligned.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
arch/riscv/kernel/traps_misaligned.c +17 -0
@@ -88,6 +88,13 @@#define INSN_MATCH_C_FSWSP 0xe002#define INSN_MASK_C_FSWSP 0xe003 +#define INSN_MATCH_C_LHU 0x8400 +#define INSN_MASK_C_LHU 0xfc43 +#define INSN_MATCH_C_LH 0x8440 +#define INSN_MASK_C_LH 0xfc43 +#define INSN_MATCH_C_SH 0x8c00 +#define INSN_MASK_C_SH 0xfc43 +#define INSN_LEN (insn) ((((insn) & 0x3) < 0x3) ? 2 : 4)#if defined(CONFIG_64BIT )
@@ -431,6 +438,13 @@ static int handle_scalar_misaligned_load(struct pt_regs *regs) fp =1 ; len =4 ;#endif + }else if ((insn &INSN_MASK_C_LHU ) ==INSN_MATCH_C_LHU ) { + len =2 ; + insn =RVC_RS2S (insn) <<SH_RD ; + }else if ((insn &INSN_MASK_C_LH ) ==INSN_MATCH_C_LH ) { + len =2 ; + shift =8 * (sizeof (ulong) - len); + insn =RVC_RS2S (insn) <<SH_RD ; }else { regs->epc = epc;return -1 ;
@@ -530,6 +544,9 @@ static int handle_scalar_misaligned_store(struct pt_regs *regs) len =4 ; val.data_ulong =GET_F32_RS2C (insn, regs);#endif + }else if ((insn &INSN_MASK_C_SH ) ==INSN_MATCH_C_SH ) { + len =2 ; + val.data_ulong =GET_RS2S (insn, regs); }else { regs->epc = epc;return -1 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 161/197 loop: factor out a loop_assign_backing_file helper
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit d278164832618bf2775c6a89e6434e2633de1eed ]
Split the code for setting up a backing file into a helper in preparation of adding more code to this path.
Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter")
--- drivers/block/loop.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/block/loop.c +10 -10
@@ -496,6 +496,14 @@ static int loop_validate_file(struct file *file, struct block_device *bdev)return 0 ; } +static void loop_assign_backing_file (struct loop_device *lo,struct file *file) +{ + lo->lo_backing_file = file; + lo->old_gfp_mask =mapping_gfp_mask (file->f_mapping); +mapping_set_gfp_mask (file->f_mapping, + lo->old_gfp_mask & ~(__GFP_IO | __GFP_FS)); +} +/* * loop_change_fd switched the backing store of a loopback device to * a new file. This is useful for operating system installers to free up
@@ -549,10 +557,7 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,disk_force_media_change (lo->lo_disk); memflags =blk_mq_freeze_queue (lo->lo_queue);mapping_set_gfp_mask (old_file->f_mapping, lo->old_gfp_mask); - lo->lo_backing_file = file; - lo->old_gfp_mask =mapping_gfp_mask (file->f_mapping); -mapping_set_gfp_mask (file->f_mapping, - lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS)); +loop_assign_backing_file (lo, file);loop_update_dio (lo);blk_mq_unfreeze_queue (lo->lo_queue, memflags); partscan = lo->lo_flags &LO_FLAGS_PARTSCAN ;
@@ -943,7 +948,6 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode, const struct loop_config *config) {struct file *file =fget (config->fd); -struct address_space *mapping;struct queue_limits lim;int error;loff_t size;
@@ -979,8 +983,6 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode,if (error) goto out_unlock; - mapping = file->f_mapping; -if ((config->info.lo_flags & ~LOOP_CONFIGURE_SETTABLE_FLAGS ) !=0 ) { error = -EINVAL ; goto out_unlock;
@@ -1012,9 +1014,7 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode,set_disk_ro (lo->lo_disk, (lo->lo_flags &LO_FLAGS_READ_ONLY ) !=0 ); lo->lo_device = bdev; - lo->lo_backing_file = file; - lo->old_gfp_mask =mapping_gfp_mask (mapping); -mapping_set_gfp_mask (mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS)); +loop_assign_backing_file (lo, file); lim =queue_limits_start_update (lo->lo_queue);loop_update_limits (lo, &lim, config->block_size);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 162/197 loop: Add sanity check for read/write_iter
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit f5c84eff634ba003326aa034c414e2a9dcb7c6a7 ]
Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue.
So before calling them, first confirm that the interface is supported and then call it.
It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue.
--- drivers/block/loop.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
drivers/block/loop.c +23 -0
@@ -504,6 +504,17 @@ static void loop_assign_backing_file(struct loop_device *lo, struct file *file) lo->old_gfp_mask & ~(__GFP_IO | __GFP_FS)); } +static int loop_check_backing_file (struct file *file) +{ +if (!file->f_op->read_iter) +return -EINVAL ; + +if ((file->f_mode &FMODE_WRITE ) && !file->f_op->write_iter) +return -EINVAL ; + +return 0 ; +} +/* * loop_change_fd switched the backing store of a loopback device to * a new file. This is useful for operating system installers to free up
@@ -525,6 +536,10 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,if (!file)return -EBADF ; + error =loop_check_backing_file (file); +if (error) +return error; +/* suppress uevents while reconfiguring the device */ dev_set_uevent_suppress (disk_to_dev (lo->lo_disk),1 );
@@ -956,6 +971,14 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode,if (!file)return -EBADF ; + +if ((mode &BLK_OPEN_WRITE ) && !file->f_op->write_iter) +return -EINVAL ; + + error =loop_check_backing_file (file); +if (error) +return error; + is_loop =is_loop_device (file);/* This is safe, since we have a reference from open(). */
Signature · 1 line
2.39.5
Re: [PATCH 6.14 162/197] loop: Add sanity check for read/write_iter
Quoted 25 lines · Greg Kroah-Hartman
6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit
f5c84eff634ba003326aa034c414e2a9dcb7c6a7]Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue.
So before calling them, first confirm that the interface is supported and then call it.It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue.
Fixes f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")Reported-by [email protected]Signed-off-by Lizhi Xu <[email protected]>Reviewed-by Christoph Hellwig <[email protected]>Signed-off-by Jens Axboe <[email protected]>Signed-off-by Sasha Levin <[email protected]>
Quoted 3 lines
--- drivers/block/loop.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
We have had an issue failing to set up loop devices with CI and Linus' tree since rc6, and once this patch hit stable it proved to be the culprit. If I revert this patch, things work as they should. The problem we are seeing is "
More information can be found in:
https://github.com/coreos/fedora-coreos-tracker/issues/1948
and
https://openqa.fedoraproject.org/tests/3438220#step/_boot_to_anaconda/5
Justin
Quoted 54 lines
drivers/block/loop.c +23
-1@@ -504,6 +504,17 @@ static void loop_assign_backing_file(struct loop_device *lo, struct file *file) lo->old_gfp_mask & ~(__GFP_IO | __GFP_FS)); } +static int loop_check_backing_file (struct file *file) +{ +if (!file->f_op->read_iter) +return -EINVAL ; + +if ((file->f_mode &FMODE_WRITE ) && !file->f_op->write_iter) +return -EINVAL ; + +return 0 ; +} +/* * loop_change_fd switched the backing store of a loopback device to * a new file. This is useful for operating system installers to free up @@ -525,6 +536,10 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,if (!file)return -EBADF ; + error =loop_check_backing_file (file); +if (error) +return error; +/* suppress uevents while reconfiguring the device */ dev_set_uevent_suppress (disk_to_dev (lo->lo_disk),1 );@@ -956,6 +971,14 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode,if (!file)return -EBADF ; + +if ((mode &BLK_OPEN_WRITE ) && !file->f_op->write_iter) +return -EINVAL ; + + error =loop_check_backing_file (file); +if (error) +return error; + is_loop =is_loop_device (file);/* This is safe, since we have a reference from open(). */ --2.39.5
Greg Kroah-Hartman
maintainerRe: [PATCH 6.14 162/197] loop: Add sanity check for read/write_iter
Quoted 36 lines · Justin Forbes
Quoted 25 lines · Greg Kroah-Hartman
6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit
f5c84eff634ba003326aa034c414e2a9dcb7c6a7]Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue.
So before calling them, first confirm that the interface is supported and then call it.It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue.
Fixes f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")Reported-by [email protected]Signed-off-by Lizhi Xu <[email protected]>Reviewed-by Christoph Hellwig <[email protected]>Signed-off-by Jens Axboe <[email protected]>Signed-off-by Sasha Levin <[email protected]>Quoted 3 lines
--- drivers/block/loop.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)We have had an issue failing to set up loop devices with CI and Linus' tree since rc6, and once this patch hit stable it proved to be the culprit. If I revert this patch, things work as they should. The problem we are seeing is "
Quoted 4 lines
More information can be found in:
https://github.com/coreos/fedora-coreos-tracker/issues/1948
and
https://openqa.fedoraproject.org/tests/3438220#step/_boot_to_anaconda/5
Sorry to hear that, please work with the developers to get this resolved in Linus's tree and then we will be glad to apply the needed fix from there.
thanks,
greg k-h
Re: [PATCH 6.14 162/197] loop: Add sanity check for read/write_iter
Quoted 37 lines · Greg Kroah-Hartman
Quoted 36 lines · Justin Forbes
Quoted 25 lines · Greg Kroah-Hartman
6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit
f5c84eff634ba003326aa034c414e2a9dcb7c6a7]Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue.
So before calling them, first confirm that the interface is supported and then call it.It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue.
Fixes f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")Reported-by [email protected]Signed-off-by Lizhi Xu <[email protected]>Reviewed-by Christoph Hellwig <[email protected]>Signed-off-by Jens Axboe <[email protected]>Signed-off-by Sasha Levin <[email protected]>Quoted 3 lines
--- drivers/block/loop.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)We have had an issue failing to set up loop devices with CI and Linus' tree since rc6, and once this patch hit stable it proved to be the culprit. If I revert this patch, things work as they should. The problem we are seeing is "
Quoted 8 lines
Quoted 4 lines
More information can be found in:
https://github.com/coreos/fedora-coreos-tracker/issues/1948
and
https://openqa.fedoraproject.org/tests/3438220#step/_boot_to_anaconda/5Sorry to hear that, please work with the developers to get this resolved in Linus's tree and then we will be glad to apply the needed fix from there.
Should be sorted and land before 6.15:
https://git.kernel.dk/cgit/linux/commit/?h=block-6.15&id=355341e4359b2d5edf0ed5e117f7e9e7a0a5dac0
Signature · 1 line
Jens Axboe
Greg Kroah-Hartman
maintainerRe: [PATCH 6.14 162/197] loop: Add sanity check for read/write_iter
Quoted 43 lines · Jens Axboe
Quoted 42 lines · Greg Kroah-Hartman
Quoted 40 lines · Justin Forbes
Quoted 25 lines · Greg Kroah-Hartman
6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit
f5c84eff634ba003326aa034c414e2a9dcb7c6a7]Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue.
So before calling them, first confirm that the interface is supported and then call it.It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue.
Fixes f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")Reported-by [email protected]Signed-off-by Lizhi Xu <[email protected]>Reviewed-by Christoph Hellwig <[email protected]>Signed-off-by Jens Axboe <[email protected]>Signed-off-by Sasha Levin <[email protected]>Quoted 3 lines
--- drivers/block/loop.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)We have had an issue failing to set up loop devices with CI and Linus' tree since rc6, and once this patch hit stable it proved to be the culprit. If I revert this patch, things work as they should. The problem we are seeing is "
More information can be found in:
https://github.com/coreos/fedora-coreos-tracker/issues/1948
and
https://openqa.fedoraproject.org/tests/3438220#step/_boot_to_anaconda/5
Quoted 7 lines
Quoted 3 lines
Sorry to hear that, please work with the developers to get this resolved in Linus's tree and then we will be glad to apply the needed fix from there.
Should be sorted and land before 6.15:
https://git.kernel.dk/cgit/linux/commit/?h=block-6.15&id=355341e4359b2d5edf0ed5e117f7e9e7a0a5dac0
Great, thanks!
Greg Kroah-Hartman
maintainerPATCH 163/197 drm/panel: simple: Update timings for AUO G101EVN010
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kevin Baker <[email protected]>
[ Upstream commit 7c6fa1797a725732981f2d77711c867166737719 ]
Switch to panel timings based on datasheet for the AUO G101EVN01.0 LVDS panel. Default timings were tested on the panel.
Previous mode-based timings resulted in horizontal display shift.
--- drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
drivers/gpu/drm/panel/panel-simple.c +13 -12
@@ -1027,27 +1027,28 @@ static const struct panel_desc auo_g070vvn01 = { }, }; -static const struct drm_display_mode auo_g101evn010_mode = { - .clock =68930 , - .hdisplay =1280 , - .hsync_start =1280 +82 , - .hsync_end =1280 +82 +2 , - .htotal =1280 +82 +2 +84 , - .vdisplay =800 , - .vsync_start =800 +8 , - .vsync_end =800 +8 +2 , - .vtotal =800 +8 +2 +6 , +static const struct display_timing auo_g101evn010_timing = { + .pixelclock = {64000000 ,68930000 ,85000000 }, + .hactive = {1280 ,1280 ,1280 }, + .hfront_porch = {8 ,64 ,256 }, + .hback_porch = {8 ,64 ,256 }, + .hsync_len = {40 ,168 ,767 }, + .vactive = {800 ,800 ,800 }, + .vfront_porch = {4 ,8 ,100 }, + .vback_porch = {4 ,8 ,100 }, + .vsync_len = {8 ,16 ,223 }, };static const struct panel_desc auo_g101evn010 = { - .modes = &auo_g101evn010_mode, - .num_modes =1 , + .timings = &auo_g101evn010_timing, + .num_timings =1 , .bpc =6 , .size = { .width =216 , .height =135 , }, .bus_format =MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , + .bus_flags =DRM_BUS_FLAG_DE_HIGH , .connector_type =DRM_MODE_CONNECTOR_LVDS , };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 164/197 nvme: unblock ctrl state transition for firmware update
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Wagner <[email protected]>
[ Upstream commit 650415fca0a97472fdd79725e35152614d1aad76 ]
The original nvme subsystem design didn't have a CONNECTING state; the state machine allowed transitions from RESETTING to LIVE directly.
With the introduction of nvme fabrics the CONNECTING state was introduce. Over time the nvme-pci started to use the CONNECTING state as well.
Eventually, a bug fix for the nvme-fc started to depend that the only valid transition to LIVE was from CONNECTING. Though this change didn't update the firmware update handler which was still depending on RESETTING to LIVE transition.
The simplest way to address it for the time being is to switch into CONNECTING state before going to LIVE state.
--- drivers/nvme/host/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/core.c +2 -1
@@ -4492,7 +4492,8 @@ static void nvme_fw_act_work(struct work_struct *work)msleep (100 ); } -if (!nvme_change_ctrl_state (ctrl,NVME_CTRL_LIVE )) +if (!nvme_change_ctrl_state (ctrl,NVME_CTRL_CONNECTING ) || + !nvme_change_ctrl_state (ctrl,NVME_CTRL_LIVE ))return ;nvme_unquiesce_io_queues (ctrl);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 165/197 riscv: misaligned: factorize trap handling
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clément Léger <[email protected]>
[ Upstream commit fd94de9f9e7aac11ec659e386b9db1203d502023 ]
Since both load/store and user/kernel should use almost the same path and that we are going to add some code around that, factorize it.
Stable-dep-of: 453805f0a28f ("riscv: misaligned: enable IRQs while handling misaligned accesses")
--- arch/riscv/kernel/traps.c | 66 +++++++++++++++++++++------------------ 1 file changed, 36 insertions(+), 30 deletions(-)
arch/riscv/kernel/traps.c +36 -30
@@ -198,47 +198,53 @@ asmlinkage __visible __trap_section void do_trap_insn_illegal(struct pt_regs *reDO_ERROR_INFO (do_trap_load_fault,SIGSEGV ,SEGV_ACCERR ,"load access fault" ); -asmlinkage __visible __trap_section void do_trap_load_misaligned(struct pt_regs *regs) +enum misaligned_access_type { +MISALIGNED_STORE , +MISALIGNED_LOAD , +}; +static const struct { +const char *type_str; +int (*handler)(struct pt_regs *regs); +} misaligned_handler[] = { + [MISALIGNED_STORE ] = { + .type_str ="Oops - store (or AMO) address misaligned" , + .handler = handle_misaligned_store, + }, + [MISALIGNED_LOAD ] = { + .type_str ="Oops - load address misaligned" , + .handler = handle_misaligned_load, + }, +}; + +static void do_trap_misaligned (struct pt_regs *regs,enum misaligned_access_type type) { -if (user_mode (regs)) { +irqentry_state_t state; + +if (user_mode (regs))irqentry_enter_from_user_mode (regs); +else + state =irqentry_nmi_enter (regs); -if (handle_misaligned_load (regs)) -do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, -"Oops - load address misaligned" ); +if (misaligned_handler[type].handler (regs)) +do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, + misaligned_handler[type].type_str); +if (user_mode (regs))irqentry_exit_to_user_mode (regs); - }else { -irqentry_state_t state =irqentry_nmi_enter (regs); - -if (handle_misaligned_load (regs)) -do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, -"Oops - load address misaligned" ); - +else irqentry_nmi_exit (regs, state); - } } -asmlinkage __visible __trap_section void do_trap_store_misaligned(struct pt_regs *regs) +asmlinkage __visible __trap_section void do_trap_load_misaligned(struct pt_regs *regs) { -if (user_mode (regs)) { -irqentry_enter_from_user_mode (regs); - -if (handle_misaligned_store (regs)) -do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, -"Oops - store (or AMO) address misaligned" ); - -irqentry_exit_to_user_mode (regs); - }else { -irqentry_state_t state =irqentry_nmi_enter (regs); - -if (handle_misaligned_store (regs)) -do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, -"Oops - store (or AMO) address misaligned" ); +do_trap_misaligned (regs,MISALIGNED_LOAD ); +} -irqentry_nmi_exit (regs, state); - } +asmlinkage __visible __trap_section void do_trap_store_misaligned(struct pt_regs *regs) +{ +do_trap_misaligned (regs,MISALIGNED_STORE ); } +DO_ERROR_INFO (do_trap_store_fault,SIGSEGV ,SEGV_ACCERR ,"store (or AMO) access fault" ); DO_ERROR_INFO(do_trap_ecall_s,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 166/197 riscv: misaligned: enable IRQs while handling misaligned accesses
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clément Léger <[email protected]>
[ Upstream commit 453805f0a28fc5091e46145e6560c776f7c7a611 ]
We can safely reenable IRQs if coming from userspace. This allows to access user memory that could potentially trigger a page fault.
--- arch/riscv/kernel/traps.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
arch/riscv/kernel/traps.c +8 -4
@@ -220,19 +220,23 @@ static void do_trap_misaligned(struct pt_regs *regs, enum misaligned_access_type {irqentry_state_t state; -if (user_mode (regs)) +if (user_mode (regs)) {irqentry_enter_from_user_mode (regs); -else +local_irq_enable (); + }else { state =irqentry_nmi_enter (regs); + }if (misaligned_handler[type].handler (regs))do_trap_error (regs,SIGBUS ,BUS_ADRALN , regs->epc, misaligned_handler[type].type_str); -if (user_mode (regs)) +if (user_mode (regs)) { +local_irq_disable ();irqentry_exit_to_user_mode (regs); -else + }else {irqentry_nmi_exit (regs, state); + } } asmlinkage __visible __trap_section void do_trap_load_misaligned(struct pt_regs *regs)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 167/197 riscv: Disallow PR_GET_TAGGED_ADDR_CTRL without Supm
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Holland <[email protected]>
[ Upstream commit 7f1c3de1370bc6a8ad5157336b258067dac0ae9c ]
When the prctl() interface for pointer masking was added, it did not check that the pointer masking ISA extension was supported, only the individual submodes. Userspace could still attempt to disable pointer masking and query the pointer masking state. commit 81de1afb2dd1 ("riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL") disallowed the former, as the senvcfg write could crash on older systems. PR_GET_TAGGED_ADDR_CTRL state does not crash, because it reads only kernel-internal state and not senvcfg, but it should still be disallowed for consistency.
--- arch/riscv/kernel/process.c | 3 +++ 1 file changed, 3 insertions(+)
arch/riscv/kernel/process.c +3 -0
@@ -333,6 +333,9 @@ long get_tagged_addr_ctrl(struct task_struct *task)struct thread_info *ti =task_thread_info (task);long ret =0 ; +if (!riscv_has_extension_unlikely (RISCV_ISA_EXT_SUPM )) +return -EINVAL ; +if (is_compat_thread (ti))return -EINVAL ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 168/197 drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejas Upadhyay <[email protected]>
[ Upstream commit 51c0ee84e4dc339287b2d7335f2b54d747794c83 ]
LNCF registers report wrong values when XE_FORCEWAKE_GT only is held. Holding XE_FORCEWAKE_ALL ensures correct operations on LNCF regs.
V2(Himal):
- Use xe_force_wake_ref_has_domain
--- drivers/gpu/drm/xe/tests/xe_mocs.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/tests/xe_mocs.c +5 -2
@@ -46,8 +46,11 @@ static void read_l3cc_table(struct xe_gt *gt,unsigned int fw_ref, i;u32 reg_val; - fw_ref =xe_force_wake_get (gt_to_fw (gt),XE_FW_GT ); -KUNIT_ASSERT_NE_MSG (test, fw_ref,0 ,"Forcewake Failed.\n" ); + fw_ref =xe_force_wake_get (gt_to_fw (gt),XE_FORCEWAKE_ALL ); +if (!xe_force_wake_ref_has_domain (fw_ref,XE_FORCEWAKE_ALL )) { +xe_force_wake_put (gt_to_fw (gt), fw_ref); +KUNIT_ASSERT_TRUE_MSG (test, true,"Forcewake Failed.\n" ); + }for (i =0 ; i < info->num_mocs_regs; i++) {if (!(i &1 )) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 169/197 drm/xe: Release force wake first then runtime power
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuicheng Lin <[email protected]>
[ Upstream commit 9d271a4f5ba52520e448ab223b1a91c6e35f17c7 ]
xe_force_wake_get() is dependent on xe_pm_runtime_get(), so for the release path, xe_force_wake_put() should be called first then xe_pm_runtime_put().
Combine the error path and normal path together with goto.
--- drivers/gpu/drm/xe/xe_gt_debugfs.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/xe/xe_gt_debugfs.c +5 -4
@@ -92,22 +92,23 @@ static int hw_engines(struct xe_gt *gt, struct drm_printer *p)struct xe_hw_engine *hwe;enum xe_hw_engine_id id;unsigned int fw_ref; +int ret =0 ;xe_pm_runtime_get (xe); fw_ref =xe_force_wake_get (gt_to_fw (gt),XE_FORCEWAKE_ALL );if (!xe_force_wake_ref_has_domain (fw_ref,XE_FORCEWAKE_ALL )) { -xe_pm_runtime_put (xe); -xe_force_wake_put (gt_to_fw (gt), fw_ref); -return -ETIMEDOUT ; + ret = -ETIMEDOUT ; + goto fw_put; }for_each_hw_engine (hwe, gt, id)xe_hw_engine_print (hwe, p); +fw_put:xe_force_wake_put (gt_to_fw (gt), fw_ref);xe_pm_runtime_put (xe); -return 0 ; +return ret; }static int powergate_info (struct xe_gt *gt,struct drm_printer *p)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 170/197 io_uring/sqpoll: Increase task_work submission batch size
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabriel Krisman Bertazi <[email protected]>
[ Upstream commit 92835cebab120f8a5f023a26a792a2ac3f816c4f ]
Our QA team reported a 10%-23%, throughput reduction on an io_uring sqpoll testcase doing IO to a null_blk, that I traced back to a reduction of the device submission queue depth utilization. It turns out that, after commit af5d68f8892f ("io_uring/sqpoll: manage task_work privately"), we capped the number of task_work entries that can be completed from a single spin of sqpoll to only 8 entries, before the sqpoll goes around to (potentially) sleep. While this cap doesn't drive the submission side directly, it impacts the completion behavior, which affects the number of IO queued by fio per sqpoll cycle on the submission side, and io_uring ends up seeing less ios per sqpoll cycle. As a result, block layer plugging is less effective, and we see more time spent inside the block layer in profilings charts, and increased submission latency measured by fio.
There are other places that have increased overhead once sqpoll sleeps more often, such as the sqpoll utilization calculation. But, in this microbenchmark, those were not representative enough in perf charts, and their removal didn't yield measurable changes in throughput. The major overhead comes from the fact we plug less, and less often, when submitting to the block layer.
My benchmark is:
fio --ioengine=io_uring --direct=1 --iodepth=128 --runtime=300 --bs=4k \
--invalidate=1 --time_based --ramp_time=10 --group_reporting=1 \
--filename=/dev/nullb0 --name=RandomReads-direct-nullb-sqpoll-4k-1 \
--rw=randread --numjobs=1 --sqthread_pollIn one machine, tested on top of Linux 6.15-rc1, we have the following
baseline:
READ: bw=4994MiB/s (5236MB/s), 4994MiB/s-4994MiB/s (5236MB/s-5236MB/s), io=439GiB (471GB), run=90001-90001msec
With this patch:
READ: bw=5762MiB/s (6042MB/s), 5762MiB/s-5762MiB/s (6042MB/s-6042MB/s), io=506GiB (544GB), run=90001-90001msec
which is a 15% improvement in measured bandwidth. The average submission latency is noticeably lowered too. As measured by fio:
Baseline:
lat (usec): min=20, max=241, avg=99.81, stdev=3.38
Patched:
lat (usec): min=26, max=226, avg=86.48, stdev=4.82
If we look at blktrace, we can also see the plugging behavior is improved. In the baseline, we end up limited to plugging 8 requests in the block layer regardless of the device queue depth size, while after patching we can drive more io, and we manage to utilize the full device queue.
In the baseline, after a stabilization phase, an ordinary submission looks like:
254,0 1 49942 0.016028795 5977 U N [iou-sqp-5976] 7
After patching, I see consistently more requests per unplug.
254,0 1 4996 0.001432872 3145 U N [iou-sqp-3144] 32
Ideally, the cap size would at least be the deep enough to fill the device queue, but we can't predict that behavior, or assume all IO goes to a single device, and thus can't guess the ideal batch size. We also don't want to let the tw run unbounded, though I'm not sure it would really be a problem. Instead, let's just give it a more sensible value that will allow for more efficient batching. I've tested with different cap values, and initially proposed to increase the cap to 1024. Jens argued it is too big of a bump and I observed that, with 32, I'm no longer able to observe this bottleneck in any of my machines.
--- io_uring/sqpoll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/sqpoll.c +1 -1
@@ -20,7 +20,7 @@#include "sqpoll.h" #define IORING_SQPOLL_CAP_ENTRIES_VALUE 8 -#define IORING_TW_CAP_ENTRIES_VALUE 8 +#define IORING_TW_CAP_ENTRIES_VALUE 32enum {IO_SQ_THREAD_SHOULD_STOP =0 ,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 171/197 do_umount(): add missing barrier before refcount checks in sync case
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit 65781e19dcfcb4aed1167d87a3ffcc2a0c071d47 ]
do_umount() analogue of the race fixed in 119e1ef80ecf "fix __legitimize_mnt()/mntput() race". Here we want to make sure that if __legitimize_mnt() doesn't notice our lock_mount_hash(), we will notice their refcount increment. Harder to hit than mntput_no_expire() one, fortunately, and consequences are milder (sync umount acting like umount -l on a rare race with RCU pathwalk hitting at just the wrong time instead of use-after-free galore mntput_no_expire() counterpart used to be hit). Still a bug...
--- fs/namespace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/namespace.c +2 -1
@@ -778,7 +778,7 @@ int __legitimize_mnt(struct vfsmount *bastard, unsigned seq)return 0 ; mnt =real_mount (bastard);mnt_add_count (mnt,1 ); -smp_mb ();// see mntput_no_expire() +smp_mb ();// see mntput_no_expire() and do_umount() if (likely (!read_seqretry (&mount_lock, seq)))return 0 ;if (bastard->mnt_flags &MNT_SYNC_UMOUNT ) {
@@ -1956,6 +1956,7 @@ static int do_umount(struct mount *mnt, int flags)umount_tree (mnt,UMOUNT_PROPAGATE ); retval =0 ; }else { +smp_mb ();// paired with __legitimize_mnt() shrink_submounts (mnt); retval = -EBUSY ;if (!propagate_mount_busy (mnt,2 )) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 172/197 rust: allow Rust 1.87.0s `clippy::ptr_eq` lint
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit a39f3087092716f2bd531d6fdc20403c3dc2a879 upstream.
Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the ptr_eq lint, e.g.:
error: use `core::ptr::eq` when comparing raw pointers
--> rust/kernel/list.rs:438:12
|
438 | if self.first == item {
| ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq
= note: `-D clippy::ptr-eq` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]`It is expected that a PR to relax the lint will be backported [2] by the time Rust 1.87.0 releases, since the lint was considered too eager (at least by default) [3].
Thus allow the lint temporarily just in case.
--- rust/kernel/alloc/kvec.rs | 3 +++ rust/kernel/list.rs | 3 +++ 2 files changed, 6 insertions(+)
rust/kernel/alloc/kvec.rs +3 -0
@@ -2,6 +2,9 @@//! Implementation of [`Vec`]. +// May not be needed in Rust 1.87.0 (pending beta backport). +#![allow(clippy::ptr_eq)] +use super ::{ allocator::{KVmalloc ,Kmalloc ,Vmalloc }, layout::ArrayLayout ,
rust/kernel/list.rs +3 -0
@@ -4,6 +4,9 @@//! A linked list implementation. +// May not be needed in Rust 1.87.0 (pending beta backport). +#![allow(clippy::ptr_eq)] +use crate ::init::PinInit ;use crate ::sync::ArcBorrow ;use crate ::types::Opaque ;
Greg Kroah-Hartman
maintainerPATCH 173/197 rust: clean Rust 1.88.0s `clippy::uninlined_format_args` lint
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit 211dcf77856db64c73e0c3b9ce0c624ec855daca upstream.
Starting with Rust 1.88.0 (expected 2025-06-26) [1], rustc may move back the uninlined_format_args to style from pedantic (it was there waiting for rust-analyzer suppotr), and thus we will start to see lints like:
warning: variables can be used directly in the `format!` string
--> rust/macros/kunit.rs:105:37
|
105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
help: change this to
|
105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");There is even a case that is a pure removal:
warning: variables can be used directly in the `format!` string
--> rust/macros/module.rs:51:13
|
51 | format!("{field}={content}\0", field = field, content = content)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
help: change this to
|
51 - format!("{field}={content}\0", field = field, content = content)
51 + format!("{field}={content}\0")The lints all seem like nice cleanups, thus just apply them.
We may want to disable allow-mixed-uninlined-format-args in the future.
--- rust/kernel/str.rs | 46 ++++++++++++++++++++++----------------------- rust/macros/module.rs | 19 ++++-------------- rust/macros/paste.rs | 2 - rust/macros/pinned_drop.rs | 3 -- 4 files changed, 30 insertions(+), 40 deletions(-)
rust/kernel/str.rs +23 -23
@@ -56,7 +56,7 @@ impl fmt::Display for BStr { b'\r' => f.write_str("\\r")?,// Printable characters. 0x20..=0x7e => f.write_char(b as char)?, - _ => write!(f, "\\x{:02x}", b)?, + _ => write!(f, "\\x{b:02x}")?, } }Ok (())
@@ -92,7 +92,7 @@ impl fmt::Debug for BStr { b'\\' => f.write_str("\\\\")?,// Printable characters. 0x20..=0x7e => f.write_char(b as char)?, - _ => write!(f, "\\x{:02x}", b)?, + _ => write!(f, "\\x{b:02x}")?, } } f.write_char ('"' )
@@ -401,7 +401,7 @@ impl fmt::Display for CStr {// Printable character. f.write_char (cas char )?; }else { -write! (f,"\\x{:02x}" , c)?; +write! (f,"\\x{c:02x}" )?; } }Ok (())
@@ -433,7 +433,7 @@ impl fmt::Debug for CStr {// Printable characters. b'\"' => f.write_str("\\\"")?, 0x20..=0x7e => f.write_char(c as char)?, - _ => write!(f, "\\x{:02x}", c)?, + _ => write!(f, "\\x{c:02x}")?, } } f.write_str ("\"" )
@@ -595,13 +595,13 @@ mod tests {#[test] fn test_cstr_display () {let hello_world =CStr ::from_bytes_with_nul (b"hello, world!\0" ).unwrap (); -assert_eq! (format! ("{}" , hello_world),"hello, world!" ); +assert_eq! (format! ("{hello_world}" ),"hello, world!" );let non_printables =CStr ::from_bytes_with_nul (b"\x01\x09\x0a\0" ).unwrap (); -assert_eq! (format! ("{}" , non_printables),"\\x01\\x09\\x0a" ); +assert_eq! (format! ("{non_printables}" ),"\\x01\\x09\\x0a" );let non_ascii =CStr ::from_bytes_with_nul (b"d\xe9j\xe0 vu\0" ).unwrap (); -assert_eq! (format! ("{}" , non_ascii),"d\\xe9j\\xe0 vu" ); +assert_eq! (format! ("{non_ascii}" ),"d\\xe9j\\xe0 vu" );let good_bytes =CStr ::from_bytes_with_nul (b"\xf0\x9f\xa6\x80\0" ).unwrap (); -assert_eq! (format! ("{}" , good_bytes),"\\xf0\\x9f\\xa6\\x80" ); +assert_eq! (format! ("{good_bytes}" ),"\\xf0\\x9f\\xa6\\x80" ); }#[test]
@@ -612,47 +612,47 @@ mod tests { bytes[ias usize ] = i.wrapping_add (1 ); }let cstr =CStr ::from_bytes_with_nul (&bytes).unwrap (); -assert_eq! (format! ("{}" , cstr),ALL_ASCII_CHARS ); +assert_eq! (format! ("{cstr}" ),ALL_ASCII_CHARS ); }#[test] fn test_cstr_debug () {let hello_world =CStr ::from_bytes_with_nul (b"hello, world!\0" ).unwrap (); -assert_eq! (format! ("{:?}" , hello_world),"\"hello, world!\"" ); +assert_eq! (format! ("{hello_world:?}" ),"\"hello, world!\"" );let non_printables =CStr ::from_bytes_with_nul (b"\x01\x09\x0a\0" ).unwrap (); -assert_eq! (format! ("{:?}" , non_printables),"\"\\x01\\x09\\x0a\"" ); +assert_eq! (format! ("{non_printables:?}" ),"\"\\x01\\x09\\x0a\"" );let non_ascii =CStr ::from_bytes_with_nul (b"d\xe9j\xe0 vu\0" ).unwrap (); -assert_eq! (format! ("{:?}" , non_ascii),"\"d\\xe9j\\xe0 vu\"" ); +assert_eq! (format! ("{non_ascii:?}" ),"\"d\\xe9j\\xe0 vu\"" );let good_bytes =CStr ::from_bytes_with_nul (b"\xf0\x9f\xa6\x80\0" ).unwrap (); -assert_eq! (format! ("{:?}" , good_bytes),"\"\\xf0\\x9f\\xa6\\x80\"" ); +assert_eq! (format! ("{good_bytes:?}" ),"\"\\xf0\\x9f\\xa6\\x80\"" ); }#[test] fn test_bstr_display () {let hello_world =BStr ::from_bytes (b"hello, world!" ); -assert_eq! (format! ("{}" , hello_world),"hello, world!" ); +assert_eq! (format! ("{hello_world}" ),"hello, world!" );let escapes =BStr ::from_bytes (b"_\t_\n_\r_\\_\'_\"_" ); -assert_eq! (format! ("{}" , escapes),"_\\t_\\n_\\r_\\_'_\"_" ); +assert_eq! (format! ("{escapes}" ),"_\\t_\\n_\\r_\\_'_\"_" );let others =BStr ::from_bytes (b"\x01" ); -assert_eq! (format! ("{}" , others),"\\x01" ); +assert_eq! (format! ("{others}" ),"\\x01" );let non_ascii =BStr ::from_bytes (b"d\xe9j\xe0 vu" ); -assert_eq! (format! ("{}" , non_ascii),"d\\xe9j\\xe0 vu" ); +assert_eq! (format! ("{non_ascii}" ),"d\\xe9j\\xe0 vu" );let good_bytes =BStr ::from_bytes (b"\xf0\x9f\xa6\x80" ); -assert_eq! (format! ("{}" , good_bytes),"\\xf0\\x9f\\xa6\\x80" ); +assert_eq! (format! ("{good_bytes}" ),"\\xf0\\x9f\\xa6\\x80" ); }#[test] fn test_bstr_debug () {let hello_world =BStr ::from_bytes (b"hello, world!" ); -assert_eq! (format! ("{:?}" , hello_world),"\"hello, world!\"" ); +assert_eq! (format! ("{hello_world:?}" ),"\"hello, world!\"" );let escapes =BStr ::from_bytes (b"_\t_\n_\r_\\_\'_\"_" ); -assert_eq! (format! ("{:?}" , escapes),"\"_\\t_\\n_\\r_\\\\_'_\\\"_\"" ); +assert_eq! (format! ("{escapes:?}" ),"\"_\\t_\\n_\\r_\\\\_'_\\\"_\"" );let others =BStr ::from_bytes (b"\x01" ); -assert_eq! (format! ("{:?}" , others),"\"\\x01\"" ); +assert_eq! (format! ("{others:?}" ),"\"\\x01\"" );let non_ascii =BStr ::from_bytes (b"d\xe9j\xe0 vu" ); -assert_eq! (format! ("{:?}" , non_ascii),"\"d\\xe9j\\xe0 vu\"" ); +assert_eq! (format! ("{non_ascii:?}" ),"\"d\\xe9j\\xe0 vu\"" );let good_bytes =BStr ::from_bytes (b"\xf0\x9f\xa6\x80" ); -assert_eq! (format! ("{:?}" , good_bytes),"\"\\xf0\\x9f\\xa6\\x80\"" ); +assert_eq! (format! ("{good_bytes:?}" ),"\"\\xf0\\x9f\\xa6\\x80\"" ); } }
rust/macros/module.rs +5 -14
@@ -48,7 +48,7 @@ impl<'a> ModInfoBuilder<'a> { ) }else {// Loadable modules' modinfo strings go as-is. -format! ("{field}={content}\0" , field = field, content = content) +format! ("{field}={content}\0" ) };write! (
@@ -124,10 +124,7 @@ impl ModuleInfo { };if seen_keys.contains (&key) { -panic! ( -"Duplicated key \"{}\". Keys can only be specified once." , - key - ); +panic! ("Duplicated key \"{key}\". Keys can only be specified once." ); }assert_eq! (expect_punct (it),':' );
@@ -140,10 +137,7 @@ impl ModuleInfo { "license" => info.license = expect_string_ascii(it), "alias" => info.alias = Some(expect_string_array(it)), "firmware" => info.firmware = Some(expect_string_array(it)), - _ => panic!( -"Unknown key \"{}\". Valid keys are: {:?}." , - key,EXPECTED_KEYS - ), + _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."), }assert_eq! (expect_punct (it),',' );
@@ -155,7 +149,7 @@ impl ModuleInfo {for keyin REQUIRED_KEYS {if !seen_keys.iter ().any (|e| e == key) { -panic! ("Missing required key \"{}\"." , key); +panic! ("Missing required key \"{key}\"." ); } }
@@ -167,10 +161,7 @@ impl ModuleInfo { }if seen_keys != ordered_keys { -panic! ( -"Keys are not ordered as expected. Order them like: {:?}." , - ordered_keys - ); +panic! ("Keys are not ordered as expected. Order them like: {ordered_keys:?}." ); } info
rust/macros/paste.rs +1 -1
@@ -50,7 +50,7 @@ fn concat_helper(tokens: &[TokenTree]) -let tokens = group.stream ().into_iter ().collect ::<Vec <TokenTree >>(); segments.append (&mut concat_helper (tokens.as_slice ())); } - token => panic!("unexpected token in paste segments: {:?}", token), + token => panic!("unexpected token in paste segments: {token:?}"), }; }
rust/macros/pinned_drop.rs +1 -2
@@ -25,8 +25,7 @@ pub(crate) fn pinned_drop(_args: TokenSt// Found the end of the generics, this should be `PinnedDrop`. assert! (matches! (tt,TokenTree ::Ident (i)if i.to_string () =="PinnedDrop" ), -"expected 'PinnedDrop', found: '{:?}'" , - tt +"expected 'PinnedDrop', found: '{tt:?}'" ); pinned_drop_idx =Some (i);break ;
Greg Kroah-Hartman
maintainerPATCH 174/197 io_uring: always arm linked timeouts prior to issue
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit b53e523261bf058ea4a518b482222e7a277b186b upstream.
There are a few spots where linked timeouts are armed, and not all of them adhere to the pre-arm, attempt issue, post-arm pattern. This can be problematic if the linked request returns that it will trigger a callback later, and does so before the linked timeout is fully armed.
Consolidate all the linked timeout handling into __io_issue_sqe(), rather than have it spread throughout the various issue entry points.
--- io_uring/io_uring.c | 50 +++++++++++++++----------------------------------- 1 file changed, 15 insertions(+), 35 deletions(-)
io_uring/io_uring.c +15 -35
@@ -443,24 +443,6 @@ static struct io_kiocb *__io_prep_linkedreturn req->link; } -static inline struct io_kiocb *io_prep_linked_timeout (struct io_kiocb *req) -{ -if (likely (!(req->flags &REQ_F_ARM_LTIMEOUT ))) -return NULL ; -return __io_prep_linked_timeout (req); -} - -static noinline void __io_arm_ltimeout(struct io_kiocb *req) -{ -io_queue_linked_timeout (__io_prep_linked_timeout (req)); -} - -static inline void io_arm_ltimeout (struct io_kiocb *req) -{ -if (unlikely (req->flags &REQ_F_ARM_LTIMEOUT )) -__io_arm_ltimeout (req); -} -static void io_prep_async_work (struct io_kiocb *req) {const struct io_issue_def *def = &io_issue_defs[req->opcode];
@@ -513,7 +495,6 @@ static void io_prep_async_link(struct iostatic void io_queue_iowq (struct io_kiocb *req) { -struct io_kiocb *link =io_prep_linked_timeout (req);struct io_uring_task *tctx = req->tctx;BUG_ON (!tctx);
@@ -538,8 +519,6 @@ static void io_queue_iowq(struct io_kioctrace_io_uring_queue_async_work (req,io_wq_is_hashed (&req->work));io_wq_enqueue (tctx->io_wq, &req->work); -if (link) -io_queue_linked_timeout (link); }static void io_req_queue_iowq_tw (struct io_kiocb *req,struct io_tw_state *ts)
@@ -1728,17 +1707,24 @@ static bool io_assign_file(struct io_kioreturn !!req->file; } +#define REQ_ISSUE_SLOW_FLAGS (REQ_F_CREDS | REQ_F_ARM_LTIMEOUT) +static int io_issue_sqe (struct io_kiocb *req,unsigned int issue_flags) {const struct io_issue_def *def = &io_issue_defs[req->opcode];const struct cred *creds =NULL ; +struct io_kiocb *link =NULL ;int ret;if (unlikely (!io_assign_file (req, def, issue_flags)))return -EBADF ; -if (unlikely ((req->flags &REQ_F_CREDS ) && req->creds !=current_cred ())) - creds =override_creds (req->creds); +if (unlikely (req->flags &REQ_ISSUE_SLOW_FLAGS )) { +if ((req->flags &REQ_F_CREDS ) && req->creds !=current_cred ()) + creds =override_creds (req->creds); +if (req->flags &REQ_F_ARM_LTIMEOUT ) + link =__io_prep_linked_timeout (req); + }if (!def->audit_skip)audit_uring_entry (req->opcode);
@@ -1748,8 +1734,12 @@ static int io_issue_sqe(struct io_kiocbif (!def->audit_skip)audit_uring_exit (!ret, ret); -if (creds) -revert_creds (creds); +if (unlikely (creds || link)) { +if (creds) +revert_creds (creds); +if (link) +io_queue_linked_timeout (link); + }if (ret ==IOU_OK ) {if (issue_flags &IO_URING_F_COMPLETE_DEFER )
@@ -1762,7 +1752,6 @@ static int io_issue_sqe(struct io_kiocbif (ret ==IOU_ISSUE_SKIP_COMPLETE ) { ret =0 ; -io_arm_ltimeout (req);/* If the op doesn't have a file, we're not polling for it */ if ((req->ctx->flags &IORING_SETUP_IOPOLL ) && def->iopoll_queue)
@@ -1805,8 +1794,6 @@ void io_wq_submit_work(struct io_wq_workelse req_ref_get (req); -io_arm_ltimeout (req); -/* either cancelled or io-wq is dying, so don't touch tctx->iowq */ if (atomic_read (&work->flags) &IO_WQ_WORK_CANCEL ) { fail:
@@ -1922,15 +1909,11 @@ struct file *io_file_get_normal(struct istatic void io_queue_async (struct io_kiocb *req,int ret) __must_hold(&req->ctx->uring_lock) { -struct io_kiocb *linked_timeout; -if (ret != -EAGAIN || (req->flags &REQ_F_NOWAIT )) {io_req_defer_failed (req, ret);return ; } - linked_timeout =io_prep_linked_timeout (req); -switch (io_arm_poll_handler (req,0 )) {case IO_APOLL_READY :io_kbuf_recycle (req,0 );
@@ -1943,9 +1926,6 @@ static void io_queue_async(struct io_kiocase IO_APOLL_OK :break ; } - -if (linked_timeout) -io_queue_linked_timeout (linked_timeout); }static inline void io_queue_sqe (struct io_kiocb *req)
Greg Kroah-Hartman
maintainerPATCH 175/197 Bluetooth: btmtk: Remove the resetting step before downloading the fw
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hao Qin <[email protected]>
commit 33634e2ab7c6369391e0ca4b9b97dc861e33d20e upstream.
Remove the resetting step before downloading the fw, as it may cause other usb devices to fail to initialise when connected during boot on kernels 6.11 and newer.
--- drivers/bluetooth/btmtk.c | 10 ---------- 1 file changed, 10 deletions(-)
drivers/bluetooth/btmtk.c +0 -10
@@ -1330,13 +1330,6 @@ int btmtk_usb_setup(struct hci_dev *hdevbreak ;case 0x7922 :case 0x7925 : -/* Reset the device to ensure it's in the initial state before -* downloading the firmware to ensure. -*/ - -if (!test_bit (BTMTK_FIRMWARE_LOADED , &btmtk_data->flags)) -btmtk_usb_subsys_reset (hdev, dev_id); - fallthrough;case 0x7961 :btmtk_fw_get_filename (fw_bin_name,sizeof (fw_bin_name), dev_id, fw_version, fw_flavor);
@@ -1345,12 +1338,9 @@ int btmtk_usb_setup(struct hci_dev *hdev btmtk_usb_hci_wmt_sync);if (err <0 ) {bt_dev_err (hdev,"Failed to set up firmware (%d)" , err); -clear_bit (BTMTK_FIRMWARE_LOADED , &btmtk_data->flags);return err; } -set_bit (BTMTK_FIRMWARE_LOADED , &btmtk_data->flags); -/* It's Device EndPoint Reset Option Register */ err =btmtk_usb_uhw_reg_write (hdev,MTK_EP_RST_OPT ,MTK_EP_RST_IN_OUT_OPT );
Greg Kroah-Hartman
maintainerPATCH 176/197 mm: page_alloc: dont steal single pages from biggest buddy
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <[email protected]>
commit c2f6ea38fc1b640aa7a2e155cc1c0410ff91afa2 upstream.
The fallback code searches for the biggest buddy first in an attempt to steal the whole block and encourage type grouping down the line.
The approach used to be this:
- Non-movable requests will split the largest buddy and steal the remainder. This splits up contiguity, but it allows subsequent requests of this type to fall back into adjacent space.
- Movable requests go and look for the smallest buddy instead. The thinking is that movable requests can be compacted, so grouping is less important than retaining contiguity.
c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion") enforces freelist type hygiene, which restricts stealing to either claiming the whole block or just taking the requested chunk; no additional pages or buddy remainders can be stolen any more.
The patch mishandled when to switch to finding the smallest buddy in that new reality. As a result, it may steal the exact request size, but from the biggest buddy. This causes fracturing for no good reason.
Fix this by committing to the new behavior: either steal the whole block, or fall back to the smallest buddy.
Remove single-page stealing from steal_suitable_fallback(). Rename it to try_to_steal_block() to make the intentions clear. If this fails, always fall back to the smallest buddy.
The following is from 4 runs of mmtest's thpchallenge. "Pollute" is single page fallback, "steal" is conversion of a partially used block. The numbers for free block conversions (omitted) are comparable.
vanilla patched
@pollute[unmovable from reclaimable]: 27 106
@pollute[unmovable from movable]: 82 46
@pollute[reclaimable from unmovable]: 256 83
@pollute[reclaimable from movable]: 46 8
@pollute[movable from unmovable]: 4841 868
@pollute[movable from reclaimable]: 5278 12568
@steal[unmovable from reclaimable]: 11 12
@steal[unmovable from movable]: 113 49
@steal[reclaimable from unmovable]: 19 34
@steal[reclaimable from movable]: 47 21
@steal[movable from unmovable]: 250 183
@steal[movable from reclaimable]: 81 93
The allocator appears to do a better job at keeping stealing and polluting to the first fallback preference. As a result, the numbers for "from movable" - the least preferred fallback option, and most detrimental to compactability - are down across the board.
--- mm/page_alloc.c | 80 +++++++++++++++++++++++--------------------------------- 1 file changed, 34 insertions(+), 46 deletions(-)
mm/page_alloc.c +34 -46
@@ -1908,13 +1908,12 @@ static inline bool boost_watermark(struc* can claim the whole pageblock for the requested migratetype. If not, we check * the pageblock for constituent pages; if at least half of the pages are free * or compatible, we can still claim the whole block, so pages freed in the -* future will be put on the correct free list. Otherwise, we isolate exactly -* the order we need from the fallback block and leave its migratetype alone. +* future will be put on the correct free list. */ static struct page * -steal_suitable_fallback (struct zone *zone,struct page *page, -int current_order,int order,int start_type, -unsigned int alloc_flags,bool whole_block) +try_to_steal_block (struct zone *zone,struct page *page, +int current_order,int order,int start_type, +unsigned int alloc_flags) {int free_pages, movable_pages, alike_pages;unsigned long start_pfn;
@@ -1927,7 +1926,7 @@ steal_suitable_fallback(struct zone *zon* highatomic accounting. */ if (is_migrate_highatomic (block_type)) - goto single_page; +return NULL ;/* Take ownership for orders >= pageblock_order */ if (current_order >= pageblock_order) {
@@ -1948,14 +1947,10 @@ steal_suitable_fallback(struct zone *zonif (boost_watermark (zone) && (alloc_flags &ALLOC_KSWAPD ))set_bit (ZONE_BOOSTED_WATERMARK , &zone->flags); -/* We are not allowed to try stealing from the whole block */ -if (!whole_block) - goto single_page; -/* moving whole block can fail due to zone boundary conditions */ if (!prep_move_freepages_block (zone, page, &start_pfn, &free_pages, &movable_pages)) - goto single_page; +return NULL ;/* * Determine how many pages are compatible with our allocation.
@@ -1988,9 +1983,7 @@ steal_suitable_fallback(struct zone *zonreturn __rmqueue_smallest (zone, order, start_type); } -single_page: -page_del_and_expand (zone, page, order, current_order, block_type); -return page; +return NULL ; }/*
@@ -2172,14 +2165,19 @@ static bool unreserve_highatomic_pageblo }/* -* Try finding a free buddy page on the fallback list and put it on the free -* list of requested migratetype, possibly along with other pages from the same -* block, depending on fragmentation avoidance heuristics. Returns true if -* fallback was found so that __rmqueue_smallest() can grab it. +* Try finding a free buddy page on the fallback list. +* +* This will attempt to steal a whole pageblock for the requested type +* to ensure grouping of such requests in the future. +* +* If a whole block cannot be stolen, regress to __rmqueue_smallest() +* logic to at least break up as little contiguity as possible. * * The use of signed ints for order and current_order is a deliberate * deviation from the rest of this file, to make the for loop * condition simpler. +* +* Return the stolen page, or NULL if none can be found. */ static __always_inline struct page * __rmqueue_fallback(struct zone *zone, int order, int start_migratetype,
@@ -2213,45 +2211,35 @@ __rmqueue_fallback(struct zone *zone, inif (fallback_mt ==-1 )continue ; -/* -* We cannot steal all free pages from the pageblock and the -* requested migratetype is movable. In that case it's better to -* steal and split the smallest available page instead of the -* largest available page, because even if the next movable -* allocation falls back into a different pageblock than this -* one, it won't cause permanent fragmentation. -*/ -if (!can_steal && start_migratetype ==MIGRATE_MOVABLE - && current_order > order) - goto find_smallest; +if (!can_steal) +break ; - goto do_steal; + page =get_page_from_free_area (area, fallback_mt); + page =try_to_steal_block (zone, page, current_order, order, + start_migratetype, alloc_flags); +if (page) + goto got_one; } -return NULL ; +if (alloc_flags &ALLOC_NOFRAGMENT ) +return NULL ; -find_smallest: +/* No luck stealing blocks. Find the smallest fallback page */ for (current_order = order; current_order <NR_PAGE_ORDERS ; current_order++) { area = &(zone->free_area[current_order]); fallback_mt =find_suitable_fallback (area, current_order, start_migratetype, false, &can_steal); -if (fallback_mt !=-1 ) -break ; - } - -/* -* This should not happen - we already found a suitable fallback -* when looking for the largest page. -*/ -VM_BUG_ON (current_order >MAX_PAGE_ORDER ); +if (fallback_mt ==-1 ) +continue ; -do_steal: - page =get_page_from_free_area (area, fallback_mt); + page =get_page_from_free_area (area, fallback_mt); +page_del_and_expand (zone, page, order, current_order, fallback_mt); + goto got_one; + } -/* take off list, maybe claim block, expand remainder */ - page =steal_suitable_fallback (zone, page, current_order, order, - start_migratetype, alloc_flags, can_steal); +return NULL ; +got_one:trace_mm_page_alloc_extfrag (page, order, current_order, start_migratetype, fallback_mt);
Greg Kroah-Hartman
maintainerPATCH 177/197 mm: page_alloc: speed up fallbacks in rmqueue_bulk()
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <[email protected]>
commit 90abee6d7895d5eef18c91d870d8168be4e76e9d upstream.
The test robot identified c2f6ea38fc1b ("mm: page_alloc: don't steal single pages from biggest buddy") as the root cause of a 56.4% regression in vm-scalability::lru-file-mmap-read.
Carlos reports an earlier patch, c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion"), as the root cause for a regression in worst-case zone->lock+irqoff hold times.
Both of these patches modify the page allocator's fallback path to be less greedy in an effort to stave off fragmentation. The flip side of this is that fallbacks are also less productive each time around, which means the fallback search can run much more frequently.
Carlos' traces point to rmqueue_bulk() specifically, which tries to refill the percpu cache by allocating a large batch of pages in a loop. It highlights how once the native freelists are exhausted, the fallback code first scans orders top-down for whole blocks to claim, then falls back to a bottom-up search for the smallest buddy to steal. For the next batch page, it goes through the same thing again.
This can be made more efficient. Since rmqueue_bulk() holds the zone->lock over the entire batch, the freelists are not subject to outside changes; when the search for a block to claim has already failed, there is no point in trying again for the next page.
Modify __rmqueue() to remember the last successful fallback mode, and restart directly from there on the next rmqueue_bulk() iteration.
Oliver confirms that this improves beyond the regression that the test robot reported against c2f6ea38fc1b:
commit:
f3b92176f4 ("tools/selftests: add guard region test for /proc/$pid/pagemap") c2f6ea38fc ("mm: page_alloc: don't steal single pages from biggest buddy") acc4d5ff0b ("Merge tag 'net-6.15-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net")
2c847f27c3 ("mm: page_alloc: speed up fallbacks in rmqueue_bulk()") <--- your patch
f3b92176f4f7100f c2f6ea38fc1b640aa7a2e155cc1 acc4d5ff0b61eb1715c498b6536 2c847f27c37da65a93d23c237c5 ---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
25525364 ± 3% -56.4% 11135467 -57.8% 10779336 +31.6% 33581409 vm-scalability.throughput
Carlos confirms that worst-case times are almost fully recovered compared to before the earlier culprit patch:
2dd482ba627d (before freelist hygiene): 1ms
c0cd6f557b90 (after freelist hygiene): 90ms
next-20250319 (steal smallest buddy): 280ms
this patch : 8ms
--- mm/page_alloc.c | 113 +++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 80 insertions(+), 33 deletions(-)
mm/page_alloc.c +80 -33
@@ -2165,22 +2165,15 @@ static bool unreserve_highatomic_pageblo }/* -* Try finding a free buddy page on the fallback list. -* -* This will attempt to steal a whole pageblock for the requested type -* to ensure grouping of such requests in the future. -* -* If a whole block cannot be stolen, regress to __rmqueue_smallest() -* logic to at least break up as little contiguity as possible. +* Try to allocate from some fallback migratetype by claiming the entire block, +* i.e. converting it to the allocation's start migratetype. * * The use of signed ints for order and current_order is a deliberate * deviation from the rest of this file, to make the for loop * condition simpler. -* -* Return the stolen page, or NULL if none can be found. */ static __always_inline struct page * -__rmqueue_fallback (struct zone *zone,int order,int start_migratetype, +__rmqueue_claim (struct zone *zone,int order,int start_migratetype,unsigned int alloc_flags) {struct free_area *area;
@@ -2217,14 +2210,29 @@ __rmqueue_fallback(struct zone *zone, in page =get_page_from_free_area (area, fallback_mt); page =try_to_steal_block (zone, page, current_order, order, start_migratetype, alloc_flags); -if (page) - goto got_one; +if (page) { +trace_mm_page_alloc_extfrag (page, order, current_order, + start_migratetype, fallback_mt); +return page; + } } -if (alloc_flags &ALLOC_NOFRAGMENT ) -return NULL ; +return NULL ; +} + +/* +* Try to steal a single page from some fallback migratetype. Leave the rest of +* the block as its current migratetype, potentially causing fragmentation. +*/ +static __always_inline struct page * +__rmqueue_steal (struct zone *zone,int order,int start_migratetype) +{ +struct free_area *area; +int current_order; +struct page *page; +int fallback_mt; +bool can_steal; -/* No luck stealing blocks. Find the smallest fallback page */ for (current_order = order; current_order <NR_PAGE_ORDERS ; current_order++) { area = &(zone->free_area[current_order]); fallback_mt = find_suitable_fallback(area, current_order,
@@ -2234,25 +2242,28 @@ __rmqueue_fallback(struct zone *zone, in page =get_page_from_free_area (area, fallback_mt);page_del_and_expand (zone, page, order, current_order, fallback_mt); - goto got_one; +trace_mm_page_alloc_extfrag (page, order, current_order, + start_migratetype, fallback_mt); +return page; }return NULL ; - -got_one: -trace_mm_page_alloc_extfrag (page, order, current_order, - start_migratetype, fallback_mt); - -return page; } +enum rmqueue_mode { +RMQUEUE_NORMAL , +RMQUEUE_CMA , +RMQUEUE_CLAIM , +RMQUEUE_STEAL , +}; +/* * Do the hard work of removing an element from the buddy allocator. * Call me with the zone->lock already held. */ static __always_inline struct page *__rmqueue (struct zone *zone,unsigned int order,int migratetype, -unsigned int alloc_flags) +unsigned int alloc_flags,enum rmqueue_mode *mode) {struct page *page;
@@ -2271,16 +2282,49 @@ __rmqueue(struct zone *zone, unsigned in } } - page =__rmqueue_smallest (zone, order, migratetype); -if (unlikely (!page)) { -if (alloc_flags &ALLOC_CMA ) +/* +* First try the freelists of the requested migratetype, then try +* fallbacks modes with increasing levels of fragmentation risk. +* +* The fallback logic is expensive and rmqueue_bulk() calls in +* a loop with the zone->lock held, meaning the freelists are +* not subject to any outside changes. Remember in *mode where +* we found pay dirt, to save us the search on the next call. +*/ +switch (*mode) { +case RMQUEUE_NORMAL : + page =__rmqueue_smallest (zone, order, migratetype); +if (page) +return page; + fallthrough; +case RMQUEUE_CMA : +if (alloc_flags &ALLOC_CMA ) { page =__rmqueue_cma_fallback (zone, order); +if (page) { + *mode =RMQUEUE_CMA ; +return page; + } + } + fallthrough; +case RMQUEUE_CLAIM : + page =__rmqueue_claim (zone, order, migratetype, alloc_flags); +if (page) { +/* Replenished preferred freelist, back to normal mode. */ + *mode =RMQUEUE_NORMAL ; +return page; + } + fallthrough; +case RMQUEUE_STEAL : +if (!(alloc_flags &ALLOC_NOFRAGMENT )) { + page =__rmqueue_steal (zone, order, migratetype); +if (page) { + *mode =RMQUEUE_STEAL ; +return page; + } + } + } -if (!page) - page =__rmqueue_fallback (zone, order, migratetype, - alloc_flags); - } -return page; +return NULL ; }/*
@@ -2292,13 +2336,14 @@ static int rmqueue_bulk(struct zone *zon unsigned long count, struct list_head *list, int migratetype, unsigned int alloc_flags) { + enum rmqueue_mode rmqm = RMQUEUE_NORMAL;unsigned long flags;int i;spin_lock_irqsave (&zone->lock, flags);for (i =0 ; i < count; ++i) {struct page *page =__rmqueue (zone, order, migratetype, - alloc_flags); + alloc_flags, &rmqm);if (unlikely (page ==NULL ))break ;
@@ -2899,7 +2944,9 @@ struct page *rmqueue_buddy(struct zone *if (alloc_flags &ALLOC_HIGHATOMIC ) page =__rmqueue_smallest (zone, order,MIGRATE_HIGHATOMIC );if (!page) { - page =__rmqueue (zone, order, migratetype, alloc_flags); +enum rmqueue_mode rmqm =RMQUEUE_NORMAL ; + + page =__rmqueue (zone, order, migratetype, alloc_flags, &rmqm);/* * If the allocation fails, allow OOM handling and
Greg Kroah-Hartman
maintainerPATCH 178/197 arm64: insn: Add support for encoding DSB
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit 63de8abd97ddb9b758bd8f915ecbd18e1f1a87a0 upstream.
To generate code in the eBPF epilogue that uses the DSB instruction, insn.c needs a heler to encode the type and domain.
Re-use the crm encoding logic from the DMB instruction.
--- arch/arm64/include/asm/insn.h | 1 arch/arm64/lib/insn.c | 60 +++++++++++++++++++++++++----------------- 2 files changed, 38 insertions(+), 23 deletions(-)
arch/arm64/include/asm/insn.h +1 -0
@@ -698,6 +698,7 @@ u32 aarch64_insn_gen_cas(enum aarch64_in }#endif u32 aarch64_insn_gen_dmb (enum aarch64_insn_mb_type type); +u32 aarch64_insn_gen_dsb (enum aarch64_insn_mb_type type);u32 aarch64_insn_gen_mrs (enum aarch64_insn_register result,enum aarch64_insn_system_register sysreg);
arch/arm64/lib/insn.c +37 -23
91 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 179/197 arm64: proton-pack: Expose whether the platform is mitigated by firmware
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit e7956c92f396a44eeeb6eaf7a5b5e1ad24db6748 upstream.
is_spectre_bhb_fw_affected() allows the caller to determine if the CPU is known to need a firmware mitigation. CPUs are either on the list of CPUs we know about, or firmware has been queried and reported that the platform is affected - and mitigated by firmware.
This helper is not useful to determine if the platform is mitigated by firmware. A CPU could be on the know list, but the firmware may not be implemented. Its affected but not mitigated.
spectre_bhb_enable_mitigation() handles this distinction by checking the firmware state before enabling the mitigation.
Add a helper to expose this state. This will be used by the BPF JIT to determine if calling firmware for a mitigation is necessary and supported.
--- arch/arm64/include/asm/spectre.h | 1 + arch/arm64/kernel/proton-pack.c | 5 +++++ 2 files changed, 6 insertions(+)
arch/arm64/include/asm/spectre.h +1 -0
@@ -97,6 +97,7 @@ enum mitigation_state arm64_get_meltdownenum mitigation_state arm64_get_spectre_bhb_state (void );bool is_spectre_bhb_affected (const struct arm64_cpu_capabilities *entry,int scope); +bool is_spectre_bhb_fw_mitigated (void );void spectre_bhb_enable_mitigation (const struct arm64_cpu_capabilities *__unused);bool try_emulate_el1_ssbs (struct pt_regs *regs,u32 instr);
arch/arm64/kernel/proton-pack.c +5 -0
@@ -1093,6 +1093,11 @@ void spectre_bhb_enable_mitigation(constupdate_mitigation_state (&spectre_bhb_state, state); } +bool is_spectre_bhb_fw_mitigated (void ) +{ +return test_bit (BHB_FW , &system_bhb_mitigations); +} +/* Patched to NOP when enabled */ void noinstr spectre_bhb_patch_loop_mitigation_enable(struct alt_instr *alt, __le32 *origptr,
Greg Kroah-Hartman
maintainerPATCH 180/197 arm64: proton-pack: Expose whether the branchy loop k value
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit a1152be30a043d2d4dcb1683415f328bf3c51978 upstream.
Add a helper to expose the k value of the branchy loop. This is needed by the BPF JIT to generate the mitigation sequence in BPF programs.
--- arch/arm64/include/asm/spectre.h | 1 + arch/arm64/kernel/proton-pack.c | 5 +++++ 2 files changed, 6 insertions(+)
arch/arm64/include/asm/spectre.h +1 -0
@@ -97,6 +97,7 @@ enum mitigation_state arm64_get_meltdownenum mitigation_state arm64_get_spectre_bhb_state (void );bool is_spectre_bhb_affected (const struct arm64_cpu_capabilities *entry,int scope); +u8 get_spectre_bhb_loop_value (void );bool is_spectre_bhb_fw_mitigated (void );void spectre_bhb_enable_mitigation (const struct arm64_cpu_capabilities *__unused);bool try_emulate_el1_ssbs (struct pt_regs *regs,u32 instr);
arch/arm64/kernel/proton-pack.c +5 -0
@@ -998,6 +998,11 @@ bool is_spectre_bhb_affected(const strucreturn true; } +u8 get_spectre_bhb_loop_value (void ) +{ +return max_bhb_k; +} +static void this_cpu_set_vectors (enum arm64_bp_harden_el1_vectors slot) {const char *v =arm64_get_bp_hardening_vector (slot);
Greg Kroah-Hartman
maintainerPATCH 181/197 arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit 0dfefc2ea2f29ced2416017d7e5b1253a54c2735 upstream.
A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by seccomp.
--- arch/arm64/include/asm/spectre.h | 1 arch/arm64/kernel/proton-pack.c | 2 - arch/arm64/net/bpf_jit_comp.c | 54 ++++++++++++++++++++++++++++++++++++--- 3 files changed, 52 insertions(+), 5 deletions(-)
arch/arm64/include/asm/spectre.h +1 -0
@@ -97,6 +97,7 @@ enum mitigation_state arm64_get_meltdownenum mitigation_state arm64_get_spectre_bhb_state (void );bool is_spectre_bhb_affected (const struct arm64_cpu_capabilities *entry,int scope); +extern bool __nospectre_bhb;u8 get_spectre_bhb_loop_value (void );bool is_spectre_bhb_fw_mitigated (void );void spectre_bhb_enable_mitigation (const struct arm64_cpu_capabilities *__unused);
arch/arm64/kernel/proton-pack.c +1 -1
@@ -1020,7 +1020,7 @@ static void this_cpu_set_vectors(enum arisb (); } -static bool __read_mostly __nospectre_bhb; +bool __read_mostly __nospectre_bhb;static int __init parse_spectre_bhb_param (char *str) { __nospectre_bhb = true;
arch/arm64/net/bpf_jit_comp.c +50 -4
93 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 182/197 arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit f300769ead032513a68e4a02e806393402e626f8 upstream.
Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB.
In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.
--- arch/arm64/net/bpf_jit_comp.c | 3 +++ 1 file changed, 3 insertions(+)
arch/arm64/net/bpf_jit_comp.c +3 -0
@@ -877,6 +877,9 @@ static void __maybe_unused build_bhb_mit arm64_get_spectre_v2_state() == SPECTRE_VULNERABLE)return ; +if (capable (CAP_SYS_ADMIN )) +return ; +if (supports_clearbhb (SCOPE_SYSTEM )) {emit (aarch64_insn_gen_hint (AARCH64_INSN_HINT_CLEARBHB ), ctx);return ;
Greg Kroah-Hartman
maintainerPATCH 183/197 arm64: proton-pack: Add new CPUs k values for branch mitigation
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit efe676a1a7554219eae0b0dcfe1e0cdcc9ef9aef upstream.
Update the list of 'k' values for the branch mitigation from arm's website.
Add the values for Cortex-X1C. The MIDR_EL1 value can be found here:
https://developer.arm.com/documentation/101968/0002/Register-descriptions/AArch>
--- arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/proton-pack.c | 1 + 2 files changed, 3 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -81,6 +81,7 @@#define ARM_CPU_PART_CORTEX_A78AE 0xD42#define ARM_CPU_PART_CORTEX_X1 0xD44#define ARM_CPU_PART_CORTEX_A510 0xD46 +#define ARM_CPU_PART_CORTEX_X1C 0xD4C#define ARM_CPU_PART_CORTEX_A520 0xD80#define ARM_CPU_PART_CORTEX_A710 0xD47#define ARM_CPU_PART_CORTEX_A715 0xD4D
@@ -167,6 +168,7 @@#define MIDR_CORTEX_A78AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78AE)#define MIDR_CORTEX_X1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1)#define MIDR_CORTEX_A510 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A510) +#define MIDR_CORTEX_X1C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1C)#define MIDR_CORTEX_A520 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A520)#define MIDR_CORTEX_A710 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A710)#define MIDR_CORTEX_A715 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A715)
arch/arm64/kernel/proton-pack.c +1 -0
@@ -891,6 +891,7 @@ static u8 spectre_bhb_loop_affected(voidMIDR_ALL_VERSIONS (MIDR_CORTEX_A78AE ),MIDR_ALL_VERSIONS (MIDR_CORTEX_A78C ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X1 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X1C ),MIDR_ALL_VERSIONS (MIDR_CORTEX_A710 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X2 ), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
Greg Kroah-Hartman
maintainerPATCH 184/197 x86/bpf: Call branch history clearing sequence on exit
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Sneddon <[email protected]>
commit d4e89d212d401672e9cdfe825d947ee3a9fbe3f5 upstream.
Classic BPF programs have been identified as potential vectors for intra-mode Branch Target Injection (BTI) attacks. Classic BPF programs can be run by unprivileged users. They allow unprivileged code to execute inside the kernel. Attackers can use unprivileged cBPF to craft branch history in kernel mode that can influence the target of indirect branches.
Introduce a branch history buffer (BHB) clearing sequence during the JIT compilation of classic BPF programs. The clearing sequence is the same as is used in previous mitigations to protect syscalls. Since eBPF programs already have their own mitigations in place, only insert the call on classic programs that aren't run by privileged users.
--- arch/x86/net/bpf_jit_comp.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
arch/x86/net/bpf_jit_comp.c +31 -0
@@ -1450,6 +1450,30 @@ static void emit_priv_frame_ptr(u8 **ppr#define PRIV_STACK_GUARD_SZ 8#define PRIV_STACK_GUARD_VAL 0xEB9F12345678eb9fULL +static int emit_spectre_bhb_barrier (u8 **pprog,u8 *ip, +struct bpf_prog *bpf_prog) +{ +u8 *prog = *pprog; +u8 *func; + +if (cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_LOOP )) { +/* The clearing sequence clobbers eax and ecx. */ +EMIT1 (0x50 );/* push rax */ +EMIT1 (0x51 );/* push rcx */ + ip +=2 ; + + func = (u8 *)clear_bhb_loop; + ip +=x86_call_depth_emit_accounting (&prog, func, ip); + +if (emit_call (&prog, func, ip)) +return -EINVAL ; +EMIT1 (0x59 );/* pop rcx */ +EMIT1 (0x58 );/* pop rax */ + } + *pprog = prog; +return 0 ; +} +static int do_jit (struct bpf_prog *bpf_prog,int *addrs,u8 *image,u8 *rw_image,int oldproglen,struct jit_context *ctx,bool jmp_padding) {
@@ -2467,6 +2491,13 @@ emit_jmp: seen_exit = true;/* Update cleanup_addr */ ctx->cleanup_addr = proglen; +if (bpf_prog_was_classic (bpf_prog) && + !capable (CAP_SYS_ADMIN )) { +u8 *ip = image + addrs[i -1 ]; + +if (emit_spectre_bhb_barrier (&prog, ip, bpf_prog)) +return -EINVAL ; + }if (bpf_prog->aux->exception_boundary) {pop_callee_regs (&prog, all_callee_regs_used);pop_r12 (&prog);
Greg Kroah-Hartman
maintainerPATCH 185/197 x86/bpf: Add IBHF call at end of classic BPF
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Sneddon <[email protected]>
commit 9f725eec8fc0b39bdc07dcc8897283c367c1a163 upstream.
Classic BPF programs can be run by unprivileged users, allowing unprivileged code to execute inside the kernel. Attackers can use this to craft branch history in kernel mode that can influence the target of indirect branches.
BHI_DIS_S provides user-kernel isolation of branch history, but cBPF can be used to bypass this protection by crafting branch history in kernel mode. To stop intra-mode attacks via cBPF programs, Intel created a new instruction Indirect Branch History Fence (IBHF). IBHF prevents the predicted targets of subsequent indirect branches from being influenced by branch history prior to the IBHF. IBHF is only effective while BHI_DIS_S is enabled.
Add the IBHF instruction to cBPF jitted code's exit path. Add the new fence when the hardware mitigation is enabled (i.e., X86_FEATURE_CLEAR_BHB_HW is set) or after the software sequence (X86_FEATURE_CLEAR_BHB_LOOP) is being used in a virtual machine. Note that X86_FEATURE_CLEAR_BHB_HW and X86_FEATURE_CLEAR_BHB_LOOP are mutually exclusive, so the JIT compiler will only emit the new fence, not the SW sequence, when X86_FEATURE_CLEAR_BHB_HW is set.
Hardware that enumerates BHI_NO basically has BHI_DIS_S protections always enabled, regardless of the value of BHI_DIS_S. Since BHI_DIS_S doesn't protect against intra-mode attacks, enumerate BHI bug on BHI_NO hardware as well.
--- arch/x86/kernel/cpu/common.c | 9 ++++++--- arch/x86/net/bpf_jit_comp.c | 19 +++++++++++++++++++ 2 files changed, 25 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/common.c +6 -3
@@ -1436,9 +1436,12 @@ static void __init cpu_set_bug_bits(struif (vulnerable_to_rfds (x86_arch_cap_msr))setup_force_cpu_bug (X86_BUG_RFDS ); -/* When virtualized, eIBRS could be hidden, assume vulnerable */ -if (!(x86_arch_cap_msr &ARCH_CAP_BHI_NO ) && - !cpu_matches (cpu_vuln_whitelist,NO_BHI ) && +/* +* Intel parts with eIBRS are vulnerable to BHI attacks. Parts with +* BHI_NO still need to use the BHI mitigation to prevent Intra-mode +* attacks. When virtualized, eIBRS could be hidden, assume vulnerable. +*/ +if (!cpu_matches (cpu_vuln_whitelist,NO_BHI ) && (boot_cpu_has (X86_FEATURE_IBRS_ENHANCED ) ||boot_cpu_has (X86_FEATURE_HYPERVISOR )))setup_force_cpu_bug (X86_BUG_BHI );
arch/x86/net/bpf_jit_comp.c +19 -0
@@ -41,6 +41,8 @@ static u8 *emit_code(u8 *ptr, u32 bytes,#define EMIT2 (b1, b2) EMIT((b1) + ((b2) << 8), 2)#define EMIT3 (b1, b2, b3) EMIT((b1) + ((b2) << 8) + ((b3) << 16), 3)#define EMIT4 (b1, b2, b3, b4) EMIT((b1) + ((b2) << 8) + ((b3) << 16) + ((b4) << 24), 4) +#define EMIT5 (b1, b2, b3, b4, b5) \ + do { EMIT1(b1); EMIT4(b2, b3, b4, b5); } while (0)#define EMIT1_off32 (b1, off) \ do { EMIT1(b1); EMIT(off, 4); } while (0)
@@ -1470,6 +1472,23 @@ static int emit_spectre_bhb_barrier(u8 *EMIT1 (0x59 );/* pop rcx */ EMIT1 (0x58 );/* pop rax */ } +/* Insert IBHF instruction */ +if ((cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_LOOP ) && +cpu_feature_enabled (X86_FEATURE_HYPERVISOR )) || + (cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_HW ) && +IS_ENABLED (CONFIG_X86_64 ))) { +/* +* Add an Indirect Branch History Fence (IBHF). IBHF acts as a +* fence preventing branch history from before the fence from +* affecting indirect branches after the fence. This is +* specifically used in cBPF jitted code to prevent Intra-mode +* BHI attacks. The IBHF instruction is designed to be a NOP on +* hardware that doesn't need or support it. The REP and REX.W +* prefixes are required by the microcode, and they also ensure +* that the NOP is unlikely to be used in existing code. +*/ +EMIT5 (0xF3 ,0x48 ,0x0F ,0x1E ,0xF8 );/* ibhf */ + } *pprog = prog;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 186/197 x86/bhi: Do not set BHI_DIS_S in 32-bit mode
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 073fdbe02c69c43fb7c0d547ec265c7747d4a646 upstream.
With the possibility of intra-mode BHI via cBPF, complete mitigation for BHI is to use IBHF (history fence) instruction with BHI_DIS_S set. Since this new instruction is only available in 64-bit mode, setting BHI_DIS_S in 32-bit mode is only a partial mitigation.
Do not set BHI_DIS_S in 32-bit mode so as to avoid reporting misleading mitigated status. With this change IBHF won't be used in 32-bit mode, also remove the CONFIG_X86_64 check from emit_spectre_bhb_barrier().
--- arch/x86/kernel/cpu/bugs.c | 6 +++--- arch/x86/net/bpf_jit_comp.c | 5 +++-- 2 files changed, 6 insertions(+), 5 deletions(-)
arch/x86/kernel/cpu/bugs.c +3 -3
@@ -1684,11 +1684,11 @@ static void __init bhi_select_mitigationreturn ; } -/* Mitigate in hardware if supported */ -if (spec_ctrl_bhi_dis ()) +if (!IS_ENABLED (CONFIG_X86_64 ))return ; -if (!IS_ENABLED (CONFIG_X86_64 )) +/* Mitigate in hardware if supported */ +if (spec_ctrl_bhi_dis ())return ;if (bhi_mitigation ==BHI_MITIGATION_VMEXIT_ONLY ) {
arch/x86/net/bpf_jit_comp.c +3 -2
@@ -1475,8 +1475,7 @@ static int emit_spectre_bhb_barrier(u8 */* Insert IBHF instruction */ if ((cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_LOOP ) &&cpu_feature_enabled (X86_FEATURE_HYPERVISOR )) || - (cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_HW ) && -IS_ENABLED (CONFIG_X86_64 ))) { +cpu_feature_enabled (X86_FEATURE_CLEAR_BHB_HW )) {/* * Add an Indirect Branch History Fence (IBHF). IBHF acts as a * fence preventing branch history from before the fence from
@@ -1486,6 +1485,8 @@ static int emit_spectre_bhb_barrier(u8 ** hardware that doesn't need or support it. The REP and REX.W * prefixes are required by the microcode, and they also ensure * that the NOP is unlikely to be used in existing code. +* +* IBHF is not a valid instruction in 32-bit mode. */ EMIT5 (0xF3 ,0x48 ,0x0F ,0x1E ,0xF8 );/* ibhf */ }
Greg Kroah-Hartman
maintainerPATCH 187/197 Documentation: x86/bugs/its: Add ITS documentation
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 1ac116ce6468670eeda39345a5585df308243dca upstream.
Add the admin-guide for Indirect Target Selection (ITS).
--- Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/indirect-target-selection.rst | 168 ++++++++++ 2 files changed, 169 insertions(+) create mode 100644 Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
Documentation/admin-guide/hw-vuln/index.rst +1 -0
@@ -22,3 +22,4 @@ are configurable at compile, boot or run srso gather_data_sampling reg-file-data-sampling + indirect-target-selection
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst new file +168 -0
168 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 188/197 x86/its: Enumerate Indirect Target Selection (ITS) bug
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 159013a7ca18c271ff64192deb62a689b622d860 upstream.
ITS bug in some pre-Alderlake Intel CPUs may allow indirect branches in the first half of a cache line get predicted to a target of a branch located in the second half of the cache line.
Set X86_BUG_ITS on affected CPUs. Mitigation to follow in later commits.
--- arch/x86/include/asm/cpufeatures.h | 1 arch/x86/include/asm/msr-index.h | 8 +++++ arch/x86/kernel/cpu/common.c | 58 +++++++++++++++++++++++++++++-------- arch/x86/kvm/x86.c | 4 +- 4 files changed, 58 insertions(+), 13 deletions(-)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -534,4 +534,5 @@#define X86_BUG_RFDS X86_BUG(1*32 + 2)/* "rfds" CPU is vulnerable to Register File Data Sampling */ #define X86_BUG_BHI X86_BUG(1*32 + 3)/* "bhi" CPU is affected by Branch History Injection */ #define X86_BUG_IBPB_NO_RET X86_BUG(1*32 + 4)/* "ibpb_no_ret" IBPB omits return target predictions */ +#define X86_BUG_ITS X86_BUG(1*32 + 5)/* "its" CPU is affected by Indirect Target Selection */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/include/asm/msr-index.h +8 -0
@@ -209,6 +209,14 @@* VERW clears CPU Register * File. */ +#define ARCH_CAP_ITS_NO BIT_ULL(62)/* +* Not susceptible to +* Indirect Target Selection. +* This bit is not set by +* HW, but is synthesized by +* VMMs for guests to know +* their affected status. +*/ #define MSR_IA32_FLUSH_CMD 0x0000010b#define L1D_FLUSH BIT(0)/*
arch/x86/kernel/cpu/common.c +46 -12
86 lines not on this page · raw message
arch/x86/kvm/x86.c +3 -1
@@ -1589,7 +1589,7 @@ EXPORT_SYMBOL_GPL(kvm_emulate_rdpmc); ARCH_CAP_PSCHANGE_MC_NO | ARCH_CAP_TSX_CTRL_MSR | ARCH_CAP_TAA_NO | \ ARCH_CAP_SBDR_SSDP_NO | ARCH_CAP_FBSDP_NO | ARCH_CAP_PSDP_NO | \ ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO | ARCH_CAP_GDS_NO | \ - ARCH_CAP_RFDS_NO | ARCH_CAP_RFDS_CLEAR | ARCH_CAP_BHI_NO) + ARCH_CAP_RFDS_NO | ARCH_CAP_RFDS_CLEAR | ARCH_CAP_BHI_NO | ARCH_CAP_ITS_NO)static u64 kvm_get_arch_capabilities (void ) {
@@ -1623,6 +1623,8 @@ static u64 kvm_get_arch_capabilities(voi data |=ARCH_CAP_MDS_NO ;if (!boot_cpu_has_bug (X86_BUG_RFDS )) data |=ARCH_CAP_RFDS_NO ; +if (!boot_cpu_has_bug (X86_BUG_ITS )) + data |=ARCH_CAP_ITS_NO ;if (!boot_cpu_has (X86_FEATURE_RTM )) {/*
Greg Kroah-Hartman
maintainerPATCH 189/197 x86/its: Add support for ITS-safe indirect thunk
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 8754e67ad4ac692c67ff1f99c0d07156f04ae40c upstream.
Due to ITS, indirect branches in the lower half of a cacheline may be vulnerable to branch target injection attack.
Introduce ITS-safe thunks to patch indirect branches in the lower half of cacheline with the thunk. Also thunk any eBPF generated indirect branches in emit_indirect_jump().
Below category of indirect branches are not mitigated:
- Indirect branches in the .init section are not mitigated because they are discarded after boot.
- Indirect branches that are explicitly marked retpoline-safe.
Note that retpoline also mitigates the indirect branches against ITS. This is because the retpoline sequence fills an RSB entry before RET, and it does not suffer from RSB-underflow part of the ITS.
--- arch/x86/Kconfig | 11 ++++++++ arch/x86/include/asm/cpufeatures.h | 1 arch/x86/include/asm/nospec-branch.h | 4 +++ arch/x86/kernel/alternative.c | 45 ++++++++++++++++++++++++++++++++--- arch/x86/kernel/vmlinux.lds.S | 6 ++++ arch/x86/lib/retpoline.S | 28 +++++++++++++++++++++ arch/x86/net/bpf_jit_comp.c | 5 +++ 7 files changed, 96 insertions(+), 4 deletions(-)
arch/x86/Kconfig +11 -0
@@ -2764,6 +2764,17 @@ config MITIGATION_SSB of speculative execution in a similar way to the Meltdown and Spectre security vulnerabilities. +config MITIGATION_ITS + bool "Enable Indirect Target Selection mitigation" + depends on CPU_SUP_INTEL && X86_64 + depends on MITIGATION_RETPOLINE && MITIGATION_RETHUNK + default y + help + Enable Indirect Target Selection (ITS) mitigation. ITS is a bug in + BPU on some Intel CPUs that may allow Spectre V2 style attacks. If + disabled, mitigation cannot be enabled via cmdline. + See <file:Documentation/admin-guide/hw-vuln/indirect-target-selection.rst> + endif config ARCH_HAS_ADD_PAGES
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -483,6 +483,7 @@#define X86_FEATURE_AMD_FAST_CPPC (21*32 + 5)/* Fast CPPC */ #define X86_FEATURE_AMD_HETEROGENEOUS_CORES (21*32 + 6)/* Heterogeneous Core Topology */ #define X86_FEATURE_AMD_WORKLOAD_CLASS (21*32 + 7)/* Workload Classification */ +#define X86_FEATURE_INDIRECT_THUNK_ITS (21*32 + 8)/* Use thunk for indirect branches in lower half of cacheline */ /* * BUG word(s)
arch/x86/include/asm/nospec-branch.h +4 -0
@@ -337,10 +337,14 @@#else /* __ASSEMBLY__ */ +#define ITS_THUNK_SIZE 64 +typedef u8 retpoline_thunk_t [RETPOLINE_THUNK_SIZE ]; +typedef u8 its_thunk_t [ITS_THUNK_SIZE ];extern retpoline_thunk_t __x86_indirect_thunk_array[];extern retpoline_thunk_t __x86_indirect_call_thunk_array[];extern retpoline_thunk_t __x86_indirect_jump_thunk_array[]; +extern its_thunk_t __x86_indirect_its_thunk_array[];#ifdef CONFIG_MITIGATION_RETHUNK extern void __x86_return_thunk (void );
arch/x86/kernel/alternative.c +42 -3
75 lines not on this page · raw message
arch/x86/kernel/vmlinux.lds.S +6 -0
@@ -528,6 +528,12 @@ INIT_PER_CPU(irq_stack_backing_store); "SRSO function pair won't alias"); #endif +#if defined(CONFIG_MITIGATION_ITS) && !defined(CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B) +. = ASSERT(__x86_indirect_its_thunk_rax & 0x20, "__x86_indirect_thunk_rax not in second half of cacheline"); +. = ASSERT(((__x86_indirect_its_thunk_rcx - __x86_indirect_its_thunk_rax) % 64) == 0, "Indirect thunks are not cacheline apart"); +. = ASSERT(__x86_indirect_its_thunk_array == __x86_indirect_its_thunk_rax, "Gap in ITS thunk array"); +#endif + #endif /* CONFIG_X86_64 */ /*
arch/x86/lib/retpoline.S +28 -0
@@ -366,6 +366,34 @@ SYM_FUNC_END(call_depth_return_thunk) #endif /* CONFIG_MITIGATION_CALL_DEPTH_TRACKING */ +#ifdef CONFIG_MITIGATION_ITS + +.macro ITS_THUNK reg + +SYM_INNER_LABEL(__x86_indirect_its_thunk_\reg, SYM_L_GLOBAL) + UNWIND_HINT_UNDEFINED + ANNOTATE_NOENDBR + ANNOTATE_RETPOLINE_SAFE + jmp *%\reg + int3 + .align 32, 0xcc /* fill to the end of the line */ + .skip 32, 0xcc /* skip to the next upper half */ +.endm + +/* ITS mitigation requires thunks be aligned to upper half of cacheline */ +.align 64, 0xcc +.skip 32, 0xcc +SYM_CODE_START(__x86_indirect_its_thunk_array) + +#define GEN(reg) ITS_THUNK reg +#include <asm/GEN-for-each-reg.h> +#undef GEN + + .align 64, 0xcc +SYM_CODE_END(__x86_indirect_its_thunk_array) + +#endif + /* * This function name is magical and is used by -mfunction-return=thunk-extern * for the compiler to generate JMPs to it.
arch/x86/net/bpf_jit_comp.c +4 -1
@@ -655,7 +655,10 @@ static void emit_indirect_jump(u8 **ppro {u8 *prog = *pprog; -if (cpu_feature_enabled (X86_FEATURE_RETPOLINE_LFENCE )) { +if (cpu_feature_enabled (X86_FEATURE_INDIRECT_THUNK_ITS )) { +OPTIMIZER_HIDE_VAR (reg); +emit_jump (&prog, &__x86_indirect_its_thunk_array[reg], ip); + }else if (cpu_feature_enabled (X86_FEATURE_RETPOLINE_LFENCE )) {EMIT_LFENCE ();EMIT2 (0xFF ,0xE0 + reg); }else if (cpu_feature_enabled (X86_FEATURE_RETPOLINE )) {
Greg Kroah-Hartman
maintainerPATCH 190/197 x86/its: Add support for ITS-safe return thunk
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit a75bf27fe41abe658c53276a0c486c4bf9adecfc upstream.
RETs in the lower half of cacheline may be affected by ITS bug, specifically when the RSB-underflows. Use ITS-safe return thunk for such RETs.
RETs that are not patched:
- RET in retpoline sequence does not need to be patched, because the sequence itself fills an RSB before RET.
- RET in Call Depth Tracking (CDT) thunks __x86_indirect_{call|jump}_thunk and call_depth_return_thunk are not patched because CDT by design prevents RSB-underflow.
- RETs in .init section are not reachable after init.
- RETs that are explicitly marked safe with ANNOTATE_UNRET_SAFE.
--- arch/x86/include/asm/alternative.h | 14 ++++++++++++++ arch/x86/include/asm/nospec-branch.h | 6 ++++++ arch/x86/kernel/alternative.c | 19 +++++++++++++++++-- arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/static_call.c | 4 ++-- arch/x86/kernel/vmlinux.lds.S | 4 ++++ arch/x86/lib/retpoline.S | 13 ++++++++++++- arch/x86/net/bpf_jit_comp.c | 2 +- 8 files changed, 57 insertions(+), 7 deletions(-)
arch/x86/include/asm/alternative.h +14 -0
@@ -125,6 +125,20 @@ static __always_inline int x86_call_dept }#endif +#if defined(CONFIG_MITIGATION_RETHUNK ) && defined(CONFIG_OBJTOOL ) +extern bool cpu_wants_rethunk (void ); +extern bool cpu_wants_rethunk_at (void *addr); +#else +static __always_inline bool cpu_wants_rethunk(void) +{ +return false; +} +static __always_inline bool cpu_wants_rethunk_at(void *addr) +{ +return false; +} +#endif +#ifdef CONFIG_SMP extern void alternatives_smp_module_add(struct module *mod, char *name, void *locks, void *locks_end,
arch/x86/include/asm/nospec-branch.h +6 -0
@@ -368,6 +368,12 @@ static inline void srso_return_thunk(voistatic inline void srso_alias_return_thunk (void ) {}#endif +#ifdef CONFIG_MITIGATION_ITS +extern void its_return_thunk (void ); +#else +static inline void its_return_thunk (void ) {} +#endif +extern void retbleed_return_thunk (void );extern void srso_return_thunk (void );extern void srso_alias_return_thunk (void );
arch/x86/kernel/alternative.c +17 -2
@@ -820,6 +820,21 @@ void __init_or_module noinline apply_ret#ifdef CONFIG_MITIGATION_RETHUNK +bool cpu_wants_rethunk (void ) +{ +return cpu_feature_enabled (X86_FEATURE_RETHUNK ); +} + +bool cpu_wants_rethunk_at (void *addr) +{ +if (!cpu_feature_enabled (X86_FEATURE_RETHUNK )) +return false; +if (x86_return_thunk != its_return_thunk) +return true; + +return !((unsigned long )addr &0x20 ); +} +/* * Rewrite the compiler generated return thunk tail-calls. *
@@ -836,7 +851,7 @@ static int patch_return(void *addr, struint i =0 ;/* Patch the custom return thunks... */ -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) { +if (cpu_wants_rethunk_at (addr)) { i =JMP32_INSN_SIZE ;__text_gen_insn (bytes,JMP32_INSN_OPCODE , addr, x86_return_thunk, i); }else {
@@ -854,7 +869,7 @@ void __init_or_module noinline apply_ret {s32 *s; -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) +if (cpu_wants_rethunk ())static_call_force_reinit ();for (s = start; s < end; s++) {
arch/x86/kernel/ftrace.c +1 -1
@@ -357,7 +357,7 @@ create_trampoline(struct ftrace_ops *ops goto fail; ip = trampoline + size; -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) +if (cpu_wants_rethunk_at (ip))__text_gen_insn (ip,JMP32_INSN_OPCODE , ip, x86_return_thunk,JMP32_INSN_SIZE );else text_poke_copy (ip, retq,sizeof (retq));
arch/x86/kernel/static_call.c +2 -2
@@ -81,7 +81,7 @@ static void __ref __static_call_transforbreak ;case RET : -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) +if (cpu_wants_rethunk_at (insn)) code =text_gen_insn (JMP32_INSN_OPCODE , insn, x86_return_thunk);else code = &retinsn;
@@ -90,7 +90,7 @@ static void __ref __static_call_transforcase JCC :if (!func) { func = __static_call_return; -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) +if (cpu_wants_rethunk ()) func = x86_return_thunk; }
arch/x86/kernel/vmlinux.lds.S +4 -0
@@ -534,6 +534,10 @@ INIT_PER_CPU(irq_stack_backing_store); . = ASSERT(__x86_indirect_its_thunk_array == __x86_indirect_its_thunk_rax, "Gap in ITS thunk array"); #endif +#if defined(CONFIG_MITIGATION_ITS) && !defined(CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B) +. = ASSERT(its_return_thunk & 0x20, "its_return_thunk not in second half of cacheline"); +#endif + #endif /* CONFIG_X86_64 */ /*
arch/x86/lib/retpoline.S +12 -1
@@ -392,7 +392,18 @@ SYM_CODE_START(__x86_indirect_its_thunk_ .align 64, 0xcc SYM_CODE_END(__x86_indirect_its_thunk_array) -#endif +.align 64, 0xcc +.skip 32, 0xcc +SYM_CODE_START(its_return_thunk) + UNWIND_HINT_FUNC + ANNOTATE_NOENDBR + ANNOTATE_UNRET_SAFE + ret + int3 +SYM_CODE_END(its_return_thunk) +EXPORT_SYMBOL(its_return_thunk) + +#endif /* CONFIG_MITIGATION_ITS */ /* * This function name is magical and is used by -mfunction-return=thunk-extern
arch/x86/net/bpf_jit_comp.c +1 -1
@@ -680,7 +680,7 @@ static void emit_return(u8 **pprog, u8 * {u8 *prog = *pprog; -if (cpu_feature_enabled (X86_FEATURE_RETHUNK )) { +if (cpu_wants_rethunk ()) {emit_jump (&prog, x86_return_thunk, ip); }else {EMIT1 (0xC3 );/* ret */
Greg Kroah-Hartman
maintainerPATCH 191/197 x86/its: Enable Indirect Target Selection mitigation
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit f4818881c47fd91fcb6d62373c57c7844e3de1c0 upstream.
Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with eIBRS. It affects prediction of indirect branch and RETs in the lower half of cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the upper half of the cacheline.
Scope of impact
===============
Guest/host isolation
--------------------
When eIBRS is used for guest/host isolation, the indirect branches in the VMM may still be predicted with targets corresponding to branches in the guest.
Intra-mode
----------
cBPF or other native gadgets can be used for intra-mode training and disclosure using ITS.
User/kernel isolation
---------------------
When eIBRS is enabled user/kernel isolation is not impacted.
Indirect Branch Prediction Barrier (IBPB)
-----------------------------------------
After an IBPB, indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This is mitigated by a microcode update.
Add cmdline parameter indirect_target_selection=off|on|force to control the mitigation to relocate the affected branches to an ITS-safe thunk i.e. located in the upper half of cacheline. Also add the sysfs reporting.
When retpoline mitigation is deployed, ITS safe-thunks are not needed, because retpoline sequence is already ITS-safe. Similarly, when call depth tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return thunk is not used, as CDT prevents RSB-underflow.
To not overcomplicate things, ITS mitigation is not supported with spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy lfence;jmp mitigation on ITS affected parts anyways.
--- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/kernel-parameters.txt | 13 + arch/x86/kernel/cpu/bugs.c | 140 ++++++++++++++++++++- drivers/base/cpu.c | 3 include/linux/cpu.h | 2 5 files changed, 155 insertions(+), 4 deletions(-)
Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0
@@ -511,6 +511,7 @@ Description: information about CPUs hete What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/gather_data_sampling + /sys/devices/system/cpu/vulnerabilities/indirect_target_selection /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds
Documentation/admin-guide/kernel-parameters.txt +13 -0
@@ -2178,6 +2178,18 @@ different crypto accelerators. This option can be used to achieve best performance for particular HW. + indirect_target_selection= [X86,Intel] Mitigation control for Indirect + Target Selection(ITS) bug in Intel CPUs. Updated + microcode is also required for a fix in IBPB. + + on: Enable mitigation (default). + off: Disable mitigation. + force: Force the ITS bug and deploy default + mitigation. + + For details see: + Documentation/admin-guide/hw-vuln/indirect-target-selection.rst + init= [KNL] Format: <full_path> Run specified binary instead of /sbin/init as init
@@ -3666,6 +3678,7 @@ expose users to several CPU vulnerabilities. Equivalent to: if nokaslr then kpti=0 [ARM64] gather_data_sampling=off [X86] + indirect_target_selection=off [X86] kvm.nx_huge_pages=off [X86] l1tf=off [X86] mds=off [X86]
arch/x86/kernel/cpu/bugs.c +136 -4
202 lines not on this page · raw message
drivers/base/cpu.c +3 -0
@@ -600,6 +600,7 @@ CPU_SHOW_VULN_FALLBACK(spec_rstack_overfCPU_SHOW_VULN_FALLBACK (gds);CPU_SHOW_VULN_FALLBACK (reg_file_data_sampling);CPU_SHOW_VULN_FALLBACK (ghostwrite); +CPU_SHOW_VULN_FALLBACK (indirect_target_selection); static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
@@ -616,6 +617,7 @@ static DEVICE_ATTR(spec_rstack_overflow, static DEVICE_ATTR(gather_data_sampling, 0444, cpu_show_gds, NULL); static DEVICE_ATTR(reg_file_data_sampling, 0444, cpu_show_reg_file_data_sampling, NULL); static DEVICE_ATTR(ghostwrite, 0444, cpu_show_ghostwrite, NULL); +static DEVICE_ATTR(indirect_target_selection, 0444, cpu_show_indirect_target_selection, NULL);static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,
@@ -633,6 +635,7 @@ static struct attribute *cpu_root_vulner &dev_attr_gather_data_sampling.attr, &dev_attr_reg_file_data_sampling.attr, &dev_attr_ghostwrite.attr, + &dev_attr_indirect_target_selection.attr, NULL };
include/linux/cpu.h +2 -0
@@ -78,6 +78,8 @@ extern ssize_t cpu_show_gds(struct devicextern ssize_t cpu_show_reg_file_data_sampling (struct device *dev,struct device_attribute *attr,char *buf);extern ssize_t cpu_show_ghostwrite (struct device *dev,struct device_attribute *attr,char *buf); +extern ssize_t cpu_show_indirect_target_selection (struct device *dev, +struct device_attribute *attr,char *buf); extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata,
Greg Kroah-Hartman
maintainerPATCH 192/197 x86/its: Add "vmexit" option to skip mitigation on some CPUs
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 2665281a07e19550944e8354a2024635a7b2714a upstream.
Ice Lake generation CPUs are not affected by guest/host isolation part of ITS. If a user is only concerned about KVM guests, they can now choose a new cmdline option "vmexit" that will not deploy the ITS mitigation when CPU is not affected by guest/host isolation. This saves the performance overhead of ITS mitigation on Ice Lake gen CPUs.
When "vmexit" option selected, if the CPU is affected by ITS guest/host isolation, the default ITS mitigation is deployed.
--- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 11 +++++++++++ arch/x86/kernel/cpu/common.c | 19 ++++++++++++------- 4 files changed, 26 insertions(+), 7 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +2 -0
@@ -2186,6 +2186,8 @@ off: Disable mitigation. force: Force the ITS bug and deploy default mitigation. + vmexit: Only deploy mitigation if CPU is affected by + guest/host isolation part of ITS. For details see: Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -536,4 +536,5 @@#define X86_BUG_BHI X86_BUG(1*32 + 3)/* "bhi" CPU is affected by Branch History Injection */ #define X86_BUG_IBPB_NO_RET X86_BUG(1*32 + 4)/* "ibpb_no_ret" IBPB omits return target predictions */ #define X86_BUG_ITS X86_BUG(1*32 + 5)/* "its" CPU is affected by Indirect Target Selection */ +#define X86_BUG_ITS_NATIVE_ONLY X86_BUG(1*32 + 6)/* "its_native_only" CPU is affected by ITS, VMX is not affected */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/kernel/cpu/bugs.c +11 -0
@@ -1189,16 +1189,19 @@ do_cmd_auto:enum its_mitigation_cmd {ITS_CMD_OFF ,ITS_CMD_ON , +ITS_CMD_VMEXIT , };enum its_mitigation {ITS_MITIGATION_OFF , +ITS_MITIGATION_VMEXIT_ONLY ,ITS_MITIGATION_ALIGNED_THUNKS ,ITS_MITIGATION_RETPOLINE_STUFF , };static const char *const its_strings[] = { [ITS_MITIGATION_OFF ] ="Vulnerable" , + [ITS_MITIGATION_VMEXIT_ONLY ] ="Mitigation: Vulnerable, KVM: Not affected" , [ITS_MITIGATION_ALIGNED_THUNKS ] ="Mitigation: Aligned branch/return thunks" , [ITS_MITIGATION_RETPOLINE_STUFF ] ="Mitigation: Retpolines, Stuffing RSB" , };
@@ -1225,6 +1228,8 @@ static int __init its_parse_cmdline(char }else if (!strcmp (str,"force" )) { its_cmd =ITS_CMD_ON ;setup_force_cpu_bug (X86_BUG_ITS ); + }else if (!strcmp (str,"vmexit" )) { + its_cmd =ITS_CMD_VMEXIT ; }else {pr_err ("Ignoring unknown indirect_target_selection option (%s)." , str); }
@@ -1280,6 +1285,12 @@ static void __init its_select_mitigationcase ITS_CMD_OFF : its_mitigation =ITS_MITIGATION_OFF ;break ; +case ITS_CMD_VMEXIT : +if (boot_cpu_has_bug (X86_BUG_ITS_NATIVE_ONLY )) { + its_mitigation =ITS_MITIGATION_VMEXIT_ONLY ; + goto out; + } + fallthrough;case ITS_CMD_ON : its_mitigation =ITS_MITIGATION_ALIGNED_THUNKS ;if (!boot_cpu_has (X86_FEATURE_RETPOLINE ))
arch/x86/kernel/cpu/common.c +12 -7
@@ -1228,6 +1228,8 @@ static const __initconst struct x86_cpu_#define RFDS BIT(7)/* CPU is affected by Indirect Target Selection */ #define ITS BIT(8) +/* CPU is affected by Indirect Target Selection, but guest-host isolation is not affected */ +#define ITS_NATIVE_ONLY BIT(9)static const struct x86_cpu_id cpu_vuln_blacklist[]__initconst = {VULNBL_INTEL_STEPS (INTEL_IVYBRIDGE ,X86_STEP_MAX ,SRBDS ),
@@ -1248,16 +1250,16 @@ static const struct x86_cpu_id cpu_vuln_VULNBL_INTEL_STEPS (INTEL_KABYLAKE ,0xc ,MMIO |RETBLEED |GDS |SRBDS ),VULNBL_INTEL_STEPS (INTEL_KABYLAKE ,X86_STEP_MAX ,MMIO |RETBLEED |GDS |SRBDS |ITS ),VULNBL_INTEL_STEPS (INTEL_CANNONLAKE_L ,X86_STEP_MAX ,RETBLEED ), -VULNBL_INTEL_STEPS (INTEL_ICELAKE_L ,X86_STEP_MAX ,MMIO |MMIO_SBDS |RETBLEED |GDS |ITS ), -VULNBL_INTEL_STEPS (INTEL_ICELAKE_D ,X86_STEP_MAX ,MMIO |GDS |ITS ), -VULNBL_INTEL_STEPS (INTEL_ICELAKE_X ,X86_STEP_MAX ,MMIO |GDS |ITS ), +VULNBL_INTEL_STEPS (INTEL_ICELAKE_L ,X86_STEP_MAX ,MMIO |MMIO_SBDS |RETBLEED |GDS |ITS |ITS_NATIVE_ONLY ), +VULNBL_INTEL_STEPS (INTEL_ICELAKE_D ,X86_STEP_MAX ,MMIO |GDS |ITS |ITS_NATIVE_ONLY ), +VULNBL_INTEL_STEPS (INTEL_ICELAKE_X ,X86_STEP_MAX ,MMIO |GDS |ITS |ITS_NATIVE_ONLY ),VULNBL_INTEL_STEPS (INTEL_COMETLAKE ,X86_STEP_MAX ,MMIO |MMIO_SBDS |RETBLEED |GDS |ITS ),VULNBL_INTEL_STEPS (INTEL_COMETLAKE_L ,0x0 ,MMIO |RETBLEED |ITS ),VULNBL_INTEL_STEPS (INTEL_COMETLAKE_L ,X86_STEP_MAX ,MMIO |MMIO_SBDS |RETBLEED |GDS |ITS ), -VULNBL_INTEL_STEPS (INTEL_TIGERLAKE_L ,X86_STEP_MAX ,GDS |ITS ), -VULNBL_INTEL_STEPS (INTEL_TIGERLAKE ,X86_STEP_MAX ,GDS |ITS ), +VULNBL_INTEL_STEPS (INTEL_TIGERLAKE_L ,X86_STEP_MAX ,GDS |ITS |ITS_NATIVE_ONLY ), +VULNBL_INTEL_STEPS (INTEL_TIGERLAKE ,X86_STEP_MAX ,GDS |ITS |ITS_NATIVE_ONLY ),VULNBL_INTEL_STEPS (INTEL_LAKEFIELD ,X86_STEP_MAX ,MMIO |MMIO_SBDS |RETBLEED ), -VULNBL_INTEL_STEPS (INTEL_ROCKETLAKE ,X86_STEP_MAX ,MMIO |RETBLEED |GDS |ITS ), +VULNBL_INTEL_STEPS (INTEL_ROCKETLAKE ,X86_STEP_MAX ,MMIO |RETBLEED |GDS |ITS |ITS_NATIVE_ONLY ),VULNBL_INTEL_STEPS (INTEL_ALDERLAKE ,X86_STEP_MAX ,RFDS ),VULNBL_INTEL_STEPS (INTEL_ALDERLAKE_L ,X86_STEP_MAX ,RFDS ), VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, RFDS),
@@ -1480,8 +1482,11 @@ static void __init cpu_set_bug_bits(struif (cpu_has (c,X86_FEATURE_AMD_IBPB ) && !cpu_has (c,X86_FEATURE_AMD_IBPB_RET ))setup_force_cpu_bug (X86_BUG_IBPB_NO_RET ); -if (vulnerable_to_its (x86_arch_cap_msr)) +if (vulnerable_to_its (x86_arch_cap_msr)) {setup_force_cpu_bug (X86_BUG_ITS ); +if (cpu_matches (cpu_vuln_blacklist,ITS_NATIVE_ONLY )) +setup_force_cpu_bug (X86_BUG_ITS_NATIVE_ONLY ); + }if (cpu_matches (cpu_vuln_whitelist,NO_MELTDOWN ))return ;
Greg Kroah-Hartman
maintainerPATCH 193/197 x86/its: Add support for RSB stuffing mitigation
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit facd226f7e0c8ca936ac114aba43cb3e8b94e41e upstream.
When retpoline mitigation is enabled for spectre-v2, enabling call-depth-tracking and RSB stuffing also mitigates ITS. Add cmdline option indirect_target_selection=stuff to allow enabling RSB stuffing mitigation.
When retpoline mitigation is not enabled, =stuff option is ignored, and default mitigation for ITS is deployed.
--- Documentation/admin-guide/kernel-parameters.txt | 3 +++ arch/x86/kernel/cpu/bugs.c | 19 +++++++++++++++++++ 2 files changed, 22 insertions(+)
Documentation/admin-guide/kernel-parameters.txt +3 -0
@@ -2188,6 +2188,9 @@ mitigation. vmexit: Only deploy mitigation if CPU is affected by guest/host isolation part of ITS. + stuff: Deploy RSB-fill mitigation when retpoline is + also deployed. Otherwise, deploy the default + mitigation. For details see: Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
arch/x86/kernel/cpu/bugs.c +19 -0
@@ -1190,6 +1190,7 @@ enum its_mitigation_cmd {ITS_CMD_OFF ,ITS_CMD_ON ,ITS_CMD_VMEXIT , + ITS_CMD_RSB_STUFF, }; enum its_mitigation {
@@ -1230,6 +1231,8 @@ static int __init its_parse_cmdline(charsetup_force_cpu_bug (X86_BUG_ITS ); }else if (!strcmp (str,"vmexit" )) { its_cmd =ITS_CMD_VMEXIT ; + }else if (!strcmp (str,"stuff" )) { + its_cmd =ITS_CMD_RSB_STUFF ; }else {pr_err ("Ignoring unknown indirect_target_selection option (%s)." , str); }
@@ -1281,6 +1284,12 @@ static void __init its_select_mitigation goto out; } +if (cmd ==ITS_CMD_RSB_STUFF && + (!boot_cpu_has (X86_FEATURE_RETPOLINE ) || !IS_ENABLED (CONFIG_MITIGATION_CALL_DEPTH_TRACKING ))) { +pr_err ("RSB stuff mitigation not supported, using default\n" ); + cmd =ITS_CMD_ON ; + } +switch (cmd) {case ITS_CMD_OFF : its_mitigation =ITS_MITIGATION_OFF ;
@@ -1298,6 +1307,16 @@ static void __init its_select_mitigationsetup_force_cpu_cap (X86_FEATURE_RETHUNK );set_return_thunk (its_return_thunk);break ; +case ITS_CMD_RSB_STUFF : + its_mitigation =ITS_MITIGATION_RETPOLINE_STUFF ; +setup_force_cpu_cap (X86_FEATURE_RETHUNK ); +setup_force_cpu_cap (X86_FEATURE_CALL_DEPTH ); +set_return_thunk (call_depth_return_thunk); +if (retbleed_mitigation ==RETBLEED_MITIGATION_NONE ) { + retbleed_mitigation =RETBLEED_MITIGATION_STUFF ; +pr_info ("Retbleed mitigation updated to stuffing\n" ); + } +break ; } out:pr_info ("%s\n" , its_strings[its_mitigation]);
Greg Kroah-Hartman
maintainerPATCH 194/197 x86/its: Align RETs in BHB clear sequence to avoid thunking
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit f0cd7091cc5a032c8870b4285305d9172569d126 upstream.
The software mitigation for BHI is to execute BHB clear sequence at syscall entry, and possibly after a cBPF program. ITS mitigation thunks RETs in the lower half of the cacheline. This causes the RETs in the BHB clear sequence to be thunked as well, adding unnecessary branches to the BHB clear sequence.
Since the sequence is in hot path, align the RET instructions in the sequence to avoid thunking.
This is how disassembly clear_bhb_loop() looks like after this change:
0x44 <+4>: mov $0x5,%ecx 0x49 <+9>: call 0xffffffff81001d9b <clear_bhb_loop+91> 0x4e <+14>: jmp 0xffffffff81001de5 <clear_bhb_loop+165> 0x53 <+19>: int3 ... 0x9b <+91>: call 0xffffffff81001dce <clear_bhb_loop+142> 0xa0 <+96>: ret 0xa1 <+97>: int3 ... 0xce <+142>: mov $0x5,%eax 0xd3 <+147>: jmp 0xffffffff81001dd6 <clear_bhb_loop+150> 0xd5 <+149>: nop 0xd6 <+150>: sub $0x1,%eax 0xd9 <+153>: jne 0xffffffff81001dd3 <clear_bhb_loop+147> 0xdb <+155>: sub $0x1,%ecx 0xde <+158>: jne 0xffffffff81001d9b <clear_bhb_loop+91> 0xe0 <+160>: ret 0xe1 <+161>: int3 0xe2 <+162>: int3 0xe3 <+163>: int3 0xe4 <+164>: int3 0xe5 <+165>: lfence 0xe8 <+168>: pop %rbp 0xe9 <+169>: ret
--- arch/x86/entry/entry_64.S | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
arch/x86/entry/entry_64.S +17 -3
@@ -1523,7 +1523,9 @@ SYM_CODE_END(rewind_stack_and_make_dead) * ORC to unwind properly. * * The alignment is for performance and not for safety, and may be safely - * refactored in the future if needed. + * refactored in the future if needed. The .skips are for safety, to ensure + * that all RETs are in the second half of a cacheline to mitigate Indirect + * Target Selection, rather than taking the slowpath via its_return_thunk. */ SYM_FUNC_START(clear_bhb_loop) push %rbp
@@ -1533,10 +1535,22 @@ SYM_FUNC_START(clear_bhb_loop) call 1f jmp 5f .align 64, 0xcc + /* + * Shift instructions so that the RET is in the upper half of the + * cacheline and don't take the slowpath to its_return_thunk. + */ + .skip 32 - (.Lret1 - 1f), 0xcc ANNOTATE_INTRA_FUNCTION_CALL 1: call 2f - RET +.Lret1: RET .align 64, 0xcc + /* + * As above shift instructions for RET at .Lret2 as well. + * + * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc + * but some Clang versions (e.g. 18) don't like this. + */ + .skip 32 - 18, 0xcc 2: movl $5, %eax 3: jmp 4f nop
@@ -1544,7 +1558,7 @@ SYM_FUNC_START(clear_bhb_loop) jnz 3b sub $1, %ecx jnz 1b - RET +.Lret2: RET 5: lfence pop %rbp RET
Greg Kroah-Hartman
maintainerPATCH 195/197 x86/ibt: Keep IBT disabled during alternative patching
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit ebebe30794d38c51f71fe4951ba6af4159d9837d upstream.
cfi_rewrite_callers() updates the fineIBT hash matching at the caller side, but except for paranoid-mode it relies on apply_retpoline() and friends for any ENDBR relocation. This could temporarily cause an indirect branch to land on a poisoned ENDBR.
For instance, with para-virtualization enabled, a simple wrmsrl() could have an indirect branch pointing to native_write_msr() who's ENDBR has been relocated due to fineIBT:
<wrmsrl>:
push %rbp
mov %rsp,%rbp
mov %esi,%eax
mov %rsi,%rdx
shr $0x20,%rdx
mov %edi,%edi
mov %rax,%rsi
call *0x21e65d0(%rip) # <pv_ops+0xb8>
^^^^^^^^^^^^^^^^^^^^^^^Such an indirect call during the alternative patching could #CP if the caller is not *yet* adjusted for the new target ENDBR. To prevent a false
#CP, keep CET-IBT disabled until all callers are patched.
Patching during the module load does not need to be guarded by IBT-disable because the module code is not executed until the patching is complete.
--- arch/x86/kernel/alternative.c | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/x86/kernel/alternative.c +8 -0
@@ -31,6 +31,7 @@#include <asm/paravirt.h> #include <asm/asm-prototypes.h> #include <asm/cfi.h> +#include <asm/ibt.h> int __read_mostly alternatives_patched;
@@ -1748,6 +1749,8 @@ static noinline void __init alt_reloc_sevoid __init alternative_instructions (void ) { +u64 ibt; +int3_selftest ();/*
@@ -1774,6 +1777,9 @@ void __init alternative_instructions(voi*/ paravirt_set_cap (); +/* Keep CET-IBT disabled until caller/callee are patched */ + ibt =ibt_save (/*disable*/ true); +__apply_fineibt (__retpoline_sites, __retpoline_sites_end, __cfi_sites, __cfi_sites_end,NULL );
@@ -1797,6 +1803,8 @@ void __init alternative_instructions(voi*/ apply_seal_endbr (__ibt_endbr_seal, __ibt_endbr_seal_end,NULL ); +ibt_restore (ibt); +#ifdef CONFIG_SMP /* Patch to UP if other cpus not imminent. */ if (!noreplace_smp && (num_present_cpus () ==1 || setup_max_cpus <=1 )) {
Greg Kroah-Hartman
maintainerPATCH 196/197 x86/its: Use dynamic thunks for indirect branches
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 872df34d7c51a79523820ea6a14860398c639b87 upstream.
ITS mitigation moves the unsafe indirect branches to a safe thunk. This could degrade the prediction accuracy as the source address of indirect branches becomes same for different execution paths.
To improve the predictions, and hence the performance, assign a separate thunk for each indirect callsite. This is also a defense-in-depth measure to avoid indirect branches aliasing with each other.
As an example, 5000 dynamic thunks would utilize around 16 bits of the address space, thereby gaining entropy. For a BTB that uses 32 bits for indexing, dynamic thunks could provide better prediction accuracy over fixed thunks.
Have ITS thunks be variable sized and use EXECMEM_MODULE_TEXT such that they are both more flexible (got to extend them later) and live in 2M TLBs, just like kernel code, avoiding undue TLB pressure.
[ pawan: CONFIG_EXECMEM_ROX is not supported on backport kernel, made
adjustments to set memory to RW and ROX ]
--- arch/x86/Kconfig | 1 arch/x86/include/asm/alternative.h | 10 ++ arch/x86/kernel/alternative.c | 129 ++++++++++++++++++++++++++++++++++++- arch/x86/kernel/module.c | 6 + include/linux/execmem.h | 3 include/linux/module.h | 5 + 6 files changed, 151 insertions(+), 3 deletions(-)
arch/x86/Kconfig +1 -0
@@ -2768,6 +2768,7 @@ config MITIGATION_ITS bool "Enable Indirect Target Selection mitigation" depends on CPU_SUP_INTEL && X86_64 depends on MITIGATION_RETPOLINE && MITIGATION_RETHUNK + select EXECMEM default y help Enable Indirect Target Selection (ITS) mitigation. ITS is a bug in
arch/x86/include/asm/alternative.h +10 -0
@@ -125,6 +125,16 @@ static __always_inline int x86_call_dept }#endif +#ifdef CONFIG_MITIGATION_ITS +extern void its_init_mod (struct module *mod); +extern void its_fini_mod (struct module *mod); +extern void its_free_mod (struct module *mod); +#else /* CONFIG_MITIGATION_ITS */ +static inline void its_init_mod (struct module *mod) { } +static inline void its_fini_mod (struct module *mod) { } +static inline void its_free_mod (struct module *mod) { } +#endif +#if defined(CONFIG_MITIGATION_RETHUNK ) && defined(CONFIG_OBJTOOL )extern bool cpu_wants_rethunk (void );extern bool cpu_wants_rethunk_at (void *addr);
arch/x86/kernel/alternative.c +126 -3
153 lines not on this page · raw message
arch/x86/kernel/module.c +6 -0
@@ -252,6 +252,8 @@ int module_finalize(const Elf_Ehdr *hdr, ibt_endbr = s; } +its_init_mod (me); +if (retpolines || cfi) {void *rseg =NULL , *cseg =NULL ;unsigned int rsize =0 , csize =0 ;
@@ -272,6 +274,9 @@ int module_finalize(const Elf_Ehdr *hdr,void *rseg = (void *)retpolines->sh_addr;apply_retpolines (rseg, rseg + retpolines->sh_size, me); } + +its_fini_mod (me); +if (returns) {void *rseg = (void *)returns->sh_addr;apply_returns (rseg, rseg + returns->sh_size, me);
@@ -335,4 +340,5 @@ int module_post_finalize(const Elf_Ehdrvoid module_arch_cleanup (struct module *mod) {alternatives_smp_module_del (mod); +its_free_mod (mod); }
include/linux/execmem.h +3 -0
@@ -4,6 +4,7 @@#include <linux/types.h> #include <linux/moduleloader.h> +#include <linux/cleanup.h> #if (defined(CONFIG_KASAN_GENERIC ) || defined(CONFIG_KASAN_SW_TAGS )) && \ !defined(CONFIG_KASAN_VMALLOC )
@@ -139,6 +140,8 @@ void *execmem_alloc(enum execmem_type ty*/ void execmem_free (void *ptr); +DEFINE_FREE(execmem, void *, if (_T) execmem_free(_T)); +#ifdef CONFIG_MMU /** * execmem_vmap - create virtual mapping for EXECMEM_MODULE_DATA memory
include/linux/module.h +5 -0
@@ -587,6 +587,11 @@ struct module {atomic_t refcnt;#endif +#ifdef CONFIG_MITIGATION_ITS +int its_num_pages; +void **its_page_array; +#endif +#ifdef CONFIG_CONSTRUCTORS /* Constructor functions. */ ctor_fn_t *ctors;
Greg Kroah-Hartman
maintainerPATCH 197/197 selftest/x86/bugs: Add selftests for ITS
In reply to Greg Kroah-Hartman6.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawan Gupta <[email protected]>
commit 7a9b709e7cc5ce1ffb84ce07bf6d157e1de758df upstream.
Below are the tests added for Indirect Target Selection (ITS):
- its_sysfs.py - Check if sysfs reflects the correct mitigation status for the mitigation selected via the kernel cmdline.
- its_permutations.py - tests mitigation selection with cmdline permutations with other bugs like spectre_v2 and retbleed.
- its_indirect_alignment.py - verifies that for addresses in .retpoline_sites section that belong to lower half of cacheline are patched to ITS-safe thunk. Typical output looks like below:
Site 49: function symbol: __x64_sys_restart_syscall+0x1f <0xffffffffbb1509af>
# vmlinux: 0xffffffff813509af: jmp 0xffffffff81f5a8e0 # kcore: 0xffffffffbb1509af: jmpq *%rax # ITS thunk NOT expected for site 49 # PASSED: Found *%rax # Site 50: function symbol: __resched_curr+0xb0 <0xffffffffbb181910> # vmlinux: 0xffffffff81381910: jmp 0xffffffff81f5a8e0 # kcore: 0xffffffffbb181910: jmp 0xffffffffc02000fc # ITS thunk expected for site 50 # PASSED: Found 0xffffffffc02000fc -> jmpq *%rax <scattered-thunk?>
- its_ret_alignment.py - verifies that for addresses in .return_sites section that belong to lower half of cacheline are patched to its_return_thunk. Typical output looks like below:
Site 97: function symbol: collect_event+0x48 <0xffffffffbb007f18>
# vmlinux: 0xffffffff81207f18: jmp 0xffffffff81f5b500 # kcore: 0xffffffffbb007f18: jmp 0xffffffffbbd5b560 # PASSED: Found jmp 0xffffffffbbd5b560 <its_return_thunk> # Site 98: function symbol: collect_event+0xa4 <0xffffffffbb007f74> # vmlinux: 0xffffffff81207f74: jmp 0xffffffff81f5b500 # kcore: 0xffffffffbb007f74: retq # PASSED: Found retq
Some of these tests have dependency on tools like virtme-ng[1] and drgn[2]. When the dependencies are not met, the test will be skipped.
[1] https://github.com/arighi/virtme-ng
[2] https://github.com/osandov/drgn
--- tools/testing/selftests/Makefile | 1 tools/testing/selftests/x86/bugs/Makefile | 3 tools/testing/selftests/x86/bugs/common.py | 164 +++++++++++++ tools/testing/selftests/x86/bugs/its_indirect_alignment.py | 150 +++++++++++ tools/testing/selftests/x86/bugs/its_permutations.py | 109 ++++++++ tools/testing/selftests/x86/bugs/its_ret_alignment.py | 139 +++++++++++ tools/testing/selftests/x86/bugs/its_sysfs.py | 65 +++++ 7 files changed, 631 insertions(+) create mode 100644 tools/testing/selftests/x86/bugs/Makefile create mode 100755 tools/testing/selftests/x86/bugs/common.py create mode 100755 tools/testing/selftests/x86/bugs/its_indirect_alignment.py create mode 100755 tools/testing/selftests/x86/bugs/its_permutations.py create mode 100755 tools/testing/selftests/x86/bugs/its_ret_alignment.py create mode 100755 tools/testing/selftests/x86/bugs/its_sysfs.py
tools/testing/selftests/Makefile +1 -0
@@ -118,6 +118,7 @@ TARGETS += user_events TARGETS += vDSO TARGETS += mm TARGETS += x86 +TARGETS += x86/bugs TARGETS += zram #Please keep the TARGETS list alphabetically sorted # Run "make quicktest=1 run_tests" or
tools/testing/selftests/x86/bugs/Makefile new file +3 -0
@@ -0,0 +1,3 @@ +TEST_PROGS := its_sysfs.py its_permutations.py its_indirect_alignment.py its_ret_alignment.py +TEST_FILES := common.py +include ../../lib.mk
tools/testing/selftests/x86/bugs/common.py new file +164 -0
164 lines not on this page · raw message
tools/testing/selftests/x86/bugs/its_indirect_alignment.py new file +150 -0
150 lines not on this page · raw message
tools/testing/selftests/x86/bugs/its_permutations.py new file +109 -0
109 lines not on this page · raw message
tools/testing/selftests/x86/bugs/its_ret_alignment.py new file +139 -0
139 lines not on this page · raw message
tools/testing/selftests/x86/bugs/its_sysfs.py new file +65 -0
65 lines not on this page · raw message
Hi!
Quoted 7 lines
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
We are getting errors here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/1813568284
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/10010530202
arch/x86/kernel/alternative.c: In function 'its_fini_mod':
1702arch/x86/kernel/alternative.c:174:32: error: invalid use of undefined type 'struct module' 1703
174 | for (int i = 0; i < mod->its_num_pages; i++) {
1704
| ^~
1705arch/x86/kernel/alternative.c:175:33: error: invalid use of undefined type 'struct module' 1706
175 | void *page = mod->its_page_array[i];
1707
| ^~
...
6.12 has same problem, likely 6.6 too.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.14:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.14.7-rc1-g4f7f8fb4f8e3
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,
tegra30-cardhu-a04Jon
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hello everyone,
I have noticed that the following commit produces a whole bunch of lines in my journal, which looks like an error for me:
Quoted 2 lines
Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcase
amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written
this does not seem to be serious, i.e. the system otherwise works as intended but it's still noteworthy. Is there a dependency commit missing maybe? From the code it looks like it was meant to be this way 🤔
You can find a full journal here, with the logspammed parts in highlight:
https://gist.github.com/christian-heusel/e8418bbdca097871489a31d79ed166d6#file-dmesg-log-L854-L981
Cheers,
Chris
Yeah getting that too
[ 21.463202] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.464700] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.466133] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.467631] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.469127] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.470631] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.472127] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.473624] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.475130] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.476631] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.478127] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.479624] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.481126] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.482623] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.484130] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.485630] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.487127] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.488630] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.490125] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.491633] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.493120] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.494642] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.496128] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.497632] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.499128] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.500633] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.502130] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.503631] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.505126] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.506629] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.508127] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 21.509647] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK: 0x01. [ 22.259286] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.259935] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.260583] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.261234] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.261883] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.262533] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.263185] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.263835] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.264481] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.265128] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.265771] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.266323] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.266970] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.267616] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.268270] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.268918] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.269567] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.270213] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.270857] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.271506] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.272154] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.272802] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.273450] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.274097] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.274745] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.275393] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.276039] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.276682] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.277274] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.277916] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.278563] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 22.279210] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.335457] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.336103] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.336745] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.337387] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.338029] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.338676] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.339271] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.339922] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.340570] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.341216] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.341864] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.342512] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.343159] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.343806] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.344456] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.345279] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.345929] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.346579] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.347232] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.347878] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.348526] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.349173] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.349816] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.350458] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.351100] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.351743] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.352390] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.353039] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.353685] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.354273] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.354920] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4 [ 27.355567] amdgpu 0000:08:00.0: amdgpu: [drm] amdgpu: DP AUX transfer fail:4
but other then that it seems to work
Den tis 13 maj 2025 kl 07:26 skrev Christian Heusel <[email protected]>:
Quoted 45 lines · Greg Kroah-Hartman
Quoted 7 lines
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hello everyone,
I have noticed that the following commit produces a whole bunch of lines in my journal, which looks like an error for me:
Quoted 2 lines
Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcaseamdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:
0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially writtenthis does not seem to be serious, i.e. the system otherwise works as intended but it's still noteworthy. Is there a dependency commit missing maybe? From the code it looks like it was meant to be this way 🤔
You can find a full journal here, with the logspammed parts in highlight:
https://gist.github.com/christian-heusel/e8418bbdca097871489a31d79ed166d6#file-dmesg-log-L854-L981Cheers,
Chris
Quoted 38 lines · Christian Heusel
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hello everyone,
I have noticed that the following commit produces a whole bunch of lines in my journal, which looks like an error for me:
Quoted 2 lines
Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcaseamdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:
0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially writtenthis does not seem to be serious, i.e. the system otherwise works as intended but it's still noteworthy. Is there a dependency commit missing maybe? From the code it looks like it was meant to be this way 🤔
Quoted 6 lines
You can find a full journal here, with the logspammed parts in highlight:
https://gist.github.com/christian-heusel/e8418bbdca097871489a31d79ed166d6#file-dmesg-log-L854-L981Cheers,
Chris
Here's the fix:
Thanks,
Same problem in rc2 just tested
Den tis 13 maj 2025 kl 07:26 skrev Christian Heusel <[email protected]>:
Quoted 45 lines · Greg Kroah-Hartman
Quoted 7 lines
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hello everyone,
I have noticed that the following commit produces a whole bunch of lines in my journal, which looks like an error for me:
Quoted 2 lines
Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcaseamdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:
0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially writtenthis does not seem to be serious, i.e. the system otherwise works as intended but it's still noteworthy. Is there a dependency commit missing maybe? From the code it looks like it was meant to be this way 🤔
You can find a full journal here, with the logspammed parts in highlight:
https://gist.github.com/christian-heusel/e8418bbdca097871489a31d79ed166d6#file-dmesg-log-L854-L981Cheers,
Chris
Quoted 1 line · Luna Jernberg
Same problem in rc2 just tested
Yes the fix is still on the way to mainline (see the mail from Mario pointing to the patches posted to amd-gfx), but given that it's just some log entries that stop again and nothing serious it should not be of much issue.
Cheers,
Chris
Quoted 46 lines
Den tis 13 maj 2025 kl 07:26 skrev Christian Heusel <[email protected]>:
Quoted 45 lines · Greg Kroah-Hartman
Quoted 7 lines
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hello everyone,
I have noticed that the following commit produces a whole bunch of lines in my journal, which looks like an error for me:
Quoted 2 lines
Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcaseamdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:
0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially written amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX reply command not ACK:0x01. amdgpu 0000:04:00.0: amdgpu: [drm] amdgpu: AUX partially writtenthis does not seem to be serious, i.e. the system otherwise works as intended but it's still noteworthy. Is there a dependency commit missing maybe? From the code it looks like it was meant to be this way 🤔
You can find a full journal here, with the logspammed parts in highlight:
https://gist.github.com/christian-heusel/e8418bbdca097871489a31d79ed166d6#file-dmesg-log-L854-L981Cheers,
Chris
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
Regressions on mips defconfig tinyconfig and allnoconfig builds failed with clang-20 toolchain on stable-rc 6.14.7-rc1, 6.12.29-rc1 and 6.6.91-rc1. But, builds pass with gcc-13.
* mips, build
- clang-20-allnoconfig
- clang-20-defconfig
- clang-20-tinyconfig
- korg-clang-20-lkftconfig-hardening
- korg-clang-20-lkftconfig-lto-full
- korg-clang-20-lkftconfig-lto-thing
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Build regression: mips defconfig clang-20 instantiation error expected an immediate
## Build error mips
<instantiation>:7:11: error: expected an immediate
ori $26, r4k_wait_idle_size - 2
^
<instantiation>:10:13: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:10:29: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:7:11: error: expected an immediate
ori $26, r4k_wait_idle_size - 2
^
<instantiation>:10:13: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:10:29: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^arch/mips/kernel/genex.S:531:2: warning: macro defined with named parameters which are not used in macro body, possible positional parameter found in body which will have no effect
.macro __BUILD_verbose nexception
^
## Build mips
* Build log: https://qa-reports.linaro.org/api/testruns/28409657/log_file/
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.14.y/build/v6.14.6-198-g4f7f8fb4f8e3/testrun/28409667/suite/build/test/clang-20-defconfig/history/
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.14.y/build/v6.14.6-198-g4f7f8fb4f8e3/testrun/28409657/suite/build/test/clang-20-defconfig/details/
* Build link: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/2x0SR9ZL9r6xvF3HT3UgkQA9ebC
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2x0SR9ZL9r6xvF3HT3UgkQA9ebC/config
* Toolchain: clang-20
## Steps to reproduce
- tuxmake --runtime podman --target-arch mips --toolchain clang-20
--kconfig defconfig LLVM=1 LLVM_IAS=1
## Build
* kernel: 6.14.7-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 4f7f8fb4f8e35798b197be0b6b13229aa1864da1
* git describe: v6.14.6-198-g4f7f8fb4f8e3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.14.y/build/v6.14.6-198-g4f7f8fb4f8e3
## Test Regressions (compared to v6.14.5-184-ga33747967783)
* mips, build
- clang-20-allnoconfig
- clang-20-defconfig
- clang-20-tinyconfig
- korg-clang-20-lkftconfig-hardening
- korg-clang-20-lkftconfig-lto-full
- korg-clang-20-lkftconfig-lto-thing
## Metric Regressions (compared to v6.14.5-184-ga33747967783)
## Test Fixes (compared to v6.14.5-184-ga33747967783)
## Metric Fixes (compared to v6.14.5-184-ga33747967783)
## Test result summary
total: 155299, pass: 129321, fail: 5951, skip: 19411, xfail: 616
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 137 passed, 2 failed
* arm64: 56 total, 55 passed, 1 failed
* i386: 18 total, 16 passed, 2 failed
* mips: 34 total, 27 passed, 7 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 40 passed, 0 failed
* riscv: 25 total, 22 passed, 3 failed
* s390: 22 total, 22 passed, 0 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 42 passed, 7 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-rust
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Quoted 46 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
Regressions on mips defconfig tinyconfig and allnoconfig builds failed with clang-20 toolchain on stable-rc 6.14.7-rc1, 6.12.29-rc1 and 6.6.91-rc1. But, builds pass with gcc-13.
* mips, build
- clang-20-allnoconfig
- clang-20-defconfig
- clang-20-tinyconfig
- korg-clang-20-lkftconfig-hardening
- korg-clang-20-lkftconfig-lto-full
- korg-clang-20-lkftconfig-lto-thingRegression Analysis:
- New regression? Yes
- Reproducibility? YesBuild regression: mips defconfig clang-20 instantiation error expected an immediate
## Build error mips
<instantiation>:7:11: error: expected an immediate
ori $26,r4k_wait_idle_size- 2
Quoted 16 lines
^
<instantiation>:10:13: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:10:29: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:7:11: error: expected an immediate
ori $26, r4k_wait_idle_size - 2
^
<instantiation>:10:13: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^
<instantiation>:10:29: error: expected an immediate
addiu $26, r4k_wait_exit - r4k_wait_insn + 2
^The bisection found this as first bad commit,
MIPS: Fix idle VS timer enqueue
[ Upstream commit 56651128e2fbad80f632f388d6bf1f39c928267a ]
- Naresh Kamboju
Greg Kroah-Hartman
maintainerQuoted 65 lines · Naresh Kamboju
Quoted 46 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
Regressions on mips defconfig tinyconfig and allnoconfig builds failed with clang-20 toolchain on stable-rc 6.14.7-rc1, 6.12.29-rc1 and 6.6.91-rc1. But, builds pass with gcc-13.
* mips, build
- clang-20-allnoconfig
- clang-20-defconfig
- clang-20-tinyconfig
- korg-clang-20-lkftconfig-hardening
- korg-clang-20-lkftconfig-lto-full
- korg-clang-20-lkftconfig-lto-thingRegression Analysis:
- New regression? Yes
- Reproducibility? YesBuild regression: mips defconfig clang-20 instantiation error expected an immediate
## Build error mips
<instantiation>:7:11: error: expected an immediate
ori $26,r4k_wait_idle_size- 2Quoted 16 lines
^ <instantiation>:10:13: error: expected an immediate addiu $26, r4k_wait_exit - r4k_wait_insn + 2 ^ <instantiation>:10:29: error: expected an immediate addiu $26, r4k_wait_exit - r4k_wait_insn + 2 ^ <instantiation>:7:11: error: expected an immediate ori $26, r4k_wait_idle_size - 2 ^ <instantiation>:10:13: error: expected an immediate addiu $26, r4k_wait_exit - r4k_wait_insn + 2 ^ <instantiation>:10:29: error: expected an immediate addiu $26, r4k_wait_exit - r4k_wait_insn + 2 ^
Quoted 5 lines
The bisection found this as first bad commit,
MIPS: Fix idle VS timer enqueue
[ Upstream commit
56651128e2fbad80f632f388d6bf1f39c928267a]
Thanks, now dropped from all queues.
greg k-h
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
6.14.7-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.14.7-rc1rv-g4f7f8fb4f8e3
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.1.1 20250425, GNU ld (GNU Binutils) 2.44.0) #1 SMP PREEMPT_DYNAMIC Tue May 13 19:59:27 JST 2025
Thanks
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +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.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
Hi Greg
6.14.7-rc1 compiles, boots and runs here on x86_64 (AMD Ryzen 5 7520U, Slackware64-current), no regressions observed.
Am 12.05.2025 um 19:37 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
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]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
As it turns out my [previous concern][0] was just about a bit too noisy logging facility you can add my
Tested on a ThinkPad E14 Gen 3 with a AMD Ryzen 5 5500U CPU and on the Steam Deck (LCD variant) aswell as a Framework Desktop.
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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.
Running included BPF selftests with a BPF CI fork (i.e. running on GitHub Action x86-64 machines), I observe that that running the BPF selftests now takes about 2x the time (from ~25m to ~50m), and verif_scale_loop3_fail is timing out, taking more than 6 minutes to run compare to the usual single digit second runtime. See [1] for the log.
07:59:38.2908767Z #449 verif_scale_loop2:OK
07:59:48.2920046Z WATCHDOG: test case verif_scale_loop3_fail executes for 10 seconds...
08:01:38.2921924Z WATCHDOG: test case verif_scale_loop3_fail executes for 120 seconds, terminating with SIGSEGV
08:01:38.2973073Z #450 verif_scale_loop3_fail:FAIL
08:01:38.2973500Z Caught signal #11!
08:01:38.2973808Z Stack trace:
08:01:38.2974148Z ./test_progs(crash_handler+0x38)[0x564524d62f5c]
08:01:38.2974682Z /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7f696f47d330]
08:01:38.2975847Z /lib/x86_64-linux-gnu/libc.so.6(syscall+0x1d)[0x7f696f55f25d]
08:01:38.2976387Z ./test_progs(+0x41a7cd)[0x564524d9d7cd]
08:01:38.2976822Z ./test_progs(+0x41a7f5)[0x564524d9d7f5]
08:01:38.2977236Z ./test_progs(+0x41a82e)[0x564524d9d82e]
08:01:38.2980004Z ./test_progs(bpf_prog_load+0x681)[0x564524d9e555]
08:01:38.2980570Z ./test_progs(+0x408ccc)[0x564524d8bccc]
08:01:38.2980969Z ./test_progs(+0x409b89)[0x564524d8cb89]
08:01:38.2981337Z ./test_progs(+0x40b87a)[0x564524d8e87a]
08:01:38.2981674Z ./test_progs(bpf_object__load+0x26)[0x564524d8eb24]
08:01:38.2981943Z ./test_progs(+0x8c160)[0x564524a0f160]
08:01:38.2982173Z ./test_progs(+0x8c1c8)[0x564524a0f1c8]
08:01:38.2982467Z ./test_progs(test_verif_scale_loop3_fail+0x21)[0x564524a0f59b]
08:01:38.2982752Z ./test_progs(+0x3e0500)[0x564524d63500]
08:01:38.2982983Z ./test_progs(main+0x5cd)[0x564524d65248]
08:01:38.2983261Z /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7f696f4621ca]
08:01:38.2983651Z /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7f696f46228b]
08:01:38.2983998Z ./test_progs(_start+0x25)[0x5645249ba4a5]
08:08:01.6898496Z libbpf: prog 'while_true': BPF program load failed: -E2BIG
08:08:01.6898956Z libbpf: prog 'while_true': -- BEGIN PROG LOAD LOG --
08:08:01.6899443Z BPF program is too large. Processed 1000001 insn
08:08:01.6899823Z verification time 383390707 usec
08:08:01.6900045Z stack depth 16
08:08:01.6900621Z processed 1000001 insns (limit 1000000) max_states_per_insn 4 total_states 12347 peak_states 12347 mark_read 1 08:08:01.6901359Z -- END PROG LOAD LOG --
08:08:01.6901824Z libbpf: prog 'while_true': failed to load: -E2BIG
08:08:01.6902368Z libbpf: failed to load object 'loop3.bpf.o'
08:08:01.6902858Z scale_test:PASS:expect_error 0 nsec
08:08:01.6903248Z #450 verif_scale_loop3_fail:FAIL
Compare to a day before when such behavior wasn't observed[2], the main difference being these additional patches:
input-cyttsp5-ensure-minimum-reset-pulse-width.patch input-cyttsp5-fix-power-control-issue-on-wakeup.patch input-mtk-pmic-keys-fix-possible-null-pointer-dereference.patch input-xpad-fix-share-button-on-xbox-one-controllers.patch input-xpad-add-support-for-8bitdo-ultimate-2-wireless-controller.patch input-xpad-fix-two-controller-table-values.patch input-synaptics-enable-intertouch-on-dynabook-portege-x30-d.patch input-synaptics-enable-intertouch-on-dynabook-portege-x30l-g.patch input-synaptics-enable-intertouch-on-dell-precision-m3800.patch input-synaptics-enable-smbus-for-hp-elitebook-850-g1.patch input-synaptics-enable-intertouch-on-tuxedo-infinitybook-pro-14-v5.patch rust-clean-rust-1.88.0-s-unnecessary_transmutes-lint.patch objtool-rust-add-one-more-noreturn-rust-function-for-rust-1.87.0.patch rust-clean-rust-1.88.0-s-warning-about-clippy-disallowed_macros-configuration.patch uio_hv_generic-fix-sysfs-creation-path-for-ring-buffer.patch staging-iio-adc-ad7816-correct-conditional-logic-for-store-mode.patch staging-bcm2835-camera-initialise-dev-in-v4l2_dev.patch staging-axis-fifo-remove-hardware-resets-for-user-errors.patch staging-axis-fifo-correct-handling-of-tx_fifo_depth-for-size-validation.patch x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch mm-fix-folio_pte_batch-on-xen-pv.patch mm-vmalloc-support-more-granular-vrealloc-sizing.patch mm-huge_memory-fix-dereferencing-invalid-pmd-migration-entry.patch mm-userfaultfd-fix-uninitialized-output-field-for-eagain-race.patch selftests-mm-compaction_test-support-platform-with-huge-mount-of-memory.patch selftests-mm-fix-a-build-failure-on-powerpc.patch selftests-mm-fix-build-break-when-compiling-pkey_util.c.patch kvm-x86-mmu-prevent-installing-hugepages-when-mem-attributes-are-changing.patch kvm-svm-forcibly-leave-smm-mode-on-shutdown-interception.patch drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch iio-adc-ad7606-fix-serial-register-access.patch iio-adc-rockchip-fix-clock-initialization-sequence.patch iio-adis16201-correct-inclinometer-channel-resolution.patch iio-chemical-sps30-use-aligned_s64-for-timestamp.patch iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch iio-hid-sensor-prox-restore-lost-scale-assignments.patch iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch drm-xe-add-page-queue-multiplier.patch
drm-amdgpu-fix-pm-notifier-handling.patch drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch drm-amd-display-fix-invalid-context-error-in-dml-helper.patch drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch usb-uhci-platform-make-the-clock-really-optional.patch smb-client-avoid-race-in-open_cached_dir-with-lease-breaks.patch xen-swiotlb-use-swiotlb-bouncing-if-kmalloc-allocation-demands-it.patch xenbus-use-kref-to-track-req-lifetime.patch accel-ivpu-increase-state-dump-msg-timeout.patch arm64-cpufeature-move-arm64_use_ng_mappings-to-the-.data-section-to-prevent-wrong-idmap-generation.patch clocksource-i8253-use-raw_spinlock_irqsave-in-clockevent_i8253_disable.patch kvm-arm64-fix-uninitialized-memcache-pointer-in-user_mem_abort.patch memblock-accept-allocated-memory-before-use-in-memblock_double_array.patch module-ensure-that-kobject_put-is-safe-for-module-type-kobjects.patch x86-microcode-consolidate-the-loader-enablement-checking.patch ocfs2-fix-panic-in-failed-foilio-allocation.patch ocfs2-fix-the-issue-with-discontiguous-allocation-in-the-global_bitmap.patch ocfs2-switch-osb-disable_recovery-to-enum.patch ocfs2-implement-handshaking-with-ocfs2-recovery-thread.patch ocfs2-stop-quota-recovery-before-disabling-quotas.patch usb-dwc3-gadget-make-gadget_wakeup-asynchronous.patch usb-cdnsp-fix-issue-with-resuming-from-l1.patch usb-cdnsp-fix-l1-resume-issue-for-rtl_revision_new_lpm-version.patch usb-gadget-f_ecm-add-get_status-callback.patch usb-gadget-tegra-xudc-ack-st_rc-after-clearing-ctrl_run.patch usb-gadget-use-get_status-callback-to-set-remote-wakeup-capability.patch usb-host-tegra-prevent-host-controller-crash-when-otg-port-is-used.patch usb-misc-onboard_usb_dev-fix-support-for-cypress-hx3-hubs.patch usb-typec-tcpm-delay-snk_try_wait_debounce-to-src_trywait-transition.patch usb-typec-ucsi-displayport-fix-deadlock.patch usb-typec-ucsi-displayport-fix-null-pointer-access.patch usb-usbtmc-use-interruptible-sleep-in-usbtmc_read.patch usb-usbtmc-fix-erroneous-get_stb-ioctl-error-returns.patch usb-usbtmc-fix-erroneous-wait_srq-ioctl-return.patch usb-usbtmc-fix-erroneous-generic_read-ioctl-return.patch iio-imu-bmi270-fix-initial-sampling-frequency-config.patch iio-accel-adxl367-fix-setting-odr-for-activity-time-.patch iio-temp-maxim-thermocouple-fix-potential-lack-of-dm.patch iio-accel-adxl355-make-timestamp-64-bit-aligned-usin.patch iio-adc-dln2-use-aligned_s64-for-timestamp.patch
mips-fix-idle-vs-timer-enqueue.patch
mips-move-r4k_wait-to-.cpuidle.text-section.patch timekeeping-prevent-coarse-clocks-going-backwards.patch accel-ivpu-separate-db-id-and-cmdq-id-allocations-fr.patch accel-ivpu-correct-mutex-unlock-order-in-job-submiss.patch mips-fix-max_reg_offset.patch
riscv-misaligned-add-handling-for-zcb-instructions.patch loop-factor-out-a-loop_assign_backing_file-helper.patch loop-add-sanity-check-for-read-write_iter.patch drm-panel-simple-update-timings-for-auo-g101evn010.patch nvme-unblock-ctrl-state-transition-for-firmware-upda.patch riscv-misaligned-factorize-trap-handling.patch riscv-misaligned-enable-irqs-while-handling-misalign.patch riscv-disallow-pr_get_tagged_addr_ctrl-without-supm.patch drm-xe-tests-mocs-hold-xe_forcewake_all-for-lncf-reg.patch drm-xe-release-force-wake-first-then-runtime-power.patch io_uring-sqpoll-increase-task_work-submission-batch-.patch do_umount-add-missing-barrier-before-refcount-checks.patch rust-allow-rust-1.87.0-s-clippy-ptr_eq-lint.patch rust-clean-rust-1.88.0-s-clippy-uninlined_format_args-lint.patch io_uring-always-arm-linked-timeouts-prior-to-issue.patch bluetooth-btmtk-remove-the-resetting-step-before-downloading-the-fw.patch mm-page_alloc-don-t-steal-single-pages-from-biggest-buddy.patch mm-page_alloc-speed-up-fallbacks-in-rmqueue_bulk.patch arm64-insn-add-support-for-encoding-dsb.patch arm64-proton-pack-expose-whether-the-platform-is-mitigated-by-firmware.patch arm64-proton-pack-expose-whether-the-branchy-loop-k-value.patch arm64-bpf-add-bhb-mitigation-to-the-epilogue-for-cbpf-programs.patch arm64-bpf-only-mitigate-cbpf-programs-loaded-by-unprivileged-users.patch arm64-proton-pack-add-new-cpus-k-values-for-branch-mitigation.patch x86-bpf-call-branch-history-clearing-sequence-on-exit.patch x86-bpf-add-ibhf-call-at-end-of-classic-bpf.patch x86-bhi-do-not-set-bhi_dis_s-in-32-bit-mode.patch documentation-x86-bugs-its-add-its-documentation.patch x86-its-enumerate-indirect-target-selection-its-bug.patch x86-its-add-support-for-its-safe-indirect-thunk.patch x86-its-add-support-for-its-safe-return-thunk.patch x86-its-enable-indirect-target-selection-mitigation.patch x86-its-add-vmexit-option-to-skip-mitigation-on-some-cpus.patch x86-its-add-support-for-rsb-stuffing-mitigation.patch x86-its-align-rets-in-bhb-clear-sequence-to-avoid-thunking.patch x86-ibt-keep-ibt-disabled-during-alternative-patching.patch x86-its-use-dynamic-thunks-for-indirect-branches.patch selftest-x86-bugs-add-selftests-for-its.patch
No patches touch BPF's core component, and while the verif_scale_loop3_fail test did time out, the verifier is still correctly rejecting it, so shouldn't have anything to do with kernel/bpf/. The x86/arm64 BPF patches only affect JIT output, and only for cBPF.
In comparison, with 6.12.29-rc1 I don't observe any timeout or increase in runtime[3]. Below is a diff comparing the applied patches in 6.12.29-rc1 and 6.14.7-rc1. Seems like 6.14.7-rc1 does not have the CALL_NOSPEC patches, but I cannot tell whether that is what makes the difference.
1: https://github.com/shunghsiyu/libbpf/actions/runs/14979866777/job/42113654856
2: https://github.com/shunghsiyu/libbpf/actions/runs/14958571057/job/42017510267
3: https://github.com/shunghsiyu/libbpf/actions/runs/14979866777/job/42113654879
6.14.7-rc1-series renamed from 6.12.29-rc1-series +27 -14
@@ -17,7 +17,7 @@ openvswitch-fix-unsafe-attribute-parsing-in-output_userspace.patch ksmbd-fix-memory-leak-in-parse_lease_state.patch s390-entry-fix-last-breaking-event-handling-in-case-.patch sch_htb-make-htb_deactivate-idempotent.patch -virtio_net-xsk-bind-unbind-xsk-for-tx.patch +virtio-net-don-t-re-enable-refill-work-too-early-whe.patch virtio-net-free-xsk_buffs-on-error-in-virtnet_xsk_po.patch gre-fix-again-ipv6-link-local-address-generation.patch net-ethernet-mtk_eth_soc-reset-all-tx-queues-on-dma-.patch
@@ -26,7 +26,6 @@ can-m_can-m_can_class_allocate_dev-initialize-spin-l.patch can-mcp251xfd-fix-tdc-setting-for-low-data-bit-rates.patch can-gw-fix-rcu-bh-usage-in-cgw_create_job.patch wifi-mac80211-fix-the-type-of-status_code-for-negoti.patch -ice-initial-support-for-e825c-hardware-in-ice_adapte.patch ice-use-dsn-instead-of-pci-bdf-for-ice_adapter-index.patch erofs-ensure-the-extra-temporary-copy-is-valid-for-s.patch ipvs-fix-uninit-value-for-saddr-in-do_output_route4.patch
@@ -46,6 +45,7 @@ net-dsa-b53-do-not-set-learning-and-unicast-multicas.patch fbnic-fix-initialization-of-mailbox-descriptor-rings.patch fbnic-gate-axi-read-write-enabling-on-fw-mailbox.patch fbnic-actually-flush_tx-instead-of-stalling-out.patch +fbnic-cleanup-handling-of-completions.patch fbnic-improve-responsiveness-of-fbnic_mbx_poll_tx_re.patch fbnic-pull-fbnic_fw_xmit_cap_msg-use-out-of-interrup.patch fbnic-do-not-allow-mailbox-to-toggle-to-ready-outsid.patch
@@ -65,6 +65,7 @@ input-synaptics-enable-intertouch-on-tuxedo-infinitybook-pro-14-v5.patch rust-clean-rust-1.88.0-s-unnecessary_transmutes-lint.patch objtool-rust-add-one-more-noreturn-rust-function-for-rust-1.87.0.patch rust-clean-rust-1.88.0-s-warning-about-clippy-disallowed_macros-configuration.patch +uio_hv_generic-fix-sysfs-creation-path-for-ring-buffer.patch staging-iio-adc-ad7816-correct-conditional-logic-for-store-mode.patch staging-bcm2835-camera-initialise-dev-in-v4l2_dev.patch staging-axis-fifo-remove-hardware-resets-for-user-errors.patch
@@ -76,17 +77,31 @@ mm-huge_memory-fix-dereferencing-invalid-pmd-migration-entry.patch mm-userfaultfd-fix-uninitialized-output-field-for-eagain-race.patch selftests-mm-compaction_test-support-platform-with-huge-mount-of-memory.patch selftests-mm-fix-a-build-failure-on-powerpc.patch +selftests-mm-fix-build-break-when-compiling-pkey_util.c.patch +kvm-x86-mmu-prevent-installing-hugepages-when-mem-attributes-are-changing.patch kvm-svm-forcibly-leave-smm-mode-on-shutdown-interception.patch drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch +riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch +iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch +iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch iio-adc-ad7606-fix-serial-register-access.patch iio-adc-rockchip-fix-clock-initialization-sequence.patch iio-adis16201-correct-inclinometer-channel-resolution.patch +iio-chemical-sps30-use-aligned_s64-for-timestamp.patch +iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch +iio-hid-sensor-prox-restore-lost-scale-assignments.patch +iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch +iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch +iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch +iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch +revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch drm-xe-add-page-queue-multiplier.patch +drm-amdgpu-fix-pm-notifier-handling.patch drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch drm-amd-display-fix-invalid-context-error-in-dml-helper.patch drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch
@@ -99,6 +114,7 @@ drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch usb-uhci-platform-make-the-clock-really-optional.patch smb-client-avoid-race-in-open_cached_dir-with-lease-breaks.patch xen-swiotlb-use-swiotlb-bouncing-if-kmalloc-allocation-demands-it.patch
@@ -106,9 +122,11 @@ xenbus-use-kref-to-track-req-lifetime.patch accel-ivpu-increase-state-dump-msg-timeout.patch arm64-cpufeature-move-arm64_use_ng_mappings-to-the-.data-section-to-prevent-wrong-idmap-generation.patch clocksource-i8253-use-raw_spinlock_irqsave-in-clockevent_i8253_disable.patch +kvm-arm64-fix-uninitialized-memcache-pointer-in-user_mem_abort.patch memblock-accept-allocated-memory-before-use-in-memblock_double_array.patch module-ensure-that-kobject_put-is-safe-for-module-type-kobjects.patch x86-microcode-consolidate-the-loader-enablement-checking.patch +ocfs2-fix-panic-in-failed-foilio-allocation.patch ocfs2-fix-the-issue-with-discontiguous-allocation-in-the-global_bitmap.patch ocfs2-switch-osb-disable_recovery-to-enum.patch ocfs2-implement-handshaking-with-ocfs2-recovery-thread.patch
@@ -122,43 +140,41 @@ usb-gadget-use-get_status-callback-to-set-remote-wakeup-capability.patch usb-host-tegra-prevent-host-controller-crash-when-otg-port-is-used.patch usb-misc-onboard_usb_dev-fix-support-for-cypress-hx3-hubs.patch usb-typec-tcpm-delay-snk_try_wait_debounce-to-src_trywait-transition.patch +usb-typec-ucsi-displayport-fix-deadlock.patch usb-typec-ucsi-displayport-fix-null-pointer-access.patch usb-usbtmc-use-interruptible-sleep-in-usbtmc_read.patch usb-usbtmc-fix-erroneous-get_stb-ioctl-error-returns.patch usb-usbtmc-fix-erroneous-wait_srq-ioctl-return.patch usb-usbtmc-fix-erroneous-generic_read-ioctl-return.patch +iio-imu-bmi270-fix-initial-sampling-frequency-config.patch iio-accel-adxl367-fix-setting-odr-for-activity-time-.patch iio-temp-maxim-thermocouple-fix-potential-lack-of-dm.patch -types-complement-the-aligned-types-with-signed-64-bi.patch iio-accel-adxl355-make-timestamp-64-bit-aligned-usin.patch iio-adc-dln2-use-aligned_s64-for-timestamp.patch mips-fix-idle-vs-timer-enqueue.patch mips-move-r4k_wait-to-.cpuidle.text-section.patch +timekeeping-prevent-coarse-clocks-going-backwards.patch +accel-ivpu-separate-db-id-and-cmdq-id-allocations-fr.patch +accel-ivpu-correct-mutex-unlock-order-in-job-submiss.patch mips-fix-max_reg_offset.patch riscv-misaligned-add-handling-for-zcb-instructions.patch -loop-use-bdev-limit-helpers-for-configuring-discard.patch -loop-simplify-discard-granularity-calc.patch -loop-fix-abba-locking-race.patch -loop-refactor-queue-limits-updates.patch loop-factor-out-a-loop_assign_backing_file-helper.patch loop-add-sanity-check-for-read-write_iter.patch drm-panel-simple-update-timings-for-auo-g101evn010.patch nvme-unblock-ctrl-state-transition-for-firmware-upda.patch riscv-misaligned-factorize-trap-handling.patch riscv-misaligned-enable-irqs-while-handling-misalign.patch -drm-xe-tests-mocs-update-xe_force_wake_get-return-ha.patch +riscv-disallow-pr_get_tagged_addr_ctrl-without-supm.patch drm-xe-tests-mocs-hold-xe_forcewake_all-for-lncf-reg.patch +drm-xe-release-force-wake-first-then-runtime-power.patch io_uring-sqpoll-increase-task_work-submission-batch-.patch do_umount-add-missing-barrier-before-refcount-checks.patch -revert-um-work-around-sched_yield-not-yielding-in-time-travel-mode.patch rust-allow-rust-1.87.0-s-clippy-ptr_eq-lint.patch rust-clean-rust-1.88.0-s-clippy-uninlined_format_args-lint.patch io_uring-always-arm-linked-timeouts-prior-to-issue.patch -bluetooth-btmtk-remove-resetting-mt7921-before-downloading-the-fw.patch bluetooth-btmtk-remove-the-resetting-step-before-downloading-the-fw.patch mm-page_alloc-don-t-steal-single-pages-from-biggest-buddy.patch mm-page_alloc-speed-up-fallbacks-in-rmqueue_bulk.patch -sched-eevdf-fix-se-slice-being-set-to-u64_max-and-resulting-crash.patch arm64-insn-add-support-for-encoding-dsb.patch arm64-proton-pack-expose-whether-the-platform-is-mitigated-by-firmware.patch arm64-proton-pack-expose-whether-the-branchy-loop-k-value.patch
@@ -168,9 +184,6 @@ arm64-proton-pack-add-new-cpus-k-values-for-branch-mitigation.patch x86-bpf-call-branch-history-clearing-sequence-on-exit.patch x86-bpf-add-ibhf-call-at-end-of-classic-bpf.patch x86-bhi-do-not-set-bhi_dis_s-in-32-bit-mode.patch -x86-speculation-simplify-and-make-call_nospec-consistent.patch -x86-speculation-add-a-conditional-cs-prefix-to-call_nospec.patch -x86-speculation-remove-the-extra-ifdef-around-call_nospec.patch documentation-x86-bugs-its-add-its-documentation.patch x86-its-enumerate-indirect-target-selection-its-bug.patch x86-its-add-support-for-its-safe-indirect-thunk.patch
Quoted 66 lines · Shung-Hsi Yu
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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.
Running included BPF selftests with a BPF CI fork (i.e. running on GitHub Action x86-64 machines), I observe that that running the BPF selftests now takes about 2x the time (from ~25m to ~50m), and
verif_scale_loop3_failis timing out, taking more than 6 minutes to run compare to the usual single digit second runtime. See [1] for the log.07:59:38.2908767Z #449 verif_scale_loop2:OK
07:59:48.2920046Z WATCHDOG: test caseverif_scale_loop3_failexecutes for 10 seconds...
08:01:38.2921924Z WATCHDOG: test caseverif_scale_loop3_failexecutes for 120 seconds, terminating with SIGSEGV
08:01:38.2973073Z #450 verif_scale_loop3_fail:FAIL
08:01:38.2973500Z Caught signal #11!
08:01:38.2973808Z Stack trace:
08:01:38.2974148Z ./test_progs(crash_handler+0x38)[0x564524d62f5c]
08:01:38.2974682Z /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7f696f47d330]
08:01:38.2975847Z /lib/x86_64-linux-gnu/libc.so.6(syscall+0x1d)[0x7f696f55f25d]
08:01:38.2976387Z ./test_progs(+0x41a7cd)[0x564524d9d7cd]
08:01:38.2976822Z ./test_progs(+0x41a7f5)[0x564524d9d7f5]
08:01:38.2977236Z ./test_progs(+0x41a82e)[0x564524d9d82e]
08:01:38.2980004Z ./test_progs(bpf_prog_load+0x681)[0x564524d9e555]
08:01:38.2980570Z ./test_progs(+0x408ccc)[0x564524d8bccc]
08:01:38.2980969Z ./test_progs(+0x409b89)[0x564524d8cb89]
08:01:38.2981337Z ./test_progs(+0x40b87a)[0x564524d8e87a]
08:01:38.2981674Z ./test_progs(bpf_object__load+0x26)[0x564524d8eb24]
08:01:38.2981943Z ./test_progs(+0x8c160)[0x564524a0f160]
08:01:38.2982173Z ./test_progs(+0x8c1c8)[0x564524a0f1c8]
08:01:38.2982467Z ./test_progs(test_verif_scale_loop3_fail+0x21)[0x564524a0f59b]
08:01:38.2982752Z ./test_progs(+0x3e0500)[0x564524d63500]
08:01:38.2982983Z ./test_progs(main+0x5cd)[0x564524d65248]
08:01:38.2983261Z /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7f696f4621ca]
08:01:38.2983651Z /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7f696f46228b]
08:01:38.2983998Z ./test_progs(_start+0x25)[0x5645249ba4a5]
08:08:01.6898496Z libbpf: prog 'while_true': BPF program load failed:-E2BIG
08:08:01.6898956Z libbpf: prog 'while_true': -- BEGIN PROG LOAD LOG --
08:08:01.6899443Z BPF program is too large. Processed 1000001 insn
08:08:01.6899823Z verification time 383390707 usec
08:08:01.6900045Z stack depth 16
08:08:01.6900621Z processed 1000001 insns (limit 1000000)max_states_per_insn4total_states12347peak_states12347mark_read1 08:08:01.6901359Z -- END PROG LOAD LOG --
08:08:01.6901824Z libbpf: prog 'while_true': failed to load:-E2BIG
08:08:01.6902368Z libbpf: failed to load object 'loop3.bpf.o'
08:08:01.6902858Z scale_test:PASS:expect_error 0 nsec
08:08:01.6903248Z #450 verif_scale_loop3_fail:FAILCompare to a day before when such behavior wasn't observed[2], the main difference being these additional patches:
input-cyttsp5-ensure-minimum-reset-pulse-width.patch input-cyttsp5-fix-power-control-issue-on-wakeup.patch input-mtk-pmic-keys-fix-possible-null-pointer-dereference.patch input-xpad-fix-share-button-on-xbox-one-controllers.patch input-xpad-add-support-for-8bitdo-ultimate-2-wireless-controller.patch input-xpad-fix-two-controller-table-values.patch input-synaptics-enable-intertouch-on-dynabook-portege-x30-d.patch input-synaptics-enable-intertouch-on-dynabook-portege-x30l-g.patch input-synaptics-enable-intertouch-on-dell-precision-m3800.patch input-synaptics-enable-smbus-for-hp-elitebook-850-g1.patch input-synaptics-enable-intertouch-on-tuxedo-infinitybook-pro-14-v5.patch rust-clean-rust-1.88.0-s-unnecessary_transmutes-lint.patch objtool-rust-add-one-more-noreturn-rust-function-for-rust-1.87.0.patch rust-clean-rust-1.88.0-s-warning-about-clippy-disallowed_macros-configuration.patch
Quoted 8 lines
uio_hv_generic-fix-sysfs-creation-path-for-ring-buffer.patch staging-iio-adc-ad7816-correct-conditional-logic-for-store-mode.patch staging-bcm2835-camera-initialise-dev-in-v4l2_dev.patch staging-axis-fifo-remove-hardware-resets-for-user-errors.patch staging-axis-fifo-correct-handling-of-tx_fifo_depth-for-size-validation.patch x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch mm-fix-folio_pte_batch-on-xen-pv.patch mm-vmalloc-support-more-granular-vrealloc-sizing.patch
Not sure why but this commit seems to related to the failure.
Below is log of bisecting v6.14.6 and v6.14.7-rc2 with the test:
./tools/testing/selftests/bpf/vmtest.sh -i -- timeout 20 ./test_progs -t verif_scale_loop3_fail
# good: [e2d3e1fdb530198317501eb7ded4f3a5fb6c881c] Linux 6.14.6
git bisect good e2d3e1fdb530198317501eb7ded4f3a5fb6c881c
# status: waiting for bad commit, 1 good commit known
# bad: [6f7a299729d3dff3ffade04ad8fbddb3b172d637] Linux 6.14.7-rc2
git bisect bad 6f7a299729d3dff3ffade04ad8fbddb3b172d637
# bad: [572ca62a1e819e1ebd317e7c0e35cf7ff382aec6] iio: light: opt3001: fix deadlock due to concurrent flag access git bisect bad 572ca62a1e819e1ebd317e7c0e35cf7ff382aec6
# good: [5b1202a1e881c45d4500afa3f1f67f2fc3cbae10] fbnic: Improve responsiveness of fbnic_mbx_poll_tx_ready git bisect good 5b1202a1e881c45d4500afa3f1f67f2fc3cbae10
# good: [3eabb5db037e216e2e9a67a36e989c5f13ae7170] mm: fix folio_pte_batch() on XEN PV
git bisect good 3eabb5db037e216e2e9a67a36e989c5f13ae7170
# bad: [93511db927bafab3499f6fb61061779ddd68f20f] iio: adc: ad7768-1: Fix insufficient alignment of timestamp. git bisect bad 93511db927bafab3499f6fb61061779ddd68f20f
# bad: [569b32a0099bc2b2a8c827b2238bf785f2632fa7] selftests/mm: fix build break when compiling pkey_util.c git bisect bad 569b32a0099bc2b2a8c827b2238bf785f2632fa7
# bad: [3d5ccf6020b22773d265ecd6f905d19498af9a4e] mm/userfaultfd: fix uninitialized output field for -EAGAIN race git bisect bad 3d5ccf6020b22773d265ecd6f905d19498af9a4e
# bad: [336f780075f36e0d1181ce44d6d4197e4a22babc] mm/huge_memory: fix dereferencing invalid pmd migration entry git bisect bad 336f780075f36e0d1181ce44d6d4197e4a22babc
# bad: [665f26e5de2325e3bca107b632bc2ccac1b9806a] mm: vmalloc: support more granular vrealloc() sizing git bisect bad 665f26e5de2325e3bca107b632bc2ccac1b9806a
# first bad commit: [665f26e5de2325e3bca107b632bc2ccac1b9806a] mm: vmalloc: support more granular vrealloc() sizing
...
Quoted 11 lines
No patches touch BPF's core component, and while the
verif_scale_loop3_failtest did time out, the verifier is still correctly rejecting it, so shouldn't have anything to do withkernel/bpf/. The x86/arm64 BPF patches only affect JIT output, and only for cBPF.In comparison, with 6.12.29-rc1 I don't observe any timeout or increase in runtime[3]. Below is a diff comparing the applied patches in 6.12.29-rc1 and 6.14.7-rc1. Seems like 6.14.7-rc1 does not have the
CALL_NOSPECpatches, but I cannot tell whether that is what makes the difference.
Thats because CALL_NOSPEC patches were already part of v6.14.
Quoted 12 lines · Pawan Gupta
Quoted 11 lines · Shung-Hsi Yu
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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.
Running included BPF selftests with a BPF CI fork (i.e. running on GitHub Action x86-64 machines), I observe that that running the BPF selftests now takes about 2x the time (from ~25m to ~50m), and
verif_scale_loop3_failis timing out, taking more than 6 minutes to run compare to the usual single digit second runtime. See [1] for the log.
...
Quoted 2 lines
Quoted 2 lines
Compare to a day before when such behavior wasn't observed[2], the main difference being these additional patches:
...
Quoted 8 lines
Not sure why but this commit seems to related to the failure.
Below is log of bisecting v6.14.6 and v6.14.7-rc2 with the test:
./tools/testing/selftests/bpf/vmtest.sh-i -- timeout 20 ./test_progs -tverif_scale_loop3_fail# good: [
e2d3e1fdb530198317501eb7ded4f3a5fb6c881c] Linux 6.14.6 git bisect goode2d3e1fdb530198317501eb7ded4f3a5fb6c881c
...
Quoted 4 lines
git bisect bad
336f780075f36e0d1181ce44d6d4197e4a22babc
# bad: [665f26e5de2325e3bca107b632bc2ccac1b9806a] mm: vmalloc: support more granularvrealloc()sizing git bisect bad665f26e5de2325e3bca107b632bc2ccac1b9806a# first bad commit: [665f26e5de2325e3bca107b632bc2ccac1b9806a] mm: vmalloc: support more granular vrealloc() sizing
Thanks! Just dawn on me after seeing this that I should try 6.15-rc6 as well (which has 665f26e5de23), turns out it also reproduce there. I'll report regression in a separate mail.
Quoted 7 lines
...
Quoted 6 lines
No patches touch BPF's core component, and while the
verif_scale_loop3_failtest did time out, the verifier is still correctly rejecting it, so shouldn't have anything to do withkernel/bpf/. The x86/arm64 BPF patches only affect JIT output, and only for cBPF.
Quoted 7 lines
Quoted 5 lines
In comparison, with 6.12.29-rc1 I don't observe any timeout or increase in runtime[3]. Below is a diff comparing the applied patches in 6.12.29-rc1 and 6.14.7-rc1. Seems like 6.14.7-rc1 does not have the
CALL_NOSPECpatches, but I cannot tell whether that is what makes the difference.Thats because
CALL_NOSPECpatches were already part of v6.14.
Ah yes indeed, sorry about the negligence.
The kernel, bpf tool and perf tool builds fine for v6.14.7-rc1 on x86 and arm64 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename 29157383 7863882 1384280 38405545 24a05a9 vmlinux
Kernel binary size for arm64 build:
text data bss dec hex filename 28427162 18477511 762704 47667377 2d758b1 vmlinux
Thanks,
Hardik
Quoted 841 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.14.7 release. There are 197 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 Wed, 14 May 2025 17:19:58 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.14.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.14.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 6.14.7-rc1Pawan Gupta <[email protected]>
selftest/x86/bugs: Add selftests for ITSPeter Zijlstra <[email protected]>
x86/its: Use dynamic thunks for indirect branchesPawan Gupta <[email protected]>
x86/ibt: Keep IBT disabled during alternative patchingPawan Gupta <[email protected]>
x86/its: Align RETs in BHB clear sequence to avoid thunkingPawan Gupta <[email protected]>
x86/its: Add support for RSB stuffing mitigationPawan Gupta <[email protected]>
x86/its: Add "vmexit" option to skip mitigation on some CPUsPawan Gupta <[email protected]>
x86/its: Enable Indirect Target Selection mitigationPawan Gupta <[email protected]>
x86/its: Add support for ITS-safe return thunkPawan Gupta <[email protected]>
x86/its: Add support for ITS-safe indirect thunkPawan Gupta <[email protected]>
x86/its: Enumerate Indirect Target Selection (ITS) bugPawan Gupta <[email protected]>
Documentation: x86/bugs/its: Add ITS documentationPawan Gupta <[email protected]>
x86/bhi: Do not setBHI_DIS_Sin 32-bit modeDaniel Sneddon <[email protected]>
x86/bpf: Add IBHF call at end of classic BPFDaniel Sneddon <[email protected]>
x86/bpf: Call branch history clearing sequence on exitJames Morse <[email protected]>
arm64: proton-pack: Add new CPUs 'k' values for branch mitigationJames Morse <[email protected]>
arm64: bpf: Only mitigate cBPF programs loaded by unprivileged usersJames Morse <[email protected]>
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programsJames Morse <[email protected]>
arm64: proton-pack: Expose whether the branchy loop k valueJames Morse <[email protected]>
arm64: proton-pack: Expose whether the platform is mitigated by firmwareJames Morse <[email protected]>
arm64: insn: Add support for encoding DSBJohannes Weiner <[email protected]>
mm:page_alloc: speed up fallbacks inrmqueue_bulk()Johannes Weiner <[email protected]>
mm:page_alloc: don't steal single pages from biggest buddyHao Qin <[email protected]>
Bluetooth: btmtk: Remove the resetting step before downloading the fwJens Axboe <[email protected]>
io_uring: always arm linked timeouts prior to issueMiguel Ojeda <[email protected]>
rust: clean Rust 1.88.0'sclippy::uninlined_format_argslintMiguel Ojeda <[email protected]>
rust: allow Rust 1.87.0's `clippy::ptr_eq` lintAl Viro <[email protected]>
do_umount(): add missing barrier before refcount checks in sync caseGabriel Krisman Bertazi <[email protected]>
io_uring/sqpoll: Increasetask_worksubmission batch sizeShuicheng Lin <[email protected]>
drm/xe: Release force wake first then runtime powerTejas Upadhyay <[email protected]>
drm/xe/tests/mocs: HoldXE_FORCEWAKE_ALLfor LNCF regsSamuel Holland <[email protected]>
riscv: DisallowPR_GET_TAGGED_ADDR_CTRLwithout SupmClément Léger <[email protected]>
riscv: misaligned: enable IRQs while handling misaligned accessesClément Léger <[email protected]>
riscv: misaligned: factorize trap handlingDaniel Wagner <[email protected]>
nvme: unblock ctrl state transition for firmware updateKevin Baker <[email protected]>
drm/panel: simple: Update timings for AUO G101EVN010Lizhi Xu <[email protected]>
loop: Add sanity check for read/write_iterChristoph Hellwig <[email protected]>
loop: factor out aloop_assign_backing_filehelperNylon Chen <[email protected]>
riscv: misaligned: Add handling for ZCB instructionsThorsten Blum <[email protected]>
MIPS: FixMAX_REG_OFFSETKarol Wachowski <[email protected]>
accel/ivpu: Correct mutex unlock order in job submissionKarol Wachowski <[email protected]>
accel/ivpu: Separate DB ID and CMDQ ID allocations from CMDQ allocationThomas Gleixner <[email protected]>
timekeeping: Prevent coarse clocks going backwardsMarco Crivellari <[email protected]>
MIPS: Mover4k_wait()to .cpuidle.text sectionMarco Crivellari <[email protected]>
MIPS: Fix idle VS timer enqueueJonathan Cameron <[email protected]>
iio: adc: dln2: Usealigned_s64for timestampJonathan Cameron <[email protected]>
iio: accel: adxl355: Make timestamp 64-bit aligned usingaligned_s64Jonathan Cameron <[email protected]>
iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer.Lothar Rubusch <[email protected]>
iio: accel: adxl367: fix setting odr for activity time updateGustavo Silva <[email protected]>
iio: imu: bmi270: fix initial sampling frequency configurationDave Penkler <[email protected]>
usb: usbtmc: Fix erroneousgeneric_readioctl returnDave Penkler <[email protected]>
usb: usbtmc: Fix erroneouswait_srqioctl returnDave Penkler <[email protected]>
usb: usbtmc: Fix erroneousget_stbioctl error returnsOliver Neukum <[email protected]>
USB: usbtmc: use interruptible sleep inusbtmc_readAndrei Kuchynski <[email protected]>
usb: typec: ucsi: displayport: Fix NULL pointer accessAndrei Kuchynski <[email protected]>
usb: typec: ucsi: displayport: Fix deadlockRD Babiera <[email protected]>
usb: typec: tcpm: delaySNK_TRY_WAIT_DEBOUNCEtoSRC_TRYWAITtransitionLukasz Czechowski <[email protected]>
usb: misc:onboard_usb_dev: fix support for Cypress HX3 hubsJim Lin <[email protected]>
usb: host: tegra: Prevent host controller crash when OTG port is usedPrashanth K <[email protected]>
usb: gadget: Useget_statuscallback to set remote wakeup capabilityWayne Chang <[email protected]>
usb: gadget: tegra-xudc: ACKST_RCafter clearingCTRL_RUNPrashanth K <[email protected]>
usb: gadget:f_ecm: Addget_statuscallbackPawel Laszczak <[email protected]>
usb: cdnsp: fix L1 resume issue forRTL_REVISION_NEW_LPMversionPawel Laszczak <[email protected]>
usb: cdnsp: Fix issue with resuming from L1Prashanth K <[email protected]>
usb: dwc3: gadget: Makegadget_wakeupasynchronousJan Kara <[email protected]>
ocfs2: stop quota recovery before disabling quotasJan Kara <[email protected]>
ocfs2: implement handshaking with ocfs2 recovery threadJan Kara <[email protected]>
ocfs2: switch osb->disable_recovery to enumHeming Zhao <[email protected]>
ocfs2: fix the issue with discontiguous allocation in theglobal_bitmapMark Tinguely <[email protected]>
ocfs2: fix panic in failed foilio allocationBorislav Petkov (AMD) <[email protected]>
x86/microcode: Consolidate the loader enablement checkingDmitry Antipov <[email protected]>
module: ensure thatkobject_put()is safe for module type kobjectsTom Lendacky <[email protected]>
memblock: Accept allocated memory before use inmemblock_double_array()Sebastian Ott <[email protected]>
KVM: arm64: Fix uninitialized memcache pointer inuser_mem_abort()Sebastian Andrzej Siewior <[email protected]>
clocksource/i8253: Useraw_spinlock_irqsave()inclockevent_i8253_disable()Yeoreum Yun <[email protected]>
arm64: cpufeature: Movearm64_use_ng_mappingsto the .data section to prevent wrong idmap generationJacek Lawrynowicz <[email protected]>
accel/ivpu: Increase state dump msg timeoutJason Andryuk <[email protected]>
xenbus: Use kref to track req lifetimeJohn Ernberg <[email protected]>
xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands itPaul Aurich <[email protected]>
smb: client: Avoid race inopen_cached_dirwith lease breaksAlexey Charkov <[email protected]>
usb: uhci-platform: Make the clock really optionalMathias Nyman <[email protected]>
xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive.Alex Deucher <[email protected]>
drm/amdgpu/hdp7: use memcfg register to post the write for HDP flushAlex Deucher <[email protected]>
drm/amdgpu/hdp6: use memcfg register to post the write for HDP flushAlex Deucher <[email protected]>
drm/amdgpu/hdp5: use memcfg register to post the write for HDP flushAlex Deucher <[email protected]>
drm/amdgpu/hdp5.2: use memcfg register to post the write for HDP flushAlex Deucher <[email protected]>
drm/amdgpu/hdp4: use memcfg register to post the write for HDP flushWayne Lin <[email protected]>
drm/amd/display: Copy AUX read reply data whenever length > 0Wayne Lin <[email protected]>
drm/amd/display: Fix wrong handling forAUX_DEFERcaseWayne Lin <[email protected]>
drm/amd/display: Remove incorrect checking in dmub aux handlerWayne Lin <[email protected]>
drm/amd/display: Fix the checking condition in dmub aux handlingAurabindo Pillai <[email protected]>
drm/amd/display: more liberal vmin/vmax update for freesyncRoman Li <[email protected]>
drm/amd/display: Fix invalid context error in dml helperRuijing Dong <[email protected]>
drm/amdgpu/vcn: using separateVCN1_AON_SOCoffsetAlex Deucher <[email protected]>
drm/amdgpu: fix pm notifier handlingMatthew Brost <[email protected]>
drm/xe: Add page queue multiplierMaíra Canal <[email protected]>
drm/v3d: Add job to pending list if the reset was skippedAlex Deucher <[email protected]>
Revert "drm/amd: Stop evicting resources on APUs in suspend"David Lechner <[email protected]>
iio: pressure: mprls0025pa: usealigned_s64for timestampLuca Ceresoli <[email protected]>
iio: light: opt3001: fix deadlock due to concurrent flag accessSilvano Seva <[email protected]>
iio: imu:st_lsm6dsx: fix possible lockup inst_lsm6dsx_read_tagged_fifoSilvano Seva <[email protected]>
iio: imu:st_lsm6dsx: fix possible lockup inst_lsm6dsx_read_fifoDavid Lechner <[email protected]>
iio: imu:inv_mpu6050: align buffer for timestampZhang Lixu <[email protected]>
iio: hid-sensor-prox: Fix incorrect OFFSET calculationZhang Lixu <[email protected]>
iio: hid-sensor-prox: support multi-channel SCALE calculationZhang Lixu <[email protected]>
iio: hid-sensor-prox: Restore lost scale assignmentsDavid Lechner <[email protected]>
iio: chemical: pms7003: usealigned_s64for timestampDavid Lechner <[email protected]>
iio: chemical: sps30: usealigned_s64for timestampGabriel Shahrouzi <[email protected]>
iio: adis16201: Correct inclinometer channel resolutionSimon Xue <[email protected]>
iio: adc: rockchip: Fix clock initialization sequenceAngelo Dureghello <[email protected]>
iio: adc: ad7606: fix serial register accessJonathan Cameron <[email protected]>
iio: adc: ad7266: Fix potential timestamp alignment issue.Jonathan Cameron <[email protected]>
iio: adc: ad7768-1: Fix insufficient alignment of timestamp.Jens Axboe <[email protected]>
io_uring: ensure deferred completions are flushed for multishotNam Cao <[email protected]>
riscv: Fix kernel crash due toPR_SET_TAGGED_ADDR_CTRLWayne Lin <[email protected]>
drm/amd/display: Shift DMUB AUX reply command if necessaryMikhail Lobanov <[email protected]>
KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionSean Christopherson <[email protected]>
KVM: x86/mmu: Prevent installing hugepages when mem attributes are changingMadhavan Srinivasan <[email protected]>
selftests/mm: fix build break when compilingpkey_util.cNysal Jan K.A. <[email protected]>
selftests/mm: fix a build failure on powerpcFeng Tang <[email protected]>
selftests/mm:compaction_test: support platform with huge mount of memoryPeter Xu <[email protected]>
mm/userfaultfd: fix uninitialized output field for-EAGAINraceGavin Guo <[email protected]>
mm/huge_memory: fix dereferencing invalid pmd migration entryKees Cook <[email protected]>
mm: vmalloc: support more granularvrealloc()sizingPetr Vaněk <[email protected]>
mm: fixfolio_pte_batch()on XEN PVDave Hansen <[email protected]>
x86/mm: Eliminate window where TLB flushes may be inadvertently skippedGabriel Shahrouzi <[email protected]>
staging: axis-fifo: Correct handling oftx_fifo_depthfor size validationGabriel Shahrouzi <[email protected]>
staging: axis-fifo: Remove hardware resets for user errorsDave Stevenson <[email protected]>
staging: bcm2835-camera: Initialise dev inv4l2_devGabriel Shahrouzi <[email protected]>
staging: iio: adc: ad7816: Correct conditional logic for store modeNaman Jain <[email protected]>
uio_hv_generic: Fix sysfs creation path for ring bufferMiguel Ojeda <[email protected]>
rust: clean Rust 1.88.0's warning aboutclippy::disallowed_macrosconfigurationMiguel Ojeda <[email protected]>
objtool/rust: add one morenoreturnRust function for Rust 1.87.0Miguel Ojeda <[email protected]>
rust: clean Rust 1.88.0'sunnecessary_transmuteslintAditya Garg <[email protected]>
Input: synaptics - enable InterTouch on TUXEDO InfinityBook Pro 14 v5Dmitry Torokhov <[email protected]>
Input: synaptics - enable SMBus for HP Elitebook 850 G1Aditya Garg <[email protected]>
Input: synaptics - enable InterTouch on Dell Precision M3800Aditya Garg <[email protected]>
Input: synaptics - enable InterTouch on Dynabook Portege X30L-GManuel Fombuena <[email protected]>
Input: synaptics - enable InterTouch on Dynabook Portege X30-DVicki Pfau <[email protected]>
Input: xpad - fix two controller table valuesLode Willems <[email protected]>
Input: xpad - add support for 8BitDo Ultimate 2 Wireless ControllerVicki Pfau <[email protected]>
Input: xpad - fix Share button on Xbox One controllersGary Bisson <[email protected]>
Input: mtk-pmic-keys - fix possible null pointer dereferenceMikael Gonella-Bolduc <[email protected]>
Input: cyttsp5 - fix power control issue on wakeupHugo Villeneuve <[email protected]>
Input: cyttsp5 - ensure minimum reset pulse widthJakub Kicinski <[email protected]>
virtio-net: fix total qstat valuesJakub Kicinski <[email protected]>
net: export a helper for adding up queue statsAlexander Duyck <[email protected]>
fbnic: Do not allow mailbox to toggle to ready outsidefbnic_mbx_poll_tx_readyAlexander Duyck <[email protected]>
fbnic: Pullfbnic_fw_xmit_cap_msguse out of interrupt contextAlexander Duyck <[email protected]>
fbnic: Improve responsiveness offbnic_mbx_poll_tx_readyAlexander Duyck <[email protected]>
fbnic: Cleanup handling of completionsAlexander Duyck <[email protected]>
fbnic: Actuallyflush_txinstead of stalling outAlexander Duyck <[email protected]>
fbnic: Gate AXI read/write enabling on FW mailboxAlexander Duyck <[email protected]>
fbnic: Fix initialization of mailbox descriptor ringsJonas Gorski <[email protected]>
net: dsa: b53: do not set learning and unicast/multicast on upJonas Gorski <[email protected]>
net: dsa: b53: fix learning on VLAN unaware bridgesJonas Gorski <[email protected]>
net: dsa: b53: fix togglingvlan_filteringJonas Gorski <[email protected]>
net: dsa: b53: do not program vlans when vlan filtering is offJonas Gorski <[email protected]>
net: dsa: b53: do not allow to configure VLAN 0Jonas Gorski <[email protected]>
net: dsa: b53: always rejoin default untagged VLAN on bridge leaveJonas Gorski <[email protected]>
net: dsa: b53: fix VLAN ID for untagged vlan on bridge leaveJonas Gorski <[email protected]>
net: dsa: b53: fix flushing old pvid VLAN on pvid changeJonas Gorski <[email protected]>
net: dsa: b53: fix clearing PVID of a portJonas Gorski <[email protected]>
net: dsa: b53: keep CPU port always tagged againJonas Gorski <[email protected]>
net: dsa: b53: allow leaky reserved multicastPaul Chaignon <[email protected]>
bpf: Scrub packet onbpf_redirect_peerJozsef Kadlecsik <[email protected]>
netfilter: ipset: fix region locking in hash typesJulian Anastasov <[email protected]>
ipvs: fix uninit-value for saddr indo_output_route4Gao Xiang <[email protected]>
erofs: ensure the extra temporary copy is valid for shortened bvecsPrzemek Kitszel <[email protected]>
ice: use DSN instead of PCI BDF forice_adapterindexMichael-CY Lee <[email protected]>
wifi: mac80211: fix the type ofstatus_codefor negotiated TID to Link MappingOliver Hartkopp <[email protected]>
can: gw: fix RCU/BH usage incgw_create_job()Kelsey Maes <[email protected]>
can: mcp251xfd: fix TDC setting for low data bit ratesAntonios Salios <[email protected]>
can:m_can:m_can_class_allocate_dev(): initialize spin lock on device probeFrank Wunderlich <[email protected]>
net: ethernet:mtk_eth_soc: do not reset PSE when setting FEDaniel Golle <[email protected]>
net: ethernet:mtk_eth_soc: reset all TX queues on DMA freeGuillaume Nault <[email protected]>
gre: Fix again IPv6 link-local address generation.Jakub Kicinski <[email protected]>
virtio-net: freexsk_buffson error invirtnet_xsk_pool_enable()Jakub Kicinski <[email protected]>
virtio-net: don't re-enable refill work too early when NAPI is disabledCong Wang <[email protected]>
sch_htb: makehtb_deactivate()idempotentHeiko Carstens <[email protected]>
s390/entry: Fix last breaking event handling in case of stack corruptionWang Zhaolong <[email protected]>
ksmbd: fix memory leak inparse_lease_state()Eelco Chaudron <[email protected]>
openvswitch: Fix unsafe attribute parsing inoutput_userspace()Sean Heelan <[email protected]>
ksmbd: Fix UAF in__close_file_table_idsNorbert Szetei <[email protected]>
ksmbd: prevent out-of-bounds stream writes by validating *posNamjae Jeon <[email protected]>
ksmbd: prevent rename with empty stringMarc Kleine-Budde <[email protected]>
can:rockchip_canfd:rkcanfd_remove(): fix order of unregistration callsMarc Kleine-Budde <[email protected]>
can: mcp251xfd:mcp251xfd_remove(): fix order of unregistration callsNiklas Schnelle <[email protected]>
s390/pci: Fix duplicatepci_dev_put()indisable_slot()when PF has child VFsAlex Williamson <[email protected]>
vfio/pci: Align huge faults to orderVeerendranath Jakkam <[email protected]>
wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentationNiklas Schnelle <[email protected]>
s390/pci: Fix missing check forzpci_create_device()error returnMarc Kleine-Budde <[email protected]>
can: mcan:m_can_class_unregister(): fix order of unregistration callsCristian Marussi <[email protected]>
firmware:arm_scmi: Fix timeout checks on polling pathWojciech Dubowik <[email protected]>
arm64: dts: imx8mm-verdin: Linkreg_usdhc2_vqmmcto usdhc2Qu Wenruo <[email protected]>
Revert "btrfs: canonicalize the device path before adding it"Max Kellermann <[email protected]>
fs/erofs/fileio: callerofs_onlinefolio_split()afterbio_add_folio()Dan Carpenter <[email protected]>
dm: add missing unlock on indm_keyslot_evict()-------------
Diffstat:
.clippy.toml | 2 +- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 168 ++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 18 ++ Makefile | 4 +- arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 25 ++- arch/arm64/include/asm/cputype.h | 2 + arch/arm64/include/asm/insn.h | 1 + arch/arm64/include/asm/spectre.h | 3 + arch/arm64/kernel/cpufeature.c | 9 +- arch/arm64/kernel/proton-pack.c | 13 +- arch/arm64/kvm/mmu.c | 13 +- arch/arm64/lib/insn.c | 76 +++++--- arch/arm64/net/bpf_jit_comp.c | 57 +++++- arch/mips/include/asm/idle.h | 3 +- arch/mips/include/asm/ptrace.h | 3 +- arch/mips/kernel/genex.S | 63 +++--- arch/mips/kernel/idle.c | 7 - arch/riscv/kernel/process.c | 6 + arch/riscv/kernel/traps.c | 64 ++++--- arch/riscv/kernel/traps_misaligned.c | 17 ++ arch/s390/kernel/entry.S | 3 +- arch/s390/pci/pci_clp.c | 2 + arch/x86/Kconfig | 12 ++ arch/x86/entry/entry_64.S | 20 +- arch/x86/include/asm/alternative.h | 24 +++ arch/x86/include/asm/cpufeatures.h | 3 + arch/x86/include/asm/microcode.h | 2 + arch/x86/include/asm/msr-index.h | 8 + arch/x86/include/asm/nospec-branch.h | 10 + arch/x86/kernel/alternative.c | 195 ++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 176 ++++++++++++++++- arch/x86/kernel/cpu/common.c | 72 +++++-- arch/x86/kernel/cpu/microcode/amd.c | 6 +- arch/x86/kernel/cpu/microcode/core.c | 60 +++--- arch/x86/kernel/cpu/microcode/intel.c | 2 +- arch/x86/kernel/cpu/microcode/internal.h | 1 - arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/head32.c | 4 - arch/x86/kernel/module.c | 6 + arch/x86/kernel/static_call.c | 4 +- arch/x86/kernel/vmlinux.lds.S | 10 + arch/x86/kvm/mmu/mmu.c | 89 ++++++--- arch/x86/kvm/smm.c | 1 + arch/x86/kvm/svm/svm.c | 4 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 ++++ arch/x86/mm/tlb.c | 23 ++- arch/x86/net/bpf_jit_comp.c | 58 +++++- drivers/accel/ivpu/ivpu_hw.c | 2 +- drivers/accel/ivpu/ivpu_job.c | 90 ++++++--- drivers/base/cpu.c | 3 + drivers/block/loop.c | 43 ++++- drivers/bluetooth/btmtk.c | 10 - drivers/clocksource/i8253.c | 4 +- drivers/firmware/arm_scmi/driver.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 18 -- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 - drivers/gpu/drm/amd/amdgpu/hdp_v4_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/hdp_v5_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/hdp_v5_2.c | 12 +- drivers/gpu/drm/amd/amdgpu/hdp_v6_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/hdp_v7_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 3 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++- .../amd/display/dc/dml2/dml2_translation_helper.c | 14 +- drivers/gpu/drm/panel/panel-simple.c | 25 +-- drivers/gpu/drm/v3d/v3d_sched.c | 28 ++- drivers/gpu/drm/xe/tests/xe_mocs.c | 7 +- drivers/gpu/drm/xe/xe_gt_debugfs.c | 9 +- drivers/gpu/drm/xe/xe_gt_pagefault.c | 11 +- drivers/hv/hyperv_vmbus.h | 6 + drivers/hv/vmbus_drv.c | 100 +++++++++- drivers/iio/accel/adis16201.c | 4 +- drivers/iio/accel/adxl355_core.c | 2 +- drivers/iio/accel/adxl367.c | 10 +- drivers/iio/adc/ad7266.c | 2 +- drivers/iio/adc/ad7606_spi.c | 2 +- drivers/iio/adc/ad7768-1.c | 2 +- drivers/iio/adc/dln2-adc.c | 2 +- drivers/iio/adc/rockchip_saradc.c | 17 +- drivers/iio/chemical/pms7003.c | 5 +- drivers/iio/chemical/sps30.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 4 + drivers/iio/imu/bmi270/bmi270_core.c | 6 +- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 6 + drivers/iio/light/hid-sensor-prox.c | 22 ++- drivers/iio/light/opt3001.c | 5 +- drivers/iio/pressure/mprls0025pa.h | 17 +- drivers/iio/temperature/maxim_thermocouple.c | 2 +- drivers/input/joystick/xpad.c | 40 ++-- drivers/input/keyboard/mtk-pmic-keys.c | 4 +- drivers/input/mouse/synaptics.c | 5 + drivers/input/touchscreen/cyttsp5.c | 7 +- drivers/md/dm-table.c | 3 +- drivers/net/can/m_can/m_can.c | 3 +- drivers/net/can/rockchip/rockchip_canfd-core.c | 2 +- drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 42 +++- drivers/net/dsa/b53/b53_common.c | 213 +++++++++++++++------ drivers/net/dsa/b53/b53_priv.h | 3 + drivers/net/dsa/bcm_sf2.c | 1 + drivers/net/ethernet/intel/ice/ice_adapter.c | 47 ++--- drivers/net/ethernet/intel/ice/ice_adapter.h | 6 +- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 19 +- drivers/net/ethernet/meta/fbnic/fbnic_csr.h | 2 + drivers/net/ethernet/meta/fbnic/fbnic_fw.c | 197 +++++++++++-------- drivers/net/ethernet/meta/fbnic/fbnic_mac.c | 6 - drivers/net/virtio_net.c | 23 ++- drivers/nvme/host/core.c | 3 +- drivers/pci/hotplug/s390_pci_hpc.c | 1 - drivers/staging/axis-fifo/axis-fifo.c | 14 +- drivers/staging/iio/adc/ad7816.c | 2 +- .../vc04_services/bcm2835-camera/bcm2835-camera.c | 1 + drivers/uio/uio_hv_generic.c | 39 ++-- drivers/usb/cdns3/cdnsp-gadget.c | 31 +++ drivers/usb/cdns3/cdnsp-gadget.h | 6 + drivers/usb/cdns3/cdnsp-pci.c | 12 +- drivers/usb/cdns3/cdnsp-ring.c | 3 +- drivers/usb/cdns3/core.h | 3 + drivers/usb/class/usbtmc.c | 59 +++--- drivers/usb/dwc3/core.h | 4 + drivers/usb/dwc3/gadget.c | 60 +++--- drivers/usb/gadget/composite.c | 12 +- drivers/usb/gadget/function/f_ecm.c | 7 + drivers/usb/gadget/udc/tegra-xudc.c | 4 + drivers/usb/host/uhci-platform.c | 2 +- drivers/usb/host/xhci-dbgcap.c | 19 +- drivers/usb/host/xhci-dbgcap.h | 3 + drivers/usb/host/xhci-tegra.c | 3 + drivers/usb/misc/onboard_usb_dev.c | 10 +- drivers/usb/typec/tcpm/tcpm.c | 2 +- drivers/usb/typec/ucsi/displayport.c | 21 +- drivers/usb/typec/ucsi/ucsi.c | 34 ++++ drivers/usb/typec/ucsi/ucsi.h | 2 + drivers/vfio/pci/vfio_pci_core.c | 12 +- drivers/xen/swiotlb-xen.c | 1 + drivers/xen/xenbus/xenbus.h | 2 + drivers/xen/xenbus/xenbus_comms.c | 9 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- drivers/xen/xenbus/xenbus_xs.c | 18 +- fs/btrfs/volumes.c | 91 +-------- fs/erofs/fileio.c | 4 +- fs/erofs/zdata.c | 29 ++- fs/namespace.c | 3 +- fs/ocfs2/alloc.c | 1 + fs/ocfs2/journal.c | 80 +++++--- fs/ocfs2/journal.h | 1 + fs/ocfs2/ocfs2.h | 17 +- fs/ocfs2/quota_local.c | 9 +- fs/ocfs2/suballoc.c | 38 +++- fs/ocfs2/suballoc.h | 1 + fs/ocfs2/super.c | 3 + fs/smb/client/cached_dir.c | 10 +- fs/smb/server/oplock.c | 7 +- fs/smb/server/smb2pdu.c | 5 + fs/smb/server/vfs.c | 7 + fs/smb/server/vfs_cache.c | 33 +++- fs/userfaultfd.c | 28 ++- include/linux/cpu.h | 2 + include/linux/execmem.h | 3 + include/linux/hyperv.h | 6 + include/linux/ieee80211.h | 2 +- include/linux/module.h | 5 + include/linux/timekeeper_internal.h | 8 +- include/linux/vmalloc.h | 1 + include/net/netdev_queues.h | 6 + init/Kconfig | 3 + io_uring/io_uring.c | 58 +++--- io_uring/sqpoll.c | 2 +- kernel/params.c | 4 +- kernel/time/timekeeping.c | 50 ++++- kernel/time/vsyscall.c | 4 +- mm/huge_memory.c | 11 +- mm/internal.h | 27 ++- mm/memblock.c | 9 +- mm/page_alloc.c | 159 +++++++++------ mm/vmalloc.c | 31 ++- net/can/gw.c | 151 +++++++++------ net/core/filter.c | 1 + net/core/netdev-genl.c | 69 +++++-- net/ipv6/addrconf.c | 15 +- net/mac80211/mlme.c | 12 +- net/netfilter/ipset/ip_set_hash_gen.h | 2 +- net/netfilter/ipvs/ip_vs_xmit.c | 27 +-- net/openvswitch/actions.c | 3 +- net/sched/sch_htb.c | 15 +- net/wireless/scan.c | 2 +- rust/bindings/lib.rs | 1 + rust/kernel/alloc/kvec.rs | 3 + rust/kernel/list.rs | 3 + rust/kernel/str.rs | 46 ++--- rust/macros/module.rs | 19 +- rust/macros/paste.rs | 2 +- rust/macros/pinned_drop.rs | 3 +- rust/uapi/lib.rs | 1 + tools/objtool/check.c | 1 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/mm/compaction_test.c | 19 +- tools/testing/selftests/mm/pkey-powerpc.h | 14 +- tools/testing/selftests/mm/pkey_util.c | 1 + tools/testing/selftests/x86/bugs/Makefile | 3 + tools/testing/selftests/x86/bugs/common.py | 164 ++++++++++++++++ .../selftests/x86/bugs/its_indirect_alignment.py | 150 +++++++++++++++ .../testing/selftests/x86/bugs/its_permutations.py | 109 +++++++++++ .../selftests/x86/bugs/its_ret_alignment.py | 139 ++++++++++++++ tools/testing/selftests/x86/bugs/its_sysfs.py | 65 +++++++ 218 files changed, 3603 insertions(+), 1269 deletions(-)