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

[Linux-stable-mirror] Patch "iommu/vt-d: Fix scatterlist offset handling" 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 iommu/vt-d: Fix scatterlist offset handling 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: iommu-vt-d-fix-scatterlist-offset-handling.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 29a90b70893817e2f2bb3cea40a29f5308e21b21 Mon Sep 17 00:00:00 2001 From: Robin Murphy <robin.murphy(a)arm.com> Date: Thu, 28 Sep 2017 15:14:01 +0100 Subject: iommu/vt-d: Fix scatterlist offset handling From: Robin Murphy <robin.murphy(a)arm.com> commit 29a90b70893817e2f2bb3cea40a29f5308e21b21 upstream. The intel-iommu DMA ops fail to correctly handle scatterlists where sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed appropriately based on the page-aligned portion of the offset, but the mapping is set up relative to sg->page, which means it fails to actually cover the whole buffer (and in the worst case doesn't cover it at all): (sg->dma_address + sg->dma_len) ----+ sg->dma_address ---------+ | iov_pfn------+ | | | | | v v v iova: a b c d e f |--------|--------|--------|--------|--------| <...calculated....> [_____mapped______] pfn: 0 1 2 3 4 5 |--------|--------|--------|--------|--------| ^ ^ ^ | | | sg->page ----+ | | sg->offset --------------+ | (sg->offset + sg->length) ----------+ As a result, the caller ends up overrunning the mapping into whatever lies beyond, which usually goes badly: [ 429.645492] DMAR: DRHD: handling fault status reg 2 [ 429.650847] DMAR: [DMA Write] Request device [02:00.4] fault addr f2682000 ... Whilst this is a fairly rare occurrence, it can happen from the result of intermediate scatterlist processing such as scatterwalk_ffwd() in the crypto layer. Whilst that particular site could be fixed up, it still seems worthwhile to bring intel-iommu in line with other DMA API implementations in handling this robustly. To that end, fix the intel_map_sg() path to line up the mapping correctly (in units of MM pages rather than VT-d pages to match the aligned_nrpages() calculation) regardless of the offset, and use sg_phys() consistently for clarity. Reported-by: Harsh Jain <Harsh(a)chelsio.com> Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> Reviewed by: Ashok Raj <ashok.raj(a)intel.com> Tested by: Jacob Pan <jacob.jun.pan(a)intel.com> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/intel-iommu.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2254,10 +2254,12 @@ static int __domain_mapping(struct dmar_ uint64_t tmp; if (!sg_res) { + unsigned int pgoff = sg->offset & ~PAGE_MASK; + sg_res = aligned_nrpages(sg->offset, sg->length); - sg->dma_address = ((dma_addr_t)iov_pfn << VTD_PAGE_SHIFT) + sg->offset; + sg->dma_address = ((dma_addr_t)iov_pfn << VTD_PAGE_SHIFT) + pgoff; sg->dma_length = sg->length; - pteval = page_to_phys(sg_page(sg)) | prot; + pteval = (sg_phys(sg) - pgoff) | prot; phys_pfn = pteval >> VTD_PAGE_SHIFT; } @@ -3790,7 +3792,7 @@ static int intel_nontranslate_map_sg(str for_each_sg(sglist, sg, nelems, i) { BUG_ON(!sg_page(sg)); - sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset; + sg->dma_address = sg_phys(sg); sg->dma_length = sg->length; } return nelems; Patches currently in stable-queue which might be from robin.murphy(a)arm.com are queue-4.14/iommu-vt-d-fix-scatterlist-offset-handling.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: stm32: fix adc/trigger link error" 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 iio: stm32: fix adc/trigger link error 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: iio-stm32-fix-adc-trigger-link-error.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 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 From: Arnd Bergmann <arnd(a)arndb.de> commit 6d745ee8b5e81f3a33791e3c854fbbfd6f3e585e upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/iio/timer/stm32-lptim-trigger.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- 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 Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/iio-stm32-fix-adc-trigger-link-error.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: health: max30102: Temperature should be in milli Celsius" 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 iio: health: max30102: Temperature should be in milli Celsius 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: iio-health-max30102-temperature-should-be-in-milli-celsius.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 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 From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net> commit ad44a9f804c1591ba2a2ec0ac8d916a515d2790c upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/health/max30102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iio/health/max30102.c +++ b/drivers/iio/health/max30102.c @@ -371,7 +371,7 @@ static int max30102_read_raw(struct iio_ 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; Patches currently in stable-queue which might be from pmeerw(a)pmeerw.net are queue-4.14/iio-health-max30102-temperature-should-be-in-milli-celsius.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13" 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 iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13 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: iio-adc-meson-saradc-meson8-and-meson8b-do-not-have-reg11-and-reg13.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 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 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> commit 96748823c483c6eed8321f78bd128dd33f09c55c upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/meson_saradc.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) --- 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); @@ -860,6 +868,7 @@ static const struct iio_info meson_sar_a 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", }; @@ -867,6 +876,7 @@ static const struct meson_sar_adc_data m 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", }; @@ -874,6 +884,7 @@ static const struct meson_sar_adc_data m 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", }; @@ -881,6 +892,7 @@ static const struct meson_sar_adc_data m 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", }; @@ -888,6 +900,7 @@ static const struct meson_sar_adc_data m 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", }; @@ -965,7 +978,7 @@ static int meson_sar_adc_probe(struct pl 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); Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.14/iio-adc-meson-saradc-initialize-the-bandgap-correctly-on-older-socs.patch queue-4.14/iio-adc-meson-saradc-fix-the-bit_idx-of-the-adc_en-clock.patch queue-4.14/iio-adc-meson-saradc-meson8-and-meson8b-do-not-have-reg11-and-reg13.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs" 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 iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs 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: iio-adc-meson-saradc-initialize-the-bandgap-correctly-on-older-socs.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 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 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> commit d85eed9f576369bc90322659de96b7dbea1f9a57 upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/meson_saradc.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) --- 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 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(struc 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(struc 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(stru 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); @@ -845,30 +859,35 @@ static const struct iio_info meson_sar_a 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", }; Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.14/iio-adc-meson-saradc-initialize-the-bandgap-correctly-on-older-socs.patch queue-4.14/iio-adc-meson-saradc-fix-the-bit_idx-of-the-adc_en-clock.patch queue-4.14/iio-adc-meson-saradc-meson8-and-meson8b-do-not-have-reg11-and-reg13.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: adc: meson-saradc: fix the bit_idx of the adc_en clock" 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 iio: adc: meson-saradc: fix the bit_idx of the adc_en clock 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: iio-adc-meson-saradc-fix-the-bit_idx-of-the-adc_en-clock.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 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 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> commit 7a6b0420d2fe4ce59437bd318826fe468f0d71ae upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/meson_saradc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 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 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); Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.14/iio-adc-meson-saradc-initialize-the-bandgap-correctly-on-older-socs.patch queue-4.14/iio-adc-meson-saradc-fix-the-bit_idx-of-the-adc_en-clock.patch queue-4.14/iio-adc-meson-saradc-meson8-and-meson8b-do-not-have-reg11-and-reg13.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: adc: cpcap: fix incorrect validation" 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 iio: adc: cpcap: fix incorrect validation 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: iio-adc-cpcap-fix-incorrect-validation.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 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 From: Pan Bian <bianpan2016(a)163.com> commit 81b039ec36a41a5451e1e36f05bb055eceab1dc8 upstream. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/cpcap-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iio/adc/cpcap-adc.c +++ b/drivers/iio/adc/cpcap-adc.c @@ -1012,7 +1012,7 @@ static int cpcap_adc_probe(struct platfo 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, Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.14/efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch queue-4.14/iio-adc-cpcap-fix-incorrect-validation.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/core: Only enforce security for InfiniBand" 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 IB/core: Only enforce security for InfiniBand 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: ib-core-only-enforce-security-for-infiniband.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 315d160c5a4e034a576a13aa21e7235d5c9ec609 Mon Sep 17 00:00:00 2001 From: Daniel Jurgens <danielj(a)mellanox.com> Date: Wed, 29 Nov 2017 20:10:39 +0200 Subject: IB/core: Only enforce security for InfiniBand From: Daniel Jurgens <danielj(a)mellanox.com> commit 315d160c5a4e034a576a13aa21e7235d5c9ec609 upstream. 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> 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> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/security.c | 50 ++++++++++++++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 4 deletions(-) --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct 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 @@ EXPORT_SYMBOL(ib_create_qp_security); 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 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 i { 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 * { 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 * 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_attr_mask, udata); - if (pps_change && !special_qp) { + if (new_pps) { /* Clean up the lists and free the appropriate * ports_pkeys structure. */ @@ -631,6 +661,9 @@ int ib_security_pkey_access(struct ib_de 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; @@ -665,6 +698,9 @@ int ib_mad_agent_security_setup(struct i { int ret; + if (!rdma_protocol_ib(agent->device, agent->port_num)) + return 0; + ret = security_ib_alloc_security(&agent->security); if (ret) return ret; @@ -690,6 +726,9 @@ int ib_mad_agent_security_setup(struct i 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); @@ -697,6 +736,9 @@ void ib_mad_agent_security_cleanup(struc 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; Patches currently in stable-queue which might be from danielj(a)mellanox.com are queue-4.14/ib-core-avoid-unnecessary-return-value-check.patch queue-4.14/ib-core-only-enforce-security-for-infiniband.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/core: Avoid unnecessary return value check" 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 IB/core: Avoid unnecessary return value check 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: ib-core-avoid-unnecessary-return-value-check.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 2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f Mon Sep 17 00:00:00 2001 From: Parav Pandit <parav(a)mellanox.com> Date: Thu, 2 Nov 2017 15:22:27 +0200 Subject: IB/core: Avoid unnecessary return value check From: Parav Pandit <parav(a)mellanox.com> commit 2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f upstream. Since there is nothing done with non zero return value, such check is avoided. Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/security.c | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -697,20 +697,13 @@ void ib_mad_agent_security_cleanup(struc int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index) { - int ret; - if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed) return -EACCES; - ret = ib_security_pkey_access(map->agent.device, - map->agent.port_num, - pkey_index, - map->agent.security); - - if (ret) - return ret; - - return 0; + return ib_security_pkey_access(map->agent.device, + map->agent.port_num, + pkey_index, + map->agent.security); } #endif /* CONFIG_SECURITY_INFINIBAND */ Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.14/ib-core-avoid-unnecessary-return-value-check.patch queue-4.14/ib-core-only-enforce-security-for-infiniband.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "hv: kvp: Avoid reading past allocated blocks from KVP file" 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 hv: kvp: Avoid reading past allocated blocks from KVP file 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: hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.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 297d6b6e56c2977fc504c61bbeeaa21296923f89 Mon Sep 17 00:00:00 2001 From: Paul Meyer <Paul.Meyer(a)microsoft.com> Date: Tue, 14 Nov 2017 13:06:47 -0700 Subject: hv: kvp: Avoid reading past allocated blocks from KVP file From: Paul Meyer <Paul.Meyer(a)microsoft.com> commit 297d6b6e56c2977fc504c61bbeeaa21296923f89 upstream. While reading in more than one block (50) of KVP records, the allocation goes per block, but the reads used the total number of allocated records (without resetting the pointer/stream). This causes the records buffer to overrun when the refresh reads more than one block over the previous capacity (e.g. reading more than 100 KVP records whereas the in-memory database was empty before). Fix this by reading the correct number of KVP records from file each time. Signed-off-by: Paul Meyer <Paul.Meyer(a)microsoft.com> Signed-off-by: Long Li <longli(a)microsoft.com> Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/hv/hv_kvp_daemon.c | 70 +++++++++-------------------------------------- 1 file changed, 14 insertions(+), 56 deletions(-) --- a/tools/hv/hv_kvp_daemon.c +++ b/tools/hv/hv_kvp_daemon.c @@ -193,11 +193,14 @@ static void kvp_update_mem_state(int poo for (;;) { readp = &record[records_read]; records_read += fread(readp, sizeof(struct kvp_record), - ENTRIES_PER_BLOCK * num_blocks, - filep); + ENTRIES_PER_BLOCK * num_blocks - records_read, + filep); if (ferror(filep)) { - syslog(LOG_ERR, "Failed to read file, pool: %d", pool); + syslog(LOG_ERR, + "Failed to read file, pool: %d; error: %d %s", + pool, errno, strerror(errno)); + kvp_release_lock(pool); exit(EXIT_FAILURE); } @@ -210,6 +213,7 @@ static void kvp_update_mem_state(int poo if (record == NULL) { syslog(LOG_ERR, "malloc failed"); + kvp_release_lock(pool); exit(EXIT_FAILURE); } continue; @@ -224,15 +228,11 @@ static void kvp_update_mem_state(int poo fclose(filep); kvp_release_lock(pool); } + static int kvp_file_init(void) { int fd; - FILE *filep; - size_t records_read; char *fname; - struct kvp_record *record; - struct kvp_record *readp; - int num_blocks; int i; int alloc_unit = sizeof(struct kvp_record) * ENTRIES_PER_BLOCK; @@ -246,61 +246,19 @@ static int kvp_file_init(void) for (i = 0; i < KVP_POOL_COUNT; i++) { fname = kvp_file_info[i].fname; - records_read = 0; - num_blocks = 1; sprintf(fname, "%s/.kvp_pool_%d", KVP_CONFIG_LOC, i); fd = open(fname, O_RDWR | O_CREAT | O_CLOEXEC, 0644 /* rw-r--r-- */); if (fd == -1) return 1; - - filep = fopen(fname, "re"); - if (!filep) { - close(fd); - return 1; - } - - record = malloc(alloc_unit * num_blocks); - if (record == NULL) { - fclose(filep); - close(fd); - return 1; - } - for (;;) { - readp = &record[records_read]; - records_read += fread(readp, sizeof(struct kvp_record), - ENTRIES_PER_BLOCK, - filep); - - if (ferror(filep)) { - syslog(LOG_ERR, "Failed to read file, pool: %d", - i); - exit(EXIT_FAILURE); - } - - if (!feof(filep)) { - /* - * We have more data to read. - */ - num_blocks++; - record = realloc(record, alloc_unit * - num_blocks); - if (record == NULL) { - fclose(filep); - close(fd); - return 1; - } - continue; - } - break; - } kvp_file_info[i].fd = fd; - kvp_file_info[i].num_blocks = num_blocks; - kvp_file_info[i].records = record; - kvp_file_info[i].num_records = records_read; - fclose(filep); - + kvp_file_info[i].num_blocks = 1; + kvp_file_info[i].records = malloc(alloc_unit); + if (kvp_file_info[i].records == NULL) + return 1; + kvp_file_info[i].num_records = 0; + kvp_update_mem_state(i); } return 0; Patches currently in stable-queue which might be from Paul.Meyer(a)microsoft.com are queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "firmware: vpd: Tie firmware kobject to device lifetime" 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 firmware: vpd: Tie firmware kobject to device lifetime 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: firmware-vpd-tie-firmware-kobject-to-device-lifetime.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 e4b28b3c3a405b251fa25db58abe1512814a680a Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Wed, 15 Nov 2017 13:00:44 -0800 Subject: firmware: vpd: Tie firmware kobject to device lifetime From: Guenter Roeck <linux(a)roeck-us.net> commit e4b28b3c3a405b251fa25db58abe1512814a680a upstream. It doesn't make sense to have /sys/firmware/vpd if the device is not instantiated, so tie its lifetime to the device. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/google/vpd.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) --- a/drivers/firmware/google/vpd.c +++ b/drivers/firmware/google/vpd.c @@ -295,7 +295,17 @@ static int vpd_probe(struct platform_dev if (ret) return ret; - return vpd_sections_init(entry.cbmem_addr); + vpd_kobj = kobject_create_and_add("vpd", firmware_kobj); + if (!vpd_kobj) + return -ENOMEM; + + ret = vpd_sections_init(entry.cbmem_addr); + if (ret) { + kobject_put(vpd_kobj); + return ret; + } + + return 0; } static int vpd_remove(struct platform_device *pdev) @@ -303,6 +313,8 @@ static int vpd_remove(struct platform_de vpd_section_destroy(&ro_vpd); vpd_section_destroy(&rw_vpd); + kobject_put(vpd_kobj); + return 0; } @@ -322,10 +334,6 @@ static int __init vpd_platform_init(void if (IS_ERR(pdev)) return PTR_ERR(pdev); - vpd_kobj = kobject_create_and_add("vpd", firmware_kobj); - if (!vpd_kobj) - return -ENOMEM; - platform_driver_register(&vpd_driver); return 0; @@ -333,7 +341,6 @@ static int __init vpd_platform_init(void static void __exit vpd_platform_exit(void) { - kobject_put(vpd_kobj); } module_init(vpd_platform_init); Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "firmware: vpd: Fix platform driver and device registration/unregistration" 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 firmware: vpd: Fix platform driver and device registration/unregistration 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: firmware-vpd-fix-platform-driver-and-device-registration-unregistration.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 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Wed, 15 Nov 2017 13:00:45 -0800 Subject: firmware: vpd: Fix platform driver and device registration/unregistration From: Guenter Roeck <linux(a)roeck-us.net> commit 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc upstream. The driver exit function needs to unregister both platform device and driver. Also, during registration, register driver first and perform error checks. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/google/vpd.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) --- a/drivers/firmware/google/vpd.c +++ b/drivers/firmware/google/vpd.c @@ -326,21 +326,29 @@ static struct platform_driver vpd_driver }, }; +static struct platform_device *vpd_pdev; + static int __init vpd_platform_init(void) { - struct platform_device *pdev; - - pdev = platform_device_register_simple("vpd", -1, NULL, 0); - if (IS_ERR(pdev)) - return PTR_ERR(pdev); + int ret; - platform_driver_register(&vpd_driver); + ret = platform_driver_register(&vpd_driver); + if (ret) + return ret; + + vpd_pdev = platform_device_register_simple("vpd", -1, NULL, 0); + if (IS_ERR(vpd_pdev)) { + platform_driver_unregister(&vpd_driver); + return PTR_ERR(vpd_pdev); + } return 0; } static void __exit vpd_platform_exit(void) { + platform_device_unregister(vpd_pdev); + platform_driver_unregister(&vpd_driver); } module_init(vpd_platform_init); Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "firmware: vpd: Destroy vpd sections in remove function" 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 firmware: vpd: Destroy vpd sections in remove function 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: firmware-vpd-destroy-vpd-sections-in-remove-function.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 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Wed, 15 Nov 2017 13:00:43 -0800 Subject: firmware: vpd: Destroy vpd sections in remove function From: Guenter Roeck <linux(a)roeck-us.net> commit 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 upstream. vpd sections are initialized during probe and thus should be destroyed in the remove function. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/google/vpd.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/drivers/firmware/google/vpd.c +++ b/drivers/firmware/google/vpd.c @@ -298,8 +298,17 @@ static int vpd_probe(struct platform_dev return vpd_sections_init(entry.cbmem_addr); } +static int vpd_remove(struct platform_device *pdev) +{ + vpd_section_destroy(&ro_vpd); + vpd_section_destroy(&rw_vpd); + + return 0; +} + static struct platform_driver vpd_driver = { .probe = vpd_probe, + .remove = vpd_remove, .driver = { .name = "vpd", }, @@ -324,8 +333,6 @@ static int __init vpd_platform_init(void static void __exit vpd_platform_exit(void) { - vpd_section_destroy(&ro_vpd); - vpd_section_destroy(&rw_vpd); kobject_put(vpd_kobj); } Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "firmware: cleanup FIRMWARE_IN_KERNEL message" 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 firmware: cleanup FIRMWARE_IN_KERNEL message 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: firmware-cleanup-firmware_in_kernel-message.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 0946b2fb38fdb6585a5ac3ca84ac73924f645952 Mon Sep 17 00:00:00 2001 From: "Robin H. Johnson" <robbat2(a)gentoo.org> Date: Thu, 16 Nov 2017 14:36:12 -0800 Subject: firmware: cleanup FIRMWARE_IN_KERNEL message From: Robin H. Johnson <robbat2(a)gentoo.org> commit 0946b2fb38fdb6585a5ac3ca84ac73924f645952 upstream. The help for FIRMWARE_IN_KERNEL still references the firmware_install command that was recently removed by commit 5620a0d1aacd ("firmware: delete in-kernel firmware"). Clean up the message to direct the user to their distribution's linux-firmware package, and remove any reference to firmware being included in the kernel source tree. Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware"). Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Signed-off-by: Robin H. Johnson <robbat2(a)gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/Kconfig | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -91,22 +91,23 @@ config FIRMWARE_IN_KERNEL depends on FW_LOADER default y help - The kernel source tree includes a number of firmware 'blobs' - that are used by various drivers. The recommended way to - use these is to run "make firmware_install", which, after - converting ihex files to binary, copies all of the needed - binary files in firmware/ to /lib/firmware/ on your system so - that they can be loaded by userspace helpers on request. + Various drivers in the kernel source tree may require firmware, + which is generally available in your distribution's linux-firmware + package. + + The linux-firmware package should install firmware into + /lib/firmware/ on your system, so they can be loaded by userspace + helpers on request. Enabling this option will build each required firmware blob - into the kernel directly, where request_firmware() will find - them without having to call out to userspace. This may be - useful if your root file system requires a device that uses - such firmware and do not wish to use an initrd. + specified by EXTRA_FIRMWARE into the kernel directly, where + request_firmware() will find them without having to call out to + userspace. This may be useful if your root file system requires a + device that uses such firmware and you do not wish to use an + initrd. This single option controls the inclusion of firmware for - every driver that uses request_firmware() and ships its - firmware in the kernel source tree, which avoids a + every driver that uses request_firmware(), which avoids a proliferation of 'Include firmware for xxx device' options. Say 'N' and let firmware be loaded from userspace. Patches currently in stable-queue which might be from robbat2(a)gentoo.org are queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "efi: Move some sysfs files to be read-only by root" 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 efi: Move some sysfs files to be read-only by root 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: efi-move-some-sysfs-files-to-be-read-only-by-root.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 af97a77bc01ce49a466f9d4c0125479e2e2230b6 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Wed, 6 Dec 2017 09:50:08 +0000 Subject: efi: Move some sysfs files to be read-only by root From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> commit af97a77bc01ce49a466f9d4c0125479e2e2230b6 upstream. Thanks to the scripts/leaking_addresses.pl script, it was found that some EFI values should not be readable by non-root users. So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to make this easier, and use it in other places at the same time. Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org> Tested-by: Dave Young <dyoung(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Matt Fleming <matt(a)codeblueprint.co.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-efi(a)vger.kernel.org Link: http://lkml.kernel.org/r/20171206095010.24170-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/efi/efi.c | 3 +-- drivers/firmware/efi/esrt.c | 15 ++++++--------- drivers/firmware/efi/runtime-map.c | 10 +++++----- include/linux/sysfs.h | 6 ++++++ 4 files changed, 18 insertions(+), 16 deletions(-) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobjec return str - buf; } -static struct kobj_attribute efi_attr_systab = - __ATTR(systab, 0400, systab_show, NULL); +static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400); #define EFI_FIELD(var) efi.var --- a/drivers/firmware/efi/esrt.c +++ b/drivers/firmware/efi/esrt.c @@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_ }; /* Generic ESRT Entry ("ESRE") support. */ -static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf) +static ssize_t fw_class_show(struct esre_entry *entry, char *buf) { char *str = buf; @@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct return str - buf; } -static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400, - esre_fw_class_show, NULL); +static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400); #define esre_attr_decl(name, size, fmt) \ -static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \ +static ssize_t name##_show(struct esre_entry *entry, char *buf) \ { \ return sprintf(buf, fmt "\n", \ le##size##_to_cpu(entry->esre.esre1->name)); \ } \ \ -static struct esre_attribute esre_##name = __ATTR(name, 0400, \ - esre_##name##_show, NULL) +static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400) esre_attr_decl(fw_type, 32, "%u"); esre_attr_decl(fw_version, 32, "%u"); @@ -193,14 +191,13 @@ static int esre_create_sysfs_entry(void /* support for displaying ESRT fields at the top level */ #define esrt_attr_decl(name, size, fmt) \ -static ssize_t esrt_##name##_show(struct kobject *kobj, \ +static ssize_t name##_show(struct kobject *kobj, \ struct kobj_attribute *attr, char *buf)\ { \ return sprintf(buf, fmt "\n", le##size##_to_cpu(esrt->name)); \ } \ \ -static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \ - esrt_##name##_show, NULL) +static struct kobj_attribute esrt_##name = __ATTR_RO_MODE(name, 0400) esrt_attr_decl(fw_resource_count, 32, "%u"); esrt_attr_decl(fw_resource_count_max, 32, "%u"); --- a/drivers/firmware/efi/runtime-map.c +++ b/drivers/firmware/efi/runtime-map.c @@ -63,11 +63,11 @@ static ssize_t map_attr_show(struct kobj return map_attr->show(entry, buf); } -static struct map_attribute map_type_attr = __ATTR_RO(type); -static struct map_attribute map_phys_addr_attr = __ATTR_RO(phys_addr); -static struct map_attribute map_virt_addr_attr = __ATTR_RO(virt_addr); -static struct map_attribute map_num_pages_attr = __ATTR_RO(num_pages); -static struct map_attribute map_attribute_attr = __ATTR_RO(attribute); +static struct map_attribute map_type_attr = __ATTR_RO_MODE(type, 0400); +static struct map_attribute map_phys_addr_attr = __ATTR_RO_MODE(phys_addr, 0400); +static struct map_attribute map_virt_addr_attr = __ATTR_RO_MODE(virt_addr, 0400); +static struct map_attribute map_num_pages_attr = __ATTR_RO_MODE(num_pages, 0400); +static struct map_attribute map_attribute_attr = __ATTR_RO_MODE(attribute, 0400); /* * These are default attributes that are added for every memmap entry. --- a/include/linux/sysfs.h +++ b/include/linux/sysfs.h @@ -117,6 +117,12 @@ struct attribute_group { .show = _name##_show, \ } +#define __ATTR_RO_MODE(_name, _mode) { \ + .attr = { .name = __stringify(_name), \ + .mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \ + .show = _name##_show, \ +} + #define __ATTR_WO(_name) { \ .attr = { .name = __stringify(_name), .mode = S_IWUSR }, \ .store = _name##_store, \ Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.14/smp-hotplug-move-step-cpuhp_ap_smpcfd_dying-to-the-correct-place.patch queue-4.14/powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch queue-4.14/bus-arm-ccn-check-memory-allocation-failure.patch queue-4.14/iio-health-max30102-temperature-should-be-in-milli-celsius.patch queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch queue-4.14/s390-always-save-and-restore-all-registers-on-context-switch.patch queue-4.14/efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch queue-4.14/alsa-seq-remove-spurious-warn_on-at-timer-check.patch queue-4.14/ib-core-avoid-unnecessary-return-value-check.patch queue-4.14/media-rc-partial-revert-of-media-rc-per-protocol-repeat-period.patch queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.14/can-peak-pcie_fd-fix-potential-bug-in-restarting-tx-queue.patch queue-4.14/s390-fix-compat-system-call-table.patch queue-4.14/ib-core-only-enforce-security-for-infiniband.patch queue-4.14/can-flexcan-fix-vf610-state-transition-issue.patch queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch queue-4.14/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch queue-4.14/can-ti_hecc-fix-napi-poll-return-value-for-repoll.patch queue-4.14/iommu-vt-d-fix-scatterlist-offset-handling.patch queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch queue-4.14/revert-powerpc-do-not-call-ppc_md.panic-in-fadump-panic-notifier.patch queue-4.14/iwlwifi-mvm-enable-rx-offloading-with-tkip-and-wep.patch queue-4.14/iio-stm32-fix-adc-trigger-link-error.patch queue-4.14/alsa-pcm-prevent-uaf-in-snd_pcm_info.patch queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch queue-4.14/isa-prevent-null-dereference-in-isa_bus-driver-callbacks.patch queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch queue-4.14/alsa-usb-audio-add-check-return-value-for-usb_string.patch queue-4.14/scsi-dma-mapping-always-provide-dma_get_cache_alignment.patch queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch queue-4.14/kdb-fix-handling-of-kallsyms_symbol_next-return-value.patch queue-4.14/kvm-arm-arm64-fix-broken-gich_elrsr-big-endian-conversion.patch queue-4.14/iwlwifi-mvm-flush-queue-before-deleting-roc.patch queue-4.14/bus-arm-ccn-fix-module-unloading-error-removing-state-147-which-has-instances-left.patch queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch queue-4.14/serdev-ttyport-fix-null-deref-on-hangup.patch queue-4.14/iio-adc-cpcap-fix-incorrect-validation.patch queue-4.14/brcmfmac-change-driver-unbind-order-of-the-sdio-function-devices.patch queue-4.14/btrfs-fix-missing-error-return-in-btrfs_drop_snapshot.patch queue-4.14/md-r5cache-move-mddev_lock-out-of-r5c_journal_mode_set.patch queue-4.14/can-peak-pci-fix-potential-bug-when-probe-fails.patch queue-4.14/drm-safely-free-connectors-from-connector_iter.patch queue-4.14/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch queue-4.14/usb-gadget-udc-renesas_usb3-fix-number-of-the-pipes.patch queue-4.14/s390-mm-fix-off-by-one-bug-in-5-level-page-table-handling.patch queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch queue-4.14/kvm-vmx-remove-i-o-port-0x80-bypass-on-intel-hosts.patch queue-4.14/arm64-sw-pan-update-saved-ttbr0-value-on-enter_lazy_tlb.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/efi-move-some-sysfs-files-to-be-read-only-by-root.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch queue-4.14/drivers-hv-vmbus-fix-a-rescind-issue.patch queue-4.14/media-rc-sir_ir-detect-presence-of-port.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/virtio-release-virtio-index-when-fail-to-device_register.patch queue-4.14/pinctrl-armada-37xx-fix-direction_output-callback-behavior.patch queue-4.14/revert-arm-dts-imx53-add-srtc-node.patch queue-4.14/kvm-x86-fix-apic-page-invalidation.patch queue-4.14/can-kvaser_usb-free-buf-in-error-paths.patch queue-4.14/media-dvb-i2c-transfers-over-usb-cannot-be-done-from-stack.patch queue-4.14/iio-adc-meson-saradc-initialize-the-bandgap-correctly-on-older-socs.patch queue-4.14/iwlwifi-mvm-fix-packet-injection.patch queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch queue-4.14/iio-adc-meson-saradc-fix-the-bit_idx-of-the-adc_en-clock.patch queue-4.14/iwlwifi-add-new-cards-for-9260-and-22000-series.patch queue-4.14/usb-gadget-core-fix-udc_set_speed-speed-handling.patch queue-4.14/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/iwlwifi-mvm-don-t-use-transmit-queue-hang-detection-when-it-is-not-possible.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/iwlwifi-mvm-mark-mic-stripped-mpdus.patch queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch queue-4.14/serdev-ttyport-fix-tty-locking-in-close.patch queue-4.14/usb-f_fs-force-reserved1-1-in-os_desc_ext_compat.patch queue-4.14/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch queue-4.14/iio-adc-meson-saradc-meson8-and-meson8b-do-not-have-reg11-and-reg13.patch queue-4.14/btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch queue-4.14/arm64-sw-pan-point-saved-ttbr0-at-the-zero-page-when-switching-to-init_mm.patch queue-4.14/alsa-hda-realtek-new-codec-support-for-alc257.patch queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch queue-4.14/arm64-fpsimd-prevent-registers-leaking-from-dead-tasks.patch queue-4.14/alsa-usb-audio-fix-out-of-bound-error.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/x86-pci-make-broadcom_postcore_init-check-acpi_disabled.patch queue-4.14/serdev-ttyport-add-missing-receive_buf-sanity-checks.patch queue-4.14/x86-idt-load-idt-early-in-start_secondary.patch queue-4.14/kvm-s390-fix-skey-emulation-permission-check.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "efi/esrt: Use memunmap() instead of kfree() to free the remapping" 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 efi/esrt: Use memunmap() instead of kfree() to free the remapping 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: efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.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 89c5a2d34bda58319e3075e8e7dd727ea25a435c Mon Sep 17 00:00:00 2001 From: Pan Bian <bianpan2016(a)163.com> Date: Wed, 6 Dec 2017 09:50:09 +0000 Subject: efi/esrt: Use memunmap() instead of kfree() to free the remapping From: Pan Bian <bianpan2016(a)163.com> commit 89c5a2d34bda58319e3075e8e7dd727ea25a435c upstream. The remapping result of memremap() should be freed with memunmap(), not kfree(). Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matt Fleming <matt(a)codeblueprint.co.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-efi(a)vger.kernel.org Link: http://lkml.kernel.org/r/20171206095010.24170-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/efi/esrt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/firmware/efi/esrt.c +++ b/drivers/firmware/efi/esrt.c @@ -428,7 +428,7 @@ err_remove_group: err_remove_esrt: kobject_put(esrt_kobj); err: - kfree(esrt); + memunmap(esrt); esrt = NULL; return error; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.14/efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch queue-4.14/iio-adc-cpcap-fix-incorrect-validation.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "drm: safely free connectors from connector_iter" 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 drm: safely free connectors from connector_iter 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: drm-safely-free-connectors-from-connector_iter.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 a703c55004e1c5076d57e43771b3e11117796ea0 Mon Sep 17 00:00:00 2001 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Mon, 4 Dec 2017 21:48:18 +0100 Subject: drm: safely free connectors from connector_iter From: Daniel Vetter <daniel.vetter(a)ffwll.ch> commit a703c55004e1c5076d57e43771b3e11117796ea0 upstream. In commit 613051dac40da1751ab269572766d3348d45a197 Author: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Wed Dec 14 00:08:06 2016 +0100 drm: locking&new iterators for connector_list we've went to extreme lengths to make sure connector iterations works in any context, without introducing any additional locking context. This worked, except for a small fumble in the implementation: When we actually race with a concurrent connector unplug event, and our temporary connector reference turns out to be the final one, then everything breaks: We call the connector release function from whatever context we happen to be in, which can be an irq/atomic context. And connector freeing grabs all kinds of locks and stuff. Fix this by creating a specially safe put function for connetor_iter, which (in this rare case) punts the cleanup to a worker. Reported-by: Ben Widawsky <ben(a)bwidawsk.net> Cc: Ben Widawsky <ben(a)bwidawsk.net> Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Dave Airlie <airlied(a)gmail.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sean Paul <seanpaul(a)chromium.org> Reviewed-by: Dave Airlie <airlied(a)gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_connector.c | 28 ++++++++++++++++++++++++++-- drivers/gpu/drm/drm_mode_config.c | 2 ++ include/drm/drm_connector.h | 8 ++++++++ 3 files changed, 36 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -152,6 +152,16 @@ static void drm_connector_free(struct kr connector->funcs->destroy(connector); } +static void drm_connector_free_work_fn(struct work_struct *work) +{ + struct drm_connector *connector = + container_of(work, struct drm_connector, free_work); + struct drm_device *dev = connector->dev; + + drm_mode_object_unregister(dev, &connector->base); + connector->funcs->destroy(connector); +} + /** * drm_connector_init - Init a preallocated connector * @dev: DRM device @@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device if (ret) return ret; + INIT_WORK(&connector->free_work, drm_connector_free_work_fn); + connector->base.properties = &connector->properties; connector->dev = dev; connector->funcs = funcs; @@ -525,6 +537,18 @@ void drm_connector_list_iter_begin(struc } EXPORT_SYMBOL(drm_connector_list_iter_begin); +/* + * Extra-safe connector put function that works in any context. Should only be + * used from the connector_iter functions, where we never really expect to + * actually release the connector when dropping our final reference. + */ +static void +drm_connector_put_safe(struct drm_connector *conn) +{ + if (refcount_dec_and_test(&conn->base.refcount.refcount)) + schedule_work(&conn->free_work); +} + /** * drm_connector_list_iter_next - return next connector * @iter: connectr_list iterator @@ -557,7 +581,7 @@ drm_connector_list_iter_next(struct drm_ spin_unlock_irqrestore(&config->connector_list_lock, flags); if (old_conn) - drm_connector_put(old_conn); + drm_connector_put_safe(old_conn); return iter->conn; } @@ -576,7 +600,7 @@ void drm_connector_list_iter_end(struct { iter->dev = NULL; if (iter->conn) - drm_connector_put(iter->conn); + drm_connector_put_safe(iter->conn); lock_release(&connector_list_iter_dep_map, 0, _RET_IP_); } EXPORT_SYMBOL(drm_connector_list_iter_end); --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -428,6 +428,8 @@ void drm_mode_config_cleanup(struct drm_ drm_connector_put(connector); } drm_connector_list_iter_end(&conn_iter); + /* connector_iter drops references in a work item. */ + flush_scheduled_work(); if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) { drm_connector_list_iter_begin(dev, &conn_iter); drm_for_each_connector_iter(connector, &conn_iter) --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -905,6 +905,14 @@ struct drm_connector { uint8_t num_h_tile, num_v_tile; uint8_t tile_h_loc, tile_v_loc; uint16_t tile_h_size, tile_v_size; + + /** + * @free_work: + * + * Work used only by &drm_connector_iter to be able to clean up a + * connector from any context. + */ + struct work_struct free_work; }; #define obj_to_connector(x) container_of(x, struct drm_connector, base) Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-4.14/drm-safely-free-connectors-from-connector_iter.patch queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Fix vblank timestamp/frame counter jumps on gen2" 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 drm/i915: Fix vblank timestamp/frame counter jumps on gen2 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: drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.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 a87e55f89f0b0dc541d89248a8445635936a3858 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Wed, 29 Nov 2017 17:37:30 +0200 Subject: drm/i915: Fix vblank timestamp/frame counter jumps on gen2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit a87e55f89f0b0dc541d89248a8445635936a3858 upstream. Previously I was under the impression that the scanline counter reads 0 when the pipe is off. Turns out that's not correct, and instead the scanline counter simply stops when the pipe stops, and it retains it's last value until the pipe starts up again, at which point the scanline counter jumps to vblank start. These jumps can cause the timestamp to jump backwards by one frame. Since we use the timestamps to guesstimage also the frame counter value on gen2, that would cause the frame counter to also jump backwards, which leads to a massice difference from the previous value. The end result is that flips/vblank events don't appear to complete as they're stuck waiting for the frame counter to catch up to that massive difference. Fix the problem properly by actually making sure the scanline counter has started to move before we assume that it's safe to enable vblank processing. v2: Less pointless duplication in the code (Chris) Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.s… (cherry picked from commit 8fedd64dabc86d0f31a0d1e152be3aa23c323553) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_display.c | 53 +++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 17 deletions(-) --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1000,7 +1000,8 @@ enum transcoder intel_pipe_to_cpu_transc return crtc->config->cpu_transcoder; } -static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) +static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv, + enum pipe pipe) { i915_reg_t reg = PIPEDSL(pipe); u32 line1, line2; @@ -1015,7 +1016,28 @@ static bool pipe_dsl_stopped(struct drm_ msleep(5); line2 = I915_READ(reg) & line_mask; - return line1 == line2; + return line1 != line2; +} + +static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + + /* Wait for the display line to settle/start moving */ + if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100)) + DRM_ERROR("pipe %c scanline %s wait timed out\n", + pipe_name(pipe), onoff(state)); +} + +static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc) +{ + wait_for_pipe_scanline_moving(crtc, false); +} + +static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) +{ + wait_for_pipe_scanline_moving(crtc, true); } /* @@ -1038,7 +1060,6 @@ static void intel_wait_for_pipe_off(stru { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; - enum pipe pipe = crtc->pipe; if (INTEL_GEN(dev_priv) >= 4) { i915_reg_t reg = PIPECONF(cpu_transcoder); @@ -1049,9 +1070,7 @@ static void intel_wait_for_pipe_off(stru 100)) WARN(1, "pipe_off wait timed out\n"); } else { - /* Wait for the display line to settle */ - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) - WARN(1, "pipe_off wait timed out\n"); + intel_wait_for_pipe_scanline_stopped(crtc); } } @@ -1944,15 +1963,14 @@ static void intel_enable_pipe(struct int POSTING_READ(reg); /* - * Until the pipe starts DSL will read as 0, which would cause - * an apparent vblank timestamp jump, which messes up also the - * frame count when it's derived from the timestamps. So let's - * wait for the pipe to start properly before we call - * drm_crtc_vblank_on() - */ - if (dev->max_vblank_count == 0 && - wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50)) - DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe)); + * Until the pipe starts PIPEDSL reads will return a stale value, + * which causes an apparent vblank timestamp jump when PIPEDSL + * resets to its proper value. That also messes up the frame count + * when it's derived from the timestamps. So let's wait for the + * pipe to start properly before we call drm_crtc_vblank_on() + */ + if (dev->max_vblank_count == 0) + intel_wait_for_pipe_scanline_moving(crtc); } /** @@ -14682,6 +14700,8 @@ void i830_enable_pipe(struct drm_i915_pr void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe) { + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe); + DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n", pipe_name(pipe)); @@ -14691,8 +14711,7 @@ void i830_disable_pipe(struct drm_i915_p I915_WRITE(PIPECONF(pipe), 0); POSTING_READ(PIPECONF(pipe)); - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) - DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe)); + intel_wait_for_pipe_scanline_stopped(crtc); I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS); POSTING_READ(DPLL(pipe)); Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU" 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 drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU 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: drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.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 120a264f9c2782682027d931d83dcbd22e01da80 Mon Sep 17 00:00:00 2001 From: Marek Szyprowski <m.szyprowski(a)samsung.com> Date: Wed, 22 Nov 2017 14:14:47 +0100 Subject: drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU From: Marek Szyprowski <m.szyprowski(a)samsung.com> commit 120a264f9c2782682027d931d83dcbd22e01da80 upstream. When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver are contiguous, because of the underlying dma_alloc_attrs() function provides only such buffers. In such case it makes no sense to keep BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid failures for buffer contiguity checks in the subsequent operations on GEM objects. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_cr if (IS_ERR(exynos_gem)) return exynos_gem; + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) { + /* + * when no IOMMU is available, all allocated buffers are + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag + */ + flags &= ~EXYNOS_BO_NONCONTIG; + DRM_WARN("Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer\n"); + } + /* set memory type and cache attribute from user side. */ exynos_gem->flags = flags; Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback" 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 drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback 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: drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.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 510353a63796d467b41237ab4f136136f68c297d Mon Sep 17 00:00:00 2001 From: Marek Szyprowski <m.szyprowski(a)samsung.com> Date: Tue, 21 Nov 2017 08:49:36 +0100 Subject: drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback From: Marek Szyprowski <m.szyprowski(a)samsung.com> commit 510353a63796d467b41237ab4f136136f68c297d upstream. get_modes() callback might be called asynchronously from the DRM core and it is not synchronized with bridge_enable(), which sets proper runtime PM state of the main DP device. Fix this by calling pm_runtime_get_sync() before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and analogix_dp_transfer() to ensure that main DP device is runtime active when doing any access to its registers. This fixes the following kernel issue on Samsung Exynos5250 Snow board: Unhandled fault: imprecise external abort (0x406) at 0x00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: : 406 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da420b #3357 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) Workqueue: events output_poll_execute task: edc14800 task.stack: edcb2000 PC is at analogix_dp_transfer+0x15c/0x2fc LR is at analogix_dp_transfer+0x134/0x2fc pc : [<c0468538>] lr : [<c0468510>] psr: 60000013 sp : edcb3be8 ip : 0000002a fp : 00000001 r10: 00000000 r9 : edcb3cd8 r8 : edcb3c40 r7 : 00000000 r6 : edd3b380 r5 : edd3b010 r4 : 00000064 r3 : 00000000 r2 : f0ad3000 r1 : edcb3c40 r0 : edd3b010 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4000406a DAC: 00000051 Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210) Stack: (0xedcb3be8 to 0xedcb4000) [<c0468538>] (analogix_dp_transfer) from [<c0424ba4>] (drm_dp_i2c_do_msg+0x8c/0x2b4) [<c0424ba4>] (drm_dp_i2c_do_msg) from [<c0424e64>] (drm_dp_i2c_xfer+0x98/0x214) [<c0424e64>] (drm_dp_i2c_xfer) from [<c057b2d8>] (__i2c_transfer+0x140/0x29c) [<c057b2d8>] (__i2c_transfer) from [<c057b4a4>] (i2c_transfer+0x70/0xe4) [<c057b4a4>] (i2c_transfer) from [<c0441de4>] (drm_do_probe_ddc_edid+0xb4/0x114) [<c0441de4>] (drm_do_probe_ddc_edid) from [<c0441e5c>] (drm_probe_ddc+0x18/0x28) [<c0441e5c>] (drm_probe_ddc) from [<c0445728>] (drm_get_edid+0x124/0x2d4) [<c0445728>] (drm_get_edid) from [<c0465ea0>] (analogix_dp_get_modes+0x90/0x114) [<c0465ea0>] (analogix_dp_get_modes) from [<c0425e8c>] (drm_helper_probe_single_connector_modes+0x198/0x68c) [<c0425e8c>] (drm_helper_probe_single_connector_modes) from [<c04325d4>] (drm_setup_crtcs+0x1b4/0xd18) [<c04325d4>] (drm_setup_crtcs) from [<c04344a8>] (drm_fb_helper_hotplug_event+0x94/0xd0) [<c04344a8>] (drm_fb_helper_hotplug_event) from [<c0425a50>] (drm_kms_helper_hotplug_event+0x24/0x28) [<c0425a50>] (drm_kms_helper_hotplug_event) from [<c04263ec>] (output_poll_execute+0x6c/0x174) [<c04263ec>] (output_poll_execute) from [<c0136f18>] (process_one_work+0x188/0x3fc) [<c0136f18>] (process_one_work) from [<c01371f4>] (worker_thread+0x30/0x4b8) [<c01371f4>] (worker_thread) from [<c013daf8>] (kthread+0x128/0x164) [<c013daf8>] (kthread) from [<c0108510>] (ret_from_fork+0x14/0x24) Code: 0a000002 ea000009 e2544001 0a00004a (e59537c8) ---[ end trace cddc7919c79f7878 ]--- Reported-by: Misha Komarovskiy <zombah(a)gmail.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171121074936.22520-1-m.szyp… --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -946,7 +946,9 @@ static int analogix_dp_get_modes(struct return 0; } + pm_runtime_get_sync(dp->dev); edid = drm_get_edid(connector, &dp->aux.ddc); + pm_runtime_put(dp->dev); if (edid) { drm_mode_connector_update_edid_property(&dp->connector, edid); Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "Drivers: hv: vmbus: Fix a rescind issue" 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 Drivers: hv: vmbus: Fix a rescind issue 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: drivers-hv-vmbus-fix-a-rescind-issue.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 7fa32e5ec28b1609abc0b797b58267f725fc3964 Mon Sep 17 00:00:00 2001 From: "K. Y. Srinivasan" <kys(a)microsoft.com> Date: Tue, 14 Nov 2017 06:53:33 -0700 Subject: Drivers: hv: vmbus: Fix a rescind issue From: K. Y. Srinivasan <kys(a)microsoft.com> commit 7fa32e5ec28b1609abc0b797b58267f725fc3964 upstream. The current rescind processing code will not correctly handle the case where the host immediately rescinds a channel that has been offerred. In this case, we could be blocked in the open call and since the channel is rescinded, the host will not respond and we could be blocked forever in the vmbus open call.i Fix this problem. Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hv/channel.c | 10 ++++++++-- drivers/hv/channel_mgmt.c | 7 ++++--- include/linux/hyperv.h | 1 + 3 files changed, 13 insertions(+), 5 deletions(-) --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -640,22 +640,28 @@ void vmbus_close(struct vmbus_channel *c */ return; } - mutex_lock(&vmbus_connection.channel_mutex); /* * Close all the sub-channels first and then close the * primary channel. */ list_for_each_safe(cur, tmp, &channel->sc_list) { cur_channel = list_entry(cur, struct vmbus_channel, sc_list); - vmbus_close_internal(cur_channel); if (cur_channel->rescind) { + wait_for_completion(&cur_channel->rescind_event); + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); hv_process_channel_removal( cur_channel->offermsg.child_relid); + } else { + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); } + mutex_unlock(&vmbus_connection.channel_mutex); } /* * Now close the primary. */ + mutex_lock(&vmbus_connection.channel_mutex); vmbus_close_internal(channel); mutex_unlock(&vmbus_connection.channel_mutex); } --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -333,6 +333,7 @@ static struct vmbus_channel *alloc_chann return NULL; spin_lock_init(&channel->lock); + init_completion(&channel->rescind_event); INIT_LIST_HEAD(&channel->sc_list); INIT_LIST_HEAD(&channel->percpu_list); @@ -883,6 +884,7 @@ static void vmbus_onoffer_rescind(struct /* * Now wait for offer handling to complete. */ + vmbus_rescind_cleanup(channel); while (READ_ONCE(channel->probe_done) == false) { /* * We wait here until any channel offer is currently @@ -898,7 +900,6 @@ static void vmbus_onoffer_rescind(struct if (channel->device_obj) { if (channel->chn_rescind_callback) { channel->chn_rescind_callback(channel); - vmbus_rescind_cleanup(channel); return; } /* @@ -907,7 +908,6 @@ static void vmbus_onoffer_rescind(struct */ dev = get_device(&channel->device_obj->device); if (dev) { - vmbus_rescind_cleanup(channel); vmbus_device_unregister(channel->device_obj); put_device(dev); } @@ -921,13 +921,14 @@ static void vmbus_onoffer_rescind(struct * 2. Then close the primary channel. */ mutex_lock(&vmbus_connection.channel_mutex); - vmbus_rescind_cleanup(channel); if (channel->state == CHANNEL_OPEN_STATE) { /* * The channel is currently not open; * it is safe for us to cleanup the channel. */ hv_process_channel_removal(rescind->child_relid); + } else { + complete(&channel->rescind_event); } mutex_unlock(&vmbus_connection.channel_mutex); } --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -708,6 +708,7 @@ struct vmbus_channel { u8 monitor_bit; bool rescind; /* got rescind msg */ + struct completion rescind_event; u32 ringbuffer_gpadlhandle; Patches currently in stable-queue which might be from kys(a)microsoft.com are queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch queue-4.14/drivers-hv-vmbus-fix-a-rescind-issue.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: Fix use of smp_processor_id() in preemptible 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 bus: arm-ccn: Fix use of smp_processor_id() in preemptible 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: bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-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 b18c2b9487d8e797fc0a757e57ac3645348c5fba Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 3 Oct 2017 18:14:12 +0100 Subject: bus: arm-ccn: Fix use of smp_processor_id() in preemptible context From: Marc Zyngier <marc.zyngier(a)arm.com> commit b18c2b9487d8e797fc0a757e57ac3645348c5fba upstream. Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system results in the following splat: [...] arm-ccn e8000000.ccn: No access to interrupts, using timer. BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id+0x1c/0x28 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111 Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017 Call trace: [<ffff000008089e78>] dump_backtrace+0x0/0x278 [<ffff00000808a22c>] show_stack+0x24/0x30 [<ffff000008bc3bc4>] dump_stack+0x8c/0xb0 [<ffff00000852b534>] check_preemption_disabled+0xfc/0x100 [<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28 [<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0 [...] as we use smp_processor_id() in the wrong context. Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug registration, making sure that we don't race against a CPU down operation. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1301,7 +1301,7 @@ static int arm_ccn_pmu_init(struct arm_c } /* Pick one CPU which we will use to collect data from CCN... */ - cpumask_set_cpu(smp_processor_id(), &ccn->dt.cpu); + cpumask_set_cpu(get_cpu(), &ccn->dt.cpu); /* Also make sure that the overflow interrupt is handled by this CPU */ if (ccn->irq) { @@ -1318,10 +1318,12 @@ static int arm_ccn_pmu_init(struct arm_c cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCN_ONLINE, &ccn->dt.node); + put_cpu(); return 0; error_pmu_register: error_set_affinity: + put_cpu(); error_choose_name: ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id); for (i = 0; i < ccn->num_xps; i++) Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left." 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 bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. 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: bus-arm-ccn-fix-module-unloading-error-removing-state-147-which-has-instances-left.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 b69f63ebf553504739cc8534cbed31bd530c6f0b Mon Sep 17 00:00:00 2001 From: Kim Phillips <kim.phillips(a)arm.com> Date: Wed, 11 Oct 2017 22:33:24 +0100 Subject: bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. From: Kim Phillips <kim.phillips(a)arm.com> commit b69f63ebf553504739cc8534cbed31bd530c6f0b upstream. Unregistering the driver before calling cpuhp_remove_multi_state() removes any remaining hotplug cpu instances so __cpuhp_remove_state_cpuslocked() doesn't emit this warning: [ 268.748362] Error: Removing state 147 which has instances left. [ 268.748373] ------------[ cut here ]------------ [ 268.748386] WARNING: CPU: 2 PID: 5476 at kernel/cpu.c:1734 __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748389] Modules linked in: arm_ccn(-) [last unloaded: arm_ccn] [ 268.748403] CPU: 2 PID: 5476 Comm: rmmod Tainted: G W 4.14.0-rc4+ #3 [ 268.748406] Hardware name: AMD Seattle/Seattle, BIOS 10:18:39 Dec 8 2016 [ 268.748410] task: ffff8001a18ca000 task.stack: ffff80019c120000 [ 268.748416] PC is at __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748421] LR is at __cpuhp_remove_state_cpuslocked+0x448/0x4f0 [ 268.748425] pc : [<ffff2000081729ec>] lr : [<ffff2000081729e0>] pstate: 60000145 [ 268.748427] sp : ffff80019c127d30 [ 268.748430] x29: ffff80019c127d30 x28: ffff8001a18ca000 [ 268.748437] x27: ffff20000c2cb000 x26: 1fffe4000042d490 [ 268.748443] x25: ffff20000216a480 x24: 0000000000000000 [ 268.748449] x23: ffff20000b08e000 x22: 0000000000000001 [ 268.748455] x21: 0000000000000093 x20: 00000000000016f8 [ 268.748460] x19: ffff20000c2cbb80 x18: 0000ffffb5fe7c58 [ 268.748466] x17: 00000000004402d0 x16: 1fffe40001864f01 [ 268.748472] x15: ffff20000c4bf8b0 x14: 0000000000000000 [ 268.748477] x13: 0000000000007032 x12: ffff20000829ae48 [ 268.748483] x11: ffff20000c4bf000 x10: 0000000000000004 [ 268.748488] x9 : 0000000000006fbc x8 : ffff20000c318a40 [ 268.748494] x7 : 0000000000000000 x6 : ffff040001864f02 [ 268.748500] x5 : 0000000000000000 x4 : 0000000000000000 [ 268.748505] x3 : 0000000000000007 x2 : dfff200000000000 [ 268.748510] x1 : 000000000000ad3d x0 : 00000000000001f0 [ 268.748516] Call trace: [ 268.748521] Exception stack(0xffff80019c127bf0 to 0xffff80019c127d30) [ 268.748526] 7be0: 00000000000001f0 000000000000ad3d [ 268.748531] 7c00: dfff200000000000 0000000000000007 0000000000000000 0000000000000000 [ 268.748535] 7c20: ffff040001864f02 0000000000000000 ffff20000c318a40 0000000000006fbc [ 268.748539] 7c40: 0000000000000004 ffff20000c4bf000 ffff20000829ae48 0000000000007032 [ 268.748544] 7c60: 0000000000000000 ffff20000c4bf8b0 1fffe40001864f01 00000000004402d0 [ 268.748548] 7c80: 0000ffffb5fe7c58 ffff20000c2cbb80 00000000000016f8 0000000000000093 [ 268.748553] 7ca0: 0000000000000001 ffff20000b08e000 0000000000000000 ffff20000216a480 [ 268.748557] 7cc0: 1fffe4000042d490 ffff20000c2cb000 ffff8001a18ca000 ffff80019c127d30 [ 268.748562] 7ce0: ffff2000081729e0 ffff80019c127d30 ffff2000081729ec 0000000060000145 [ 268.748566] 7d00: 00000000000001f0 0000000000000000 0001000000000000 0000000000000000 [ 268.748569] 7d20: ffff80019c127d30 ffff2000081729ec [ 268.748575] [<ffff2000081729ec>] __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748580] [<ffff200008172adc>] __cpuhp_remove_state+0x54/0x80 [ 268.748597] [<ffff20000215dd84>] arm_ccn_exit+0x2c/0x70 [arm_ccn] [ 268.748604] [<ffff20000834cfbc>] SyS_delete_module+0x5a4/0x708 [ 268.748607] Exception stack(0xffff80019c127ec0 to 0xffff80019c128000) [ 268.748612] 7ec0: 0000000019bb7258 0000000000000800 ba64d0fb3d26a800 00000000000000da [ 268.748616] 7ee0: 0000ffffb6144e28 0000ffffcd95b409 fefefefefefefeff 7f7f7f7f7f7f7f7f [ 268.748621] 7f00: 000000000000006a 1999999999999999 0000ffffb6179000 0000000000bbcc6d [ 268.748625] 7f20: 0000ffffb6176b98 0000ffffcd95c2d0 0000ffffb5fe7b58 0000ffffb6163000 [ 268.748630] 7f40: 0000ffffb60ad3e0 00000000004402d0 0000ffffb5fe7c58 0000000019bb71f0 [ 268.748634] 7f60: 0000ffffcd95c740 0000000000000000 0000000019bb71f0 0000000000416700 [ 268.748639] 7f80: 0000000000000000 00000000004402e8 0000000019bb6010 0000ffffcd95c748 [ 268.748643] 7fa0: 0000000000000000 0000ffffcd95c460 00000000004113a8 0000ffffcd95c460 [ 268.748648] 7fc0: 0000ffffb60ad3e8 0000000080000000 0000000019bb7258 000000000000006a [ 268.748652] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 268.748657] [<ffff200008084f9c>] __sys_trace_return+0x0/0x4 [ 268.748661] ---[ end trace a996d358dcaa7f9c ]--- Fixes: 8df038725ad5 ("bus/arm-ccn: Use cpu-hp's multi instance support instead custom list") Signed-off-by: Kim Phillips <kim.phillips(a)arm.com> Acked-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1587,8 +1587,8 @@ static int __init arm_ccn_init(void) static void __exit arm_ccn_exit(void) { - cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_CCN_ONLINE); platform_driver_unregister(&arm_ccn_driver); + cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_CCN_ONLINE); } module_init(arm_ccn_init); Patches currently in stable-queue which might be from kim.phillips(a)arm.com are queue-4.14/bus-arm-ccn-fix-module-unloading-error-removing-state-147-which-has-instances-left.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: Check memory allocation failure" 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 bus: arm-ccn: Check memory allocation failure 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: bus-arm-ccn-check-memory-allocation-failure.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 24771179c5c138f0ea3ef88b7972979f62f2d5db Mon Sep 17 00:00:00 2001 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 27 Aug 2017 11:06:50 +0100 Subject: bus: arm-ccn: Check memory allocation failure From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> commit 24771179c5c138f0ea3ef88b7972979f62f2d5db upstream. Check memory allocation failures and return -ENOMEM in such cases This avoids a potential NULL pointer dereference. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Acked-by: Scott Branden <scott.branden(a)broadcom.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1271,6 +1271,10 @@ static int arm_ccn_pmu_init(struct arm_c int len = snprintf(NULL, 0, "ccn_%d", ccn->dt.id); name = devm_kzalloc(ccn->dev, len + 1, GFP_KERNEL); + if (!name) { + err = -ENOMEM; + goto error_choose_name; + } snprintf(name, len + 1, "ccn_%d", ccn->dt.id); } @@ -1318,6 +1322,7 @@ static int arm_ccn_pmu_init(struct arm_c error_pmu_register: error_set_affinity: +error_choose_name: ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id); for (i = 0; i < ccn->num_xps; i++) writel(0, ccn->xp[i].base + CCN_XP_DT_CONTROL); Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/bus-arm-ccn-check-memory-allocation-failure.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-cci: Fix use of smp_processor_id() in preemptible 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 bus: arm-cci: Fix use of smp_processor_id() in preemptible 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: bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-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 4608af8aa53e7f3922ddee695d023b7bcd5cb35b Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 3 Oct 2017 18:14:13 +0100 Subject: bus: arm-cci: Fix use of smp_processor_id() in preemptible context From: Marc Zyngier <marc.zyngier(a)arm.com> commit 4608af8aa53e7f3922ddee695d023b7bcd5cb35b upstream. The ARM CCI driver seem to be using smp_processor_id() in a preemptible context, which is likely to make a DEBUG_PREMPT kernel scream at boot time. Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug registration, making sure that we don't race against a CPU down operation. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-cci.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/bus/arm-cci.c +++ b/drivers/bus/arm-cci.c @@ -1755,14 +1755,17 @@ static int cci_pmu_probe(struct platform raw_spin_lock_init(&cci_pmu->hw_events.pmu_lock); mutex_init(&cci_pmu->reserve_mutex); atomic_set(&cci_pmu->active_events, 0); - cpumask_set_cpu(smp_processor_id(), &cci_pmu->cpus); + cpumask_set_cpu(get_cpu(), &cci_pmu->cpus); ret = cci_pmu_init(cci_pmu, pdev); - if (ret) + if (ret) { + put_cpu(); return ret; + } cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCI_ONLINE, &cci_pmu->node); + put_cpu(); pr_info("ARM %s PMU driver probed", cci_pmu->model->name); return 0; } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror