November 2020 - Linux-stable-mirror

patch "iio: adc: stm32-adc: fix a regression when using dma and irq" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32-adc: fix a regression when using dma and irq to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 695e2f5c289bb7f8b85351dcfa35fa236e0200a4 Mon Sep 17 00:00:00 2001 From: Olivier Moysan <olivier.moysan(a)st.com> Date: Wed, 21 Oct 2020 10:53:13 +0200 Subject: iio: adc: stm32-adc: fix a regression when using dma and irq Since overrun interrupt support has been added, there's a regression when two ADCs are used at the same time, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). This is a regression as similar issue had been fixed earlier by commit dcb10920179a ("iio: adc: stm32-adc: fix a race when using several adcs with dma and irq"). Issue is that stm32_adc_eoc_enabled() returns non-zero value (always) since OVR bit has been added and enabled for both DMA and IRQ case. Remove OVR mask in IER register, and rely only on CSR status for overrun. To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has to be cleared. CSR OVR bit cannot be cleared directly by software. To do this ADC must be stopped first, and OVR bit in ADC ISR has to be cleared. Also add a check in ADC IRQ handler to report spurious IRQs. Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt") Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/stm32-adc-core.c | 41 +++++++++++--------------- drivers/iio/adc/stm32-adc.c | 50 ++++++++++++++++++++++++++++++-- 2 files changed, 65 insertions(+), 26 deletions(-) diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c index cd870c089182..a83199b212a4 100644 --- a/drivers/iio/adc/stm32-adc-core.c +++ b/drivers/iio/adc/stm32-adc-core.c @@ -41,18 +41,16 @@ * struct stm32_adc_common_regs - stm32 common registers * @csr: common status register offset * @ccr: common control register offset - * @eoc1_msk: adc1 end of conversion flag in @csr - * @eoc2_msk: adc2 end of conversion flag in @csr - * @eoc3_msk: adc3 end of conversion flag in @csr + * @eoc_msk: array of eoc (end of conversion flag) masks in csr for adc1..n + * @ovr_msk: array of ovr (overrun flag) masks in csr for adc1..n * @ier: interrupt enable register offset for each adc * @eocie_msk: end of conversion interrupt enable mask in @ier */ struct stm32_adc_common_regs { u32 csr; u32 ccr; - u32 eoc1_msk; - u32 eoc2_msk; - u32 eoc3_msk; + u32 eoc_msk[STM32_ADC_MAX_ADCS]; + u32 ovr_msk[STM32_ADC_MAX_ADCS]; u32 ier; u32 eocie_msk; }; @@ -282,21 +280,20 @@ static int stm32h7_adc_clk_sel(struct platform_device *pdev, static const struct stm32_adc_common_regs stm32f4_adc_common_regs = { .csr = STM32F4_ADC_CSR, .ccr = STM32F4_ADC_CCR, - .eoc1_msk = STM32F4_EOC1 | STM32F4_OVR1, - .eoc2_msk = STM32F4_EOC2 | STM32F4_OVR2, - .eoc3_msk = STM32F4_EOC3 | STM32F4_OVR3, + .eoc_msk = { STM32F4_EOC1, STM32F4_EOC2, STM32F4_EOC3}, + .ovr_msk = { STM32F4_OVR1, STM32F4_OVR2, STM32F4_OVR3}, .ier = STM32F4_ADC_CR1, - .eocie_msk = STM32F4_EOCIE | STM32F4_OVRIE, + .eocie_msk = STM32F4_EOCIE, }; /* STM32H7 common registers definitions */ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = { .csr = STM32H7_ADC_CSR, .ccr = STM32H7_ADC_CCR, - .eoc1_msk = STM32H7_EOC_MST | STM32H7_OVR_MST, - .eoc2_msk = STM32H7_EOC_SLV | STM32H7_OVR_SLV, + .eoc_msk = { STM32H7_EOC_MST, STM32H7_EOC_SLV}, + .ovr_msk = { STM32H7_OVR_MST, STM32H7_OVR_SLV}, .ier = STM32H7_ADC_IER, - .eocie_msk = STM32H7_EOCIE | STM32H7_OVRIE, + .eocie_msk = STM32H7_EOCIE, }; static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = { @@ -318,6 +315,7 @@ static void stm32_adc_irq_handler(struct irq_desc *desc) { struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc); struct irq_chip *chip = irq_desc_get_chip(desc); + int i; u32 status; chained_irq_enter(chip, desc); @@ -335,17 +333,12 @@ static void stm32_adc_irq_handler(struct irq_desc *desc) * before invoking the interrupt handler (e.g. call ISR only for * IRQ-enabled ADCs). */ - if (status & priv->cfg->regs->eoc1_msk && - stm32_adc_eoc_enabled(priv, 0)) - generic_handle_irq(irq_find_mapping(priv->domain, 0)); - - if (status & priv->cfg->regs->eoc2_msk && - stm32_adc_eoc_enabled(priv, 1)) - generic_handle_irq(irq_find_mapping(priv->domain, 1)); - - if (status & priv->cfg->regs->eoc3_msk && - stm32_adc_eoc_enabled(priv, 2)) - generic_handle_irq(irq_find_mapping(priv->domain, 2)); + for (i = 0; i < priv->cfg->num_irqs; i++) { + if ((status & priv->cfg->regs->eoc_msk[i] && + stm32_adc_eoc_enabled(priv, i)) || + (status & priv->cfg->regs->ovr_msk[i])) + generic_handle_irq(irq_find_mapping(priv->domain, i)); + } chained_irq_exit(chip, desc); }; diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index b3f31f147347..16c02c30dec7 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -154,6 +154,7 @@ struct stm32_adc; * @start_conv: routine to start conversions * @stop_conv: routine to stop conversions * @unprepare: optional unprepare routine (disable, power-down) + * @irq_clear: routine to clear irqs * @smp_cycles: programmable sampling time (ADC clock cycles) */ struct stm32_adc_cfg { @@ -166,6 +167,7 @@ struct stm32_adc_cfg { void (*start_conv)(struct iio_dev *, bool dma); void (*stop_conv)(struct iio_dev *); void (*unprepare)(struct iio_dev *); + void (*irq_clear)(struct iio_dev *indio_dev, u32 msk); const unsigned int *smp_cycles; }; @@ -621,6 +623,13 @@ static void stm32f4_adc_stop_conv(struct iio_dev *indio_dev) STM32F4_ADON | STM32F4_DMA | STM32F4_DDS); } +static void stm32f4_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + + stm32_adc_clr_bits(adc, adc->cfg->regs->isr_eoc.reg, msk); +} + static void stm32h7_adc_start_conv(struct iio_dev *indio_dev, bool dma) { struct stm32_adc *adc = iio_priv(indio_dev); @@ -659,6 +668,13 @@ static void stm32h7_adc_stop_conv(struct iio_dev *indio_dev) stm32_adc_clr_bits(adc, STM32H7_ADC_CFGR, STM32H7_DMNGT_MASK); } +static void stm32h7_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + /* On STM32H7 IRQs are cleared by writing 1 into ISR register */ + stm32_adc_set_bits(adc, adc->cfg->regs->isr_eoc.reg, msk); +} + static int stm32h7_adc_exit_pwr_down(struct iio_dev *indio_dev) { struct stm32_adc *adc = iio_priv(indio_dev); @@ -1235,17 +1251,40 @@ static int stm32_adc_read_raw(struct iio_dev *indio_dev, } } +static void stm32_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + + adc->cfg->irq_clear(indio_dev, msk); +} + static irqreturn_t stm32_adc_threaded_isr(int irq, void *data) { struct iio_dev *indio_dev = data; struct stm32_adc *adc = iio_priv(indio_dev); const struct stm32_adc_regspec *regs = adc->cfg->regs; u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg); + u32 mask = stm32_adc_readl(adc, regs->ier_eoc.reg); - if (status & regs->isr_ovr.mask) + /* Check ovr status right now, as ovr mask should be already disabled */ + if (status & regs->isr_ovr.mask) { + /* + * Clear ovr bit to avoid subsequent calls to IRQ handler. + * This requires to stop ADC first. OVR bit state in ISR, + * is propaged to CSR register by hardware. + */ + adc->cfg->stop_conv(indio_dev); + stm32_adc_irq_clear(indio_dev, regs->isr_ovr.mask); dev_err(&indio_dev->dev, "Overrun, stopping: restart needed\n"); + return IRQ_HANDLED; + } - return IRQ_HANDLED; + if (!(status & mask)) + dev_err_ratelimited(&indio_dev->dev, + "Unexpected IRQ: IER=0x%08x, ISR=0x%08x\n", + mask, status); + + return IRQ_NONE; } static irqreturn_t stm32_adc_isr(int irq, void *data) @@ -1254,6 +1293,10 @@ static irqreturn_t stm32_adc_isr(int irq, void *data) struct stm32_adc *adc = iio_priv(indio_dev); const struct stm32_adc_regspec *regs = adc->cfg->regs; u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg); + u32 mask = stm32_adc_readl(adc, regs->ier_eoc.reg); + + if (!(status & mask)) + return IRQ_WAKE_THREAD; if (status & regs->isr_ovr.mask) { /* @@ -2046,6 +2089,7 @@ static const struct stm32_adc_cfg stm32f4_adc_cfg = { .start_conv = stm32f4_adc_start_conv, .stop_conv = stm32f4_adc_stop_conv, .smp_cycles = stm32f4_adc_smp_cycles, + .irq_clear = stm32f4_adc_irq_clear, }; static const struct stm32_adc_cfg stm32h7_adc_cfg = { @@ -2057,6 +2101,7 @@ static const struct stm32_adc_cfg stm32h7_adc_cfg = { .prepare = stm32h7_adc_prepare, .unprepare = stm32h7_adc_unprepare, .smp_cycles = stm32h7_adc_smp_cycles, + .irq_clear = stm32h7_adc_irq_clear, }; static const struct stm32_adc_cfg stm32mp1_adc_cfg = { @@ -2069,6 +2114,7 @@ static const struct stm32_adc_cfg stm32mp1_adc_cfg = { .prepare = stm32h7_adc_prepare, .unprepare = stm32h7_adc_unprepare, .smp_cycles = stm32h7_adc_smp_cycles, + .irq_clear = stm32h7_adc_irq_clear, }; static const struct of_device_id stm32_adc_of_match[] = { -- 2.29.2

4 years, 5 months

1
0
0 0

patch "iio: adc: mediatek: fix unset field" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: mediatek: fix unset field to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 15207a92e019803d62687455d8aa2ff9eb3dc82c Mon Sep 17 00:00:00 2001 From: Fabien Parent <fparent(a)baylibre.com> Date: Sun, 18 Oct 2020 21:46:44 +0200 Subject: iio: adc: mediatek: fix unset field dev_comp field is used in a couple of places but it is never set. This results in kernel oops when dereferencing a NULL pointer. Set the `dev_comp` field correctly in the probe function. Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support") Signed-off-by: Fabien Parent <fparent(a)baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/mt6577_auxadc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c index ac415cb089cd..79c1dd68b909 100644 --- a/drivers/iio/adc/mt6577_auxadc.c +++ b/drivers/iio/adc/mt6577_auxadc.c @@ -9,9 +9,9 @@ #include <linux/err.h> #include <linux/kernel.h> #include <linux/module.h> -#include <linux/of.h> -#include <linux/of_device.h> +#include <linux/mod_devicetable.h> #include <linux/platform_device.h> +#include <linux/property.h> #include <linux/iopoll.h> #include <linux/io.h> #include <linux/iio/iio.h> @@ -276,6 +276,8 @@ static int mt6577_auxadc_probe(struct platform_device *pdev) goto err_disable_clk; } + adc_dev->dev_comp = device_get_match_data(&pdev->dev); + mutex_init(&adc_dev->lock); mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC, -- 2.29.2

4 years, 5 months

1
0
0 0

patch "iio: cros_ec: Use default frequencies when EC returns invalid" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: cros_ec: Use default frequencies when EC returns invalid to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 56e4f2dda23c6d39d327944faa89efaa4eb290d1 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou <gwendal(a)chromium.org> Date: Tue, 30 Jun 2020 08:37:30 -0700 Subject: iio: cros_ec: Use default frequencies when EC returns invalid information Minimal and maximal frequencies supported by a sensor is queried. On some older machines, these frequencies are not returned properly and the EC returns 0 instead. When returned maximal frequency is 0, ignore the information and use default frequencies instead. Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Link: https://lore.kernel.org/r/20200630153730.3302889-1-gwendal@chromium.org CC: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- .../cros_ec_sensors/cros_ec_sensors_core.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index c62cacc04672..e3f507771f17 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -256,7 +256,7 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent); struct cros_ec_dev *ec = sensor_hub->ec; struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev); - u32 ver_mask; + u32 ver_mask, temp; int frequencies[ARRAY_SIZE(state->frequencies) / 2] = { 0 }; int ret, i; @@ -311,10 +311,16 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, &frequencies[2], &state->fifo_max_event_count); } else { - frequencies[1] = state->resp->info_3.min_frequency; - frequencies[2] = state->resp->info_3.max_frequency; - state->fifo_max_event_count = - state->resp->info_3.fifo_max_event_count; + if (state->resp->info_3.max_frequency == 0) { + get_default_min_max_freq(state->resp->info.type, + &frequencies[1], + &frequencies[2], + &temp); + } else { + frequencies[1] = state->resp->info_3.min_frequency; + frequencies[2] = state->resp->info_3.max_frequency; + } + state->fifo_max_event_count = state->resp->info_3.fifo_max_event_count; } for (i = 0; i < ARRAY_SIZE(frequencies); i++) { state->frequencies[2 * i] = frequencies[i] / 1000; -- 2.29.2

4 years, 5 months

1
0
0 0

[PATCH] MIPS: reserve the memblock right after the kernel

by Alexander A Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Linux doesn't own the memory immediately after the kernel image. On Octeon bootloader places a shared structure right close after the kernel _end, refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c. If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc() inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns memory block overlapping with the above octeon_bootinfo structure, which is being overwritten afterwards. Cc: stable(a)vger.kernel.org Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> --- arch/mips/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 0d42532..f6cf2f6 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -504,6 +504,12 @@ static void __init check_kernel_sections_mem(void) if (!memblock_is_region_memory(start, size)) { pr_info("Kernel sections are not in the memory maps\n"); memblock_add(start, size); + /* + * Octeon bootloader places shared data structure right after + * the kernel => make sure it will not be corrupted. + */ + memblock_reserve(__pa_symbol(&_end), + start + size - __pa_symbol(&_end)); } } -- 2.10.2

4 years, 5 months

7
15
0 0

[PATCH][v2] x86/microcode/intel: check cpu stepping and processor flag before saving microcode

by Chen Yu

Currently scan_microcode() leverages microcode_matches() to check if the microcode matches the CPU by comparing the family and model. However before saving the microcode in scan_microcode(), the processor stepping and flag of the microcode signature should also be considered in order to avoid incompatible update and caused the failure of microcode update. For example on one platform the microcode failed to be updated to the latest revison on APs during resume from S3 due to incompatible cpu stepping and signature->pf. This is because the scan_microcode() has saved an incompatible copy of intel_ucode_patch in save_microcode_in_initrd_intel() after bootup. And this intel_ucode_patch is used by APs during early resume from S3 which results in unchecked MSR access error during resume from S3: [ 95.519390] unchecked MSR access error: RDMSR from 0x123 at rIP: 0xffffffffb7676208 (native_read_msr+0x8/0x40) [ 95.519391] Call Trace: [ 95.519395] update_srbds_msr+0x38/0x80 [ 95.519396] identify_secondary_cpu+0x7a/0x90 [ 95.519397] smp_store_cpu_info+0x4e/0x60 [ 95.519398] start_secondary+0x49/0x150 [ 95.519399] secondary_startup_64_no_verify+0xa6/0xab The system keeps running on old microcode during resume: [ 210.366757] microcode: load_ucode_intel_ap: CPU1, enter, intel_ucode_patch: 0xffff9bf2816e0000 [ 210.366757] microcode: load_ucode_intel_ap: CPU1, p: 0xffff9bf2816e0000, rev: 0xd6 [ 210.366759] microcode: apply_microcode_early: rev: 0x84 [ 210.367826] microcode: apply_microcode_early: rev after upgrade: 0x84 until mc_cpu_starting() is invoked on each AP during resume and the correct microcode is updated via apply_microcode_intel(). To fix this issue, the scan_microcode() uses find_matching_signature() instead of microcode_matches() to compare the (family, model, stepping, processor flag), and only save the microcode that matches. As there is no other place invoking microcode_matches(), remove it accordingly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208535 Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Cc: stable(a)vger.kernel.org#v4.10+ Reviewed-by: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Chen Yu <yu.c.chen(a)intel.com> --- v2: Remove RFC tag and Cc the stable mailing list. --- arch/x86/kernel/cpu/microcode/intel.c | 50 ++------------------------- 1 file changed, 2 insertions(+), 48 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 6a99535d7f37..923853f79099 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -100,53 +100,6 @@ static int has_newer_microcode(void *mc, unsigned int csig, int cpf, int new_rev return find_matching_signature(mc, csig, cpf); } -/* - * Given CPU signature and a microcode patch, this function finds if the - * microcode patch has matching family and model with the CPU. - * - * %true - if there's a match - * %false - otherwise - */ -static bool microcode_matches(struct microcode_header_intel *mc_header, - unsigned long sig) -{ - unsigned long total_size = get_totalsize(mc_header); - unsigned long data_size = get_datasize(mc_header); - struct extended_sigtable *ext_header; - unsigned int fam_ucode, model_ucode; - struct extended_signature *ext_sig; - unsigned int fam, model; - int ext_sigcount, i; - - fam = x86_family(sig); - model = x86_model(sig); - - fam_ucode = x86_family(mc_header->sig); - model_ucode = x86_model(mc_header->sig); - - if (fam == fam_ucode && model == model_ucode) - return true; - - /* Look for ext. headers: */ - if (total_size <= data_size + MC_HEADER_SIZE) - return false; - - ext_header = (void *) mc_header + data_size + MC_HEADER_SIZE; - ext_sig = (void *)ext_header + EXT_HEADER_SIZE; - ext_sigcount = ext_header->count; - - for (i = 0; i < ext_sigcount; i++) { - fam_ucode = x86_family(ext_sig->sig); - model_ucode = x86_model(ext_sig->sig); - - if (fam == fam_ucode && model == model_ucode) - return true; - - ext_sig++; - } - return false; -} - static struct ucode_patch *memdup_patch(void *data, unsigned int size) { struct ucode_patch *p; @@ -344,7 +297,8 @@ scan_microcode(void *data, size_t size, struct ucode_cpu_info *uci, bool save) size -= mc_size; - if (!microcode_matches(mc_header, uci->cpu_sig.sig)) { + if (!find_matching_signature(data, uci->cpu_sig.sig, + uci->cpu_sig.pf)) { data += mc_size; continue; } -- 2.17.1

4 years, 5 months

2
1
0 0

[PATCH] ubifs: wbuf: Don't leak kernel memory to flash

by Richard Weinberger

Write buffers use a kmalloc()'ed buffer, they can leak up to seven bytes of kernel memory to flash if writes are not aligned. So use ubifs_pad() to fill these gaps with padding bytes. This was never a problem while scanning because the scanner logic manually aligns node lengths and skips over these gaps. Cc: <stable(a)vger.kernel.org> Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger <richard(a)nod.at> --- fs/ubifs/io.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c index 7e4bfaf2871f..eae9cf5a57b0 100644 --- a/fs/ubifs/io.c +++ b/fs/ubifs/io.c @@ -319,7 +319,7 @@ void ubifs_pad(const struct ubifs_info *c, void *buf, int pad) { uint32_t crc; - ubifs_assert(c, pad >= 0 && !(pad & 7)); + ubifs_assert(c, pad >= 0); if (pad >= UBIFS_PAD_NODE_SZ) { struct ubifs_ch *ch = buf; @@ -764,6 +764,10 @@ int ubifs_wbuf_write_nolock(struct ubifs_wbuf *wbuf, void *buf, int len) * write-buffer. */ memcpy(wbuf->buf + wbuf->used, buf, len); + if (aligned_len > len) { + ubifs_assert(c, aligned_len - len < 8); + ubifs_pad(c, wbuf->buf + wbuf->used + len, aligned_len - len); + } if (aligned_len == wbuf->avail) { dbg_io("flush jhead %s wbuf to LEB %d:%d", @@ -856,13 +860,18 @@ int ubifs_wbuf_write_nolock(struct ubifs_wbuf *wbuf, void *buf, int len) } spin_lock(&wbuf->lock); - if (aligned_len) + if (aligned_len) { /* * And now we have what's left and what does not take whole * max. write unit, so write it to the write-buffer and we are * done. */ memcpy(wbuf->buf, buf + written, len); + if (aligned_len > len) { + ubifs_assert(c, aligned_len - len < 8); + ubifs_pad(c, wbuf->buf + len, aligned_len - len); + } + } if (c->leb_size - wbuf->offs >= c->max_write_size) wbuf->size = c->max_write_size; -- 2.26.2

4 years, 5 months

3
3
0 0

[PATCH] unlz4: Handle 0-size chunks, discard trailing padding/garbage

by siarhei.liakh＠concurrent-rt.com

From: Siarhei Liakh <siarhei.liakh(a)concurrent-rt.com> TL;DR: There are two places in unlz4() function where reads beyond the end of a buffer might happen under certain conditions which had been observed in real life on stock Ubuntu 20.04 x86_64 with several vanilla mainline kernels, including 5.10. As a result of this issue, the kernel fails to decompress LZ4-compressed initramfs with following message showing up in the logs: initramfs unpacking failed: Decoding failed Note that in most cases the affected system is still able to proceed with the boot process to completion. LONG STORY: Background. Not so long ago we've noticed that some of our Ubuntu 20.04 x86_64 test systems often fail to boot newly generated initramfs image. After extensive investigation we determined that a failure required the following combination for our 5.4.66-rt38 kernel with some additional custom patches: Real x86_64 hardware or QEMU UEFI boot Ubunutu 20.04 (or 20.04.1) x86_64 CONFIG_BLK_DEV_RAM=y in .config COMPRESS=lz4 in initramfs.conf Freshly compiled and installed kernel Freshly generated and installed initramfs image In our testing, such a combination would often produce a non-bootable system. It is important to note that [un]bootability of the system was later tracked down to particular instances of initramfs images, and would follow them if they were to be switched around/transferred to other systems. What is even more important is that consecutive re-generations of initramfs images from the same source and binary materials would yield about 75% of "bad" images. Further, once the image is identified as "bad",it always stays "bad"; once one is "good" it always stays "good". Reverting CONFIG_BLK_DEV_RAM to "m" (default in Ubuntu), or changing COMPRESS to "gzip" yields a 100% bootable system. Decompressing "bad" initramfs image with "unmkinitramfs" yields *exactly* the same set of binaries, as verified by matching MD5 sums to those from "good" image. Speculation. Based on general observations, it appears that Ubuntu's userland toolchain cannot consistently generate exactly the same compressed initramfs image, likely due to some variations in timestamps between the runs. This causes variations in compressed lz4 data stream. Further, either initramfs tools or lz4 libraries appear to pad compressed lz4 output to closest 4-byte boundary. lz4 v1.9.2 that ships with Ubuntu 20.04 appears to be able to handle such padding just fine, while lz4 (supposedly v1.8.3) within Linux kernel cannot. Several reports of somewhat similar behavior had been recently circulation through different bug tracking systems and discussion forums [1-4]. I also suspect only that systems which can mount permanent root directly (or with help of modules contained in first, supposedly uncompressed, part of initramfs, or the ones with statically linked modules) can actually complete the boot when LZ4 decompression fails. This would certainly explain why most of Ubuntu systems still manage to boot even after failing to decompress the image. The facts. Regardless of whether Ubuntu 20.04 toolchain produces a valid lz4-compressed initramfs image or not, current version of unlz4() function in kernel has two code paths which had been observed attempting to read beyond the buffer end when presented with one of the "padded"/"bad" initramfs images generated by stock Ubuntu 20.04 toolchain. Some configurations of some 5.4 kernels are known to fail to boot in such cases. This behavior also becomes evident on vanilla 5.10.0-rc3 and 5.10.0-rc4 kernels with addition of two logging statements for corresponding edge cases, even though it does not prevent system from booting in most generic configurations. Further investigation is likely warranted to confirm whether userland toolchain contains any bugs and/or whether any of these cases constitute violation of LZ4 and/or initramfs specification. References [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660 [2] https://github.com/linuxmint/mint20-beta/issues/90 [3] https://askubuntu.com/questions/1245458/getting-the-message-0-283078-initra… [4] https://forums.linuxmint.com/viewtopic.php?t=323152 Signed-off-by: Siarhei Liakh <siarhei.liakh(a)concurrent-rt.com> --- Please CC: me directly on all replies. lib/decompress_unlz4.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c index c0cfcfd486be..a016643a6dc5 100644 --- a/lib/decompress_unlz4.c +++ b/lib/decompress_unlz4.c @@ -125,6 +125,21 @@ STATIC inline int INIT unlz4(u8 *input, long in_len, continue; } + if (chunksize == 0) { + /* + * Nothing to decode... + * FIXME: this could be an error condition due + * to invalid or corrupt data. However, some + * userspace tools had been observed producing + * otherwise valid initramfs images which happen + * to hit this condition. + * TODO: need to figure out whether the latest + * LZ4 and initramfs specifications allows for + * zero-sized chunks. + * See similar message below. + */ + break; + } if (posp) *posp += 4; @@ -179,6 +194,20 @@ STATIC inline int INIT unlz4(u8 *input, long in_len, else if (size < 0) { error("data corrupted"); goto exit_2; + } else if (size < 4) { + /* + * Ignore any undesized junk/padding... + * FIXME: this could be an error condition due + * to invalid or corrupt data. However, some + * userspace tools had been observed producing + * otherwise valid initramfs images which happen + * to hit this condition. + * TODO: need to figure out whether the latest + * LZ4 and initramfs specifications allows for + * small padding at the end of the chunk. + * See similar message above. + */ + break; } inp += chunksize; } -- 2.17.1

4 years, 5 months

2
1
0 0

stable-rc/queue/4.14 baseline: 58 runs, 1 regressions (v4.14.206-57-g106ef0d11ee4)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 58 runs, 1 regressions (v4.14.206-57-g106ef0d11ee4) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------+------+---------------+----------+--------------------+------------ odroid-xu3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.20… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.206-57-g106ef0d11ee4 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 106ef0d11ee4695a42a4544818b1b6dbf22379e6 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------+------+---------------+----------+--------------------+------------ odroid-xu3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fb333f07e16472dcdd22e62 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.206-57-g106ef0d11e… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.206-57-g106ef0d11e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fb333f07e16472dcdd22e63 new failure (last pass: v4.14.206-22-g2ec7a9bf443b0)

4 years, 5 months

1
0
0 0

stable-rc/queue/4.14 build: 4 builds: 0 failed, 4 passed, 1 warning (v4.14.206-57-g106ef0d11ee4)

by kernelci.org bot

stable-rc/queue/4.14 build: 4 builds: 0 failed, 4 passed, 1 warning (v4.14.206-57-g106ef0d11ee4) Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.14/kernel/v4.14.206-5… Tree: stable-rc Branch: queue/4.14 Git Describe: v4.14.206-57-g106ef0d11ee4 Git Commit: 106ef0d11ee4695a42a4544818b1b6dbf22379e6 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 2 unique architectures Warnings Detected: arm: palmz72_defconfig (gcc-8): 1 warning mips: Warnings summary: 1 /scratch/linux/drivers/clk/clk.c:48:27: warning: ‘orphan_list’ defined but not used [-Wunused-variable] ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- dove_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- e55_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- palmz72_defconfig (arm, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: /scratch/linux/drivers/clk/clk.c:48:27: warning: ‘orphan_list’ defined but not used [-Wunused-variable] --- For more info write to <info(a)kernelci.org>

4 years, 5 months

1
0
0 0

stable-rc/queue/4.4 build: 4 builds: 0 failed, 4 passed (v4.4.243-41-g75498c12fce0)

by kernelci.org bot

stable-rc/queue/4.4 build: 4 builds: 0 failed, 4 passed (v4.4.243-41-g75498c12fce0) Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.4/kernel/v4.4.243-41-… Tree: stable-rc Branch: queue/4.4 Git Describe: v4.4.243-41-g75498c12fce0 Git Commit: 75498c12fce0d400d89cf310841ed46844936e6f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 2 unique architectures ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- cns3420vb_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- footbridge_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- msp71xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- s3c6400_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches --- For more info write to <info(a)kernelci.org>

4 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2020