- Linux-stable-mirror - lists.linaro.org

by Bean Huo (beanhuo)

Hi, Greg >On Mon, Nov 27, 2017 at 11:25:47AM +0000, Bean Huo (beanhuo) wrote: >> Hi, all >> Is there someone knows if exists one utilis dedicated to UFS device, rather >than SCSI utils? >> I have tried sg3-utils, but it is not convenient for the embedded ARM-based >system. >> And also it doesn't support several UFS special command. > >What specific UFS commands do you need to make to the device that the >current driver does not support? There are some UFS/vendor native commands. They are not SCSI based. >And yes, this is a trick question as there are about 4 different major forks that >I know of of the UFS driver in different vendor trees, all of which support >different types of UFS commands :( > >> If we don't have this kind of tool for UFS, is it necessary for us to develop a >>ufs-utils? > >I doubt it, what neds to happen is getting all of the functionality that lives in >these different forks all merged upstream into the in-kernel driver. Then I bet >all of the needed functionality you are looking for will be there. > Sometimes customers tend to use user space tool to do some configuration. And especially, for example the UFS FFU. >good luck! > Thanks ! >greg k-h //Bean Huo

7 years, 7 months

4
3
0 0

[Linux-stable-mirror] [PATCH] scsi: ufs: ufshcd: Enable no_write_same for scsi host

by Bjorn Andersson

Occasionally the following error message can be seen in the logs of Qualcomm devices using UFS: EXT4-fs (sda9): Delayed block allocation failed for inode 685600 at logical offset 1086 with max blocks 3 with error 121 EXT4-fs (sda9): This should not happen!! Data will be lost This is caused by a failing WRITE_SAME command, which per the JEDEC UFS specification is not a supported. Set the no_write_same flag on the ufshcd SCSI host to let the SCSI layer know this. Fixes: 7a3e97b0dc4b ("[SCSI] ufshcd: UFS Host controller driver") Cc: stable(a)vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- drivers/scsi/ufs/ufshcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 88c086f5c4e3..e5b1efd1dafd 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -6515,6 +6515,7 @@ static struct scsi_host_template ufshcd_driver_template = { .can_queue = UFSHCD_CAN_QUEUE, .max_host_blocked = 1, .track_queue_depth = 1, + .no_write_same = 1, }; static int ufshcd_config_vreg_load(struct device *dev, struct ufs_vreg *vreg, -- 2.15.0

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] patch "iio: stm32: fix adc/trigger link error" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: stm32: fix adc/trigger link error to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 6d745ee8b5e81f3a33791e3c854fbbfd6f3e585e Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 6 Sep 2017 14:56:50 +0200 Subject: iio: stm32: fix adc/trigger link error The ADC driver can trigger on either the timer or the lptim trigger, but it only uses a Kconfig 'select' statement to ensure that the first of the two is present. When the lptim trigger is enabled as a loadable module, and the adc driver is built-in, we now get a link error: drivers/iio/adc/stm32-adc.o: In function `stm32_adc_get_trig_extsel': stm32-adc.c:(.text+0x4e0): undefined reference to `is_stm32_lptim_trigger' We could use a second 'select' statement and always have both trigger drivers enabled when the adc driver is, but it seems that the lptimer trigger was intentionally left optional, so it seems better to keep it that way. This adds a hack to use 'IS_REACHABLE()' rather than 'IS_ENABLED()', which avoids the link error, but instead leads to the lptimer trigger not being used in the broken configuration. I've added a runtime warning for this case to help users figure out what they did wrong if this should ever be done by accident. Fixes: f0b638a7f6db ("iio: adc: stm32: add support for lptimer triggers") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- include/linux/iio/timer/stm32-lptim-trigger.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/iio/timer/stm32-lptim-trigger.h b/include/linux/iio/timer/stm32-lptim-trigger.h index 34d59bfdce2d..464458d20b16 100644 --- a/include/linux/iio/timer/stm32-lptim-trigger.h +++ b/include/linux/iio/timer/stm32-lptim-trigger.h @@ -16,11 +16,14 @@ #define LPTIM2_OUT "lptim2_out" #define LPTIM3_OUT "lptim3_out" -#if IS_ENABLED(CONFIG_IIO_STM32_LPTIMER_TRIGGER) +#if IS_REACHABLE(CONFIG_IIO_STM32_LPTIMER_TRIGGER) bool is_stm32_lptim_trigger(struct iio_trigger *trig); #else static inline bool is_stm32_lptim_trigger(struct iio_trigger *trig) { +#if IS_ENABLED(CONFIG_IIO_STM32_LPTIMER_TRIGGER) + pr_warn_once("stm32 lptim_trigger not linked in\n"); +#endif return false; } #endif -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: health: max30102: Temperature should be in milli Celsius" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: health: max30102: Temperature should be in milli Celsius to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From ad44a9f804c1591ba2a2ec0ac8d916a515d2790c Mon Sep 17 00:00:00 2001 From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net> Date: Fri, 27 Oct 2017 21:45:31 +0200 Subject: iio: health: max30102: Temperature should be in milli Celsius As per ABI temperature should be in milli Celsius after scaling, not Celsius Note on stable cc. This driver is breaking the standard IIO ABI. (JC) Signed-off-by: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net> Acked-by: Matt Ranostay <matt.ranostay(a)konsulko.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/health/max30102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c index 203ffb9cad6a..147a8c14235f 100644 --- a/drivers/iio/health/max30102.c +++ b/drivers/iio/health/max30102.c @@ -371,7 +371,7 @@ static int max30102_read_raw(struct iio_dev *indio_dev, mutex_unlock(&indio_dev->mlock); break; case IIO_CHAN_INFO_SCALE: - *val = 1; /* 0.0625 */ + *val = 1000; /* 62.5 */ *val2 = 16; ret = IIO_VAL_FRACTIONAL; break; -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: fix kernel-doc build errors" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: fix kernel-doc build errors to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c175cb7cd953782bbf4e8bdf088ad61440d6dde5 Mon Sep 17 00:00:00 2001 From: Randy Dunlap <rdunlap(a)infradead.org> Date: Sun, 29 Oct 2017 17:06:01 -0700 Subject: iio: fix kernel-doc build errors Fix build errors in kernel-doc notation. Symbols that end in '_' have a special meaning, but adding a '*' makes them OK. ../drivers/iio/industrialio-core.c:635: ERROR: Unknown target name: "iio_val". ../drivers/iio/industrialio-core.c:642: ERROR: Unknown target name: "iio_val". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/industrialio-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 9c4cfd19b739..2f0998ebeed2 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -631,7 +631,7 @@ static ssize_t __iio_format_value(char *buf, size_t len, unsigned int type, * iio_format_value() - Formats a IIO value into its string representation * @buf: The buffer to which the formatted value gets written * which is assumed to be big enough (i.e. PAGE_SIZE). - * @type: One of the IIO_VAL_... constants. This decides how the val + * @type: One of the IIO_VAL_* constants. This decides how the val * and val2 parameters are formatted. * @size: Number of IIO value entries contained in vals * @vals: Pointer to the values, exact meaning depends on the @@ -639,7 +639,7 @@ static ssize_t __iio_format_value(char *buf, size_t len, unsigned int type, * * Return: 0 by default, a negative number on failure or the * total number of characters written for a type that belongs - * to the IIO_VAL_... constant. + * to the IIO_VAL_* constant. */ ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals) { -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: adc: meson-saradc: fix the bit_idx of the adc_en clock" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: meson-saradc: fix the bit_idx of the adc_en clock to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7a6b0420d2fe4ce59437bd318826fe468f0d71ae Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Tue, 31 Oct 2017 21:01:43 +0100 Subject: iio: adc: meson-saradc: fix the bit_idx of the adc_en clock Meson8 and Meson8b SoCs use the the SAR ADC gate clock provided by the MESON_SAR_ADC_REG3 register within the SAR ADC register area. According to the datasheet (and the existing MESON_SAR_ADC_REG3_CLK_EN definition) the gate is on bit 30. The fls() function returns the last set bit, which is "bit index + 1" (fls(MESON_SAR_ADC_REG3_CLK_EN) returns 31). Fix this by switching to __ffs() which returns the first set bit, which is bit 30 in our case. This off by one error results in the ADC not being usable on devices where the bootloader did not enable the clock. Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/meson_saradc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c index 9c6932ffc0af..1d25c78b74d2 100644 --- a/drivers/iio/adc/meson_saradc.c +++ b/drivers/iio/adc/meson_saradc.c @@ -600,7 +600,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev, init.num_parents = 1; priv->clk_gate.reg = base + MESON_SAR_ADC_REG3; - priv->clk_gate.bit_idx = fls(MESON_SAR_ADC_REG3_CLK_EN); + priv->clk_gate.bit_idx = __ffs(MESON_SAR_ADC_REG3_CLK_EN); priv->clk_gate.hw.init = &init; priv->adc_clk = devm_clk_register(&indio_dev->dev, &priv->clk_gate.hw); -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 96748823c483c6eed8321f78bd128dd33f09c55c Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Tue, 31 Oct 2017 21:01:45 +0100 Subject: iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13 The Meson GXBB and newer SoCs have a few more registers than the older Meson8 and Meson8b SoCs. Use a separate regmap config to limit the older SoCs to the DELTA_10 register. Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/meson_saradc.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c index a220d07d890f..36047147ce7c 100644 --- a/drivers/iio/adc/meson_saradc.c +++ b/drivers/iio/adc/meson_saradc.c @@ -224,6 +224,7 @@ struct meson_sar_adc_data { u32 bandgap_reg; unsigned int resolution; const char *name; + const struct regmap_config *regmap_config; }; struct meson_sar_adc_priv { @@ -243,13 +244,20 @@ struct meson_sar_adc_priv { int calibscale; }; -static const struct regmap_config meson_sar_adc_regmap_config = { +static const struct regmap_config meson_sar_adc_regmap_config_gxbb = { .reg_bits = 8, .val_bits = 32, .reg_stride = 4, .max_register = MESON_SAR_ADC_REG13, }; +static const struct regmap_config meson_sar_adc_regmap_config_meson8 = { + .reg_bits = 8, + .val_bits = 32, + .reg_stride = 4, + .max_register = MESON_SAR_ADC_DELTA_10, +}; + static unsigned int meson_sar_adc_get_fifo_count(struct iio_dev *indio_dev) { struct meson_sar_adc_priv *priv = iio_priv(indio_dev); @@ -859,6 +867,7 @@ static const struct iio_info meson_sar_adc_iio_info = { static const struct meson_sar_adc_data meson_sar_adc_meson8_data = { .has_bl30_integration = false, .bandgap_reg = MESON_SAR_ADC_DELTA_10, + .regmap_config = &meson_sar_adc_regmap_config_meson8, .resolution = 10, .name = "meson-meson8-saradc", }; @@ -866,6 +875,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = { static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = { .has_bl30_integration = false, .bandgap_reg = MESON_SAR_ADC_DELTA_10, + .regmap_config = &meson_sar_adc_regmap_config_meson8, .resolution = 10, .name = "meson-meson8b-saradc", }; @@ -873,6 +883,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = { static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = { .has_bl30_integration = true, .bandgap_reg = MESON_SAR_ADC_REG11, + .regmap_config = &meson_sar_adc_regmap_config_gxbb, .resolution = 10, .name = "meson-gxbb-saradc", }; @@ -880,6 +891,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = { static const struct meson_sar_adc_data meson_sar_adc_gxl_data = { .has_bl30_integration = true, .bandgap_reg = MESON_SAR_ADC_REG11, + .regmap_config = &meson_sar_adc_regmap_config_gxbb, .resolution = 12, .name = "meson-gxl-saradc", }; @@ -887,6 +899,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = { static const struct meson_sar_adc_data meson_sar_adc_gxm_data = { .has_bl30_integration = true, .bandgap_reg = MESON_SAR_ADC_REG11, + .regmap_config = &meson_sar_adc_regmap_config_gxbb, .resolution = 12, .name = "meson-gxm-saradc", }; @@ -964,7 +977,7 @@ static int meson_sar_adc_probe(struct platform_device *pdev) return ret; priv->regmap = devm_regmap_init_mmio(&pdev->dev, base, - &meson_sar_adc_regmap_config); + priv->data->regmap_config); if (IS_ERR(priv->regmap)) return PTR_ERR(priv->regmap); -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: adc: meson-saradc: initialize the bandgap correctly on older" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: meson-saradc: initialize the bandgap correctly on older to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From d85eed9f576369bc90322659de96b7dbea1f9a57 Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Tue, 31 Oct 2017 21:01:44 +0100 Subject: iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs Meson8 and Meson8b do not have the MESON_SAR_ADC_REG11 register. The bandgap setting for these SoCs is configured in the MESON_SAR_ADC_DELTA_10 register instead. Make the driver aware of this difference and use the correct bandgap register depending on the SoC. This has worked fine on Meson8 and Meson8b because the bootloader is already initializing the bandgap setting. Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/meson_saradc.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c index 1d25c78b74d2..a220d07d890f 100644 --- a/drivers/iio/adc/meson_saradc.c +++ b/drivers/iio/adc/meson_saradc.c @@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel { struct meson_sar_adc_data { bool has_bl30_integration; + u32 bandgap_reg; unsigned int resolution; const char *name; }; @@ -685,6 +686,20 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev) return 0; } +static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off) +{ + struct meson_sar_adc_priv *priv = iio_priv(indio_dev); + u32 enable_mask; + + if (priv->data->bandgap_reg == MESON_SAR_ADC_REG11) + enable_mask = MESON_SAR_ADC_REG11_BANDGAP_EN; + else + enable_mask = MESON_SAR_ADC_DELTA_10_TS_VBG_EN; + + regmap_update_bits(priv->regmap, priv->data->bandgap_reg, enable_mask, + on_off ? enable_mask : 0); +} + static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev) { struct meson_sar_adc_priv *priv = iio_priv(indio_dev); @@ -717,9 +732,9 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev) regval = FIELD_PREP(MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, 1); regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG0, MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, regval); - regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11, - MESON_SAR_ADC_REG11_BANDGAP_EN, - MESON_SAR_ADC_REG11_BANDGAP_EN); + + meson_sar_adc_set_bandgap(indio_dev, true); + regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3, MESON_SAR_ADC_REG3_ADC_EN, MESON_SAR_ADC_REG3_ADC_EN); @@ -739,8 +754,7 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev) err_adc_clk: regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3, MESON_SAR_ADC_REG3_ADC_EN, 0); - regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11, - MESON_SAR_ADC_REG11_BANDGAP_EN, 0); + meson_sar_adc_set_bandgap(indio_dev, false); clk_disable_unprepare(priv->sana_clk); err_sana_clk: clk_disable_unprepare(priv->core_clk); @@ -765,8 +779,8 @@ static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev) regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3, MESON_SAR_ADC_REG3_ADC_EN, 0); - regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11, - MESON_SAR_ADC_REG11_BANDGAP_EN, 0); + + meson_sar_adc_set_bandgap(indio_dev, false); clk_disable_unprepare(priv->sana_clk); clk_disable_unprepare(priv->core_clk); @@ -844,30 +858,35 @@ static const struct iio_info meson_sar_adc_iio_info = { static const struct meson_sar_adc_data meson_sar_adc_meson8_data = { .has_bl30_integration = false, + .bandgap_reg = MESON_SAR_ADC_DELTA_10, .resolution = 10, .name = "meson-meson8-saradc", }; static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = { .has_bl30_integration = false, + .bandgap_reg = MESON_SAR_ADC_DELTA_10, .resolution = 10, .name = "meson-meson8b-saradc", }; static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = { .has_bl30_integration = true, + .bandgap_reg = MESON_SAR_ADC_REG11, .resolution = 10, .name = "meson-gxbb-saradc", }; static const struct meson_sar_adc_data meson_sar_adc_gxl_data = { .has_bl30_integration = true, + .bandgap_reg = MESON_SAR_ADC_REG11, .resolution = 12, .name = "meson-gxl-saradc", }; static const struct meson_sar_adc_data meson_sar_adc_gxm_data = { .has_bl30_integration = true, + .bandgap_reg = MESON_SAR_ADC_REG11, .resolution = 12, .name = "meson-gxm-saradc", }; -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "iio: adc: cpcap: fix incorrect validation" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: cpcap: fix incorrect validation to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 81b039ec36a41a5451e1e36f05bb055eceab1dc8 Mon Sep 17 00:00:00 2001 From: Pan Bian <bianpan2016(a)163.com> Date: Mon, 13 Nov 2017 00:01:20 +0800 Subject: iio: adc: cpcap: fix incorrect validation Function platform_get_irq_byname() returns a negative error code on failure, and a zero or positive number on success. However, in function cpcap_adc_probe(), positive IRQ numbers are also taken as error cases. Use "if (ddata->irq < 0)" instead of "if (!ddata->irq)" to validate the return value of platform_get_irq_byname(). Signed-off-by: Pan Bian <bianpan2016(a)163.com> Fixes: 25ec249632d50 ("iio: adc: cpcap: Add minimal support for CPCAP PMIC ADC") Reviewed-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Acked-by: Tony Lindgren <tony(a)atomide.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/cpcap-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c index 3576ec73ec23..9ad60421d360 100644 --- a/drivers/iio/adc/cpcap-adc.c +++ b/drivers/iio/adc/cpcap-adc.c @@ -1011,7 +1011,7 @@ static int cpcap_adc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, indio_dev); ddata->irq = platform_get_irq_byname(pdev, "adcdone"); - if (!ddata->irq) + if (ddata->irq < 0) return -ENODEV; error = devm_request_threaded_irq(&pdev->dev, ddata->irq, NULL, -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 08/10] staging: ccree: NULLify backup_info when unused

by Gilad Ben-Yossef

backup_info field is only allocated for decrypt code path. The field was not nullified when not used causing a kfree in an error handling path to attempt to free random addresses as uncovered in stress testing. Fixes: 737aed947f9b ("staging: ccree: save ciphertext for CTS IV") Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/staging/ccree/ssi_cipher.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/ccree/ssi_cipher.c b/drivers/staging/ccree/ssi_cipher.c index 9019615..7b484f1 100644 --- a/drivers/staging/ccree/ssi_cipher.c +++ b/drivers/staging/ccree/ssi_cipher.c @@ -907,6 +907,7 @@ static int ssi_ablkcipher_encrypt(struct ablkcipher_request *req) unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm); req_ctx->is_giv = false; + req_ctx->backup_info = NULL; return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, req->nbytes, req->info, ivsize, -- 2.7.4

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] MIPS: fix incorrect mem=X@Y handling

by Mathieu Malaterre

On Tue, Sep 5, 2017 at 1:06 PM, Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> wrote: > Change 73fbc1eba7ff added a fix to ensure that the memory range between > PHYS_OFFSET and low memory address specified by mem= cmdline argument is > not later processed by free_all_bootmem. > This change was incorrect for systems where the commandline specifies > more than 1 mem argument, as it will cause all memory between > PHYS_OFFSET and each of the memory offsets to be marked as reserved, > which results in parts of the RAM marked as reserved (Creator CI20's > u-boot has a default commandline argument 'mem=256M@0x0 > mem=768M@0x30000000'). > > Change the behaviour to ensure that only the range between PHYS_OFFSET > and the lowest start address of the memories is marked as protected. > > This change also ensures that the range is marked protected even if it's > only defined through the devicetree and not only via commandline > arguments. > > Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com> > Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> > Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") > Cc: stable(a)vger.kernel.org > --- > arch/mips/kernel/setup.c | 19 ++++++++++++++++--- > 1 file changed, 16 insertions(+), 3 deletions(-) > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > index fe39397..a1c39ec 100644 > --- a/arch/mips/kernel/setup.c > +++ b/arch/mips/kernel/setup.c > @@ -374,6 +374,7 @@ static void __init bootmem_init(void) > unsigned long reserved_end; > unsigned long mapstart = ~0UL; > unsigned long bootmap_size; > + phys_addr_t ramstart = ~0UL; > bool bootmap_valid = false; > int i; > > @@ -394,6 +395,21 @@ static void __init bootmem_init(void) > max_low_pfn = 0; > > /* > + * Reserve any memory between the start of RAM and PHYS_OFFSET > + */ > + for (i = 0; i < boot_mem_map.nr_map; i++) { > + if (boot_mem_map.map[i].type != BOOT_MEM_RAM) > + continue; > + > + ramstart = min(ramstart, boot_mem_map.map[i].addr); > + } > + > + if (ramstart > PHYS_OFFSET) > + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET, > + BOOT_MEM_RESERVED); > + > + > + /* > * Find the highest page frame number we have available. > */ > for (i = 0; i < boot_mem_map.nr_map; i++) { > @@ -663,9 +679,6 @@ static int __init early_parse_mem(char *p) > > add_memory_region(start, size, BOOT_MEM_RAM); > > - if (start && start > PHYS_OFFSET) > - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET, > - BOOT_MEM_RESERVED); > return 0; > } > early_param("mem", early_parse_mem); > -- > 2.7.4 > > Teested-by: Mathieu Malaterre <malat(a)debian.org> Would be nice to have it upstream at some point... Thanks

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 3.18 01/15] route: also update fnhe_genid when updating a route cache

by alexander.levin＠verizon.com

From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit cebe84c6190d741045a322f5343f717139993c08 ] Now when ip route flush cache and it turn out all fnhe_genid != genid. If a redirect/pmtu icmp packet comes and the old fnhe is found and all it's members but fnhe_genid will be updated. Then next time when it looks up route and tries to rebind this fnhe to the new dst, the fnhe will be flushed due to fnhe_genid != genid. It causes this redirect/pmtu icmp packet acutally not to be applied. This patch is to also reset fnhe_genid when updating a route cache. Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions") Acked-by: Hannes Frederic Sowa <hannes(a)stressinduktion.org> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- net/ipv4/route.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 2fe9459fbe24..a04d29d70e6a 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -622,9 +622,12 @@ static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw, struct fnhe_hash_bucket *hash; struct fib_nh_exception *fnhe; struct rtable *rt; + u32 genid, hval; unsigned int i; int depth; - u32 hval = fnhe_hashfun(daddr); + + genid = fnhe_genid(dev_net(nh->nh_dev)); + hval = fnhe_hashfun(daddr); spin_lock_bh(&fnhe_lock); @@ -647,6 +650,8 @@ static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw, } if (fnhe) { + if (fnhe->fnhe_genid != genid) + fnhe->fnhe_genid = genid; if (gw) fnhe->fnhe_gw = gw; if (pmtu) { @@ -671,7 +676,7 @@ static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw, fnhe->fnhe_next = hash->chain; rcu_assign_pointer(hash->chain, fnhe); } - fnhe->fnhe_genid = fnhe_genid(dev_net(nh->nh_dev)); + fnhe->fnhe_genid = genid; fnhe->fnhe_daddr = daddr; fnhe->fnhe_gw = gw; fnhe->fnhe_pmtu = pmtu; -- 2.11.0

7 years, 7 months

1
14
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.4 01/20] kbuild: pkg: use --transform option to prefix paths in tar

by alexander.levin＠verizon.com

From: Masahiro Yamada <yamada.masahiro(a)socionext.com> [ Upstream commit 2dbc644ac62bbcb9ee78e84719953f611be0413d ] For rpm-pkg and deb-pkg, a source tar file is created. All paths in the archive must be prefixed with the base name of the tar so that everything is contained in the directory when you extract it. Currently, scripts/package/Makefile uses a symlink for that, and removes it after the tar is created. If you terminate the build during the tar creation, the symlink is left over. Then, at the next package build, you will see a warning like follows: ln: '.' and 'kernel-4.14.0+/.' are the same file It is possible to fix it by adding -n (--no-dereference) option to the "ln" command, but a cleaner way is to use --transform option of "tar" command. This option is GNU extension, but it should not hurt to use it in the Linux build system. The 'S' flag is needed to exclude symlinks from the path fixup. Without it, symlinks in the kernel are broken. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- scripts/package/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/scripts/package/Makefile b/scripts/package/Makefile index 493e226356ca..52917fb8e0c5 100644 --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -39,10 +39,9 @@ if test "$(objtree)" != "$(srctree)"; then \ false; \ fi ; \ $(srctree)/scripts/setlocalversion --save-scmversion; \ -ln -sf $(srctree) $(2); \ tar -cz $(RCS_TAR_IGNORE) -f $(2).tar.gz \ - $(addprefix $(2)/,$(TAR_CONTENT) $(3)); \ -rm -f $(2) $(objtree)/.scmversion + --transform 's:^:$(2)/:S' $(TAR_CONTENT) $(3); \ +rm -f $(objtree)/.scmversion # rpm-pkg # --------------------------------------------------------------------------- -- 2.11.0

7 years, 7 months

1
19
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/33] kbuild: pkg: use --transform option to prefix paths in tar

by alexander.levin＠verizon.com

From: Masahiro Yamada <yamada.masahiro(a)socionext.com> [ Upstream commit 2dbc644ac62bbcb9ee78e84719953f611be0413d ] For rpm-pkg and deb-pkg, a source tar file is created. All paths in the archive must be prefixed with the base name of the tar so that everything is contained in the directory when you extract it. Currently, scripts/package/Makefile uses a symlink for that, and removes it after the tar is created. If you terminate the build during the tar creation, the symlink is left over. Then, at the next package build, you will see a warning like follows: ln: '.' and 'kernel-4.14.0+/.' are the same file It is possible to fix it by adding -n (--no-dereference) option to the "ln" command, but a cleaner way is to use --transform option of "tar" command. This option is GNU extension, but it should not hurt to use it in the Linux build system. The 'S' flag is needed to exclude symlinks from the path fixup. Without it, symlinks in the kernel are broken. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- scripts/package/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/scripts/package/Makefile b/scripts/package/Makefile index 71b4a8af9d4d..7badec3498b8 100644 --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -39,10 +39,9 @@ if test "$(objtree)" != "$(srctree)"; then \ false; \ fi ; \ $(srctree)/scripts/setlocalversion --save-scmversion; \ -ln -sf $(srctree) $(2); \ tar -cz $(RCS_TAR_IGNORE) -f $(2).tar.gz \ - $(addprefix $(2)/,$(TAR_CONTENT) $(3)); \ -rm -f $(2) $(objtree)/.scmversion + --transform 's:^:$(2)/:S' $(TAR_CONTENT) $(3); \ +rm -f $(objtree)/.scmversion # rpm-pkg # --------------------------------------------------------------------------- -- 2.11.0

7 years, 7 months

1
32
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.14 01/64] irqchip/qcom: Fix u32 comparison with value less than zero

by alexander.levin＠verizon.com

From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit e9990d70e8a063a7b894c5cbb99f630a0f41200d ] The comparison of u32 nregs being less than zero is never true since nregs is unsigned. Fix this by making nregs a signed integer. Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: kernel-janitors(a)vger.kernel.org Cc: Jason Cooper <jason(a)lakedaemon.net> Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/irqchip/qcom-irq-combiner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/qcom-irq-combiner.c b/drivers/irqchip/qcom-irq-combiner.c index 6aa3ea479214..f31265937439 100644 --- a/drivers/irqchip/qcom-irq-combiner.c +++ b/drivers/irqchip/qcom-irq-combiner.c @@ -238,7 +238,7 @@ static int __init combiner_probe(struct platform_device *pdev) { struct combiner *combiner; size_t alloc_sz; - u32 nregs; + int nregs; int err; nregs = count_registers(pdev); -- 2.11.0

7 years, 7 months

1
63
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit b42518053ffd221d79cff2df8c0257db88a71334: Linux 3.18.85 (2017-11-30 08:35:56 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg/4.14/3.18 for you to fetch changes up to 90cbc83fe2279c1f0b5e94196c27253513405d77: perf test attr: Fix ignored test case result (2017-11-30 17:01:13 -0500) - ---------------------------------------------------------------- Ben Hutchings (1): usbip: tools: Install all headers needed for libusbip development Boshi Wang (1): ima: fix hash algorithm initialization Gustavo A. R. Silva (1): EDAC, sb_edac: Fix missing break in switch Hiromitsu Yamasaki (1): spi: sh-msiof: Fix DMA transfer size check Jibin Xu (1): sysrq : fix Show Regs call trace on ARM Lukas Wunner (1): serial: 8250_fintek: Fix rs485 disablement on invalid ioctl() Masami Hiramatsu (1): kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT=y Thomas Richter (1): perf test attr: Fix ignored test case result arch/Kconfig | 2 +- drivers/edac/sb_edac.c | 1 + drivers/spi/spi-sh-msiof.c | 2 +- drivers/tty/serial/8250/8250_fintek.c | 2 +- drivers/tty/sysrq.c | 9 +++++++-- kernel/kprobes.c | 14 ++++++++------ security/integrity/ima/ima_main.c | 4 ++++ tools/perf/tests/attr.c | 2 +- tools/usb/usbip/Makefile.am | 3 ++- 9 files changed, 26 insertions(+), 13 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaIIAGAAoJEN6mb/eXdyzcB/AP/2JM6q4DXlQNiG6gFgU1MAIR N6uwbY9a+RRE/P2sSb0fTx+/f2JTdRhY/NK15y2up+vWxOAzBmqE/NotO0gzaMc1 a+8LkomLf9BS4I/ScRb/iAANUBwWcZNPFHuiYRNGg5y0Ru4uI2C4LNpmNXE6uhWC ia7PjeElSbVZptmMAk1Fdb3A+eYZDwZUvBjf1Zcsjd3QYCS2psa/xQu+uvv4CsNX 1UlGnVqF6hIqrpO1JYgS1vRuGSsSdLiPVrFdVha9Npg6ORtBk6Be6y0vq7uHmvqD x0+iFimMTadSRLPWW5u5CmXsDdhgXb3+5PPl8Bw4krJ7RX9/qWLWmyXJ3pGaZr7U 81LFws1Kt7sG+aDwCSq48rhUnbQAEardI16H9abujM3sCe3b0uboLm8PV9K7JlpZ xiK5lo3U1ia2v1TKUeFS2KhdQtnV0YzHpfIDS9TDQk28kFFtkKDek3x8xM74Z6aa xXtDi4qAJpa/73V9cr9DQM0UuavAk+3QDFEZras8C0dkMqi/DIEvpvZUQrvBMj3t bCldw32ylhtg+xaKPNUO7CXoRoKmE6b2kAed0PJ9sZIXYwoS3PGZnvGUDXDNqOY1 Mad0Mhh8JDiEBtBpEuIQzSVSTRNIeOqGYS1RiCN0oPI0uY/3xWZ7NV2bj+KXAqOe 66nYqLJq2Ai7Dgx4l6Es =eGmn -----END PGP SIGNATURE-----

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] Patch "mm, oom_reaper: gather each vma to prevent leaking TLB entry" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, oom_reaper: gather each vma to prevent leaking TLB entry to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 687cb0884a714ff484d038e9190edc874edcf146 Mon Sep 17 00:00:00 2001 From: Wang Nan <wangnan0(a)huawei.com> Date: Wed, 29 Nov 2017 16:09:58 -0800 Subject: mm, oom_reaper: gather each vma to prevent leaking TLB entry From: Wang Nan <wangnan0(a)huawei.com> commit 687cb0884a714ff484d038e9190edc874edcf146 upstream. tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory space. In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush TLB when tlb->fullmm is true: commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1"). Which causes leaking of tlb entries. Will clarifies his patch: "Basically, we tag each address space with an ASID (PCID on x86) which is resident in the TLB. This means we can elide TLB invalidation when pulling down a full mm because we won't ever assign that ASID to another mm without doing TLB invalidation elsewhere (which actually just nukes the whole TLB). I think that means that we could potentially not fault on a kernel uaccess, because we could hit in the TLB" There could be a window between complete_signal() sending IPI to other cores and all threads sharing this mm are really kicked off from cores. In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to flush TLB then frees pages. However, due to the above problem, the TLB entries are not really flushed on arm64. Other threads are possible to access these pages through TLB entries. Moreover, a copy_to_user() can also write to these pages without generating page fault, causes use-after-free bugs. This patch gathers each vma instead of gathering full vm space. In this case tlb->fullmm is not true. The behavior of oom reaper become similar to munmapping before do_exit, which should be safe for all archs. Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com Fixes: aac453635549 ("mm, oom: introduce oom reaper") Signed-off-by: Wang Nan <wangnan0(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: David Rientjes <rientjes(a)google.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Bob Liu <liubo95(a)huawei.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Roman Gushchin <guro(a)fb.com> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/oom_kill.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -532,7 +532,6 @@ static bool __oom_reap_task_mm(struct ta */ set_bit(MMF_UNSTABLE, &mm->flags); - tlb_gather_mmu(&tlb, mm, 0, -1); for (vma = mm->mmap ; vma; vma = vma->vm_next) { if (!can_madv_dontneed_vma(vma)) continue; @@ -547,11 +546,13 @@ static bool __oom_reap_task_mm(struct ta * we do not want to block exit_mmap by keeping mm ref * count elevated without a good reason. */ - if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) + if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) { + tlb_gather_mmu(&tlb, mm, vma->vm_start, vma->vm_end); unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end, NULL); + tlb_finish_mmu(&tlb, vma->vm_start, vma->vm_end); + } } - tlb_finish_mmu(&tlb, 0, -1); pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n", task_pid_nr(tsk), tsk->comm, K(get_mm_counter(mm, MM_ANONPAGES)), Patches currently in stable-queue which might be from wangnan0(a)huawei.com are queue-4.14/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "mm, memory_hotplug: do not back off draining pcp free pages from kworker context" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, memory_hotplug: do not back off draining pcp free pages from kworker context to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4b81cb2ff69c8a8e297a147d2eb4d9b5e8d7c435 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko(a)suse.com> Date: Wed, 29 Nov 2017 16:09:54 -0800 Subject: mm, memory_hotplug: do not back off draining pcp free pages from kworker context From: Michal Hocko <mhocko(a)suse.com> commit 4b81cb2ff69c8a8e297a147d2eb4d9b5e8d7c435 upstream. drain_all_pages backs off when called from a kworker context since commit 0ccce3b92421 ("mm, page_alloc: drain per-cpu pages from workqueue context") because the original IPI based pcp draining has been replaced by a WQ based one and the check wanted to prevent from recursion and inter workers dependencies. This has made some sense at the time because the system WQ has been used and one worker holding the lock could be blocked while waiting for new workers to emerge which can be a problem under OOM conditions. Since then commit ce612879ddc7 ("mm: move pcp and lru-pcp draining into single wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a rescuer so we shouldn't depend on any other WQ activity to make a forward progress so calling drain_all_pages from a worker context is safe as long as this doesn't happen from mm_percpu_wq itself which is not the case because all workers are required to _not_ depend on any MM locks. Why is this a problem in the first place? ACPI driven memory hot-remove (acpi_device_hotplug) is executed from the worker context. We end up calling __offline_pages to free all the pages and that requires both lru_add_drain_all_cpuslocked and drain_all_pages to do their job otherwise we can have dangling pages on pcp lists and fail the offline operation (__test_page_isolated_in_pageblock would see a page with 0 ref count but without PageBuddy set). Fix the issue by removing the worker check in drain_all_pages. lru_add_drain_all_cpuslocked doesn't have this restriction so it works as expected. Link: http://lkml.kernel.org/r/20170828093341.26341-1-mhocko@kernel.org Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue context") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/page_alloc.c | 4 ---- 1 file changed, 4 deletions(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2487,10 +2487,6 @@ void drain_all_pages(struct zone *zone) if (WARN_ON_ONCE(!mm_percpu_wq)) return; - /* Workqueues cannot recurse */ - if (current->flags & PF_WQ_WORKER) - return; - /* * Do not drain if one is already in progress unless it's specific to * a zone. Such callers are primarily CMA and memory hotplug and need Patches currently in stable-queue which might be from mhocko(a)suse.com are queue-4.14/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch queue-4.14/mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18.

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18. . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaIH/ZAAoJEN6mb/eXdyzcNa4P/2ctdnWkCUVD+UgsEKWn8hBf Gb2+RPaMaWf9wVF9LuKdl4JlGdrzTdXRAqmOZuaEWjGr89AOqbn84Z/Yb8NcmXef 8z/CEC2Gmb8lVLtDZdN7a8oSkV+Nt3EAGMK9qvUvUIoJAxAI12l/2jnVdwo1QKef Q0PNH9rPrpEb4k1nlnT8xqz+Uc3qGVMa26s5jBVnheg1YX3ucdXCoOfwfgMbnujT P0Sckb/j+hfWFx3AHHvuHuavrDpUEMSXvWeVd3mcQQUsyI+iUsjiIFVt9QY8p2Bw qpFgWSHg6qwlFAl2/QrUhIOTJ6RfnExbjvkKPPIU/MH/hUhbzmQ+vl7o/TFgg2p0 n89tpP+TYRwMy0rA1NMYqVKN8+l+pQvJ89j2OXVJ5uJfJblvp3HbrwQu6EFIN52x 86/Su7zzy3WOp9KY/v+CksMxo1COrTOxmNSXu0Rd1I9P1F4j8rxHQj229sIuCHcs zDgzWRT6oU5cdnw/iLcpKcH9GqrwBPDNkJYeSRrkSU5Vr/MCdZjUHFl8hBAz24tB Tzy1km2N0HXQwfikTk8cruwHR9t+hziraN49gi1wknda5uw93wTgqFRwj8HHfxXJ lSc5C5c4OlbkjARyAYkOlpgOBH/gLKrQWGg90cffOQIlfJ5cRgMfpI5o8WC3kobG F99f74cLB36Gh7z84rIX =0vft -----END PGP SIGNATURE-----

7 years, 7 months

2
3
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit c35c375efa4e2c832946a04e83155f928135e8f6: Linux 3.18.83 (2017-11-21 09:01:08 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-3.18 for you to fetch changes up to af0d729a7a2287ee2ad8468025529700cf182f32: net: fec: fix multicast filtering hardware setup (2017-11-22 13:40:15 -0500) - ---------------------------------------------------------------- Benjamin Coddington (1): nfs: Don't take a reference on fl->fl_file for LOCK operation Colin Ian King (1): net: sctp: fix array overrun read on sctp_timer_tbl David Forster (1): vti6: fix device register to report IFLA_INFO_KIND Jan Kara (1): mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers Parthasarathy Bhuvaragan (1): tipc: fix cleanup at module unload Peter Ujfalusi (1): ARM: OMAP1: DMA: Correct the number of logical channels Rui Sousa (1): net: fec: fix multicast filtering hardware setup Trond Myklebust (1): NFSv4: Fix client recovery when server reboots multiple times Vlad Tsyrklevich (1): net/appletalk: Fix kernel memory disclosure arch/arm/mach-omap1/dma.c | 16 +++++++--------- drivers/net/appletalk/ipddp.c | 2 +- drivers/net/ethernet/freescale/fec_main.c | 23 +++++++++-------------- drivers/staging/lustre/lustre/llite/llite_mmap.c | 4 +--- fs/nfs/nfs4proc.c | 3 --- fs/nfs/nfs4state.c | 1 - include/linux/buffer_head.h | 4 +--- net/ipv6/ip6_vti.c | 2 +- net/sctp/debug.c | 2 +- net/tipc/server.c | 4 +--- 10 files changed, 22 insertions(+), 39 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaIH/kAAoJEN6mb/eXdyzc7mAP/3yIZQSqf9D4m3Ze4zUD8MAL DP6L5qmUz79FFzXaTtrles3Shn48P1I+r1o4Gqz2y0Nf6wZu+jmeKdaeByAeM1av G69vHv35BnuooGhnrqBE/xM2EAZQ4eybeyVUFRztC07+LxX/9+CuCM13h5A2VJ07 Q2tNXd6W4l18cgfR5AeTy+x2kkoQsWU64XtZeZkT7fax02FBme7Q+jCRcK2TJYHy MJFh+4yTTmwv0wOGCTUU8hdIdoOIZxBs/eQ1VbxXvzzuvNmucJzNEa2sG4pFB02a p5e9SzxH/guiUoEuYX4yFWQNO48bh+6XvPpKMo2hR209jTHh7jlcJhb+6Ei46RXs U6hIjHDOYoGOufolRNudCBsfrJKECxQzLi//Qx69Aq2Lww8OkgVIJq3nd0/0YP83 J0MD+8B0ofncHo4ietTt98Udz2xklr+gmOJLKggLGVbbn5symAUkSbWV4164O87r a3o7mzRNky6JI/bQVyqGHvnBxIGMWzTb2gf1bf1HWwADrabcDYDpOpsNc5u7VkNa n5GDf+IuiXtprc242BtuyPiODc8dDctmCwoqegOaytUNJWv5lHNw/jW324DeZ/BF g2yFet6HdsbDBjEvo5rOMHisbr+m7ckgor1lmOnKmSuu/ZtIdbkSw7P0iHPOj2Id m6Zzb8HW7iAkjezRFJyo =xF38 -----END PGP SIGNATURE-----

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [PATCH] x86/efi-bgrt: Replace early_memremap() with memremap()

by Ghannam, Yazen

Upstream commit ID: e2c90dd7e11e3025b46719a79fb4bb1e7a5cef9f Prerequisite commit: "50a0cb565246 x86/efi-bgrt: Fix kernel panic when mapping BGRT data" Reason: Fixes the following call trace on AMD Fam17h systems. [ +0.019604] ------------[ cut here ]------------ [ +0.000008] WARNING: CPU: 0 PID: 0 at /home/yghannam/linux-amd-yazen/mm/early_ioremap.c:122 __early_ioremap+0x9b/0x1bd() [ +0.000006] Modules linked in: [ +0.000006] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.103-HEAD #2 ... [ +0.000006] 0000000000000286 02cb38f113d2874f ffffffff81e03e50 ffffffff813e0767 [ +0.000007] 0000000000000000 ffffffff81c9e5f0 ffffffff81e03e88 ffffffff81080192 [ +0.000007] 0000000074d32018 0000000000000000 0000000000000001 0000000000000001 [ +0.000007] Call Trace: [ +0.000007] [<ffffffff813e0767>] dump_stack+0x63/0x8c [ +0.000006] [<ffffffff81080192>] warn_slowpath_common+0x82/0xc0 [ +0.000005] [<ffffffff810802da>] warn_slowpath_null+0x1a/0x20 [ +0.000004] [<ffffffff81fbb86e>] __early_ioremap+0x9b/0x1bd [ +0.000006] [<ffffffff81fa5476>] ? __early_set_fixmap+0x84/0x95 [ +0.000005] [<ffffffff811adc75>] ? kmalloc_slab+0x5/0xa0 [ +0.000005] [<ffffffff81fbbb66>] early_ioremap+0x13/0x15 [ +0.000005] [<ffffffff81fa860b>] efi_bgrt_init+0x192/0x1ea [ +0.000004] [<ffffffff81fa7b68>] efi_late_init+0x9/0xb [ +0.000006] [<ffffffff81f88002>] start_kernel+0x46c/0x49c [ +0.000005] [<ffffffff81f87120>] ? early_idt_handler_array+0x120/0x120 [ +0.000005] [<ffffffff81f8732d>] x86_64_start_reservations+0x2a/0x2c [ +0.000004] [<ffffffff81f8746a>] x86_64_start_kernel+0x13b/0x15e [ +0.000009] ---[ end trace f9b2fbcd6a135369 ]--- [ +0.000004] Ignoring BGRT: failed to map image memory Stable version to apply to: 4.4.x Thanks, Yazen

7 years, 7 months

2
3
0 0

[Linux-stable-mirror] [PATCH rdma-rc v4] IB/core: Only enforce security for InfiniBand

by Dan Jurgens

From: Daniel Jurgens <danielj(a)mellanox.com> For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL. Cc: Paul Moore <paul(a)paul-moore.com> Cc: Don Dutile <ddutile(a)redhat.com> Cc: stable(a)vger.kernel.org Reported-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs") Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Tested-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> --- Changelog: v3->v4: Unlock in error flow v2->v3: Fix build warning v1->v2: Fixed build errors v0->v1: Added proper SElinux patch --- drivers/infiniband/core/security.c | 50 +++++++++++++++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c index 209d057..817d554 100644 --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec) int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev) { + u8 i = rdma_start_port(dev); + bool is_ib = false; int ret; + while (i <= rdma_end_port(dev) && !is_ib) + is_ib = rdma_protocol_ib(dev, i++); + + /* If this isn't an IB device don't create the security context */ + if (!is_ib) + return 0; + qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL); if (!qp->qp_sec) return -ENOMEM; @@ -441,6 +450,10 @@ int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev) void ib_destroy_qp_security_begin(struct ib_qp_security *sec) { + /* Return if not IB */ + if (!sec) + return; + mutex_lock(&sec->mutex); /* Remove the QP from the lists so it won't get added to @@ -470,6 +483,10 @@ void ib_destroy_qp_security_abort(struct ib_qp_security *sec) int ret; int i; + /* Return if not IB */ + if (!sec) + return; + /* If a concurrent cache update is in progress this * QP security could be marked for an error state * transition. Wait for this to complete. @@ -505,6 +522,10 @@ void ib_destroy_qp_security_end(struct ib_qp_security *sec) { int i; + /* Return if not IB */ + if (!sec) + return; + /* If a concurrent cache update is occurring we must * wait until this QP security structure is processed * in the QP to error flow before destroying it because @@ -557,7 +578,7 @@ int ib_security_modify_qp(struct ib_qp *qp, { int ret = 0; struct ib_ports_pkeys *tmp_pps; - struct ib_ports_pkeys *new_pps; + struct ib_ports_pkeys *new_pps = NULL; struct ib_qp *real_qp = qp->real_qp; bool special_qp = (real_qp->qp_type == IB_QPT_SMI || real_qp->qp_type == IB_QPT_GSI || @@ -565,18 +586,27 @@ int ib_security_modify_qp(struct ib_qp *qp, bool pps_change = ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) || (qp_attr_mask & IB_QP_ALT_PATH)); + WARN_ONCE((qp_attr_mask & IB_QP_PORT && + rdma_protocol_ib(real_qp->device, qp_attr->port_num) && + !real_qp->qp_sec), + "%s: QP security is not initialized for IB QP: %d\n", + __func__, real_qp->qp_num); + /* The port/pkey settings are maintained only for the real QP. Open * handles on the real QP will be in the shared_qp_list. When * enforcing security on the real QP all the shared QPs will be * checked as well. */ - if (pps_change && !special_qp) { + if (pps_change && !special_qp && real_qp->qp_sec) { mutex_lock(&real_qp->qp_sec->mutex); new_pps = get_new_pps(real_qp, qp_attr, qp_attr_mask); - + if (!new_pps) { + mutex_unlock(&real_qp->qp_sec->mutex); + return -ENOMEM; + } /* Add this QP to the lists for the new port * and pkey settings before checking for permission * in case there is a concurrent cache update @@ -600,7 +630,7 @@ int ib_security_modify_qp(struct ib_qp *qp, qp_attr_mask, udata); - if (pps_change && !special_qp) { + if (new_pps) { /* Clean up the lists and free the appropriate * ports_pkeys structure. */ @@ -630,6 +660,9 @@ static int ib_security_pkey_access(struct ib_device *dev, u16 pkey; int ret; + if (!rdma_protocol_ib(dev, port_num)) + return 0; + ret = ib_get_cached_pkey(dev, port_num, pkey_index, &pkey); if (ret) return ret; @@ -663,6 +696,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent, { int ret; + if (!rdma_protocol_ib(agent->device, agent->port_num)) + return 0; + ret = security_ib_alloc_security(&agent->security); if (ret) return ret; @@ -688,6 +724,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent, void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent) { + if (!rdma_protocol_ib(agent->device, agent->port_num)) + return; + security_ib_free_security(agent->security); if (agent->lsm_nb_reg) unregister_lsm_notifier(&agent->lsm_nb); @@ -695,6 +734,9 @@ void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent) int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index) { + if (!rdma_protocol_ib(map->agent.device, map->agent.port_num)) + return 0; + if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed) return -EACCES; -- 1.8.3.1

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [PATCH 1/2] Ensure that the SCSI error handler gets woken up

by Bart Van Assche

If scsi_eh_scmd_add() is called concurrently with scsi_host_queue_ready() while shost->host_blocked > 0 then it can happen that neither function wakes up the SCSI error handler. Fix this by making every function that decreases the host_busy counter wake up the error handler if necessary and by protecting the host_failed checks with the SCSI host lock. Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com> Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com> Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: <stable(a)vger.kernel.org> --- drivers/scsi/scsi_error.c | 8 +++++++- drivers/scsi/scsi_lib.c | 39 ++++++++++++++++++++++++++++----------- 2 files changed, 35 insertions(+), 12 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 5e89049e9b4e..b22a9a23c74c 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -233,19 +233,25 @@ static void scsi_eh_reset(struct scsi_cmnd *scmd) void scsi_eh_scmd_add(struct scsi_cmnd *scmd) { struct Scsi_Host *shost = scmd->device->host; + enum scsi_host_state shost_state; unsigned long flags; int ret; WARN_ON_ONCE(!shost->ehandler); spin_lock_irqsave(shost->host_lock, flags); + shost_state = shost->shost_state; if (scsi_host_set_state(shost, SHOST_RECOVERY)) { ret = scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY); WARN_ON_ONCE(ret); } if (shost->eh_deadline != -1 && !shost->last_reset) shost->last_reset = jiffies; - + if (shost_state != shost->shost_state) { + spin_unlock_irqrestore(shost->host_lock, flags); + synchronize_rcu(); + spin_lock_irqsave(shost->host_lock, flags); + } scsi_eh_reset(scmd); list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q); shost->host_failed++; diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index b6d3842b6809..7d18fb245d7d 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd) cmd->cmd_len = scsi_command_size(cmd->cmnd); } -void scsi_device_unbusy(struct scsi_device *sdev) +/* + * Decrement the host_busy counter and wake up the error handler if necessary. + * Avoid as follows that the error handler is not woken up if shost->host_busy + * == shost->host_failed: use synchronize_rcu() in scsi_eh_scmd_add() in + * combination with an RCU read lock in this function to ensure that this + * function in its entirety either finishes before scsi_eh_scmd_add() + * increases the host_failed counter or that it notices the shost state change + * made by scsi_eh_scmd_add(). + */ +static void scsi_dec_host_busy(struct Scsi_Host *shost) { - struct Scsi_Host *shost = sdev->host; - struct scsi_target *starget = scsi_target(sdev); unsigned long flags; + rcu_read_lock(); atomic_dec(&shost->host_busy); - if (starget->can_queue > 0) - atomic_dec(&starget->target_busy); - - if (unlikely(scsi_host_in_recovery(shost) && - (shost->host_failed || shost->host_eh_scheduled))) { + if (unlikely(scsi_host_in_recovery(shost))) { spin_lock_irqsave(shost->host_lock, flags); - scsi_eh_wakeup(shost); + if (shost->host_failed || shost->host_eh_scheduled) + scsi_eh_wakeup(shost); spin_unlock_irqrestore(shost->host_lock, flags); } + rcu_read_unlock(); +} + +void scsi_device_unbusy(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + struct scsi_target *starget = scsi_target(sdev); + + scsi_dec_host_busy(shost); + + if (starget->can_queue > 0) + atomic_dec(&starget->target_busy); atomic_dec(&sdev->device_busy); } @@ -1531,7 +1548,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q, list_add_tail(&sdev->starved_entry, &shost->starved_list); spin_unlock_irq(shost->host_lock); out_dec: - atomic_dec(&shost->host_busy); + scsi_dec_host_busy(shost); return 0; } @@ -2017,7 +2034,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, return BLK_STS_OK; out_dec_host_busy: - atomic_dec(&shost->host_busy); + scsi_dec_host_busy(shost); out_dec_target_busy: if (scsi_target(sdev)->can_queue > 0) atomic_dec(&scsi_target(sdev)->target_busy); -- 2.15.0

7 years, 7 months

4
4
0 0

[Linux-stable-mirror] Patch "x86/efi-bgrt: Replace early_memremap() with memremap()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/efi-bgrt: Replace early_memremap() with memremap() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-efi-bgrt-replace-early_memremap-with-memremap.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e2c90dd7e11e3025b46719a79fb4bb1e7a5cef9f Mon Sep 17 00:00:00 2001 From: Matt Fleming <matt(a)codeblueprint.co.uk> Date: Mon, 21 Dec 2015 14:12:52 +0000 Subject: x86/efi-bgrt: Replace early_memremap() with memremap() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Matt Fleming <matt(a)codeblueprint.co.uk> commit e2c90dd7e11e3025b46719a79fb4bb1e7a5cef9f upstream. Môshe reported the following warning triggered on his machine since commit 50a0cb565246 ("x86/efi-bgrt: Fix kernel panic when mapping BGRT data"), [ 0.026936] ------------[ cut here ]------------ [ 0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137 __early_ioremap+0x102/0x1bb() [ 0.026941] Modules linked in: [ 0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2 [ 0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05 07/14/2015 [ 0.026946] 0000000000000000 900f03d5a116524d ffffffff81c03e60 ffffffff813a3fff [ 0.026948] 0000000000000000 ffffffff81c03e98 ffffffff810a0852 00000000d7b76000 [ 0.026949] 0000000000000000 0000000000000001 0000000000000001 000000000000017c [ 0.026951] Call Trace: [ 0.026955] [<ffffffff813a3fff>] dump_stack+0x44/0x55 [ 0.026958] [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0 [ 0.026959] [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20 [ 0.026961] [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb [ 0.026962] [<ffffffff81d8c602>] early_memremap+0x13/0x15 [ 0.026964] [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad [ 0.026966] [<ffffffff81d778ec>] efi_late_init+0x9/0xb [ 0.026968] [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f [ 0.026970] [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120 [ 0.026972] [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c [ 0.026974] [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d [ 0.026977] ---[ end trace f9b3812eb8e24c58 ]--- [ 0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory early_memremap() has an upper limit on the size of mapping it can handle which is ~200KB. Clearly the BGRT image on Môshe's machine is much larger than that. There's actually no reason to restrict ourselves to using the early_* version of memremap() - the ACPI BGRT driver is invoked late enough in boot that we can use the standard version, with the benefit that the late version allows mappings of arbitrary size. Reported-by: Môshe van der Sterre <me(a)moshe.nl> Tested-by: Môshe van der Sterre <me(a)moshe.nl> Signed-off-by: Matt Fleming <matt(a)codeblueprint.co.uk> Cc: Josh Triplett <josh(a)joshtriplett.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com> Cc: Borislav Petkov <bp(a)suse.de> Link: http://lkml.kernel.org/r/1450707172-12561-1-git-send-email-matt@codebluepri… Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: "Ghannam, Yazen" <Yazen.Ghannam(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/platform/efi/efi-bgrt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/x86/platform/efi/efi-bgrt.c +++ b/arch/x86/platform/efi/efi-bgrt.c @@ -69,14 +69,14 @@ void __init efi_bgrt_init(void) return; } - image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header)); + image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB); if (!image) { pr_err("Ignoring BGRT: failed to map image header memory\n"); return; } memcpy(&bmp_header, image, sizeof(bmp_header)); - early_memunmap(image, sizeof(bmp_header)); + memunmap(image); bgrt_image_size = bmp_header.size; bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN); @@ -86,7 +86,7 @@ void __init efi_bgrt_init(void) return; } - image = early_memremap(bgrt_tab->image_address, bmp_header.size); + image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB); if (!image) { pr_err("Ignoring BGRT: failed to map image memory\n"); kfree(bgrt_image); @@ -95,5 +95,5 @@ void __init efi_bgrt_init(void) } memcpy(bgrt_image, image, bgrt_image_size); - early_memunmap(image, bmp_header.size); + memunmap(image); } Patches currently in stable-queue which might be from matt(a)codeblueprint.co.uk are queue-4.4/x86-mm-pat-ensure-cpa-pfn-only-contains-page-frame-numbers.patch queue-4.4/x86-efi-hoist-page-table-switching-code-into-efi_call_virt.patch queue-4.4/x86-efi-build-our-own-page-table-structures.patch queue-4.4/x86-efi-bgrt-replace-early_memremap-with-memremap.patch queue-4.4/x86-efi-bgrt-fix-kernel-panic-when-mapping-bgrt-data.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/efi-bgrt: Fix kernel panic when mapping BGRT data" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/efi-bgrt: Fix kernel panic when mapping BGRT data to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-efi-bgrt-fix-kernel-panic-when-mapping-bgrt-data.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 50a0cb565246f20d59cdb161778531e4b19d35ac Mon Sep 17 00:00:00 2001 From: Sai Praneeth <sai.praneeth.prakhya(a)intel.com> Date: Wed, 9 Dec 2015 15:41:08 -0800 Subject: x86/efi-bgrt: Fix kernel panic when mapping BGRT data From: Sai Praneeth <sai.praneeth.prakhya(a)intel.com> commit 50a0cb565246f20d59cdb161778531e4b19d35ac upstream. Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page table structures") efi regions have a separate page directory called "efi_pgd". In order to access any efi region we have to first shift %cr3 to this page table. In the bgrt code we are trying to copy bgrt_header and image, but these regions fall under "EFI_BOOT_SERVICES_DATA" and to access these regions we have to shift %cr3 to efi_pgd and not doing so will cause page fault as shown below. [ 0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4 [ 0.259126] Freeing SMP alternatives memory: 32K (ffffffff8230e000 - ffffffff82316000) [ 0.271803] BUG: unable to handle kernel paging request at fffffffefce35002 [ 0.279740] IP: [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd [ 0.286383] PGD 300f067 PUD 0 [ 0.289879] Oops: 0000 [#1] SMP [ 0.293566] Modules linked in: [ 0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1-eywa-eywa-built-in-47041+ #2 [ 0.306619] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.1511110114 11/11/2015 [ 0.320925] task: ffffffff820134c0 ti: ffffffff82000000 task.ti: ffffffff82000000 [ 0.329420] RIP: 0010:[<ffffffff821bca49>] [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd [ 0.338821] RSP: 0000:ffffffff82003f18 EFLAGS: 00010246 [ 0.344852] RAX: fffffffefce35000 RBX: fffffffefce35000 RCX: fffffffefce2b000 [ 0.352952] RDX: 000000008a82b000 RSI: ffffffff8235bb80 RDI: 000000008a835000 [ 0.361050] RBP: ffffffff82003f30 R08: 000000008a865000 R09: ffffffffff202850 [ 0.369149] R10: ffffffff811ad62f R11: 0000000000000000 R12: 0000000000000000 [ 0.377248] R13: ffff88016dbaea40 R14: ffffffff822622c0 R15: ffffffff82003fb0 [ 0.385348] FS: 0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000 [ 0.394533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.401054] CR2: fffffffefce35002 CR3: 000000000300c000 CR4: 00000000003406f0 [ 0.409153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.417252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.425350] Stack: [ 0.427638] ffffffffffffffff ffffffff82256900 ffff88016dbaea40 ffffffff82003f40 [ 0.436086] ffffffff821bbce0 ffffffff82003f88 ffffffff8219c0c2 0000000000000000 [ 0.444533] ffffffff8219ba4a ffffffff822622c0 0000000000083000 00000000ffffffff [ 0.452978] Call Trace: [ 0.455763] [<ffffffff821bbce0>] efi_late_init+0x9/0xb [ 0.461697] [<ffffffff8219c0c2>] start_kernel+0x463/0x47f [ 0.467928] [<ffffffff8219ba4a>] ? set_init_arg+0x55/0x55 [ 0.474159] [<ffffffff8219b120>] ? early_idt_handler_array+0x120/0x120 [ 0.481669] [<ffffffff8219b5ee>] x86_64_start_reservations+0x2a/0x2c [ 0.488982] [<ffffffff8219b72d>] x86_64_start_kernel+0x13d/0x14c [ 0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89 c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4 <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$ [ 0.518151] RIP [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd [ 0.524888] RSP <ffffffff82003f18> [ 0.528851] CR2: fffffffefce35002 [ 0.532615] ---[ end trace 7b06521e6ebf2aea ]--- [ 0.537852] Kernel panic - not syncing: Attempted to kill the idle task! As said above one way to fix this bug is to shift %cr3 to efi_pgd but we are not doing that way because it leaks inner details of how we switch to EFI page tables into a new call site and it also adds duplicate code. Instead, we remove the call to efi_lookup_mapped_addr() and always perform early_mem*() instead of early_io*() because we want to remap RAM regions and not I/O regions. We also delete efi_lookup_mapped_addr() because we are no longer using it. Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com> Reported-by: Wendy Wang <wendy.wang(a)intel.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Josh Triplett <josh(a)joshtriplett.org> Cc: Ricardo Neri <ricardo.neri(a)intel.com> Cc: Ravi Shankar <ravi.v.shankar(a)intel.com> Signed-off-by: Matt Fleming <matt(a)codeblueprint.co.uk> Cc: "Ghannam, Yazen" <Yazen.Ghannam(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/platform/efi/efi-bgrt.c | 39 ++++++++++++++------------------------- drivers/firmware/efi/efi.c | 32 -------------------------------- 2 files changed, 14 insertions(+), 57 deletions(-) --- a/arch/x86/platform/efi/efi-bgrt.c +++ b/arch/x86/platform/efi/efi-bgrt.c @@ -28,8 +28,7 @@ struct bmp_header { void __init efi_bgrt_init(void) { acpi_status status; - void __iomem *image; - bool ioremapped = false; + void *image; struct bmp_header bmp_header; if (acpi_disabled) @@ -70,20 +69,14 @@ void __init efi_bgrt_init(void) return; } - image = efi_lookup_mapped_addr(bgrt_tab->image_address); + image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header)); if (!image) { - image = early_ioremap(bgrt_tab->image_address, - sizeof(bmp_header)); - ioremapped = true; - if (!image) { - pr_err("Ignoring BGRT: failed to map image header memory\n"); - return; - } + pr_err("Ignoring BGRT: failed to map image header memory\n"); + return; } - memcpy_fromio(&bmp_header, image, sizeof(bmp_header)); - if (ioremapped) - early_iounmap(image, sizeof(bmp_header)); + memcpy(&bmp_header, image, sizeof(bmp_header)); + early_memunmap(image, sizeof(bmp_header)); bgrt_image_size = bmp_header.size; bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN); @@ -93,18 +86,14 @@ void __init efi_bgrt_init(void) return; } - if (ioremapped) { - image = early_ioremap(bgrt_tab->image_address, - bmp_header.size); - if (!image) { - pr_err("Ignoring BGRT: failed to map image memory\n"); - kfree(bgrt_image); - bgrt_image = NULL; - return; - } + image = early_memremap(bgrt_tab->image_address, bmp_header.size); + if (!image) { + pr_err("Ignoring BGRT: failed to map image memory\n"); + kfree(bgrt_image); + bgrt_image = NULL; + return; } - memcpy_fromio(bgrt_image, image, bgrt_image_size); - if (ioremapped) - early_iounmap(image, bmp_header.size); + memcpy(bgrt_image, image, bgrt_image_size); + early_memunmap(image, bmp_header.size); } --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -325,38 +325,6 @@ u64 __init efi_mem_desc_end(efi_memory_d return end; } -/* - * We can't ioremap data in EFI boot services RAM, because we've already mapped - * it as RAM. So, look it up in the existing EFI memory map instead. Only - * callable after efi_enter_virtual_mode and before efi_free_boot_services. - */ -void __iomem *efi_lookup_mapped_addr(u64 phys_addr) -{ - struct efi_memory_map *map; - void *p; - map = efi.memmap; - if (!map) - return NULL; - if (WARN_ON(!map->map)) - return NULL; - for (p = map->map; p < map->map_end; p += map->desc_size) { - efi_memory_desc_t *md = p; - u64 size = md->num_pages << EFI_PAGE_SHIFT; - u64 end = md->phys_addr + size; - if (!(md->attribute & EFI_MEMORY_RUNTIME) && - md->type != EFI_BOOT_SERVICES_CODE && - md->type != EFI_BOOT_SERVICES_DATA) - continue; - if (!md->virt_addr) - continue; - if (phys_addr >= md->phys_addr && phys_addr < end) { - phys_addr += md->virt_addr - md->phys_addr; - return (__force void __iomem *)(unsigned long)phys_addr; - } - } - return NULL; -} - static __initdata efi_config_table_type_t common_tables[] = { {ACPI_20_TABLE_GUID, "ACPI 2.0", &efi.acpi20}, {ACPI_TABLE_GUID, "ACPI", &efi.acpi}, Patches currently in stable-queue which might be from sai.praneeth.prakhya(a)intel.com are queue-4.4/x86-mm-pat-ensure-cpa-pfn-only-contains-page-frame-numbers.patch queue-4.4/x86-efi-hoist-page-table-switching-code-into-efi_call_virt.patch queue-4.4/x86-efi-build-our-own-page-table-structures.patch queue-4.4/x86-efi-bgrt-replace-early_memremap-with-memremap.patch queue-4.4/x86-efi-bgrt-fix-kernel-panic-when-mapping-bgrt-data.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror