4.19.31-stable review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 147/280 netfilter: ipt_CLUSTERIP: fix warning unused variable cn
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Roxell <[email protected]>
commit 206b8cc514d7ff2b79dd2d5ad939adc7c493f07a upstream.
When CONFIG_PROC_FS isn't set the variable cn isn't used.
net/ipv4/netfilter/ipt_CLUSTERIP.c: In function ‘clusterip_net_exit’:net/ipv4/netfilter/ipt_CLUSTERIP.c:849:24: warning: unused variable ‘cn’ [-Wunused-variable]
struct clusterip_net *cn = clusterip_pernet(net);
^~Rework so the variable 'cn' is declared inside "#ifdef CONFIG_PROC_FS".
--- net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/netfilter/ipt_CLUSTERIP.c +1 -1
@@ -846,9 +846,9 @@ static int clusterip_net_init(struct netstatic void clusterip_net_exit (struct net *net) { +#ifdef CONFIG_PROC_FS struct clusterip_net *cn =clusterip_pernet (net); -#ifdef CONFIG_PROC_FS mutex_lock (&cn->mutex);proc_remove (cn->procdir); cn->procdir =NULL ;
Greg Kroah-Hartman
maintainerPATCH 148/280 spi: ti-qspi: Fix mmap read when more than one CS in use
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vignesh R <[email protected]>
commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.
Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has has got order of parameter wrong when calling regmap_update_bits() to select CS for mmap access. Mask and value arguments are interchanged. Code will work on a system with single slave, but fails when more than one CS is in use. Fix this by correcting the order of parameters when calling regmap_update_bits().
--- drivers/spi/spi-ti-qspi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/spi/spi-ti-qspi.c +3 -3
@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(stti_qspi_write (qspi,MM_SWITCH ,QSPI_SPI_SWITCH_REG );if (qspi->ctrl_base) {regmap_update_bits (qspi->ctrl_base, qspi->ctrl_reg, -MEM_CS_EN (spi->chip_select), -MEM_CS_MASK ); +MEM_CS_MASK , +MEM_CS_EN (spi->chip_select)); } qspi->mmap_enabled = true; }
@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(sti_qspi_write (qspi,0 ,QSPI_SPI_SWITCH_REG );if (qspi->ctrl_base)regmap_update_bits (qspi->ctrl_base, qspi->ctrl_reg, -0 ,MEM_CS_MASK ); +MEM_CS_MASK ,0 ); qspi->mmap_enabled = false; }
Greg Kroah-Hartman
maintainerPATCH 149/280 spi: pxa2xx: Setup maximum supported DMA transfer length
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.
When the commit b6ced294fb61
("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
switches to SPI core provided DMA helpers, it missed to setup maximum supported DMA transfer length for the controller and thus users mistakenly try to send more data than supported with the following warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
Setup maximum supported DMA transfer length in order to make users know the limit.
--- drivers/spi/spi-pxa2xx.c | 1 + 1 file changed, 1 insertion(+)
drivers/spi/spi-pxa2xx.c +1 -0
@@ -1612,6 +1612,7 @@ static int pxa2xx_spi_probe(struct platf platform_info->enable_dma = false; }else { master->can_dma = pxa2xx_spi_can_dma; + master->max_dma_len =MAX_DMA_LEN ; } }
Greg Kroah-Hartman
maintainerPATCH 150/280 regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.
LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420 Arndale Octa board).
--- drivers/regulator/s2mps11.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/regulator/s2mps11.c +3 -3
@@ -363,7 +363,7 @@ static const struct regulator_desc s2mpsregulator_desc_s2mps11_ldo (32 ,STEP_50_MV ),regulator_desc_s2mps11_ldo (33 ,STEP_50_MV ),regulator_desc_s2mps11_ldo (34 ,STEP_50_MV ), -regulator_desc_s2mps11_ldo (35 ,STEP_50_MV ), +regulator_desc_s2mps11_ldo (35 ,STEP_25_MV ),regulator_desc_s2mps11_ldo (36 ,STEP_50_MV ),regulator_desc_s2mps11_ldo (37 ,STEP_50_MV ), regulator_desc_s2mps11_ldo(38, STEP_50_MV),
@@ -373,8 +373,8 @@ static const struct regulator_desc s2mpsregulator_desc_s2mps11_buck1_4 (4 ), regulator_desc_s2mps11_buck5,regulator_desc_s2mps11_buck67810 (6 ,MIN_600_MV ,STEP_6_25_MV ), -regulator_desc_s2mps11_buck67810 (7 ,MIN_600_MV ,STEP_6_25_MV ), -regulator_desc_s2mps11_buck67810 (8 ,MIN_600_MV ,STEP_6_25_MV ), +regulator_desc_s2mps11_buck67810 (7 ,MIN_600_MV ,STEP_12_5_MV ), +regulator_desc_s2mps11_buck67810 (8 ,MIN_600_MV ,STEP_12_5_MV ), regulator_desc_s2mps11_buck9, regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV), };
Greg Kroah-Hartman
maintainerPATCH 151/280 regulator: max77620: Initialize values for DT properties
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Zhang <[email protected]>
commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.
If regulator DT node doesn't exist, its of_parse_cb callback function isn't called. Then all values for DT properties are filled with zero. This leads to wrong register update for FPS and POK settings.
--- drivers/regulator/max77620-regulator.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/regulator/max77620-regulator.c +9 -1
@@ -1,7 +1,7 @@/* * Maxim MAX77620 Regulator driver * -* Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved. +* Copyright (c) 2016-2018, NVIDIA CORPORATION. All rights reserved. * * Author: Mallikarjun Kasoju <[email protected]> * Laxman Dewangan <[email protected]>
@@ -803,6 +803,14 @@ static int max77620_regulator_probe(stru rdesc = &rinfo[id].desc; pmic->rinfo[id] = &max77620_regs_info[id]; pmic->enable_power_mode[id] =MAX77620_POWER_MODE_NORMAL ; + pmic->reg_pdata[id].active_fps_src =-1 ; + pmic->reg_pdata[id].active_fps_pd_slot =-1 ; + pmic->reg_pdata[id].active_fps_pu_slot =-1 ; + pmic->reg_pdata[id].suspend_fps_src =-1 ; + pmic->reg_pdata[id].suspend_fps_pd_slot =-1 ; + pmic->reg_pdata[id].suspend_fps_pu_slot =-1 ; + pmic->reg_pdata[id].power_ok =-1 ; + pmic->reg_pdata[id].ramp_rate_setting =-1 ; ret =max77620_read_slew_rate (pmic, id);if (ret <0 )
Greg Kroah-Hartman
maintainerPATCH 152/280 regulator: s2mpa01: Fix step values for some LDOs
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stuart Menefy <[email protected]>
commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.
The step values for some of the LDOs appears to be incorrect, resulting in incorrect voltages (or at least, ones which are different from the Samsung 3.4 vendor kernel).
--- drivers/regulator/s2mpa01.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/regulator/s2mpa01.c +5 -5
@@ -298,13 +298,13 @@ static const struct regulator_desc regulregulator_desc_ldo (2 ,STEP_50_MV ),regulator_desc_ldo (3 ,STEP_50_MV ),regulator_desc_ldo (4 ,STEP_50_MV ), -regulator_desc_ldo (5 ,STEP_50_MV ), +regulator_desc_ldo (5 ,STEP_25_MV ),regulator_desc_ldo (6 ,STEP_25_MV ),regulator_desc_ldo (7 ,STEP_50_MV ),regulator_desc_ldo (8 ,STEP_50_MV ),regulator_desc_ldo (9 ,STEP_50_MV ),regulator_desc_ldo (10 ,STEP_50_MV ), -regulator_desc_ldo (11 ,STEP_25_MV ), +regulator_desc_ldo (11 ,STEP_50_MV ),regulator_desc_ldo (12 ,STEP_50_MV ),regulator_desc_ldo (13 ,STEP_50_MV ), regulator_desc_ldo(14, STEP_50_MV),
@@ -315,11 +315,11 @@ static const struct regulator_desc regulregulator_desc_ldo (19 ,STEP_50_MV ),regulator_desc_ldo (20 ,STEP_50_MV ),regulator_desc_ldo (21 ,STEP_50_MV ), -regulator_desc_ldo (22 ,STEP_25_MV ), -regulator_desc_ldo (23 ,STEP_25_MV ), +regulator_desc_ldo (22 ,STEP_50_MV ), +regulator_desc_ldo (23 ,STEP_50_MV ),regulator_desc_ldo (24 ,STEP_50_MV ),regulator_desc_ldo (25 ,STEP_50_MV ), -regulator_desc_ldo (26 ,STEP_50_MV ), +regulator_desc_ldo (26 ,STEP_25_MV ),regulator_desc_buck1_4 (1 ),regulator_desc_buck1_4 (2 ), regulator_desc_buck1_4(3),
Greg Kroah-Hartman
maintainerPATCH 153/280 clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stuart Menefy <[email protected]>
commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.
When a timer tick occurs and the clock is in one-shot mode, the timer needs to be stopped to prevent it triggering subsequent interrupts. Currently this code is in exynos4_mct_tick_clear(), but as it is only needed when an ISR occurs move it into exynos4_mct_tick_isr(), leaving exynos4_mct_tick_clear() just doing what its name suggests it should.
--- drivers/clocksource/exynos_mct.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/clocksource/exynos_mct.c +11 -11
@@ -388,6 +388,13 @@ static void exynos4_mct_tick_start(unsigexynos4_mct_write (tmp, mevt->base +MCT_L_TCON_OFFSET ); } +static void exynos4_mct_tick_clear (struct mct_clock_event_device *mevt) +{ +/* Clear the MCT tick interrupt */ +if (readl_relaxed (reg_base + mevt->base +MCT_L_INT_CSTAT_OFFSET ) &1 ) +exynos4_mct_write (0x1 , mevt->base +MCT_L_INT_CSTAT_OFFSET ); +} +static int exynos4_tick_set_next_event (unsigned long cycles,struct clock_event_device *evt) {
@@ -420,8 +427,11 @@ static int set_state_periodic(struct cloreturn 0 ; } -static void exynos4_mct_tick_clear (struct mct_clock_event_device *mevt) +static irqreturn_t exynos4_mct_tick_isr (int irq,void *dev_id) { +struct mct_clock_event_device *mevt = dev_id; +struct clock_event_device *evt = &mevt->evt; +/* * This is for supporting oneshot mode. * Mct would generate interrupt periodically
@@ -430,16 +440,6 @@ static void exynos4_mct_tick_clear(strucif (!clockevent_state_periodic (&mevt->evt))exynos4_mct_tick_stop (mevt); -/* Clear the MCT tick interrupt */ -if (readl_relaxed (reg_base + mevt->base +MCT_L_INT_CSTAT_OFFSET ) &1 ) -exynos4_mct_write (0x1 , mevt->base +MCT_L_INT_CSTAT_OFFSET ); -} - -static irqreturn_t exynos4_mct_tick_isr (int irq,void *dev_id) -{ -struct mct_clock_event_device *mevt = dev_id; -struct clock_event_device *evt = &mevt->evt; -exynos4_mct_tick_clear (mevt); evt->event_handler (evt);
Greg Kroah-Hartman
maintainerPATCH 154/280 clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stuart Menefy <[email protected]>
commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.
When shutting down the timer, ensure that after we have stopped the timer any pending interrupts are cleared. This fixes a problem when suspending, as interrupts are disabled before the timer is stopped, so the timer interrupt may still be asserted, preventing the system entering a low power state when the wfi is executed.
--- drivers/clocksource/exynos_mct.c | 1 + 1 file changed, 1 insertion(+)
drivers/clocksource/exynos_mct.c +1 -0
@@ -411,6 +411,7 @@ static int set_state_shutdown(struct clo mevt = container_of(evt, struct mct_clock_event_device, evt);exynos4_mct_tick_stop (mevt); +exynos4_mct_tick_clear (mevt);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 155/280 clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Holland <[email protected]>
commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.
The Allwinner A64 SoC is known[1] to have an unstable architectural timer, which manifests itself most obviously in the time jumping forward a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a timer frequency of 24 MHz, implying that the time went slightly backward (and this was interpreted by the kernel as it jumping forward and wrapping around past the epoch).
Investigation revealed instability in the low bits of CNTVCT at the point a high bit rolls over. This leads to power-of-two cycle forward and backward jumps. (Testing shows that forward jumps are about twice as likely as backward jumps.) Since the counter value returns to normal after an indeterminate read, each "jump" really consists of both a forward and backward jump from the software perspective.
Unless the kernel is trapping CNTVCT reads, a userspace program is able to read the register in a loop faster than it changes. A test program running on all 4 CPU cores that reported jumps larger than 100 ms was run for 13.6 hours and reported the following:
Count | Event
-------+---------------------------
9940 | jumped backward 699ms
268 | jumped backward 1398ms
1 | jumped backward 2097ms
16020 | jumped forward 175ms
6443 | jumped forward 699ms
2976 | jumped forward 1398ms
9 | jumped forward 356516ms
9 | jumped forward 357215ms
4 | jumped forward 714430ms
1 | jumped forward 3578440msThis works out to a jump larger than 100 ms about every 5.5 seconds on each CPU core.
The largest jump (almost an hour!) was the following sequence of reads:
0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
Note that the middle bits don't necessarily all read as all zeroes or all ones during the anomalous behavior; however the low 10 bits checked by the function in this patch have never been observed with any other value.
Also note that smaller jumps are much more common, with backward jumps of 2048 (2^11) cycles observed over 400 times per second on each core. (Of course, this is partially explained by lower bits rolling over more frequently.) Any one of these could have caused the 95 year time skip.
Similar anomalies were observed while reading CNTPCT (after patching the kernel to allow reads from userspace). However, the CNTPCT jumps are much less frequent, and only small jumps were observed. The same program as before (except now reading CNTPCT) observed after 72 hours:
Count | Event
-------+---------------------------
17 | jumped backward 699ms
52 | jumped forward 175ms
2831 | jumped forward 699ms
5 | jumped forward 1398msFurther investigation showed that the instability in CNTPCT/CNTVCT also affected the respective timer's TVAL register. The following values were observed immediately after writing CNVT_TVAL to 0x10000000:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
The pattern of errors in CNTV_TVAL seemed to depend on exactly which value was written to it. For example, after writing 0x10101010:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
I was also twice able to reproduce the issue covered by Allwinner's workaround[4], that writing to TVAL sometimes fails, and both CVAL and TVAL are left with entirely bogus values. One was the following values:
CNTVCT | CNTV_TVAL | CNTV_CVAL
--------------------+------------+--------------------------------------
0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
========================================================================
Because the CPU can read the CNTPCT/CNTVCT registers faster than they change, performing two reads of the register and comparing the high bits (like other workarounds) is not a workable solution. And because the timer can jump both forward and backward, no pair of reads can distinguish a good value from a bad one. The only way to guarantee a good value from consecutive reads would be to read _three_ times, and take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or more if an anomaly is detected.
However, since there is a distinct pattern to the bad values, we can optimize the common case (1022/1024 of the time) to a single read by simply ignoring values that match the error pattern. This still takes no more than 3 cycles in the worst case, and requires much less code. As an additional safety check, we still limit the loop iteration to the number of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
For the TVAL registers, the simple solution is to not use them. Instead, read or write the CVAL and calculate the TVAL value in software.
Although the manufacturer is aware of at least part of the erratum[4], there is no official name for it. For now, use the kernel-internal name "UNKNOWN1".
[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
--- Documentation/arm64/silicon-errata.txt | 2 + drivers/clocksource/Kconfig | 10 ++++++ drivers/clocksource/arm_arch_timer.c | 55 +++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+)
Documentation/arm64/silicon-errata.txt +2 -0
@@ -44,6 +44,8 @@ stable kernels. | Implementor | Component | Erratum ID | Kconfig | +----------------+-----------------+-----------------+-----------------------------+ +| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +| | | | | | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
drivers/clocksource/Kconfig +10 -0
@@ -365,6 +365,16 @@ config ARM64_ERRATUM_858921 The workaround will be dynamically enabled when an affected core is detected. +config SUN50I_ERRATUM_UNKNOWN1 + bool "Workaround for Allwinner A64 erratum UNKNOWN1" + default y + depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI + select ARM_ARCH_TIMER_OOL_WORKAROUND + help + This option enables a workaround for instability in the timer on + the Allwinner A64 SoC. The workaround will only be active if the + allwinner,erratum-unknown1 property is found in the timer node. + config ARM_GLOBAL_TIMER bool "Support for the ARM global timer" if COMPILE_TEST select TIMER_OF if OF
drivers/clocksource/arm_arch_timer.c +55 -0
67 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 156/280 s390/setup: fix early warning messages
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Schwidefsky <[email protected]>
commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.
The setup_lowcore() function creates a new prefix page for the boot CPU. The PSW mask for the system_call, external interrupt, i/o interrupt and the program check handler have the DAT bit set in this new prefix page.
At the time setup_lowcore is called the system still runs without virtual address translation, the paging_init() function creates the kernel page table and loads the CR13 with the kernel ASCE.
Any code between setup_lowcore() and the end of paging_init() that has a BUG or WARN statement will create a program check that can not be handled correctly as there is no kernel page table yet.
To allow early WARN statements initially setup the lowcore with DAT off and set the DAT bit only after paging_init() has completed.
--- arch/s390/kernel/setup.c | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-)
arch/s390/kernel/setup.c +23 -9
@@ -303,7 +303,7 @@ early_param("vmalloc", parse_vmalloc); void *restart_stack __section(.data); -static void __init setup_lowcore (void ) +static void __init setup_lowcore_dat_off (void ) {struct lowcore *lc;
@@ -314,19 +314,16 @@ static void __init setup_lowcore(void) lc =memblock_virt_alloc_low (sizeof (*lc),sizeof (*lc)); lc->restart_psw.mask =PSW_KERNEL_BITS ; lc->restart_psw.addr = (unsigned long ) restart_int_handler; - lc->external_new_psw.mask =PSW_KERNEL_BITS | -PSW_MASK_DAT |PSW_MASK_MCHECK ; + lc->external_new_psw.mask =PSW_KERNEL_BITS |PSW_MASK_MCHECK ; lc->external_new_psw.addr = (unsigned long ) ext_int_handler; lc->svc_new_psw.mask =PSW_KERNEL_BITS | -PSW_MASK_DAT |PSW_MASK_IO |PSW_MASK_EXT |PSW_MASK_MCHECK ; +PSW_MASK_IO |PSW_MASK_EXT |PSW_MASK_MCHECK ; lc->svc_new_psw.addr = (unsigned long ) system_call; - lc->program_new_psw.mask =PSW_KERNEL_BITS | -PSW_MASK_DAT |PSW_MASK_MCHECK ; + lc->program_new_psw.mask =PSW_KERNEL_BITS |PSW_MASK_MCHECK ; lc->program_new_psw.addr = (unsigned long ) pgm_check_handler; lc->mcck_new_psw.mask =PSW_KERNEL_BITS ; lc->mcck_new_psw.addr = (unsigned long ) mcck_int_handler; - lc->io_new_psw.mask =PSW_KERNEL_BITS | -PSW_MASK_DAT |PSW_MASK_MCHECK ; + lc->io_new_psw.mask =PSW_KERNEL_BITS |PSW_MASK_MCHECK ; lc->io_new_psw.addr = (unsigned long ) io_int_handler; lc->clock_comparator = clock_comparator_max; lc->kernel_stack = ((unsigned long ) &init_thread_union)
@@ -388,6 +385,17 @@ static void __init setup_lowcore(void) lowcore_ptr[0 ] = lc; } +static void __init setup_lowcore_dat_on (void ) +{ +struct lowcore *lc; + + lc = lowcore_ptr[0 ]; + lc->external_new_psw.mask |=PSW_MASK_DAT ; + lc->svc_new_psw.mask |=PSW_MASK_DAT ; + lc->program_new_psw.mask |=PSW_MASK_DAT ; + lc->io_new_psw.mask |=PSW_MASK_DAT ; +} +static struct resource code_resource = { .name ="Kernel code" , .flags =IORESOURCE_BUSY |IORESOURCE_SYSTEM_RAM ,
@@ -946,7 +954,7 @@ void __init setup_arch(char **cmdline_p)#endif setup_resources (); -setup_lowcore (); +setup_lowcore_dat_off ();smp_fill_possible_mask ();cpu_detect_mhz_feature ();cpu_init ();
@@ -959,6 +967,12 @@ void __init setup_arch(char **cmdline_p)*/ paging_init (); +/* +* After paging_init created the kernel page table, the new PSWs +* in lowcore can now run with DAT enabled. +*/ +setup_lowcore_dat_on (); +/* Setup default console */ conmode_default ();set_preferred_console ();
Greg Kroah-Hartman
maintainerPATCH 157/280 s390/virtio: handle find on invalid queue gracefully
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Halil Pasic <[email protected]>
commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.
A queue with a capacity of zero is clearly not a valid virtio queue. Some emulators report zero queue size if queried with an invalid queue index. Instead of crashing in this case let us just return -ENOENT. To make that work properly, let us fix the notifier cleanup logic as well.
--- drivers/s390/virtio/virtio_ccw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/s390/virtio/virtio_ccw.c +3 -1
@@ -272,6 +272,8 @@ static void virtio_ccw_drop_indicators(s {struct virtio_ccw_vq_info *info; +if (!vcdev->airq_info) +return ;list_for_each_entry (info, &vcdev->virtqueues, node)drop_airq_indicator (info->vq, vcdev->airq_info); }
@@ -413,7 +415,7 @@ static int virtio_ccw_read_vq_conf(struc ret =ccw_io_helper (vcdev, ccw,VIRTIO_CCW_DOING_READ_VQ_CONF );if (ret)return ret; -return vcdev->config_block->num; +return vcdev->config_block->num ?: -ENOENT ; }static void virtio_ccw_del_vq (struct virtqueue *vq,struct ccw1 *ccw)
Greg Kroah-Hartman
maintainerPATCH 158/280 scsi: virtio_scsi: dont send sc payload with tmfs
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Franciosi <[email protected]>
commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.
The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of device-readable records and a single device-writable response entry:
struct virtio_scsi_ctrl_tmf
{
// Device-readable part
le32 type;
le32 subtype;
u8 lun[8];
le64 id;
// Device-writable part
u8 response;
}The above should be organised as two descriptor entries (or potentially more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64 id" or after "u8 response".
The Linux driver doesn't respect that, with virtscsi_abort() and virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It results in the original scsi command payload (or writable buffers) added to the tmf.
This fixes the problem by leaving cmd->sc zeroed out, which makes virtscsi_kick_cmd() add the tmf to the control vq without any payload.
--- drivers/scsi/virtio_scsi.c | 2 -- 1 file changed, 2 deletions(-)
drivers/scsi/virtio_scsi.c +0 -2
@@ -621,7 +621,6 @@ static int virtscsi_device_reset(structreturn FAILED ;memset (cmd,0 ,sizeof (*cmd)); - cmd->sc = sc; cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req ){ .type =VIRTIO_SCSI_T_TMF , .subtype = cpu_to_virtio32(vscsi->vdev,
@@ -680,7 +679,6 @@ static int virtscsi_abort(struct scsi_cmreturn FAILED ;memset (cmd,0 ,sizeof (*cmd)); - cmd->sc = sc; cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req ){ .type =VIRTIO_SCSI_T_TMF , .subtype =VIRTIO_SCSI_T_TMF_ABORT_TASK ,
Greg Kroah-Hartman
maintainerPATCH 159/280 scsi: aacraid: Fix performance issue on logical drives
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sagar Biradar <[email protected]>
commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream.
Fix performance issue where the queue depth for SmartIOC logical volumes is set to 1, and allow the usual logical volume code to be executed
--- drivers/scsi/aacraid/linit.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/scsi/aacraid/linit.c +8 -5
@@ -413,13 +413,16 @@ static int aac_slave_configure(struct scif (chn <AAC_MAX_BUSES && tid <AAC_MAX_TARGETS && aac->sa_firmware) { devtype = aac->hba_map[chn][tid].devtype; -if (devtype ==AAC_DEVTYPE_NATIVE_RAW ) +if (devtype ==AAC_DEVTYPE_NATIVE_RAW ) { depth = aac->hba_map[chn][tid].qd_limit; -else if (devtype ==AAC_DEVTYPE_ARC_RAW ) + set_timeout =1 ; + goto common_config; + } +if (devtype ==AAC_DEVTYPE_ARC_RAW ) { set_qd_dev_type = true; - - set_timeout =1 ; - goto common_config; + set_timeout =1 ; + goto common_config; + } }if (aac->jbod && (sdev->type ==TYPE_DISK ))
Greg Kroah-Hartman
maintainerPATCH 160/280 scsi: sd: Optimal I/O size should be a multiple of physical block size
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin K. Petersen <[email protected]>
commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.
It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 0xFFFF blocks. That looks bogus, especially for a device with a 4096-byte physical block size.
Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's reported physical block size.
To make the sanity checking conditionals more readable--and to facilitate printing warnings--relocate the checking to a helper function. No functional change aside from the printks.
Cc: <[email protected]>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759
--- drivers/scsi/sd.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 50 insertions(+), 9 deletions(-)
drivers/scsi/sd.c +50 -9
@@ -3066,6 +3066,55 @@ static void sd_read_security(struct scsi sdkp->security =1 ; } +/* +* Determine the device's preferred I/O size for reads and writes +* unless the reported value is unreasonably small, large, not a +* multiple of the physical block size, or simply garbage. +*/ +static bool sd_validate_opt_xfer_size (struct scsi_disk *sdkp, +unsigned int dev_max) +{ +struct scsi_device *sdp = sdkp->device; +unsigned int opt_xfer_bytes = +logical_to_bytes (sdp, sdkp->opt_xfer_blocks); + +if (sdkp->opt_xfer_blocks > dev_max) { +sd_first_printk (KERN_WARNING , sdkp, +"Optimal transfer size %u logical blocks " \ +"> dev_max (%u logical blocks)\n" , + sdkp->opt_xfer_blocks, dev_max); +return false; + } + +if (sdkp->opt_xfer_blocks >SD_DEF_XFER_BLOCKS ) { +sd_first_printk (KERN_WARNING , sdkp, +"Optimal transfer size %u logical blocks " \ +"> sd driver limit (%u logical blocks)\n" , + sdkp->opt_xfer_blocks,SD_DEF_XFER_BLOCKS ); +return false; + } + +if (opt_xfer_bytes <PAGE_SIZE ) { +sd_first_printk (KERN_WARNING , sdkp, +"Optimal transfer size %u bytes < " \ +"PAGE_SIZE (%u bytes)\n" , + opt_xfer_bytes, (unsigned int )PAGE_SIZE ); +return false; + } + +if (opt_xfer_bytes & (sdkp->physical_block_size -1 )) { +sd_first_printk (KERN_WARNING , sdkp, +"Optimal transfer size %u bytes not a " \ +"multiple of physical block size (%u bytes)\n" , + opt_xfer_bytes, sdkp->physical_block_size); +return false; + } + +sd_first_printk (KERN_INFO , sdkp,"Optimal transfer size %u bytes\n" , + opt_xfer_bytes); +return true; +} +/** * sd_revalidate_disk - called the first time a new disk is seen, * performs disk spin up, read_capacity, etc.
@@ -3144,15 +3193,7 @@ static int sd_revalidate_disk(struct gen dev_max =min_not_zero (dev_max, sdkp->max_xfer_blocks); q->limits.max_dev_sectors =logical_to_sectors (sdp, dev_max); -/* -* Determine the device's preferred I/O size for reads and writes -* unless the reported value is unreasonably small, large, or -* garbage. -*/ -if (sdkp->opt_xfer_blocks && - sdkp->opt_xfer_blocks <= dev_max && - sdkp->opt_xfer_blocks <=SD_DEF_XFER_BLOCKS && -logical_to_bytes (sdp, sdkp->opt_xfer_blocks) >=PAGE_SIZE ) { +if (sd_validate_opt_xfer_size (sdkp, dev_max)) { q->limits.io_opt =logical_to_bytes (sdp, sdkp->opt_xfer_blocks); rw_max =logical_to_sectors (sdp, sdkp->opt_xfer_blocks); }else
Greg Kroah-Hartman
maintainerPATCH 161/280 scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <[email protected]>
commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.
When using SCSI passthrough in combination with the iSCSI target driver then cmd->t_state_lock may be obtained from interrupt context. Hence, all code that obtains cmd->t_state_lock from thread context must disable interrupts first. This patch avoids that lockdep reports the following:
WARNING: inconsistent lock state
4.18.0-dbg+ #1 Not tainted
--------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes:000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod] {HARDIRQ-ON-W} state was registered at:
lock_acquire+0xd2/0x260 _raw_spin_lock+0x32/0x50 iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod] iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod] iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod] kthread+0x1cf/0x1f0 ret_from_fork+0x24/0x30 irq event stamp: 1281 hardirqs last enabled at (1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160 hardirqs last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0 softirqs last enabled at (1278): [<ffffffff977cd9a1>] lock_sock_nested+0x51/0xc0 softirqs last disabled at (1280): [<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
---- lock(&(&cmd->t_state_lock)->rlock);
<Interrupt>
lock(&(&cmd->t_state_lock)->rlock);
--- drivers/target/iscsi/iscsi_target.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/target/iscsi/iscsi_target.c +2 -2
@@ -4045,9 +4045,9 @@ static void iscsit_release_commands_fromstruct se_cmd *se_cmd = &cmd->se_cmd;if (se_cmd->se_tfo !=NULL ) { -spin_lock (&se_cmd->t_state_lock); +spin_lock_irq (&se_cmd->t_state_lock); se_cmd->transport_state |=CMD_T_FABRIC_STOP ; -spin_unlock (&se_cmd->t_state_lock); +spin_unlock_irq (&se_cmd->t_state_lock); } }spin_unlock_bh (&conn->cmd_lock);
Greg Kroah-Hartman
maintainerPATCH 162/280 scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by firmware
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Himanshu Madhani <[email protected]>
commit ec322937a7f152d68755dc8316523bf6f831b48f upstream.
This patch fixes LUN discovery when loop ID is not yet assigned by the firmware during driver load/sg_reset operations. Driver will now search for new loop id before retrying login.
--- drivers/scsi/qla2xxx/qla_init.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +8 -5
@@ -643,11 +643,14 @@ static void qla24xx_handle_gnl_done_evenbreak ;case DSC_LS_PORT_UNAVAIL :default : -if (fcport->loop_id !=FC_NO_LOOP_ID ) -qla2x00_clear_loop_id (fcport); - - fcport->loop_id = loop_id; - fcport->fw_login_state =DSC_LS_PORT_UNAVAIL ; +if (fcport->loop_id ==FC_NO_LOOP_ID ) { +qla2x00_find_new_loop_id (vha, fcport); + fcport->fw_login_state = +DSC_LS_PORT_UNAVAIL ; + } +ql_dbg (ql_dbg_disc, vha,0x20e5 , +"%s %d %8phC\n" , __func__, __LINE__, + fcport->port_name);qla24xx_fcport_handle_login (vha, fcport);break ; }
Greg Kroah-Hartman
maintainerPATCH 163/280 fs/devpts: always delete dcache dentry-s in dput()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Varad Gautam <[email protected]>
commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.
d_delete only unhashes an entry if it is reached with dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
more pty driver interface cleanups"), d_delete was called on a dentry from devpts_pty_kill with two references held, which would trigger the unhashing, and the subsequent dputs would release it.
Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second reference from d_find_alias, and the d_delete call left the dentries still on the hashed list without actually ever being dropped from dcache before explicit cleanup. This causes the number of negative dentries for devpts to pile up, and an ls /dev/pts invocation can take seconds to return.
Provide always_delete_dentry() from simple_dentry_operations as .d_delete for devpts, to make the dentry be dropped from dcache.
Without this cleanup, the number of dentries in /dev/pts/ can be grown arbitrarily as:
python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'
A systemtap probe on dcache_readdir to count d_subdirs shows this count to increase with each pty spawn invocation above:
probe kernel.function("dcache_readdir") {
subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
p = subdirs;
p = @cast(p, "list_head")->next;
i = 0
while (p != subdirs) {
p = @cast(p, "list_head")->next;
i = i+1;
}
printf("number of dentries: %d\n", i);
}--- fs/devpts/inode.c | 1 + 1 file changed, 1 insertion(+)
fs/devpts/inode.c +1 -0
@@ -455,6 +455,7 @@ devpts_fill_super(struct super_block *s, s->s_blocksize_bits =10 ; s->s_magic =DEVPTS_SUPER_MAGIC ; s->s_op = &devpts_sops; + s->s_d_op = &simple_dentry_operations; s->s_time_gran =1 ; error = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 164/280 splice: dont merge into linked buffers
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.
Before this patch, it was possible for two pipes to affect each other after data had been transferred between them with tee():
============
$ cat tee_test.c
int main(void) {
int pipe_a[2];
if (pipe(pipe_a)) err(1, "pipe");
int pipe_b[2];
if (pipe(pipe_b)) err(1, "pipe");
if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write"); if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee"); if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
char buf[5];
if (read(pipe_a[0], buf, 4) != 4) err(1, "read"); buf[4] = 0;
printf("got back: '%s'\n", buf);
}
$ gcc -o tee_test tee_test.c $ ./tee_test got back: 'abxx' $ ============
As suggested by Al Viro, fix it by creating a separate type for non-mergeable pipe buffers, then changing the types of buffers in splice_pipe_to_pipe() and link_pipe().
--- fs/pipe.c | 14 ++++++++++++++ fs/splice.c | 4 ++++ include/linux/pipe_fs_i.h | 1 + 3 files changed, 19 insertions(+)
fs/pipe.c +14 -0
@@ -234,6 +234,14 @@ static const struct pipe_buf_operations .get = generic_pipe_buf_get, }; +static const struct pipe_buf_operations anon_pipe_buf_nomerge_ops = { + .can_merge =0 , + .confirm = generic_pipe_buf_confirm, + .release = anon_pipe_buf_release, + .steal = anon_pipe_buf_steal, + .get = generic_pipe_buf_get, +}; +static const struct pipe_buf_operations packet_pipe_buf_ops = { .can_merge =0 , .confirm = generic_pipe_buf_confirm,
@@ -242,6 +250,12 @@ static const struct pipe_buf_operations .get = generic_pipe_buf_get, }; +void pipe_buf_mark_unmergeable (struct pipe_buffer *buf) +{ +if (buf->ops == &anon_pipe_buf_ops) + buf->ops = &anon_pipe_buf_nomerge_ops; +} +static ssize_t pipe_read (struct kiocb *iocb,struct iov_iter *to) {
fs/splice.c +4 -0
@@ -1593,6 +1593,8 @@ retry:*/ obuf->flags &= ~PIPE_BUF_FLAG_GIFT ; +pipe_buf_mark_unmergeable (obuf); + obuf->len = len; opipe->nrbufs++; ibuf->offset += obuf->len;
@@ -1667,6 +1669,8 @@ static int link_pipe(struct pipe_inode_i*/ obuf->flags &= ~PIPE_BUF_FLAG_GIFT ; +pipe_buf_mark_unmergeable (obuf); +if (obuf->len > len) obuf->len = len;
include/linux/pipe_fs_i.h +1 -0
@@ -182,6 +182,7 @@ void generic_pipe_buf_get(struct pipe_inint generic_pipe_buf_confirm (struct pipe_inode_info *,struct pipe_buffer *);int generic_pipe_buf_steal (struct pipe_inode_info *,struct pipe_buffer *);void generic_pipe_buf_release (struct pipe_inode_info *,struct pipe_buffer *); +void pipe_buf_mark_unmergeable (struct pipe_buffer *buf);extern const struct pipe_buf_operations nosteal_pipe_buf_ops;
Greg Kroah-Hartman
maintainerPATCH 165/280 ovl: During copy up, first copy up data and then xattrs
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Goyal <[email protected]>
commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream.
If a file with capability set (and hence security.capability xattr) is written kernel clears security.capability xattr. For overlay, during file copy up if xattrs are copied up first and then data is, copied up. This means data copy up will result in clearing of security.capability xattr file on lower has. And this can result into surprises. If a lower file has CAP_SETUID, then it should not be cleared over copy up (if nothing was actually written to file).
This also creates problems with chown logic where it first copies up file and then tries to clear setuid bit. But by that time security.capability xattr is already gone (due to data copy up), and caller gets -ENODATA. This has been reported by Giuseppe here.
https://github.com/containers/libpod/issues/2015#issuecomment-447824842
Fix this by copying up data first and then metadta. This is a regression which has been introduced by my commit as part of metadata only copy up patches.
TODO: There will be some corner cases where a file is copied up metadata only and later data copy up happens and that will clear security.capability xattr. Something needs to be done about that too.
--- fs/overlayfs/copy_up.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-)
fs/overlayfs/copy_up.c +18 -13
@@ -501,6 +501,24 @@ static int ovl_copy_up_inode(struct ovl_ {int err; +/* +* Copy up data first and then xattrs. Writing data after +* xattrs will remove security.capability xattr automatically. +*/ +if (S_ISREG (c->stat.mode) && !c->metacopy) { +struct path upperpath, datapath; + +ovl_path_upper (c->dentry, &upperpath); +if (WARN_ON (upperpath.dentry !=NULL )) +return -EIO ; + upperpath.dentry = temp; + +ovl_path_lowerdata (c->dentry, &datapath); + err =ovl_copy_up_data (&datapath, &upperpath, c->stat.size); +if (err) +return err; + } + err =ovl_copy_xattr (c->lowerpath.dentry, temp);if (err)return err;
@@ -517,19 +535,6 @@ static int ovl_copy_up_inode(struct ovl_if (err)return err; } - -if (S_ISREG (c->stat.mode) && !c->metacopy) { -struct path upperpath, datapath; - -ovl_path_upper (c->dentry, &upperpath); -BUG_ON (upperpath.dentry !=NULL ); - upperpath.dentry = temp; - -ovl_path_lowerdata (c->dentry, &datapath); - err =ovl_copy_up_data (&datapath, &upperpath, c->stat.size); -if (err) -return err; - }if (c->metacopy) { err = ovl_check_setxattr(c->dentry, temp, OVL_XATTR_METACOPY,
Greg Kroah-Hartman
maintainerPATCH 166/280 ovl: Do not lose security.capability xattr over metadata file copy-up
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Goyal <[email protected]>
commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream.
If a file has been copied up metadata only, and later data is copied up, upper loses any security.capability xattr it has (underlying filesystem clears it as upon file write).
Quoted 1 line
From a user's point of view, this is just a file copy-up and that should
not result in losing security.capability xattr. Hence, before data copy up, save security.capability xattr (if any) and restore it on upper after data copy up is complete.
--- fs/overlayfs/copy_up.c | 28 ++++++++++++++++++++++- fs/overlayfs/overlayfs.h | 2 + fs/overlayfs/util.c | 55 +++++++++++++++++++++++++++++------------------ 3 files changed, 63 insertions(+), 22 deletions(-)
fs/overlayfs/copy_up.c +26 -2
@@ -711,6 +711,8 @@ static int ovl_copy_up_meta_inode_data(s {struct path upperpath, datapath;int err; +char *capability =NULL ; +ssize_t uninitialized_var (cap_size );ovl_path_upper (c->dentry, &upperpath);if (WARN_ON (upperpath.dentry ==NULL ))
@@ -720,15 +722,37 @@ static int ovl_copy_up_meta_inode_data(sif (WARN_ON (datapath.dentry ==NULL ))return -EIO ; +if (c->stat.size) { + err = cap_size =ovl_getxattr (upperpath.dentry,XATTR_NAME_CAPS , + &capability,0 ); +if (err <0 && err != -ENODATA ) + goto out; + } + err =ovl_copy_up_data (&datapath, &upperpath, c->stat.size);if (err) -return err; + goto out_free; + +/* +* Writing to upper file will clear security.capability xattr. We +* don't want that to happen for normal copy-up operation. +*/ +if (capability) { + err =ovl_do_setxattr (upperpath.dentry,XATTR_NAME_CAPS , + capability, cap_size,0 ); +if (err) + goto out_free; + } + err =vfs_removexattr (upperpath.dentry,OVL_XATTR_METACOPY );if (err) -return err; + goto out_free;ovl_set_upperdata (d_inode (c->dentry)); +out_free: +kfree (capability); +out:return err; }
fs/overlayfs/overlayfs.h +2 -0
@@ -277,6 +277,8 @@ int ovl_lock_rename_workdir(struct dentrint ovl_check_metacopy_xattr (struct dentry *dentry);bool ovl_is_metacopy_dentry (struct dentry *dentry);char *ovl_get_redirect_xattr (struct dentry *dentry,int padding); +ssize_t ovl_getxattr (struct dentry *dentry,char *name,char **value, +size_t padding);static inline bool ovl_is_impuredir (struct dentry *dentry) {
fs/overlayfs/util.c +35 -20
78 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 167/280 m68k: Add -ffreestanding to CFLAGS
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Finn Thain <[email protected]>
commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':block/partitions/ldm.c:153: undefined reference to `strcmp'
This is caused by a new optimization which effectively replaces a strncmp() call with a strcmp() call. This affects a number of strncmp() call sites in the kernel.
The entire class of optimizations is avoided with -fno-builtin, which gets enabled by -ffreestanding. This may avoid possible future build failures in case new optimizations appear in future compilers.
I haven't done any performance measurements with this patch but I did count the function calls in a defconfig build. For example, there are now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the other libc functions is smaller.
If this harms performance we can tackle that regression by optimizing the call sites, ideally using semantic patches. That way, clang and ICC builds might benfit too.
Cc: [email protected]
Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
--- arch/m68k/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/m68k/Makefile +4 -1
@@ -58,7 +58,10 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-o cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) KBUILD_AFLAGS += $(cpuflags-y) -KBUILD_CFLAGS += $(cpuflags-y) -pipe +KBUILD_CFLAGS += $(cpuflags-y) + +KBUILD_CFLAGS += -pipe -ffreestanding + ifdef CONFIG_MMU # without -fno-strength-reduce the 53c7xx.c driver fails ;-( KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
Greg Kroah-Hartman
maintainerPATCH 168/280 Btrfs: setup a nofs context for memory allocation at btrfs_create_tree()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream.
We are holding a transaction handle when creating a tree, therefore we can not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is triggered by the allocation, therefore setup a nofs context.
--- fs/btrfs/disk-io.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/btrfs/disk-io.c +8 -0
@@ -17,6 +17,7 @@#include <linux/semaphore.h> #include <linux/error-injection.h> #include <linux/crc32c.h> +#include <linux/sched/mm.h> #include <asm/unaligned.h> #include "ctree.h" #include "disk-io.h"
@@ -1236,10 +1237,17 @@ struct btrfs_root *btrfs_create_tree(strstruct btrfs_root *tree_root = fs_info->tree_root;struct btrfs_root *root;struct btrfs_key key; +unsigned int nofs_flag;int ret =0 ;uuid_le uuid =NULL_UUID_LE ; +/* +* We're holding a transaction handle, so use a NOFS memory allocation +* context to avoid deadlock if reclaim happens. +*/ + nofs_flag =memalloc_nofs_save (); root =btrfs_alloc_root (fs_info,GFP_KERNEL ); +memalloc_nofs_restore (nofs_flag);if (!root)return ERR_PTR (-ENOMEM );
Greg Kroah-Hartman
maintainerPATCH 169/280 Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit a0873490660246db587849a9e172f2b7b21fa88a upstream.
We are holding a transaction handle when setting an acl, therefore we can not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock if reclaim is triggered by the allocation, therefore setup a nofs context.
--- fs/btrfs/acl.c | 9 +++++++++ 1 file changed, 9 insertions(+)
fs/btrfs/acl.c +9 -0
@@ -9,6 +9,7 @@#include <linux/posix_acl_xattr.h> #include <linux/posix_acl.h> #include <linux/sched.h> +#include <linux/sched/mm.h> #include <linux/slab.h> #include "ctree.h"
@@ -72,8 +73,16 @@ static int __btrfs_set_acl(struct btrfs_ }if (acl) { +unsigned int nofs_flag; + size =posix_acl_xattr_size (acl->a_count); +/* +* We're holding a transaction handle, so use a NOFS memory +* allocation context to avoid deadlock if reclaim happens. +*/ + nofs_flag =memalloc_nofs_save (); value =kmalloc (size,GFP_KERNEL ); +memalloc_nofs_restore (nofs_flag);if (!value) { ret = -ENOMEM ; goto out;
Greg Kroah-Hartman
maintainerPATCH 170/280 btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Thumshirn <[email protected]>
commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.
We recently had a customer issue with a corrupted filesystem. When trying to mount this image btrfs panicked with a division by zero in calc_stripe_length().
The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length() takes this value and divides it by the number of copies the RAID profile is expected to have to calculate the amount of data stripes. As a DUP profile is expected to have 2 copies this division resulted in 1/2 = 0. Later then the 'data_stripes' variable is used as a divisor in the stripe length calculation which results in a division by 0 and thus a kernel panic.
When encountering a filesystem with a DUP block group and a 'num_stripes' value unequal to 2, refuse mounting as the image is corrupted and will lead to unexpected behaviour.
Code inspection showed a RAID1 block group has the same issues.
--- fs/btrfs/volumes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/btrfs/volumes.c +2 -2
@@ -6425,10 +6425,10 @@ static int btrfs_check_chunk_valid(struc }if ((type &BTRFS_BLOCK_GROUP_RAID10 && sub_stripes !=2 ) || - (type &BTRFS_BLOCK_GROUP_RAID1 && num_stripes <1 ) || + (type &BTRFS_BLOCK_GROUP_RAID1 && num_stripes !=2 ) || (type &BTRFS_BLOCK_GROUP_RAID5 && num_stripes <2 ) || (type &BTRFS_BLOCK_GROUP_RAID6 && num_stripes <3 ) || - (type &BTRFS_BLOCK_GROUP_DUP && num_stripes >2 ) || + (type &BTRFS_BLOCK_GROUP_DUP && num_stripes !=2 ) || ((type &BTRFS_BLOCK_GROUP_PROFILE_MASK ) ==0 && num_stripes !=1 )) { btrfs_err(fs_info,
Greg Kroah-Hartman
maintainerPATCH 171/280 Btrfs: fix corruption reading shared and compressed extents after hole punching
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that are shared within the same file and they are consecutive, this got fixed by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents"). However there was a case that was missing in those fixes, which is when the shared and compressed extents are referenced with a non-zero offset. The following shell script creates a reproducer for this issue:
#!/bin/bash
mkfs.btrfs -f /dev/sdc &> /dev/null
mount -o compress /dev/sdc /mnt/sdc
# Create a file with 3 consecutive compressed extents, each has an
# uncompressed size of 128Kb and a compressed size of 4Kb.
for ((i = 1; i <= 3; i++)); do
head -c 4096 /dev/zero
for ((j = 1; j <= 31; j++)); do
head -c 4096 /dev/zero | tr '\0' "\377"
done
done > /mnt/sdc/foobar
syncecho "Digest after file creation: $(md5sum /mnt/sdc/foobar)"
# Clone the first extent into offsets 128K and 256K. xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar sync
echo "Digest after cloning: $(md5sum /mnt/sdc/foobar)"
# Punch holes into the regions that are already full of zeroes. xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
sync
echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)" echo "Dropping page cache..." sysctl -q vm.drop_caches=1 echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"
umount /dev/sdc
When running the script we get the following output:
Digest after file creation: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
linked 131072/131072 bytes at offset 131072
128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec) linked 131072/131072 bytes at offset 262144
128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
Digest after cloning: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar Digest after hole punching: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
Dropping page cache...
Digest after hole punching: fba694ae8664ed0c2e9ff8937e7f1484 /mnt/sdc/foobar
This happens because after reading all the pages of the extent in the range from 128K to 256K for example, we read the hole at offset 256K and then when reading the page at offset 260K we don't submit the existing bio, which is responsible for filling all the page in the range 128K to 256K only, therefore adding the pages from range 260K to 384K to the existing bio and submitting it after iterating over the entire range. Once the bio completes, the uncompressed data fills only the pages in the range 128K to 256K because there's no more data read from disk, leaving the pages in the range 260K to 384K unfilled. It is just a slightly different variant of what was solved by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents").
Fix this by forcing a bio submit, during readpages(), whenever we find a compressed extent map for a page that is different from the extent map for the previous page or has a different starting offset (in case it's the same compressed extent), instead of the extent map's original start offset.
A test case for fstests follows soon.
--- fs/btrfs/extent_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/btrfs/extent_io.c +2 -2
@@ -3002,11 +3002,11 @@ static int __do_readpage(struct extent_i*/ if (test_bit (EXTENT_FLAG_COMPRESSED , &em->flags) && prev_em_start && *prev_em_start != (u64)-1 && - *prev_em_start != em->orig_start) + *prev_em_start != em->start) force_bio_submit = true;if (prev_em_start) - *prev_em_start = em->orig_start; + *prev_em_start = em->start;free_extent_map (em); em =NULL ;
Greg Kroah-Hartman
maintainerPATCH 172/280 soc: qcom: rpmh: Avoid accessing freed memory from batch API
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Boyd <[email protected]>
commit baef1c90aac7e5bf13f0360a3b334825a23d31a1 upstream.
Using the batch API from the interconnect driver sometimes leads to a KASAN error due to an access to freed memory. This is easier to trigger with threadirqs on the kernel commandline.
BUG: KASAN: use-after-free in rpmh_tx_done+0x114/0x12c
Read of size 1 at addr fffffff51414ad84 by task irq/110-apps_rs/57
CPU: 0 PID: 57 Comm: irq/110-apps_rs Tainted: G W 4.19.10 #72
Call trace:
dump_backtrace+0x0/0x2f8
show_stack+0x20/0x2c
__dump_stack+0x20/0x28
dump_stack+0xcc/0x10c
print_address_description+0x74/0x240
kasan_report+0x250/0x26c
__asan_report_load1_noabort+0x20/0x2c
rpmh_tx_done+0x114/0x12c
tcs_tx_done+0x450/0x768
irq_forced_thread_fn+0x58/0x9c
irq_thread+0x120/0x1dc
kthread+0x248/0x260
ret_from_fork+0x10/0x18
Allocated by task 385:
kasan_kmalloc+0xac/0x148
__kmalloc+0x170/0x1e4
rpmh_write_batch+0x174/0x540
qcom_icc_set+0x8dc/0x9ac
icc_set+0x288/0x2e8
a6xx_gmu_stop+0x320/0x3c0
a6xx_pm_suspend+0x108/0x124
adreno_suspend+0x50/0x60
pm_generic_runtime_suspend+0x60/0x78
__rpm_callback+0x214/0x32c
rpm_callback+0x54/0x184
rpm_suspend+0x3f8/0xa90
pm_runtime_work+0xb4/0x178
process_one_work+0x544/0xbc0
worker_thread+0x514/0x7d0
kthread+0x248/0x260
ret_from_fork+0x10/0x18
Freed by task 385:
__kasan_slab_free+0x12c/0x1e0
kasan_slab_free+0x10/0x1c
kfree+0x134/0x588
rpmh_write_batch+0x49c/0x540
qcom_icc_set+0x8dc/0x9ac
icc_set+0x288/0x2e8
a6xx_gmu_stop+0x320/0x3c0
a6xx_pm_suspend+0x108/0x124
adreno_suspend+0x50/0x60
cr50_spi spi5.0: SPI transfer timed out
pm_generic_runtime_suspend+0x60/0x78
__rpm_callback+0x214/0x32c
rpm_callback+0x54/0x184
rpm_suspend+0x3f8/0xa90
pm_runtime_work+0xb4/0x178
process_one_work+0x544/0xbc0
worker_thread+0x514/0x7d0
kthread+0x248/0x260
ret_from_fork+0x10/0x18
The buggy address belongs to the object at fffffff51414ac80
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 260 bytes inside of
512-byte region [fffffff51414ac80, fffffff51414ae80)
The buggy address belongs to the page:
page:ffffffbfd4505200 count:1 mapcount:0 mapping:fffffff51e00c680 index:0x0 compound_mapcount: 0
flags: 0x4000000000008100(slab|head)
raw: 4000000000008100 ffffffbfd4529008 ffffffbfd44f9208 fffffff51e00c680
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
fffffff51414ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
fffffff51414ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>fffffff51414ad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
fffffff51414ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
fffffff51414ae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fcThe batch API sets the same completion for each rpmh message that's sent and then loops through all the messages and waits for that single completion declared on the stack to be completed before returning from the function and freeing the message structures. Unfortunately, some messages may still be in process and 'stuck' in the TCS. At some later point, the tcs_tx_done() interrupt will run and try to process messages that have already been freed at the end of rpmh_write_batch(). This will in turn access the 'needs_free' member of the rpmh_request structure and cause KASAN to complain. Furthermore, if there's a message that's completed in rpmh_tx_done() and freed immediately after the complete() call is made we'll be racing with potentially freed memory when accessing the 'needs_free' member:
CPU0 CPU1 ---- ---- rpmh_tx_done() complete(&compl) wait_for_completion(&compl) kfree(rpm_msg) if (rpm_msg->needs_free) <KASAN warning splat>
Let's fix this by allocating a chunk of completions for each message and waiting for all of them to be completed before returning from the batch API. Alternatively, we could wait for the last message in the batch, but that may be a more complicated change because it looks like tcs_tx_done() just iterates through the indices of the queue and completes each message instead of tracking the last inserted message and completing that first.
--- drivers/soc/qcom/rpmh.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-)
drivers/soc/qcom/rpmh.c +21 -13
@@ -80,6 +80,7 @@ void rpmh_tx_done(const struct tcs_reque struct rpmh_request *rpm_msg = container_of(msg, struct rpmh_request, msg);struct completion *compl = rpm_msg->completion; +bool free = rpm_msg->needs_free; rpm_msg->err = r;
@@ -94,7 +95,7 @@ void rpmh_tx_done(const struct tcs_requecomplete (compl); exit: -if (rpm_msg->needs_free) +if (free)kfree (rpm_msg); }
@@ -348,11 +349,12 @@ int rpmh_write_batch(const struct device {struct batch_cache_req *req;struct rpmh_request *rpm_msgs; -DECLARE_COMPLETION_ONSTACK (compl); +struct completion *compls;struct rpmh_ctrlr *ctrlr =get_rpmh_ctrlr (dev);unsigned long time_left;int count =0 ; -int ret, i, j; +int ret, i; +void *ptr;if (!cmd || !n)return -EINVAL ;
@@ -362,10 +364,15 @@ int rpmh_write_batch(const struct deviceif (!count)return -EINVAL ; - req =kzalloc (sizeof (*req) + count *sizeof (req->rpm_msgs[0 ]), + ptr =kzalloc (sizeof (*req) + + count * (sizeof (req->rpm_msgs[0 ]) +sizeof (*compls)),GFP_ATOMIC ); -if (!req) +if (!ptr)return -ENOMEM ; + + req = ptr; + compls = ptr +sizeof (*req) + count *sizeof (*rpm_msgs); + req->count = count; rpm_msgs = req->rpm_msgs;
@@ -380,25 +387,26 @@ int rpmh_write_batch(const struct device }for (i =0 ; i < count; i++) { - rpm_msgs[i].completion = &compl; +struct completion *compl = &compls[i]; + +init_completion (compl); + rpm_msgs[i].completion = compl; ret =rpmh_rsc_send_data (ctrlr_to_drv (ctrlr), &rpm_msgs[i].msg);if (ret) {pr_err ("Error(%d) sending RPMH message addr=%#x\n" , ret, rpm_msgs[i].msg.cmds[0 ].addr); -for (j = i; j < count; j++) -rpmh_tx_done (&rpm_msgs[j].msg, ret);break ; } } time_left =RPMH_TIMEOUT_MS ; -for (i =0 ; i < count; i++) { - time_left =wait_for_completion_timeout (&compl, time_left); +while (i--) { + time_left =wait_for_completion_timeout (&compls[i], time_left);if (!time_left) {/* * Better hope they never finish because they'll signal -* the completion on our stack and that's bad once -* we've returned from the function. +* the completion that we're going to free once +* we've returned from this function. */ WARN_ON (1 ); ret = -ETIMEDOUT ;
@@ -407,7 +415,7 @@ int rpmh_write_batch(const struct device } exit: -kfree (req); +kfree (ptr);return ret; }
Greg Kroah-Hartman
maintainerPATCH 173/280 libertas_tf: dont set URB_ZERO_PACKET on IN USB transfer
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lubomir Rintel <[email protected]>
commit 607076a904c435f2677fadaadd4af546279db68b upstream.
It doesn't make sense and the USB core warns on each submit of such URB, easily flooding the message buffer with tracebacks.
Analogous issue was fixed in regular libertas driver in commit 6528d8804780 ("libertas: don't set URB_ZERO_PACKET on IN USB transfer").
--- drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 -- 1 file changed, 2 deletions(-)
drivers/net/wireless/marvell/libertas_tf/if_usb.c +0 -2
@@ -433,8 +433,6 @@ static int __if_usb_submit_rx_urb(structskb_tail_pointer (skb), MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn, cardp); - cardp->rx_urb->transfer_flags |=URB_ZERO_PACKET ; -lbtf_deb_usb2 (&cardp->udev->dev,"Pointer for rx_urb %p\n" , cardp->rx_urb); ret =usb_submit_urb (cardp->rx_urb,GFP_ATOMIC );
Greg Kroah-Hartman
maintainerPATCH 174/280 irqchip/gic-v3-its: Avoid parsing _indirect_ twice for Device table
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zenghui Yu <[email protected]>
commit 8d565748b6035eeda18895c213396a4c9fac6a4c upstream.
In current logic, its_parse_indirect_baser() will be invoked twice when allocating Device tables. Add a *break* to omit the unnecessary and annoying (might be ...) invoking.
--- drivers/irqchip/irq-gic-v3-its.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/irqchip/irq-gic-v3-its.c +2 -0
@@ -1893,6 +1893,8 @@ static int its_alloc_tables(struct its_n indirect =its_parse_indirect_baser (its, baser, psz, &order, its->device_ids); +break ; +case GITS_BASER_TYPE_VCPU : indirect = its_parse_indirect_baser(its, baser, psz, &order,
Greg Kroah-Hartman
maintainerPATCH 175/280 irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doug Berger <[email protected]>
commit 33517881ede742107f416533b8c3e4abc56763da upstream.
Using the irq_gc_lock/irq_gc_unlock functions in the suspend and resume functions creates the opportunity for a deadlock during suspend, resume, and shutdown. Using the irq_gc_lock_irqsave/ irq_gc_unlock_irqrestore variants prevents this possible deadlock.
--- drivers/irqchip/irq-brcmstb-l2.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/irqchip/irq-brcmstb-l2.c +6 -4
@@ -129,8 +129,9 @@ static void brcmstb_l2_intc_suspend(strustruct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct irq_chip_type *ct =irq_data_get_chip_type (d);struct brcmstb_l2_intc_data *b = gc->private; +unsigned long flags; -irq_gc_lock (gc); +irq_gc_lock_irqsave (gc, flags);/* Save the current mask */ b->saved_mask =irq_reg_readl (gc, ct->regs.mask);
@@ -139,7 +140,7 @@ static void brcmstb_l2_intc_suspend(struirq_reg_writel (gc, ~gc->wake_active, ct->regs.disable);irq_reg_writel (gc, gc->wake_active, ct->regs.enable); } -irq_gc_unlock (gc); +irq_gc_unlock_irqrestore (gc, flags); }static void brcmstb_l2_intc_resume (struct irq_data *d)
@@ -147,8 +148,9 @@ static void brcmstb_l2_intc_resume(strucstruct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct irq_chip_type *ct =irq_data_get_chip_type (d);struct brcmstb_l2_intc_data *b = gc->private; +unsigned long flags; -irq_gc_lock (gc); +irq_gc_lock_irqsave (gc, flags);if (ct->chip.irq_ack) {/* Clear unmasked non-wakeup interrupts */ irq_reg_writel(gc, ~b->saved_mask & ~gc->wake_active,
@@ -158,7 +160,7 @@ static void brcmstb_l2_intc_resume(struc/* Restore the saved mask */ irq_reg_writel (gc, b->saved_mask, ct->regs.disable);irq_reg_writel (gc, ~b->saved_mask, ct->regs.enable); -irq_gc_unlock (gc); +irq_gc_unlock_irqrestore (gc, flags); } static int __init brcmstb_l2_intc_of_init(struct device_node *np,
Greg Kroah-Hartman
maintainerPATCH 176/280 x86/kprobes: Prohibit probing on optprobe template code
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu <[email protected]>
commit 0192e6535ebe9af68614198ced4fd6d37b778ebf upstream.
Prohibit probing on optprobe template code, since it is not a code but a template instruction sequence. If we modify this template, copied template must be broken.
--- arch/x86/kernel/kprobes/opt.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/kernel/kprobes/opt.c +5 -0
@@ -141,6 +141,11 @@ asm (void optprobe_template_func (void );STACK_FRAME_NON_STANDARD (optprobe_template_func); +NOKPROBE_SYMBOL (optprobe_template_func); +NOKPROBE_SYMBOL (optprobe_template_entry); +NOKPROBE_SYMBOL (optprobe_template_val); +NOKPROBE_SYMBOL (optprobe_template_call); +NOKPROBE_SYMBOL (optprobe_template_end);#define TMPL_MOVE_IDX \ ((long)optprobe_template_val - (long)optprobe_template_entry)
Greg Kroah-Hartman
maintainerPATCH 177/280 cpufreq: kryo: Release OPP tables on module removal
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <[email protected]>
commit 0334906c06967142c8805fbe88acf787f65d3d26 upstream.
Commit 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit") made it possible to build the kryo cpufreq driver as a module, but it failed to release all the resources, i.e. OPP tables, when the module is unloaded.
This patch fixes it by releasing the OPP tables, by calling dev_pm_opp_put_supported_hw() for them, from the qcom_cpufreq_kryo_remove() routine. The array of pointers to the OPP tables is also allocated dynamically now in qcom_cpufreq_kryo_probe(), as the pointers will be required while releasing the resources.
Compile tested only.
--- drivers/cpufreq/qcom-cpufreq-kryo.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
drivers/cpufreq/qcom-cpufreq-kryo.c +18 -2
@@ -75,7 +75,7 @@ static enum _msm8996_version qcom_cpufrestatic int qcom_cpufreq_kryo_probe (struct platform_device *pdev) { -struct opp_table *opp_tables[NR_CPUS ] = {0 }; +struct opp_table **opp_tables;enum _msm8996_version msm8996_version;struct nvmem_cell *speedbin_nvmem;struct device_node *np;
@@ -133,6 +133,10 @@ static int qcom_cpufreq_kryo_probe(struc }kfree (speedbin); + opp_tables =kcalloc (num_possible_cpus (),sizeof (*opp_tables),GFP_KERNEL ); +if (!opp_tables) +return -ENOMEM ; +for_each_possible_cpu (cpu) { cpu_dev =get_cpu_device (cpu);if (NULL == cpu_dev) {
@@ -151,8 +155,10 @@ static int qcom_cpufreq_kryo_probe(struc cpufreq_dt_pdev =platform_device_register_simple ("cpufreq-dt" ,-1 ,NULL ,0 ); -if (!IS_ERR (cpufreq_dt_pdev)) +if (!IS_ERR (cpufreq_dt_pdev)) { +platform_set_drvdata (pdev, opp_tables);return 0 ; + } ret =PTR_ERR (cpufreq_dt_pdev);dev_err (cpu_dev,"Failed to register platform device\n" );
@@ -163,13 +169,23 @@ free_opp:break ;dev_pm_opp_put_supported_hw (opp_tables[cpu]); } +kfree (opp_tables);return ret; }static int qcom_cpufreq_kryo_remove (struct platform_device *pdev) { +struct opp_table **opp_tables =platform_get_drvdata (pdev); +unsigned int cpu; +platform_device_unregister (cpufreq_dt_pdev); + +for_each_possible_cpu (cpu) +dev_pm_opp_put_supported_hw (opp_tables[cpu]); + +kfree (opp_tables); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 178/280 cpufreq: tegra124: add missing of_node_put()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yangtao Li <[email protected]>
commit 446fae2bb5395f3028d8e3aae1508737e5a72ea1 upstream.
of_cpu_device_node_get() will increase the refcount of device_node, it is necessary to call of_node_put() at the end to release the refcount.
--- drivers/cpufreq/tegra124-cpufreq.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/cpufreq/tegra124-cpufreq.c +2 -0
@@ -134,6 +134,8 @@ static int tegra124_cpufreq_probe(structplatform_set_drvdata (pdev, priv); +of_node_put (np); +return 0 ; out_switch_to_pllx:
Greg Kroah-Hartman
maintainerPATCH 179/280 cpufreq: pxa2xx: remove incorrect __init annotation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 9505b98ccddc454008ca7efff90044e3e857c827 upstream.
pxa_cpufreq_init_voltages() is marked __init but usually inlined into the non-__init pxa_cpufreq_init() function. When building with clang, it can stay as a standalone function in a discarded section, and produce this warning:
WARNING: vmlinux.o(.text+0x616a00): Section mismatch in reference from the function pxa_cpufreq_init() to the function .init.text:pxa_cpufreq_init_voltages() The function pxa_cpufreq_init() references
the function __init pxa_cpufreq_init_voltages().
This is often because pxa_cpufreq_init lacks a __init
annotation or the annotation of pxa_cpufreq_init_voltages is wrong.
--- drivers/cpufreq/pxa2xx-cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/cpufreq/pxa2xx-cpufreq.c +2 -2
@@ -143,7 +143,7 @@ static int pxa_cpufreq_change_voltage(coreturn ret; } -static void __init pxa_cpufreq_init_voltages (void ) +static void pxa_cpufreq_init_voltages (void ) { vcc_core =regulator_get (NULL ,"vcc_core" );if (IS_ERR (vcc_core)) {
@@ -159,7 +159,7 @@ static int pxa_cpufreq_change_voltage(coreturn 0 ; } -static void __init pxa_cpufreq_init_voltages (void ) { } +static void pxa_cpufreq_init_voltages (void ) { }#endif static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
Greg Kroah-Hartman
maintainerPATCH 180/280 ext4: fix check of inode in swap_inode_boot_loader
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: yangerkun <[email protected]>
commit 67a11611e1a5211f6569044fbf8150875764d1d0 upstream.
Before really do swap between inode and boot inode, something need to check to avoid invalid or not permitted operation, like does this inode has inline data. But the condition check should be protected by inode lock to avoid change while swapping. Also some other condition will not change between swapping, but there has no problem to do this under inode lock.
--- fs/ext4/ioctl.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-)
fs/ext4/ioctl.c +13 -9
@@ -116,15 +116,6 @@ static long swap_inode_boot_loader(strucstruct inode *inode_bl;struct ext4_inode_info *ei_bl; -if (inode->i_nlink !=1 || !S_ISREG (inode->i_mode) || -IS_SWAPFILE (inode) ||IS_ENCRYPTED (inode) || -ext4_has_inline_data (inode)) -return -EINVAL ; - -if (IS_RDONLY (inode) ||IS_APPEND (inode) ||IS_IMMUTABLE (inode) || - !inode_owner_or_capable (inode) || !capable (CAP_SYS_ADMIN )) -return -EPERM ; - inode_bl =ext4_iget (sb,EXT4_BOOT_LOADER_INO ,EXT4_IGET_SPECIAL );if (IS_ERR (inode_bl))return PTR_ERR (inode_bl);
@@ -137,6 +128,19 @@ static long swap_inode_boot_loader(struc* that only 1 swap_inode_boot_loader is running. */ lock_two_nondirectories (inode, inode_bl); +if (inode->i_nlink !=1 || !S_ISREG (inode->i_mode) || +IS_SWAPFILE (inode) ||IS_ENCRYPTED (inode) || +ext4_has_inline_data (inode)) { + err = -EINVAL ; + goto journal_err_out; + } + +if (IS_RDONLY (inode) ||IS_APPEND (inode) ||IS_IMMUTABLE (inode) || + !inode_owner_or_capable (inode) || !capable (CAP_SYS_ADMIN )) { + err = -EPERM ; + goto journal_err_out; + } +/* Wait for all existing dio workers */ inode_dio_wait (inode);inode_dio_wait (inode_bl);
Greg Kroah-Hartman
maintainerPATCH 181/280 ext4: cleanup pagecache before swap i_data
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: yangerkun <[email protected]>
commit a46c68a318b08f819047843abf349aeee5d10ac2 upstream.
While do swap, we should make sure there has no new dirty page since we should swap i_data between two inode:
1.We should lock i_mmap_sem with write to avoid new pagecache from mmap read/write;
2.Change filemap_flush to filemap_write_and_wait and move them to the space protected by inode lock to avoid new pagecache from buffer read/write.
--- fs/ext4/ioctl.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
fs/ext4/ioctl.c +12 -4
@@ -121,9 +121,6 @@ static long swap_inode_boot_loader(strucreturn PTR_ERR (inode_bl); ei_bl =EXT4_I (inode_bl); -filemap_flush (inode->i_mapping); -filemap_flush (inode_bl->i_mapping); -/* Protect orig inodes against a truncate and make sure, * that only 1 swap_inode_boot_loader is running. */ lock_two_nondirectories (inode, inode_bl);
@@ -141,6 +138,15 @@ static long swap_inode_boot_loader(struc goto journal_err_out; } +down_write (&EXT4_I (inode)->i_mmap_sem); + err =filemap_write_and_wait (inode->i_mapping); +if (err) + goto err_out; + + err =filemap_write_and_wait (inode_bl->i_mapping); +if (err) + goto err_out; +/* Wait for all existing dio workers */ inode_dio_wait (inode);inode_dio_wait (inode_bl);
@@ -151,7 +157,7 @@ static long swap_inode_boot_loader(struc handle =ext4_journal_start (inode_bl,EXT4_HT_MOVE_EXTENTS ,2 );if (IS_ERR (handle)) { err = -EINVAL ; - goto journal_err_out; + goto err_out; }/* Protect extent tree against block allocations via delalloc */
@@ -208,6 +214,8 @@ static long swap_inode_boot_loader(strucext4_journal_stop (handle);ext4_double_up_write_data_sem (inode, inode_bl); +err_out: +up_write (&EXT4_I (inode)->i_mmap_sem); journal_err_out:unlock_two_nondirectories (inode, inode_bl);iput (inode_bl);
Greg Kroah-Hartman
maintainerPATCH 182/280 ext4: update quota information while swapping boot loader inode
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: yangerkun <[email protected]>
commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.
While do swap between two inode, they swap i_data without update quota information. Also, swap_inode_boot_loader can do "revert" somtimes, so update the quota while all operations has been finished.
--- fs/ext4/ioctl.c | 56 +++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 43 insertions(+), 13 deletions(-)
fs/ext4/ioctl.c +43 -13
@@ -68,8 +68,6 @@ static void swap_inode_data(struct inode ei2 =EXT4_I (inode2);swap (inode1->i_version, inode2->i_version); -swap (inode1->i_blocks, inode2->i_blocks); -swap (inode1->i_bytes, inode2->i_bytes);swap (inode1->i_atime, inode2->i_atime);swap (inode1->i_mtime, inode2->i_mtime);
@@ -115,6 +113,9 @@ static long swap_inode_boot_loader(strucint err;struct inode *inode_bl;struct ext4_inode_info *ei_bl; +qsize_t size, size_bl, diff; +blkcnt_t blocks; +unsigned short bytes; inode_bl =ext4_iget (sb,EXT4_BOOT_LOADER_INO ,EXT4_IGET_SPECIAL );if (IS_ERR (inode_bl))
@@ -180,6 +181,13 @@ static long swap_inode_boot_loader(strucmemset (ei_bl->i_data,0 ,sizeof (ei_bl->i_data)); } + err =dquot_initialize (inode); +if (err) + goto err_out1; + + size = (qsize_t)(inode->i_blocks) * (1 <<9 ) + inode->i_bytes; + size_bl = (qsize_t)(inode_bl->i_blocks) * (1 <<9 ) + inode_bl->i_bytes; + diff = size - size_bl;swap_inode_data (inode, inode_bl); inode->i_ctime = inode_bl->i_ctime =current_time (inode);
@@ -193,24 +201,46 @@ static long swap_inode_boot_loader(struc err =ext4_mark_inode_dirty (handle, inode);if (err <0 ) { +/* No need to update quota information. */ ext4_warning (inode->i_sb,"couldn't mark inode #%lu dirty (err %d)" , inode->i_ino, err);/* Revert all changes: */ swap_inode_data (inode, inode_bl);ext4_mark_inode_dirty (handle, inode); - }else { - err =ext4_mark_inode_dirty (handle, inode_bl); -if (err <0 ) { -ext4_warning (inode_bl->i_sb, -"couldn't mark inode #%lu dirty (err %d)" , - inode_bl->i_ino, err); -/* Revert all changes: */ -swap_inode_data (inode, inode_bl); -ext4_mark_inode_dirty (handle, inode); -ext4_mark_inode_dirty (handle, inode_bl); - } + goto err_out1; + } + + blocks = inode_bl->i_blocks; + bytes = inode_bl->i_bytes; + inode_bl->i_blocks = inode->i_blocks; + inode_bl->i_bytes = inode->i_bytes; + err =ext4_mark_inode_dirty (handle, inode_bl); +if (err <0 ) { +/* No need to update quota information. */ +ext4_warning (inode_bl->i_sb, +"couldn't mark inode #%lu dirty (err %d)" , + inode_bl->i_ino, err); + goto revert; + } + +/* Bootloader inode should not be counted into quota information. */ +if (diff >0 ) +dquot_free_space (inode, diff); +else + err =dquot_alloc_space (inode,-1 * diff); + +if (err <0 ) { +revert: +/* Revert all changes: */ + inode_bl->i_blocks = blocks; + inode_bl->i_bytes = bytes; +swap_inode_data (inode, inode_bl); +ext4_mark_inode_dirty (handle, inode); +ext4_mark_inode_dirty (handle, inode_bl); } + +err_out1:ext4_journal_stop (handle);ext4_double_up_write_data_sem (inode, inode_bl);
Greg Kroah-Hartman
maintainerPATCH 183/280 ext4: add mask of ext4 flags to swap
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: yangerkun <[email protected]>
commit abdc644e8cbac2e9b19763680e5a7cf9bab2bee7 upstream.
The reason is that while swapping two inode, we swap the flags too. Some flags such as EXT4_JOURNAL_DATA_FL can really confuse the things since we're not resetting the address operations structure. The simplest way to keep things sane is to restrict the flags that can be swapped.
--- fs/ext4/ext4.h | 3 +++ fs/ext4/ioctl.c | 6 +++++- 2 files changed, 8 insertions(+), 1 deletion(-)
fs/ext4/ext4.h +3 -0
@@ -435,6 +435,9 @@ struct flex_groups {/* Flags that are appropriate for non-directories/regular files. */ #define EXT4_OTHER_FLMASK (EXT4_NODUMP_FL | EXT4_NOATIME_FL) +/* The only flags that should be swapped */ +#define EXT4_FL_SHOULD_SWAP (EXT4_HUGE_FILE_FL | EXT4_EXTENTS_FL) +/* Mask out flags that are inappropriate for the given type of inode. */ static inline __u32 ext4_mask_flags (umode_t mode,__u32 flags) {
fs/ext4/ioctl.c +5 -1
@@ -63,6 +63,7 @@ static void swap_inode_data(struct inodeloff_t isize;struct ext4_inode_info *ei1;struct ext4_inode_info *ei2; +unsigned long tmp; ei1 =EXT4_I (inode1); ei2 =EXT4_I (inode2);
@@ -72,7 +73,10 @@ static void swap_inode_data(struct inodeswap (inode1->i_mtime, inode2->i_mtime);memswap (ei1->i_data, ei2->i_data,sizeof (ei1->i_data)); -swap (ei1->i_flags, ei2->i_flags); + tmp = ei1->i_flags &EXT4_FL_SHOULD_SWAP ; + ei1->i_flags = (ei2->i_flags &EXT4_FL_SHOULD_SWAP ) | + (ei1->i_flags & ~EXT4_FL_SHOULD_SWAP ); + ei2->i_flags = tmp | (ei2->i_flags & ~EXT4_FL_SHOULD_SWAP );swap (ei1->i_disksize, ei2->i_disksize);ext4_es_remove_extent (inode1,0 ,EXT_MAX_BLOCKS );ext4_es_remove_extent (inode2,0 ,EXT_MAX_BLOCKS );
Greg Kroah-Hartman
maintainerPATCH 184/280 ext4: fix crash during online resizing
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream.
When computing maximum size of filesystem possible with given number of group descriptor blocks, we forget to include s_first_data_block into the number of blocks. Thus for filesystems with non-zero s_first_data_block it can happen that computed maximum filesystem size is actually lower than current filesystem size which confuses the code and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on flex_gd->count == 0. The problem can be reproduced like:
truncate -s 100g /tmp/image
mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs /dev/loop0 262145
resize2fs /dev/loop0 300000
Fix the problem by properly including s_first_data_block into the computed number of filesystem blocks.
--- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/resize.c +2 -1
@@ -1960,7 +1960,8 @@ retry:le16_to_cpu (es->s_reserved_gdt_blocks); n_group = n_desc_blocks *EXT4_DESC_PER_BLOCK (sb); n_blocks_count = (ext4_fsblk_t )n_group * -EXT4_BLOCKS_PER_GROUP (sb); +EXT4_BLOCKS_PER_GROUP (sb) + +le32_to_cpu (es->s_first_data_block); n_group--;/* set to last group number */ }
Greg Kroah-Hartman
maintainerPATCH 185/280 PCI/ASPM: Use LTR if already enabled by platform
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <[email protected]>
commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream.
RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro 7140 table stopped working after wakeup from suspend and bisected the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"). David Ward reported the same problem on a Dell Latitude 7350.
After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it"), we don't enable LTR unless the platform has granted LTR control to us. In addition, we don't notice if the platform had already enabled LTR itself.
After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"), we avoid using LTR if we don't think the path to the device has LTR enabled.
The combination means that if the platform itself enables LTR but declines to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2.
--- drivers/pci/probe.c | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-)
drivers/pci/probe.c +23 -13
@@ -2038,11 +2038,8 @@ static void pci_configure_ltr(struct pci {#ifdef CONFIG_PCIEASPM struct pci_host_bridge *host =pci_find_host_bridge (dev->bus); -u32 cap;struct pci_dev *bridge; - -if (!host->native_ltr) -return ; +u32 cap, ctl;if (!pci_is_pcie (dev))return ;
@@ -2051,22 +2048,35 @@ static void pci_configure_ltr(struct pciif (!(cap &PCI_EXP_DEVCAP2_LTR ))return ; -/* -* Software must not enable LTR in an Endpoint unless the Root -* Complex and all intermediate Switches indicate support for LTR. -* PCIe r3.1, sec 6.18. -*/ -if (pci_pcie_type (dev) ==PCI_EXP_TYPE_ROOT_PORT ) - dev->ltr_path =1 ; -else { +pcie_capability_read_dword (dev,PCI_EXP_DEVCTL2 , &ctl); +if (ctl &PCI_EXP_DEVCTL2_LTR_EN ) { +if (pci_pcie_type (dev) ==PCI_EXP_TYPE_ROOT_PORT ) { + dev->ltr_path =1 ; +return ; + } + bridge =pci_upstream_bridge (dev);if (bridge && bridge->ltr_path) dev->ltr_path =1 ; + +return ; } -if (dev->ltr_path) +if (!host->native_ltr) +return ; + +/* +* Software must not enable LTR in an Endpoint unless the Root +* Complex and all intermediate Switches indicate support for LTR. +* PCIe r4.0, sec 6.18. +*/ +if (pci_pcie_type (dev) ==PCI_EXP_TYPE_ROOT_PORT || + ((bridge =pci_upstream_bridge (dev)) && + bridge->ltr_path)) {pcie_capability_set_word (dev,PCI_EXP_DEVCTL2 ,PCI_EXP_DEVCTL2_LTR_EN ); + dev->ltr_path =1 ; + }#endif }
Greg Kroah-Hartman
maintainerPATCH 186/280 PCI/DPC: Fix print AER status in DPC event handling
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dongdong Liu <[email protected]>
commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream.
Previously dpc_handler() called aer_get_device_error_info() without initializing info->severity, so aer_get_device_error_info() relied on uninitialized data.
Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask, and severity registers and set info->severity.
Also, clear the port's AER fatal error status bits.
--- drivers/pci/pcie/dpc.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
drivers/pci/pcie/dpc.c +26 -1
@@ -153,6 +153,28 @@ static void dpc_process_rp_pio_error(strpci_write_config_dword (pdev, cap +PCI_EXP_DPC_RP_PIO_STATUS , status); } +static int dpc_get_aer_uncorrect_severity (struct pci_dev *dev, +struct aer_err_info *info) +{ +int pos = dev->aer_cap; +u32 status, mask, sev; + +pci_read_config_dword (dev, pos +PCI_ERR_UNCOR_STATUS , &status); +pci_read_config_dword (dev, pos +PCI_ERR_UNCOR_MASK , &mask); + status &= ~mask; +if (!status) +return 0 ; + +pci_read_config_dword (dev, pos +PCI_ERR_UNCOR_SEVER , &sev); + status &= sev; +if (status) + info->severity =AER_FATAL ; +else + info->severity =AER_NONFATAL ; + +return 1 ; +} +static irqreturn_t dpc_handler (int irq,void *context) {struct aer_err_info info;
@@ -180,9 +202,12 @@ static irqreturn_t dpc_handler(int irq,/* show RP PIO error detail information */ if (dpc->rp_extensions && reason ==3 && ext_reason ==0 )dpc_process_rp_pio_error (dpc); -else if (reason ==0 &&aer_get_device_error_info (pdev, &info)) { +else if (reason ==0 && +dpc_get_aer_uncorrect_severity (pdev, &info) && +aer_get_device_error_info (pdev, &info)) {aer_print_error (pdev, &info);pci_cleanup_aer_uncorrect_error_status (pdev); +pci_aer_clear_fatal_status (pdev); }/* We configure DPC so it only triggers on ERR_FATAL */
Greg Kroah-Hartman
maintainerPATCH 187/280 PCI: dwc: skip MSI init if MSIs have been explicitly disabled
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream.
Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API) the MSI init claims one of the controller IRQs as a chained IRQ line for the MSI controller. On some designs, like the i.MX6, this line is shared with a PCIe legacy IRQ. When the line is claimed for the MSI domain, any device trying to use this legacy IRQs will fail to request this IRQ line.
As MSI and legacy IRQs are already mutually exclusive on the DWC core, as the core won't forward any legacy IRQs once any MSI has been enabled, users wishing to use legacy IRQs already need to explictly disable MSI support (usually via the pci=nomsi kernel commandline option). To avoid any issues with MSI conflicting with legacy IRQs, just skip all of the DWC MSI initalization, including the IRQ line claim, when MSI is disabled.
--- drivers/pci/controller/dwc/pcie-designware-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/controller/dwc/pcie-designware-host.c +1 -1
@@ -439,7 +439,7 @@ int dw_pcie_host_init(struct pcie_port *if (ret) pci->num_viewport =2 ; -if (IS_ENABLED (CONFIG_PCI_MSI )) { +if (IS_ENABLED (CONFIG_PCI_MSI ) &&pci_msi_enabled ()) {/* * If a specific SoC driver needs to change the * default number of vectors, it needs to implement
Greg Kroah-Hartman
maintainerPATCH 188/280 IB/hfi1: Close race condition on user context disable and close
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael J. Ruhl <[email protected]>
commit bc5add09764c123f58942a37c8335247e683d234 upstream.
When disabling and removing a receive context, it is possible for an asynchronous event (i.e IRQ) to occur. Because of this, there is a race between cleaning up the context, and the context being used by the asynchronous event.
cpu 0 (context cleanup)
rc->ref_count-- (ref_count == 0)
hfi1_rcd_free()
cpu 1 (IRQ (with rcd index))
rcd_get_by_index()
lock
ref_count+++ <-- reference count race (WARNING)
return rcd
unlockcpu 0
hfi1_free_ctxtdata() <-- incorrect free location lock
remove rcd from array
unlock
free rcd
This race will cause the following WARNING trace:
WARNING: CPU: 0 PID: 175027 at include/linux/kref.h:52 hfi1_rcd_get_by_index+0x84/0xa0 [hfi1] CPU: 0 PID: 175027 Comm: IMB-MPI1 Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015 Call Trace: dump_stack+0x19/0x1b __warn+0xd8/0x100 warn_slowpath_null+0x1d/0x20 hfi1_rcd_get_by_index+0x84/0xa0 [hfi1] is_rcv_urgent_int+0x24/0x90 [hfi1] general_interrupt+0x1b6/0x210 [hfi1] __handle_irq_event_percpu+0x44/0x1c0 handle_irq_event_percpu+0x32/0x80 handle_irq_event+0x3c/0x60 handle_edge_irq+0x7f/0x150 handle_irq+0xe4/0x1a0 do_IRQ+0x4d/0xf0 common_interrupt+0x162/0x162
The race can also lead to a use after free which could be similar to:
general protection fault: 0000 1 SMP CPU: 71 PID: 177147 Comm: IMB-MPI1 Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.el7.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015 task: ffff9962a8098000 ti: ffff99717a508000 task.ti: ffff99717a508000 __kmalloc+0x94/0x230 Call Trace: ? hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1] hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1] hfi1_aio_write+0xba/0x110 [hfi1] do_sync_readv_writev+0x7b/0xd0 do_readv_writev+0xce/0x260 ? handle_mm_fault+0x39d/0x9b0 ? pick_next_task_fair+0x5f/0x1b0 ? sched_clock_cpu+0x85/0xc0 ? __schedule+0x13a/0x890 vfs_writev+0x35/0x60 SyS_writev+0x7f/0x110 system_call_fastpath+0x22/0x27
Use the appropriate kref API to verify access.
Reorder context cleanup to ensure context removal before cleanup occurs correctly.
--- drivers/infiniband/hw/hfi1/hfi.h | 2 +- drivers/infiniband/hw/hfi1/init.c | 14 +++++++++----- 2 files changed, 10 insertions(+), 6 deletions(-)
drivers/infiniband/hw/hfi1/hfi.h +1 -1
@@ -1425,7 +1425,7 @@ void hfi1_init_pportdata(struct pci_dev struct hfi1_devdata *dd, u8 hw_pidx, u8 port);void hfi1_free_ctxtdata (struct hfi1_devdata *dd,struct hfi1_ctxtdata *rcd);int hfi1_rcd_put (struct hfi1_ctxtdata *rcd); -void hfi1_rcd_get (struct hfi1_ctxtdata *rcd); +int hfi1_rcd_get (struct hfi1_ctxtdata *rcd);struct hfi1_ctxtdata *hfi1_rcd_get_by_index_safe (struct hfi1_devdata *dd,u16 ctxt);struct hfi1_ctxtdata *hfi1_rcd_get_by_index (struct hfi1_devdata *dd,u16 ctxt);
drivers/infiniband/hw/hfi1/init.c +9 -5
@@ -213,12 +213,12 @@ static void hfi1_rcd_free(struct kref *kstruct hfi1_ctxtdata *rcd = container_of(kref, struct hfi1_ctxtdata, kref); -hfi1_free_ctxtdata (rcd->dd, rcd); -spin_lock_irqsave (&rcd->dd->uctxt_lock, flags); rcd->dd->rcd[rcd->ctxt] =NULL ;spin_unlock_irqrestore (&rcd->dd->uctxt_lock, flags); +hfi1_free_ctxtdata (rcd->dd, rcd); +kfree (rcd); }
@@ -241,10 +241,13 @@ int hfi1_rcd_put(struct hfi1_ctxtdata *r* @rcd: pointer to an initialized rcd data structure * * Use this to get a reference after the init. +* +* Return : reflect kref_get_unless_zero(), which returns non-zero on +* increment, otherwise 0. */ -void hfi1_rcd_get (struct hfi1_ctxtdata *rcd) +int hfi1_rcd_get (struct hfi1_ctxtdata *rcd) { -kref_get (&rcd->kref); +return kref_get_unless_zero (&rcd->kref); }/**
@@ -324,7 +327,8 @@ struct hfi1_ctxtdata *hfi1_rcd_get_by_inspin_lock_irqsave (&dd->uctxt_lock, flags);if (dd->rcd[ctxt]) { rcd = dd->rcd[ctxt]; -hfi1_rcd_get (rcd); +if (!hfi1_rcd_get (rcd)) + rcd =NULL ; }spin_unlock_irqrestore (&dd->uctxt_lock, flags);
Greg Kroah-Hartman
maintainerPATCH 189/280 cxl: Wrap iterations over afu slices inside afu_list_lock
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vaibhav Jain <[email protected]>
commit edeb304f659792fb5bab90d7d6f3408b4c7301fb upstream.
Within cxl module, iteration over array 'adapter->afu' may be racy at few points as it might be simultaneously read during an EEH and its contents being set to NULL while driver is being unloaded or unbound from the adapter. This might result in a NULL pointer to 'struct afu' being de-referenced during an EEH thereby causing a kernel oops.
This patch fixes this by making sure that all access to the array 'adapter->afu' is wrapped within the context of spin-lock 'adapter->afu_list_lock'.
--- drivers/misc/cxl/guest.c | 2 ++ drivers/misc/cxl/pci.c | 39 ++++++++++++++++++++++++++++++--------- 2 files changed, 32 insertions(+), 9 deletions(-)
drivers/misc/cxl/guest.c +2 -0
@@ -267,6 +267,7 @@ static int guest_reset(struct cxl *adaptint i, rc;pr_devel ("Adapter reset request\n" ); +spin_lock (&adapter->afu_list_lock);for (i =0 ; i < adapter->slices; i++) {if ((afu = adapter->afu[i])) { pci_error_handlers(afu, CXL_ERROR_DETECTED_EVENT,
@@ -283,6 +284,7 @@ static int guest_reset(struct cxl *adaptpci_error_handlers (afu,CXL_RESUME_EVENT ,0 ); } } +spin_unlock (&adapter->afu_list_lock);return rc; }
drivers/misc/cxl/pci.c +30 -9
@@ -1807,7 +1807,7 @@ static pci_ers_result_t cxl_vphb_error_d/* There should only be one entry, but go through the list * anyway */ -if (afu->phb ==NULL ) +if (afu ==NULL || afu->phb ==NULL )return result;list_for_each_entry (afu_dev, &afu->phb->bus->devices, bus_list) {
@@ -1834,7 +1834,8 @@ static pci_ers_result_t cxl_pci_error_de {struct cxl *adapter =pci_get_drvdata (pdev);struct cxl_afu *afu; -pci_ers_result_t result =PCI_ERS_RESULT_NEED_RESET , afu_result; +pci_ers_result_t result =PCI_ERS_RESULT_NEED_RESET ; +pci_ers_result_t afu_result =PCI_ERS_RESULT_NEED_RESET ;int i;/* At this point, we could still have an interrupt pending.
@@ -1845,6 +1846,7 @@ static pci_ers_result_t cxl_pci_error_de/* If we're permanently dead, give up. */ if (state == pci_channel_io_perm_failure) { +spin_lock (&adapter->afu_list_lock);for (i =0 ; i < adapter->slices; i++) { afu = adapter->afu[i];/*
@@ -1853,6 +1855,7 @@ static pci_ers_result_t cxl_pci_error_de*/ cxl_vphb_error_detected (afu, state); } +spin_unlock (&adapter->afu_list_lock);return PCI_ERS_RESULT_DISCONNECT ; }
@@ -1934,11 +1937,17 @@ static pci_ers_result_t cxl_pci_error_de* * In slot_reset, free the old resources and allocate new ones. * * In resume, clear the flag to allow things to start. */ + +/* Make sure no one else changes the afu list */ +spin_lock (&adapter->afu_list_lock); +for (i =0 ; i < adapter->slices; i++) { afu = adapter->afu[i]; - afu_result =cxl_vphb_error_detected (afu, state); +if (afu ==NULL ) +continue ; + afu_result =cxl_vphb_error_detected (afu, state);cxl_context_detach_all (afu); cxl_ops->afu_deactivate_mode (afu, afu->current_mode);pci_deconfigure_afu (afu);
@@ -1950,6 +1959,7 @@ static pci_ers_result_t cxl_pci_error_de (result == PCI_ERS_RESULT_NEED_RESET)) result =PCI_ERS_RESULT_NONE ; } +spin_unlock (&adapter->afu_list_lock);/* should take the context lock here */ if (cxl_adapter_context_lock (adapter) !=0 )
@@ -1982,14 +1992,18 @@ static pci_ers_result_t cxl_pci_slot_res*/ cxl_adapter_context_unlock (adapter); +spin_lock (&adapter->afu_list_lock);for (i =0 ; i < adapter->slices; i++) { afu = adapter->afu[i]; +if (afu ==NULL ) +continue ; +if (pci_configure_afu (afu, adapter, pdev)) - goto err; + goto err_unlock;if (cxl_afu_select_best_mode (afu)) - goto err; + goto err_unlock;if (afu->phb ==NULL )continue ;
@@ -2001,16 +2015,16 @@ static pci_ers_result_t cxl_pci_slot_res ctx =cxl_get_context (afu_dev);if (ctx &&cxl_release_context (ctx)) - goto err; + goto err_unlock; ctx =cxl_dev_context_init (afu_dev);if (IS_ERR (ctx)) - goto err; + goto err_unlock; afu_dev->dev.archdata.cxl_ctx = ctx;if (cxl_ops->afu_check_and_enable (afu)) - goto err; + goto err_unlock; afu_dev->error_state = pci_channel_io_normal;
@@ -2031,8 +2045,13 @@ static pci_ers_result_t cxl_pci_slot_res result =PCI_ERS_RESULT_DISCONNECT ; } } + +spin_unlock (&adapter->afu_list_lock);return result; +err_unlock: +spin_unlock (&adapter->afu_list_lock); + err:/* All the bits that happen in both error_detected and cxl_remove * should be idempotent, so we don't need to worry about leaving a mix
@@ -2053,10 +2072,11 @@ static void cxl_pci_resume(struct pci_de* This is not the place to be checking if everything came back up * properly, because there's no return value: do that in slot_reset. */ +spin_lock (&adapter->afu_list_lock);for (i =0 ; i < adapter->slices; i++) { afu = adapter->afu[i]; -if (afu->phb ==NULL ) +if (afu ==NULL || afu->phb ==NULL )continue ;list_for_each_entry (afu_dev, &afu->phb->bus->devices, bus_list) {
@@ -2065,6 +2085,7 @@ static void cxl_pci_resume(struct pci_de afu_dev->driver->err_handler->resume (afu_dev); } } +spin_unlock (&adapter->afu_list_lock); }static const struct pci_error_handlers cxl_err_handler = {
Greg Kroah-Hartman
maintainerPATCH 190/280 ext2: Fix underflow in ext2_max_size()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 1c2d14212b15a60300a2d4f6364753e87394c521 upstream.
When ext2 filesystem is created with 64k block size, ext2_max_size() will return value less than 0. Also, we cannot write any file in this fs since the sb->maxbytes is less than 0. The core of the problem is that the size of block index tree for such large block size is more than i_blocks can carry. So fix the computation to count with this possibility.
File size limits computed with the new function for the full range of possible block sizes look like:
bits file_size
10 17247252480
11 275415851008
12 2196873666560 13 2197948973056 14 2198486220800 15 2198754754560 16 2198888906752
--- fs/ext2/super.c | 41 ++++++++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 15 deletions(-)
fs/ext2/super.c +26 -15
@@ -761,7 +761,8 @@ static loff_t ext2_max_size(int bits) {loff_t res =EXT2_NDIR_BLOCKS ;int meta_blocks; -loff_t upper_limit; +unsigned int upper_limit; +unsigned int ppb =1 << (bits-2 );/* This is calculated to be the largest file size for a * dense, file such that the total number of
@@ -775,24 +776,34 @@ static loff_t ext2_max_size(int bits)/* total blocks in file system block size */ upper_limit >>= (bits -9 ); - -/* indirect blocks */ - meta_blocks =1 ; -/* double indirect blocks */ - meta_blocks +=1 + (1LL << (bits-2 )); -/* tripple indirect blocks */ - meta_blocks +=1 + (1LL << (bits-2 )) + (1LL << (2 *(bits-2 ))); - - upper_limit -= meta_blocks; - upper_limit <<= bits; - +/* Compute how many blocks we can address by block tree */ res +=1LL << (bits-2 ); res +=1LL << (2 *(bits-2 )); res +=1LL << (3 *(bits-2 )); +/* Does block tree limit file size? */ +if (res < upper_limit) + goto check_lfs; + + res = upper_limit; +/* How many metadata blocks are needed for addressing upper_limit? */ + upper_limit -=EXT2_NDIR_BLOCKS ; +/* indirect blocks */ + meta_blocks =1 ; + upper_limit -= ppb; +/* double indirect blocks */ +if (upper_limit < ppb * ppb) { + meta_blocks +=1 +DIV_ROUND_UP (upper_limit, ppb); + res -= meta_blocks; + goto check_lfs; + } + meta_blocks +=1 + ppb; + upper_limit -= ppb * ppb; +/* tripple indirect blocks for the rest */ + meta_blocks +=1 +DIV_ROUND_UP (upper_limit, ppb) + +DIV_ROUND_UP (upper_limit, ppb*ppb); + res -= meta_blocks; +check_lfs: res <<= bits; -if (res > upper_limit) - res = upper_limit; -if (res >MAX_LFS_FILESIZE ) res =MAX_LFS_FILESIZE ;
Greg Kroah-Hartman
maintainerPATCH 191/280 clk: uniphier: Fix update register for CPU-gear
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kunihiko Hayashi <[email protected]>
commit 521282237b9d78b9bff423ec818becd4c95841c2 upstream.
Need to set the update bit in UNIPHIER_CLK_CPUGEAR_UPD to update the CPU-gear value.
--- drivers/clk/uniphier/clk-uniphier-cpugear.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/uniphier/clk-uniphier-cpugear.c +1 -1
@@ -47,7 +47,7 @@ static int uniphier_clk_cpugear_set_parereturn ret; ret =regmap_write_bits (gear->regmap, - gear->regbase +UNIPHIER_CLK_CPUGEAR_SET , + gear->regbase +UNIPHIER_CLK_CPUGEAR_UPD ,UNIPHIER_CLK_CPUGEAR_UPD_BIT ,UNIPHIER_CLK_CPUGEAR_UPD_BIT );if (ret)
Greg Kroah-Hartman
maintainerPATCH 192/280 clk: clk-twl6040: Fix imprecise external abort for pdmclk
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
commit 5ae51d67aec95f6f9386aa8dd5db424964895575 upstream.
I noticed that modprobe clk-twl6040 can fail after a cold boot with:
abe_cm:clk:0010:0: failed to enable
...
Unhandled fault: imprecise external abort (0x1406) at 0xbe896b20
WARNING: CPU: 1 PID: 29 at drivers/clk/clk.c:828 clk_core_disable_lock+0x18/0x24
...
(clk_core_disable_lock) from [<c0123534>] (_disable_clocks+0x18/0x90) (_disable_clocks) from [<c0124040>] (_idle+0x17c/0x244) (_idle) from [<c0125ad4>] (omap_hwmod_idle+0x24/0x44) (omap_hwmod_idle) from [<c053a038>] (sysc_runtime_suspend+0x48/0x108) (sysc_runtime_suspend) from [<c06084c4>] (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [<c0608578>] (rpm_callback+0x20/0x80) (rpm_callback) from [<c0607034>] (rpm_suspend+0x120/0x694) (rpm_suspend) from [<c0607a78>] (__pm_runtime_idle+0x60/0x84) (__pm_runtime_idle) from [<c053aaf0>] (sysc_probe+0x874/0xf2c) (sysc_probe) from [<c05fecd4>] (platform_drv_probe+0x48/0x98)
After searching around for a similar issue, I came across an earlier fix that never got merged upstream in the Android tree for glass-omap-xrr02. There is patch "MFD: twl6040-codec: Implement PDMCLK cold temp errata" by Misael Lopez Cruz <[email protected]>.
Based on my observations, this fix is also needed when cold booting devices, and not just for deeper idle modes. Since we now have a clock driver for pdmclk, let's fix the issue in twl6040_pdmclk_prepare().
--- drivers/clk/clk-twl6040.c | 53 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 51 insertions(+), 2 deletions(-)
drivers/clk/clk-twl6040.c +51 -2
@@ -41,6 +41,43 @@ static int twl6040_pdmclk_is_prepared(streturn pdmclk->enabled; } +static int twl6040_pdmclk_reset_one_clock (struct twl6040_pdmclk *pdmclk, +unsigned int reg) +{ +const u8 reset_mask =TWL6040_HPLLRST ;/* Same for HPPLL and LPPLL */ +int ret; + + ret =twl6040_set_bits (pdmclk->twl6040, reg, reset_mask); +if (ret <0 ) +return ret; + + ret =twl6040_clear_bits (pdmclk->twl6040, reg, reset_mask); +if (ret <0 ) +return ret; + +return 0 ; +} + +/* +* TWL6040A2 Phoenix Audio IC erratum #6: "PDM Clock Generation Issue At +* Cold Temperature". This affects cold boot and deeper idle states it +* seems. The workaround consists of resetting HPPLL and LPPLL. +*/ +static int twl6040_pdmclk_quirk_reset_clocks (struct twl6040_pdmclk *pdmclk) +{ +int ret; + + ret =twl6040_pdmclk_reset_one_clock (pdmclk,TWL6040_REG_HPPLLCTL ); +if (ret) +return ret; + + ret =twl6040_pdmclk_reset_one_clock (pdmclk,TWL6040_REG_LPPLLCTL ); +if (ret) +return ret; + +return 0 ; +} +static int twl6040_pdmclk_prepare (struct clk_hw *hw) { struct twl6040_pdmclk *pdmclk = container_of(hw, struct twl6040_pdmclk,
@@ -48,8 +85,20 @@ static int twl6040_pdmclk_prepare(structint ret; ret =twl6040_power (pdmclk->twl6040,1 ); -if (!ret) - pdmclk->enabled =1 ; +if (ret) +return ret; + + ret =twl6040_pdmclk_quirk_reset_clocks (pdmclk); +if (ret) + goto out_err; + + pdmclk->enabled =1 ; + +return 0 ; + +out_err: +dev_err (pdmclk->dev,"%s: error %i\n" , __func__, ret); +twl6040_power (pdmclk->twl6040,0 );return ret; }
Greg Kroah-Hartman
maintainerPATCH 193/280 clk: samsung: exynos5: Fix possible NULL pointer exception on platform_device_alloc() failure
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 5f0b6216ea381b43c0dff88702d6cc5673d63922 upstream.
During initialization of subdevices if platform_device_alloc() failed, returned NULL pointer will be later dereferenced. Add proper error paths to exynos5_clk_register_subcmu(). The return value of this function is still ignored because at this stage of init there is nothing we can do.
--- drivers/clk/samsung/clk-exynos5-subcmu.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/clk/samsung/clk-exynos5-subcmu.c +8 -2
@@ -136,15 +136,21 @@ static int __init exynos5_clk_register_s {struct of_phandle_args genpdspec = { .np = pd_node };struct platform_device *pdev; +int ret; pdev =platform_device_alloc (info->pd_name,-1 ); +if (!pdev) +return -ENOMEM ; + pdev->dev.parent = parent; pdev->driver_override ="exynos5-subcmu" ;platform_set_drvdata (pdev, (void *)info);of_genpd_add_device (&genpdspec, &pdev->dev); -platform_device_add (pdev); + ret =platform_device_add (pdev); +if (ret) +platform_device_put (pdev); -return 0 ; +return ret; }static int __init exynos5_clk_probe (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 194/280 clk: samsung: exynos5: Fix kfree() of const memory on setting driver_override
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 785c9f411eb2d9a6076d3511c631587d5e676bf3 upstream.
Platform driver driver_override field should not be initialized from const memory because the core later kfree() it. If driver_override is manually set later through sysfs, kfree() of old value leads to:
$ echo "new_value" > /sys/bus/platform/drivers/.../driver_override
kernel BUG at ../mm/slub.c:3960!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
(kfree) from [<c058e8c0>] (platform_set_driver_override+0x84/0xac)
(platform_set_driver_override) from [<c058e908>] (driver_override_store+0x20/0x34)
(driver_override_store) from [<c031f778>] (kernfs_fop_write+0x100/0x1dc)
(kernfs_fop_write) from [<c0296de8>] (__vfs_write+0x2c/0x17c)
(__vfs_write) from [<c02970c4>] (vfs_write+0xa4/0x188)
(vfs_write) from [<c02972e8>] (ksys_write+0x4c/0xac)
(ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)The clk-exynos5-subcmu driver uses override only for the purpose of creating meaningful names for children devices (matching names of power domains, e.g. DISP, MFC). The driver_override was not developed for this purpose so just switch to default names of devices to fix the issue.
--- drivers/clk/samsung/clk-exynos5-subcmu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/clk/samsung/clk-exynos5-subcmu.c +1 -2
@@ -138,12 +138,11 @@ static int __init exynos5_clk_register_sstruct platform_device *pdev;int ret; - pdev =platform_device_alloc (info->pd_name,-1 ); + pdev =platform_device_alloc ("exynos5-subcmu" ,PLATFORM_DEVID_AUTO );if (!pdev)return -ENOMEM ; pdev->dev.parent = parent; - pdev->driver_override ="exynos5-subcmu" ;platform_set_drvdata (pdev, (void *)info);of_genpd_add_device (&genpdspec, &pdev->dev); ret =platform_device_add (pdev);
Greg Kroah-Hartman
maintainerPATCH 195/280 clk: ingenic: Fix round_rate misbehaving with non-integer dividers
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Cercueil <[email protected]>
commit bc5d922c93491878c44c9216e9d227c7eeb81d7f upstream.
Take a parent rate of 180 MHz, and a requested rate of 4.285715 MHz. This results in a theorical divider of 41.999993 which is then rounded up to 42. The .round_rate function would then return (180 MHz / 42) as the clock, rounded down, so 4.285714 MHz.
Calling clk_set_rate on 4.285714 MHz would round the rate again, and give a theorical divider of 42,0000028, now rounded up to 43, and the rate returned would be (180 MHz / 43) which is 4.186046 MHz, aka. not what we requested.
Fix this by rounding up the divisions.
--- drivers/clk/ingenic/cgu.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/clk/ingenic/cgu.c +5 -5
@@ -426,16 +426,16 @@ ingenic_clk_round_rate(struct clk_hw *hwstruct ingenic_clk *ingenic_clk =to_ingenic_clk (hw);struct ingenic_cgu *cgu = ingenic_clk->cgu;const struct ingenic_cgu_clk_info *clk_info; -long rate = *parent_rate; +unsigned int div =1 ; clk_info = &cgu->clock_info[ingenic_clk->idx];if (clk_info->type &CGU_CLK_DIV ) - rate /=ingenic_clk_calc_div (clk_info, *parent_rate, req_rate); + div =ingenic_clk_calc_div (clk_info, *parent_rate, req_rate);else if (clk_info->type &CGU_CLK_FIXDIV ) - rate /= clk_info->fixdiv.div; + div = clk_info->fixdiv.div; -return rate; +return DIV_ROUND_UP (*parent_rate, div); } static int
@@ -455,7 +455,7 @@ ingenic_clk_set_rate(struct clk_hw *hw,if (clk_info->type &CGU_CLK_DIV ) { div =ingenic_clk_calc_div (clk_info, parent_rate, req_rate); - rate = parent_rate / div; + rate =DIV_ROUND_UP (parent_rate, div);if (rate != req_rate)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 196/280 clk: ingenic: Fix doc of ingenic_cgu_div_info
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Cercueil <[email protected]>
commit 7ca4c922aad2e3c46767a12f80d01c6b25337b59 upstream.
The 'div' field does not represent a number of bits used to divide (understand: right-shift) the divider, but a number itself used to divide the divider.
--- drivers/clk/ingenic/cgu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/ingenic/cgu.h +1 -1
@@ -80,7 +80,7 @@ struct ingenic_cgu_mux_info {* @reg: offset of the divider control register within the CGU * @shift: number of bits to left shift the divide value by (ie. the index of * the lowest bit of the divide value within its control register) -* @div: number of bits to divide the divider value by (i.e. if the +* @div: number to divide the divider value by (i.e. if the * effective divider value is the value written to the register * multiplied by some constant) * @bits: the size of the divide value in bits
Greg Kroah-Hartman
maintainerPATCH 197/280 usb: chipidea: tegra: Fix missed ci_hdrc_remove_device()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Osipenko <[email protected]>
commit 563b9372f7ec57e44e8f9a8600c5107d7ffdd166 upstream.
The ChipIdea's platform device need to be unregistered on Tegra's driver module removal.
--- drivers/usb/chipidea/ci_hdrc_tegra.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/chipidea/ci_hdrc_tegra.c +1 -0
@@ -130,6 +130,7 @@ static int tegra_udc_remove(struct platf {struct tegra_udc *udc =platform_get_drvdata (pdev); +ci_hdrc_remove_device (udc->dev);usb_phy_set_suspend (udc->phy,1 );clk_disable_unprepare (udc->clk);
Greg Kroah-Hartman
maintainerPATCH 198/280 usb: typec: tps6598x: handle block writes separately with plain-I2C adapters
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolaus Voss <[email protected]>
commit 8a863a608d47fa5d9dd15cf841817f73f804cf91 upstream.
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C adapters, but the problem described with regmap-i2c not handling SMBus block transfers (i.e. read and writes) correctly also exists with writes.
As workaround, this patch adds a block write function the same way 1a2f474d328f adds a block read function.
--- drivers/usb/typec/tps6598x.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-)
drivers/usb/typec/tps6598x.c +20 -6
@@ -110,6 +110,20 @@ tps6598x_block_read(struct tps6598x *tpsreturn 0 ; } +static int tps6598x_block_write (struct tps6598x *tps,u8 reg, +void *val,size_t len) +{ +u8 data[TPS_MAX_LEN +1 ]; + +if (!tps->i2c_protocol) +return regmap_raw_write (tps->regmap, reg, val, len); + + data[0 ] = len; +memcpy (&data[1 ], val, len); + +return regmap_raw_write (tps->regmap, reg, data,sizeof (data)); +} +static inline int tps6598x_read16 (struct tps6598x *tps,u8 reg,u16 *val) {return tps6598x_block_read (tps, reg, val,sizeof (u16));
@@ -127,23 +141,23 @@ static inline int tps6598x_read64(structstatic inline int tps6598x_write16 (struct tps6598x *tps,u8 reg,u16 val) { -return regmap_raw_write (tps->regmap, reg, &val,sizeof (u16)); +return tps6598x_block_write (tps, reg, &val,sizeof (u16)); }static inline int tps6598x_write32 (struct tps6598x *tps,u8 reg,u32 val) { -return regmap_raw_write (tps->regmap, reg, &val,sizeof (u32)); +return tps6598x_block_write (tps, reg, &val,sizeof (u32)); }static inline int tps6598x_write64 (struct tps6598x *tps,u8 reg,u64 val) { -return regmap_raw_write (tps->regmap, reg, &val,sizeof (u64)); +return tps6598x_block_write (tps, reg, &val,sizeof (u64)); }static inline int tps6598x_write_4cc (struct tps6598x *tps,u8 reg,const char *val) { -return regmap_raw_write (tps->regmap, reg, &val,sizeof (u32)); +return tps6598x_block_write (tps, reg, &val,sizeof (u32)); }static int tps6598x_read_partner_identity (struct tps6598x *tps)
@@ -229,8 +243,8 @@ static int tps6598x_exec_cmd(struct tps6return -EBUSY ;if (in_len) { - ret =regmap_raw_write (tps->regmap,TPS_REG_DATA1 , - in_data, in_len); + ret =tps6598x_block_write (tps,TPS_REG_DATA1 , + in_data, in_len);if (ret)return ret; }
Greg Kroah-Hartman
maintainerPATCH 199/280 dmaengine: usb-dmac: Make DMAC system sleep callbacks explicit
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phuong Nguyen <[email protected]>
commit d9140a0da4a230a03426d175145989667758aa6a upstream.
This commit fixes the issue that USB-DMAC hangs silently after system resumes on R-Car Gen3 hence renesas_usbhs will not work correctly when using USB-DMAC for bulk transfer e.g. ethernet or serial gadgets.
The issue can be reproduced by these steps:
1. modprobe g_serial
2. Suspend and resume system.
3. connect a usb cable to host side
4. Transfer data from Host to Target
5. cat /dev/ttyGS0 (Target side)
6. echo "test" > /dev/ttyACM0 (Host side)
The 'cat' will not result anything. However, system still can work normally.
Currently, USB-DMAC driver does not have system sleep callbacks hence this driver relies on the PM core to force runtime suspend/resume to suspend and reinitialize USB-DMAC during system resume. After the commit 17218e0092f8 ("PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume()"), PM core will not force runtime suspend/resume anymore so this issue happens.
To solve this, make system suspend resume explicit by using pm_runtime_force_{suspend,resume}() as the system sleep callbacks. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC suspended after and initialized before renesas_usbhs."
--- drivers/dma/sh/usb-dmac.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/dma/sh/usb-dmac.c +2 -0
@@ -697,6 +697,8 @@ static int usb_dmac_runtime_resume(struc#endif /* CONFIG_PM */ static const struct dev_pm_ops usb_dmac_pm = { + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, + pm_runtime_force_resume)SET_RUNTIME_PM_OPS (usb_dmac_runtime_suspend, usb_dmac_runtime_resume,NULL ) };
Greg Kroah-Hartman
maintainerPATCH 200/280 mm: hwpoison: fix thp split handing in soft_offline_in_use_page()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhongjiang <[email protected]>
commit 46612b751c4941c5c0472ddf04027e877ae5990f upstream.
When soft_offline_in_use_page() runs on a thp tail page after pmd is split, we trigger the following VM_BUG_ON_PAGE():
Memory failure: 0x3755ff: non anonymous thp
__get_any_page: 0x3755ff: unknown zero refcount page type 2fffff80000000 Soft offlining pfn 0x34d805 at process virtual address 0x20fff000 page:ffffea000d360140 count:0 mapcount:0 mapping:0000000000000000 index:0x1
flags: 0x2fffff80000000()
raw: 002fffff80000000 ffffea000d360108 ffffea000d360188 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at ./include/linux/mm.h:519!
soft_offline_in_use_page() passed refcount and page lock from tail page to head page, which is not needed because we can pass any subpage to split_huge_page().
Naoya had fixed a similar issue in c3901e722b29 ("mm: hwpoison: fix thp split handling in memory_failure()"). But he missed fixing soft offline.
--- mm/memory-failure.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
mm/memory-failure.c +6 -8
@@ -1823,19 +1823,17 @@ static int soft_offline_in_use_page(strustruct page *hpage =compound_head (page);if (!PageHuge (page) &&PageTransHuge (hpage)) { -lock_page (hpage); -if (!PageAnon (hpage) ||unlikely (split_huge_page (hpage))) { -unlock_page (hpage); -if (!PageAnon (hpage)) +lock_page (page); +if (!PageAnon (page) ||unlikely (split_huge_page (page))) { +unlock_page (page); +if (!PageAnon (page))pr_info ("soft offline: %#lx: non anonymous thp\n" ,page_to_pfn (page));else pr_info ("soft offline: %#lx: thp split failed\n" ,page_to_pfn (page)); -put_hwpoison_page (hpage); +put_hwpoison_page (page);return -EBUSY ; } -unlock_page (hpage); -get_hwpoison_page (page); -put_hwpoison_page (hpage); +unlock_page (page); }/*
Greg Kroah-Hartman
maintainerPATCH 201/280 mm/vmalloc: fix size check for remap_vmalloc_range_partial()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Penyaev <[email protected]>
commit 401592d2e095947344e10ec0623adbcd58934dd4 upstream.
When VM_NO_GUARD is not set area->size includes adjacent guard page, thus for correct size checking get_vm_area_size() should be used, but not area->size.
This fixes possible kernel oops when userspace tries to mmap an area on 1 page bigger than was allocated by vmalloc_user() call: the size check inside remap_vmalloc_range_partial() accounts non-existing guard page also, so check successfully passes but vmalloc_to_page() returns NULL (guard page does not physically exist).
The following code pattern example should trigger an oops:
static int oops_mmap(struct file *file, struct vm_area_struct *vma)
{
void *mem; mem = vmalloc_user(4096);
BUG_ON(!mem);
/* Do not care about mem leak */
return remap_vmalloc_range(vma, mem, 0);}
And userspace simply mmaps size + PAGE_SIZE:
mmap(NULL, 8192, PROT_WRITE|PROT_READ, MAP_PRIVATE, fd, 0);
Possible candidates for oops which do not have any explicit size checks:
*** drivers/media/usb/stkwebcam/stk-webcam.c: v4l_stk_mmap[789] ret = remap_vmalloc_range(vma, sbuf->buffer, 0);
Or the following one:
*** drivers/video/fbdev/core/fbmem.c
static int
fb_mmap(struct file *file, struct vm_area_struct * vma)
...
res = fb->fb_mmap(info, vma);Where fb_mmap callback calls remap_vmalloc_range() directly without any explicit checks:
*** drivers/video/fbdev/vfb.c
static int vfb_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
return remap_vmalloc_range(vma, (void *)info->fix.smem_start, vma->vm_pgoff);
}--- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/vmalloc.c +1 -1
@@ -2244,7 +2244,7 @@ int remap_vmalloc_range_partial(struct vif (!(area->flags &VM_USERMAP ))return -EINVAL ; -if (kaddr + size > area->addr + area->size) +if (kaddr + size > area->addr +get_vm_area_size (area))return -EINVAL ; do {
Greg Kroah-Hartman
maintainerPATCH 202/280 mm/memory.c: do_fault: avoid usage of stale vm_area_struct
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Stancek <[email protected]>
commit fc8efd2ddfed3f343c11b693e87140ff358d7ff5 upstream.
LTP testcase mtest06 [1] can trigger a crash on s390x running 5.0.0-rc8. This is a stress test, where one thread mmaps/writes/munmaps memory area and other thread is trying to read from it:
CPU: 0 PID: 2611 Comm: mmap1 Not tainted 5.0.0-rc8+ #51 Hardware name: IBM 2964 N63 400 (z/VM 6.4.0) Krnl PSW : 0404e00180000000 00000000001ac8d8 (__lock_acquire+0x7/0x7a8) Call Trace: ([<0000000000000000>] (null)) [<00000000001adae4>] lock_acquire+0xec/0x258 [<000000000080d1ac>] _raw_spin_lock_bh+0x5c/0x98 [<000000000012a780>] page_table_free+0x48/0x1a8 [<00000000002f6e54>] do_fault+0xdc/0x670 [<00000000002fadae>] __handle_mm_fault+0x416/0x5f0 [<00000000002fb138>] handle_mm_fault+0x1b0/0x320 [<00000000001248cc>] do_dat_exception+0x19c/0x2c8 [<000000000080e5ee>] pgm_check_handler+0x19e/0x200
page_table_free() is called with NULL mm parameter, but because "0" is a valid address on s390 (see S390_lowcore), it keeps going until it eventually crashes in lockdep's lock_acquire. This crash is reproducible at least since 4.14.
Problem is that "vmf->vma" used in do_fault() can become stale. Because mmap_sem may be released, other threads can come in, call munmap() and cause "vma" be returned to kmem cache, and get zeroed/re-initialized and re-used:
handle_mm_fault |
__handle_mm_fault |
do_fault |
vma = vmf->vma |
do_read_fault |
__do_fault |
vma->vm_ops->fault(vmf); |
mmap_sem is released |
|
| do_munmap()
| remove_vma_list()
| remove_vma()
| vm_area_free()
| # vma is released
| ...
| # same vma is allocated
| # from kmem cache
| do_mmap()
| vm_area_alloc()
| memset(vma, 0, ...)
|
pte_free(vma->vm_mm, ...); |
page_table_free |
spin_lock_bh(&mm->context.lock);|
<crash> |Cache mm_struct to avoid using potentially stale "vma".
[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c
--- mm/memory.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/memory.c +4 -1
@@ -3762,10 +3762,13 @@ static vm_fault_t do_shared_fault(struct* but allow concurrent faults). * The mmap_sem may have been released depending on flags and our * return value. See filemap_fault() and __lock_page_or_retry(). +* If mmap_sem is released, vma may become invalid (for example +* by other thread calling munmap()). */ static vm_fault_t do_fault (struct vm_fault *vmf) {struct vm_area_struct *vma = vmf->vma; +struct mm_struct *vm_mm = vma->vm_mm;vm_fault_t ret;/*
@@ -3806,7 +3809,7 @@ static vm_fault_t do_fault(struct vm_fau/* preallocated pagetable is unused: free it */ if (vmf->prealloc_pte) { -pte_free (vma->vm_mm, vmf->prealloc_pte); +pte_free (vm_mm, vmf->prealloc_pte); vmf->prealloc_pte =NULL ; }return ret;
Greg Kroah-Hartman
maintainerPATCH 203/280 kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zev Weiss <[email protected]>
commit 8cf7630b29701d364f8df4a50e4f1f5e752b2778 upstream.
This bug has apparently existed since the introduction of this function in the pre-git era (4500e91754d3 in Thomas Gleixner's history.git, "[NET]: Add proc_dointvec_userhz_jiffies, use it for proper handling of neighbour sysctls.").
As a minimal fix we can simply duplicate the corresponding check in do_proc_dointvec_conv().
--- kernel/sysctl.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
kernel/sysctl.c +10 -1
@@ -2552,7 +2552,16 @@ static int do_proc_dointvec_minmax_conv( {struct do_proc_dointvec_minmax_conv_param *param = data;if (write) { -int val = *negp ? -*lvalp : *lvalp; +int val; +if (*negp) { +if (*lvalp > (unsigned long )INT_MAX +1 ) +return -EINVAL ; + val = -*lvalp; + }else { +if (*lvalp > (unsigned long )INT_MAX ) +return -EINVAL ; + val = *lvalp; + }if ((param->min && *param->min > val) || (param->max && *param->max < val))return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 204/280 device property: Fix the length used in PROPERTY_ENTRY_STRING()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heikki Krogerus <[email protected]>
commit 2b6e492467c78183bb629bb0a100ea3509b615a5 upstream.
With string type property entries we need to use sizeof(const char *) instead of the number of characters as the length of the entry.
If the string was shorter then sizeof(const char *), attempts to read it would have failed with -EOVERFLOW. The problem has been hidden because all build-in string properties have had a string longer then 8 characters until now.
--- include/linux/property.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/property.h +1 -1
@@ -258,7 +258,7 @@ struct property_entry {#define PROPERTY_ENTRY_STRING (_name_, _val_) \ (struct property_entry) { \ .name = _name_, \ - .length = sizeof(_val_), \ + .length = sizeof(const char *), \ .type = DEV_PROP_STRING, \ { .value = { .str = _val_ } }, \ }
Greg Kroah-Hartman
maintainerPATCH 205/280 intel_th: Dont reference unassigned outputs
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shishkin <[email protected]>
commit 9ed3f22223c33347ed963e7c7019cf2956dd4e37 upstream.
When an output port driver is removed, also remove references to it from any masters. Failing to do this causes a NULL ptr dereference when configuring another output port:
Quoted 8 lines
BUG: unable to handle kernel NULL pointer dereference at 000000000000000d RIP: 0010:master_attr_store+0x9d/0x160 [intel_th_gth] Call Trace: dev_attr_store+0x1b/0x30 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x125/0x1a0 __vfs_write+0x3a/0x190 ? __vfs_write+0x5/0x190
Quoted 8 lines
? _cond_resched+0x1a/0x50 ? rcu_all_qs+0x5/0xb0 ? __vfs_write+0x5/0x190 vfs_write+0xb8/0x1b0 ksys_write+0x55/0xc0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x5a/0x140 entry_SYSCALL_64_after_hwframe+0x44/0xa9
--- drivers/hwtracing/intel_th/gth.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hwtracing/intel_th/gth.c +4 -0
@@ -607,6 +607,7 @@ static void intel_th_gth_unassign(struct {struct gth_device *gth =dev_get_drvdata (&thdev->dev);int port = othdev->output.port; +int master;if (thdev->host_mode)return ;
@@ -615,6 +616,9 @@ static void intel_th_gth_unassign(struct othdev->output.port =-1 ; othdev->output.active = false; gth->output[port].output =NULL ; +for (master =0 ; master <TH_CONFIGURABLE_MASTERS ; master++) +if (gth->master[master] == port) + gth->master[master] =-1 ;spin_unlock (>h->gth_lock); }
Greg Kroah-Hartman
maintainerPATCH 206/280 parport_pc: fix find_superio io compare code, should use equal test.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: QiaoChong <[email protected]>
commit 21698fd57984cd28207d841dbdaa026d6061bceb upstream.
In the original code before 181bf1e815a2 the loop was continuing until it finds the first matching superios[i].io and p->base.
But after 181bf1e815a2 the logic changed and the loop now returns the pointer to the first mismatched array element which is then used in get_superio_dma() and get_superio_irq() and thus returning the wrong value.
Fix the condition so that it now returns the correct pointer.
--- drivers/parport/parport_pc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/parport/parport_pc.c +1 -1
@@ -1377,7 +1377,7 @@ static struct superio_struct *find_super {int i;for (i =0 ; i <NR_SUPERIOS ; i++) -if (superios[i].io != p->base) +if (superios[i].io == p->base)return &superios[i];return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 207/280 i2c: tegra: fix maximum transfer size
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sowjanya Komatineni <[email protected]>
commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream.
Tegra186 and prior supports maximum 4K bytes per packet transfer including 12 bytes of packet header.
This patch fixes max write length limit to account packet header size for transfers.
--- drivers/i2c/busses/i2c-tegra.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-tegra.c +1 -1
@@ -832,7 +832,7 @@ static const struct i2c_algorithm tegra_/* payload size is only 12 bit */ static const struct i2c_adapter_quirks tegra_i2c_quirks = { .max_read_len =4096 , - .max_write_len =4096 , + .max_write_len =4096 -12 , };static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
Greg Kroah-Hartman
maintainerPATCH 208/280 media: i2c: ov5640: Fix post-reset delay
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Loic Poulain <[email protected]>
commit 1d4c41f3d887bcd66e82cb2fda124533dad8808a upstream.
According to the ov5640 specification (2.7 power up sequence), host can access the sensor's registers 20ms after reset. Trying to access them before leads to undefined behavior and result in sporadic initialization errors.
--- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/i2c/ov5640.c +1 -1
@@ -1759,7 +1759,7 @@ static void ov5640_reset(struct ov5640_dusleep_range (1000 ,2000 );gpiod_set_value_cansleep (sensor->reset_gpio,0 ); -usleep_range (5000 ,10000 ); +usleep_range (20000 ,25000 ); }static int ov5640_set_power_on (struct ov5640_dev *sensor)
Greg Kroah-Hartman
maintainerPATCH 209/280 gpio: pca953x: Fix dereference of irq data in shutdown
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Walton <[email protected]>
commit c378b3aa015931a46c91d6ccc2fe04d97801d060 upstream.
If a PCA953x gpio was used as an interrupt and then released, the shutdown function was trying to extract the pca953x_chip pointer directly from the irq_data, but in reality was getting the gpio_chip structure.
The net effect was that the subsequent writes to the data structure corrupted data in the gpio_chip structure, which wasn't immediately obvious until attempting to use the GPIO again in the future, at which point the kernel panics.
This fix correctly extracts the pca953x_chip structure via the gpio_chip structure, as is correctly done in the other irq functions.
--- drivers/gpio/gpio-pca953x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpio/gpio-pca953x.c +2 -1
@@ -543,7 +543,8 @@ static int pca953x_irq_set_type(struct istatic void pca953x_irq_shutdown (struct irq_data *d) { -struct pca953x_chip *chip =irq_data_get_irq_chip_data (d); +struct gpio_chip *gc =irq_data_get_irq_chip_data (d); +struct pca953x_chip *chip =gpiochip_get_data (gc);u8 mask =1 << (d->hwirq %BANK_SZ ); chip->irq_trig_raise[d->hwirq /BANK_SZ ] &= ~mask;
Greg Kroah-Hartman
maintainerPATCH 210/280 can: flexcan: FLEXCAN_IFLAG_MB: add () around macro argument
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 22233f7bf2c99ef52ec19d30876a12d2f725972e ]
This patch fixes the following checkpatch warning:
| Macro argument 'x' may be better as '(x)' to avoid precedence issues
--- drivers/net/can/flexcan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/flexcan.c +1 -1
@@ -140,7 +140,7 @@#define FLEXCAN_TX_MB 63#define FLEXCAN_RX_MB_OFF_TIMESTAMP_FIRST (FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP + 1)#define FLEXCAN_RX_MB_OFF_TIMESTAMP_LAST (FLEXCAN_TX_MB - 1) -#define FLEXCAN_IFLAG_MB (x) BIT(x & 0x1f) +#define FLEXCAN_IFLAG_MB (x) BIT((x) & 0x1f)#define FLEXCAN_IFLAG_RX_FIFO_OVERFLOW BIT(7)#define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)#define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(5)
Signature · 1 line
2.19.1
Greg Kroah-Hartman
maintainerPATCH 211/280 drm/i915: Relax mmap VMA check
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit ca22f32a6296cbfa29de56328c8505560a18cfa8 ]
Legacy behaviour was to allow non-page-aligned mmap requests, as does the linux mmap(2) implementation by virtue of automatically rounding up for the caller.
To avoid breaking legacy userspace relax the newly introduced fix.
--- drivers/gpu/drm/i915/i915_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_gem.c +2 -1
@@ -1828,7 +1828,8 @@ __vma_matches(struct vm_area_struct *vma, struct file *filp,if (vma->vm_file != filp)return false; -return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size; +return vma->vm_start == addr && + (vma->vm_end - vma->vm_start) ==PAGE_ALIGN (size); }/**
Signature · 8 lines
2.19.1 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Greg Kroah-Hartman
maintainerPATCH 212/280 bpf: only test gso type on gso packets
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 4c3024debf62de4c6ac6d3cb4c0063be21d4f652 ]
BPF can adjust gso only for tcp bytestreams. Fail on other gso types.
But only on gso packets. It does not touch this field if !gso_size.
--- include/linux/skbuff.h | 4 ++-- net/core/filter.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
include/linux/skbuff.h +2 -2
@@ -4086,10 +4086,10 @@ static inline bool skb_is_gso_sctp(const struct sk_buff *skb)return skb_shinfo (skb)->gso_type &SKB_GSO_SCTP ; } +/* Note: Should be called only if skb_is_gso(skb) is true */ static inline bool skb_is_gso_tcp (const struct sk_buff *skb) { -return skb_is_gso (skb) && -skb_shinfo (skb)->gso_type & (SKB_GSO_TCPV4 |SKB_GSO_TCPV6 ); +return skb_shinfo (skb)->gso_type & (SKB_GSO_TCPV4 |SKB_GSO_TCPV6 ); }static inline void skb_gso_reset (struct sk_buff *skb)
net/core/filter.c +4 -4
@@ -2614,7 +2614,7 @@ static int bpf_skb_proto_4_to_6(struct sk_buff *skb)u32 off =skb_mac_header_len (skb);int ret; -if (!skb_is_gso_tcp (skb)) +if (skb_is_gso (skb) && !skb_is_gso_tcp (skb))return -ENOTSUPP ; ret =skb_cow (skb, len_diff);
@@ -2655,7 +2655,7 @@ static int bpf_skb_proto_6_to_4(struct sk_buff *skb)u32 off =skb_mac_header_len (skb);int ret; -if (!skb_is_gso_tcp (skb)) +if (skb_is_gso (skb) && !skb_is_gso_tcp (skb))return -ENOTSUPP ; ret =skb_unclone (skb,GFP_ATOMIC );
@@ -2780,7 +2780,7 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 len_diff)u32 off =skb_mac_header_len (skb) +bpf_skb_net_base_len (skb);int ret; -if (!skb_is_gso_tcp (skb)) +if (skb_is_gso (skb) && !skb_is_gso_tcp (skb))return -ENOTSUPP ; ret =skb_cow (skb, len_diff);
@@ -2809,7 +2809,7 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 len_diff)u32 off =skb_mac_header_len (skb) +bpf_skb_net_base_len (skb);int ret; -if (!skb_is_gso_tcp (skb)) +if (skb_is_gso (skb) && !skb_is_gso_tcp (skb))return -ENOTSUPP ; ret =skb_unclone (skb,GFP_ATOMIC );
Signature · 1 line
2.19.1
Greg Kroah-Hartman
maintainerPATCH 213/280 serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFO
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anssi Hannula <[email protected]>
commit 7abab1605139bc41442864c18f9573440f7ca105 upstream.
If RX is disabled while there are still unprocessed bytes in RX FIFO, cdns_uart_handle_rx() called from interrupt handler will get stuck in the receive loop as read bytes will not get removed from the RX FIFO and CDNS_UART_SR_RXEMPTY bit will never get set.
Avoid the stuck handler by checking first if RX is disabled. port->lock protects against race with RX-disabling functions.
This HW behavior was mentioned by Nathan Rossi in 43e98facc4a3 ("tty:
xuartps: Fix RX hang, and TX corruption in termios call") which fixed a similar issue in cdns_uart_set_termios().
The behavior can also be easily verified by e.g. setting CDNS_UART_CR_RX_DIS at the beginning of cdns_uart_handle_rx() - the following loop will then get stuck.
Resetting the FIFO using RXRST would not set RXEMPTY either so simply issuing a reset after RX-disable would not work.
I observe this frequently on a ZynqMP board during heavy RX load at 1M baudrate when the reader process exits and thus RX gets disabled.
--- drivers/tty/serial/xilinx_uartps.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/tty/serial/xilinx_uartps.c +7 -1
@@ -362,7 +362,13 @@ static irqreturn_t cdns_uart_isr(int irqcdns_uart_handle_tx (dev_id); isrstatus &= ~CDNS_UART_IXR_TXEMPTY ; } -if (isrstatus &CDNS_UART_IXR_RXMASK ) + +/* +* Skip RX processing if RX is disabled as RXEMPTY will never be set +* as read bytes will not be removed from the FIFO. +*/ +if (isrstatus &CDNS_UART_IXR_RXMASK && + !(readl (port->membase +CDNS_UART_CR ) &CDNS_UART_CR_RX_DIS ))cdns_uart_handle_rx (dev_id, isrstatus);spin_unlock (&port->lock);
Greg Kroah-Hartman
maintainerPATCH 214/280 serial: 8250_of: assume reg-shift of 2 for mrvl,mmp-uart
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lubomir Rintel <[email protected]>
commit f4817843e39ce78aace0195a57d4e8500a65a898 upstream.
There are two other drivers that bind to mrvl,mmp-uart and both of them assume register shift of 2 bits. There are device trees that lack the property and rely on that assumption.
If this driver wins the race to bind to those devices, it should behave the same as the older deprecated driver.
--- drivers/tty/serial/8250/8250_of.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/tty/serial/8250/8250_of.c +4 -0
@@ -130,6 +130,10 @@ static int of_platform_serial_setup(stru port->flags |=UPF_IOREMAP ; } +/* Compatibility with the deprecated pxa driver and 8250_pxa drivers. */ +if (of_device_is_compatible (np,"mrvl,mmp-uart" )) + port->regshift =2 ; +/* Check for registers offset within the devices address range */ if (of_property_read_u32 (np,"reg-shift" , &prop) ==0 ) port->regshift = prop;
Greg Kroah-Hartman
maintainerPATCH 215/280 serial: 8250_pci: Fix number of ports for ACCES serial cards
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Dolan <[email protected]>
commit b896b03bc7fce43a07012cc6bf5e2ab2fddf3364 upstream.
Have the correct number of ports created for ACCES serial cards. Two port cards show up as four ports, and four port cards show up as eight.
--- drivers/tty/serial/8250/8250_pci.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-)
drivers/tty/serial/8250/8250_pci.c +18 -18
@@ -4575,10 +4575,10 @@ static const struct pci_device_id serial*/ {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_COM_2SDB ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_COM_2S,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SDB,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 },
@@ -4587,10 +4587,10 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7954 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_COM232_2DB ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_COM232_2,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM232_4DB,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 },
@@ -4599,10 +4599,10 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7954 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_COM_2SMDB ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_COM_2SM,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SMDB,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 },
@@ -4611,13 +4611,13 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7954 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_MPCIE_ICM485_1 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7951 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_ICM422_2,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_ICM485_2,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_ICM422_4,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 },
@@ -4626,16 +4626,16 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7954 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_ICM_2S ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_2,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_MPCIE_ICM232_2,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7954 },
@@ -4644,13 +4644,13 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7954 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_ICM_2SM ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7954 }, + pbn_pericom_PI7C9X7952 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM422_4,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7958 }, + pbn_pericom_PI7C9X7954 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM485_4,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7958 }, + pbn_pericom_PI7C9X7954 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM422_8,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7958 },
@@ -4659,19 +4659,19 @@ static const struct pci_device_id serial pbn_pericom_PI7C9X7958 }, {PCI_VENDOR_ID_ACCESIO ,PCI_DEVICE_ID_ACCESIO_PCIE_COM232_4 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7958 }, + pbn_pericom_PI7C9X7954 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM232_8,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7958 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SM,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7958 }, + pbn_pericom_PI7C9X7954 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_COM_8SM,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , pbn_pericom_PI7C9X7958 }, { PCI_VENDOR_ID_ACCESIO, PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4SM,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 , - pbn_pericom_PI7C9X7958 }, + pbn_pericom_PI7C9X7954 },/* * Topic TP560 Data/Fax/Voice 56k modem (reported by Evan Clarke) */
Greg Kroah-Hartman
maintainerPATCH 216/280 serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Dolan <[email protected]>
commit 78d3820b9bd39028727c6aab7297b63c093db343 upstream.
The four port Pericom chips have the fourth port at the wrong address. Make use of quirk to fix it.
--- drivers/tty/serial/8250/8250_pci.c | 105 +++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+)
drivers/tty/serial/8250/8250_pci.c +105 -0
@@ -2027,6 +2027,111 @@ static struct pci_serial_quirk pci_seria .setup = pci_default_setup, .exit = pci_plx9050_exit, }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SDB, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_COM_4S, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM232_4DB, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_COM232_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SMDB, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_COM_4SM, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_ICM422_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_ICM485_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_MPCIE_ICM232_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM422_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM485_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM232_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_COM_4SM, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4SM, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup, + }, /* * SBS Technologies, Inc., PMC-OCTALPRO 232 */
Greg Kroah-Hartman
maintainerPATCH 217/280 jbd2: clear dirty flag when revoking a buffer from an older transaction
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhangyi (F) <[email protected]>
commit 904cdbd41d749a476863a0ca41f6f396774f26e4 upstream.
Now, we capture a data corruption problem on ext4 while we're truncating an extent index block. Imaging that if we are revoking a buffer which has been journaled by the committing transaction, the buffer's jbddirty flag will not be cleared in jbd2_journal_forget(), so the commit code will set the buffer dirty flag again after refile the buffer.
fsx kjournald2
jbd2_journal_commit_transactionjbd2_journal_revoke commit phase 1~5...
jbd2_journal_forget
belongs to older transaction commit phase 6
jbddirty not clear __jbd2_journal_refile_buffer
__jbd2_journal_unfile_buffer
test_clear_buffer_jbddirty
mark_buffer_dirty
Finally, if the freed extent index block was allocated again as data block by some other files, it may corrupt the file data after writing cached pages later, such as during unmount time. (In general, clean_bdev_aliases() related helpers should be invoked after re-allocation to prevent the above corruption, but unfortunately we missed it when zeroout the head of extra extent blocks in ext4_ext_handle_unwritten_extents()).
This patch mark buffer as freed and set j_next_transaction to the new transaction when it already belongs to the committing transaction in jbd2_journal_forget(), so that commit code knows it should clear dirty bits when it is done with the buffer.
This problem can be reproduced by xfstests generic/455 easily with seeds (3246 3247 3248 3249).
--- fs/jbd2/transaction.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
fs/jbd2/transaction.c +12 -5
@@ -1576,14 +1576,21 @@ int jbd2_journal_forget (handle_t *handl/* However, if the buffer is still owned by a prior * (committing) transaction, we can't drop it yet... */ JBUFFER_TRACE (jh,"belongs to older transaction" ); -/* ... but we CAN drop it from the new transaction if we -* have also modified it since the original commit. */ +/* ... but we CAN drop it from the new transaction through +* marking the buffer as freed and set j_next_transaction to +* the new transaction, so that not only the commit code +* knows it should clear dirty bits when it is done with the +* buffer, but also the buffer can be checkpointed only +* after the new transaction commits. */ -if (jh->b_next_transaction) { -J_ASSERT (jh->b_next_transaction == transaction); +set_buffer_freed (bh); + +if (!jh->b_next_transaction) {spin_lock (&journal->j_list_lock); - jh->b_next_transaction =NULL ; + jh->b_next_transaction = transaction;spin_unlock (&journal->j_list_lock); + }else { +J_ASSERT (jh->b_next_transaction == transaction);/* * only drop a reference if this transaction modified
Greg Kroah-Hartman
maintainerPATCH 218/280 jbd2: fix compile warning when using JBUFFER_TRACE
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhangyi (F) <[email protected]>
commit 01215d3edb0f384ddeaa5e4a22c1ae5ff634149f upstream.
The jh pointer may be used uninitialized in the two cases below and the compiler complain about it when enabling JBUFFER_TRACE macro, fix them.
In file included from fs/jbd2/transaction.c:19:0:fs/jbd2/transaction.c: In function ‘jbd2_journal_get_undo_access’:./include/linux/jbd2.h:1637:38: warning: ‘jh’ is used uninitialized in this function [-Wuninitialized]
#define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0)
^
fs/jbd2/transaction.c:1219:23: note: ‘jh’ was declared here
struct journal_head *jh;
^
In file included from fs/jbd2/transaction.c:19:0:
fs/jbd2/transaction.c: In function ‘jbd2_journal_dirty_metadata’:
./include/linux/jbd2.h:1637:38: warning: ‘jh’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0)
^
fs/jbd2/transaction.c:1332:23: note: ‘jh’ was declared here
struct journal_head *jh;
^--- fs/jbd2/transaction.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
fs/jbd2/transaction.c +8 -8
@@ -1219,11 +1219,12 @@ int jbd2_journal_get_undo_access(handle_struct journal_head *jh;char *committed_data =NULL ; -JBUFFER_TRACE (jh,"entry" );if (jbd2_write_access_granted (handle, bh, true))return 0 ; jh =jbd2_journal_add_journal_head (bh); +JBUFFER_TRACE (jh,"entry" ); +/* * Do this first --- it can drop the journal lock, so we want to * make sure that obtaining the committed_data is done
@@ -1334,15 +1335,17 @@ int jbd2_journal_dirty_metadata(handle_tif (is_handle_aborted (handle))return -EROFS ; -if (!buffer_jbd (bh)) { - ret = -EUCLEAN ; - goto out; - } +if (!buffer_jbd (bh)) +return -EUCLEAN ; +/* * We don't grab jh reference here since the buffer must be part * of the running transaction. */ jh =bh2jh (bh); +jbd_debug (5 ,"journal_head %p\n" , jh); +JBUFFER_TRACE (jh,"entry" ); +/* * This and the following assertions are unreliable since we may see jh * in inconsistent state unless we grab bh_state lock. But this is
@@ -1376,9 +1379,6 @@ int jbd2_journal_dirty_metadata(handle_t } journal = transaction->t_journal; -jbd_debug (5 ,"journal_head %p\n" , jh); -JBUFFER_TRACE (jh,"entry" ); -jbd_lock_bh_state (bh);if (jh->b_modified ==0 ) {
Greg Kroah-Hartman
maintainerPATCH 219/280 selinux: add the missing walk_size + len check in selinux_sctp_bind_connect
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
commit 292c997a1970f8d1e1dfa354ed770a22f7b5a434 upstream.
As does in __sctp_connect(), when checking addrs in a while loop, after get the addr len according to sa_family, it's necessary to do the check walk_size + af->sockaddr_len > addrs_size to make sure it won't access an out-of-bounds addr.
The same thing is needed in selinux_sctp_bind_connect(), otherwise an out-of-bounds issue can be triggered:
[14548.772313] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x1aa/0x1f0 [14548.927083] Call Trace: [14548.938072] dump_stack+0x9a/0xe9 [14548.953015] print_address_description+0x65/0x22e [14548.996524] kasan_report.cold.6+0x92/0x1a6 [14549.015335] selinux_sctp_bind_connect+0x1aa/0x1f0 [14549.036947] security_sctp_bind_connect+0x58/0x90 [14549.058142] __sctp_setsockopt_connectx+0x5a/0x150 [sctp] [14549.081650] sctp_setsockopt.part.24+0x1322/0x3ce0 [sctp]
--- security/selinux/hooks.c | 3 +++ 1 file changed, 3 insertions(+)
security/selinux/hooks.c +3 -0
@@ -5334,6 +5334,9 @@ static int selinux_sctp_bind_connect(strreturn -EINVAL ; } +if (walk_size + len > addrlen) +return -EINVAL ; + err = -EINVAL ;switch (optname) {/* Bind checks */
Greg Kroah-Hartman
maintainerPATCH 220/280 security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit 3815a245b50124f0865415dcb606a034e97494d4 upstream.
In the case when we're reusing a superblock, selinux_sb_clone_mnt_opts() fails to set set_kern_flags, with the result that nfs_clone_sb_security() incorrectly clears NFS_CAP_SECURITY_LABEL.
The result is that if you mount the same NFS filesystem twice, NFS security labels are turned off, even if they would work fine if you mounted the filesystem only once.
("fixes" may be not exactly the right tag, it may be more like "fixed-other-cases-but-missed-this-one".)
--- security/selinux/hooks.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
security/selinux/hooks.c +4 -1
@@ -1034,8 +1034,11 @@ static int selinux_sb_clone_mnt_opts(conBUG_ON (!(oldsbsec->flags &SE_SBINITIALIZED ));/* if fs is reusing a sb, make sure that the contexts match */ -if (newsbsec->flags &SE_SBINITIALIZED ) +if (newsbsec->flags &SE_SBINITIALIZED ) { +if ((kern_flags &SECURITY_LSM_NATIVE_LABELS ) && !set_context) + *set_kern_flags |=SECURITY_LSM_NATIVE_LABELS ;return selinux_cmp_sb_context (oldsb, newsb); + }mutex_lock (&newsbsec->lock);
Greg Kroah-Hartman
maintainerPATCH 221/280 powerpc/32: Clear on-stack exception marker upon exception return
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff upstream.
Clear the on-stack STACK_FRAME_REGS_MARKER on exception exit in order to avoid confusing stacktrace like the one below.
Call Trace:
[c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable)
[c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180
[c0e9dd10] [c0895130] memchr+0x24/0x74
[c0e9dd30] [c00a9e38] msg_print_text+0x124/0x574
[c0e9dde0] [c00ab710] console_unlock+0x114/0x4f8
[c0e9de40] [c00adc60] vprintk_emit+0x188/0x1c4
--- interrupt: c0e9df00 at 0x400f330
LR = init_stack+0x1f00/0x2000
[c0e9de80] [c00ae3c4] printk+0xa8/0xcc (unreliable)
[c0e9df20] [c0c27e44] early_irq_init+0x38/0x108
[c0e9df50] [c0c15434] start_kernel+0x310/0x488
[c0e9dff0] [00003484] 0x3484With this patch the trace becomes:
Call Trace: [c0e9dca0] [c01c42c0] print_address_description+0x64/0x2bc (unreliable) [c0e9dcd0] [c01c46a4] kasan_report+0xfc/0x180 [c0e9dd10] [c0895150] memchr+0x24/0x74 [c0e9dd30] [c00a9e58] msg_print_text+0x124/0x574 [c0e9dde0] [c00ab730] console_unlock+0x114/0x4f8 [c0e9de40] [c00adc80] vprintk_emit+0x188/0x1c4 [c0e9de80] [c00ae3e4] printk+0xa8/0xcc [c0e9df20] [c0c27e44] early_irq_init+0x38/0x108 [c0e9df50] [c0c15434] start_kernel+0x310/0x488 [c0e9dff0] [00003484] 0x3484
--- arch/powerpc/kernel/entry_32.S | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/powerpc/kernel/entry_32.S +9 -0
@@ -745,6 +745,9 @@ fast_exception_return: mtcr r10 lwz r10,_LINK(r11) mtlr r10 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r11) REST_GPR(10, r11) #if defined(CONFIG_PPC_8xx) && defined(CONFIG_PERF_EVENTS) mtspr SPRN_NRI, r0
@@ -982,6 +985,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRE mtcrf 0xFF,r10 mtlr r11 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r1) /* * Once we put values in SRR0 and SRR1, we are in a state * where exceptions are not recoverable, since taking an
@@ -1021,6 +1027,9 @@ exc_exit_restart_end: mtlr r11 lwz r10,_CCR(r1) mtcrf 0xff,r10 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r1) REST_2GPRS(9, r1) .globl exc_exit_restart exc_exit_restart:
Greg Kroah-Hartman
maintainerPATCH 222/280 powerpc/wii: properly disable use of BATs when requested.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 6d183ca8baec983dc4208ca45ece3c36763df912 upstream.
'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC deny the use of BATS for mapping memory.
This patch makes sure that the specific wii RAM mapping function takes it into account as well.
--- arch/powerpc/platforms/embedded6xx/wii.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/powerpc/platforms/embedded6xx/wii.c +4 -0
@@ -83,6 +83,10 @@ unsigned long __init wii_mmu_mapin_mem2(/* MEM2 64MB@0x10000000 */ delta = wii_hole_start + wii_hole_size; size = top - delta; + +if (__map_without_bats) +return delta; +for (bl =128 <<10 ; bl < max_size; bl <<=1 ) {if (bl *2 > size)break ;
Greg Kroah-Hartman
maintainerPATCH 223/280 powerpc/powernv: Make opal log only readable by root
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jordan Niethe <[email protected]>
commit 7b62f9bd2246b7d3d086e571397c14ba52645ef1 upstream.
Currently the opal log is globally readable. It is kernel policy to limit the visibility of physical addresses / kernel pointers to root. Given this and the fact the opal log may contain this information it would be better to limit the readability to root.
--- arch/powerpc/platforms/powernv/opal-msglog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/platforms/powernv/opal-msglog.c +1 -1
@@ -98,7 +98,7 @@ static ssize_t opal_msglog_read(struct f }static struct bin_attribute opal_msglog_attr = { - .attr = {.name ="msglog" , .mode =0444 }, + .attr = {.name ="msglog" , .mode =0400 }, .read = opal_msglog_read };
Greg Kroah-Hartman
maintainerPATCH 224/280 powerpc/83xx: Also save/restore SPRG4-7 during suspend
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 36da5ff0bea2dc67298150ead8d8471575c54c7d upstream.
The 83xx has 8 SPRG registers and uses at least SPRG4 for DTLB handling LRU.
--- arch/powerpc/platforms/83xx/suspend-asm.S | 34 +++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-)
arch/powerpc/platforms/83xx/suspend-asm.S +27 -7
@@ -26,13 +26,13 @@ #define SS_MSR 0x74 #define SS_SDR1 0x78 #define SS_LR 0x7c -#define SS_SPRG 0x80 /* 4 SPRGs */ -#define SS_DBAT 0x90 /* 8 DBATs */ -#define SS_IBAT 0xd0 /* 8 IBATs */ -#define SS_TB 0x110 -#define SS_CR 0x118 -#define SS_GPREG 0x11c /* r12-r31 */ -#define STATE_SAVE_SIZE 0x16c +#define SS_SPRG 0x80 /* 8 SPRGs */ +#define SS_DBAT 0xa0 /* 8 DBATs */ +#define SS_IBAT 0xe0 /* 8 IBATs */ +#define SS_TB 0x120 +#define SS_CR 0x128 +#define SS_GPREG 0x12c /* r12-r31 */ +#define STATE_SAVE_SIZE 0x17c .section .data .align 5
@@ -103,6 +103,16 @@ _GLOBAL(mpc83xx_enter_deep_sleep) stw r7, SS_SPRG+12(r3) stw r8, SS_SDR1(r3) + mfspr r4, SPRN_SPRG4 + mfspr r5, SPRN_SPRG5 + mfspr r6, SPRN_SPRG6 + mfspr r7, SPRN_SPRG7 + + stw r4, SS_SPRG+16(r3) + stw r5, SS_SPRG+20(r3) + stw r6, SS_SPRG+24(r3) + stw r7, SS_SPRG+28(r3) + mfspr r4, SPRN_DBAT0U mfspr r5, SPRN_DBAT0L mfspr r6, SPRN_DBAT1U
@@ -493,6 +503,16 @@ mpc83xx_deep_resume: mtspr SPRN_IBAT7U, r6 mtspr SPRN_IBAT7L, r7 + lwz r4, SS_SPRG+16(r3) + lwz r5, SS_SPRG+20(r3) + lwz r6, SS_SPRG+24(r3) + lwz r7, SS_SPRG+28(r3) + + mtspr SPRN_SPRG4, r4 + mtspr SPRN_SPRG5, r5 + mtspr SPRN_SPRG6, r6 + mtspr SPRN_SPRG7, r7 + lwz r4, SS_SPRG+0(r3) lwz r5, SS_SPRG+4(r3) lwz r6, SS_SPRG+8(r3)
Greg Kroah-Hartman
maintainerPATCH 225/280 powerpc/powernv: Dont reprogram SLW image on every KVM guest entry/exit
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Mackerras <[email protected]>
commit 19f8a5b5be2898573a5e1dc1db93e8d40117606a upstream.
Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug", 2017-07-21) added two calls to opal_slw_set_reg() inside pnv_cpu_offline(), with the aim of changing the LPCR value in the SLW image to disable wakeups from the decrementer while a CPU is offline. However, pnv_cpu_offline() gets called each time a secondary CPU thread is woken up to participate in running a KVM guest, that is, not just when a CPU is offlined.
Since opal_slw_set_reg() is a very slow operation (with observed execution times around 20 milliseconds), this means that an offline secondary CPU can often be busy doing the opal_slw_set_reg() call when the primary CPU wants to grab all the secondary threads so that it can run a KVM guest. This leads to messages like "KVM: couldn't grab CPU n" being printed and guest execution failing.
There is no need to reprogram the SLW image on every KVM guest entry and exit. So that we do it only when a CPU is really transitioning between online and offline, this moves the calls to pnv_program_cpu_hotplug_lpcr() into pnv_smp_cpu_kill_self().
--- arch/powerpc/include/asm/powernv.h | 2 ++ arch/powerpc/platforms/powernv/idle.c | 27 ++------------------------- arch/powerpc/platforms/powernv/smp.c | 25 +++++++++++++++++++++++++ 3 files changed, 29 insertions(+), 25 deletions(-)
arch/powerpc/include/asm/powernv.h +2 -0
@@ -23,6 +23,8 @@ extern int pnv_npu2_handle_fault(struct unsigned long *flags, unsigned long *status, int count); +void pnv_program_cpu_hotplug_lpcr (unsigned int cpu,u64 lpcr_val); +void pnv_tm_init (void );#else static inline void powernv_set_nmmu_ptcr (unsigned long ptcr) { }
arch/powerpc/platforms/powernv/idle.c +2 -25
@@ -458,7 +458,8 @@ EXPORT_SYMBOL_GPL(pnv_power9_force_smt4_#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */ #ifdef CONFIG_HOTPLUG_CPU -static void pnv_program_cpu_hotplug_lpcr (unsigned int cpu,u64 lpcr_val) + +void pnv_program_cpu_hotplug_lpcr (unsigned int cpu,u64 lpcr_val) {u64 pir =get_hard_smp_processor_id (cpu);
@@ -481,20 +482,6 @@ unsigned long pnv_cpu_offline(unsigned i {unsigned long srr1;u32 idle_states =pnv_get_supported_cpuidle_states (); -u64 lpcr_val; - -/* -* We don't want to take decrementer interrupts while we are -* offline, so clear LPCR:PECE1. We keep PECE2 (and -* LPCR_PECE_HVEE on P9) enabled as to let IPIs in. -* -* If the CPU gets woken up by a special wakeup, ensure that -* the SLW engine sets LPCR with decrementer bit cleared, else -* the CPU will come back to the kernel due to a spurious -* wakeup. -*/ - lpcr_val =mfspr (SPRN_LPCR ) & ~(u64 )LPCR_PECE1 ; -pnv_program_cpu_hotplug_lpcr (cpu, lpcr_val);__ppc64_runlatch_off ();
@@ -526,16 +513,6 @@ unsigned long pnv_cpu_offline(unsigned i__ppc64_runlatch_on (); -/* -* Re-enable decrementer interrupts in LPCR. -* -* Further, we want stop states to be woken up by decrementer -* for non-hotplug cases. So program the LPCR via stop api as -* well. -*/ - lpcr_val =mfspr (SPRN_LPCR ) | (u64 )LPCR_PECE1 ; -pnv_program_cpu_hotplug_lpcr (cpu, lpcr_val); - return srr1; }#endif
arch/powerpc/platforms/powernv/smp.c +25 -0
@@ -39,6 +39,7 @@#include <asm/cpuidle.h> #include <asm/kexec.h> #include <asm/reg.h> +#include <asm/powernv.h> #include "powernv.h"
@@ -153,6 +154,7 @@ static void pnv_smp_cpu_kill_self(void) {unsigned int cpu;unsigned long srr1, wmask; +u64 lpcr_val;/* Standard hot unplug procedure */ /*
@@ -174,6 +176,19 @@ static void pnv_smp_cpu_kill_self(void)if (cpu_has_feature (CPU_FTR_ARCH_207S )) wmask =SRR1_WAKEMASK_P8 ; +/* +* We don't want to take decrementer interrupts while we are +* offline, so clear LPCR:PECE1. We keep PECE2 (and +* LPCR_PECE_HVEE on P9) enabled so as to let IPIs in. +* +* If the CPU gets woken up by a special wakeup, ensure that +* the SLW engine sets LPCR with decrementer bit cleared, else +* the CPU will come back to the kernel due to a spurious +* wakeup. +*/ + lpcr_val =mfspr (SPRN_LPCR ) & ~(u64 )LPCR_PECE1 ; +pnv_program_cpu_hotplug_lpcr (cpu, lpcr_val); +while (!generic_check_cpu_restart (cpu)) {/* * Clear IPI flag, since we don't handle IPIs while
@@ -246,6 +261,16 @@ static void pnv_smp_cpu_kill_self(void) } +/* +* Re-enable decrementer interrupts in LPCR. +* +* Further, we want stop states to be woken up by decrementer +* for non-hotplug cases. So program the LPCR via stop api as +* well. +*/ + lpcr_val =mfspr (SPRN_LPCR ) | (u64 )LPCR_PECE1 ; +pnv_program_cpu_hotplug_lpcr (cpu, lpcr_val); +DBG ("CPU%d coming online...\n" , cpu); }
Greg Kroah-Hartman
maintainerPATCH 226/280 powerpc: Fix 32-bit KVM-PR lockup and host crash with MacOS guest
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Cave-Ayland <[email protected]>
commit fe1ef6bcdb4fca33434256a802a3ed6aacf0bd2f upstream.
Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving it up" unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR MacOS guest to lockup and panic the host kernel.
Leaving FE0/1 enabled means unrelated processes might receive FPEs when they're not expecting them and crash. In particular if this happens to init the host will then panic.
eg (transcribed):
qemu-system-ppc[837]: unhandled signal 8 at 12cc9ce4 nip 12cc9ce4 lr 12cc9ca4 code 0 systemd[1]: unhandled signal 8 at 202f02e0 nip 202f02e0 lr 001003d4 code 0
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Reinstate these bits to the MSR bitmask to enable MacOS guests to run under 32-bit KVM-PR once again without issue.
--- arch/powerpc/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/process.c +1 -1
@@ -180,7 +180,7 @@ static void __giveup_fpu(struct task_strsave_fpu (tsk); msr = tsk->thread.regs->msr; - msr &= ~MSR_FP ; + msr &= ~(MSR_FP |MSR_FE0 |MSR_FE1 );#ifdef CONFIG_VSX if (cpu_has_feature (CPU_FTR_VSX )) msr &= ~MSR_VSX ;
Greg Kroah-Hartman
maintainerPATCH 227/280 powerpc/ptrace: Simplify vr_get/set() to avoid GCC warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
commit ca6d5149d2ad0a8d2f9c28cbe379802260a0a5e0 upstream.
GCC 8 warns about the logic in vr_get/set(), which with -Werror breaks the build:
In function ‘user_regset_copyin’,
inlined from ‘vr_set’ at arch/powerpc/kernel/ptrace.c:628:9:
include/linux/regset.h:295:4: error: ‘memcpy’ offset [-527, -529] is out of the bounds [0, 16] of object ‘vrsave’ with type ‘union <anonymous>’ [-Werror=array-bounds] arch/powerpc/kernel/ptrace.c: In function ‘vr_set’:
arch/powerpc/kernel/ptrace.c:623:5: note: ‘vrsave’ declared here
} vrsave;
This has been identified as a regression in GCC, see GCC bug 88273.
However we can avoid the warning and also simplify the logic and make it more robust.
Currently we pass -1 as end_pos to user_regset_copyout(). This says "copy up to the end of the regset".
The definition of the regset is:
[REGSET_VMX] = {
.core_note_type = NT_PPC_VMX, .n = 34,
.size = sizeof(vector128), .align = sizeof(vector128),
.active = vr_active, .get = vr_get, .set = vr_set
},The end is calculated as (n * size), ie. 34 * sizeof(vector128).
In vr_get/set() we pass start_pos as 33 * sizeof(vector128), meaning we can copy up to sizeof(vector128) into/out-of vrsave.
The on-stack vrsave is defined as:
union {
elf_vrreg_t reg;
u32 word;} vrsave;
And elf_vrreg_t is:
typedef __vector128 elf_vrreg_t;
So there is no bug, but we rely on all those sizes lining up, otherwise we would have a kernel stack exposure/overwrite on our hands.
Rather than relying on that we can pass an explict end_pos based on the sizeof(vrsave). The result should be exactly the same but it's more obviously not over-reading/writing the stack and it avoids the compiler warning.
--- arch/powerpc/kernel/ptrace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
arch/powerpc/kernel/ptrace.c +8 -2
@@ -561,6 +561,7 @@ static int vr_get(struct task_struct *ta/* * Copy out only the low-order word of vrsave. */ +int start, end;union {elf_vrreg_t reg;u32 word;
@@ -569,8 +570,10 @@ static int vr_get(struct task_struct *ta vrsave.word = target->thread.vrsave; + start =33 *sizeof (vector128); + end = start +sizeof (vrsave); ret =user_regset_copyout (&pos, &count, &kbuf, &ubuf, &vrsave, -33 *sizeof (vector128),-1 ); + start, end); }return ret;
@@ -608,6 +611,7 @@ static int vr_set(struct task_struct *ta/* * We use only the first word of vrsave. */ +int start, end;union {elf_vrreg_t reg;u32 word;
@@ -616,8 +620,10 @@ static int vr_set(struct task_struct *ta vrsave.word = target->thread.vrsave; + start =33 *sizeof (vector128); + end = start +sizeof (vrsave); ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, &vrsave, -33 *sizeof (vector128),-1 ); + start, end);if (!ret) target->thread.vrsave = vrsave.word; }
Greg Kroah-Hartman
maintainerPATCH 228/280 powerpc/hugetlb: Dont do runtime allocation of 16G pages in LPAR configuration
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aneesh Kumar K.V <[email protected]>
commit 35f2806b481f5b9207f25e1886cba5d1c4d12cc7 upstream.
We added runtime allocation of 16G pages in commit 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") That was done to enable 16G allocation on PowerNV and KVM config. In case of KVM config, we mostly would have the entire guest RAM backed by 16G hugetlb pages for this to work. PAPR do support partial backing of guest RAM with hugepages via ibm,expected#pages node of memory node in the device tree. This means rest of the guest RAM won't be backed by 16G contiguous pages in the host and hence a hash page table insertion can fail in such case.
An example error message will look like
hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback
hash-mmu: trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386
readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2
This patch address that by preventing runtime allocation of 16G hugepages in LPAR config. To allocate 16G hugetlb one need to kernel command line hugepagesz=16G hugepages=<number of 16G pages>
With radix translation mode we don't run into this issue.
This change will prevent runtime allocation of 16G hugetlb pages on kvm with hash translation mode. However, with the current upstream it was observed that 16G hugetlbfs backed guest doesn't boot at all.
We observe boot failure with the below message:
[131354.647546] KVM: map_vrma at 0 failed, ret=-4
That means this patch is not resulting in an observable regression. Once we fix the boot issue with 16G hugetlb backed memory, we need to use ibm,expected#pages memory node attribute to indicate 16G page reservation to the guest. This will also enable partial backing of guest RAM with 16G pages.
--- arch/powerpc/include/asm/book3s/64/hugetlb.h | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/powerpc/include/asm/book3s/64/hugetlb.h +8 -0
@@ -35,6 +35,14 @@ static inline int hstate_get_psize(struc#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE static inline bool gigantic_page_supported (void ) { +/* +* We used gigantic page reservation with hypervisor assist in some case. +* We cannot use runtime allocation of gigantic pages in those platforms +* This is hash translation mode LPARs. +*/ +if (firmware_has_feature (FW_FEATURE_LPAR ) && !radix_enabled ()) +return false; +return true; }#endif
Greg Kroah-Hartman
maintainerPATCH 229/280 powerpc/traps: fix recoverability of machine check handling on book3s/32
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 0bbea75c476b77fa7d7811d6be911cc7583e640f upstream.
Looks like book3s/32 doesn't set RI on machine check, so checking RI before calling die() will always be fatal allthought this is not an issue in most cases.
--- arch/powerpc/kernel/traps.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/powerpc/kernel/traps.c +4 -4
@@ -767,15 +767,15 @@ void machine_check_exception(struct pt_rif (check_io_access (regs)) goto bail; -/* Must die if the interrupt is not recoverable */ -if (!(regs->msr &MSR_RI )) -nmi_panic (regs,"Unrecoverable Machine check" ); -if (!nested)nmi_exit ();die ("Machine check" , regs,SIGBUS ); +/* Must die if the interrupt is not recoverable */ +if (!(regs->msr &MSR_RI )) +nmi_panic (regs,"Unrecoverable Machine check" ); +return ; bail:
Greg Kroah-Hartman
maintainerPATCH 230/280 powerpc/traps: Fix the message printed when stack overflows
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 9bf3d3c4e4fd82c7174f4856df372ab2a71005b9 upstream.
Today's message is useless:
[ 42.253267] Kernel stack overflow in process (ptrval), r1=c65500b0
This patch fixes it:
[ 66.905235] Kernel stack overflow in process sh[356], r1=c65560b0
--- arch/powerpc/kernel/traps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/kernel/traps.c +2 -2
@@ -1545,8 +1545,8 @@ bail:void StackOverflow (struct pt_regs *regs) { -printk (KERN_CRIT "Kernel stack overflow in process %p, r1=%lx\n" , - current, regs->gpr[1 ]); +pr_crit ("Kernel stack overflow in process %s[%d], r1=%lx\n" , + current->comm,task_pid_nr (current), regs->gpr[1 ]);debugger (regs);show_regs (regs);panic ("kernel stack overflow" );
Greg Kroah-Hartman
maintainerPATCH 231/280 ARM: s3c24xx: Fix boolean expressions in osiris_dvs_notify
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit e2477233145f2156434afb799583bccd878f3e9f upstream.
Fix boolean expressions by using logical AND operator '&&' instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
--- arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/mach-s3c24xx/mach-osiris-dvs.c +4 -4
@@ -65,16 +65,16 @@ static int osiris_dvs_notify(struct notiswitch (val) {case CPUFREQ_PRECHANGE : -if (old_dvs & !new_dvs || - cur_dvs & !new_dvs) { +if ((old_dvs && !new_dvs) || + (cur_dvs && !new_dvs)) {pr_debug ("%s: exiting dvs\n" , __func__); cur_dvs = false;gpio_set_value (OSIRIS_GPIO_DVS ,1 ); }break ;case CPUFREQ_POSTCHANGE : -if (!old_dvs & new_dvs || - !cur_dvs & new_dvs) { +if ((!old_dvs && new_dvs) || + (!cur_dvs && new_dvs)) {pr_debug ("entering dvs\n" ); cur_dvs = true;gpio_set_value (OSIRIS_GPIO_DVS ,0 );
Greg Kroah-Hartman
maintainerPATCH 232/280 arm64: Fix HCR.TGE status for NMI contexts
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julien Thierry <[email protected]>
commit 5870970b9a828d8693aa6d15742573289d7dbcd0 upstream.
When using VHE, the host needs to clear HCR_EL2.TGE bit in order to interact with guest TLBs, switching from EL2&0 translation regime to EL1&0.
However, some non-maskable asynchronous event could happen while TGE is cleared like SDEI. Because of this address translation operations relying on EL2&0 translation regime could fail (tlb invalidation, userspace access, ...).
Fix this by properly setting HCR_EL2.TGE when entering NMI context and clear it if necessary when returning to the interrupted context.
--- arch/arm64/include/asm/hardirq.h | 31 +++++++++++++++++++++++++++++++ arch/arm64/kernel/irq.c | 3 +++ include/linux/hardirq.h | 7 +++++++ 3 files changed, 41 insertions(+)
arch/arm64/include/asm/hardirq.h +31 -0
@@ -17,8 +17,12 @@#define __ASM_HARDIRQ_H#include <linux/cache.h> +#include <linux/percpu.h> #include <linux/threads.h> +#include <asm/barrier.h> #include <asm/irq.h> +#include <asm/kvm_arm.h> +#include <asm/sysreg.h> #define NR_IPI 7
@@ -37,6 +41,33 @@ u64 smp_irq_stat_cpu(unsigned int cpu);#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1 +struct nmi_ctx { +u64 hcr; +}; + +DECLARE_PER_CPU(struct nmi_ctx, nmi_contexts); + +#define arch_nmi_enter () \ + do { \ + if (is_kernel_in_hyp_mode()) { \ + struct nmi_ctx *nmi_ctx = this_cpu_ptr(&nmi_contexts); \ + nmi_ctx->hcr = read_sysreg(hcr_el2); \ + if (!(nmi_ctx->hcr & HCR_TGE)) { \ + write_sysreg(nmi_ctx->hcr | HCR_TGE, hcr_el2); \ + isb(); \ + } \ + } \ + } while (0) + +#define arch_nmi_exit () \ + do { \ + if (is_kernel_in_hyp_mode()) { \ + struct nmi_ctx *nmi_ctx = this_cpu_ptr(&nmi_contexts); \ + if (!(nmi_ctx->hcr & HCR_TGE)) \ + write_sysreg(nmi_ctx->hcr, hcr_el2); \ + } \ + } while (0) +static inline void ack_bad_irq (unsigned int irq) {extern unsigned long irq_err_count;
arch/arm64/kernel/irq.c +3 -0
@@ -33,6 +33,9 @@unsigned long irq_err_count; +/* Only access this in an NMI enter/exit */ +DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts); + DEFINE_PER_CPU(unsigned long *, irq_stack_ptr);int arch_show_interrupts (struct seq_file *p,int prec)
include/linux/hardirq.h +7 -0
@@ -60,8 +60,14 @@ extern void irq_enter(void);*/ extern void irq_exit (void ); +#ifndef arch_nmi_enter +#define arch_nmi_enter () do { } while (0) +#define arch_nmi_exit () do { } while (0) +#endif +#define nmi_enter () \ do { \ + arch_nmi_enter(); \ printk_nmi_enter(); \ lockdep_off(); \ ftrace_nmi_enter(); \
@@ -80,6 +86,7 @@ extern void irq_exit(void);ftrace_nmi_exit (); \lockdep_on (); \printk_nmi_exit (); \ +arch_nmi_exit (); \ } while (0)#endif /* LINUX_HARDIRQ_H */
Greg Kroah-Hartman
maintainerPATCH 233/280 arm64: debug: Ensure debug handlers check triggering exception level
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 6bd288569b50bc89fa5513031086746968f585cb upstream.
Debug exception handlers may be called for exceptions generated both by user and kernel code. In many cases, this is checked explicitly, but in other cases things either happen to work by happy accident or they go slightly wrong. For example, executing 'brk #4' from userspace will enter the kprobes code and be ignored, but the instruction will be retried forever in userspace instead of delivering a SIGTRAP.
Fix this issue in the most stable-friendly fashion by simply adding explicit checks of the triggering exception level to all of our debug exception handlers.
--- arch/arm64/kernel/kgdb.c | 14 ++++++++++---- arch/arm64/kernel/probes/kprobes.c | 6 ++++++ 2 files changed, 16 insertions(+), 4 deletions(-)
arch/arm64/kernel/kgdb.c +10 -4
@@ -244,27 +244,33 @@ int kgdb_arch_handle_exception(int excepstatic int kgdb_brk_fn (struct pt_regs *regs,unsigned int esr) { +if (user_mode (regs)) +return DBG_HOOK_ERROR ; +kgdb_handle_exception (1 ,SIGTRAP ,0 , regs); -return 0 ; +return DBG_HOOK_HANDLED ; }NOKPROBE_SYMBOL (kgdb_brk_fn) static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr) { +if (user_mode (regs)) +return DBG_HOOK_ERROR ; + compiled_break =1 ;kgdb_handle_exception (1 ,SIGTRAP ,0 , regs); -return 0 ; +return DBG_HOOK_HANDLED ; }NOKPROBE_SYMBOL (kgdb_compiled_brk_fn);static int kgdb_step_brk_fn (struct pt_regs *regs,unsigned int esr) { -if (!kgdb_single_step) +if (user_mode (regs) || !kgdb_single_step)return DBG_HOOK_ERROR ;kgdb_handle_exception (1 ,SIGTRAP ,0 , regs); -return 0 ; +return DBG_HOOK_HANDLED ; }NOKPROBE_SYMBOL (kgdb_step_brk_fn);
arch/arm64/kernel/probes/kprobes.c +6 -0
@@ -450,6 +450,9 @@ kprobe_single_step_handler(struct pt_regstruct kprobe_ctlblk *kcb =get_kprobe_ctlblk ();int retval; +if (user_mode (regs)) +return DBG_HOOK_ERROR ; +/* return error if this is not our step */ retval =kprobe_ss_hit (kcb,instruction_pointer (regs));
@@ -466,6 +469,9 @@ kprobe_single_step_handler(struct pt_regint __kprobes kprobe_breakpoint_handler (struct pt_regs *regs,unsigned int esr) { +if (user_mode (regs)) +return DBG_HOOK_ERROR ; +kprobe_handler (regs);return DBG_HOOK_HANDLED ; }
Greg Kroah-Hartman
maintainerPATCH 234/280 arm64: KVM: Fix architecturally invalid reset value for FPEXC32_EL2
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Martin <[email protected]>
commit c88b093693ccbe41991ef2e9b1d251945e6e54ed upstream.
Due to what looks like a typo dating back to the original addition of FPEXC32_EL2 handling, KVM currently initialises this register to an architecturally invalid value.
As a result, the VECITR field (RES1) in bits [10:8] is initialised with 0, and the two reserved (RES0) bits [6:5] are initialised with
1. (In the Common VFP Subarchitecture as specified by ARMv7-A, these two bits were IMP DEF. ARMv8-A removes them.)
This patch changes the reset value from 0x70 to 0x700, which reflects the architectural constraints and is presumably what was originally intended.
--- arch/arm64/kvm/sys_regs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kvm/sys_regs.c +1 -1
@@ -1456,7 +1456,7 @@ static const struct sys_reg_desc sys_reg { SYS_DESC(SYS_DACR32_EL2), NULL, reset_unknown, DACR32_EL2 }, { SYS_DESC(SYS_IFSR32_EL2), NULL, reset_unknown, IFSR32_EL2 }, - { SYS_DESC(SYS_FPEXC32_EL2), NULL, reset_val, FPEXC32_EL2, 0x70 }, + { SYS_DESC(SYS_FPEXC32_EL2), NULL, reset_val, FPEXC32_EL2, 0x700 }, }; static bool trap_dbgidr(struct kvm_vcpu *vcpu,
Greg Kroah-Hartman
maintainerPATCH 235/280 ipmi_si: fix use-after-free of resource->name
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
commit 401e7e88d4ef80188ffa07095ac00456f901b8c4 upstream.
When we excute the following commands, we got oops rmmod ipmi_si
cat /proc/ioports
[ 1623.482380] Unable to handle kernel paging request at virtual address ffff00000901d478 [ 1623.482382] Mem abort info: [ 1623.482383] ESR = 0x96000007 [ 1623.482385] Exception class = DABT (current EL), IL = 32 bits [ 1623.482386] SET = 0, FnV = 0 [ 1623.482387] EA = 0, S1PTW = 0 [ 1623.482388] Data abort info: [ 1623.482389] ISV = 0, ISS = 0x00000007 [ 1623.482390] CM = 0, WnR = 0 [ 1623.482393] swapper pgtable: 4k pages, 48-bit VAs, pgdp = 00000000d7d94a66 [ 1623.482395] [ffff00000901d478] pgd=000000dffbfff003, pud=000000dffbffe003, pmd=0000003f5d06e003, pte=0000000000000000 [ 1623.482399] Internal error: Oops: 96000007 [#1] SMP [ 1623.487407] Modules linked in: ipmi_si(E) nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm dm_mirror dm_region_hash dm_log iw_cm dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ses ghash_ce sha2_ce enclosure sha256_arm64 sg sha1_ce hisi_sas_v2_hw hibmc_drm sbsa_gwdt hisi_sas_main ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe mdio hns_dsaf ipmi_devintf hns_enet_drv ipmi_msghandler hns_mdio [last unloaded: ipmi_si] [ 1623.532410] CPU: 30 PID: 11438 Comm: cat Kdump: loaded Tainted: G E 5.0.0-rc3+ #168 [ 1623.541498] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017 [ 1623.548822] pstate: a0000005 (NzCv daif -PAN -UAO) [ 1623.553684] pc : string+0x28/0x98 [ 1623.557040] lr : vsnprintf+0x368/0x5e8 [ 1623.560837] sp : ffff000013213a80 [ 1623.564191] x29: ffff000013213a80 x28: ffff00001138abb5 [ 1623.569577] x27: ffff000013213c18 x26: ffff805f67d06049 [ 1623.574963] x25: 0000000000000000 x24: ffff00001138abb5 [ 1623.580349] x23: 0000000000000fb7 x22: ffff0000117ed000 [ 1623.585734] x21: ffff000011188fd8 x20: ffff805f67d07000 [ 1623.591119] x19: ffff805f67d06061 x18: ffffffffffffffff [ 1623.596505] x17: 0000000000000200 x16: 0000000000000000 [ 1623.601890] x15: ffff0000117ed748 x14: ffff805f67d07000 [ 1623.607276] x13: ffff805f67d0605e x12: 0000000000000000 [ 1623.612661] x11: 0000000000000000 x10: 0000000000000000 [ 1623.618046] x9 : 0000000000000000 x8 : 000000000000000f [ 1623.623432] x7 : ffff805f67d06061 x6 : fffffffffffffffe [ 1623.628817] x5 : 0000000000000012 x4 : ffff00000901d478 [ 1623.634203] x3 : ffff0a00ffffff04 x2 : ffff805f67d07000 [ 1623.639588] x1 : ffff805f67d07000 x0 : ffffffffffffffff [ 1623.644974] Process cat (pid: 11438, stack limit = 0x000000008d4cbc10) [ 1623.651592] Call trace: [ 1623.654068] string+0x28/0x98 [ 1623.657071] vsnprintf+0x368/0x5e8 [ 1623.660517] seq_vprintf+0x70/0x98 [ 1623.668009] seq_printf+0x7c/0xa0 [ 1623.675530] r_show+0xc8/0xf8 [ 1623.682558] seq_read+0x330/0x440 [ 1623.689877] proc_reg_read+0x78/0xd0 [ 1623.697346] __vfs_read+0x60/0x1a0 [ 1623.704564] vfs_read+0x94/0x150 [ 1623.711339] ksys_read+0x6c/0xd8 [ 1623.717939] __arm64_sys_read+0x24/0x30 [ 1623.725077] el0_svc_common+0x120/0x148 [ 1623.732035] el0_svc_handler+0x30/0x40 [ 1623.738757] el0_svc+0x8/0xc [ 1623.744520] Code: d1000406 aa0103e2 54000149 b4000080 (39400085) [ 1623.753441] ---[ end trace f91b6a4937de9835 ]--- [ 1623.760871] Kernel panic - not syncing: Fatal exception [ 1623.768935] SMP: stopping secondary CPUs [ 1623.775718] Kernel Offset: disabled [ 1623.781998] CPU features: 0x002,21006008 [ 1623.788777] Memory Limit: none [ 1623.798329] Starting crashdump kernel... [ 1623.805202] Bye!
If io_setup is called successful in try_smi_init() but try_smi_init() goes out_err before calling ipmi_register_smi(), so ipmi_unregister_smi() will not be called while removing module. It leads to the resource that allocated in io_setup() can not be freed, but the name(DEVICE_NAME) of resource is freed while removing the module. It causes use-after-free when cat /proc/ioports.
Fix this by calling io_cleanup() while try_smi_init() goes to out_err. and don't call io_cleanup() until io_setup() returns successful to avoid warning prints.
--- drivers/char/ipmi/ipmi_si_intf.c | 5 +++++ drivers/char/ipmi/ipmi_si_mem_io.c | 5 +++-- drivers/char/ipmi/ipmi_si_port_io.c | 5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-)
drivers/char/ipmi/ipmi_si_intf.c +5 -0
@@ -2085,6 +2085,11 @@ static int try_smi_init(struct smi_infoWARN_ON (new_smi->io.dev->init_name !=NULL ); out_err: +if (rv && new_smi->io.io_cleanup) { + new_smi->io.io_cleanup (&new_smi->io); + new_smi->io.io_cleanup =NULL ; + } +kfree (init_name);return rv; }
drivers/char/ipmi/ipmi_si_mem_io.c +3 -2
@@ -81,8 +81,6 @@ int ipmi_si_mem_setup(struct si_sm_io *iif (!addr)return -ENODEV ; - io->io_cleanup = mem_cleanup; -/* * Figure out the actual readb/readw/readl/etc routine to use based * upon the register size.
@@ -141,5 +139,8 @@ int ipmi_si_mem_setup(struct si_sm_io *imem_region_cleanup (io, io->io_size);return -EIO ; } + + io->io_cleanup = mem_cleanup; +return 0 ; }
drivers/char/ipmi/ipmi_si_port_io.c +3 -2
@@ -68,8 +68,6 @@ int ipmi_si_port_setup(struct si_sm_io *if (!addr)return -ENODEV ; - io->io_cleanup = port_cleanup; -/* * Figure out the actual inb/inw/inl/etc routine to use based * upon the register size.
@@ -109,5 +107,8 @@ int ipmi_si_port_setup(struct si_sm_io *return -EIO ; } } + + io->io_cleanup = port_cleanup; +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 236/280 dm: fix to_sector() for 32bit
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 0bdb50c531f7377a9da80d3ce2d61f389c84cb30 upstream.
A dm-raid array with devices larger than 4GB won't assemble on a 32 bit host since _check_data_dev_sectors() was added in 4.16. This is because to_sector() treats its argument as an "unsigned long" which is 32bits (4GB) on a 32bit host. Using "unsigned long long" is more correct.
Kernels as early as 4.2 can have other problems due to to_sector() being used on the size of a device.
--- include/linux/device-mapper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/device-mapper.h +1 -1
@@ -601,7 +601,7 @@ do { \*/ #define dm_target_offset (ti, sector) ((sector) - (ti)->begin) -static inline sector_t to_sector (unsigned long n) +static inline sector_t to_sector (unsigned long long n) {return (n >>SECTOR_SHIFT ); }
Greg Kroah-Hartman
maintainerPATCH 237/280 dm integrity: limit the rate of error messages
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit 225557446856448039a9e495da37b72c20071ef2 upstream.
When using dm-integrity underneath md-raid, some tests with raid auto-correction trigger large amounts of integrity failures - and all these failures print an error message. These messages can bring the system to a halt if the system is using serial console.
Fix this by limiting the rate of error messages - it improves the speed of raid recovery and avoids the hang.
--- drivers/md/dm-integrity.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/md/dm-integrity.c +4 -4
@@ -1357,8 +1357,8 @@ again: checksums_ptr - checksums, !dio->write ? TAG_CMP : TAG_WRITE);if (unlikely (r)) {if (r >0 ) { -DMERR ("Checksum failed at sector 0x%llx" , - (unsigned long long )(sector - ((r + ic->tag_size -1 ) / ic->tag_size))); +DMERR_LIMIT ("Checksum failed at sector 0x%llx" , + (unsigned long long )(sector - ((r + ic->tag_size -1 ) / ic->tag_size))); r = -EILSEQ ;atomic64_inc (&ic->number_of_mismatches); }
@@ -1550,8 +1550,8 @@ retry_kmap:integrity_sector_checksum (ic, logical_sector, mem + bv.bv_offset, checksums_onstack);if (unlikely (memcmp (checksums_onstack,journal_entry_tag (ic, je), ic->tag_size))) { -DMERR ("Checksum failed when reading from journal, at sector 0x%llx" , - (unsigned long long )logical_sector); +DMERR_LIMIT ("Checksum failed when reading from journal, at sector 0x%llx" , + (unsigned long long )logical_sector); } }#endif
Greg Kroah-Hartman
maintainerPATCH 238/280 mfd: sm501: Fix potential NULL pointer dereference
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit ae7b8eda27b33b1f688dfdebe4d46f690a8f9162 upstream.
There is a potential NULL pointer dereference in case devm_kzalloc() fails and returns NULL.
Fix this by adding a NULL check on *lookup*
This bug was detected with the help of Coccinelle.
--- drivers/mfd/sm501.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mfd/sm501.c +3 -0
@@ -1145,6 +1145,9 @@ static int sm501_register_gpio_i2c_insta lookup =devm_kzalloc (&pdev->dev,sizeof (*lookup) +3 *sizeof (struct gpiod_lookup ),GFP_KERNEL ); +if (!lookup) +return -ENOMEM ; + lookup->dev_id ="i2c-gpio" ;if (iic->pin_sda <32 ) lookup->table[0 ].chip_label ="SM501-LOW" ;
Greg Kroah-Hartman
maintainerPATCH 239/280 cpcap-charger: generate events for userspace
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Machek <[email protected]>
commit fd10606f93a149a9f3d37574e5385b083b4a7b32 upstream.
The driver doesn't generate uevents on charger connect/disconnect. This leads to UPower not detecting when AC is on or off... and that is bad.
Reported by Arthur D. on github (
https://github.com/maemo-leste/bugtracker/issues/206 ), thanks to Merlijn Wajer for suggesting a fix.
--- drivers/power/supply/cpcap-charger.c | 1 + 1 file changed, 1 insertion(+)
drivers/power/supply/cpcap-charger.c +1 -0
@@ -458,6 +458,7 @@ static void cpcap_usb_detect(struct work goto out_err; } +power_supply_changed (ddata->usb);return ; out_err:
Greg Kroah-Hartman
maintainerPATCH 240/280 NFS: Fix I/O request leakages
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit f57dcf4c72113c745d83f1c65f7291299f65c14f upstream.
When we fail to add the request to the I/O queue, we currently leave it to the caller to free the failed request. However since some of the requests that fail are actually created by nfs_pageio_add_request() itself, and are not passed back the caller, this leads to a leakage issue, which can again cause page locks to leak.
This commit addresses the leakage by freeing the created requests on error, using desc->pg_completion_ops->error_cleanup()
--- fs/nfs/pagelist.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-)
fs/nfs/pagelist.c +21 -5
@@ -989,6 +989,17 @@ static void nfs_pageio_doio(struct nfs_p } } +static void +nfs_pageio_cleanup_request (struct nfs_pageio_descriptor *desc, +struct nfs_page *req) +{ +LIST_HEAD (head); + +nfs_list_remove_request (req); +nfs_list_add_request (req, &head); + desc->pg_completion_ops->error_cleanup (&head); +} +/** * nfs_pageio_add_request - Attempt to coalesce a request into a page list. * @desc: destination io descriptor
@@ -1026,10 +1037,8 @@ static int __nfs_pageio_add_request(strunfs_page_group_unlock (req); desc->pg_moreio =1 ;nfs_pageio_doio (desc); -if (desc->pg_error <0 ) -return 0 ; -if (mirror->pg_recoalesce) -return 0 ; +if (desc->pg_error <0 || mirror->pg_recoalesce) + goto out_cleanup_subreq;/* retry add_request for this subreq */ nfs_page_group_lock (req);continue ;
@@ -1062,6 +1071,10 @@ err_ptr: desc->pg_error =PTR_ERR (subreq);nfs_page_group_unlock (req);return 0 ; +out_cleanup_subreq: +if (req != subreq) +nfs_pageio_cleanup_request (desc, subreq); +return 0 ; }static int nfs_do_recoalesce (struct nfs_pageio_descriptor *desc)
@@ -1169,11 +1182,14 @@ int nfs_pageio_add_request(struct nfs_paif (nfs_pgio_has_mirroring (desc)) desc->pg_mirror_idx = midx;if (!nfs_pageio_add_request_mirror (desc, dupreq)) - goto out_failed; + goto out_cleanup_subreq; }return 1 ; +out_cleanup_subreq: +if (req != dupreq) +nfs_pageio_cleanup_request (desc, dupreq); out_failed:/* remember fatal errors */ if (nfs_error_is_fatal (desc->pg_error))
Greg Kroah-Hartman
maintainerPATCH 241/280 NFS: Fix an I/O request leakage in nfs_do_recoalesce
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 4d91969ed4dbcefd0e78f77494f0cb8fada9048a upstream.
Whether we need to exit early, or just reprocess the list, we must not lost track of the request which failed to get recoalesced.
--- fs/nfs/pagelist.c | 1 - 1 file changed, 1 deletion(-)
fs/nfs/pagelist.c +0 -1
@@ -1093,7 +1093,6 @@ static int nfs_do_recoalesce(struct nfs_struct nfs_page *req; req = list_first_entry(&head, struct nfs_page, wb_list); -nfs_list_remove_request (req);if (__nfs_pageio_add_request (desc, req))continue ;if (desc->pg_error <0 ) {
Greg Kroah-Hartman
maintainerPATCH 242/280 NFS: Dont recoalesce on error in nfs_pageio_complete_mirror()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 8127d82705998568b52ac724e28e00941538083d upstream.
If the I/O completion failed with a fatal error, then we should just exit nfs_pageio_complete_mirror() rather than try to recoalesce.
--- fs/nfs/pagelist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/pagelist.c +1 -1
@@ -1214,7 +1214,7 @@ static void nfs_pageio_complete_mirror(s desc->pg_mirror_idx = mirror_idx;for (;;) {nfs_pageio_doio (desc); -if (!mirror->pg_recoalesce) +if (desc->pg_error <0 || !mirror->pg_recoalesce)break ;if (!nfs_do_recoalesce (desc))break ;
Greg Kroah-Hartman
maintainerPATCH 243/280 nfsd: fix performance-limiting session calculation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 upstream.
We're unintentionally limiting the number of slots per nfsv4.1 session to 10. Often more than 10 simultaneous RPCs are needed for the best performance.
This calculation was meant to prevent any one client from using up more than a third of the limit we set for total memory use across all clients and sessions. Instead, it's limiting the client to a third of the maximum for a single session.
Fix this.
--- fs/nfsd/nfs4state.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
fs/nfsd/nfs4state.c +4 -4
@@ -1514,16 +1514,16 @@ static u32 nfsd4_get_drc_mem(struct nfsd {u32 slotsize =slot_bytes (ca);u32 num = ca->maxreqs; -int avail; +unsigned long avail, total_avail;spin_lock (&nfsd_drc_lock); - avail =min ((unsigned long )NFSD_MAX_MEM_PER_SESSION , - nfsd_drc_max_mem - nfsd_drc_mem_used); + total_avail = nfsd_drc_max_mem - nfsd_drc_mem_used; + avail =min ((unsigned long )NFSD_MAX_MEM_PER_SESSION , total_avail);/* * Never use more than a third of the remaining memory, * unless it's the only way to give this client a slot: */ - avail =clamp_t (int, avail, slotsize, avail/3 ); + avail =clamp_t (int, avail, slotsize, total_avail/3 ); num =min_t (int, num, avail / slotsize); nfsd_drc_mem_used += num * slotsize;spin_unlock (&nfsd_drc_lock);
Greg Kroah-Hartman
maintainerPATCH 244/280 nfsd: fix memory corruption caused by readdir
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit b602345da6cbb135ba68cf042df8ec9a73da7981 upstream.
If the result of an NFSv3 readdir{,plus} request results in the "offset" on one entry having to be split across 2 pages, and is sized so that the next directory entry doesn't fit in the requested size, then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits, it notices that ->offset and ->offset1 are set, and so stores the offset value in the two pages as required. It clears ->offset1 but *does not* clear ->offset.
Normally this omission doesn't matter as encode_entry_baggage() will be called, and will set ->offset to a suitable value (not on a page boundary).
But in the case where cd->buflen < elen and nfserr_toosmall is returned, ->offset is not reset.
This means that nfsd3proc_readdirplus will see ->offset with a value 4 bytes before the end of a page, and ->offset1 set to NULL. It will try to write 8bytes to ->offset.
If we are lucky, the next page will be read-only, and the system will
BUG: unable to handle kernel paging request at...
If we are unlucky, some innocent page will have the first 4 bytes corrupted.
nfsd3proc_readdir() doesn't even check for ->offset1, it just blindly writes 8 bytes to the offset wherever it is.
Fix this by clearing ->offset after it is used, and copying the ->offset handling code from nfsd3_proc_readdirplus into nfsd3_proc_readdir.
(Note that the commit hash in the Fixes tag is from the 'history'
tree - this bug predates git).
Fixes-URL: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=0b1d57cf7654
--- fs/nfsd/nfs3proc.c | 16 ++++++++++++++-- fs/nfsd/nfs3xdr.c | 1 + 2 files changed, 15 insertions(+), 2 deletions(-)
fs/nfsd/nfs3proc.c +14 -2
@@ -463,8 +463,19 @@ nfsd3_proc_readdir(struct svc_rqst *rqst &resp->common, nfs3svc_encode_entry);memcpy (resp->verf, argp->verf,8 ); resp->count = resp->buffer - argp->buffer; -if (resp->offset) -xdr_encode_hyper (resp->offset, argp->cookie); +if (resp->offset) { +loff_t offset = argp->cookie; + +if (unlikely (resp->offset1)) { +/* we ended up with offset on a page boundary */ + *resp->offset =htonl (offset >>32 ); + *resp->offset1 =htonl (offset &0xffffffff ); + resp->offset1 =NULL ; + }else { +xdr_encode_hyper (resp->offset, offset); + } + resp->offset =NULL ; + }RETURN_STATUS (nfserr); }
@@ -533,6 +544,7 @@ nfsd3_proc_readdirplus(struct svc_rqst * }else {xdr_encode_hyper (resp->offset, offset); } + resp->offset =NULL ; }RETURN_STATUS (nfserr);
fs/nfsd/nfs3xdr.c +1 -0
@@ -921,6 +921,7 @@ encode_entry(struct readdir_cd *ccd, con }else {xdr_encode_hyper (cd->offset, offset64); } + cd->offset =NULL ; }/*
Greg Kroah-Hartman
maintainerPATCH 245/280 nfsd: fix wrong check in write_v4_end_grace()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yihao Wu <[email protected]>
commit dd838821f0a29781b185cd8fb8e48d5c177bd838 upstream.
Commit 62a063b8e7d1 "nfsd4: fix crash on writing v4_end_grace before nfsd startup" is trying to fix a NULL dereference issue, but it mistakenly checks if the nfsd server is started. So fix it.
--- fs/nfsd/nfsctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfsctl.c +1 -1
@@ -1126,7 +1126,7 @@ static ssize_t write_v4_end_grace(structcase 'Y' :case 'y' :case '1' : -if (nn->nfsd_serv) +if (!nn->nfsd_serv)return -EBUSY ;nfsd4_end_grace (nn);break ;
Greg Kroah-Hartman
maintainerPATCH 246/280 NFSv4.1: Reinitialise sequence results before retransmitting a request
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit c1dffe0bf7f9c3d57d9f237a7cb2a81e62babd2b upstream.
If we have to retransmit a request, we should ensure that we reinitialise the sequence results structure, since in the event of a signal we need to treat the request as if it had not been sent.
--- fs/nfs/nfs4proc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
fs/nfs/nfs4proc.c +8 -4
@@ -947,6 +947,13 @@ nfs4_sequence_process_interrupted(struct#endif /* !CONFIG_NFS_V4_1 */ +static void nfs41_sequence_res_init (struct nfs4_sequence_res *res) +{ + res->sr_timestamp = jiffies; + res->sr_status_flags =0 ; + res->sr_status =1 ; +} + static void nfs4_sequence_attach_slot(struct nfs4_sequence_args *args, struct nfs4_sequence_res *res,
@@ -958,10 +965,6 @@ void nfs4_sequence_attach_slot(struct nf args->sa_slot = slot; res->sr_slot = slot; - res->sr_timestamp = jiffies; - res->sr_status_flags =0 ; - res->sr_status =1 ; - } int nfs4_setup_sequence(struct nfs_client *client,
@@ -1007,6 +1010,7 @@ int nfs4_setup_sequence(struct nfs_clientrace_nfs4_setup_sequence (session, args); out_start: +nfs41_sequence_res_init (res);rpc_call_start (task);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 247/280 svcrpc: fix UDP on servers with lots of threads
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit b7e5034cbecf5a65b7bfdc2b20a8378039577706 upstream.
James Pearson found that an NFS server stopped responding to UDP requests if started with more than 1017 threads.
sv_max_mesg is about 2^20, so that is probably where the calculation performed by
svc_sock_setbufsize(svsk->sk_sock,
(serv->sv_nrthreads+3) * serv->sv_max_mesg,
(serv->sv_nrthreads+3) * serv->sv_max_mesg);starts to overflow an int.
--- net/sunrpc/svcsock.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
net/sunrpc/svcsock.c +10 -10
@@ -381,12 +381,16 @@ static int svc_partial_recvfrom(struct s/* * Set socket snd and rcv buffer lengths */ -static void svc_sock_setbufsize (struct socket *sock,unsigned int snd, -unsigned int rcv) +static void svc_sock_setbufsize (struct svc_sock *svsk,unsigned int nreqs) { +unsigned int max_mesg = svsk->sk_xprt.xpt_server->sv_max_mesg; +struct socket *sock = svsk->sk_sock; + + nreqs =min (nreqs,INT_MAX /2 / max_mesg); +lock_sock (sock->sk); - sock->sk->sk_sndbuf = snd *2 ; - sock->sk->sk_rcvbuf = rcv *2 ; + sock->sk->sk_sndbuf = nreqs * max_mesg *2 ; + sock->sk->sk_rcvbuf = nreqs * max_mesg *2 ; sock->sk->sk_write_space (sock->sk);release_sock (sock->sk); }
@@ -548,9 +552,7 @@ static int svc_udp_recvfrom(struct svc_r* provides an upper bound on the number of threads * which will access the socket. */ -svc_sock_setbufsize (svsk->sk_sock, - (serv->sv_nrthreads+3 ) * serv->sv_max_mesg, - (serv->sv_nrthreads+3 ) * serv->sv_max_mesg); +svc_sock_setbufsize (svsk, serv->sv_nrthreads +3 );clear_bit (XPT_DATA , &svsk->sk_xprt.xpt_flags); skb =NULL ;
@@ -718,9 +720,7 @@ static void svc_udp_init(struct svc_sock* receive and respond to one request. * svc_udp_recvfrom will re-adjust if necessary */ -svc_sock_setbufsize (svsk->sk_sock, -3 * svsk->sk_xprt.xpt_server->sv_max_mesg, -3 * svsk->sk_xprt.xpt_server->sv_max_mesg); +svc_sock_setbufsize (svsk,3 );/* data might have come in before data_ready set up */ set_bit (XPT_DATA , &svsk->sk_xprt.xpt_flags);
Greg Kroah-Hartman
maintainerPATCH 248/280 PM / wakeup: Rework wakeup source timer cancellation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <[email protected]>
commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream.
If wakeup_source_add() is called right after wakeup_source_remove() for the same wakeup source, timer_setup() may be called for a potentially scheduled timer which is incorrect.
To avoid that, move the wakeup source timer cancellation from wakeup_source_drop() to wakeup_source_remove().
Moreover, make wakeup_source_remove() clear the timer function after canceling the timer to let wakeup_source_not_registered() treat unregistered wakeup sources in the same way as the ones that have never been registered.
--- drivers/base/power/wakeup.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/base/power/wakeup.c +7 -1
@@ -118,7 +118,6 @@ void wakeup_source_drop(struct wakeup_soif (!ws)return ; -del_timer_sync (&ws->timer);__pm_relax (ws); }EXPORT_SYMBOL_GPL (wakeup_source_drop);
@@ -205,6 +204,13 @@ void wakeup_source_remove(struct wakeup_list_del_rcu (&ws->entry);raw_spin_unlock_irqrestore (&events_lock, flags);synchronize_srcu (&wakeup_srcu); + +del_timer_sync (&ws->timer); +/* +* Clear timer.function to make wakeup_source_not_registered() treat +* this wakeup source as not registered. +*/ + ws->timer.function =NULL ; }EXPORT_SYMBOL_GPL (wakeup_source_remove);
Greg Kroah-Hartman
maintainerPATCH 249/280 bcache: never writeback a discard operation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Axtens <[email protected]>
commit 9951379b0ca88c95876ad9778b9099e19a95d566 upstream.
Some users see panics like the following when performing fstrim on a bcached volume:
[ 529.803060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 530.183928] #PF error: [normal kernel read fault] [ 530.412392] PGD 8000001f42163067 P4D 8000001f42163067 PUD 1f42168067 PMD 0 [ 530.750887] Oops: 0000 [#1] SMP PTI [ 530.920869] CPU: 10 PID: 4167 Comm: fstrim Kdump: loaded Not tainted 5.0.0-rc1+ #3 [ 531.290204] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015 [ 531.693137] RIP: 0010:blk_queue_split+0x148/0x620 [ 531.922205] Code: 60 38 89 55 a0 45 31 db 45 31 f6 45 31 c9 31 ff 89 4d 98 85 db 0f 84 7f 04 00 00 44 8b 6d 98 4c 89 ee 48 c1 e6 04 49 03 70 78 <8b> 46 08 44 8b 56 0c 48 8b 16 44 29 e0 39 d8 48 89 55 a8 0f 47 c3 [ 532.838634] RSP: 0018:ffffb9b708df39b0 EFLAGS: 00010246 [ 533.093571] RAX: 00000000ffffffff RBX: 0000000000046000 RCX: 0000000000000000 [ 533.441865] RDX: 0000000000000200 RSI: 0000000000000000 RDI: 0000000000000000 [ 533.789922] RBP: ffffb9b708df3a48 R08: ffff940d3b3fdd20 R09: 0000000000000000 [ 534.137512] R10: ffffb9b708df3958 R11: 0000000000000000 R12: 0000000000000000 [ 534.485329] R13: 0000000000000000 R14: 0000000000000000 R15: ffff940d39212020 [ 534.833319] FS: 00007efec26e3840(0000) GS:ffff940d1f480000(0000) knlGS:0000000000000000 [ 535.224098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 535.504318] CR2: 0000000000000008 CR3: 0000001f4e256004 CR4: 00000000001606e0 [ 535.851759] Call Trace: [ 535.970308] ? mempool_alloc_slab+0x15/0x20 [ 536.174152] ? bch_data_insert+0x42/0xd0 [bcache] [ 536.403399] blk_mq_make_request+0x97/0x4f0 [ 536.607036] generic_make_request+0x1e2/0x410 [ 536.819164] submit_bio+0x73/0x150 [ 536.980168] ? submit_bio+0x73/0x150 [ 537.149731] ? bio_associate_blkg_from_css+0x3b/0x60 [ 537.391595] ? _cond_resched+0x1a/0x50 [ 537.573774] submit_bio_wait+0x59/0x90 [ 537.756105] blkdev_issue_discard+0x80/0xd0 [ 537.959590] ext4_trim_fs+0x4a9/0x9e0 [ 538.137636] ? ext4_trim_fs+0x4a9/0x9e0 [ 538.324087] ext4_ioctl+0xea4/0x1530 [ 538.497712] ? _copy_to_user+0x2a/0x40 [ 538.679632] do_vfs_ioctl+0xa6/0x600 [ 538.853127] ? __do_sys_newfstat+0x44/0x70 [ 539.051951] ksys_ioctl+0x6d/0x80 [ 539.212785] __x64_sys_ioctl+0x1a/0x20 [ 539.394918] do_syscall_64+0x5a/0x110 [ 539.568674] entry_SYSCALL_64_after_hwframe+0x44/0xa9
We have observed it where both:
1) LVM/devmapper is involved (bcache backing device is LVM volume) and
2) writeback cache is involved (bcache cache_mode is writeback)
On one machine, we can reliably reproduce it with:
# echo writeback > /sys/block/bcache0/bcache/cache_mode
(not sure whether above line is required)
# mount /dev/bcache0 /test
# for i in {0..10}; do
file="$(mktemp /test/zero.XXX)"
dd if=/dev/zero of="$file" bs=1M count=256
sync
rm $file
done
# fstrim -v /testObserving this with tracepoints on, we see the following writes:
fstrim-18019 [022] .... 91107.302026: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112 + 196352 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302050: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4456464 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302075: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4718608 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302094: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5324816 + 180224 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302121: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5505040 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302145: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5767184 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.308777: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 6373392 + 180224 hit 1 bypass 0
<crash>
Note the final one has different hit/bypass flags.
This is because in should_writeback(), we were hitting a case where the partial stripe condition was returning true and so should_writeback() was returning true early.
If that hadn't been the case, it would have hit the would_skip test, and as would_skip == s->iop.bypass == true, should_writeback() would have returned false.
Looking at the git history from 'commit 72c270612bd3 ("bcache: Write out full stripes")', it looks like the idea was to optimise for raid5/6:
* If a stripe is already dirty, force writes to that stripe to writeback mode - to help build up full stripes of dirty data
To fix this issue, make sure that should_writeback() on a discard op never returns true.
More details of debugging:
https://www.spinics.net/lists/linux-bcache/msg06996.html
Previous reports:
- https://bugzilla.kernel.org/show_bug.cgi?id=201051
- https://bugzilla.kernel.org/show_bug.cgi?id=196103
- https://www.spinics.net/lists/linux-bcache/msg06885.html
(Coly Li: minor modification to follow maximum 75 chars per line rule)
--- drivers/md/bcache/writeback.h | 3 +++ 1 file changed, 3 insertions(+)
drivers/md/bcache/writeback.h +3 -0
@@ -63,6 +63,9 @@ static inline bool should_writeback(stru in_use > CUTOFF_WRITEBACK_SYNC)return false; +if (bio_op (bio) ==REQ_OP_DISCARD ) +return false; +if (dc->partial_stripes_expensive &&bcache_dev_stripe_dirty (dc, bio->bi_iter.bi_sector,bio_sectors (bio)))
Greg Kroah-Hartman
maintainerPATCH 250/280 stable-kernel-rules.rst: add link to networking patch queue
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit a41e8f25fa8f8f67360d88eb0eebbabe95a64bdf upstream.
The networking maintainer keeps a public list of the patches being queued up for the next round of stable releases. Be sure to check there before asking for a patch to be applied so that you do not waste people's time.
--- Documentation/process/stable-kernel-rules.rst | 3 +++ 1 file changed, 3 insertions(+)
Documentation/process/stable-kernel-rules.rst +3 -0
@@ -38,6 +38,9 @@ Procedure for submitting patches to the - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>` + after first checking the stable networking queue at + https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= + to ensure the requested patch is not already queued up. - Security patches should not be handled (solely) by the -stable review process but should follow the procedures in :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
Greg Kroah-Hartman
maintainerPATCH 251/280 vt: perform safe console erase in the right order
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Pitre <[email protected]>
commit a6dbe442755999960ca54a9b8ecfd9606be0ea75 upstream.
Commit 4b4ecd9cb853 ("vt: Perform safe console erase only once") removed what appeared to be an extra call to scr_memsetw(). This missed the fact that set_origin() must be called before clearing the screen otherwise old screen content gets restored on the screen when using vgacon. Let's fix that by moving all the scrollback handling to flush_scrollback() where it logically belongs, and invoking it before the actual screen clearing in csi_J(), making the code simpler in the end.
--- drivers/tty/vt/vt.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-)
drivers/tty/vt/vt.c +7 -8
@@ -935,8 +935,11 @@ static void flush_scrollback(struct vc_d {WARN_CONSOLE_UNLOCKED (); +set_origin (vc);if (vc->vc_sw->con_flush_scrollback) vc->vc_sw->con_flush_scrollback (vc); +else + vc->vc_sw->con_switch (vc); }/*
@@ -1506,8 +1509,10 @@ static void csi_J(struct vc_data *vc, in count = ((vc->vc_pos - vc->vc_origin) >>1 ) +1 ; start = (unsigned short *)vc->vc_origin;break ; +case 3 :/* include scrollback */ +flush_scrollback (vc); +/* fallthrough */ case 2 :/* erase whole display */ -case 3 :/* (and scrollback buffer later) */ vc_uniscr_clear_lines (vc,0 , vc->vc_rows); count = vc->vc_cols * vc->vc_rows; start = (unsigned short *)vc->vc_origin;
@@ -1516,13 +1521,7 @@ static void csi_J(struct vc_data *vc, inreturn ; }scr_memsetw (start, vc->vc_video_erase_char,2 * count); -if (vpar ==3 ) { -set_origin (vc); -flush_scrollback (vc); -if (con_is_visible (vc)) -update_screen (vc); - }else if (con_should_update (vc)) -do_update_region (vc, (unsigned long ) start, count); +update_region (vc, (unsigned long ) start, count); vc->vc_need_wrap =0 ; }
Greg Kroah-Hartman
maintainerPATCH 252/280 x86/unwind/orc: Fix ORC unwind table alignment
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
commit f76a16adc485699f95bb71fce114f97c832fe664 upstream.
The .orc_unwind section is a packed array of 6-byte structs. It's currently aligned to 6 bytes, which is causing warnings in the LLD linker.
Six isn't a power of two, so it's not a valid alignment value. The actual alignment doesn't matter much because it's an array of packed structs. An alignment of two is sufficient. In reality it always gets aligned to four bytes because it comes immediately after the 4-byte-aligned .orc_unwind_ip section.
--- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +1 -1
@@ -727,7 +727,7 @@ KEEP(*(.orc_unwind_ip)) \ __stop_orc_unwind_ip = .; \ } \ - . = ALIGN(6); \ + . = ALIGN(2); \ .orc_unwind : AT(ADDR(.orc_unwind) - LOAD_OFFSET) { \ __start_orc_unwind = .; \ KEEP(*(.orc_unwind)) \
Greg Kroah-Hartman
maintainerPATCH 253/280 perf intel-pt: Fix CYC timestamp calculation after OVF
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 03997612904866abe7cdcc992784ef65cb3a4b81 upstream.
CYC packet timestamp calculation depends upon CBR which was being cleared upon overflow (OVF). That can cause errors due to failing to synchronize with sideband events. Even if a CBR change has been lost, the old CBR is still a better estimate than zero. So remove the clearing of CBR.
--- tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 - 1 file changed, 1 deletion(-)
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +0 -1
@@ -1389,7 +1389,6 @@ static int intel_pt_overflow(struct inte {intel_pt_log ("ERROR: Buffer overflow\n" );intel_pt_clear_tx_flags (decoder); - decoder->cbr =0 ; decoder->timestamp_insn_cnt =0 ; decoder->pkt_state =INTEL_PT_STATE_ERR_RESYNC ; decoder->overflow = true;
Greg Kroah-Hartman
maintainerPATCH 254/280 perf tools: Fix split_kallsyms_for_kcore() for trampoline symbols
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit d6d457451eb94fa747dc202765592eb8885a7352 upstream.
Kallsyms symbols do not have a size, so the size becomes the distance to the next symbol.
Consequently the recently added trampoline symbols end up with large sizes because the trampolines are some distance from one another and the main kernel map.
However, symbols that end outside their map can disrupt the symbol tree because, after mapping, it can appear incorrectly that they overlap other symbols.
Add logic to truncate symbol size to the end of the corresponding map.
--- tools/perf/util/symbol.c | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/util/symbol.c +2 -0
@@ -709,6 +709,8 @@ static int map_groups__split_kallsyms_fo } pos->start -= curr_map->start - curr_map->pgoff; +if (pos->end > curr_map->end) + pos->end = curr_map->end;if (pos->end) pos->end -= curr_map->start - curr_map->pgoff;symbols__insert (&curr_map->dso->symbols, pos);
Greg Kroah-Hartman
maintainerPATCH 255/280 perf auxtrace: Define auxtrace record alignment
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit c3fcadf0bb765faf45d6d562246e1d08885466df upstream.
Define auxtrace record alignment so that it can be referenced elsewhere.
Note this is preparation for patch "perf intel-pt: Fix overlap calculation for padding"
--- tools/perf/util/auxtrace.c | 4 ++-- tools/perf/util/auxtrace.h | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-)
tools/perf/util/auxtrace.c +2 -2
@@ -1273,9 +1273,9 @@ static int __auxtrace_mmap__read(struct }/* padding must be written by fn() e.g. record__process_auxtrace() */ - padding = size &7 ; + padding = size & (PERF_AUXTRACE_RECORD_ALIGNMENT -1 );if (padding) - padding =8 - padding; + padding =PERF_AUXTRACE_RECORD_ALIGNMENT - padding;memset (&ev,0 ,sizeof (ev)); ev.auxtrace.header.type =PERF_RECORD_AUXTRACE ;
tools/perf/util/auxtrace.h +3 -0
@@ -38,6 +38,9 @@ struct record_opts;struct auxtrace_info_event ;struct events_stats ; +/* Auxtrace records must have the same alignment as perf event records */ +#define PERF_AUXTRACE_RECORD_ALIGNMENT 8 +enum auxtrace_type {PERF_AUXTRACE_UNKNOWN ,PERF_AUXTRACE_INTEL_PT ,
Greg Kroah-Hartman
maintainerPATCH 256/280 perf intel-pt: Fix overlap calculation for padding
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 5a99d99e3310a565b0cf63f785b347be9ee0da45 upstream.
Auxtrace records might have up to 7 bytes of padding appended. Adjust the overlap accordingly.
--- tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 36 ++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-)
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +34 -2
@@ -26,6 +26,7 @@#include "../cache.h" #include "../util.h" +#include "../auxtrace.h" #include "intel-pt-insn-decoder.h" #include "intel-pt-pkt-decoder.h"
@@ -2558,6 +2559,34 @@ static int intel_pt_tsc_cmp(uint64_t tsc } } +#define MAX_PADDING (PERF_AUXTRACE_RECORD_ALIGNMENT - 1) + +/** +* adj_for_padding - adjust overlap to account for padding. +* @buf_b: second buffer +* @buf_a: first buffer +* @len_a: size of first buffer +* +* @buf_a might have up to 7 bytes of padding appended. Adjust the overlap +* accordingly. +* +* Return: A pointer into @buf_b from where non-overlapped data starts +*/ +static unsigned char *adj_for_padding (unsigned char *buf_b, +unsigned char *buf_a,size_t len_a) +{ +unsigned char *p = buf_b -MAX_PADDING ; +unsigned char *q = buf_a + len_a -MAX_PADDING ; +int i; + +for (i =MAX_PADDING ; i; i--, p++, q++) { +if (*p != *q) +break ; + } + +return p; +} +/** * intel_pt_find_overlap_tsc - determine start of non-overlapped trace data * using TSC.
@@ -2608,8 +2637,11 @@ static unsigned char *intel_pt_find_over/* Same TSC, so buffers are consecutive */ if (!cmp && rem_b >= rem_a) { +unsigned char *start; + *consecutive = true; -return buf_b + len_b - (rem_b - rem_a); + start = buf_b + len_b - (rem_b - rem_a); +return adj_for_padding (start, buf_a, len_a); }if (cmp <0 )return buf_b;/* tsc_a < tsc_b => no overlap */
@@ -2672,7 +2704,7 @@ unsigned char *intel_pt_find_overlap(uns found =memmem (buf_a, len_a, buf_b, len_a);if (found) { *consecutive = true; -return buf_b + len_a; +return adj_for_padding (buf_b + len_a, buf_a, len_a); }/* Try again at next PSB in buffer 'a' */
Greg Kroah-Hartman
maintainerPATCH 257/280 perf/x86/intel/uncore: Fix client IMC events return huge result
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 8041ffd36f42d8521d66dd1e236feb58cecd68bc upstream.
The client IMC bandwidth events currently return very large values:
$ perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I 10000 -a
10.000117222 34,788.76 MiB uncore_imc/data_reads/ 10.000117222 8.26 MiB uncore_imc/data_writes/ 20.000374584 34,842.89 MiB uncore_imc/data_reads/ 20.000374584 10.45 MiB uncore_imc/data_writes/ 30.000633299 37,965.29 MiB uncore_imc/data_reads/ 30.000633299 323.62 MiB uncore_imc/data_writes/ 40.000891548 41,012.88 MiB uncore_imc/data_reads/ 40.000891548 6.98 MiB uncore_imc/data_writes/ 50.001142480 1,125,899,906,621,494.75 MiB uncore_imc/data_reads/ 50.001142480 6.97 MiB uncore_imc/data_writes/
The client IMC events are freerunning counters. They still use the old event encoding format (0x1 for data_read and 0x2 for data write). The counter bit width is calculated by common code, which assume that the standard encoding format is used for the freerunning counters. Error bit width information is calculated.
The patch intends to convert the old client IMC event encoding to the standard encoding format.
Current common code uses event->attr.config which directly copy from user space. We should not implicitly modify it for a converted event. The event->hw.config is used to replace the event->attr.config in common code.
For client IMC events, the event->attr.config is used to calculate a converted event with standard encoding format in the custom event_init(). The converted event is stored in event->hw.config. For other events of freerunning counters, they already use the standard encoding format. The same value as event->attr.config is assigned to event->hw.config in common event_init().
--- arch/x86/events/intel/uncore.c | 1 + arch/x86/events/intel/uncore.h | 12 ++++++------ arch/x86/events/intel/uncore_snb.c | 4 +++- 3 files changed, 10 insertions(+), 7 deletions(-)
arch/x86/events/intel/uncore.c +1 -0
@@ -740,6 +740,7 @@ static int uncore_pmu_event_init(struct/* fixed counters have event field hardcoded to zero */ hwc->config =0ULL ; }else if (is_freerunning_event (event)) { + hwc->config = event->attr.config;if (!check_valid_freerunning_event (box, event))return -EINVAL ; event->hw.idx =UNCORE_PMC_IDX_FREERUNNING ;
arch/x86/events/intel/uncore.h +6 -6
@@ -285,8 +285,8 @@ static inlineunsigned int uncore_freerunning_counter (struct intel_uncore_box *box,struct perf_event *event) { -unsigned int type =uncore_freerunning_type (event->attr.config); -unsigned int idx =uncore_freerunning_idx (event->attr.config); +unsigned int type =uncore_freerunning_type (event->hw.config); +unsigned int idx =uncore_freerunning_idx (event->hw.config);struct intel_uncore_pmu *pmu = box->pmu; return pmu->type->freerunning[type].counter_base +
@@ -360,7 +360,7 @@ static inlineunsigned int uncore_freerunning_bits (struct intel_uncore_box *box,struct perf_event *event) { -unsigned int type =uncore_freerunning_type (event->attr.config); +unsigned int type =uncore_freerunning_type (event->hw.config);return box->pmu->type->freerunning[type].bits; }
@@ -368,7 +368,7 @@ unsigned int uncore_freerunning_bits(strstatic inline int uncore_num_freerunning (struct intel_uncore_box *box,struct perf_event *event) { -unsigned int type =uncore_freerunning_type (event->attr.config); +unsigned int type =uncore_freerunning_type (event->hw.config);return box->pmu->type->freerunning[type].num_counters; }
@@ -382,8 +382,8 @@ static inline int uncore_num_freerunningstatic inline bool check_valid_freerunning_event (struct intel_uncore_box *box,struct perf_event *event) { -unsigned int type =uncore_freerunning_type (event->attr.config); -unsigned int idx =uncore_freerunning_idx (event->attr.config); +unsigned int type =uncore_freerunning_type (event->hw.config); +unsigned int idx =uncore_freerunning_idx (event->hw.config);return (type <uncore_num_freerunning_types (box, event)) && (idx <uncore_num_freerunning (box, event));
arch/x86/events/intel/uncore_snb.c +3 -1
@@ -444,9 +444,11 @@ static int snb_uncore_imc_event_init(str/* must be done before validate_group */ event->hw.event_base = base; - event->hw.config = cfg; event->hw.idx = idx; +/* Convert to standard encoding format for freerunning counters */ + event->hw.config = ((cfg -1 ) <<8 ) |0x10ff ; +/* no group validation needed, we have free running counters */ return 0 ;
Greg Kroah-Hartman
maintainerPATCH 258/280 perf intel-pt: Fix divide by zero when TSC is not available
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 076333870c2f5bdd9b6d31e7ca1909cf0c84cbfa upstream.
When TSC is not available, "timeless" decoding is used but a divide by zero occurs if perf_time_to_tsc() is called.
Ensure the divisor is not zero.
--- tools/perf/util/intel-pt.c | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/util/intel-pt.c +2 -0
@@ -2507,6 +2507,8 @@ int intel_pt_process_auxtrace_info(union } pt->timeless_decoding =intel_pt_timeless_decoding (pt); +if (pt->timeless_decoding && !pt->tc.time_mult) + pt->tc.time_mult =1 ; pt->have_tsc =intel_pt_have_tsc (pt); pt->sampling_mode = false; pt->est_tsc = !pt->timeless_decoding;
Greg Kroah-Hartman
maintainerPATCH 259/280 md: Fix failed allocation of md_register_thread
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aditya Pakki <[email protected]>
commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec upstream.
mddev->sync_thread can be set to NULL on kzalloc failure downstream. The patch checks for such a scenario and frees allocated resources.
Committer node:
Added similar fix to raid5.c, as suggested by Guoqing.
--- drivers/md/raid10.c | 2 ++ drivers/md/raid5.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/md/raid10.c +2 -0
@@ -3959,6 +3959,8 @@ static int raid10_run(struct mddev *mddeset_bit (MD_RECOVERY_RUNNING , &mddev->recovery); mddev->sync_thread =md_register_thread (md_do_sync, mddev,"reshape" ); +if (!mddev->sync_thread) + goto out_free_conf; }return 0 ;
drivers/md/raid5.c +2 -0
@@ -7390,6 +7390,8 @@ static int raid5_run(struct mddev *mddevset_bit (MD_RECOVERY_RUNNING , &mddev->recovery); mddev->sync_thread =md_register_thread (md_do_sync, mddev,"reshape" ); +if (!mddev->sync_thread) + goto abort; }/* Ok, everything is just fine now */
Greg Kroah-Hartman
maintainerPATCH 260/280 tpm/tpm_crb: Avoid unaligned reads in crb_recv()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Sakkinen <[email protected]>
commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream.
The current approach to read first 6 bytes from the response and then tail of the response, can cause the 2nd memcpy_fromio() to do an unaligned read (e.g. read 32-bit word from address aligned to a 16-bits), depending on how memcpy_fromio() is implemented. If this happens, the read will fail and the memory controller will fill the read with 1's.
This was triggered by 170d13ca3a2f, which should be probably refined to check and react to the address alignment. Before that commit, on x86 memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right thing (from tpm_crb's perspective) for us so far, but we should not rely on that. Thus, it makes sense to fix this also in tpm_crb, not least because the fix can be then backported to stable kernels and make them more robust when compiled in differing environments.
--- drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
drivers/char/tpm/tpm_crb.c +16 -6
@@ -287,19 +287,29 @@ static int crb_recv(struct tpm_chip *chistruct crb_priv *priv =dev_get_drvdata (&chip->dev);unsigned int expected; -/* sanity check */ -if (count <6 ) +/* A sanity check that the upper layer wants to get at least the header +* as that is the minimum size for any TPM response. +*/ +if (count <TPM_HEADER_SIZE )return -EIO ; +/* If this bit is set, according to the spec, the TPM is in +* unrecoverable condition. +*/ if (ioread32 (&priv->regs_t->ctrl_sts) &CRB_CTRL_STS_ERROR )return -EIO ; -memcpy_fromio (buf, priv->rsp,6 ); - expected =be32_to_cpup ((__be32 *) &buf[2 ]); -if (expected > count || expected <6 ) +/* Read the first 8 bytes in order to get the length of the response. +* We read exactly a quad word in order to make sure that the remaining +* reads will be aligned. +*/ +memcpy_fromio (buf, priv->rsp,8 ); + + expected =be32_to_cpup ((__be32 *)&buf[2 ]); +if (expected > count || expected <TPM_HEADER_SIZE )return -EIO ; -memcpy_fromio (&buf[6 ], &priv->rsp[6 ], expected -6 ); +memcpy_fromio (&buf[8 ], &priv->rsp[8 ], expected -8 );return expected; }
Greg Kroah-Hartman
maintainerPATCH 261/280 tpm: Unify the send callback behaviour
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Sakkinen <[email protected]>
commit f5595f5baa30e009bf54d0d7653a9a0cc465be60 upstream.
The send() callback should never return length as it does not in every driver except tpm_crb in the success case. The reason is that the main transmit functionality only cares about whether the transmit was successful or not and ignores the count completely.
--- drivers/char/tpm/st33zp24/st33zp24.c | 2 +- drivers/char/tpm/tpm-interface.c | 11 ++++++++++- drivers/char/tpm/tpm_atmel.c | 2 +- drivers/char/tpm/tpm_i2c_atmel.c | 6 +++++- drivers/char/tpm/tpm_i2c_infineon.c | 2 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +- drivers/char/tpm/tpm_ibmvtpm.c | 8 ++++---- drivers/char/tpm/tpm_infineon.c | 2 +- drivers/char/tpm/tpm_nsc.c | 2 +- drivers/char/tpm/tpm_tis_core.c | 2 +- drivers/char/tpm/tpm_vtpm_proxy.c | 3 +-- drivers/char/tpm/xen-tpmfront.c | 2 +- 12 files changed, 28 insertions(+), 16 deletions(-)
drivers/char/tpm/st33zp24/st33zp24.c +1 -1
@@ -436,7 +436,7 @@ static int st33zp24_send(struct tpm_chip goto out_err; } -return len; +return 0 ; out_err:st33zp24_cancel (chip);release_locality (chip);
drivers/char/tpm/tpm-interface.c +10 -1
@@ -495,10 +495,19 @@ static ssize_t tpm_try_transmit(struct tif (rc <0 ) {if (rc != -EPIPE )dev_err (&chip->dev, -"%s: tpm_send: error %d\n" , __func__, rc); +"%s: send(): error %d\n" , __func__, rc); goto out; } +/* A sanity check. send() should just return zero on success e.g. +* not the command length. +*/ +if (rc >0 ) { +dev_warn (&chip->dev, +"%s: send(): invalid value %d\n" , __func__, rc); + rc =0 ; + } +if (chip->flags &TPM_CHIP_FLAG_IRQ ) goto out_recv;
drivers/char/tpm/tpm_atmel.c +1 -1
@@ -105,7 +105,7 @@ static int tpm_atml_send(struct tpm_chipiowrite8 (buf[i], priv->iobase); } -return count; +return 0 ; }static void tpm_atml_cancel (struct tpm_chip *chip)
drivers/char/tpm/tpm_i2c_atmel.c +5 -1
@@ -65,7 +65,11 @@ static int i2c_atmel_send(struct tpm_chidev_dbg (&chip->dev,"%s(buf=%*ph len=%0zx) -> sts=%d\n" , __func__, (int )min_t (size_t,64 , len), buf, len, status); -return status; + +if (status <0 ) +return status; + +return 0 ; }static int i2c_atmel_recv (struct tpm_chip *chip,u8 *buf,size_t count)
drivers/char/tpm/tpm_i2c_infineon.c +1 -1
@@ -587,7 +587,7 @@ static int tpm_tis_i2c_send(struct tpm_c/* go and do it */ iic_tpm_write (TPM_STS (tpm_dev.locality), &sts,1 ); -return len; +return 0 ; out_err:tpm_tis_i2c_ready (chip);/* The TPM needs some time to clean up here,
drivers/char/tpm/tpm_i2c_nuvoton.c +1 -1
@@ -469,7 +469,7 @@ static int i2c_nuvoton_send(struct tpm_c }dev_dbg (dev,"%s() -> %zd\n" , __func__, len); -return len; +return 0 ; }static bool i2c_nuvoton_req_canceled (struct tpm_chip *chip,u8 status)
drivers/char/tpm/tpm_ibmvtpm.c +4 -4
@@ -141,14 +141,14 @@ static int tpm_ibmvtpm_recv(struct tpm_c }/** -* tpm_ibmvtpm_send - Send tpm request -* +* tpm_ibmvtpm_send() - Send a TPM command * @chip: tpm chip struct * @buf: buffer contains data to send * @count: size of buffer * * Return: -* Number of bytes sent or < 0 on error. +* 0 on success, +* -errno on error */ static int tpm_ibmvtpm_send (struct tpm_chip *chip,u8 *buf,size_t count) {
@@ -194,7 +194,7 @@ static int tpm_ibmvtpm_send(struct tpm_c rc =0 ; ibmvtpm->tpm_processing_cmd = false; }else - rc = count; + rc =0 ;spin_unlock (&ibmvtpm->rtce_lock);return rc;
drivers/char/tpm/tpm_infineon.c +1 -1
@@ -354,7 +354,7 @@ static int tpm_inf_send(struct tpm_chipfor (i =0 ; i < count; i++) {wait_and_send (chip, buf[i]); } -return count; +return 0 ; }static void tpm_inf_cancel (struct tpm_chip *chip)
drivers/char/tpm/tpm_nsc.c +1 -1
@@ -226,7 +226,7 @@ static int tpm_nsc_send(struct tpm_chip }outb (NSC_COMMAND_EOC , priv->base +NSC_COMMAND ); -return count; +return 0 ; }static void tpm_nsc_cancel (struct tpm_chip *chip)
drivers/char/tpm/tpm_tis_core.c +1 -1
@@ -485,7 +485,7 @@ static int tpm_tis_send_main(struct tpm_ goto out_err; } } -return len; +return 0 ; out_err:tpm_tis_ready (chip);return rc;
drivers/char/tpm/tpm_vtpm_proxy.c +1 -2
@@ -335,7 +335,6 @@ static int vtpm_proxy_is_driver_command(static int vtpm_proxy_tpm_op_send (struct tpm_chip *chip,u8 *buf,size_t count) {struct proxy_dev *proxy_dev =dev_get_drvdata (&chip->dev); -int rc =0 ;if (count >sizeof (proxy_dev->buffer)) { dev_err(&chip->dev,
@@ -366,7 +365,7 @@ static int vtpm_proxy_tpm_op_send(structwake_up_interruptible (&proxy_dev->wq); -return rc; +return 0 ; }static void vtpm_proxy_tpm_op_cancel (struct tpm_chip *chip)
drivers/char/tpm/xen-tpmfront.c +1 -1
@@ -173,7 +173,7 @@ static int vtpm_send(struct tpm_chip *chreturn -ETIME ; } -return count; +return 0 ; }static int vtpm_recv (struct tpm_chip *chip,u8 *buf,size_t count)
Greg Kroah-Hartman
maintainerPATCH 262/280 rcu: Do RCU GP kthread self-wakeup from softirq and interrupt
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang, Jun <[email protected]>
commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream.
The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup.
Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions.
This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature.
This patch does not Cc stable because it does not apply cleanly to earlier kernel versions.
Signed-off: "Zhang, Jun" <[email protected]>
Signed-off: "He, Bo" <[email protected]>
Signed-off: "xiao, jin" <[email protected]>
Signed-off: Bai, Jie A <[email protected]>
[ paulmck: Switch from !in_softirq() to "!in_interrupt() &&
!in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ]
--- kernel/rcu/tree.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
kernel/rcu/tree.c +14 -6
@@ -1689,15 +1689,23 @@ static bool rcu_future_gp_cleanup(struct }/* -* Awaken the grace-period kthread for the specified flavor of RCU. -* Don't do a self-awaken, and don't bother awakening when there is -* nothing for the grace-period kthread to do (as in several CPUs -* raced to awaken, and we lost), and finally don't try to awaken -* a kthread that has not yet been created. +* Awaken the grace-period kthread. Don't do a self-awaken (unless in +* an interrupt or softirq handler), and don't bother awakening when there +* is nothing for the grace-period kthread to do (as in several CPUs raced +* to awaken, and we lost), and finally don't try to awaken a kthread that +* has not yet been created. If all those checks are passed, track some +* debug information and awaken. +* +* So why do the self-wakeup when in an interrupt or softirq handler +* in the grace-period kthread's context? Because the kthread might have +* been interrupted just as it was going to sleep, and just after the final +* pre-sleep check of the awaken condition. In this case, a wakeup really +* is required, and is therefore supplied. */ static void rcu_gp_kthread_wake (struct rcu_state *rsp) { -if (current == rsp->gp_kthread || +if ((current == rsp->gp_kthread && + !in_interrupt () && !in_serving_softirq ()) || !READ_ONCE (rsp->gp_flags) || !rsp->gp_kthread)return ;
Greg Kroah-Hartman
maintainerPATCH 263/280 media: imx: prpencvf: Stop upstream before disabling IDMA channel
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve Longerbeam <[email protected]>
commit a19c22677377b87e4354f7306f46ad99bc982a9f upstream.
Upstream must be stopped immediately after receiving the last EOF and before disabling the IDMA channel. This can be accomplished by moving upstream stream off to just after receiving the last EOF completion in prp_stop(). For symmetry also move upstream stream on to end of prp_start().
This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on:
while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done
Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset.
The lockup occurs when disabling the IDMA channel at stream off. Stopping the video data stream entering the IDMA channel before disabling the channel itself appears to be a reliable fix for the hard lockup.
--- drivers/staging/media/imx/imx-ic-prpencvf.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-)
drivers/staging/media/imx/imx-ic-prpencvf.c +17 -9
@@ -680,12 +680,23 @@ static int prp_start(struct prp_priv *pr goto out_free_nfb4eof_irq; } +/* start upstream */ + ret =v4l2_subdev_call (priv->src_sd, video, s_stream,1 ); + ret = (ret && ret != -ENOIOCTLCMD ) ? ret :0 ; +if (ret) { +v4l2_err (&ic_priv->sd, +"upstream stream on failed: %d\n" , ret); + goto out_free_eof_irq; + } +/* start the EOF timeout timer */ mod_timer (&priv->eof_timeout_timer, jiffies +msecs_to_jiffies (IMX_MEDIA_EOF_TIMEOUT ));return 0 ; +out_free_eof_irq: +devm_free_irq (ic_priv->dev, priv->eof_irq, priv); out_free_nfb4eof_irq:devm_free_irq (ic_priv->dev, priv->nfb4eof_irq, priv); out_unsetup:
@@ -717,6 +728,12 @@ static void prp_stop(struct prp_priv *prif (ret ==0 )v4l2_warn (&ic_priv->sd,"wait last EOF timeout\n" ); +/* stop upstream */ + ret =v4l2_subdev_call (priv->src_sd, video, s_stream,0 ); +if (ret && ret != -ENOIOCTLCMD ) +v4l2_warn (&ic_priv->sd, +"upstream stream off failed: %d\n" , ret); +devm_free_irq (ic_priv->dev, priv->eof_irq, priv);devm_free_irq (ic_priv->dev, priv->nfb4eof_irq, priv);
@@ -1148,15 +1165,6 @@ static int prp_s_stream(struct v4l2_subdif (ret) goto out; -/* start/stop upstream */ - ret =v4l2_subdev_call (priv->src_sd, video, s_stream, enable); - ret = (ret && ret != -ENOIOCTLCMD ) ? ret :0 ; -if (ret) { -if (enable) -prp_stop (priv); - goto out; - } - update_count: priv->stream_count += enable ?1 :-1 ;if (priv->stream_count <0 )
Greg Kroah-Hartman
maintainerPATCH 264/280 media: lgdt330x: fix lock status reporting
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: French, Nicholas A <[email protected]>
commit 1b4fd9de6ec7f3722c2b3e08cc5ad171c11f93be upstream.
A typo in code cleanup commit db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic") broke the FE_HAS_LOCK reporting for 3303 chips by inadvertently modifying the register mask.
The broken lock status is critial as it prevents video capture cards from reporting signal strength, scanning for channels, and capturing video.
Fix regression by reverting mask change.
--- drivers/media/dvb-frontends/lgdt330x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/dvb-frontends/lgdt330x.c +1 -1
@@ -783,7 +783,7 @@ static int lgdt3303_read_status(struct dif ((buf[0 ] &0x02 ) ==0x00 ) *status |=FE_HAS_SYNC ; -if ((buf[0 ] &0xfd ) ==0x01 ) +if ((buf[0 ] &0x01 ) ==0x01 ) *status |=FE_HAS_VITERBI |FE_HAS_LOCK ;break ;default :
Greg Kroah-Hartman
maintainerPATCH 265/280 media: uvcvideo: Avoid NULL pointer dereference at the end of streaming
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <[email protected]>
commit 9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream.
The UVC video driver converts the timestamp from hardware specific unit to one known by the kernel at the time when the buffer is dequeued. This is fine in general, but the streamoff operation consists of the following steps (among other things):
1. uvc_video_clock_cleanup --- the hardware clock sample array is released and the pointer to the array is set to NULL,
2. buffers in active state are returned to the user and
3. buf_finish callback is called on buffers that are prepared. buf_finish includes calling uvc_video_clock_update that accesses the hardware clock sample array.
The above is serialised by a queue specific mutex. Address the problem by skipping the clock conversion if the hardware clock sample array is already released.
--- drivers/media/usb/uvc/uvc_video.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/media/usb/uvc/uvc_video.c +8 -0
@@ -676,6 +676,14 @@ void uvc_video_clock_update(struct uvc_sif (!uvc_hw_timestamps_param)return ; +/* +* We will get called from __vb2_queue_cancel() if there are buffers +* done but not dequeued by the user, but the sample array has already +* been released at that time. Just bail out in that case. +*/ +if (!clock->samples) +return ; +spin_lock_irqsave (&clock->lock, flags);if (clock->count < clock->size)
Greg Kroah-Hartman
maintainerPATCH 266/280 media: vimc: Add vimc-streamer for stream control
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas A. M. Magalhães <[email protected]>
commit adc589d2a20808fb99d46a78175cd023f2040338 upstream.
Add a linear pipeline logic for the stream control. It's created by walking backwards on the entity graph. When the stream starts it will simply loop through the pipeline calling the respective process_frame function of each entity.
and sensor")
--- drivers/media/platform/vimc/Makefile | 3 drivers/media/platform/vimc/vimc-capture.c | 18 +- drivers/media/platform/vimc/vimc-common.c | 35 ----- drivers/media/platform/vimc/vimc-common.h | 15 -- drivers/media/platform/vimc/vimc-debayer.c | 26 --- drivers/media/platform/vimc/vimc-scaler.c | 28 ---- drivers/media/platform/vimc/vimc-sensor.c | 56 +------- drivers/media/platform/vimc/vimc-streamer.c | 188 ++++++++++++++++++++++++++++ drivers/media/platform/vimc/vimc-streamer.h | 38 +++++ 9 files changed, 260 insertions(+), 147 deletions(-)
drivers/media/platform/vimc/Makefile +2 -1
@@ -5,6 +5,7 @@ vimc_common-objs := vimc-common.o vimc_debayer-objs := vimc-debayer.o vimc_scaler-objs := vimc-scaler.o vimc_sensor-objs := vimc-sensor.o +vimc_streamer-objs := vimc-streamer.o obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o \ - vimc_scaler.o vimc_sensor.o + vimc_scaler.o vimc_sensor.o vimc_streamer.o
drivers/media/platform/vimc/vimc-capture.c +9 -9
@@ -24,6 +24,7 @@#include <media/videobuf2-vmalloc.h> #include "vimc-common.h" +#include "vimc-streamer.h" #define VIMC_CAP_DRV_NAME "vimc-capture"
@@ -44,7 +45,7 @@ struct vimc_cap_device {spinlock_t qlock;struct mutex lock;u32 sequence; -struct media_pipeline pipe; +struct vimc_stream stream; };static const struct v4l2_pix_format fmt_default = {
@@ -248,14 +249,13 @@ static int vimc_cap_start_streaming(stru vcap->sequence =0 ;/* Start the media pipeline */ - ret =media_pipeline_start (entity, &vcap->pipe); + ret =media_pipeline_start (entity, &vcap->stream.pipe);if (ret) {vimc_cap_return_all_buffers (vcap,VB2_BUF_STATE_QUEUED );return ret; } -/* Enable streaming from the pipe */ - ret =vimc_pipeline_s_stream (&vcap->vdev.entity,1 ); + ret =vimc_streamer_s_stream (&vcap->stream, &vcap->ved,1 );if (ret) {media_pipeline_stop (entity);vimc_cap_return_all_buffers (vcap,VB2_BUF_STATE_QUEUED );
@@ -273,8 +273,7 @@ static void vimc_cap_stop_streaming(stru {struct vimc_cap_device *vcap =vb2_get_drv_priv (vq); -/* Disable streaming from the pipe */ -vimc_pipeline_s_stream (&vcap->vdev.entity,0 ); +vimc_streamer_s_stream (&vcap->stream, &vcap->ved,0 );/* Stop the media pipeline */ media_pipeline_stop (&vcap->vdev.entity);
@@ -355,8 +354,8 @@ static void vimc_cap_comp_unbind(structkfree (vcap); } -static void vimc_cap_process_frame (struct vimc_ent_device *ved, -struct media_pad *sink,const void *frame) +static void *vimc_cap_process_frame (struct vimc_ent_device *ved, +const void *frame) { struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device, ved);
@@ -370,7 +369,7 @@ static void vimc_cap_process_frame(struc typeof(*vimc_buf), list);if (!vimc_buf) {spin_unlock (&vcap->qlock); -return ; +return ERR_PTR (-EAGAIN ); }/* Remove this entry from the list */
@@ -391,6 +390,7 @@ static void vimc_cap_process_frame(strucvb2_set_plane_payload (&vimc_buf->vb2.vb2_buf,0 , vcap->format.sizeimage);vb2_buffer_done (&vimc_buf->vb2.vb2_buf,VB2_BUF_STATE_DONE ); +return NULL ; } static int vimc_cap_comp_bind(struct device *comp, struct device *master,
drivers/media/platform/vimc/vimc-common.c +0 -35
@@ -207,41 +207,6 @@ const struct vimc_pix_map *vimc_pix_map_ }EXPORT_SYMBOL_GPL (vimc_pix_map_by_pixelformat); -int vimc_propagate_frame (struct media_pad *src,const void *frame) -{ -struct media_link *link; - -if (!(src->flags &MEDIA_PAD_FL_SOURCE )) -return -EINVAL ; - -/* Send this frame to all sink pads that are direct linked */ -list_for_each_entry (link, &src->entity->links, list) { -if (link->source == src && - (link->flags &MEDIA_LNK_FL_ENABLED )) { -struct vimc_ent_device *ved =NULL ; -struct media_entity *entity = link->sink->entity; - -if (is_media_entity_v4l2_subdev (entity)) { -struct v4l2_subdev *sd = - container_of(entity, struct v4l2_subdev, - entity); - ved =v4l2_get_subdevdata (sd); - }else if (is_media_entity_v4l2_video_device (entity)) { -struct video_device *vdev = -container_of (entity, - struct video_device, - entity); - ved =video_get_drvdata (vdev); - } -if (ved && ved->process_frame) - ved->process_frame (ved, link->sink, frame); - } - } - -return 0 ; -} -EXPORT_SYMBOL_GPL (vimc_propagate_frame); -/* Helper function to allocate and initialize pads */ struct media_pad *vimc_pads_init (u16 num_pads,const unsigned long *pads_flag) {
drivers/media/platform/vimc/vimc-common.h +2 -13
@@ -113,24 +113,13 @@ struct vimc_pix_map {struct vimc_ent_device {struct media_entity *ent;struct media_pad *pads; -void (*process_frame)(struct vimc_ent_device *ved, -struct media_pad *sink,const void *frame); +void * (*process_frame)(struct vimc_ent_device *ved, +const void *frame);void (*vdev_get_format)(struct vimc_ent_device *ved,struct v4l2_pix_format *fmt); };/** -* vimc_propagate_frame - propagate a frame through the topology -* -* @src: the source pad where the frame is being originated -* @frame: the frame to be propagated -* -* This function will call the process_frame callback from the vimc_ent_device -* struct of the nodes directly connected to the @src pad -*/ -int vimc_propagate_frame (struct media_pad *src,const void *frame); - -/** * vimc_pads_init - initialize pads * * @num_pads: number of pads to initialize
drivers/media/platform/vimc/vimc-debayer.c +4 -22
@@ -321,7 +321,6 @@ static void vimc_deb_set_rgb_mbus_fmt_rgstatic int vimc_deb_s_stream (struct v4l2_subdev *sd,int enable) {struct vimc_deb_device *vdeb =v4l2_get_subdevdata (sd); -int ret;if (enable) {const struct vimc_pix_map *vpix;
@@ -351,22 +350,10 @@ static int vimc_deb_s_stream(struct v4l2if (!vdeb->src_frame)return -ENOMEM ; -/* Turn the stream on in the subdevices directly connected */ - ret =vimc_pipeline_s_stream (&vdeb->sd.entity,1 ); -if (ret) { -vfree (vdeb->src_frame); - vdeb->src_frame =NULL ; -return ret; - } }else {if (!vdeb->src_frame)return 0 ; -/* Disable streaming from the pipe */ - ret =vimc_pipeline_s_stream (&vdeb->sd.entity,0 ); -if (ret) -return ret; -vfree (vdeb->src_frame); vdeb->src_frame =NULL ; }
@@ -480,9 +467,8 @@ static void vimc_deb_calc_rgb_sink(struc } } -static void vimc_deb_process_frame (struct vimc_ent_device *ved, -struct media_pad *sink, -const void *sink_frame) +static void *vimc_deb_process_frame (struct vimc_ent_device *ved, +const void *sink_frame) { struct vimc_deb_device *vdeb = container_of(ved, struct vimc_deb_device, ved);
@@ -491,7 +477,7 @@ static void vimc_deb_process_frame(struc/* If the stream in this node is not active, just return */ if (!vdeb->src_frame) -return ; +return ERR_PTR (-EINVAL );for (i =0 ; i < vdeb->sink_fmt.height; i++)for (j =0 ; j < vdeb->sink_fmt.width; j++) {
@@ -499,12 +485,8 @@ static void vimc_deb_process_frame(struc vdeb->set_rgb_src (vdeb, i, j, rgb); } -/* Propagate the frame through all source pads */ -for (i =1 ; i < vdeb->sd.entity.num_pads; i++) { -struct media_pad *pad = &vdeb->sd.entity.pads[i]; +return vdeb->src_frame; -vimc_propagate_frame (pad, vdeb->src_frame); - } } static void vimc_deb_comp_unbind(struct device *comp, struct device *master,
drivers/media/platform/vimc/vimc-scaler.c +4 -24
@@ -217,7 +217,6 @@ static const struct v4l2_subdev_pad_opsstatic int vimc_sca_s_stream (struct v4l2_subdev *sd,int enable) {struct vimc_sca_device *vsca =v4l2_get_subdevdata (sd); -int ret;if (enable) {const struct vimc_pix_map *vpix;
@@ -245,22 +244,10 @@ static int vimc_sca_s_stream(struct v4l2if (!vsca->src_frame)return -ENOMEM ; -/* Turn the stream on in the subdevices directly connected */ - ret =vimc_pipeline_s_stream (&vsca->sd.entity,1 ); -if (ret) { -vfree (vsca->src_frame); - vsca->src_frame =NULL ; -return ret; - } }else {if (!vsca->src_frame)return 0 ; -/* Disable streaming from the pipe */ - ret =vimc_pipeline_s_stream (&vsca->sd.entity,0 ); -if (ret) -return ret; -vfree (vsca->src_frame); vsca->src_frame =NULL ; }
@@ -346,26 +333,19 @@ static void vimc_sca_fill_src_frame(consvimc_sca_scale_pix (vsca, i, j, sink_frame); } -static void vimc_sca_process_frame (struct vimc_ent_device *ved, -struct media_pad *sink, -const void *sink_frame) +static void *vimc_sca_process_frame (struct vimc_ent_device *ved, +const void *sink_frame) { struct vimc_sca_device *vsca = container_of(ved, struct vimc_sca_device, ved); -unsigned int i;/* If the stream in this node is not active, just return */ if (!vsca->src_frame) -return ; +return ERR_PTR (-EINVAL );vimc_sca_fill_src_frame (vsca, sink_frame); -/* Propagate the frame through all source pads */ -for (i =1 ; i < vsca->sd.entity.num_pads; i++) { -struct media_pad *pad = &vsca->sd.entity.pads[i]; - -vimc_propagate_frame (pad, vsca->src_frame); - } +return vsca->src_frame; }; static void vimc_sca_comp_unbind(struct device *comp, struct device *master,
drivers/media/platform/vimc/vimc-sensor.c +13 -43
91 lines not on this page · raw message
drivers/media/platform/vimc/vimc-streamer.c new file +188 -0
188 lines not on this page · raw message
drivers/media/platform/vimc/vimc-streamer.h new file +38 -0
@@ -0,0 +1,38 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* +* vimc-streamer.h Virtual Media Controller Driver +* +* Copyright (C) 2018 Lucas A. M. Magalhães <[email protected]> +* +*/ + +#ifndef _VIMC_STREAMER_H_ +#define _VIMC_STREAMER_H_ + +#include <media/media-device.h> + +#include "vimc-common.h" + +#define VIMC_STREAMER_PIPELINE_MAX_SIZE 16 + +struct vimc_stream { +struct media_pipeline pipe; +struct vimc_ent_device *ved_pipeline[VIMC_STREAMER_PIPELINE_MAX_SIZE ]; +unsigned int pipe_size; +u8 *frame; +struct task_struct *kthread; +}; + +/** +* vimc_streamer_s_streamer - start/stop the stream +* +* @stream: the pointer to the stream to start or stop +* @ved: The last entity of the streamer pipeline +* @enable: any non-zero number start the stream, zero stop +* +*/ +int vimc_streamer_s_stream (struct vimc_stream *stream, +struct vimc_ent_device *ved, +int enable); + +#endif //_VIMC_STREAMER_H_
Greg Kroah-Hartman
maintainerPATCH 267/280 media: imx: csi: Disable CSI immediately after last EOF
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve Longerbeam <[email protected]>
commit 2e0fe66e0a136252f4d89dbbccdcb26deb867eb8 upstream.
Disable the CSI immediately after receiving the last EOF before stream off (and thus before disabling the IDMA channel). Do this by moving the wait for EOF completion into a new function csi_idmac_wait_last_eof().
This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on:
while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done
Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset.
The lockup occurs when disabling the IDMA channel at stream off. Disabling the CSI before disabling the IDMA channel appears to be a reliable fix for the hard lockup.
--- drivers/staging/media/imx/imx-media-csi.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/staging/media/imx/imx-media-csi.c +14 -3
@@ -626,7 +626,7 @@ out_put_ipu:return ret; } -static void csi_idmac_stop (struct csi_priv *priv) +static void csi_idmac_wait_last_eof (struct csi_priv *priv) {unsigned long flags;int ret;
@@ -643,7 +643,10 @@ static void csi_idmac_stop(struct csi_pr &priv->last_eof_comp, msecs_to_jiffies(IMX_MEDIA_EOF_TIMEOUT));if (ret ==0 )v4l2_warn (&priv->sd,"wait last EOF timeout\n" ); +} +static void csi_idmac_stop (struct csi_priv *priv) +{devm_free_irq (priv->dev, priv->eof_irq, priv);devm_free_irq (priv->dev, priv->nfb4eof_irq, priv);
@@ -755,6 +758,16 @@ idmac_stop:static void csi_stop (struct csi_priv *priv) { +if (priv->dest ==IPU_CSI_DEST_IDMAC ) +csi_idmac_wait_last_eof (priv); + +/* +* Disable the CSI asap, after syncing with the last EOF. +* Doing so after the IDMA channel is disabled has shown to +* create hard system-wide hangs. +*/ +ipu_csi_disable (priv->csi); +if (priv->dest ==IPU_CSI_DEST_IDMAC ) {csi_idmac_stop (priv);
@@ -762,8 +775,6 @@ static void csi_stop(struct csi_priv *prif (priv->fim)imx_media_fim_set_stream (priv->fim,NULL , false); } - -ipu_csi_disable (priv->csi); }static const struct csi_skip_desc csi_skip[12 ] = {
Greg Kroah-Hartman
maintainerPATCH 268/280 media: imx: csi: Stop upstream before disabling IDMA channel
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve Longerbeam <[email protected]>
commit 4bc1ab41eee9d02ad2483bf8f51a7b72e3504eba upstream.
Move upstream stream off to just after receiving the last EOF completion and disabling the CSI (and thus before disabling the IDMA channel) in csi_stop(). For symmetry also move upstream stream on to beginning of csi_start().
Doing this makes csi_s_stream() more symmetric with prp_s_stream() which will require the same change to fix a hard lockup.
--- drivers/staging/media/imx/imx-media-csi.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
drivers/staging/media/imx/imx-media-csi.c +13 -12
@@ -722,10 +722,16 @@ static int csi_start(struct csi_priv *pr output_fi = &priv->frame_interval[priv->active_output_pad]; +/* start upstream */ + ret =v4l2_subdev_call (priv->src_sd, video, s_stream,1 ); + ret = (ret && ret != -ENOIOCTLCMD ) ? ret :0 ; +if (ret) +return ret; +if (priv->dest ==IPU_CSI_DEST_IDMAC ) { ret =csi_idmac_start (priv);if (ret) -return ret; + goto stop_upstream; } ret =csi_setup (priv);
@@ -753,6 +759,8 @@ fim_off: idmac_stop:if (priv->dest ==IPU_CSI_DEST_IDMAC )csi_idmac_stop (priv); +stop_upstream: +v4l2_subdev_call (priv->src_sd, video, s_stream,0 );return ret; }
@@ -768,6 +776,9 @@ static void csi_stop(struct csi_priv *pr*/ ipu_csi_disable (priv->csi); +/* stop upstream */ +v4l2_subdev_call (priv->src_sd, video, s_stream,0 ); +if (priv->dest ==IPU_CSI_DEST_IDMAC ) {csi_idmac_stop (priv);
@@ -935,23 +946,13 @@ static int csi_s_stream(struct v4l2_subd goto update_count;if (enable) { -/* upstream must be started first, before starting CSI */ - ret =v4l2_subdev_call (priv->src_sd, video, s_stream,1 ); - ret = (ret && ret != -ENOIOCTLCMD ) ? ret :0 ; -if (ret) - goto out; -dev_dbg (priv->dev,"stream ON\n" ); ret =csi_start (priv); -if (ret) { -v4l2_subdev_call (priv->src_sd, video, s_stream,0 ); +if (ret) goto out; - } }else {dev_dbg (priv->dev,"stream OFF\n" ); -/* CSI must be stopped first, then stop upstream */ csi_stop (priv); -v4l2_subdev_call (priv->src_sd, video, s_stream,0 ); } update_count:
Greg Kroah-Hartman
maintainerPATCH 269/280 drm/fb-helper: generic: Fix drm_fbdev_client_restore()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Noralf Trønnes <[email protected]>
commit 78de14c23e031420aa5f61973583635eccd6cd2a upstream.
If fbdev setup has failed, lastclose will give a NULL pointer deref:
[ 77.794295] [drm:drm_lastclose] [ 77.794414] [drm:drm_lastclose] driver lastclose completed [ 77.794660] Unable to handle kernel NULL pointer dereference at virtual address 00000014 [ 77.809460] pgd = b376b71b [ 77.818275] [00000014] *pgd=175ba831, *pte=00000000, *ppte=00000000 [ 77.830813] Internal error: Oops: 17 [#1] ARM [ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core [ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C 5.0.0-rc1+ #1 [ 77.879525] Hardware name: BCM2835 [ 77.889185] PC is at restore_fbdev_mode+0x20/0x164 [ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c [ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14) [ 78.291030] Backtrace: [ 78.300815] [<c04f2d0c>] (restore_fbdev_mode) from [<c04f4708>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c) [ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6:00000000 r5:d891ac00 r4:d891ac00 [ 78.334432] [<c04f46b4>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c04f47e8>] (drm_fbdev_client_restore+0x18/0x20) [ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00 r3:c04f47d0 [ 78.368689] [<c04f47d0>] (drm_fbdev_client_restore) from [<c051b6b4>] (drm_client_dev_restore+0x7c/0xc0) [ 78.385982] [<c051b638>] (drm_client_dev_restore) from [<c04f8fd0>] (drm_lastclose+0xc4/0xd4) [ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800 [ 78.416688] [<c04f8f0c>] (drm_lastclose) from [<c04f9088>] (drm_release+0xa8/0x10c) [ 78.431929] r5:d8a85e00 r4:d7697800 [ 78.442989] [<c04f8fe0>] (drm_release) from [<c02640c4>] (__fput+0x104/0x1c8) [ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:00000008 r5:d74c1b90 r4:d8a8a280 [ 78.472043] [<c0263fc0>] (__fput) from [<c02641ec>] (____fput+0x18/0x1c) [ 78.486363] r10:00000006 r9:d7722000 r8:c01011c4 r7:00000000 r6:c0ebac6c r5:d892a340 [ 78.501869] r4:d8a8a280 [ 78.512002] [<c02641d4>] (____fput) from [<c013ef1c>] (task_work_run+0x98/0xac) [ 78.527186] [<c013ee84>] (task_work_run) from [<c010cc54>] (do_work_pending+0x4f8/0x570) [ 78.543238] r7:d7722030 r6:00000004 r5:d7723fb0 r4:00000000 [ 78.556825] [<c010c75c>] (do_work_pending) from [<c0101034>] (slow_work_pending+0xc/0x20) [ 78.674256] ---[ end trace 70d3a60cf739be3b ]---
Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
--- drivers/gpu/drm/drm_fb_helper.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/gpu/drm/drm_fb_helper.c +1 -3
@@ -3156,9 +3156,7 @@ static void drm_fbdev_client_unregister(static int drm_fbdev_client_restore (struct drm_client_dev *client) { -struct drm_fb_helper *fb_helper =drm_fb_helper_from_client (client); - -drm_fb_helper_restore_fbdev_mode_unlocked (fb_helper); +drm_fb_helper_lastclose (client->dev);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 270/280 drm/radeon/evergreen_cs: fix missing break in switch statement
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream.
Add missing break statement in order to prevent the code from falling through to case CB_TARGET_MASK.
This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough.
--- drivers/gpu/drm/radeon/evergreen_cs.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/radeon/evergreen_cs.c +1 -0
@@ -1299,6 +1299,7 @@ static int evergreen_cs_handle_reg(strucreturn -EINVAL ; } ib[idx] += (u32)((reloc->gpu_offset >>8 ) &0xffffffff ); +break ;case CB_TARGET_MASK : track->cb_target_mask =radeon_get_ib_value (p, idx); track->cb_dirty = true;
Greg Kroah-Hartman
maintainerPATCH 271/280 drm/amd/powerplay: correct power reading on fiji
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Evan Quan <[email protected]>
commit f5742ec36422a39b57f0256e4847f61b3c432f8c upstream.
Set sampling period as 500ms to provide a smooth power reading output. Also, correct the register for power reading.
--- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +3 -3
@@ -3487,14 +3487,14 @@ static int smu7_get_gpu_power(struct pp_smum_send_msg_to_smc (hwmgr, PPSMC_MSG_PmStatusLogStart);cgs_write_ind_register (hwmgr->device,CGS_IND_REG__SMC , - ixSMU_PM_STATUS_94,0 ); + ixSMU_PM_STATUS_95,0 );for (i =0 ; i <10 ; i++) { -mdelay (1 ); +mdelay (500 );smum_send_msg_to_smc (hwmgr, PPSMC_MSG_PmStatusLogSample); tmp =cgs_read_ind_register (hwmgr->device,CGS_IND_REG__SMC , - ixSMU_PM_STATUS_94); + ixSMU_PM_STATUS_95);if (tmp !=0 )break ; }
Greg Kroah-Hartman
maintainerPATCH 272/280 drm/amd/display: dont call dm_pp_ function from an fpu block
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harry Wentland <[email protected]>
commit 59d3191f14dc18881fec1172c7096b7863622803 upstream.
Powerplay functions called from dm_pp_* functions tend to do a mutex_lock which isn't safe to do inside a kernel_fpu_begin/end block as those will disable/enable preemption.
Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make sure they happen outside of kernel_fpu_begin/end.
--- drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c +6 -2
@@ -1347,12 +1347,12 @@ void dcn_bw_update_from_pplib(struct dcstruct dm_pp_clock_levels_with_voltage fclks = {0 }, dcfclks = {0 };bool res; -kernel_fpu_begin (); -/* TODO: This is not the proper way to obtain fabric_and_dram_bandwidth, should be min(fclk, memclk) */ res =dm_pp_get_clock_levels_by_type_with_voltage ( ctx,DM_PP_CLOCK_TYPE_FCLK , &fclks); +kernel_fpu_begin (); +if (res) res =verify_clock_values (&fclks);
@@ -1371,9 +1371,13 @@ void dcn_bw_update_from_pplib(struct dc }else BREAK_TO_DEBUGGER (); +kernel_fpu_end (); + res =dm_pp_get_clock_levels_by_type_with_voltage ( ctx,DM_PP_CLOCK_TYPE_DCFCLK , &dcfclks); +kernel_fpu_begin (); +if (res) res =verify_clock_values (&dcfclks);
Greg Kroah-Hartman
maintainerPATCH 273/280 KVM: Call kvm_arch_memslots_updated() before updating memslots
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 152482580a1b0accb60676063a1ac57b2d12daf6 upstream.
kvm_arch_memslots_updated() is at this point in time an x86-specific hook for handling MMIO generation wraparound. x86 stashes 19 bits of the memslots generation number in its MMIO sptes in order to avoid full page fault walks for repeat faults on emulated MMIO addresses. Because only 19 bits are used, wrapping the MMIO generation number is possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that the generation has changed so that it can invalidate all MMIO sptes in case the effective MMIO generation has wrapped so as to avoid using a stale spte, e.g. a (very) old spte that was created with generation==0.
Given that the purpose of kvm_arch_memslots_updated() is to prevent consuming stale entries, it needs to be called before the new generation is propagated to memslots. Invalidating the MMIO sptes after updating memslots means that there is a window where a vCPU could dereference the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO spte that was created with (pre-wrap) generation==0.
--- arch/mips/include/asm/kvm_host.h | 2 +- arch/powerpc/include/asm/kvm_host.h | 2 +- arch/s390/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/mmu.c | 4 ++-- arch/x86/kvm/x86.c | 4 ++-- include/linux/kvm_host.h | 2 +- virt/kvm/arm/mmu.c | 2 +- virt/kvm/kvm_main.c | 7 +++++-- 9 files changed, 15 insertions(+), 12 deletions(-)
arch/mips/include/asm/kvm_host.h +1 -1
@@ -1131,7 +1131,7 @@ static inline void kvm_arch_hardware_unsstatic inline void kvm_arch_sync_events (struct kvm *kvm) {}static inline void kvm_arch_free_memslot (struct kvm *kvm,struct kvm_memory_slot *free,struct kvm_memory_slot *dont) {} -static inline void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots) {} +static inline void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen) {}static inline void kvm_arch_sched_in (struct kvm_vcpu *vcpu,int cpu) {}static inline void kvm_arch_vcpu_blocking (struct kvm_vcpu *vcpu) {}static inline void kvm_arch_vcpu_unblocking (struct kvm_vcpu *vcpu) {}
arch/powerpc/include/asm/kvm_host.h +1 -1
@@ -822,7 +822,7 @@ struct kvm_vcpu_arch {static inline void kvm_arch_hardware_disable (void ) {}static inline void kvm_arch_hardware_unsetup (void ) {}static inline void kvm_arch_sync_events (struct kvm *kvm) {} -static inline void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots) {} +static inline void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen) {}static inline void kvm_arch_flush_shadow_all (struct kvm *kvm) {}static inline void kvm_arch_sched_in (struct kvm_vcpu *vcpu,int cpu) {}static inline void kvm_arch_exit (void ) {}
arch/s390/include/asm/kvm_host.h +1 -1
@@ -865,7 +865,7 @@ static inline void kvm_arch_vcpu_uninit(static inline void kvm_arch_sched_in (struct kvm_vcpu *vcpu,int cpu) {}static inline void kvm_arch_free_memslot (struct kvm *kvm,struct kvm_memory_slot *free,struct kvm_memory_slot *dont) {} -static inline void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots) {} +static inline void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen) {}static inline void kvm_arch_flush_shadow_all (struct kvm *kvm) {}static inline void kvm_arch_flush_shadow_memslot (struct kvm *kvm,struct kvm_memory_slot *slot) {}
arch/x86/include/asm/kvm_host.h +1 -1
@@ -1194,7 +1194,7 @@ void kvm_mmu_clear_dirty_pt_masked(strucstruct kvm_memory_slot *slot, gfn_t gfn_offset, unsigned long mask);void kvm_mmu_zap_all (struct kvm *kvm); -void kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,struct kvm_memslots *slots); +void kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,u64 gen);unsigned int kvm_mmu_calculate_mmu_pages (struct kvm *kvm);void kvm_mmu_change_mmu_pages (struct kvm *kvm,unsigned int kvm_nr_mmu_pages);
arch/x86/kvm/mmu.c +2 -2
@@ -5774,13 +5774,13 @@ static bool kvm_has_zapped_obsolete_pagereturn unlikely (!list_empty_careful (&kvm->arch.zapped_obsolete_pages)); } -void kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,struct kvm_memslots *slots) +void kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,u64 gen) {/* * The very rare case: if the generation-number is round, * zap all shadow pages. */ -if (unlikely ((slots->generation &MMIO_GEN_MASK ) ==0 )) { +if (unlikely ((gen &MMIO_GEN_MASK ) ==0 )) {kvm_debug_ratelimited ("kvm: zapping shadow pages for mmio generation wraparound\n" );kvm_mmu_invalidate_zap_all_pages (kvm); }
arch/x86/kvm/x86.c +2 -2
@@ -9108,13 +9108,13 @@ out_free:return -ENOMEM ; } -void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots) +void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen) {/* * memslots->generation has been incremented. * mmio generation may have reached its maximum value. */ -kvm_mmu_invalidate_mmio_sptes (kvm, slots); +kvm_mmu_invalidate_mmio_sptes (kvm, gen); } int kvm_arch_prepare_memory_region(struct kvm *kvm,
include/linux/kvm_host.h +1 -1
@@ -633,7 +633,7 @@ void kvm_arch_free_memslot(struct kvm *k struct kvm_memory_slot *dont);int kvm_arch_create_memslot (struct kvm *kvm,struct kvm_memory_slot *slot,unsigned long npages); -void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots); +void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen); int kvm_arch_prepare_memory_region(struct kvm *kvm, struct kvm_memory_slot *memslot, const struct kvm_userspace_memory_region *mem,
virt/kvm/arm/mmu.c +1 -1
@@ -2154,7 +2154,7 @@ int kvm_arch_create_memslot(struct kvm *return 0 ; } -void kvm_arch_memslots_updated (struct kvm *kvm,struct kvm_memslots *slots) +void kvm_arch_memslots_updated (struct kvm *kvm,u64 gen) { }
virt/kvm/kvm_main.c +5 -2
@@ -873,6 +873,7 @@ static struct kvm_memslots *install_new_ int as_id, struct kvm_memslots *slots) { struct kvm_memslots *old_memslots = __kvm_memslots(kvm, as_id); +u64 gen;/* * Set the low bit in the generation, which disables SPTE caching
@@ -895,9 +896,11 @@ static struct kvm_memslots *install_new_* space 0 will use generations 0, 4, 8, ... while * address space 1 will * use generations 2, 6, 10, 14, ... */ - slots->generation +=KVM_ADDRESS_SPACE_NUM *2 -1 ; + gen = slots->generation +KVM_ADDRESS_SPACE_NUM *2 -1 ; -kvm_arch_memslots_updated (kvm, slots); +kvm_arch_memslots_updated (kvm, gen); + + slots->generation = gen;return old_memslots; }
Greg Kroah-Hartman
maintainerPATCH 274/280 KVM: x86/mmu: Detect MMIO generation wrap in any address space
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit e1359e2beb8b0a1188abc997273acbaedc8ee791 upstream.
The check to detect a wrap of the MMIO generation explicitly looks for a generation number of zero. Now that unique memslots generation numbers are assigned to each address space, only address space 0 will get a generation number of exactly zero when wrapping. E.g. when address space 1 goes from 0x7fffe to 0x80002, the MMIO generation number will wrap to 0x2. Adjust the MMIO generation to strip the address space modifier prior to checking for a wrap.
--- arch/x86/kvm/mmu.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)
arch/x86/kvm/mmu.c +19 -2
@@ -5776,11 +5776,28 @@ static bool kvm_has_zapped_obsolete_pagevoid kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,u64 gen) { + gen &=MMIO_GEN_MASK ; + +/* +* Shift to eliminate the "update in-progress" flag, which isn't +* included in the spte's generation number. +*/ + gen >>=1 ; + +/* +* Generation numbers are incremented in multiples of the number of +* address spaces in order to provide unique generations across all +* address spaces. Strip what is effectively the address space +* modifier prior to checking for a wrap of the MMIO generation so +* that a wrap in any address space is detected. +*/ + gen &= ~((u64 )KVM_ADDRESS_SPACE_NUM -1 ); +/* -* The very rare case: if the generation-number is round, +* The very rare case: if the MMIO generation number has wrapped, * zap all shadow pages. */ -if (unlikely ((gen &MMIO_GEN_MASK ) ==0 )) { +if (unlikely (gen ==0 )) {kvm_debug_ratelimited ("kvm: zapping shadow pages for mmio generation wraparound\n" );kvm_mmu_invalidate_zap_all_pages (kvm); }
Greg Kroah-Hartman
maintainerPATCH 275/280 KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit ddfd1730fd829743e41213e32ccc8b4aa6dc8325 upstream.
When installing new memslots, KVM sets bit 0 of the generation number to indicate that an update is in-progress. Until the update is complete, there are no guarantees as to whether a vCPU will see the old or the new memslots. Explicity prevent caching MMIO accesses so as to avoid using an access cached from the old memslots after the new memslots have been installed.
Note that it is unclear whether or not disabling caching during the update window is strictly necessary as there is no definitive documentation as to what ordering guarantees KVM provides with respect to updating memslots. That being said, the MMIO spte code does not allow reusing sptes created while an update is in-progress, and the associated documentation explicitly states:
We do not want to use an MMIO sptes created with an odd generation number, ... If KVM is unlucky and creates an MMIO spte while the low bit is 1, the next access to the spte will always be a cache miss.
At the very least, disabling the per-vCPU MMIO cache during updates will make its behavior consistent with the MMIO spte behavior and documentation.
--- arch/x86/kvm/x86.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/x86/kvm/x86.h +6 -1
@@ -181,6 +181,11 @@ static inline bool emul_is_noncanonical_static inline void vcpu_cache_mmio_info (struct kvm_vcpu *vcpu,gva_t gva,gfn_t gfn,unsigned access) { +u64 gen =kvm_memslots (vcpu->kvm)->generation; + +if (unlikely (gen &1 )) +return ; +/* * If this is a shadow nested page table, the "GVA" is * actually a nGPA.
@@ -188,7 +193,7 @@ static inline void vcpu_cache_mmio_info( vcpu->arch.mmio_gva =mmu_is_nested (vcpu) ?0 : gva &PAGE_MASK ; vcpu->arch.access = access; vcpu->arch.mmio_gfn = gfn; - vcpu->arch.mmio_gen =kvm_memslots (vcpu->kvm)->generation; + vcpu->arch.mmio_gen = gen; }static inline bool vcpu_match_mmio_gen (struct kvm_vcpu *vcpu)
Greg Kroah-Hartman
maintainerPATCH 276/280 KVM: nVMX: Sign extend displacements of VMX instrs mem operands
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 946c522b603f281195af1df91837a1d4d1eb3bc9 upstream.
The VMCS.EXIT_QUALIFCATION field reports the displacements of memory operands for various instructions, including VMX instructions, as a naturally sized unsigned value, but masks the value by the addr size, e.g. given a ModRM encoded as -0x28(%ebp), the -0x28 displacement is reported as 0xffffffd8 for a 32-bit address size. Despite some weird wording regarding sign extension, the SDM explicitly states that bits beyond the instructions address size are undefined:
In all cases, bits of this field beyond the instruction’s address size are undefined.
Failure to sign extend the displacement results in KVM incorrectly treating a negative displacement as a large positive displacement when the address size of the VMX instruction is smaller than KVM's native size, e.g. a 32-bit address size on a 64-bit KVM.
The very original decoding, added by commit 064aea774768 ("KVM: nVMX:
Decoding memory operands of VMX instructions"), sort of modeled sign extension by truncating the final virtual/linear address for a 32-bit address size. I.e. it messed up the effective address but made it work by adjusting the final address.
When segmentation checks were added, the truncation logic was kept as-is and no sign extension logic was introduced. In other words, it kept calculating the wrong effective address while mostly generating the correct virtual/linear address. As the effective address is what's used in the segment limit checks, this results in KVM incorreclty injecting #GP/#SS faults due to non-existent segment violations when a nested VMM uses negative displacements with an address size smaller than KVM's native address size.
Using the -0x28(%ebp) example, an EBP value of 0x1000 will result in KVM using 0x100000fd8 as the effective address when checking for a segment limit violation. This causes a 100% failure rate when running a 32-bit KVM build as L1 on top of a 64-bit KVM L0.
--- arch/x86/kvm/vmx.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/x86/kvm/vmx.c +4 -0
@@ -8184,6 +8184,10 @@ static int get_vmx_mem_address(struct kv/* Addr = segment_base + offset */ /* offset = base + [index * scale] + displacement */ off = exit_qualification;/* holds the displacement */ +if (addr_size ==1 ) + off = (gva_t )sign_extend64 (off,31 ); +else if (addr_size ==0 ) + off = (gva_t )sign_extend64 (off,15 );if (base_is_valid) off +=kvm_register_read (vcpu, base_reg);if (index_is_valid)
Greg Kroah-Hartman
maintainerPATCH 277/280 KVM: nVMX: Apply addr size mask to effective address for VMX instructions
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.
The address size of an instruction affects the effective address, not the virtual/linear address. The final address may still be truncated, e.g. to 32-bits outside of long mode, but that happens irrespective of the address size, e.g. a 32-bit address size can yield a 64-bit virtual address when using FS/GS with a non-zero base.
--- arch/x86/kvm/vmx.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx.c +23 -2
@@ -8193,20 +8193,41 @@ static int get_vmx_mem_address(struct kvif (index_is_valid) off +=kvm_register_read (vcpu, index_reg)<<scaling;vmx_get_segment (vcpu, &s, seg_reg); - *ret = s.base + off; +/* +* The effective address, i.e. @off, of a memory operand is truncated +* based on the address size of the instruction. Note that this is +* the *effective address*, i.e. the address prior to accounting for +* the segment's base. +*/ if (addr_size ==1 )/* 32 bit */ - *ret &=0xffffffff ; + off &=0xffffffff ; +else if (addr_size ==0 )/* 16 bit */ + off &=0xffff ;/* Checks for #GP/#SS exceptions. */ exn = false;if (is_long_mode (vcpu)) { +/* +* The virtual/linear address is never truncated in 64-bit +* mode, e.g. a 32-bit address size can yield a 64-bit virtual +* address when using FS/GS with a non-zero base. +*/ + *ret = s.base + off; +/* Long mode: #GP(0)/#SS(0) if the memory address is in a * non-canonical form. This is the only check on the memory * destination for long mode! */ exn =is_noncanonical_address (*ret, vcpu); }else if (is_protmode (vcpu)) { +/* +* When not in long mode, the virtual/linear address is +* unconditionally truncated to 32 bits regardless of the +* address size. +*/ + *ret = (s.base + off) &0xffffffff ; +/* Protected mode: apply checks for segment validity in the * following order: * - segment type check (#GP(0) may be thrown)
Greg Kroah-Hartman
maintainerPATCH 278/280 KVM: nVMX: Ignore limit checks on VMX instructions using flat segments
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 34333cc6c2cb021662fd32e24e618d1b86de95bf upstream.
Regarding segments with a limit==0xffffffff, the SDM officially states:
When the effective limit is FFFFFFFFH (4 GBytes), these accesses may or may not cause the indicated exceptions. Behavior is implementation-specific and may vary from one execution to another.
In practice, all CPUs that support VMX ignore limit checks for "flat segments", i.e. an expand-up data or code segment with base=0 and limit=0xffffffff. This is subtly different than wrapping the effective address calculation based on the address size, as the flat segment behavior also applies to accesses that would wrap the 4g boundary, e.g. a 4-byte access starting at 0xffffffff will access linear addresses 0xffffffff, 0x0, 0x1 and 0x2.
--- arch/x86/kvm/vmx.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
arch/x86/kvm/vmx.c +9 -3
@@ -8251,10 +8251,16 @@ static int get_vmx_mem_address(struct kv/* Protected mode: #GP(0)/#SS(0) if the segment is unusable. */ exn = (s.unusable !=0 ); -/* Protected mode: #GP(0)/#SS(0) if the memory -* operand is outside the segment limit. + +/* +* Protected mode: #GP(0)/#SS(0) if the memory operand is +* outside the segment limit. All CPUs that support VMX ignore +* limit checks for flat segments, i.e. segments with base==0, +* limit==0xffffffff and of type expand-up data or code. */ - exn = exn || (off +sizeof (u64) > s.limit); +if (!(s.base ==0 && s.limit ==0xffffffff && + ((s.type &8 ) || !(s.type &4 )))) + exn = exn || (off +sizeof (u64) > s.limit); }if (exn) { kvm_queue_exception_e(vcpu,
Greg Kroah-Hartman
maintainerPATCH 279/280 bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Coly Li <[email protected]>
commit dc7292a5bcb4c878b076fca2ac3fc22f81b8f8df upstream.
In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")' REQ_META is replaced by REQ_PRIO to indicate metadata bio. This assumption is not always correct, e.g. XFS uses REQ_META to mark metadata bio other than REQ_PRIO. This is why Nix noticed that bcache does not cache metadata for XFS after the above commit.
Thanks to Dave Chinner, he explains the difference between REQ_META and REQ_PRIO from view of file system developer. Here I quote part of his explanation from mailing list,
REQ_META is used for metadata. REQ_PRIO is used to communicate to the lower layers that the submitter considers this IO to be more important that non REQ_PRIO IO and so dispatch should be expedited.
IOWs, if the filesystem considers metadata IO to be more important that user data IO, then it will use REQ_PRIO | REQ_META rather than just REQ_META.
Then it seems bios with REQ_META or REQ_PRIO should both be cached for performance optimation, because they are all probably low I/O latency demand by upper layer (e.g. file system).
So in this patch, when we want to decide whether to bypass the cache, REQ_META and REQ_PRIO are both checked. Then both metadata and high priority I/O requests will be handled properly.
--- drivers/md/bcache/request.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/md/bcache/request.c +4 -3
@@ -392,10 +392,11 @@ static bool check_should_bypass(struct c/* * Flag for bypass if the IO is for read-ahead or background, -* unless the read-ahead request is for metadata (eg, for gfs2). +* unless the read-ahead request is for metadata +* (eg, for gfs2 or xfs). */ if (bio->bi_opf & (REQ_RAHEAD |REQ_BACKGROUND ) && - !(bio->bi_opf &REQ_META )) + !(bio->bi_opf & (REQ_META |REQ_PRIO ))) goto skip; if (bio->bi_iter.bi_sector & (c->sb.block_size - 1) ||
@@ -877,7 +878,7 @@ static int cached_dev_cache_miss(struct }if (!(bio->bi_opf &REQ_RAHEAD ) && - !(bio->bi_opf &REQ_META ) && + !(bio->bi_opf & (REQ_META |REQ_PRIO )) && s->iop.c->gc_stats.in_use <CUTOFF_CACHE_READA ) reada =min_t (sector_t, dc->readahead >>9 ,get_capacity (bio->bi_disk) -bio_end_sector (bio));
Greg Kroah-Hartman
maintainerPATCH 280/280 s390/setup: fix boot crash for machine without EDAT-1
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Schwidefsky <[email protected]>
commit 86a86804e4f18fc3880541b3d5a07f4df0fe29cb upstream.
The fix to make WARN work in the early boot code created a problem on older machines without EDAT-1. The setup_lowcore_dat_on function uses the pointer from lowcore_ptr[0] to set the DAT bit in the new PSWs. That does not work if the kernel page table is set up with 4K pages as the prefix address maps to absolute zero.
To make this work the PSWs need to be changed with via address 0 in form of the S390_lowcore definition.
--- arch/s390/kernel/setup.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
arch/s390/kernel/setup.c +6 -7
@@ -387,13 +387,12 @@ static void __init setup_lowcore_dat_offstatic void __init setup_lowcore_dat_on (void ) { -struct lowcore *lc; - - lc = lowcore_ptr[0 ]; - lc->external_new_psw.mask |=PSW_MASK_DAT ; - lc->svc_new_psw.mask |=PSW_MASK_DAT ; - lc->program_new_psw.mask |=PSW_MASK_DAT ; - lc->io_new_psw.mask |=PSW_MASK_DAT ; +__ctl_clear_bit (0 ,28 ); + S390_lowcore.external_new_psw.mask |=PSW_MASK_DAT ; + S390_lowcore.svc_new_psw.mask |=PSW_MASK_DAT ; + S390_lowcore.program_new_psw.mask |=PSW_MASK_DAT ; + S390_lowcore.io_new_psw.mask |=PSW_MASK_DAT ; +__ctl_set_bit (0 ,28 ); }static struct resource code_resource = {
stable-rc/linux-4.19.y boot: 59 boots: 0 failed, 59 passed (v4.19.30-281-gf4bc3dea377c)
stable-rc/linux-4.19.y boot: 59 boots: 0 failed, 59 passed (v4.19.30-281-gf4bc3dea377c)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.30-281-gf4bc3dea377c/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.30-281-gf4bc3dea377c/
Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.30-281-gf4bc3dea377c
Git Commit: f4bc3dea377c7afbfe0a36d2c72e9031910349e9
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 34 unique boards, 16 SoC families, 10 builds out of 206
---
For more info write to <[email protected]>
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.31 release. There are 280 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Mar 24 11:11:09 UTC 2019. Anything received after that time might be too late.
Build results:
total: 156 pass: 156 fail: 0 Qemu test results: total: 345 pass: 345 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.31 release. There are 280 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Mar 24 11:11:09 UTC 2019. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.31-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.19.31-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: f4bc3dea377c7afbfe0a36d2c72e9031910349e9
git describe: v4.19.30-281-gf4bc3dea377c
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.30-281-gf4bc3dea377c
No regressions (compared to build v4.19.30)
No fixes (compared to build v4.19.30)
Ran 23127 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.31 release. There are 280 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Mar 24 11:11:09 UTC 2019. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.31-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
28 tests: 28 pass, 0 failLinux version: 4.19.31-rc1-gf4bc3de
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic