6.1.11-rc1 review
Greg Kroah-Hartman
maintainerPATCH 133/208 iio: hid: fix the retval in gyro_3d_capture_sample
In reply to Greg Kroah-HartmanFrom: Dmitry Perchanov <[email protected]>
commit eb50cd5bfdac61627a5026566cf3b90ced7b141c upstream.
Return value should be zero for success. This was forgotten for timestamp feature. Verified on RealSense cameras.
--- drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 + 1 file changed, 1 insertion(+)
drivers/iio/gyro/hid-sensor-gyro-3d.c +1 -0
@@ -231,6 +231,7 @@ static int gyro_3d_capture_sample(struct gyro_state->timestamp =hid_sensor_convert_timestamp (&gyro_state->common_attributes, *(s64 *)raw_data); + ret =0 ;break ;default :break ;
Greg Kroah-Hartman
maintainerPATCH 134/208 iio: adc: xilinx-ams: fix devm_krealloc() return value check
In reply to Greg Kroah-HartmanFrom: Marco Pagani <[email protected]>
commit 6794ed0cfcc6ce737240eccc48b3e8190df36703 upstream.
The clang-analyzer reported a warning: "Value stored to 'ret' is never read".
Fix the return value check if devm_krealloc() fails to resize ams_channels.
--- drivers/iio/adc/xilinx-ams.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/xilinx-ams.c +1 -1
@@ -1329,7 +1329,7 @@ static int ams_parse_firmware(struct iio dev_channels =devm_krealloc (dev, ams_channels, dev_size,GFP_KERNEL );if (!dev_channels) - ret = -ENOMEM ; +return -ENOMEM ; indio_dev->channels = dev_channels; indio_dev->num_channels = num_channels;
Greg Kroah-Hartman
maintainerPATCH 135/208 iio: adc: berlin2-adc: Add missing of_node_put() in error path
In reply to Greg Kroah-HartmanFrom: Xiongfeng Wang <[email protected]>
commit cbd3a0153cd18a2cbef6bf3cf31bb406c3fc9f55 upstream.
of_get_parent() will return a device_node pointer with refcount incremented. We need to use of_node_put() on it when done. Add the missing of_node_put() in the error path of berlin2_adc_probe();
--- drivers/iio/adc/berlin2-adc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/iio/adc/berlin2-adc.c +3 -1
@@ -298,8 +298,10 @@ static int berlin2_adc_probe(struct platint ret; indio_dev =devm_iio_device_alloc (&pdev->dev,sizeof (*priv)); -if (!indio_dev) +if (!indio_dev) { +of_node_put (parent_np);return -ENOMEM ; + } priv =iio_priv (indio_dev);
Greg Kroah-Hartman
maintainerPATCH 136/208 iio: imx8qxp-adc: fix irq flood when call imx8qxp_adc_read_raw()
In reply to Greg Kroah-HartmanFrom: Frank Li <[email protected]>
commit 0fc3562a993c3dc41d1177b3983d9300d0db1d4d upstream.
irq flood happen when run
cat /sys/bus/iio/devices/iio:device0/in_voltage1_raw
imx8qxp_adc_read_raw()
{
...
enable irq
/* adc start */
writel(1, adc->regs + IMX8QXP_ADR_ADC_SWTRIG);
^^^^ trigger irq flood.
wait_for_completion_interruptible_timeout();
readl(adc->regs + IMX8QXP_ADR_ADC_RESFIFO);
^^^^ clear irq here.
...
}There is only FIFO watermark interrupt at this ADC controller. IRQ line will be assert until software read data from FIFO. So IRQ flood happen during wait_for_completion_interruptible_timeout().
Move FIFO read into irq handle to avoid irq flood.
--- drivers/iio/adc/imx8qxp-adc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/iio/adc/imx8qxp-adc.c +9 -2
@@ -86,6 +86,8 @@#define IMX8QXP_ADC_TIMEOUT msecs_to_jiffies(100) +#define IMX8QXP_ADC_MAX_FIFO_SIZE 16 +struct imx8qxp_adc {struct device *dev;void __iomem *regs;
@@ -95,6 +97,7 @@ struct imx8qxp_adc {/* Serialise ADC channel reads */ struct mutex lock;struct completion completion; +u32 fifo[IMX8QXP_ADC_MAX_FIFO_SIZE ]; };#define IMX8QXP_ADC_CHAN (_idx) { \
@@ -238,8 +241,7 @@ static int imx8qxp_adc_read_raw(struct iio_dev *indio_dev,return ret; } - *val =FIELD_GET (IMX8QXP_ADC_RESFIFO_VAL_MASK , -readl (adc->regs +IMX8QXP_ADR_ADC_RESFIFO )); + *val = adc->fifo[0 ];mutex_unlock (&adc->lock);return IIO_VAL_INT ;
@@ -265,10 +267,15 @@ static irqreturn_t imx8qxp_adc_isr(int irq, void *dev_id) {struct imx8qxp_adc *adc = dev_id;u32 fifo_count; +int i; fifo_count =FIELD_GET (IMX8QXP_ADC_FCTRL_FCOUNT_MASK ,readl (adc->regs +IMX8QXP_ADR_ADC_FCTRL )); +for (i =0 ; i < fifo_count; i++) + adc->fifo[i] =FIELD_GET (IMX8QXP_ADC_RESFIFO_VAL_MASK , +readl_relaxed (adc->regs +IMX8QXP_ADR_ADC_RESFIFO )); +if (fifo_count)complete (&adc->completion);
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 137/208 iio:adc:twl6030: Enable measurements of VUSB, VBAT and others
In reply to Greg Kroah-HartmanFrom: Andreas Kemnade <[email protected]>
commit f804bd0dc28683a93a60f271aaefb2fc5b0853dd upstream.
Some inputs need to be wired up to produce proper measurements, without this change only near zero values are reported.
--- drivers/iio/adc/twl6030-gpadc.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
drivers/iio/adc/twl6030-gpadc.c +32 -0
@@ -57,6 +57,18 @@#define TWL6030_GPADCS BIT(1)#define TWL6030_GPADCR BIT(0) +#define USB_VBUS_CTRL_SET 0x04 +#define USB_ID_CTRL_SET 0x06 + +#define TWL6030_MISC1 0xE4 +#define VBUS_MEAS 0x01 +#define ID_MEAS 0x01 + +#define VAC_MEAS 0x04 +#define VBAT_MEAS 0x02 +#define BB_MEAS 0x01 + +/** * struct twl6030_chnl_calib - channel calibration * @gain: slope coefficient for ideal curve
@@ -927,6 +939,26 @@ static int twl6030_gpadc_probe(struct plreturn ret; } + ret =twl_i2c_write_u8 (TWL_MODULE_USB ,VBUS_MEAS ,USB_VBUS_CTRL_SET ); +if (ret <0 ) { +dev_err (dev,"failed to wire up inputs\n" ); +return ret; + } + + ret =twl_i2c_write_u8 (TWL_MODULE_USB ,ID_MEAS ,USB_ID_CTRL_SET ); +if (ret <0 ) { +dev_err (dev,"failed to wire up inputs\n" ); +return ret; + } + + ret =twl_i2c_write_u8 (TWL6030_MODULE_ID0 , +VBAT_MEAS |BB_MEAS |BB_MEAS , +TWL6030_MISC1 ); +if (ret <0 ) { +dev_err (dev,"failed to wire up inputs\n" ); +return ret; + } + indio_dev->name =DRIVER_NAME ; indio_dev->info = &twl6030_gpadc_iio_info; indio_dev->modes =INDIO_DIRECT_MODE ;
Greg Kroah-Hartman
maintainerPATCH 138/208 iio: light: cm32181: Fix PM support on system with 2 I2C resources
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit ee3c5b644a0fdcfed27515a39fb2dd3a016704c1 upstream.
Commit c1e62062ff54 ("iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resources") creates a second client for the actual I2C address, but the "struct device" passed to PM ops is the first I2C client that can't talk to the sensor.
That means the I2C transfers in both suspend and resume routines can fail and blocking the whole suspend process.
Instead of using the first client for I2C transfer, use the I2C client stored in the cm32181 private struct so the PM ops can get the correct I2C client to really talk to the sensor device.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2152281
--- drivers/iio/light/cm32181.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/iio/light/cm32181.c +5 -4
@@ -440,6 +440,8 @@ static int cm32181_probe(struct i2c_client *client)if (!indio_dev)return -ENOMEM ; +i2c_set_clientdata (client, indio_dev); +/* * Some ACPI systems list 2 I2C resources for the CM3218 sensor, the * SMBus Alert Response Address (ARA, 0x0c) and the actual I2C address.
@@ -460,8 +462,6 @@ static int cm32181_probe(struct i2c_client *client)return PTR_ERR (client); } -i2c_set_clientdata (client, indio_dev); - cm32181 =iio_priv (indio_dev); cm32181->client = client; cm32181->dev = dev;
@@ -490,7 +490,8 @@ static int cm32181_probe(struct i2c_client *client)static int cm32181_suspend (struct device *dev) { -struct i2c_client *client =to_i2c_client (dev); +struct cm32181_chip *cm32181 =iio_priv (dev_get_drvdata (dev)); +struct i2c_client *client = cm32181->client;return i2c_smbus_write_word_data (client,CM32181_REG_ADDR_CMD ,CM32181_CMD_ALS_DISABLE );
@@ -498,8 +499,8 @@ static int cm32181_suspend(struct device *dev)static int cm32181_resume (struct device *dev) { -struct i2c_client *client =to_i2c_client (dev);struct cm32181_chip *cm32181 =iio_priv (dev_get_drvdata (dev)); +struct i2c_client *client = cm32181->client;return i2c_smbus_write_word_data (client,CM32181_REG_ADDR_CMD , cm32181->conf_regs[CM32181_REG_ADDR_CMD ]);
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 139/208 iio: imu: fxos8700: fix ACCEL measurement range selection
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit 9d61c1820598a5ea474576ed55318a6dadee37ed upstream.
When device is in active mode, it fails to set an ACCEL full-scale range(2g/4g/8g) in FXOS8700_XYZ_DATA_CFG. This is not align with the datasheet, but it is a fxos8700 chip behavior.
Keep the device in standby mode before setting ACCEL full-scale range into FXOS8700_XYZ_DATA_CFG in chip initialization phase and setting scale phase.
--- drivers/iio/imu/fxos8700_core.c | 41 +++++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 7 deletions(-)
drivers/iio/imu/fxos8700_core.c +34 -7
@@ -345,7 +345,8 @@ static int fxos8700_set_active_mode(strustatic int fxos8700_set_scale (struct fxos8700_data *data,enum fxos8700_sensor t,int uscale) { -int i; +int i, ret, val; +bool active_mode;static const int scale_num =ARRAY_SIZE (fxos8700_accel_scale);struct device *dev =regmap_get_device (data->regmap);
@@ -354,6 +355,25 @@ static int fxos8700_set_scale(struct fxoreturn -EINVAL ; } +/* +* When device is in active mode, it failed to set an ACCEL +* full-scale range(2g/4g/8g) in FXOS8700_XYZ_DATA_CFG. +* This is not align with the datasheet, but it is a fxos8700 +* chip behavier. Set the device in standby mode before setting +* an ACCEL full-scale range. +*/ + ret =regmap_read (data->regmap,FXOS8700_CTRL_REG1 , &val); +if (ret) +return ret; + + active_mode = val &FXOS8700_ACTIVE ; +if (active_mode) { + ret =regmap_write (data->regmap,FXOS8700_CTRL_REG1 , + val & ~FXOS8700_ACTIVE ); +if (ret) +return ret; + } +for (i =0 ; i < scale_num; i++)if (fxos8700_accel_scale[i].uscale == uscale)break ;
@@ -361,8 +381,12 @@ static int fxos8700_set_scale(struct fxoif (i == scale_num)return -EINVAL ; -return regmap_write (data->regmap,FXOS8700_XYZ_DATA_CFG , + ret =regmap_write (data->regmap,FXOS8700_XYZ_DATA_CFG , fxos8700_accel_scale[i].bits); +if (ret) +return ret; +return regmap_write (data->regmap,FXOS8700_CTRL_REG1 , + active_mode); } static int fxos8700_get_scale(struct fxos8700_data *data,
@@ -592,14 +616,17 @@ static int fxos8700_chip_init(struct fxoif (ret)return ret; -/* Max ODR (800Hz individual or 400Hz hybrid), active mode */ - ret =regmap_write (data->regmap,FXOS8700_CTRL_REG1 , -FXOS8700_CTRL_ODR_MAX |FXOS8700_ACTIVE ); +/* +* Set max full-scale range (+/-8G) for ACCEL sensor in chip +* initialization then activate the device. +*/ + ret =regmap_write (data->regmap,FXOS8700_XYZ_DATA_CFG ,MODE_8G );if (ret)return ret; -/* Set for max full-scale range (+/-8G) */ -return regmap_write (data->regmap,FXOS8700_XYZ_DATA_CFG ,MODE_8G ); +/* Max ODR (800Hz individual or 400Hz hybrid), active mode */ +return regmap_write (data->regmap,FXOS8700_CTRL_REG1 , +FXOS8700_CTRL_ODR_MAX |FXOS8700_ACTIVE ); }static void fxos8700_chip_uninit (void *data)
Greg Kroah-Hartman
maintainerPATCH 140/208 iio: imu: fxos8700: fix incomplete ACCEL and MAGN channels readback
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit 37a94d86d7050665d6d01378b2c916c28e454f10 upstream.
The length of ACCEL and MAGN 3-axis channels output data is 6 byte individually. However block only read 3 bytes data into buffer from ACCEL or MAGN output data registers every time. It causes an incomplete ACCEL and MAGN channels readback.
Set correct value count for regmap_bulk_read to get 6 bytes ACCEL and MAGN channels readback.
--- drivers/iio/imu/fxos8700_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/imu/fxos8700_core.c +1 -1
@@ -425,7 +425,7 @@ static int fxos8700_get_data(struct fxos/* Block read 6 bytes of device output registers to avoid data loss */ ret =regmap_bulk_read (data->regmap, base, data->buf, -FXOS8700_DATA_BUF_SIZE ); +sizeof (data->buf));if (ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 141/208 iio: imu: fxos8700: fix IMU data bits returned to user space
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit a53f945879c0cb9de3a4c05a665f5157884b5208 upstream.
ACCEL output data registers contain the X-axis, Y-axis, and Z-axis 14-bit left-justified sample data and MAGN output data registers contain the X-axis, Y-axis, and Z-axis 16-bit sample data. The ACCEL raw register output data should be divided by 4 before sent to userspace.
Apply a 2 bits signed right shift to the raw data from ACCEL output data register but keep that from MAGN sensor as the origin.
--- drivers/iio/imu/fxos8700_core.c | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-)
drivers/iio/imu/fxos8700_core.c +27 -1
@@ -418,6 +418,7 @@ static int fxos8700_get_data(struct fxos int axis, int *val) { u8 base, reg; +s16 tmp;int ret;enum fxos8700_sensor type =fxos8700_to_sensor (chan_type);
@@ -432,8 +433,33 @@ static int fxos8700_get_data(struct fxos/* Convert axis to buffer index */ reg = axis -IIO_MOD_X ; +/* +* Convert to native endianness. The accel data and magn data +* are signed, so a forced type conversion is needed. +*/ + tmp =be16_to_cpu (data->buf[reg]); + +/* +* ACCEL output data registers contain the X-axis, Y-axis, and Z-axis +* 14-bit left-justified sample data and MAGN output data registers +* contain the X-axis, Y-axis, and Z-axis 16-bit sample data. Apply +* a signed 2 bits right shift to the readback raw data from ACCEL +* output data register and keep that from MAGN sensor as the origin. +* Value should be extended to 32 bit. +*/ +switch (chan_type) { +case IIO_ACCEL : + tmp = tmp >>2 ; +break ; +case IIO_MAGN : +/* Nothing to do */ +break ; +default : +return -EINVAL ; + } +/* Convert to native endianness */ - *val =sign_extend32 (be16_to_cpu (data->buf[reg]),15 ); + *val =sign_extend32 (tmp,15 );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 142/208 iio: imu: fxos8700: fix map label of channel type to MAGN sensor
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit 429e1e8ec696e0e7a0742904e3dc2f83b7b23dfb upstream.
FXOS8700 is an IMU sensor with ACCEL sensor and MAGN sensor. Sensor type is indexed by corresponding channel type in a switch. IIO_ANGL_VEL channel type mapped to MAGN sensor has caused confusion.
Fix the mapping label of "IIO_MAGN" channel type instead of "IIO_ANGL_VEL" channel type to MAGN sensor.
--- drivers/iio/imu/fxos8700_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/imu/fxos8700_core.c +1 -1
@@ -320,7 +320,7 @@ static enum fxos8700_sensor fxos8700_to_switch (iio_type) {case IIO_ACCEL :return FXOS8700_ACCEL ; -case IIO_ANGL_VEL : +case IIO_MAGN :return FXOS8700_MAGN ;default :return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 143/208 iio: imu: fxos8700: fix swapped ACCEL and MAGN channels readback
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit c68b44bc7d9b1469774a1c985ee71d2cbc5ebef5 upstream.
Because ACCEL and MAGN channels data register base address is swapped the accelerometer and magnetometer channels readback is swapped.
--- drivers/iio/imu/fxos8700_core.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/iio/imu/fxos8700_core.c +15 -2
@@ -420,9 +420,22 @@ static int fxos8700_get_data(struct fxosu8 base, reg;s16 tmp;int ret; -enum fxos8700_sensor type =fxos8700_to_sensor (chan_type); - base = type ?FXOS8700_OUT_X_MSB :FXOS8700_M_OUT_X_MSB ; +/* +* Different register base addresses varies with channel types. +* This bug hasn't been noticed before because using an enum is +* really hard to read. Use an a switch statement to take over that. +*/ +switch (chan_type) { +case IIO_ACCEL : + base =FXOS8700_OUT_X_MSB ; +break ; +case IIO_MAGN : + base =FXOS8700_M_OUT_X_MSB ; +break ; +default : +return -EINVAL ; + }/* Block read 6 bytes of device output registers to avoid data loss */ ret = regmap_bulk_read(data->regmap, base, data->buf,
Greg Kroah-Hartman
maintainerPATCH 144/208 iio: imu: fxos8700: fix incorrect ODR mode readback
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit 78ad6864e9e012cdba7c353d044d21ffcfd5f34b upstream.
The absence of a correct offset leads an incorrect ODR mode readback after use a hexadecimal number to mark the value from FXOS8700_CTRL_REG1.
Get ODR mode by field mask and FIELD_GET clearly and conveniently. And attach other additional fix for keeping the original code logic and a good readability.
--- drivers/iio/imu/fxos8700_core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/iio/imu/fxos8700_core.c +6 -6
@@ -10,6 +10,7 @@#include <linux/regmap.h> #include <linux/acpi.h> #include <linux/bitops.h> +#include <linux/bitfield.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h>
@@ -144,9 +145,9 @@#define FXOS8700_NVM_DATA_BNK0 0xa7/* Bit definitions for FXOS8700_CTRL_REG1 */ -#define FXOS8700_CTRL_ODR_MSK 0x38#define FXOS8700_CTRL_ODR_MAX 0x00#define FXOS8700_CTRL_ODR_MIN GENMASK(4, 3) +#define FXOS8700_CTRL_ODR_MSK GENMASK(5, 3)/* Bit definitions for FXOS8700_M_CTRL_REG1 */ #define FXOS8700_HMS_MASK GENMASK(1, 0)
@@ -508,10 +509,9 @@ static int fxos8700_set_odr(struct fxos8if (i >= odr_num)return -EINVAL ; -return regmap_update_bits (data->regmap, -FXOS8700_CTRL_REG1 , -FXOS8700_CTRL_ODR_MSK +FXOS8700_ACTIVE , - fxos8700_odr[i].bits <<3 | active_mode); + val &= ~FXOS8700_CTRL_ODR_MSK ; + val |=FIELD_PREP (FXOS8700_CTRL_ODR_MSK , fxos8700_odr[i].bits) |FXOS8700_ACTIVE ; +return regmap_write (data->regmap,FXOS8700_CTRL_REG1 , val); } static int fxos8700_get_odr(struct fxos8700_data *data, enum fxos8700_sensor t,
@@ -524,7 +524,7 @@ static int fxos8700_get_odr(struct fxos8if (ret)return ret; - val &=FXOS8700_CTRL_ODR_MSK ; + val =FIELD_GET (FXOS8700_CTRL_ODR_MSK , val);for (i =0 ; i < odr_num; i++)if (val == fxos8700_odr[i].bits)
Greg Kroah-Hartman
maintainerPATCH 145/208 iio: imu: fxos8700: fix failed initialization ODR mode assignment
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit eb6d8f8705bc19141bac81d8161461f9e256948a upstream.
The absence of correct offset leads a failed initialization ODR mode assignment.
Select MAX ODR mode as the initialization ODR mode by field mask and FIELD_PREP.
--- drivers/iio/imu/fxos8700_core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/imu/fxos8700_core.c +4 -2
@@ -664,8 +664,10 @@ static int fxos8700_chip_init(struct fxoreturn ret;/* Max ODR (800Hz individual or 400Hz hybrid), active mode */ -return regmap_write (data->regmap,FXOS8700_CTRL_REG1 , -FXOS8700_CTRL_ODR_MAX |FXOS8700_ACTIVE ); +return regmap_update_bits (data->regmap,FXOS8700_CTRL_REG1 , +FXOS8700_CTRL_ODR_MSK |FXOS8700_ACTIVE , +FIELD_PREP (FXOS8700_CTRL_ODR_MSK ,FXOS8700_CTRL_ODR_MAX ) | +FXOS8700_ACTIVE ); }static void fxos8700_chip_uninit (void *data)
Greg Kroah-Hartman
maintainerPATCH 146/208 iio: imu: fxos8700: remove definition FXOS8700_CTRL_ODR_MIN
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit ff5e2cd92ffda9a25ffa2cbdb3a0cf17650172a6 upstream.
FXOS8700_CTRL_ODR_MIN is not used but value is probably wrong.
Remove it for a good readability.
--- drivers/iio/imu/fxos8700_core.c | 1 - 1 file changed, 1 deletion(-)
drivers/iio/imu/fxos8700_core.c +0 -1
@@ -146,7 +146,6 @@/* Bit definitions for FXOS8700_CTRL_REG1 */ #define FXOS8700_CTRL_ODR_MAX 0x00 -#define FXOS8700_CTRL_ODR_MIN GENMASK(4, 3)#define FXOS8700_CTRL_ODR_MSK GENMASK(5, 3)/* Bit definitions for FXOS8700_M_CTRL_REG1 */
Greg Kroah-Hartman
maintainerPATCH 147/208 iio: imu: fxos8700: fix MAGN sensor scale and unit
In reply to Greg Kroah-HartmanFrom: Carlos Song <[email protected]>
commit 2acd031347f645871959a799238a7caf6803aa18 upstream.
+/-1200uT is a MAGN sensor full measurement range. Magnetometer scale is the magnetic sensitivity parameter. It is referenced as 0.1uT according to datasheet and magnetometer channel unit is Gauss in sysfs-bus-iio documentation. Gauss and uTesla unit conversion relationship as follows: 0.1uT = 0.001Gs.
Set magnetometer scale and available magnetometer scale as fixed 0.001Gs.
--- drivers/iio/imu/fxos8700_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iio/imu/fxos8700_core.c +3 -3
@@ -351,7 +351,7 @@ static int fxos8700_set_scale(struct fxostruct device *dev =regmap_get_device (data->regmap);if (t ==FXOS8700_MAGN ) { -dev_err (dev,"Magnetometer scale is locked at 1200uT\n" ); +dev_err (dev,"Magnetometer scale is locked at 0.001Gs\n" );return -EINVAL ; }
@@ -396,7 +396,7 @@ static int fxos8700_get_scale(struct fxostatic const int scale_num =ARRAY_SIZE (fxos8700_accel_scale);if (t ==FXOS8700_MAGN ) { - *uscale =1200 ;/* Magnetometer is locked at 1200uT */ + *uscale =1000 ;/* Magnetometer is locked at 0.001Gs */ return 0 ; }
@@ -588,7 +588,7 @@ static IIO_CONST_ATTR(in_accel_sampling_ static IIO_CONST_ATTR(in_magn_sampling_frequency_available, "1.5625 6.25 12.5 50 100 200 400 800"); static IIO_CONST_ATTR(in_accel_scale_available, "0.000244 0.000488 0.000976"); -static IIO_CONST_ATTR(in_magn_scale_available, "0.000001200"); +static IIO_CONST_ATTR(in_magn_scale_available, "0.001000");static struct attribute *fxos8700_attrs[] = { &iio_const_attr_in_accel_sampling_frequency_available.dev_attr.attr,
Greg Kroah-Hartman
maintainerPATCH 148/208 nvmem: brcm_nvram: Add check for kzalloc
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
commit b0576ade3aaf24b376ea1a4406ae138e2a22b0c0 upstream.
Add the check for the return value of kzalloc in order to avoid NULL pointer dereference.
--- drivers/nvmem/brcm_nvram.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/nvmem/brcm_nvram.c +3 -0
@@ -97,6 +97,9 @@ static int brcm_nvram_parse(struct brcm_ len =le32_to_cpu (header.len); data =kzalloc (len,GFP_KERNEL ); +if (!data) +return -ENOMEM ; +memcpy_fromio (data, priv->base, len); data[len -1 ] ='\0' ;
Greg Kroah-Hartman
maintainerPATCH 149/208 nvmem: sunxi_sid: Always use 32-bit MMIO reads
In reply to Greg Kroah-HartmanFrom: Samuel Holland <[email protected]>
commit c151d5ed8e8fe0474bd61dce7f2076ca5916c683 upstream.
The SID SRAM on at least some SoCs (A64 and D1) returns different values when read with bus cycles narrower than 32 bits. This is not immediately obvious, because memcpy_fromio() uses word-size accesses as long as enough data is being copied.
The vendor driver always uses 32-bit MMIO reads, so do the same here. This is faster than the register-based method, which is currently used as a workaround on A64. And it fixes the values returned on D1, where the SRAM method was being used.
The special case for the last word is needed to maintain .word_size == 1 for sysfs ABI compatibility, as noted previously in commit de2a3eaea552 ("nvmem: sunxi_sid: Optimize register read-out method").
--- drivers/nvmem/sunxi_sid.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/nvmem/sunxi_sid.c +14 -1
@@ -41,8 +41,21 @@ static int sunxi_sid_read(void *context, unsigned int offset, void *val, size_t bytes) {struct sunxi_sid *sid = context; +u32 word; + +/* .stride = 4 so offset is guaranteed to be aligned */ +__ioread32_copy (val, sid->base + sid->value_offset + offset, bytes /4 ); -memcpy_fromio (val, sid->base + sid->value_offset + offset, bytes); + val +=round_down (bytes,4 ); + offset +=round_down (bytes,4 ); + bytes = bytes %4 ; + +if (!bytes) +return 0 ; + +/* Handle any trailing bytes */ + word =readl_relaxed (sid->base + sid->value_offset + offset); +memcpy (val, &word, bytes);return 0 ; }
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 150/208 nvmem: qcom-spmi-sdam: fix module autoloading
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 1ca7fca349316231bbaa68d16f819a08d683c5a7 upstream.
Add the missing module device table so that the driver can be autoloaded when built as a module.
--- drivers/nvmem/qcom-spmi-sdam.c | 1 + 1 file changed, 1 insertion(+)
drivers/nvmem/qcom-spmi-sdam.c +1 -0
@@ -166,6 +166,7 @@ static const struct of_device_id sdam_match_table[] = { { .compatible = "qcom,spmi-sdam" }, {}, }; +MODULE_DEVICE_TABLE (of, sdam_match_table);static struct platform_driver sdam_driver = { .driver = {
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 151/208 parisc: Fix return code of pdc_iodc_print()
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 5d1335dabb3c493a3d6d5b233953b6ac7b6c1ff2 upstream.
There is an off-by-one if the printed string includes a new-line char.
--- arch/parisc/kernel/firmware.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/parisc/kernel/firmware.c +3 -2
@@ -1303,7 +1303,7 @@ static char iodc_dbuf[4096] __page_align*/ int pdc_iodc_print (const unsigned char *str,unsigned count) { -unsigned int i; +unsigned int i, found =0 ;unsigned long flags; count = min_t(unsigned int, count, sizeof(iodc_dbuf));
@@ -1315,6 +1315,7 @@ int pdc_iodc_print(const unsigned char * iodc_dbuf[i+0 ] ='\r' ; iodc_dbuf[i+1 ] ='\n' ; i +=2 ; + found =1 ; goto print;default : iodc_dbuf[i] = str[i];
@@ -1330,7 +1331,7 @@ print: __pa(pdc_result), 0, __pa(iodc_dbuf), i, 0);spin_unlock_irqrestore (&pdc_lock, flags); -return i; +return i - found; }#if !defined(BOOTLOADER )
Greg Kroah-Hartman
maintainerPATCH 152/208 parisc: Replace hardcoded value with PRIV_USER constant in ptrace.c
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 3f0c17809a098d3f0c1ec83f1fb3ca61638d3dcd upstream.
Prefer usage of the PRIV_USER constant over the hard-coded value to set the lowest 2 bits for the userspace privilege.
--- arch/parisc/kernel/ptrace.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/parisc/kernel/ptrace.c +3 -3
@@ -166,7 +166,7 @@ long arch_ptrace(struct task_struct *chi addr >= sizeof(struct pt_regs))break ;if (addr ==PT_IAOQ0 || addr ==PT_IAOQ1 ) { - data |=3 ;/* ensure userspace privilege */ + data |=PRIV_USER ;/* ensure userspace privilege */ } if ((addr >= PT_GR1 && addr <= PT_GR31) || addr == PT_IAOQ0 || addr == PT_IAOQ1 ||
@@ -285,7 +285,7 @@ long compat_arch_ptrace(struct task_struif (addr >=sizeof (struct pt_regs ))break ;if (addr ==PT_IAOQ0 +4 || addr ==PT_IAOQ1 +4 ) { - data |=3 ;/* ensure userspace privilege */ + data |=PRIV_USER ;/* ensure userspace privilege */ }if (addr >=PT_FR0 && addr <=PT_FR31 +4 ) {/* Special case, fp regs are 64 bits anyway */
@@ -483,7 +483,7 @@ static void set_reg(struct pt_regs *regscase RI (iaoq[0 ]):case RI (iaoq[1 ]):/* set 2 lowest bits to ensure userspace privilege: */ - regs->iaoq[num -RI (iaoq[0 ])] = val |3 ; + regs->iaoq[num -RI (iaoq[0 ])] = val |PRIV_USER ;return ;case RI (sar): regs->sar = val;return ;
Greg Kroah-Hartman
maintainerPATCH 153/208 parisc: Wire up PTRACE_GETREGS/PTRACE_SETREGS for compat case
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 316f1f42b5cc1d95124c1f0387c867c1ba7b6d0e upstream.
Wire up the missing ptrace requests PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS and PTRACE_SETFPREGS when running 32-bit applications on 64-bit kernels.
--- arch/parisc/kernel/ptrace.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
arch/parisc/kernel/ptrace.c +13 -2
@@ -126,6 +126,12 @@ long arch_ptrace(struct task_struct *chiunsigned long tmp;long ret = -EIO ; +unsigned long user_regs_struct_size =sizeof (struct user_regs_struct ); +#ifdef CONFIG_64BIT +if (is_compat_task ()) + user_regs_struct_size /=2 ; +#endif +switch (request) {/* Read the word at location addr in the USER area. For ptraced
@@ -181,14 +187,14 @@ long arch_ptrace(struct task_struct *chireturn copy_regset_to_user (child,task_user_regset_view (current),REGSET_GENERAL , -0 ,sizeof (struct user_regs_struct ), +0 , user_regs_struct_size, datap);case PTRACE_SETREGS :/* Set all gp regs in the child. */ return copy_regset_from_user (child,task_user_regset_view (current),REGSET_GENERAL , -0 ,sizeof (struct user_regs_struct ), +0 , user_regs_struct_size, datap);case PTRACE_GETFPREGS :/* Get the child FPU state. */
@@ -302,6 +308,11 @@ long compat_arch_ptrace(struct task_stru } }break ; +case PTRACE_GETREGS : +case PTRACE_SETREGS : +case PTRACE_GETFPREGS : +case PTRACE_SETFPREGS : +return arch_ptrace (child, request, addr, data);default : ret =compat_ptrace_request (child, request, addr, data);
Greg Kroah-Hartman
maintainerPATCH 154/208 riscv: disable generation of unwind tables
In reply to Greg Kroah-HartmanFrom: Andreas Schwab <[email protected]>
commit 2f394c0e7d1129a35156e492bc8f445fb20f43ac upstream.
GCC 13 will enable -fasynchronous-unwind-tables by default on riscv. In the kernel, we don't have any use for unwind tables yet, so disable them. More importantly, the .eh_frame section brings relocations (R_RISC_32_PCREL, R_RISCV_SET{6,8,16}, R_RISCV_SUB{6,8,16}) into modules that we are not prepared to handle.
--- arch/riscv/Makefile | 3 +++ 1 file changed, 3 insertions(+)
arch/riscv/Makefile +3 -0
@@ -80,6 +80,9 @@ ifeq ($(CONFIG_PERF_EVENTS),y) KBUILD_CFLAGS += -fno-omit-frame-pointer endif +# Avoid generating .eh_frame sections. +KBUILD_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables + KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax) KBUILD_AFLAGS_MODULE += $(call as-option,-Wa$(comma)-mno-relax)
Greg Kroah-Hartman
maintainerPATCH 155/208 Revert "mm: kmemleak: alloc gray object for reserved region with direct map"
In reply to Greg Kroah-HartmanFrom: Isaac J. Manjarres <[email protected]>
commit 8ef852f1cb426a5812aee700d3b4297aaa426acc upstream.
This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.
Kmemleak operates by periodically scanning memory regions for pointers to allocated memory blocks to determine if they are leaked or not. However, reserved memory regions can be used for DMA transactions between a device and a CPU, and thus, wouldn't contain pointers to allocated memory blocks, making them inappropriate for kmemleak to scan. Thus, revert this commit.
--- drivers/of/fdt.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/of/fdt.c +1 -5
@@ -26,7 +26,6 @@#include <linux/serial_core.h> #include <linux/sysfs.h> #include <linux/random.h> -#include <linux/kmemleak.h> #include <asm/setup.h> /* for COMMAND_LINE_SIZE */ #include <asm/page.h>
@@ -525,12 +524,9 @@ static int __init __reserved_mem_reserve_reg(unsigned long node, size =dt_mem_next_cell (dt_root_size_cells, &prop);if (size && -early_init_dt_reserve_memory (base, size, nomap) ==0 ) { +early_init_dt_reserve_memory (base, size, nomap) ==0 )pr_debug ("Reserved memory: reserved region for node '%s': base %pa, size %lu MiB\n" , uname, &base, (unsigned long )(size /SZ_1M )); -if (!nomap) -kmemleak_alloc_phys (base, size,0 ); - }else pr_err ("Reserved memory: failed to reserve memory for node '%s': base %pa, size %lu MiB\n" , uname, &base, (unsigned long )(size /SZ_1M ));
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 156/208 mm: multi-gen LRU: fix crash during cgroup migration
In reply to Greg Kroah-HartmanFrom: Yu Zhao <[email protected]>
commit de08eaa6156405f2e9369f06ba5afae0e4ab3b62 upstream.
lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself. This isn't true for the following scenario:
CPU 1 CPU 2
clone()
cgroup_can_fork()
cgroup_procs_write()
cgroup_post_fork()
task_lock()
lru_gen_migrate_mm()
task_unlock()
task_lock()
lru_gen_add_mm()
task_unlock()And when the above happens, kernel crashes because of linked list corruption (mm_struct->lru_gen.list).
--- mm/vmscan.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/vmscan.c +4 -1
@@ -3290,13 +3290,16 @@ void lru_gen_migrate_mm(struct mm_structif (mem_cgroup_disabled ())return ; +/* migration can happen before addition */ +if (!mm->lru_gen.memcg) +return ; +rcu_read_lock (); memcg =mem_cgroup_from_task (task);rcu_read_unlock ();if (memcg == mm->lru_gen.memcg)return ; -VM_WARN_ON_ONCE (!mm->lru_gen.memcg);VM_WARN_ON_ONCE (list_empty (&mm->lru_gen.list));lru_gen_del_mm (mm);
Greg Kroah-Hartman
maintainerPATCH 157/208 mm: hugetlb: proc: check for hugetlb shared PMD in /proc/PID/smaps
In reply to Greg Kroah-HartmanFrom: Mike Kravetz <[email protected]>
commit 3489dbb696d25602aea8c3e669a6d43b76bd5358 upstream.
Patch series "Fixes for hugetlb mapcount at most 1 for shared PMDs".
This issue of mapcount in hugetlb pages referenced by shared PMDs was discussed in [1]. The following two patches address user visible behavior caused by this issue.
[1] https://lore.kernel.org/linux-mm/Y9BF+OCdWnCSilEu@monkey/
This patch (of 2):
A hugetlb page will have a mapcount of 1 if mapped by multiple processes via a shared PMD. This is because only the first process increases the map count, and subsequent processes just add the shared PMD page to their page table.
page_mapcount is being used to decide if a hugetlb page is shared or private in /proc/PID/smaps. Pages referenced via a shared PMD were incorrectly being counted as private.
To fix, check for a shared PMD if mapcount is 1. If a shared PMD is found count the hugetlb page as shared. A new helper to check for a shared PMD is added.
--- fs/proc/task_mmu.c | 4 +--- include/linux/hugetlb.h | 13 +++++++++++++ 2 files changed, 14 insertions(+), 3 deletions(-)
fs/proc/task_mmu.c +1 -3
@@ -737,9 +737,7 @@ static int smaps_hugetlb_range(pte_t *pt page =pfn_swap_entry_to_page (swpent); }if (page) { -int mapcount =page_mapcount (page); - -if (mapcount >=2 ) +if (page_mapcount (page) >=2 ||hugetlb_pmd_shared (pte)) mss->shared_hugetlb +=huge_page_size (hstate_vma (vma));else mss->private_hugetlb +=huge_page_size (hstate_vma (vma));
include/linux/hugetlb.h +13 -0
@@ -7,6 +7,7 @@#include <linux/fs.h> #include <linux/hugetlb_inline.h> #include <linux/cgroup.h> +#include <linux/page_ref.h> #include <linux/list.h> #include <linux/kref.h> #include <linux/pgtable.h>
@@ -1182,6 +1183,18 @@ static inline __init void hugetlb_cma_re }#endif +#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE +static inline bool hugetlb_pmd_shared (pte_t *pte) +{ +return page_count (virt_to_page (pte)) >1 ; +} +#else +static inline bool hugetlb_pmd_shared (pte_t *pte) +{ +return false; +} +#endif +bool want_pmd_share (struct vm_area_struct *vma,unsigned long addr);#ifndef __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE
Greg Kroah-Hartman
maintainerPATCH 158/208 mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath()
In reply to Greg Kroah-HartmanFrom: Kefeng Wang <[email protected]>
commit ac86f547ca1002aec2ef66b9e64d03f45bbbfbb9 upstream.
As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"), hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could occurs a NULL pointer dereference, let's do not record the foreign writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to fix it.
--- include/linux/memcontrol.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
include/linux/memcontrol.h +4 -1
@@ -1655,10 +1655,13 @@ void mem_cgroup_track_foreign_dirty_slowstatic inline void mem_cgroup_track_foreign_dirty (struct folio *folio,struct bdi_writeback *wb) { +struct mem_cgroup *memcg; +if (mem_cgroup_disabled ())return ; -if (unlikely (&folio_memcg (folio)->css != wb->memcg_css)) + memcg =folio_memcg (folio); +if (unlikely (memcg && &memcg->css != wb->memcg_css))mem_cgroup_track_foreign_dirty_slowpath (folio, wb); }
Greg Kroah-Hartman
maintainerPATCH 159/208 usb: gadget: f_uac2: Fix incorrect increment of bNumEndpoints
In reply to Greg Kroah-HartmanFrom: Pratham Pratap <[email protected]>
commit 2fa89458af9993fab8054daf827f38881e2ad473 upstream.
Currently connect/disconnect of USB cable calls afunc_bind and eventually increments the bNumEndpoints. Performing multiple plugin/plugout will increment bNumEndpoints incorrectly, and on the next plug-in it leads to invalid configuration of descriptor and hence enumeration fails.
Fix this by resetting the value of bNumEndpoints to 1 on every afunc_bind call.
--- drivers/usb/gadget/function/f_uac2.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/function/f_uac2.c +1 -0
@@ -1142,6 +1142,7 @@ afunc_bind(struct usb_configuration *cfg } std_as_out_if0_desc.bInterfaceNumber = ret; std_as_out_if1_desc.bInterfaceNumber = ret; + std_as_out_if1_desc.bNumEndpoints =1 ; uac2->as_out_intf = ret; uac2->as_out_alt =0 ;
Greg Kroah-Hartman
maintainerPATCH 160/208 usb: typec: ucsi: Dont attempt to resume the ports before they exist
In reply to Greg Kroah-HartmanFrom: Heikki Krogerus <[email protected]>
commit f82060da749c611ed427523b6d1605d87338aac1 upstream.
This will fix null pointer dereference that was caused by the driver attempting to resume ports that were not yet registered.
--- drivers/usb/typec/ucsi/ucsi.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/typec/ucsi/ucsi.c +8 -1
@@ -1269,6 +1269,9 @@ err_unregister: con->port =NULL ; } +kfree (ucsi->connector); + ucsi->connector =NULL ; + err_reset:memset (&ucsi->cap,0 ,sizeof (ucsi->cap));ucsi_reset_ppm (ucsi);
@@ -1300,7 +1303,8 @@ static void ucsi_resume_work(struct workint ucsi_resume (struct ucsi *ucsi) { -queue_work (system_long_wq, &ucsi->resume_work); +if (ucsi->connector) +queue_work (system_long_wq, &ucsi->resume_work);return 0 ; }EXPORT_SYMBOL_GPL (ucsi_resume);
@@ -1420,6 +1424,9 @@ void ucsi_unregister(struct ucsi *ucsi)/* Disable notifications */ ucsi->ops->async_write (ucsi,UCSI_CONTROL , &cmd,sizeof (cmd)); +if (!ucsi->connector) +return ; +for (i =0 ; i < ucsi->cap.num_connectors; i++) {cancel_work_sync (&ucsi->connector[i].work);ucsi_unregister_partner (&ucsi->connector[i]);
Greg Kroah-Hartman
maintainerPATCH 161/208 usb: gadget: udc: do not clear gadget driver.bus
In reply to Greg Kroah-HartmanFrom: Aaro Koskinen <[email protected]>
commit 30d09b3131f5b1b9d54ad9b7ee171a45e21362b3 upstream.
Before the commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget driver.bus was unused. For whatever reason, many UDC drivers set this field explicitly to NULL in udc_start(). With the newly added gadget bus, doing this will crash the driver during the attach.
The problem was first reported, fixed and tested with OMAP UDC and g_ether. Other drivers are changed based on code analysis only.
--- drivers/usb/gadget/udc/bcm63xx_udc.c | 1 - drivers/usb/gadget/udc/fotg210-udc.c | 1 - drivers/usb/gadget/udc/fsl_qe_udc.c | 1 - drivers/usb/gadget/udc/fsl_udc_core.c | 1 - drivers/usb/gadget/udc/fusb300_udc.c | 1 - drivers/usb/gadget/udc/goku_udc.c | 1 - drivers/usb/gadget/udc/gr_udc.c | 1 - drivers/usb/gadget/udc/m66592-udc.c | 1 - drivers/usb/gadget/udc/max3420_udc.c | 1 - drivers/usb/gadget/udc/mv_u3d_core.c | 1 - drivers/usb/gadget/udc/mv_udc_core.c | 1 - drivers/usb/gadget/udc/net2272.c | 1 - drivers/usb/gadget/udc/net2280.c | 1 - drivers/usb/gadget/udc/omap_udc.c | 1 - drivers/usb/gadget/udc/pch_udc.c | 1 - drivers/usb/gadget/udc/snps_udc_core.c | 1 - 16 files changed, 16 deletions(-)
drivers/usb/gadget/udc/bcm63xx_udc.c +0 -1
@@ -1830,7 +1830,6 @@ static int bcm63xx_udc_start(struct usb_bcm63xx_select_phy_mode (udc, true); udc->driver = driver; - driver->driver.bus =NULL ; udc->gadget.dev.of_node = udc->dev->of_node;spin_unlock_irqrestore (&udc->lock, flags);
drivers/usb/gadget/udc/fotg210-udc.c +0 -1
@@ -1009,7 +1009,6 @@ static int fotg210_udc_start(struct usb_u32 value;/* hook up the driver */ - driver->driver.bus =NULL ; fotg210->driver = driver;/* enable device global interrupt */
drivers/usb/gadget/udc/fsl_qe_udc.c +0 -1
@@ -2285,7 +2285,6 @@ static int fsl_qe_start(struct usb_gadge/* lock is needed but whether should use this lock or another */ spin_lock_irqsave (&udc->lock, flags); - driver->driver.bus =NULL ;/* hook up the driver */ udc->driver = driver; udc->gadget.speed = driver->max_speed;
drivers/usb/gadget/udc/fsl_udc_core.c +0 -1
@@ -1943,7 +1943,6 @@ static int fsl_udc_start(struct usb_gadg/* lock is needed but whether should use this lock or another */ spin_lock_irqsave (&udc_controller->lock, flags); - driver->driver.bus =NULL ;/* hook up the driver */ udc_controller->driver = driver;spin_unlock_irqrestore (&udc_controller->lock, flags);
drivers/usb/gadget/udc/fusb300_udc.c +0 -1
@@ -1311,7 +1311,6 @@ static int fusb300_udc_start(struct usb_struct fusb300 *fusb300 =to_fusb300 (g);/* hook up the driver */ - driver->driver.bus =NULL ; fusb300->driver = driver;return 0 ;
drivers/usb/gadget/udc/goku_udc.c +0 -1
@@ -1375,7 +1375,6 @@ static int goku_udc_start(struct usb_gadstruct goku_udc *dev =to_goku_udc (g);/* hook up the driver */ - driver->driver.bus =NULL ; dev->driver = driver;/*
drivers/usb/gadget/udc/gr_udc.c +0 -1
@@ -1906,7 +1906,6 @@ static int gr_udc_start(struct usb_gadgespin_lock (&dev->lock);/* Hook up the driver */ - driver->driver.bus =NULL ; dev->driver = driver;/* Get ready for host detection */
drivers/usb/gadget/udc/m66592-udc.c +0 -1
@@ -1454,7 +1454,6 @@ static int m66592_udc_start(struct usb_gstruct m66592 *m66592 =to_m66592 (g);/* hook up the driver */ - driver->driver.bus =NULL ; m66592->driver = driver;m66592_bset (m66592,M66592_VBSE |M66592_URST ,M66592_INTENB0 );
drivers/usb/gadget/udc/max3420_udc.c +0 -1
@@ -1108,7 +1108,6 @@ static int max3420_udc_start(struct usb_spin_lock_irqsave (&udc->lock, flags);/* hook up the driver */ - driver->driver.bus =NULL ; udc->driver = driver; udc->gadget.speed =USB_SPEED_FULL ;
drivers/usb/gadget/udc/mv_u3d_core.c +0 -1
@@ -1243,7 +1243,6 @@ static int mv_u3d_start(struct usb_gadge }/* hook up the driver ... */ - driver->driver.bus =NULL ; u3d->driver = driver; u3d->ep0_dir =USB_DIR_OUT ;
drivers/usb/gadget/udc/mv_udc_core.c +0 -1
@@ -1359,7 +1359,6 @@ static int mv_udc_start(struct usb_gadgespin_lock_irqsave (&udc->lock, flags);/* hook up the driver ... */ - driver->driver.bus =NULL ; udc->driver = driver; udc->usb_state =USB_STATE_ATTACHED ;
drivers/usb/gadget/udc/net2272.c +0 -1
@@ -1451,7 +1451,6 @@ static int net2272_start(struct usb_gadg dev->ep[i].irqs =0 ;/* hook up the driver ... */ dev->softconnect =1 ; - driver->driver.bus =NULL ; dev->driver = driver;/* ... then enable host detection and ep0; and we're ready
drivers/usb/gadget/udc/net2280.c +0 -1
@@ -2423,7 +2423,6 @@ static int net2280_start(struct usb_gadg dev->ep[i].irqs =0 ;/* hook up the driver ... */ - driver->driver.bus =NULL ; dev->driver = driver; retval =device_create_file (&dev->pdev->dev, &dev_attr_function);
drivers/usb/gadget/udc/omap_udc.c +0 -1
@@ -2066,7 +2066,6 @@ static int omap_udc_start(struct usb_gad udc->softconnect =1 ;/* hook up the driver */ - driver->driver.bus =NULL ; udc->driver = driver;spin_unlock_irqrestore (&udc->lock, flags);
drivers/usb/gadget/udc/pch_udc.c +0 -1
@@ -2908,7 +2908,6 @@ static int pch_udc_start(struct usb_gadg {struct pch_udc_dev *dev =to_pch_udc (g); - driver->driver.bus =NULL ; dev->driver = driver;/* get ready for ep0 traffic */
drivers/usb/gadget/udc/snps_udc_core.c +0 -1
@@ -1933,7 +1933,6 @@ static int amd5536_udc_start(struct usb_struct udc *dev =to_amd5536_udc (g);u32 tmp; - driver->driver.bus =NULL ; dev->driver = driver;/* Some gadget drivers use both ep0 directions.
Greg Kroah-Hartman
maintainerPATCH 162/208 kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
commit d83d7ed260283560700d4034a80baad46620481b upstream.
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
--- kernel/irq/irqdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/irq/irqdomain.c +1 -1
@@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(strucstatic void debugfs_remove_domain_dir (struct irq_domain *d) { -debugfs_remove (debugfs_lookup (d->name, domain_dir)); +debugfs_lookup_and_remove (d->name, domain_dir); }void __init irq_domain_debugfs_init (struct dentry *root)
Greg Kroah-Hartman
maintainerPATCH 163/208 HV: hv_balloon: fix memory leak with using debugfs_lookup()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
commit 6dfb0771429a63db8561d44147f2bb76f93e1c86 upstream.
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
--- drivers/hv/hv_balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hv/hv_balloon.c +1 -1
@@ -1911,7 +1911,7 @@ static void hv_balloon_debugfs_init(strstatic void hv_balloon_debugfs_exit (struct hv_dynmem_device *b) { -debugfs_remove (debugfs_lookup ("hv-balloon" ,NULL )); +debugfs_lookup_and_remove ("hv-balloon" ,NULL ); }#else
Greg Kroah-Hartman
maintainerPATCH 164/208 x86/debug: Fix stack recursion caused by wrongly ordered DR7 accesses
In reply to Greg Kroah-HartmanFrom: Joerg Roedel <[email protected]>
commit 9d2c7203ffdb846399b82b0660563c89e918c751 upstream.
In kernels compiled with CONFIG_PARAVIRT=n, the compiler re-orders the DR7 read in exc_nmi() to happen before the call to sev_es_ist_enter().
This is problematic when running as an SEV-ES guest because in this environment the DR7 read might cause a #VC exception, and taking #VC exceptions is not safe in exc_nmi() before sev_es_ist_enter() has run.
The result is stack recursion if the NMI was caused on the #VC IST stack, because a subsequent #VC exception in the NMI handler will overwrite the stack frame of the interrupted #VC handler.
As there are no compiler barriers affecting the ordering of DR7 reads/writes, make the accesses to this register volatile, forbidding the compiler to re-order them.
[ bp: Massage text, make them volatile too, to make sure some aggressive compiler optimization pass doesn't discard them. ]
--- arch/x86/include/asm/debugreg.h | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-)
arch/x86/include/asm/debugreg.h +24 -2
@@ -39,7 +39,20 @@ static __always_inline unsigned long nat asm("mov %%db6, %0" :"=r" (val));break ;case 7 : - asm("mov %%db7, %0" :"=r" (val)); +/* +* Apply __FORCE_ORDER to DR7 reads to forbid re-ordering them +* with other code. +* +* This is needed because a DR7 access can cause a #VC exception +* when running under SEV-ES. Taking a #VC exception is not a +* safe thing to do just anywhere in the entry code and +* re-ordering might place the access into an unsafe location. +* +* This happened in the NMI handler, where the DR7 read was +* re-ordered to happen before the call to sev_es_ist_enter(), +* causing stack recursion. +*/ + asm volatile("mov %%db7, %0" : "=r" (val) : __FORCE_ORDER);break ;default :BUG ();
@@ -66,7 +79,16 @@ static __always_inline void native_set_d asm("mov %0, %%db6" ::"r" (value));break ;case 7 : - asm("mov %0, %%db7" ::"r" (value)); +/* +* Apply __FORCE_ORDER to DR7 writes to forbid re-ordering them +* with other code. +* +* While is didn't happen with a DR7 write (see the DR7 read +* comment above which explains where it happened), add the +* __FORCE_ORDER here too to avoid similar problems in the +* future. +*/ + asm volatile("mov %0, %%db7" ::"r" (value), __FORCE_ORDER);break ;default :BUG ();
Greg Kroah-Hartman
maintainerPATCH 165/208 fpga: m10bmc-sec: Fix probe rollback
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit 60ce26d10e5850f33cc76fce52f5377045e75a15 upstream.
Handle probe error rollbacks properly to avoid leaks.
--- drivers/fpga/intel-m10-bmc-sec-update.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/fpga/intel-m10-bmc-sec-update.c +12 -5
@@ -574,20 +574,27 @@ static int m10bmc_sec_probe(struct platform_device *pdev) len =scnprintf (buf,SEC_UPDATE_LEN_MAX ,"secure-update%d" , sec->fw_name_id); sec->fw_name =kmemdup_nul (buf, len,GFP_KERNEL ); -if (!sec->fw_name) -return -ENOMEM ; +if (!sec->fw_name) { + ret = -ENOMEM ; + goto fw_name_fail; + } fwl =firmware_upload_register (THIS_MODULE , sec->dev, sec->fw_name, &m10bmc_ops, sec);if (IS_ERR (fwl)) {dev_err (sec->dev,"Firmware Upload driver failed to start\n" ); -kfree (sec->fw_name); -xa_erase (&fw_upload_xa, sec->fw_name_id); -return PTR_ERR (fwl); + ret =PTR_ERR (fwl); + goto fw_uploader_fail; } sec->fwl = fwl;return 0 ; + +fw_uploader_fail: +kfree (sec->fw_name); +fw_name_fail: +xa_erase (&fw_upload_xa, sec->fw_name_id); +return ret; }static int m10bmc_sec_remove (struct platform_device *pdev)
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 166/208 fpga: stratix10-soc: Fix return value check in s10_ops_write_init()
In reply to Greg Kroah-HartmanFrom: Zheng Yongjun <[email protected]>
commit 65ea840afd508194b0ee903256162aa87e46ec30 upstream.
In case of error, the function stratix10_svc_allocate_memory() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR().
--- drivers/fpga/stratix10-soc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/fpga/stratix10-soc.c +2 -2
@@ -213,9 +213,9 @@ static int s10_ops_write_init(struct fpg/* Allocate buffers from the service layer's pool. */ for (i =0 ; i <NUM_SVC_BUFS ; i++) { kbuf =stratix10_svc_allocate_memory (priv->chan,SVC_BUF_SIZE ); -if (!kbuf) { +if (IS_ERR (kbuf)) {s10_free_buffers (mgr); - ret = -ENOMEM ; + ret =PTR_ERR (kbuf); goto init_done; }
Greg Kroah-Hartman
maintainerPATCH 167/208 mm/uffd: fix pte marker when fork() without fork event
In reply to Greg Kroah-HartmanFrom: Peter Xu <[email protected]>
commit 49d6d7fb631345b0f2957a7c4be24ad63903150f upstream.
Patch series "mm: Fixes on pte markers".
Patch 1 resolves the syzkiller report from Pengfei.
Patch 2 further harden pte markers when used with the recent swapin error markers. The major case is we should persist a swapin error marker after fork(), so child shouldn't read a corrupted page.
This patch (of 2):
When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may have it and has pte marker installed. The warning is improper along with the comment. The right thing is to inherit the pte marker when needed, or keep the dst pte empty.
A vague guess is this happened by an accident when there's the prior patch to introduce src/dst vma into this helper during the uffd-wp feature got developed and I probably messed up in the rebase, since if we replace dst_vma with src_vma the warning & comment it all makes sense too.
Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the general path.
Reproducer:
https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c
Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808
--- mm/memory.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
mm/memory.c +2 -6
@@ -875,12 +875,8 @@ copy_nonpresent_pte(struct mm_struct *dsreturn -EBUSY ;return -ENOENT ; }else if (is_pte_marker_entry (entry)) { -/* -* We're copying the pgtable should only because dst_vma has -* uffd-wp enabled, do sanity check. -*/ -WARN_ON_ONCE (!userfaultfd_wp (dst_vma)); -set_pte_at (dst_mm, addr, dst_pte, pte); +if (userfaultfd_wp (dst_vma)) +set_pte_at (dst_mm, addr, dst_pte, pte);return 0 ; }if (!userfaultfd_wp (dst_vma))
Greg Kroah-Hartman
maintainerPATCH 168/208 mm/swapfile: add cond_resched() in get_swap_pages()
In reply to Greg Kroah-HartmanFrom: Longlong Xia <[email protected]>
commit 7717fc1a12f88701573f9ed897cc4f6699c661e3 upstream.
The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently.
The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case:cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.
--- mm/swapfile.c | 1 + 1 file changed, 1 insertion(+)
mm/swapfile.c +1 -0
@@ -1101,6 +1101,7 @@ start_over: goto check_out;pr_debug ("scan_swap_map of si %d failed to find offset\n" , si->type); +cond_resched ();spin_lock (&swap_avail_lock); nextsi:
Greg Kroah-Hartman
maintainerPATCH 169/208 mm/khugepaged: fix ->anon_vma race
In reply to Greg Kroah-HartmanFrom: Jann Horn <[email protected]>
commit 023f47a8250c6bdb4aebe744db4bf7f73414028b upstream.
If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked.
Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains).
If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them.
Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access.
Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access.
--- mm/khugepaged.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
mm/khugepaged.c +13 -1
@@ -1649,7 +1649,7 @@ static int retract_page_tables(struct ad* has higher cost too. It would also probably require locking * the anon_vma. */ -if (vma->anon_vma) { +if (READ_ONCE (vma->anon_vma)) { result =SCAN_PAGE_ANON ; goto next; }
@@ -1678,6 +1678,18 @@ static int retract_page_tables(struct adif ((cc->is_khugepaged || is_target) &&mmap_write_trylock (mm)) {/* +* Re-check whether we have an ->anon_vma, because +* collapse_and_free_pmd() requires that either no +* ->anon_vma exists or the anon_vma is locked. +* We already checked ->anon_vma above, but that check +* is racy because ->anon_vma can be populated under the +* mmap lock in read mode. +*/ +if (vma->anon_vma) { + result =SCAN_PAGE_ANON ; + goto unlock_next; + } +/* * When a vma is registered with uffd-wp, we can't * recycle the pmd pgtable because there can be pte * markers installed. Skip it only, so the rest mm/vma
Greg Kroah-Hartman
maintainerPATCH 170/208 mm, mremap: fix mremap() expanding for vmas with vm_ops->close()
In reply to Greg Kroah-HartmanFrom: Vlastimil Babka <[email protected]>
commit d014cd7c1c358edc3ea82ebf327a036a42ed0164 upstream.
Fabian has reported another regression in 6.1 due to ca3d76b0aa80 ("mm:
add merging after mremap resize"). The problem is that vma_merge() can fail when vma has a vm_ops->close() method, causing is_mergeable_vma() test to be negative. This was happening for vma mapping a file from fuse-overlayfs, which does have the method. But when we are simply expanding the vma, we never remove it due to the "merge" with the added area, so the test should not prevent the expansion.
As a quick fix, check for such vmas and expand them using vma_adjust() directly as was done before commit ca3d76b0aa80. For a more robust long term solution we should try to limit the check for vma_ops->close only to cases that actually result in vma removal, so that no merge would be prevented unnecessarily.
--- mm/mremap.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-)
mm/mremap.c +19 -6
@@ -1027,16 +1027,29 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, }/* -* Function vma_merge() is called on the extension we are adding to -* the already existing vma, vma_merge() will merge this extension with -* the already existing vma (expand operation itself) and possibly also -* with the next vma if it becomes adjacent to the expanded vma and -* otherwise compatible. +* Function vma_merge() is called on the extension we +* are adding to the already existing vma, vma_merge() +* will merge this extension with the already existing +* vma (expand operation itself) and possibly also with +* the next vma if it becomes adjacent to the expanded +* vma and otherwise compatible. +* +* However, vma_merge() can currently fail due to +* is_mergeable_vma() check for vm_ops->close (see the +* comment there). Yet this should not prevent vma +* expanding, so perform a simple expand for such vma. +* Ideally the check for close op should be only done +* when a vma would be actually removed due to a merge. */ - vma =vma_merge (mm, vma, extension_start, extension_end, +if (!vma->vm_ops || !vma->vm_ops->close) { + vma =vma_merge (mm, vma, extension_start, extension_end, vma->vm_flags, vma->anon_vma, vma->vm_file, extension_pgoff,vma_policy (vma), vma->vm_userfaultfd_ctx,anon_vma_name (vma)); + }else if (vma_adjust (vma, vma->vm_start, addr + new_len, + vma->vm_pgoff,NULL )) { + vma =NULL ; + }if (!vma) {vm_unacct_memory (pages); ret = -ENOMEM ;
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 171/208 mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
In reply to Greg Kroah-HartmanFrom: Zach O'Keefe <[email protected]>
commit edb5d0cf5525357652aff6eacd9850b8ced07143 upstream.
In commit 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none():
- if (!pmd_present(pmde))
- return SCAN_PMD_NULL;
+ if (pmd_none(pmde))
+ return SCAN_PMD_NONE;
This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd. Such codepaths include:
A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER already in the pagecache.
B) In retract_page_tables(), if we fail to grab mmap_lock for the target mm/address.
In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.
However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds. One such example that could leak through are swap entries. The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd.
We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch.
The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state. For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit.
Covering all 4 cases for x86 (all checks done on the same pmd value):
1) pmd_present() && pmd_trans_huge()
All we actually know here is that the PSE bit is set. Either:
a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE
is set.
=> huge-pmd b) We are currently racing with __split_huge_page(). The danger here is that we proceed as-if we have a huge-pmd, but really we are looking at a pte-mapping-pmd. So, what is the risk of this danger?
The only relevant path is:
madvise_collapse() -> collapse_pte_mapped_thp()
Where we might just incorrectly report back "success", when really the memory isn't pmd-backed. This is fine, since split could happen immediately after (actually) successful madvise_collapse(). So, it should be safe to just assume huge-pmd here.
2) pmd_present() && !pmd_trans_huge()
Either:
a) PSE not set and either PRESENT or PROTNONE is.
=> pte-table-mapping pmd (or PROT_NONE)
b) devmap. This routine can be called immediately after unlocking/locking mmap_lock -- or called with no locks held (see khugepaged_scan_mm_slot()), so previous VMA checks have since been invalidated.
3) !pmd_present() && pmd_trans_huge()
Not possible.
4) !pmd_present() && !pmd_trans_huge()
Neither PRESENT nor PROTNONE set
=> not present
I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path).
Also, add a comment above find_pmd_or_thp_or_none() to help future travelers reason about the validity of the code; namely, the possible mutations that might happen out from under us, depending on how mmap_lock is held (if at all).
--- mm/khugepaged.c | 8 ++++++++ 1 file changed, 8 insertions(+)
mm/khugepaged.c +8 -0
@@ -847,6 +847,10 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,return SCAN_SUCCEED ; } +/* +* See pmd_trans_unstable() for how the result may change out from +* underneath us, even if we hold mmap_lock in read. +*/ static int find_pmd_or_thp_or_none (struct mm_struct *mm,unsigned long address,pmd_t **pmd)
@@ -865,8 +869,12 @@ static int find_pmd_or_thp_or_none(struct mm_struct *mm,#endif if (pmd_none (pmde))return SCAN_PMD_NONE ; +if (!pmd_present (pmde)) +return SCAN_PMD_NULL ;if (pmd_trans_huge (pmde))return SCAN_PMD_MAPPED ; +if (pmd_devmap (pmde)) +return SCAN_PMD_NULL ;if (pmd_bad (pmde))return SCAN_PMD_NULL ;return SCAN_SUCCEED ;
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 172/208 highmem: round down the address passed to kunmap_flush_on_unmap()
In reply to Greg Kroah-HartmanFrom: Matthew Wilcox (Oracle) <[email protected]>
commit 88d7b12068b95731c280af8ce88e8ee9561f96de upstream.
We already round down the address in kunmap_local_indexed() which is the other implementation of __kunmap_local(). The only implementation of kunmap_flush_on_unmap() is PA-RISC which is expecting a page-aligned address. This may be causing PA-RISC to be flushing the wrong addresses currently.
--- include/linux/highmem-internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/highmem-internal.h +2 -2
@@ -200,7 +200,7 @@ static inline void *kmap_local_pfn(unsigstatic inline void __kunmap_local (const void *addr) {#ifdef ARCH_HAS_FLUSH_ON_KUNMAP -kunmap_flush_on_unmap (addr); +kunmap_flush_on_unmap (PTR_ALIGN_DOWN (addr,PAGE_SIZE ));#endif }
@@ -227,7 +227,7 @@ static inline void *kmap_atomic_pfn(unsistatic inline void __kunmap_atomic (const void *addr) {#ifdef ARCH_HAS_FLUSH_ON_KUNMAP -kunmap_flush_on_unmap (addr); +kunmap_flush_on_unmap (PTR_ALIGN_DOWN (addr,PAGE_SIZE ));#endif pagefault_enable ();if (IS_ENABLED (CONFIG_PREEMPT_RT ))
Greg Kroah-Hartman
maintainerPATCH 173/208 ia64: fix build error due to switch case label appearing next to declaration
In reply to Greg Kroah-HartmanFrom: James Morse <[email protected]>
commit 6f28a2613497fc587e347afa99fa2c52230678a7 upstream.
Since commit aa06a9bd8533 ("ia64: fix clock_getres(CLOCK_MONOTONIC) to report ITC frequency"), gcc 10.1.0 fails to build ia64 with the gnomic:
| ../arch/ia64/kernel/sys_ia64.c: In function 'ia64_clock_getres': | ../arch/ia64/kernel/sys_ia64.c:189:3: error: a label can only be part of a statement and a declaration is not a statement | 189 | s64 tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
This line appears immediately after a case label in a switch.
Move the declarations out of the case, to the top of the function.
--- arch/ia64/kernel/sys_ia64.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/ia64/kernel/sys_ia64.c +5 -2
@@ -170,6 +170,9 @@ ia64_mremap (unsigned long addr, unsigned long old_len, unsigned long new_len, uasmlinkage long ia64_clock_getres (const clockid_t which_clock,struct __kernel_timespec __user *tp) { +struct timespec64 rtn_tp; +s64 tick_ns; +/* * ia64's clock_gettime() syscall is implemented as a vdso call * fsys_clock_gettime(). Currently it handles only
@@ -185,8 +188,8 @@ ia64_clock_getres(const clockid_t which_clock, struct __kernel_timespec __user *switch (which_clock) {case CLOCK_REALTIME :case CLOCK_MONOTONIC : -s64 tick_ns =DIV_ROUND_UP (NSEC_PER_SEC , local_cpu_data->itc_freq); -struct timespec64 rtn_tp =ns_to_timespec64 (tick_ns); + tick_ns =DIV_ROUND_UP (NSEC_PER_SEC , local_cpu_data->itc_freq); + rtn_tp =ns_to_timespec64 (tick_ns);return put_timespec64 (&rtn_tp, tp); }
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 174/208 Squashfs: fix handling and sanity checking of xattr_ids count
In reply to Greg Kroah-HartmanFrom: Phillip Lougher <[email protected]>
commit f65c4bbbd682b0877b669828b4e033b8d5d0a2dc upstream.
A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing.
In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225.
Flaw 1 (64-bit systems only):
The signed integer xattr_ids variable causes sign extension.
This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long".
On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len).
Flaw 2 (32-bit systems only):
On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned.
The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.
The effect of the 0 length computation:
In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850.
This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes).
len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);
/*
* The computed size of the index table (len bytes) should exactly
* match the table start and end points
*/
start = table_start + sizeof(*id_table);
end = msblk->bytes_used;
if (len != (end - start))
return ERR_PTR(-EINVAL);Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator.
Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system.
It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation.
[1] https://lore.kernel.org/lkml/[email protected]/
--- fs/squashfs/squashfs_fs.h | 2 +- fs/squashfs/squashfs_fs_sb.h | 2 +- fs/squashfs/xattr.h | 4 ++-- fs/squashfs/xattr_id.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-)
fs/squashfs/squashfs_fs.h +1 -1
@@ -183,7 +183,7 @@ static inline int squashfs_block_size(__#define SQUASHFS_ID_BLOCK_BYTES (A ) (SQUASHFS_ID_BLOCKS(A) *\ sizeof(u64))/* xattr id lookup table defines */ -#define SQUASHFS_XATTR_BYTES (A ) ((A) * sizeof(struct squashfs_xattr_id)) +#define SQUASHFS_XATTR_BYTES (A ) (((u64) (A)) * sizeof(struct squashfs_xattr_id))#define SQUASHFS_XATTR_BLOCK (A ) (SQUASHFS_XATTR_BYTES(A) / \ SQUASHFS_METADATA_SIZE)
fs/squashfs/squashfs_fs_sb.h +1 -1
@@ -63,7 +63,7 @@ struct squashfs_sb_info {long long bytes_used;unsigned int inodes;unsigned int fragments; -int xattr_ids; +unsigned int xattr_ids;unsigned int ids;bool panic_on_errors; };
fs/squashfs/xattr.h +2 -2
@@ -10,12 +10,12 @@#ifdef CONFIG_SQUASHFS_XATTR extern __le64 *squashfs_read_xattr_id_table (struct super_block *,u64 , -u64 *,int *); +u64 *,unsigned int *);extern int squashfs_xattr_lookup (struct super_block *,unsigned int ,int *,unsigned int *,unsigned long long *);#else static inline __le64 *squashfs_read_xattr_id_table (struct super_block *sb, -u64 start,u64 *xattr_table_start,int *xattr_ids) +u64 start,u64 *xattr_table_start,unsigned int *xattr_ids) {struct squashfs_xattr_id_table *id_table;
fs/squashfs/xattr_id.c +1 -1
@@ -56,7 +56,7 @@ int squashfs_xattr_lookup(struct super_b* Read uncompressed xattr id lookup table indexes from disk into memory */ __le64 *squashfs_read_xattr_id_table (struct super_block *sb,u64 table_start, -u64 *xattr_table_start,int *xattr_ids) +u64 *xattr_table_start,unsigned int *xattr_ids) {struct squashfs_sb_info *msblk = sb->s_fs_info;unsigned int len, indexes;
Greg Kroah-Hartman
maintainerPATCH 175/208 maple_tree: fix mas_empty_area_rev() lower bound validation
In reply to Greg Kroah-HartmanFrom: Liam Howlett <[email protected]>
commit 7327e8111adb315423035fb5233533016dfd3f2e upstream.
mas_empty_area_rev() was not correctly validating the start of a gap against the lower limit. This could lead to the range starting lower than the requested minimum.
Fix the issue by better validating a gap once one is found.
This commit also adds tests to the maple tree test suite for this issue and tests the mas_empty_area() function for similar bound checking.
--- lib/maple_tree.c | 17 ++++----- lib/test_maple_tree.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+), 9 deletions(-)
lib/maple_tree.c +8 -9
@@ -4883,7 +4883,7 @@ static bool mas_rev_awalk(struct ma_statunsigned long *pivots, *gaps;void __rcu **slots;unsigned long gap =0 ; -unsigned long max, min, index; +unsigned long max, min;unsigned char offset;if (unlikely (mas_is_err (mas)))
@@ -4905,8 +4905,7 @@ static bool mas_rev_awalk(struct ma_stat min =mas_safe_min (mas, pivots, --offset); max =mas_safe_pivot (mas, pivots, offset, type); - index = mas->index; -while (index <= max) { +while (mas->index <= max) { gap =0 ;if (gaps) gap = gaps[offset];
@@ -4937,10 +4936,8 @@ static bool mas_rev_awalk(struct ma_stat min =mas_safe_min (mas, pivots, offset); } -if (unlikely (index > max)) { -mas_set_err (mas, -EBUSY ); -return false; - } +if (unlikely ((mas->index > max) || (size -1 > max - mas->index))) + goto no_space;if (unlikely (ma_is_leaf (type))) { mas->offset = offset;
@@ -4957,9 +4954,11 @@ static bool mas_rev_awalk(struct ma_statreturn false; ascend: -if (mte_is_root (mas->node)) -mas_set_err (mas, -EBUSY ); +if (!mte_is_root (mas->node)) +return false; +no_space: +mas_set_err (mas, -EBUSY );return false; }
lib/test_maple_tree.c +89 -0
101 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 176/208 migrate: hugetlb: check for hugetlb shared PMD in node migration
In reply to Greg Kroah-HartmanFrom: Mike Kravetz <[email protected]>
commit 73bdf65ea74857d7fb2ec3067a3cec0e261b1462 upstream.
migrate_pages/mempolicy semantics state that CAP_SYS_NICE is required to move pages shared with another process to a different node. page_mapcount
Quoted 1 line
1 is being used to determine if a hugetlb page is shared. However, a
hugetlb page will have a mapcount of 1 if mapped by multiple processes via a shared PMD. As a result, hugetlb pages shared by multiple processes and mapped with a shared PMD can be moved by a process without CAP_SYS_NICE.
To fix, check for a shared PMD if mapcount is 1. If a shared PMD is found consider the page shared.
--- mm/mempolicy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/mempolicy.c +2 -1
@@ -600,7 +600,8 @@ static int queue_pages_hugetlb(pte_t *pt/* With MPOL_MF_MOVE, we migrate only unshared hugepage. */ if (flags & (MPOL_MF_MOVE_ALL ) || - (flags &MPOL_MF_MOVE &&page_mapcount (page) ==1 )) { + (flags &MPOL_MF_MOVE &&page_mapcount (page) ==1 && + !hugetlb_pmd_shared (pte))) {if (isolate_hugetlb (page, qp->pagelist) && (flags &MPOL_MF_STRICT ))/*
Greg Kroah-Hartman
maintainerPATCH 177/208 dma-buf: actually set signaling bit for private stub fences
In reply to Greg Kroah-HartmanFrom: Danilo Krummrich <[email protected]>
commit d2ceea0eb6e17bb37d8b85cb4c16797c0d683d1c upstream.
In dma_fence_allocate_private_stub() set the signaling bit of the newly allocated private stub fence rather than the signaling bit of the shared dma_fence_stub.
--- drivers/dma-buf/dma-fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma-buf/dma-fence.c +1 -1
@@ -167,7 +167,7 @@ struct dma_fence *dma_fence_allocate_private_stub(void) 0, 0);set_bit (DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT , - &dma_fence_stub.flags); + &fence->flags);dma_fence_signal (fence);
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 178/208 serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
In reply to Greg Kroah-HartmanFrom: Marek Vasut <[email protected]>
commit 3f6c02fa712bd453871877fe1d1969625617471e upstream.
Requesting an interrupt with IRQF_ONESHOT will run the primary handler in the hard-IRQ context even in the force-threaded mode. The force-threaded mode is used by PREEMPT_RT in order to avoid acquiring sleeping locks (spinlock_t) in hard-IRQ context. This combination makes it impossible and leads to "sleeping while atomic" warnings.
Use one interrupt handler for both handlers (primary and secondary) and drop the IRQF_ONESHOT flag which is not needed.
--- drivers/tty/serial/stm32-usart.c | 33 +++++---------------------------- 1 file changed, 5 insertions(+), 28 deletions(-)
drivers/tty/serial/stm32-usart.c +5 -28
@@ -798,25 +798,11 @@ static irqreturn_t stm32_usart_interruptspin_unlock (&port->lock); } -if (stm32_usart_rx_dma_enabled (port)) -return IRQ_WAKE_THREAD ; -else -return IRQ_HANDLED ; -} - -static irqreturn_t stm32_usart_threaded_interrupt (int irq,void *ptr) -{ -struct uart_port *port = ptr; -struct tty_port *tport = &port->state->port; -struct stm32_port *stm32_port =to_stm32_port (port); -unsigned int size; -unsigned long flags; -/* Receiver timeout irq for DMA RX */ -if (!stm32_port->throttled) { -spin_lock_irqsave (&port->lock, flags); +if (stm32_usart_rx_dma_enabled (port) && !stm32_port->throttled) { +spin_lock (&port->lock); size =stm32_usart_receive_chars (port, false); -uart_unlock_and_check_sysrq_irqrestore (port, flags); +uart_unlock_and_check_sysrq (port);if (size)tty_flip_buffer_push (tport); }
@@ -1016,10 +1002,8 @@ static int stm32_usart_startup(struct uau32 val;int ret; - ret =request_threaded_irq (port->irq, stm32_usart_interrupt, - stm32_usart_threaded_interrupt, -IRQF_ONESHOT |IRQF_NO_SUSPEND , - name, port); + ret =request_irq (port->irq, stm32_usart_interrupt, +IRQF_NO_SUSPEND , name, port);if (ret)return ret;
@@ -1602,13 +1586,6 @@ static int stm32_usart_of_dma_rx_probe(sstruct dma_slave_config config;int ret; -/* -* Using DMA and threaded handler for the console could lead to -* deadlocks. -*/ -if (uart_console (port)) -return -ENODEV ; - stm32port->rx_buf =dma_alloc_coherent (dev,RX_BUF_L , &stm32port->rx_dma_buf,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 179/208 drm/i915: Avoid potential vm use-after-free
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
commit 41d419382ec7e257e54b7b6ff0d3623aafb1316d upstream.
Adding the vm to the vm_xa table makes it visible to userspace, which could try to race with us to close the vm. So we need to take our extra reference before putting it in the table.
--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/gem/i915_gem_context.c +11 -3
@@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private *file_priv, vm = ctx->vm;GEM_BUG_ON (!vm); +/* +* Get a reference for the allocated handle. Once the handle is +* visible in the vm_xa table, userspace could try to close it +* from under our feet, so we need to hold the extra reference +* first. +*/ +i915_vm_get (vm); + err =xa_alloc (&file_priv->vm_xa, &id, vm, xa_limit_32b,GFP_KERNEL ); -if (err) +if (err) { +i915_vm_put (vm);return err; - -i915_vm_get (vm); + }GEM_BUG_ON (id ==0 );/* reserved for invalid/unassigned ppgtt */ args->value = id;
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 180/208 drm/i915: Fix potential bit_17 double-free
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
commit 7057a8f126f14f14b040faecfa220fd27c6c2f85 upstream.
A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock.
--- drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/gem/i915_gem_tiling.c +5 -4
@@ -305,10 +305,6 @@ i915_gem_object_set_tiling(struct drm_i9spin_unlock (&obj->vma.lock); obj->tiling_and_stride = tiling | stride; -i915_gem_object_unlock (obj); - -/* Force the fence to be reacquired for GTT access */ -i915_gem_object_release_mmap_gtt (obj);/* Try to preallocate memory required to save swizzling on put-pages */ if (i915_gem_object_needs_bit17_swizzle (obj)) {
@@ -321,6 +317,11 @@ i915_gem_object_set_tiling(struct drm_i9 obj->bit_17 =NULL ; } +i915_gem_object_unlock (obj); + +/* Force the fence to be reacquired for GTT access */ +i915_gem_object_release_mmap_gtt (obj); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 181/208 drm/amd: Fix initialization for nbio 4.3.0
In reply to Greg Kroah-HartmanFrom: Mario Limonciello <[email protected]>
commit 5048fa1ebf89d03cf0ceca13fab8f800399e9ee3 upstream.
A mistake has been made on some boards with NBIO 4.3.0 where some NBIO registers aren't properly set by the hardware.
Ensure that they're set during initialization.
--- drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c +7 -1
@@ -337,7 +337,13 @@ const struct nbio_hdp_flush_reg nbio_v4_3_hdp_flush_reg = {static void nbio_v4_3_init_registers (struct amdgpu_device *adev) { -return ; +if (adev->ip_versions[NBIO_HWIP ][0 ] ==IP_VERSION (4 ,3 ,0 )) { +uint32_t data; + + data =RREG32_SOC15 (NBIO ,0 , regRCC_DEV0_EPF2_STRAP2); + data &= ~RCC_DEV0_EPF2_STRAP2__STRAP_NO_SOFT_RESET_DEV0_F2_MASK ; +WREG32_SOC15 (NBIO ,0 , regRCC_DEV0_EPF2_STRAP2, data); + } }static u32 nbio_v4_3_get_rom_offset (struct amdgpu_device *adev)
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 182/208 drm/amd/pm: drop unneeded dpm features disablement for SMU 13.0.4/11
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit 1538709c9f1c207d30afd95ea41b3aeb973f67e7 upstream.
PMFW will handle the features disablement properly for gpu reset case, driver involvement may cause some unexpected issues.
--- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +14 -0
@@ -1499,6 +1499,20 @@ static int smu_disable_dpms(struct smu_c }/* +* For SMU 13.0.4/11, PMFW will handle the features disablement properly +* for gpu reset case. Driver involvement is unnecessary. +*/ +if (amdgpu_in_reset (adev)) { +switch (adev->ip_versions[MP1_HWIP ][0 ]) { +case IP_VERSION (13 ,0 ,4 ): +case IP_VERSION (13 ,0 ,11 ): +return 0 ; +default : +break ; + } + } + +/* * For gpu reset, runpm and hibernation through BACO, * BACO feature has to be kept enabled. */
Greg Kroah-Hartman
maintainerPATCH 183/208 drm/amdgpu: update wave data type to 3 for gfx11
In reply to Greg Kroah-HartmanFrom: Graham Sider <[email protected]>
commit ed8e793c65e4c6633e8577e40d574da8a56d2e0f upstream.
SQ_WAVE_INST_DW0 isn't present on gfx11 compared to gfx10, so update wave data type to signify a difference.
--- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c +2 -2
@@ -790,8 +790,8 @@ static void gfx_v11_0_read_wave_data(struct amdgpu_device *adev, uint32_t simd,* zero here */ WARN_ON (simd !=0 ); -/* type 2 wave data */ - dst[(*no_fields)++] =2 ; +/* type 3 wave data */ + dst[(*no_fields)++] =3 ; dst[(*no_fields)++] =wave_read_ind (adev, wave, ixSQ_WAVE_STATUS); dst[(*no_fields)++] =wave_read_ind (adev, wave, ixSQ_WAVE_PC_LO); dst[(*no_fields)++] =wave_read_ind (adev, wave, ixSQ_WAVE_PC_HI);
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 184/208 nvmem: core: initialise nvmem->id early
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 3bd747c7ea13cb145f0d84444e00df928b0842d9 upstream.
The error path for wp_gpio attempts to free the IDA nvmem->id, but this has yet to be assigned, so will always be zero - leaking the ID allocated by ida_alloc(). Fix this by moving the initialisation of nvmem->id earlier.
--- drivers/nvmem/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvmem/core.c +2 -1
@@ -770,6 +770,8 @@ struct nvmem_device *nvmem_register(consreturn ERR_PTR (rval); } + nvmem->id = rval; +if (config->wp_gpio) nvmem->wp_gpio = config->wp_gpio;else if (!config->ignore_wp)
@@ -785,7 +787,6 @@ struct nvmem_device *nvmem_register(conskref_init (&nvmem->refcnt);INIT_LIST_HEAD (&nvmem->cells); - nvmem->id = rval; nvmem->owner = config->owner;if (!nvmem->owner && config->dev->driver) nvmem->owner = config->dev->driver->owner;
Greg Kroah-Hartman
maintainerPATCH 185/208 nvmem: core: remove nvmem_config wp_gpio
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 569653f022a29a1a44ea9de5308b657228303fa5 upstream.
No one provides wp_gpio, so let's remove it to avoid issues with the nvmem core putting this gpio.
--- drivers/nvmem/core.c | 4 +--- include/linux/nvmem-provider.h | 2 -- 2 files changed, 1 insertion(+), 5 deletions(-)
drivers/nvmem/core.c +1 -3
@@ -772,9 +772,7 @@ struct nvmem_device *nvmem_register(cons nvmem->id = rval; -if (config->wp_gpio) - nvmem->wp_gpio = config->wp_gpio; -else if (!config->ignore_wp) +if (!config->ignore_wp) nvmem->wp_gpio =gpiod_get_optional (config->dev,"wp" ,GPIOD_OUT_HIGH );if (IS_ERR (nvmem->wp_gpio)) {
include/linux/nvmem-provider.h +0 -2
@@ -70,7 +70,6 @@ struct nvmem_keepout {* @word_size: Minimum read/write access granularity. * @stride: Minimum read/write access stride. * @priv: User context passed to read/write callbacks. -* @wp-gpio: Write protect pin * @ignore_wp: Write Protect pin is managed by the provider. * * Note: A default "nvmem<id>" name will be assigned to the device if
@@ -85,7 +84,6 @@ struct nvmem_config {const char *name;int id;struct module *owner; -struct gpio_desc *wp_gpio;const struct nvmem_cell_info *cells;int ncells;const struct nvmem_keepout *keepout;
Greg Kroah-Hartman
maintainerPATCH 186/208 nvmem: core: fix cleanup after dev_set_name()
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 560181d3ace61825f4ca9dd3481d6c0ee6709fa8 upstream.
If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device.
This results in a slightly larger fix, but results in clear code.
Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio".
--- drivers/nvmem/core.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)
drivers/nvmem/core.c +10 -12
@@ -772,14 +772,18 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config) nvmem->id = rval; + nvmem->dev.type = &nvmem_provider_type; + nvmem->dev.bus = &nvmem_bus_type; + nvmem->dev.parent = config->dev; + +device_initialize (&nvmem->dev); +if (!config->ignore_wp) nvmem->wp_gpio =gpiod_get_optional (config->dev,"wp" ,GPIOD_OUT_HIGH );if (IS_ERR (nvmem->wp_gpio)) { -ida_free (&nvmem_ida, nvmem->id); rval =PTR_ERR (nvmem->wp_gpio); -kfree (nvmem); -return ERR_PTR (rval); + goto err_put_device; }kref_init (&nvmem->refcnt);
@@ -791,9 +795,6 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config) nvmem->stride = config->stride ?:1 ; nvmem->word_size = config->word_size ?:1 ; nvmem->size = config->size; - nvmem->dev.type = &nvmem_provider_type; - nvmem->dev.bus = &nvmem_bus_type; - nvmem->dev.parent = config->dev; nvmem->root_only = config->root_only; nvmem->priv = config->priv; nvmem->type = config->type;
@@ -821,11 +822,8 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)break ; } -if (rval) { -ida_free (&nvmem_ida, nvmem->id); -kfree (nvmem); -return ERR_PTR (rval); - } +if (rval) + goto err_put_device; nvmem->read_only =device_property_present (config->dev,"read-only" ) || config->read_only || !nvmem->reg_write;
@@ -836,7 +834,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)dev_dbg (&nvmem->dev,"Registering nvmem device %s\n" , config->name); - rval =device_register (&nvmem->dev); + rval =device_add (&nvmem->dev);if (rval) goto err_put_device;
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 187/208 nvmem: core: fix registration vs use race
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit ab3428cfd9aa2f3463ee4b2909b5bb2193bd0c4a upstream.
The i.MX6 CPU frequency driver sometimes fails to register at boot time due to nvmem_cell_read_u32() sporadically returning -ENOENT.
This happens because there is a window where __nvmem_device_get() in of_nvmem_cell_get() is able to return the nvmem device, but as cells have been setup, nvmem_find_cell_entry_by_node() returns NULL.
The occurs because the nvmem core registration code violates one of the fundamental principles of kernel programming: do not publish data structures before their setup is complete.
Fix this by making nvmem core code conform with this principle.
--- drivers/nvmem/core.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)
drivers/nvmem/core.c +8 -10
@@ -832,22 +832,16 @@ struct nvmem_device *nvmem_register(cons nvmem->dev.groups = nvmem_dev_groups;#endif -dev_dbg (&nvmem->dev,"Registering nvmem device %s\n" , config->name); - - rval =device_add (&nvmem->dev); -if (rval) - goto err_put_device; -if (nvmem->nkeepout) { rval =nvmem_validate_keepouts (nvmem);if (rval) - goto err_device_del; + goto err_put_device; }if (config->compat) { rval =nvmem_sysfs_setup_compat (nvmem, config);if (rval) - goto err_device_del; + goto err_put_device; }if (config->cells) {
@@ -864,6 +858,12 @@ struct nvmem_device *nvmem_register(consif (rval) goto err_remove_cells; +dev_dbg (&nvmem->dev,"Registering nvmem device %s\n" , config->name); + + rval =device_add (&nvmem->dev); +if (rval) + goto err_remove_cells; +blocking_notifier_call_chain (&nvmem_notifier,NVMEM_ADD , nvmem);return nvmem;
@@ -873,8 +873,6 @@ err_remove_cells: err_teardown_compat:if (config->compat)nvmem_sysfs_remove_compat (nvmem, config); -err_device_del: -device_del (&nvmem->dev); err_put_device:put_device (&nvmem->dev);
Greg Kroah-Hartman
maintainerPATCH 188/208 nvmem: core: fix device node refcounting
In reply to Greg Kroah-HartmanFrom: Michael Walle <[email protected]>
commit edcf2fb660526b5ed29f93bd17328a2b4835c8b2 upstream.
In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places.
--- drivers/nvmem/core.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/nvmem/core.c +8 -3
@@ -1237,16 +1237,21 @@ struct nvmem_cell *of_nvmem_cell_get(strif (!cell_np)return ERR_PTR (-ENOENT ); - nvmem_np =of_get_next_parent (cell_np); -if (!nvmem_np) + nvmem_np =of_get_parent (cell_np); +if (!nvmem_np) { +of_node_put (cell_np);return ERR_PTR (-EINVAL ); + } nvmem =__nvmem_device_get (nvmem_np, device_match_of_node);of_node_put (nvmem_np); -if (IS_ERR (nvmem)) +if (IS_ERR (nvmem)) { +of_node_put (cell_np);return ERR_CAST (nvmem); + } cell_entry =nvmem_find_cell_entry_by_node (nvmem, cell_np); +of_node_put (cell_np);if (!cell_entry) {__nvmem_device_put (nvmem);return ERR_PTR (-ENOENT );
Greg Kroah-Hartman
maintainerPATCH 189/208 nvmem: core: fix cell removal on error
In reply to Greg Kroah-HartmanFrom: Michael Walle <[email protected]>
commit db3546d58b5a0fa581d9c9f2bdc2856fa6c5e43e upstream.
nvmem_add_cells() could return an error after some cells are already added to the provider. In this case, the added cells are not removed. Remove any registered cells if nvmem_add_cells() fails.
--- drivers/nvmem/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/nvmem/core.c +1 -2
@@ -847,7 +847,7 @@ struct nvmem_device *nvmem_register(consif (config->cells) { rval =nvmem_add_cells (nvmem, config->cells, config->ncells);if (rval) - goto err_teardown_compat; + goto err_remove_cells; } rval =nvmem_add_cells_from_table (nvmem);
@@ -870,7 +870,6 @@ struct nvmem_device *nvmem_register(cons err_remove_cells:nvmem_device_remove_all_cells (nvmem); -err_teardown_compat:if (config->compat)nvmem_sysfs_remove_compat (nvmem, config); err_put_device:
Greg Kroah-Hartman
maintainerPATCH 190/208 nvmem: core: fix return value
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 0c4862b1c1465e473bc961a02765490578bf5c20 upstream.
Dan Carpenter points out that the return code was not set in commit 60c8b4aebd8e ("nvmem: core: fix cleanup after dev_set_name()"), but this is not the only issue - we also need to zero wp_gpio to prevent gpiod_put() being called on an error value.
--- drivers/nvmem/core.c | 1 + 1 file changed, 1 insertion(+)
drivers/nvmem/core.c +1 -0
@@ -783,6 +783,7 @@ struct nvmem_device *nvmem_register(cons GPIOD_OUT_HIGH);if (IS_ERR (nvmem->wp_gpio)) { rval =PTR_ERR (nvmem->wp_gpio); + nvmem->wp_gpio =NULL ; goto err_put_device; }
Greg Kroah-Hartman
maintainerPATCH 191/208 phy: qcom-qmp-combo: fix runtime suspend
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit c7b98de745cffdceefc077ad5cf9cda032ef8959 upstream.
Drop the confused runtime-suspend type check which effectively broke runtime PM if the DP child node happens to be parsed before the USB child node during probe (e.g. due to order of child nodes in the devicetree).
Instead use the new driver data USB PHY pointer to access the USB configuration and resources.
--- drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-)
drivers/phy/qualcomm/phy-qcom-qmp-combo.c +2 -10
@@ -2296,15 +2296,11 @@ static void qmp_combo_disable_autonomousstatic int __maybe_unused qmp_combo_runtime_suspend (struct device *dev) {struct qcom_qmp *qmp =dev_get_drvdata (dev); -struct qmp_phy *qphy = qmp->phys[0 ]; +struct qmp_phy *qphy = qmp->usb_phy;const struct qmp_phy_cfg *cfg = qphy->cfg;dev_vdbg (dev,"Suspending QMP phy, mode:%d\n" , qphy->mode); -/* Supported only for USB3 PHY and luckily USB3 is the first phy */ -if (cfg->type !=PHY_TYPE_USB3 ) -return 0 ; -if (!qmp->init_count) {dev_vdbg (dev,"PHY not initialized, bailing out\n" );return 0 ;
@@ -2321,16 +2317,12 @@ static int __maybe_unused qmp_combo_runtstatic int __maybe_unused qmp_combo_runtime_resume (struct device *dev) {struct qcom_qmp *qmp =dev_get_drvdata (dev); -struct qmp_phy *qphy = qmp->phys[0 ]; +struct qmp_phy *qphy = qmp->usb_phy;const struct qmp_phy_cfg *cfg = qphy->cfg;int ret =0 ;dev_vdbg (dev,"Resuming QMP phy, mode:%d\n" , qphy->mode); -/* Supported only for USB3 PHY and luckily USB3 is the first phy */ -if (cfg->type !=PHY_TYPE_USB3 ) -return 0 ; -if (!qmp->init_count) {dev_vdbg (dev,"PHY not initialized, bailing out\n" );return 0 ;
Greg Kroah-Hartman
maintainerPATCH 192/208 serial: 8250_dma: Fix DMA Rx completion race
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit 31352811e13dc2313f101b890fd4b1ce760b5fe7 upstream.
__dma_rx_complete() is called from two places:
- Through the DMA completion callback dma_rx_complete()
- From serial8250_rx_dma_flush() after IIR_RLSI or IIR_RX_TIMEOUT
The former does not hold port's lock during __dma_rx_complete() which allows these two to race and potentially insert the same data twice.
Extend port's lock coverage in dma_rx_complete() to prevent the race and check if the DMA Rx is still pending completion before calling into __dma_rx_complete().
--- drivers/tty/serial/8250/8250_dma.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_dma.c +13 -1
@@ -57,6 +57,18 @@ static void __dma_rx_complete(void *paratty_flip_buffer_push (tty_port); } +static void dma_rx_complete (void *param) +{ +struct uart_8250_port *p = param; +struct uart_8250_dma *dma = p->dma; +unsigned long flags; + +spin_lock_irqsave (&p->port.lock, flags); +if (dma->rx_running) +__dma_rx_complete (p); +spin_unlock_irqrestore (&p->port.lock, flags); +} +int serial8250_tx_dma (struct uart_8250_port *p) {struct uart_8250_dma *dma = p->dma;
@@ -130,7 +142,7 @@ int serial8250_rx_dma(struct uart_8250_preturn -EBUSY ; dma->rx_running =1 ; - desc->callback = __dma_rx_complete; + desc->callback = dma_rx_complete; desc->callback_param = p; dma->rx_cookie =dmaengine_submit (desc);
Greg Kroah-Hartman
maintainerPATCH 193/208 serial: 8250_dma: Fix DMA Rx rearm race
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit 57e9af7831dcf211c5c689c2a6f209f4abdf0bce upstream.
As DMA Rx can be completed from two places, it is possible that DMA Rx completes before DMA completion callback had a chance to complete it. Once the previous DMA Rx has been completed, a new one can be started on the next UART interrupt. The following race is possible (uart_unlock_and_check_sysrq_irqrestore() replaced with spin_unlock_irqrestore() for simplicity/clarity):
CPU0 CPU1
dma_rx_complete()serial8250_handle_irq()
spin_lock_irqsave(&port->lock)
handle_rx_dma()
serial8250_rx_dma_flush()
__dma_rx_complete()
dma->rx_running = 0
// Complete DMA Rx spin_unlock_irqrestore(&port->lock)
serial8250_handle_irq()
spin_lock_irqsave(&port->lock)
handle_rx_dma()
serial8250_rx_dma()
dma->rx_running = 1
// Setup a new DMA Rx spin_unlock_irqrestore(&port->lock)
spin_lock_irqsave(&port->lock) // sees dma->rx_running = 1 __dma_rx_complete() dma->rx_running = 0 // Incorrectly complete // running DMA Rx
This race seems somewhat theoretical to occur for real but handle it correctly regardless. Check what is the DMA status before complething anything in __dma_rx_complete().
--- drivers/tty/serial/8250/8250_dma.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_dma.c +10 -2
@@ -44,15 +44,23 @@ static void __dma_rx_complete(void *parastruct uart_8250_dma *dma = p->dma;struct tty_port *tty_port = &p->port.state->port;struct dma_tx_state state; +enum dma_status dma_status;int count; - dma->rx_running =0 ; -dmaengine_tx_status (dma->rxchan, dma->rx_cookie, &state); +/* +* New DMA Rx can be started during the completion handler before it +* could acquire port's lock and it might still be ongoing. Don't to +* anything in such case. +*/ + dma_status =dmaengine_tx_status (dma->rxchan, dma->rx_cookie, &state); +if (dma_status ==DMA_IN_PROGRESS ) +return ; count = dma->rx_size - state.residue;tty_insert_flip_string (tty_port, dma->rx_buf, count); p->port.icount.rx += count; + dma->rx_running =0 ;tty_flip_buffer_push (tty_port); }
Greg Kroah-Hartman
maintainerPATCH 194/208 platform/x86/amd: pmc: add CONFIG_SERIO dependency
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit abce209d18fd26e865b2406cc68819289db973f9 upstream.
Using the serio subsystem now requires the code to be reachable:
x86_64-linux-ld: drivers/platform/x86/amd/pmc.o: in function `amd_pmc_suspend_handler':
pmc.c:(.text+0x86c): undefined reference to `serio_bus'
Add the usual dependency: as other users of serio use 'select' rather than 'depends on', use the same here.
--- drivers/platform/x86/amd/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/platform/x86/amd/Kconfig +1 -0
@@ -8,6 +8,7 @@ source "drivers/platform/x86/amd/pmf/Kco config AMD_PMC tristate "AMD SoC PMC driver" depends on ACPI && PCI && RTC_CLASS + select SERIO help The driver provides support for AMD Power Management Controller primarily responsible for S2Idle transactions that are driven from
Greg Kroah-Hartman
maintainerPATCH 195/208 ASoC: SOF: sof-audio: prepare_widgets: Check swidget for NULL on sink failure
In reply to Greg Kroah-HartmanFrom: Peter Ujfalusi <[email protected]>
commit fb4293600cc651cfe4d48ec489f1d175adf6e2f8 upstream.
If the swidget is NULL we skip the preparing of the widget and jump to handle the sink path of the widget.
If the prepare fails in this case we would undo the prepare but the swidget is NULL (we skipped the prepare for the widget).
To avoid NULL pointer dereference in this case we must check swidget against NULL pointer once again.
--- sound/soc/sof/sof-audio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/sof/sof-audio.c +2 -1
@@ -327,7 +327,8 @@ sink_prepare: p->walking = false;if (ret <0 ) {/* unprepare the source widget */ -if (widget_ops[widget->id].ipc_unprepare && swidget->prepared) { +if (widget_ops[widget->id].ipc_unprepare && + swidget && swidget->prepared) { widget_ops[widget->id].ipc_unprepare (swidget); swidget->prepared = false; }
Greg Kroah-Hartman
maintainerPATCH 196/208 iio:adc:twl6030: Enable measurement of VAC
In reply to Greg Kroah-HartmanFrom: Andreas Kemnade <[email protected]>
commit bffb7d9d1a3dbd09e083b88aefd093b3b10abbfb upstream.
VAC needs to be wired up to produce proper measurements, without this change only near zero values are reported.
--- drivers/iio/adc/twl6030-gpadc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/twl6030-gpadc.c +1 -1
@@ -952,7 +952,7 @@ static int twl6030_gpadc_probe(struct pl } ret =twl_i2c_write_u8 (TWL6030_MODULE_ID0 , -VBAT_MEAS |BB_MEAS |BB_MEAS , +VBAT_MEAS |BB_MEAS |VAC_MEAS ,TWL6030_MISC1 );if (ret <0 ) {dev_err (dev,"failed to wire up inputs\n" );
Greg Kroah-Hartman
maintainerPATCH 197/208 powerpc/64s/radix: Fix crash with unaligned relocated kernel
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 98d0219e043e09013e883eacde3b93e0b2bf944d upstream.
If a relocatable kernel is loaded at an address that is not 2MB aligned and told not to relocate to zero, the kernel can crash due to mark_rodata_ro() incorrectly changing some read-write data to read-only.
Scenarios where the misalignment can occur are when the kernel is loaded by kdump or using the RELOCATABLE_TEST config option.
Example crash with the kernel loaded at 5MB:
Run /sbin/init as init process
BUG: Unable to handle kernel data access on write at 0xc000000000452000
Faulting instruction address: 0xc0000000005b6730
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
CPU: 1 PID: 1 Comm: init Not tainted 6.2.0-rc1-00011-g349188be4841 #166
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,git-5b4c5a hv:linux,kvm pSeries
NIP: c0000000005b6730 LR: c000000000ae9ab8 CTR: 0000000000000380
REGS: c000000004503250 TRAP: 0300 Not tainted (6.2.0-rc1-00011-g349188be4841)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 44288480 XER: 00000000
CFAR: c0000000005b66ec DAR: c000000000452000 DSISR: 0a000000 IRQMASK: 0
...
NIP memset+0x68/0x104
LR zero_user_segments.constprop.0+0xa8/0xf0
Call Trace:
ext4_mpage_readpages+0x7f8/0x830
ext4_readahead+0x48/0x60
read_pages+0xb8/0x380
page_cache_ra_unbounded+0x19c/0x250
filemap_fault+0x58c/0xae0
__do_fault+0x60/0x100
__handle_mm_fault+0x1230/0x1a40
handle_mm_fault+0x120/0x300
___do_page_fault+0x20c/0xa80
do_page_fault+0x30/0xc0
data_access_common_virt+0x210/0x220This happens because mark_rodata_ro() tries to change permissions on the range _stext..__end_rodata, but _stext sits in the middle of the 2MB page from 4MB to 6MB:
radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
radix-mmu: Mapped 0x0000000000400000-0x0000000002400000 with 2.00 MiB pages (exec)
The logic that changes the permissions assumes the linear mapping was split correctly at boot, so it marks the entire 2MB page read-only. That leads to the write fault above.
To fix it, the boot time mapping logic needs to consider that if the kernel is running at a non-zero address then _stext is a boundary where it must split the mapping.
That leads to the mapping being split correctly, allowing the rodata permission change to take happen correctly, with no spillover:
radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
radix-mmu: Mapped 0x0000000000400000-0x0000000000500000 with 64.0 KiB pages
radix-mmu: Mapped 0x0000000000500000-0x0000000000600000 with 64.0 KiB pages (exec)
radix-mmu: Mapped 0x0000000000600000-0x0000000002400000 with 2.00 MiB pages (exec)
If the kernel is loaded at a 2MB aligned address, the mapping continues to use 2MB pages as before:
radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
radix-mmu: Mapped 0x0000000000400000-0x0000000002c00000 with 2.00 MiB pages (exec)
radix-mmu: Mapped 0x0000000002c00000-0x0000000100000000 with 2.00 MiB pages
--- arch/powerpc/mm/book3s64/radix_pgtable.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/powerpc/mm/book3s64/radix_pgtable.c +11 -0
@@ -262,6 +262,17 @@ print_mapping(unsigned long start, unsigstatic unsigned long next_boundary (unsigned long addr,unsigned long end) {#ifdef CONFIG_STRICT_KERNEL_RWX +unsigned long stext_phys; + + stext_phys =__pa_symbol (_stext); + +// Relocatable kernel running at non-zero real address +if (stext_phys !=0 ) { +// Start of relocated kernel text is a rodata boundary +if (addr < stext_phys) +return stext_phys; + } +if (addr <__pa_symbol (__srwx_boundary))return __pa_symbol (__srwx_boundary);#endif
Greg Kroah-Hartman
maintainerPATCH 198/208 powerpc/64s: Fix local irq disable when PMIs are disabled
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit bc88ef663265676419555df2dc469a471c0add31 upstream.
When PMI interrupts are soft-masked, local_irq_save() will clear the PMI mask bit, allowing PMIs in and causing a race condition. This causes a deadlock in native_hpte_insert via hash_preload, which depends on PMIs being disabled since commit 8b91cee5eadd ("powerpc/64s/hash: Make hash faults work in NMI context"). native_hpte_insert calls local_irq_save(). It's possible the lpar hash code is also affected when tracing is enabled because __trace_hcall_entry() calls local_irq_save().
Fix this by making arch_local_irq_save() _or_ the IRQS_DISABLED bit into the mask.
This was found with the stress_hpt option with a kbuild workload running together with perf record -g.
--- arch/powerpc/include/asm/hw_irq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/include/asm/hw_irq.h +1 -1
@@ -192,7 +192,7 @@ static inline void arch_local_irq_enable(void)static inline unsigned long arch_local_irq_save (void ) { -return irq_soft_mask_set_return (IRQS_DISABLED ); +return irq_soft_mask_or_return (IRQS_DISABLED ); }static inline bool arch_irqs_disabled_flags (unsigned long flags)
Signature · 1 line
2.39.1
Greg Kroah-Hartman
maintainerPATCH 199/208 powerpc/imc-pmu: Revert nest_init_lock to being a mutex
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit ad53db4acb415976761d7302f5b02e97f2bd097e upstream.
The recent commit 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled section") fixed warnings (and possible deadlocks) in the IMC PMU driver by converting the locking to use spinlocks.
It also converted the init-time nest_init_lock to a spinlock, even though it's not used at runtime in IRQ disabled sections or while holding other spinlocks.
This leads to warnings such as:
BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:49
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 1, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc2-14719-gf12cd06109f4-dirty #1
Hardware name: Mambo,Simulated-System POWER9 0x4e1203 opal:v6.6.6 PowerNV
Call Trace:
dump_stack_lvl+0x74/0xa8 (unreliable)
__might_resched+0x178/0x1a0
__cpuhp_setup_state+0x64/0x1e0
init_imc_pmu+0xe48/0x1250
opal_imc_counters_probe+0x30c/0x6a0
platform_probe+0x78/0x110
really_probe+0x104/0x420
__driver_probe_device+0xb0/0x170
driver_probe_device+0x58/0x180
__driver_attach+0xd8/0x250
bus_for_each_dev+0xb4/0x140
driver_attach+0x34/0x50
bus_add_driver+0x1e8/0x2d0
driver_register+0xb4/0x1c0
__platform_driver_register+0x38/0x50
opal_imc_driver_init+0x2c/0x40
do_one_initcall+0x80/0x360
kernel_init_freeable+0x310/0x3b8
kernel_init+0x30/0x1a0
ret_from_kernel_thread+0x5c/0x64Fix it by converting nest_init_lock back to a mutex, so that we can call sleeping functions while holding it. There is no interaction between nest_init_lock and the runtime spinlocks used by the actual PMU routines.
--- arch/powerpc/perf/imc-pmu.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
arch/powerpc/perf/imc-pmu.c +7 -7
@@ -22,7 +22,7 @@* Used to avoid races in counting the nest-pmu units during hotplug * register and unregister */ -static DEFINE_SPINLOCK (nest_init_lock); +static DEFINE_MUTEX (nest_init_lock); static DEFINE_PER_CPU(struct imc_pmu_ref *, local_nest_imc_refc);static struct imc_pmu **per_nest_pmu_arr;static cpumask_t nest_imc_cpumask;
@@ -1629,7 +1629,7 @@ static void imc_common_mem_free(struct istatic void imc_common_cpuhp_mem_free (struct imc_pmu *pmu_ptr) {if (pmu_ptr->domain ==IMC_DOMAIN_NEST ) { -spin_lock (&nest_init_lock); +mutex_lock (&nest_init_lock);if (nest_pmus ==1 ) {cpuhp_remove_state (CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE );kfree (nest_imc_refc);
@@ -1639,7 +1639,7 @@ static void imc_common_cpuhp_mem_free(stif (nest_pmus >0 ) nest_pmus--; -spin_unlock (&nest_init_lock); +mutex_unlock (&nest_init_lock); }/* Free core_imc memory */
@@ -1796,11 +1796,11 @@ int init_imc_pmu(struct device_node *par* rest. To handle the cpuhotplug callback unregister, we track * the number of nest pmus in "nest_pmus". */ -spin_lock (&nest_init_lock); +mutex_lock (&nest_init_lock);if (nest_pmus ==0 ) { ret =init_nest_pmu_ref ();if (ret) { -spin_unlock (&nest_init_lock); +mutex_unlock (&nest_init_lock);kfree (per_nest_pmu_arr); per_nest_pmu_arr =NULL ; goto err_free_mem;
@@ -1808,7 +1808,7 @@ int init_imc_pmu(struct device_node *par/* Register for cpu hotplug notification. */ ret =nest_pmu_cpumask_init ();if (ret) { -spin_unlock (&nest_init_lock); +mutex_unlock (&nest_init_lock);kfree (nest_imc_refc);kfree (per_nest_pmu_arr); per_nest_pmu_arr =NULL ;
@@ -1816,7 +1816,7 @@ int init_imc_pmu(struct device_node *par } } nest_pmus++; -spin_unlock (&nest_init_lock); +mutex_unlock (&nest_init_lock);break ;case IMC_DOMAIN_CORE : ret =core_imc_pmu_cpumask_init ();
Greg Kroah-Hartman
maintainerPATCH 200/208 fs/ntfs3: Validate attribute data and valid sizes
In reply to Greg Kroah-HartmanFrom: Abdun Nihaal <[email protected]>
commit 019d22eb0eb707fc099e6e8fad9b3933236a06d0 upstream.
The data_size and valid_size fields of non resident attributes should be less than the its alloc_size field, but this is not checked in ntfs_read_mft function.
Syzbot reports a allocation order warning due to a large unchecked value of data_size getting assigned to inode->i_size which is then passed to kcalloc.
Add sanity check for ensuring that the data_size and valid_size fields are not larger than alloc_size field.
--- fs/ntfs3/inode.c | 7 +++++++ 1 file changed, 7 insertions(+)
fs/ntfs3/inode.c +7 -0
@@ -132,6 +132,13 @@ next_attr:if (le16_to_cpu (attr->name_off) + attr->name_len > asize) goto out; +if (attr->non_res) { + t64 =le64_to_cpu (attr->nres.alloc_size); +if (le64_to_cpu (attr->nres.data_size) > t64 || +le64_to_cpu (attr->nres.valid_size) > t64) + goto out; + } +switch (attr->type) {case ATTR_STD : if (attr->non_res ||
Greg Kroah-Hartman
maintainerPATCH 201/208 ovl: Use "buf" flexible array for memcpy() destination
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
commit cf8aa9bf97cadf85745506c6a3e244b22c268d63 upstream.
The "buf" flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening:
memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)
--- fs/overlayfs/export.c | 2 +- fs/overlayfs/overlayfs.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
fs/overlayfs/export.c +1 -1
@@ -796,7 +796,7 @@ static struct ovl_fh *ovl_fid_to_fh(strureturn ERR_PTR (-ENOMEM );/* Copy unaligned inner fh into aligned buffer */ -memcpy (&fh->fb, fid, buflen -OVL_FH_WIRE_OFFSET ); +memcpy (fh->buf, fid, buflen -OVL_FH_WIRE_OFFSET );return fh; }
fs/overlayfs/overlayfs.h +1 -1
@@ -108,7 +108,7 @@ struct ovl_fh {u8 padding[3 ];/* make sure fb.fid is 32bit aligned */ union {struct ovl_fb fb; -u8 buf[0 ]; + DECLARE_FLEX_ARRAY(u8, buf); }; } __packed;
Greg Kroah-Hartman
maintainerPATCH 202/208 f2fs: initialize locks earlier in f2fs_fill_super()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
commit 92b4cf5b48955a4bdd15fe4e2067db8ebd87f04c upstream.
syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation.
--- fs/f2fs/super.c | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-)
fs/f2fs/super.c +20 -18
@@ -4095,6 +4095,24 @@ try_onemore: sbi->sb = sb; +/* initialize locks within allocated memory */ +init_f2fs_rwsem (&sbi->gc_lock); +mutex_init (&sbi->writepages); +init_f2fs_rwsem (&sbi->cp_global_sem); +init_f2fs_rwsem (&sbi->node_write); +init_f2fs_rwsem (&sbi->node_change); +spin_lock_init (&sbi->stat_lock); +init_f2fs_rwsem (&sbi->cp_rwsem); +init_f2fs_rwsem (&sbi->quota_sem); +init_waitqueue_head (&sbi->cp_wait); +spin_lock_init (&sbi->error_lock); + +for (i =0 ; i <NR_INODE_TYPE ; i++) { +INIT_LIST_HEAD (&sbi->inode_list[i]); +spin_lock_init (&sbi->inode_lock[i]); + } +mutex_init (&sbi->flush_lock); +/* Load the checksum driver */ sbi->s_chksum_driver =crypto_alloc_shash ("crc32" ,0 ,0 );if (IS_ERR (sbi->s_chksum_driver)) {
@@ -4118,6 +4136,8 @@ try_onemore: sb->s_fs_info = sbi; sbi->raw_super = raw_super; +memcpy (sbi->errors, raw_super->s_errors,MAX_F2FS_ERRORS ); +/* precompute checksum seed for metadata */ if (f2fs_sb_has_inode_chksum (sbi)) sbi->s_chksum_seed = f2fs_chksum(sbi, ~0, raw_super->uuid,
@@ -4174,26 +4194,14 @@ try_onemore:/* init f2fs-specific super block info */ sbi->valid_super_block = valid_super_block; -init_f2fs_rwsem (&sbi->gc_lock); -mutex_init (&sbi->writepages); -init_f2fs_rwsem (&sbi->cp_global_sem); -init_f2fs_rwsem (&sbi->node_write); -init_f2fs_rwsem (&sbi->node_change);/* disallow all the data/node/meta page writes */ set_sbi_flag (sbi,SBI_POR_DOING ); -spin_lock_init (&sbi->stat_lock); err =f2fs_init_write_merge_io (sbi);if (err) goto free_bio_info; -spin_lock_init (&sbi->error_lock); -memcpy (sbi->errors, raw_super->s_errors,MAX_F2FS_ERRORS ); - -init_f2fs_rwsem (&sbi->cp_rwsem); -init_f2fs_rwsem (&sbi->quota_sem); -init_waitqueue_head (&sbi->cp_wait);init_sb_info (sbi); err =f2fs_init_iostat (sbi);
@@ -4271,12 +4279,6 @@ try_onemore:limit_reserve_root (sbi);adjust_unusable_cap_perc (sbi); -for (i =0 ; i <NR_INODE_TYPE ; i++) { -INIT_LIST_HEAD (&sbi->inode_list[i]); -spin_lock_init (&sbi->inode_lock[i]); - } -mutex_init (&sbi->flush_lock); -f2fs_init_extent_cache_info (sbi);f2fs_init_ino_entry_info (sbi);
Greg Kroah-Hartman
maintainerPATCH 203/208 fbdev: smscufx: fix error handling code in ufx_usb_probe
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 upstream.
The current error handling code in ufx_usb_probe have many unmatching issues, e.g., missing ufx_free_usb_list, destroy_modedb label should only include framebuffer_release, fb_dealloc_cmap only matches fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.............
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................
backtrace:
[<ffffffff814c99a0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[<ffffffff824d219c>] kmalloc include/linux/slab.h:553 [inline]
[<ffffffff824d219c>] kzalloc include/linux/slab.h:689 [inline]
[<ffffffff824d219c>] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]
[<ffffffff824d219c>] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655
[<ffffffff82d17927>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[<ffffffff827132da>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[<ffffffff82713c27>] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[<ffffffff82710137>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff827136b5>] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[<ffffffff82711d36>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[<ffffffff8270e242>] device_add+0x642/0xdc0 drivers/base/core.c:3517
[<ffffffff82d14d5f>] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170
[<ffffffff82d2576c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
[<ffffffff82d16ffc>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778Fix this bug by rewriting the error handling code in ufx_usb_probe.
--- drivers/video/fbdev/smscufx.c | 46 ++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 15 deletions(-)
drivers/video/fbdev/smscufx.c +31 -15
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_intestruct usb_device *usbdev;struct ufx_data *dev;struct fb_info *info; -int retval; +int retval = -ENOMEM ;u32 id_rev, fpga_rev;/* usb initialization */
@@ -1654,15 +1654,17 @@ static int ufx_usb_probe(struct usb_inteif (!ufx_alloc_urb_list (dev,WRITES_IN_FLIGHT ,MAX_TRANSFER )) {dev_err (dev->gdev,"ufx_alloc_urb_list failed\n" ); - goto e_nomem; + goto put_ref; }/* We don't register a new USB class. Our client interface is fbdev */ /* allocates framebuffer driver structure, not framebuffer memory */ info =framebuffer_alloc (0 , &usbdev->dev); -if (!info) - goto e_nomem; +if (!info) { +dev_err (dev->gdev,"framebuffer_alloc failed\n" ); + goto free_urb_list; + } dev->info = info; info->par = dev;
@@ -1705,22 +1707,34 @@ static int ufx_usb_probe(struct usb_intecheck_warn_goto_error (retval,"unable to find common mode for display and adapter" ); retval =ufx_reg_set_bits (dev,0x4000 ,0x00000001 ); -check_warn_goto_error (retval,"error %d enabling graphics engine" , retval); +if (retval <0 ) { +dev_err (dev->gdev,"error %d enabling graphics engine" , retval); + goto setup_modes; + }/* ready to begin using device */ atomic_set (&dev->usb_active,1 );dev_dbg (dev->gdev,"checking var" ); retval =ufx_ops_check_var (&info->var, info); -check_warn_goto_error (retval,"error %d ufx_ops_check_var" , retval); +if (retval <0 ) { +dev_err (dev->gdev,"error %d ufx_ops_check_var" , retval); + goto reset_active; + }dev_dbg (dev->gdev,"setting par" ); retval =ufx_ops_set_par (info); -check_warn_goto_error (retval,"error %d ufx_ops_set_par" , retval); +if (retval <0 ) { +dev_err (dev->gdev,"error %d ufx_ops_set_par" , retval); + goto reset_active; + }dev_dbg (dev->gdev,"registering framebuffer" ); retval =register_framebuffer (info); -check_warn_goto_error (retval,"error %d register_framebuffer" , retval); +if (retval <0 ) { +dev_err (dev->gdev,"error %d register_framebuffer" , retval); + goto reset_active; + } dev_info(dev->gdev, "SMSC UDX USB device /dev/fb%d attached. %dx%d resolution." " Using %dK framebuffer memory\n", info->node,
@@ -1728,21 +1742,23 @@ static int ufx_usb_probe(struct usb_intereturn 0 ; -error: -fb_dealloc_cmap (&info->cmap); -destroy_modedb: +reset_active: +atomic_set (&dev->usb_active,0 ); +setup_modes:fb_destroy_modedb (info->monspecs.modedb);vfree (info->screen_base);fb_destroy_modelist (&info->modelist); +error: +fb_dealloc_cmap (&info->cmap); +destroy_modedb:framebuffer_release (info); +free_urb_list: +if (dev->urbs.count >0 ) +ufx_free_urb_list (dev); put_ref:kref_put (&dev->kref, ufx_free);/* ref for framebuffer */ kref_put (&dev->kref, ufx_free);/* last ref from kref_init */ return retval; - -e_nomem: - retval = -ENOMEM ; - goto put_ref; }static void ufx_usb_disconnect (struct usb_interface *interface)
Greg Kroah-Hartman
maintainerPATCH 204/208 f2fs: fix to do sanity check on i_extra_isize in is_alive()
In reply to Greg Kroah-HartmanFrom: Chao Yu <[email protected]>
commit d3b7b4afd6b2c344eabf9cc26b8bfa903c164c7c upstream.
syzbot found a f2fs bug:
BUG: KASAN: slab-out-of-bounds in data_blkaddr fs/f2fs/f2fs.h:2891 [inline] BUG: KASAN: slab-out-of-bounds in is_alive fs/f2fs/gc.c:1117 [inline] BUG: KASAN: slab-out-of-bounds in gc_data_segment fs/f2fs/gc.c:1520 [inline] BUG: KASAN: slab-out-of-bounds in do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 Read of size 4 at addr ffff888076557568 by task kworker/u4:3/52 CPU: 1 PID: 52 Comm: kworker/u4:3 Not tainted 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbb/0x1f0 mm/kasan/report.c:495 data_blkaddr fs/f2fs/f2fs.h:2891 [inline] is_alive fs/f2fs/gc.c:1117 [inline] gc_data_segment fs/f2fs/gc.c:1520 [inline] do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 f2fs_gc+0x88c/0x20a0 fs/f2fs/gc.c:1831 f2fs_balance_fs+0x544/0x6b0 fs/f2fs/segment.c:410 f2fs_write_inode+0x57e/0xe20 fs/f2fs/inode.c:753 write_inode fs/fs-writeback.c:1440 [inline] __writeback_single_inode+0xcfc/0x1440 fs/fs-writeback.c:1652 writeback_sb_inodes+0x54d/0xf90 fs/fs-writeback.c:1870 wb_writeback+0x2c5/0xd70 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x2dc/0x12f0 fs/fs-writeback.c:2227 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
The root cause is that we forgot to do sanity check on .i_extra_isize in below path, result in accessing invalid address later, fix it.
- gc_data_segment
- is_alive
- data_blkaddr
- offset_in_addr
--- fs/f2fs/gc.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
fs/f2fs/gc.c +12 -6
@@ -1078,7 +1078,7 @@ static bool is_alive(struct f2fs_sb_info {struct page *node_page;nid_t nid; -unsigned int ofs_in_node, max_addrs; +unsigned int ofs_in_node, max_addrs, base;block_t source_blkaddr; nid =le32_to_cpu (sum->nid);
@@ -1104,11 +1104,17 @@ static bool is_alive(struct f2fs_sb_inforeturn false; } - max_addrs =IS_INODE (node_page) ?DEF_ADDRS_PER_INODE : -DEF_ADDRS_PER_BLOCK ; -if (ofs_in_node >= max_addrs) { -f2fs_err (sbi,"Inconsistent ofs_in_node:%u in summary, ino:%u, nid:%u, max:%u" , - ofs_in_node, dni->ino, dni->nid, max_addrs); +if (IS_INODE (node_page)) { + base =offset_in_addr (F2FS_INODE (node_page)); + max_addrs =DEF_ADDRS_PER_INODE ; + }else { + base =0 ; + max_addrs =DEF_ADDRS_PER_BLOCK ; + } + +if (base + ofs_in_node >= max_addrs) { +f2fs_err (sbi,"Inconsistent blkaddr offset: base:%u, ofs_in_node:%u, max:%u, ino:%u, nid:%u" , + base, ofs_in_node, max_addrs, dni->ino, dni->nid);f2fs_put_page (node_page,1 );return false; }
Greg Kroah-Hartman
maintainerPATCH 205/208 wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads
In reply to Greg Kroah-HartmanFrom: Minsuk Kang <[email protected]>
commit 4920ab131b2dbae7464b72bdcac465d070254209 upstream.
This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmf_setup_wiphybands() or brcmf_cfg80211_attach().
Found by a modified version of syzkaller.
Crash Report from brcmf_construct_chaninfo():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888115f24000, ffff888115f24800)
Memory state around the buggy address:
ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================Crash Report from brcmf_enable_bw40_2g():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_cfg80211_attach+0x3d11/0x3fd0 Read of size 4 at addr ffff888103787600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_cfg80211_attach+0x3d11/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_cfg80211_attach+0x3302/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888103787000 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888103787000, ffff888103787800)
Memory state around the buggy address:
ffff888103787500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888103787580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888103787600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888103787680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888103787700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 17 ++++++++++++ 1 file changed, 17 insertions(+)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +17 -0
@@ -91,6 +91,9 @@#define BRCMF_ASSOC_PARAMS_FIXED_SIZE \ (sizeof(struct brcmf_assoc_params_le) - sizeof(u16)) +#define BRCMF_MAX_CHANSPEC_LIST \ + (BRCMF_DCMD_MEDLEN / sizeof(__le32) - 1) +static bool check_vif_up (struct brcmf_cfg80211_vif *vif) {if (!test_bit (BRCMF_VIF_STATUS_READY , &vif->sme_state)) {
@@ -6556,6 +6559,13 @@ static int brcmf_construct_chaninfo(stru band->channels[i].flags =IEEE80211_CHAN_DISABLED ; total =le32_to_cpu (list->count); +if (total >BRCMF_MAX_CHANSPEC_LIST ) { +bphy_err (drvr,"Invalid count of channel Spec. (%u)\n" , + total); + err = -EINVAL ; + goto fail_pbuf; + } +for (i =0 ; i < total; i++) { ch.chspec = (u16 )le32_to_cpu (list->element[i]); cfg->d11inf.decchspec (&ch);
@@ -6701,6 +6711,13 @@ static int brcmf_enable_bw40_2g(struct b band =cfg_to_wiphy (cfg)->bands[NL80211_BAND_2GHZ ]; list = (struct brcmf_chanspec_list *)pbuf; num_chan =le32_to_cpu (list->count); +if (num_chan >BRCMF_MAX_CHANSPEC_LIST ) { +bphy_err (drvr,"Invalid count of channel Spec. (%u)\n" , + num_chan); +kfree (pbuf); +return -EINVAL ; + } +for (i =0 ; i < num_chan; i++) { ch.chspec = (u16 )le32_to_cpu (list->element[i]); cfg->d11inf.decchspec (&ch);
Greg Kroah-Hartman
maintainerPATCH 206/208 gfs2: Cosmetic gfs2_dinode_{in,out} cleanup
In reply to Greg Kroah-HartmanFrom: Andreas Gruenbacher <[email protected]>
commit 7db354444ad8429e660b0f8145d425285d4f90ff upstream.
In each of the two functions, add an inode variable that points to &ip->i_inode and use that throughout the rest of the function.
--- fs/gfs2/glops.c | 41 +++++++++++++++++++++-------------------- fs/gfs2/super.c | 27 ++++++++++++++------------- 2 files changed, 35 insertions(+), 33 deletions(-)
fs/gfs2/glops.c +21 -20
@@ -397,38 +397,39 @@ static int gfs2_dinode_in(struct gfs2_instruct timespec64 atime;u16 height, depth;umode_t mode =be32_to_cpu (str->di_mode); -bool is_new = ip->i_inode.i_state &I_NEW ; +struct inode *inode = &ip->i_inode; +bool is_new = inode->i_state &I_NEW ;if (unlikely (ip->i_no_addr !=be64_to_cpu (str->di_num.no_addr))) goto corrupt; -if (unlikely (!is_new &&inode_wrong_type (&ip->i_inode, mode))) +if (unlikely (!is_new &&inode_wrong_type (inode, mode))) goto corrupt; ip->i_no_formal_ino =be64_to_cpu (str->di_num.no_formal_ino); - ip->i_inode.i_mode = mode; + inode->i_mode = mode;if (is_new) { - ip->i_inode.i_rdev =0 ; + inode->i_rdev =0 ;switch (mode &S_IFMT ) {case S_IFBLK :case S_IFCHR : - ip->i_inode.i_rdev =MKDEV (be32_to_cpu (str->di_major), -be32_to_cpu (str->di_minor)); + inode->i_rdev =MKDEV (be32_to_cpu (str->di_major), +be32_to_cpu (str->di_minor));break ; } } -i_uid_write (&ip->i_inode,be32_to_cpu (str->di_uid)); -i_gid_write (&ip->i_inode,be32_to_cpu (str->di_gid)); -set_nlink (&ip->i_inode,be32_to_cpu (str->di_nlink)); -i_size_write (&ip->i_inode,be64_to_cpu (str->di_size)); -gfs2_set_inode_blocks (&ip->i_inode,be64_to_cpu (str->di_blocks)); +i_uid_write (inode,be32_to_cpu (str->di_uid)); +i_gid_write (inode,be32_to_cpu (str->di_gid)); +set_nlink (inode,be32_to_cpu (str->di_nlink)); +i_size_write (inode,be64_to_cpu (str->di_size)); +gfs2_set_inode_blocks (inode,be64_to_cpu (str->di_blocks)); atime.tv_sec =be64_to_cpu (str->di_atime); atime.tv_nsec =be32_to_cpu (str->di_atime_nsec); -if (timespec64_compare (&ip->i_inode.i_atime, &atime) <0 ) - ip->i_inode.i_atime = atime; - ip->i_inode.i_mtime.tv_sec =be64_to_cpu (str->di_mtime); - ip->i_inode.i_mtime.tv_nsec =be32_to_cpu (str->di_mtime_nsec); - ip->i_inode.i_ctime.tv_sec =be64_to_cpu (str->di_ctime); - ip->i_inode.i_ctime.tv_nsec =be32_to_cpu (str->di_ctime_nsec); +if (timespec64_compare (&inode->i_atime, &atime) <0 ) + inode->i_atime = atime; + inode->i_mtime.tv_sec =be64_to_cpu (str->di_mtime); + inode->i_mtime.tv_nsec =be32_to_cpu (str->di_mtime_nsec); + inode->i_ctime.tv_sec =be64_to_cpu (str->di_ctime); + inode->i_ctime.tv_nsec =be32_to_cpu (str->di_ctime_nsec); ip->i_goal =be64_to_cpu (str->di_goal_meta); ip->i_generation =be64_to_cpu (str->di_generation);
@@ -436,7 +437,7 @@ static int gfs2_dinode_in(struct gfs2_in ip->i_diskflags =be32_to_cpu (str->di_flags); ip->i_eattr =be64_to_cpu (str->di_eattr);/* i_diskflags and i_eattr must be set before gfs2_set_inode_flags() */ -gfs2_set_inode_flags (&ip->i_inode); +gfs2_set_inode_flags (inode); height =be16_to_cpu (str->di_height);if (unlikely (height >GFS2_MAX_META_HEIGHT )) goto corrupt;
@@ -448,8 +449,8 @@ static int gfs2_dinode_in(struct gfs2_in ip->i_depth = (u8 )depth; ip->i_entries =be32_to_cpu (str->di_entries); -if (S_ISREG (ip->i_inode.i_mode)) -gfs2_set_aops (&ip->i_inode); +if (S_ISREG (inode->i_mode)) +gfs2_set_aops (inode);return 0 ; corrupt:
fs/gfs2/super.c +14 -13
@@ -379,6 +379,7 @@ out:void gfs2_dinode_out (const struct gfs2_inode *ip,void *buf) { +const struct inode *inode = &ip->i_inode;struct gfs2_dinode *str = buf; str->di_header.mh_magic =cpu_to_be32 (GFS2_MAGIC );
@@ -386,15 +387,15 @@ void gfs2_dinode_out(const struct gfs2_i str->di_header.mh_format =cpu_to_be32 (GFS2_FORMAT_DI ); str->di_num.no_addr =cpu_to_be64 (ip->i_no_addr); str->di_num.no_formal_ino =cpu_to_be64 (ip->i_no_formal_ino); - str->di_mode =cpu_to_be32 (ip->i_inode.i_mode); - str->di_uid =cpu_to_be32 (i_uid_read (&ip->i_inode)); - str->di_gid =cpu_to_be32 (i_gid_read (&ip->i_inode)); - str->di_nlink =cpu_to_be32 (ip->i_inode.i_nlink); - str->di_size =cpu_to_be64 (i_size_read (&ip->i_inode)); - str->di_blocks =cpu_to_be64 (gfs2_get_inode_blocks (&ip->i_inode)); - str->di_atime =cpu_to_be64 (ip->i_inode.i_atime.tv_sec); - str->di_mtime =cpu_to_be64 (ip->i_inode.i_mtime.tv_sec); - str->di_ctime =cpu_to_be64 (ip->i_inode.i_ctime.tv_sec); + str->di_mode =cpu_to_be32 (inode->i_mode); + str->di_uid =cpu_to_be32 (i_uid_read (inode)); + str->di_gid =cpu_to_be32 (i_gid_read (inode)); + str->di_nlink =cpu_to_be32 (inode->i_nlink); + str->di_size =cpu_to_be64 (i_size_read (inode)); + str->di_blocks =cpu_to_be64 (gfs2_get_inode_blocks (inode)); + str->di_atime =cpu_to_be64 (inode->i_atime.tv_sec); + str->di_mtime =cpu_to_be64 (inode->i_mtime.tv_sec); + str->di_ctime =cpu_to_be64 (inode->i_ctime.tv_sec); str->di_goal_meta =cpu_to_be64 (ip->i_goal); str->di_goal_data =cpu_to_be64 (ip->i_goal);
@@ -402,16 +403,16 @@ void gfs2_dinode_out(const struct gfs2_i str->di_flags =cpu_to_be32 (ip->i_diskflags); str->di_height =cpu_to_be16 (ip->i_height); - str->di_payload_format =cpu_to_be32 (S_ISDIR (ip->i_inode.i_mode) && + str->di_payload_format =cpu_to_be32 (S_ISDIR (inode->i_mode) && !(ip->i_diskflags &GFS2_DIF_EXHASH ) ?GFS2_FORMAT_DE :0 ); str->di_depth =cpu_to_be16 (ip->i_depth); str->di_entries =cpu_to_be32 (ip->i_entries); str->di_eattr =cpu_to_be64 (ip->i_eattr); - str->di_atime_nsec =cpu_to_be32 (ip->i_inode.i_atime.tv_nsec); - str->di_mtime_nsec =cpu_to_be32 (ip->i_inode.i_mtime.tv_nsec); - str->di_ctime_nsec =cpu_to_be32 (ip->i_inode.i_ctime.tv_nsec); + str->di_atime_nsec =cpu_to_be32 (inode->i_atime.tv_nsec); + str->di_mtime_nsec =cpu_to_be32 (inode->i_mtime.tv_nsec); + str->di_ctime_nsec =cpu_to_be32 (inode->i_ctime.tv_nsec); }/**
Greg Kroah-Hartman
maintainerPATCH 207/208 gfs2: Always check inode size of inline inodes
In reply to Greg Kroah-HartmanFrom: Andreas Gruenbacher <[email protected]>
commit 70376c7ff31221f1d21db5611d8209e677781d3a upstream.
Check if the inode size of stuffed (inline) inodes is within the allowed range when reading inodes from disk (gfs2_dinode_in()). This prevents us from on-disk corruption.
The two checks in stuffed_readpage() and gfs2_unstuffer_page() that just truncate inline data to the maximum allowed size don't actually make sense, and they can be removed now as well.
--- fs/gfs2/aops.c | 2 -- fs/gfs2/bmap.c | 3 --- fs/gfs2/glops.c | 3 +++ 3 files changed, 3 insertions(+), 5 deletions(-)
fs/gfs2/aops.c +0 -2
@@ -427,8 +427,6 @@ static int stuffed_readpage(struct gfs2_return error; kaddr =kmap_atomic (page); -if (dsize >gfs2_max_stuffed_size (ip)) - dsize =gfs2_max_stuffed_size (ip);memcpy (kaddr, dibh->b_data +sizeof (struct gfs2_dinode ), dsize);memset (kaddr + dsize,0 ,PAGE_SIZE - dsize);kunmap_atomic (kaddr);
fs/gfs2/bmap.c +0 -3
@@ -61,9 +61,6 @@ static int gfs2_unstuffer_page(struct gfvoid *kaddr =kmap (page);u64 dsize =i_size_read (inode); -if (dsize >gfs2_max_stuffed_size (ip)) - dsize =gfs2_max_stuffed_size (ip); -memcpy (kaddr, dibh->b_data +sizeof (struct gfs2_dinode ), dsize);memset (kaddr + dsize,0 ,PAGE_SIZE - dsize);kunmap (page);
fs/gfs2/glops.c +3 -0
@@ -449,6 +449,9 @@ static int gfs2_dinode_in(struct gfs2_in ip->i_depth = (u8 )depth; ip->i_entries =be32_to_cpu (str->di_entries); +if (gfs2_is_stuffed (ip) && inode->i_size >gfs2_max_stuffed_size (ip)) + goto corrupt; +if (S_ISREG (inode->i_mode))gfs2_set_aops (inode);
Greg Kroah-Hartman
maintainerPATCH 208/208 bpf: Skip invalid kfunc call in backtrack_insn
In reply to Greg Kroah-HartmanFrom: Hao Sun <[email protected]>
commit d3178e8a434b58678d99257c0387810a24042fb6 upstream.
The verifier skips invalid kfunc call in check_kfunc_call(), which would be captured in fixup_kfunc_call() if such insn is not eliminated by dead code elimination. However, this can lead to the following warning in backtrack_insn(), also see [1]:
------------[ cut here ]------------ verifier backtracking bug WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrack_insn kernel/bpf/verifier.c:2756 __mark_chain_precision kernel/bpf/verifier.c:3065 mark_chain_precision kernel/bpf/verifier.c:3165 adjust_reg_min_max_vals kernel/bpf/verifier.c:10715 check_alu_op kernel/bpf/verifier.c:10928 do_check kernel/bpf/verifier.c:13821 [inline] do_check_common kernel/bpf/verifier.c:16289 [...]
So make backtracking conservative with this by returning ENOTSUPP.
[1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/
--- kernel/bpf/verifier.c | 6 ++++++ 1 file changed, 6 insertions(+)
kernel/bpf/verifier.c +6 -0
@@ -2664,6 +2664,12 @@ static int backtrack_insn(struct bpf_verif (opcode ==BPF_CALL ) {if (insn->src_reg ==BPF_PSEUDO_CALL )return -ENOTSUPP ; +/* kfunc with imm==0 is invalid and fixup_kfunc_call will +* catch this error later. Make backtracking conservative +* with ENOTSUPP. +*/ +if (insn->src_reg ==BPF_PSEUDO_KFUNC_CALL && insn->imm ==0 ) +return -ENOTSUPP ;/* regular helper call sets R0 */ *reg_mask &= ~1 ;if (*reg_mask &0x3f ) {
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 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 9 lines
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.
On our RISC-V hardware this looks good, no issues noticed.
Thanks,
Conor.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 failLinux version: 6.1.11-rc1-g78e134c7117c
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Following build regressions noticed while building selftests/vm/hugetlb-madvise.c
with kselftest-merge configs.
Build errors:
----------
hugetlb-madvise.c:242:13: warning: implicit declaration of function 'fallocate'; did you mean 'alloca'? [-Wimplicit-function-declaration]
242 | if (fallocate(fd, 0, 0, NR_HUGE_PAGES * huge_page_size)) {
| ^~~~~~~~~
| alloca
hugetlb-madvise.c:289:27: error: 'FALLOC_FL_PUNCH_HOLE' undeclared
(first use in this function)
289 | if (fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
| ^~~~~~~~~~~~~~~~~~~~hugetlb-madvise.c:289:27: note: each undeclared identifier is reported only once for each function it appears in hugetlb-madvise.c:289:50: error: 'FALLOC_FL_KEEP_SIZE' undeclared (first use in this function)
289 | if (fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
| ^~~~~~~~~~~~~~~~~~~
make[3]: *** [../lib.mk:145:/home/tuxbuild/.cache/tuxmake/builds/1/build/kselftest/vm/hugetlb-madvise] Error 1
Build log:
https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/3728198425#L1676
https://storage.tuxsuite.com/public/linaro/lkft/builds/2LPeQeCIu0YEfltwqAFCvDaj29A/
--
Linaro LKFT
https://lkft.linaro.org
Quoted 44 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Following build regressions noticed while buildingselftests/vm/hugetlb-madvise.c
with kselftest-merge configs.Build errors:
----------
hugetlb-madvise.c:242:13: warning: implicit declaration of function 'fallocate'; did you mean 'alloca'? [-Wimplicit-function-declaration]242 | if (fallocate(fd, 0, 0, NR_HUGE_PAGES * huge_page_size)) { | ^~~~~~~~~ | alloca hugetlb-madvise.c:289:27: error: 'FALLOC_FL_PUNCH_HOLE' undeclared (first use in this function) 289 | if (fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, | ^~~~~~~~~~~~~~~~~~~~hugetlb-madvise.c:289:27: note: each undeclared identifier is reported only once for each function it appears in hugetlb-madvise.c:289:50: error: '
FALLOC_FL_KEEP_SIZE' undeclared (first use in this function)
289 | if (fallocate(fd,FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE,
Quoted 8 lines
| ^~~~~~~~~~~~~~~~~~~make[3]: *** [
../lib.mk:145:/home/tuxbuild/.cache/tuxmake/builds/1/build/kselftest/vm/hugetlb-madvise] Error 1Build log:
https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/3728198425#L1676
https://storage.tuxsuite.com/public/linaro/lkft/builds/2LPeQeCIu0YEfltwqAFCvDaj29A/
I think we should drop the patch "[PATCH 6.1 012/208] selftests/vm: remove __USE_GNU in hugetlb-madvise.c" from this merge.
That patch fixes commit 62f33fa22800 ("selftests/vm: use memfd for hugetlb-madvise test"), but that's only in 6.2-rc1 and it's not in 6.1.
I don't really know why it got picked for 6.1 stable backport, because the original patch doesn't contain "CC: stable".
Thanks,
Signature · 1 line
Peter Xu
Greg Kroah-Hartman
maintainerQuoted 54 lines · Peter Xu
Quoted 44 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Following build regressions noticed while buildingselftests/vm/hugetlb-madvise.c
with kselftest-merge configs.Build errors:
----------
hugetlb-madvise.c:242:13: warning: implicit declaration of function 'fallocate'; did you mean 'alloca'? [-Wimplicit-function-declaration]242 | if (fallocate(fd, 0, 0, NR_HUGE_PAGES * huge_page_size)) { | ^~~~~~~~~ | alloca hugetlb-madvise.c:289:27: error: 'FALLOC_FL_PUNCH_HOLE' undeclared (first use in this function) 289 | if (fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, | ^~~~~~~~~~~~~~~~~~~~hugetlb-madvise.c:289:27: note: each undeclared identifier is reported only once for each function it appears in hugetlb-madvise.c:289:50: error: '
FALLOC_FL_KEEP_SIZE' undeclared (first use in this function)
289 | if (fallocate(fd,FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE,Quoted 8 lines
| ^~~~~~~~~~~~~~~~~~~make[3]: *** [
../lib.mk:145:/home/tuxbuild/.cache/tuxmake/builds/1/build/kselftest/vm/hugetlb-madvise] Error 1Build log:
https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/3728198425#L1676
https://storage.tuxsuite.com/public/linaro/lkft/builds/2LPeQeCIu0YEfltwqAFCvDaj29A/
Quoted 8 lines
I think we should drop the patch "[PATCH 6.1 012/208] selftests/vm: remove
__USE_GNUinhugetlb-madvise.c" from this merge.That patch fixes commit
62f33fa22800("selftests/vm: use memfd for hugetlb-madvise test"), but that's only in 6.2-rc1 and it's not in 6.1.I don't really know why it got picked for 6.1 stable backport, because the original patch doesn't contain "CC: stable".
Now dropped, thanks!
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.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 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 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.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 503 pass: 503 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +0000. Anything received after that time might be too late.
Hi Greg,
6.1.11-rc1 tested.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Alder Lake x86_64 (nuc12 i7-1260P)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi
Quoted 9 lines
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.11 release. There are 208 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Feb 2023 12:55:54 +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.1.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.