Skip to contentSkip to conversation

4.19.188-rc1 review

PATCH In review Greg Kroah-Hartman 7 participants 20 messages Apr 15, 2021 – Apr 16, 2021

Subsystems (2)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.19.188-rc1 review

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.188-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.19.188-rc1

Juergen Gross <[email protected]>
xen/events: fix setting irq affinity

Arnaldo Carvalho de Melo <[email protected]>
perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches

Saravana Kannan <[email protected]>
driver core: Fix locking bug in deferred_probe_timeout_work_func()

Florian Westphal <[email protected]>
netfilter: x_tables: fix compat match/target pad out-of-bound write

Greg Kroah-Hartman <[email protected]>
staging: m57621-mmc: delete driver from the tree.

Florian Fainelli <[email protected]>
net: phy: broadcom: Only advertise EEE for supported modes

Zihao Yu <[email protected]>
riscv,entry: fix misaligned base for excp_vect_table

Yufen Yu <[email protected]>
block: only update parent bi_status when bio fail

Dmitry Osipenko <[email protected]>
drm/tegra: dc: Don't set PLL clock to 0Hz

Bob Peterson <[email protected]>
gfs2: report "already frozen/thawed" errors

Arnd Bergmann <[email protected]>
drm/imx: imx-ldb: fix out of bounds array access warning

Suzuki K Poulose <[email protected]>
KVM: arm64: Disable guest access to trace filter controls

Suzuki K Poulose <[email protected]>
KVM: arm64: Hide system instruction access to Trace registers

-------------

Diffstat:

 Makefile                               |    4 +-
 arch/arm64/include/asm/kvm_arm.h       |    1 +
 arch/arm64/kernel/cpufeature.c         |    1 -
 arch/arm64/kvm/debug.c                 |    2 +
 arch/riscv/kernel/entry.S              |    1 +
 block/bio.c                            |    2 +-
 drivers/base/dd.c                      |    8 +-
 drivers/gpu/drm/imx/imx-ldb.c          |   10 +
 drivers/gpu/drm/tegra/dc.c             |   10 +-
 drivers/net/phy/bcm-phy-lib.c          |   11 +-
 drivers/staging/Kconfig                |    2 -
 drivers/staging/Makefile               |    1 -
 drivers/staging/mt7621-mmc/Kconfig     |   16 -
 drivers/staging/mt7621-mmc/Makefile    |   42 -
 drivers/staging/mt7621-mmc/TODO        |    8 -
 drivers/staging/mt7621-mmc/board.h     |   63 -
 drivers/staging/mt7621-mmc/dbg.c       |  307 ----
 drivers/staging/mt7621-mmc/dbg.h       |  149 --
 drivers/staging/mt7621-mmc/mt6575_sd.h |  488 -------
 drivers/staging/mt7621-mmc/sd.c        | 2392 --------------------------------
 drivers/xen/events/events_base.c       |    4 +-
 fs/gfs2/super.c                        |   10 +-
 net/ipv4/netfilter/arp_tables.c        |    2 +
 net/ipv4/netfilter/ip_tables.c         |    2 +
 net/ipv6/netfilter/ip6_tables.c        |    2 +
 net/netfilter/x_tables.c               |   10 +-
 tools/perf/util/map.c                  |    7 +-
 27 files changed, 54 insertions(+), 3501 deletions(-)
author maintainer
#1 lore raw

PATCH 1/13 KVM: arm64: Hide system instruction access to Trace registers

From: Suzuki K Poulose <[email protected]>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest, when the trace register accesses are trapped (CPTR_EL2.TTA == 1). So, the guest will get an undefined instruction, if trusts the ID registers and access one of the trace registers. Lets be nice to the guest and hide the feature to avoid unexpected behavior.

Even though this can be done at KVM sysreg emulation layer, we do this by removing the TRACEVER from the sanitised feature register field. This is fine as long as the ETM drivers can handle the individual trace units separately, even when there are differences among the CPUs.

---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)
arch/arm64/kernel/cpufeature.c +0 -1
index 1719d21a171a..122d5e843ab6 100644
@@ -258,7 +258,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
Signature · 1 line
2.30.2
author maintainer
#2 lore raw

PATCH 2/13 KVM: arm64: Disable guest access to trace filter controls

In reply to Greg Kroah-Hartman

From: Suzuki K Poulose <[email protected]>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers. We do not advertise the Trace filter feature to the guest (ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with the filtering controls set by a nvhe host.

---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)
arch/arm64/include/asm/kvm_arm.h +1 -0
index a3b6f58d188c..6d43f7901da2 100644
@@ -198,6 +198,7 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
arch/arm64/kvm/debug.c +2 -0
index 4e722d73a3c3..3606f6b89094 100644
@@ -100,6 +100,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -123,6 +124,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
Signature · 1 line
2.30.2
author maintainer
#3 lore raw

PATCH 3/13 drm/imx: imx-ldb: fix out of bounds array access warning

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the warning, as well as any possible other error condition that may be triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF, but Liu Ying points out that the driver may hit the out-of-bounds problem at runtime anyway.

---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
drivers/gpu/drm/imx/imx-ldb.c +10 -0
index 221a8cbc57f9..a4dba034dca4 100644
@@ -206,6 +206,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -264,6 +269,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
Signature · 1 line
2.30.2
author maintainer
#4 lore raw

PATCH 4/13 gfs2: report "already frozen/thawed" errors

In reply to Greg Kroah-Hartman

From: Bob Peterson <[email protected]>

[ Upstream commit ff132c5f93c06bd4432bbab5c369e468653bdec4 ]

Before this patch, gfs2's freeze function failed to report an error when the target file system was already frozen as it should (and as generic vfs function freeze_super does. Similarly, gfs2's thaw function failed to report an error when trying to thaw a file system that is not frozen, as vfs function thaw_super does. The errors were checked, but it always returned a 0 return code.

This patch adds the missing error return codes to gfs2 freeze and thaw.

---
 fs/gfs2/super.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
fs/gfs2/super.c +6 -4
index 22cd68bd8c9b..3cc2237e5896 100644
@@ -1000,11 +1000,13 @@ void gfs2_freeze_func(struct work_struct *work)
 static int gfs2_freeze(struct super_block *sb)
 {
 	struct gfs2_sbd *sdp = sb->s_fs_info;
-	int error = 0;
+	int error;
 
 	mutex_lock(&sdp->sd_freeze_mutex);
-	if (atomic_read(&sdp->sd_freeze_state) != SFS_UNFROZEN)
+	if (atomic_read(&sdp->sd_freeze_state) != SFS_UNFROZEN) {
+		error = -EBUSY;
 		goto out;
+	}
 
 	if (test_bit(SDF_SHUTDOWN, &sdp->sd_flags)) {
 		error = -EINVAL;
@@ -1046,10 +1048,10 @@ static int gfs2_unfreeze(struct super_block *sb)
 	struct gfs2_sbd *sdp = sb->s_fs_info;
 
 	mutex_lock(&sdp->sd_freeze_mutex);
-        if (atomic_read(&sdp->sd_freeze_state) != SFS_FROZEN ||
+	if (atomic_read(&sdp->sd_freeze_state) != SFS_FROZEN ||
 	    !gfs2_holder_initialized(&sdp->sd_freeze_gh)) {
 		mutex_unlock(&sdp->sd_freeze_mutex);
-                return 0;
+		return -EINVAL;
 	}
 
 	gfs2_glock_dq_uninit(&sdp->sd_freeze_gh);
Signature · 1 line
2.30.2
author maintainer
#5 lore raw

PATCH 5/13 drm/tegra: dc: Dont set PLL clock to 0Hz

In reply to Greg Kroah-Hartman

From: Dmitry Osipenko <[email protected]>

[ Upstream commit f8fb97c915954fc6de6513cdf277103b5c6df7b3 ]

RGB output doesn't allow to change parent clock rate of the display and PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall not set the display clock to 0Hz since this change propagates to the parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.

This bug stayed unnoticed because by default PLLP is used as the parent clock for the display controller and PLLP silently skips the erroneous 0Hz rate changes because it always has active child clocks that don't permit rate changes. The PLLP isn't acceptable for some devices that we want to upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel clock rate requirements that can't be fulfilled by using PLLP and then the bug pops up in this case since parent clock is set to 0Hz, killing the display output.

Don't touch DC clock if pclk=0 in order to fix the problem.

---
 drivers/gpu/drm/tegra/dc.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/tegra/dc.c +5 -5
index 965088afcfad..03adb4cf325b 100644
@@ -1670,6 +1670,11 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
 			dev_err(dc->dev,
 				"failed to set clock rate to %lu Hz\n",
 				state->pclk);
+
+		err = clk_set_rate(dc->clk, state->pclk);
+		if (err < 0)
+			dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
+				dc->clk, state->pclk, err);
 	}
 
 	DRM_DEBUG_KMS("rate: %lu, div: %u\n", clk_get_rate(dc->clk),
@@ -1680,11 +1685,6 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
 		value = SHIFT_CLK_DIVIDER(state->div) | PIXEL_CLK_DIVIDER_PCD1;
 		tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
 	}
-
-	err = clk_set_rate(dc->clk, state->pclk);
-	if (err < 0)
-		dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
-			dc->clk, state->pclk, err);
 }
 
 static void tegra_dc_stop(struct tegra_dc *dc)
Signature · 1 line
2.30.2
author maintainer
#6 lore raw

PATCH 6/13 block: only update parent bi_status when bio fail

In reply to Greg Kroah-Hartman

From: Yufen Yu <[email protected]>

[ Upstream commit 3edf5346e4f2ce2fa0c94651a90a8dda169565ee ]

For multiple split bios, if one of the bio is fail, the whole should return error to application. But we found there is a race between bio_integrity_verify_fn and bio complete, which return io success to application after one of the bio fail. The race as following:

split bio(READ) kworker

nvme_complete_rq
blk_update_request //split error=0
bio_endio

    bio_integrity_endio
      queue_work(kintegrityd_wq, &bip->bip_work);

                         bio_integrity_verify_fn
                         bio_endio //split bio
                          __bio_chain_endio
                             if (!parent->bi_status)

                               <interrupt entry>
                               nvme_irq
                                 blk_update_request //parent error=7
                                 req_bio_endio
                                    bio->bi_status = 7 //parent bio
                               <interrupt exit>

                               parent->bi_status = 0
                        parent->bi_end_io() // return bi_status=0

The bio has been split as two: split and parent. When split bio completed, it depends on kworker to do endio, while bio_integrity_verify_fn have been interrupted by parent bio complete irq handler. Then, parent bio->bi_status which have been set in irq handler will overwrite by kworker.

In fact, even without the above race, we also need to conside the concurrency beteen mulitple split bio complete and update the same parent bi_status. Normally, multiple split bios will be issued to the same hctx and complete from the same irq vector. But if we have updated queue map between multiple split bios, these bios may complete on different hw queue and different irq vector. Then the concurrency update parent bi_status may cause the final status error.

---
 block/bio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
block/bio.c +1 -1
index 3d757055305f..fe749404ef93 100644
@@ -314,7 +314,7 @@ static struct bio *__bio_chain_endio(struct bio *bio)
 {
 	struct bio *parent = bio->bi_private;
 
-	if (!parent->bi_status)
+	if (bio->bi_status && !parent->bi_status)
 		parent->bi_status = bio->bi_status;
 	bio_put(bio);
 	return parent;
Signature · 1 line
2.30.2
author maintainer
#7 lore raw

PATCH 7/13 riscv,entry: fix misaligned base for excp_vect_table

In reply to Greg Kroah-Hartman

From: Zihao Yu <[email protected]>

[ Upstream commit ac8d0b901f0033b783156ab2dc1a0e73ec42409b ]

In RV64, the size of each entry in excp_vect_table is 8 bytes. If the base of the table is not 8-byte aligned, loading an entry in the table will raise a misaligned exception. Although such exception will be handled by opensbi/bbl, this still causes performance degradation.

---
 arch/riscv/kernel/entry.S | 1 +
 1 file changed, 1 insertion(+)
arch/riscv/kernel/entry.S +1 -0
index a03821b2656a..d9de22686e27 100644
@@ -449,6 +449,7 @@ ENDPROC(__fstate_restore)
 
 
 	.section ".rodata"
+	.align LGREG
 	/* Exception vector table */
 ENTRY(excp_vect_table)
 	RISCV_PTR do_trap_insn_misaligned
Signature · 1 line
2.30.2
author maintainer
#8 lore raw

PATCH 8/13 net: phy: broadcom: Only advertise EEE for supported modes

In reply to Greg Kroah-Hartman

From: Florian Fainelli <[email protected]>

commit c056d480b40a68f2520ccc156c7fae672d69d57d upstream

We should not be advertising EEE for modes that we do not support, correct that oversight by looking at the PHY device supported linkmodes.

Fixes 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
---
 drivers/net/phy/bcm-phy-lib.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/phy/bcm-phy-lib.c +8 -3
@@ -198,7 +198,7 @@ EXPORT_SYMBOL_GPL(bcm_phy_enable_apd);
 
 int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
 {
-	int val;
+	int val, mask = 0;
 
 	/* Enable EEE at PHY level */
 	val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
@@ -217,10 +217,15 @@ int bcm_phy_set_eee(struct phy_device *p
 	if (val < 0)
 		return val;
 
+	if (phydev->supported & SUPPORTED_1000baseT_Full)
+		mask |= MDIO_EEE_1000T;
+	if (phydev->supported & SUPPORTED_100baseT_Full)
+		mask |= MDIO_EEE_100TX;
+
 	if (enable)
-		val |= (MDIO_EEE_100TX | MDIO_EEE_1000T);
+		val |= mask;
 	else
-		val &= ~(MDIO_EEE_100TX | MDIO_EEE_1000T);
+		val &= ~mask;
 
 	phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
 
author maintainer
#9 lore raw

PATCH 9/13 staging: m57621-mmc: delete driver from the tree.

In reply to Greg Kroah-Hartman

From: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 441bf7332d55c4d34afae9ffc3bbec621093f4d1 ]

The license text in this driver is "interesting" and not really obvious that it is supposed to be able to be distributed in the kernel source tree. Yes, the MODULE_LICENSE() text says GPL, so it's probably ok, but to be safe, I am deleting this driver. I will be glad to add it back if the license is properly sorted out, but for now, this isn't worth the potential risk, I should have never taken it in the first place.

Cc Matthias Brugger <[email protected]>
Cc NeilBrown <[email protected]>
Cc George Hilliard <[email protected]>
Cc "Christian Lütke-Stetzkamp" <[email protected]>
Cc Nishad Kamdar <[email protected]>
Cc Sergej Perschin <[email protected]>
Cc John Crispin <[email protected]>
---
 drivers/staging/Kconfig                |    2 -
 drivers/staging/Makefile               |    1 -
 drivers/staging/mt7621-mmc/Kconfig     |   16 -
 drivers/staging/mt7621-mmc/Makefile    |   42 -
 drivers/staging/mt7621-mmc/TODO        |    8 -
 drivers/staging/mt7621-mmc/board.h     |   63 -
 drivers/staging/mt7621-mmc/dbg.c       |  307 ---
 drivers/staging/mt7621-mmc/dbg.h       |  149 --
 drivers/staging/mt7621-mmc/mt6575_sd.h |  488 -----
 drivers/staging/mt7621-mmc/sd.c        | 2392 ------------------------
 10 files changed, 3468 deletions(-)
 delete mode 100644 drivers/staging/mt7621-mmc/Kconfig
 delete mode 100644 drivers/staging/mt7621-mmc/Makefile
 delete mode 100644 drivers/staging/mt7621-mmc/TODO
 delete mode 100644 drivers/staging/mt7621-mmc/board.h
 delete mode 100644 drivers/staging/mt7621-mmc/dbg.c
 delete mode 100644 drivers/staging/mt7621-mmc/dbg.h
 delete mode 100644 drivers/staging/mt7621-mmc/mt6575_sd.h
 delete mode 100644 drivers/staging/mt7621-mmc/sd.c
drivers/staging/Kconfig +0 -2
index 1abf76be2aa8..58e8140c1f57 100644
@@ -114,8 +114,6 @@ source "drivers/staging/mt7621-spi/Kconfig"
 
 source "drivers/staging/mt7621-dma/Kconfig"
 
-source "drivers/staging/mt7621-mmc/Kconfig"
-
 source "drivers/staging/mt7621-eth/Kconfig"
 
 source "drivers/staging/mt7621-dts/Kconfig"
drivers/staging/Makefile +0 -1
index ab0cbe8815b1..6f3065569fa0 100644
@@ -47,7 +47,6 @@ obj-$(CONFIG_SOC_MT7621)	+= mt7621-pci/
 obj-$(CONFIG_SOC_MT7621)	+= mt7621-pinctrl/
 obj-$(CONFIG_SOC_MT7621)	+= mt7621-spi/
 obj-$(CONFIG_SOC_MT7621)	+= mt7621-dma/
-obj-$(CONFIG_SOC_MT7621)	+= mt7621-mmc/
 obj-$(CONFIG_SOC_MT7621)	+= mt7621-eth/
 obj-$(CONFIG_SOC_MT7621)	+= mt7621-dts/
 obj-$(CONFIG_STAGING_GASKET_FRAMEWORK)	+= gasket/
drivers/staging/mt7621-mmc/Kconfig deleted +0 -16
deleted file mode 100644
index c6dfe8c637dc..000000000000
@@ -1,16 +0,0 @@
-config MTK_MMC
-	tristate "MTK SD/MMC"
-	depends on !MTD_NAND_RALINK && MMC
-
-config MTK_AEE_KDUMP
-	bool "MTK AEE KDUMP"
-	depends on MTK_MMC
-
-config MTK_MMC_CD_POLL
-	bool "Card Detect with Polling"
-	depends on MTK_MMC
-
-config MTK_MMC_EMMC_8BIT
-	bool "eMMC 8-bit support"
-	depends on MTK_MMC && RALINK_MT7628
-
drivers/staging/mt7621-mmc/Makefile deleted +0 -42

42 lines not on this page · raw message

drivers/staging/mt7621-mmc/TODO deleted +0 -8
deleted file mode 100644
index febb32d37e07..000000000000
@@ -1,8 +0,0 @@
-
-- general code review and clean up
-- ensure device-tree requirements are documented
-- should probably be merged with drivers/mmc/host/mtk-sd.c
-- possibly fix to work with highmem pages so a bounce buffer isn't
-  needed.
-
-Cc: NeilBrown <[email protected]>
drivers/staging/mt7621-mmc/board.h deleted +0 -63

63 lines not on this page · raw message

drivers/staging/mt7621-mmc/dbg.c deleted +0 -307

307 lines not on this page · raw message

drivers/staging/mt7621-mmc/dbg.h deleted +0 -149

149 lines not on this page · raw message

drivers/staging/mt7621-mmc/mt6575_sd.h deleted +0 -488

488 lines not on this page · raw message

drivers/staging/mt7621-mmc/sd.c deleted +0 -2392

1,912 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.30.2

Part of the diff is not shown here. View the raw message.

author maintainer
#10 lore raw

PATCH 10/13 netfilter: x_tables: fix compat match/target pad out-of-bound write

In reply to Greg Kroah-Hartman

From: Florian Westphal <[email protected]>

commit b29c457a6511435960115c0f548c4360d5f4801d upstream.

xt_compat_match/target_from_user doesn't check that zeroing the area to start of next rule won't write past end of allocated ruleset blob.

Remove this code and zero the entire blob beforehand.

Reported-by [email protected]
Fixes 9fa492cdc160c ("[NETFILTER]: x_tables: simplify compat API")
---
 net/ipv4/netfilter/arp_tables.c |    2 ++
 net/ipv4/netfilter/ip_tables.c  |    2 ++
 net/ipv6/netfilter/ip6_tables.c |    2 ++
 net/netfilter/x_tables.c        |   10 ++--------
 4 files changed, 8 insertions(+), 8 deletions(-)
net/ipv4/netfilter/arp_tables.c +2 -0
@@ -1195,6 +1195,8 @@ static int translate_compat_table(struct
 	if (!newinfo)
 		goto out_unlock;
 
+	memset(newinfo->entries, 0, size);
+
 	newinfo->number = compatr->num_entries;
 	for (i = 0; i < NF_ARP_NUMHOOKS; i++) {
 		newinfo->hook_entry[i] = compatr->hook_entry[i];
net/ipv4/netfilter/ip_tables.c +2 -0
@@ -1433,6 +1433,8 @@ translate_compat_table(struct net *net,
 	if (!newinfo)
 		goto out_unlock;
 
+	memset(newinfo->entries, 0, size);
+
 	newinfo->number = compatr->num_entries;
 	for (i = 0; i < NF_INET_NUMHOOKS; i++) {
 		newinfo->hook_entry[i] = compatr->hook_entry[i];
net/ipv6/netfilter/ip6_tables.c +2 -0
@@ -1448,6 +1448,8 @@ translate_compat_table(struct net *net,
 	if (!newinfo)
 		goto out_unlock;
 
+	memset(newinfo->entries, 0, size);
+
 	newinfo->number = compatr->num_entries;
 	for (i = 0; i < NF_INET_NUMHOOKS; i++) {
 		newinfo->hook_entry[i] = compatr->hook_entry[i];
net/netfilter/x_tables.c +2 -8
@@ -738,7 +738,7 @@ void xt_compat_match_from_user(struct xt
 {
 	const struct xt_match *match = m->u.kernel.match;
 	struct compat_xt_entry_match *cm = (struct compat_xt_entry_match *)m;
-	int pad, off = xt_compat_match_offset(match);
+	int off = xt_compat_match_offset(match);
 	u_int16_t msize = cm->u.user.match_size;
 	char name[sizeof(m->u.user.name)];
 
@@ -748,9 +748,6 @@ void xt_compat_match_from_user(struct xt
 		match->compat_from_user(m->data, cm->data);
 	else
 		memcpy(m->data, cm->data, msize - sizeof(*cm));
-	pad = XT_ALIGN(match->matchsize) - match->matchsize;
-	if (pad > 0)
-		memset(m->data + match->matchsize, 0, pad);
 
 	msize += off;
 	m->u.user.match_size = msize;
@@ -1121,7 +1118,7 @@ void xt_compat_target_from_user(struct x
 {
 	const struct xt_target *target = t->u.kernel.target;
 	struct compat_xt_entry_target *ct = (struct compat_xt_entry_target *)t;
-	int pad, off = xt_compat_target_offset(target);
+	int off = xt_compat_target_offset(target);
 	u_int16_t tsize = ct->u.user.target_size;
 	char name[sizeof(t->u.user.name)];
 
@@ -1131,9 +1128,6 @@ void xt_compat_target_from_user(struct x
 		target->compat_from_user(t->data, ct->data);
 	else
 		memcpy(t->data, ct->data, tsize - sizeof(*ct));
-	pad = XT_ALIGN(target->targetsize) - target->targetsize;
-	if (pad > 0)
-		memset(t->data + target->targetsize, 0, pad);
 
 	tsize += off;
 	t->u.user.target_size = tsize;
author maintainer
#11 lore raw

PATCH 11/13 driver core: Fix locking bug in deferred_probe_timeout_work_func()

In reply to Greg Kroah-Hartman

From: Saravana Kannan <[email protected]>

commit eed6e41813deb9ee622cd9242341f21430d7789f upstream.

list_for_each_entry_safe() is only useful if we are deleting nodes in a linked list within the loop. It doesn't protect against other threads adding/deleting nodes to the list in parallel. We need to grab deferred_probe_mutex when traversing the deferred_probe_pending_list.

Fixes 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
---
 drivers/base/dd.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/base/dd.c +5 -3
@@ -254,14 +254,16 @@ int driver_deferred_probe_check_state(st
 
 static void deferred_probe_timeout_work_func(struct work_struct *work)
 {
-	struct device_private *private, *p;
+	struct device_private *p;
 
 	deferred_probe_timeout = 0;
 	driver_deferred_probe_trigger();
 	flush_work(&deferred_probe_work);
 
-	list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
-		dev_info(private->device, "deferred probe pending");
+	mutex_lock(&deferred_probe_mutex);
+	list_for_each_entry(p, &deferred_probe_pending_list, deferred_probe)
+		dev_info(p->device, "deferred probe pending\n");
+	mutex_unlock(&deferred_probe_mutex);
 }
 static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
 
author maintainer
#12 lore raw

PATCH 12/13 perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches

In reply to Greg Kroah-Hartman

From: Arnaldo Carvalho de Melo <[email protected]>

commit 77d02bd00cea9f1a87afe58113fa75b983d6c23a upstream.

Noticed on a debian:experimental mips and mipsel cross build build environment:

  perfbuilder@ec265a086e9b:~$ mips-linux-gnu-gcc --version | head -1
  mips-linux-gnu-gcc (Debian 10.2.1-3) 10.2.1 20201224
  perfbuilder@ec265a086e9b:~$

CC /tmp/build/perf/util/map.o
util/map.c: In function 'map__new':
util/map.c:109:5: error: '%s' directive output may be truncated writing between 1 and 2147483645 bytes into a region of size 4096 [-Werror=format-truncation=]

    109 |    "%s/platforms/%s/arch-%s/usr/lib/%s",
        |     ^~
  In file included from /usr/mips-linux-gnu/include/stdio.h:867,
                   from util/symbol.h:11,
                   from util/map.c:2:
  /usr/mips-linux-gnu/include/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output 32 or more bytes (assuming 4294967321) into a destination of size 4096
     67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     68 |        __bos (__s), __fmt, __va_arg_pack ());
        |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cc1: all warnings being treated as errors

Since we have the lenghts for what lands in that place, use it to give the compiler more info and make it happy.

---
 tools/perf/util/map.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
tools/perf/util/map.c +3 -4
@@ -88,8 +88,7 @@ static inline bool replace_android_lib(c
 	if (!strncmp(filename, "/system/lib/", 12)) {
 		char *ndk, *app;
 		const char *arch;
-		size_t ndk_length;
-		size_t app_length;
+		int ndk_length, app_length;
 
 		ndk = getenv("NDK_ROOT");
 		app = getenv("APP_PLATFORM");
@@ -117,8 +116,8 @@ static inline bool replace_android_lib(c
 		if (new_length > PATH_MAX)
 			return false;
 		snprintf(newfilename, new_length,
-			"%s/platforms/%s/arch-%s/usr/lib/%s",
-			ndk, app, arch, libname);
+			"%.*s/platforms/%.*s/arch-%s/usr/lib/%s",
+			ndk_length, ndk, app_length, app, arch, libname);
 
 		return true;
 	}
author maintainer
#13 lore raw

PATCH 13/13 xen/events: fix setting irq affinity

In reply to Greg Kroah-Hartman

From: Juergen Gross <[email protected]>

The backport of upstream patch 25da4618af240fbec61 ("xen/events: don't unmask an event channel when an eoi is pending") introduced a regression for stable kernels 5.10 and older: setting IRQ affinity for IRQs related to interdomain events would no longer work, as moving the IRQ to its new cpu was not included in the irq_ack callback for those events.

Fix that by adding the needed call.

Note that kernels 5.11 and later don't need the explicit moving of the IRQ to the target cpu in the irq_ack callback, due to a rework of the affinity setting in kernel 5.11.

---
 drivers/xen/events/events_base.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/xen/events/events_base.c +2 -2
@@ -1782,7 +1782,7 @@ static void lateeoi_ack_dynirq(struct ir
 
 	if (VALID_EVTCHN(evtchn)) {
 		do_mask(info, EVT_MASK_REASON_EOI_PENDING);
-		event_handler_exit(info);
+		ack_dynirq(data);
 	}
 }
 
@@ -1793,7 +1793,7 @@ static void lateeoi_mask_ack_dynirq(stru
 
 	if (VALID_EVTCHN(evtchn)) {
 		do_mask(info, EVT_MASK_REASON_EXPLICIT);
-		event_handler_exit(info);
+		ack_dynirq(data);
 	}
 }
 
Tested-by on the v1 series
#14 lore raw
In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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.

CIP testing did not find any kernel problems here: (some boards are unavailable)

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y

Best regards,
Pavel

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Tested-by on the v1 series
#15 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.188-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

maintainer Tested-by on the v1 series
#16 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.188-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v4.19:

    12 builds:	12 pass, 0 fail
    22 boots:	22 pass, 0 fail
    40 tests:	40 pass, 0 fail

Linux version: 4.19.188-rc1-g9f5de887b160
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra194-p2972-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra30-cardhu-a04

Jon

Tested-by Linux Kernel Functional Testing on the v1 series
#17 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.188-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-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.

## Build
* kernel: 4.19.188-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.19.y
* git commit: 9f5de887b160253cf03d6ae91e72ba7dbd4a2317
* git describe: v4.19.187-14-g9f5de887b160
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.187-14-g9f5de887b160

## No regressions (compared to v4.19.187)

## No fixes (compared to v4.19.187)

## Test result summary
total: 71166, pass: 57695, fail: 1809, skip: 11392, xfail: 270,

## Build Summary
* arm: 97 total, 96 passed, 1 failed
* arm64: 25 total, 24 passed, 1 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 14 total, 13 passed, 1 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 39 total, 39 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 15 total, 14 passed, 1 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-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-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

Tested-by Hulk Robot on the v1 series
#18 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.188-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

Tested on arm64 and x86 for 4.19.188-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.188-rc1
Commit: 9f5de887b160253cf03d6ae91e72ba7dbd4a2317
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 5723
passed: 5723
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 5723
passed: 5723
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by on the v1 series
#19 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.188 release. There are 13 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 Sat, 17 Apr 2021 14:44:01 +0000. Anything received after that time might be too late.

Build test:
mips (gcc version 10.3.1 20210416): 63 configs -> no new failure arm (gcc version 10.3.1 20210416): 116 configs -> no new failure x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression.
arm: Booted on rpi3b. No regression.

--
Regards
Sudip