Skip to contentSkip to conversation

4.0.2-stable review

PATCH In review Greg Kroah-Hartman 4 participants 228 messages May 2, 2015 – May 6, 2015 Page 2 of 2

Subsystems (3)
lore
Share & tools
lore
author maintainer
#154 lore raw

PATCH 160/220 xtensa: ISS: fix locking in TAP network adapter

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Max Filippov <[email protected]>

commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d upstream.

- don't lock lp->lock in the iss_net_timer for the call of iss_net_poll, it will lock it itself;
- invert order of lp->lock and opened_lock acquisition in the iss_net_open to make it consistent with iss_net_poll;
- replace spin_lock with spin_lock_bh when acquiring locks used in iss_net_timer from non-atomic context;
- replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit as the driver doesn't use lp->lock in the hard IRQ context;
- replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise lockdep is unhappy about using non-static key.

---
 arch/xtensa/platforms/iss/network.c |   29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)
arch/xtensa/platforms/iss/network.c +15 -14
@@ -349,8 +349,8 @@ static void iss_net_timer(unsigned long
 {
 	struct iss_net_private *lp = (struct iss_net_private *)priv;
 
-	spin_lock(&lp->lock);
 	iss_net_poll();
+	spin_lock(&lp->lock);
 	mod_timer(&lp->timer, jiffies + lp->timer_val);
 	spin_unlock(&lp->lock);
 }
@@ -361,7 +361,7 @@ static int iss_net_open(struct net_devic
 	struct iss_net_private *lp = netdev_priv(dev);
 	int err;
 
-	spin_lock(&lp->lock);
+	spin_lock_bh(&lp->lock);
 
 	err = lp->tp.open(lp);
 	if (err < 0)
@@ -376,9 +376,11 @@ static int iss_net_open(struct net_devic
 	while ((err = iss_net_rx(dev)) > 0)
 		;
 
-	spin_lock(&opened_lock);
+	spin_unlock_bh(&lp->lock);
+	spin_lock_bh(&opened_lock);
 	list_add(&lp->opened_list, &opened);
-	spin_unlock(&opened_lock);
+	spin_unlock_bh(&opened_lock);
+	spin_lock_bh(&lp->lock);
 
 	init_timer(&lp->timer);
 	lp->timer_val = ISS_NET_TIMER_VALUE;
@@ -387,7 +389,7 @@ static int iss_net_open(struct net_devic
 	mod_timer(&lp->timer, jiffies + lp->timer_val);
 
 out:
-	spin_unlock(&lp->lock);
+	spin_unlock_bh(&lp->lock);
 	return err;
 }
 
@@ -395,7 +397,7 @@ static int iss_net_close(struct net_devi
 {
 	struct iss_net_private *lp = netdev_priv(dev);
 	netif_stop_queue(dev);
-	spin_lock(&lp->lock);
+	spin_lock_bh(&lp->lock);
 
 	spin_lock(&opened_lock);
 	list_del(&opened);
@@ -405,18 +407,17 @@ static int iss_net_close(struct net_devi
 
 	lp->tp.close(lp);
 
-	spin_unlock(&lp->lock);
+	spin_unlock_bh(&lp->lock);
 	return 0;
 }
 
 static int iss_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct iss_net_private *lp = netdev_priv(dev);
-	unsigned long flags;
 	int len;
 
 	netif_stop_queue(dev);
-	spin_lock_irqsave(&lp->lock, flags);
+	spin_lock_bh(&lp->lock);
 
 	len = lp->tp.write(lp, &skb);
 
@@ -438,7 +439,7 @@ static int iss_net_start_xmit(struct sk_
 		pr_err("%s: %s failed(%d)\n", dev->name, __func__, len);
 	}
 
-	spin_unlock_irqrestore(&lp->lock, flags);
+	spin_unlock_bh(&lp->lock);
 
 	dev_kfree_skb(skb);
 	return NETDEV_TX_OK;
@@ -466,9 +467,9 @@ static int iss_net_set_mac(struct net_de
 
 	if (!is_valid_ether_addr(hwaddr->sa_data))
 		return -EADDRNOTAVAIL;
-	spin_lock(&lp->lock);
+	spin_lock_bh(&lp->lock);
 	memcpy(dev->dev_addr, hwaddr->sa_data, ETH_ALEN);
-	spin_unlock(&lp->lock);
+	spin_unlock_bh(&lp->lock);
 	return 0;
 }
 
@@ -520,11 +521,11 @@ static int iss_net_configure(int index,
 	*lp = (struct iss_net_private) {
 		.device_list		= LIST_HEAD_INIT(lp->device_list),
 		.opened_list		= LIST_HEAD_INIT(lp->opened_list),
-		.lock			= __SPIN_LOCK_UNLOCKED(lp.lock),
 		.dev			= dev,
 		.index			= index,
-		};
+	};
 
+	spin_lock_init(&lp->lock);
 	/*
 	 * If this name ends up conflicting with an existing registered
 	 * netdevice, that is OK, register_netdev{,ice}() will notice this
author maintainer
#155 lore raw

PATCH 161/220 gpio: mvebu: Fix mask/unmask managment per irq chip type

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Gregory CLEMENT <[email protected]>

commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream.

Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario:

First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm.

The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue.

It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario.

This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov:
9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012

---
 drivers/gpio/gpio-mvebu.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/gpio/gpio-mvebu.c +16 -8
@@ -320,11 +320,13 @@ static void mvebu_gpio_edge_irq_mask(str
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
 	struct mvebu_gpio_chip *mvchip = gc->private;
+	struct irq_chip_type *ct = irq_data_get_chip_type(d);
 	u32 mask = 1 << (d->irq - gc->irq_base);
 
 	irq_gc_lock(gc);
-	gc->mask_cache &= ~mask;
-	writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+	ct->mask_cache_priv &= ~mask;
+
+	writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
 	irq_gc_unlock(gc);
 }
 
@@ -332,11 +334,13 @@ static void mvebu_gpio_edge_irq_unmask(s
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
 	struct mvebu_gpio_chip *mvchip = gc->private;
+	struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
 	u32 mask = 1 << (d->irq - gc->irq_base);
 
 	irq_gc_lock(gc);
-	gc->mask_cache |= mask;
-	writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+	ct->mask_cache_priv |= mask;
+	writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
 	irq_gc_unlock(gc);
 }
 
@@ -344,11 +348,13 @@ static void mvebu_gpio_level_irq_mask(st
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
 	struct mvebu_gpio_chip *mvchip = gc->private;
+	struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
 	u32 mask = 1 << (d->irq - gc->irq_base);
 
 	irq_gc_lock(gc);
-	gc->mask_cache &= ~mask;
-	writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+	ct->mask_cache_priv &= ~mask;
+	writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
 	irq_gc_unlock(gc);
 }
 
@@ -356,11 +362,13 @@ static void mvebu_gpio_level_irq_unmask(
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
 	struct mvebu_gpio_chip *mvchip = gc->private;
+	struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
 	u32 mask = 1 << (d->irq - gc->irq_base);
 
 	irq_gc_lock(gc);
-	gc->mask_cache |= mask;
-	writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+	ct->mask_cache_priv |= mask;
+	writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
 	irq_gc_unlock(gc);
 }
 
author maintainer
#156 lore raw

PATCH 162/220 clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Bartlomiej Zolnierkiewicz <[email protected]>

commit 3a9e9cb65be84d6c64fbe9c69a73c15d59f29454 upstream.

Commit 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature") enabled ARMCLK down feature on all Exynos4 SoCs. Unfortunately on Exynos4210 SoC ARMCLK down feature causes a lockup when ondemand cpufreq governor is used. Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs.

This patch was tested on:
- Exynos4210 SoC based Trats board
- Exynos4210 SoC based Origen board
- Exynos4412 SoC based Trats2 board
- Exynos4412 SoC based Odroid-U3 board

Cc Daniel Drake <[email protected]>
Cc Tomasz Figa <[email protected]>
Cc Kukjin Kim <[email protected]>
Fixes 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature")
---
 drivers/clk/samsung/clk-exynos4.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/clk/samsung/clk-exynos4.c +5 -6
@@ -1354,7 +1354,7 @@ static struct samsung_pll_clock exynos4x
 			VPLL_LOCK, VPLL_CON0, NULL),
 };
 
-static void __init exynos4_core_down_clock(enum exynos4_soc soc)
+static void __init exynos4x12_core_down_clock(void)
 {
 	unsigned int tmp;
 
@@ -1373,11 +1373,9 @@ static void __init exynos4_core_down_clo
 	__raw_writel(tmp, reg_base + PWR_CTRL1);
 
 	/*
-	 * Disable the clock up feature on Exynos4x12, in case it was
-	 * enabled by bootloader.
+	 * Disable the clock up feature in case it was enabled by bootloader.
 	 */
-	if (exynos4_soc == EXYNOS4X12)
-		__raw_writel(0x0, reg_base + E4X12_PWR_CTRL2);
+	__raw_writel(0x0, reg_base + E4X12_PWR_CTRL2);
 }
 
 /* register exynos4 clocks */
@@ -1474,7 +1472,8 @@ static void __init exynos4_clk_init(stru
 	samsung_clk_register_alias(ctx, exynos4_aliases,
 			ARRAY_SIZE(exynos4_aliases));
 
-	exynos4_core_down_clock(soc);
+	if (soc == EXYNOS4X12)
+		exynos4x12_core_down_clock();
 	exynos4_clk_sleep_init();
 
 	samsung_clk_of_add_provider(np, ctx);
author maintainer
#157 lore raw

PATCH 163/220 clk: tegra: Register the proper number of resets

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Thierry Reding <[email protected]>

commit 5e43e259171e1eee8bc074d9c44be434e685087b upstream.

The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32).

This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array.

Cc Peter De Schrijver <[email protected]>
Cc Prashant Gaikwad <[email protected]>
Fixes 6d5b988e7dc5 ("clk: tegra: implement a reset driver")
---
 drivers/clk/tegra/clk.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/tegra/clk.c +1 -1
@@ -272,7 +272,7 @@ void __init tegra_add_of_provider(struct
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
 	rst_ctlr.of_node = np;
-	rst_ctlr.nr_resets = clk_num * 32;
+	rst_ctlr.nr_resets = periph_banks * 32;
 	reset_controller_register(&rst_ctlr);
 }
 
author maintainer
#158 lore raw

PATCH 164/220 clk: tegra: Use the proper parent for plld_dsi

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Thierry Reding <[email protected]>

commit c1d676cec572544616273d5853cb7cc38fbaa62b upstream.

The current parent, plld_out0, does not exist. The proper name is pll_d_out0. While at it, rename the plld_dsi clock to pll_d_dsi_out to be more consistent with other clock names.

Fixes b270491eb9a0 ("clk: tegra: Define PLLD_DSI and remove dsia(b)_mux")
---
 drivers/clk/tegra/clk-tegra124.c                |   14 ++++++++------
 include/dt-bindings/clock/tegra124-car-common.h |    2 +-
 2 files changed, 9 insertions(+), 7 deletions(-)
drivers/clk/tegra/clk-tegra124.c +8 -6
@@ -1110,16 +1110,18 @@ static __init void tegra124_periph_clk_i
 					1, 2);
 	clks[TEGRA124_CLK_XUSB_SS_DIV2] = clk;
 
-	clk = clk_register_gate(NULL, "plld_dsi", "plld_out0", 0,
+	clk = clk_register_gate(NULL, "pll_d_dsi_out", "pll_d_out0", 0,
 				clk_base + PLLD_MISC, 30, 0, &pll_d_lock);
-	clks[TEGRA124_CLK_PLLD_DSI] = clk;
+	clks[TEGRA124_CLK_PLL_D_DSI_OUT] = clk;
 
-	clk = tegra_clk_register_periph_gate("dsia", "plld_dsi", 0, clk_base,
-					     0, 48, periph_clk_enb_refcnt);
+	clk = tegra_clk_register_periph_gate("dsia", "pll_d_dsi_out", 0,
+					     clk_base, 0, 48,
+					     periph_clk_enb_refcnt);
 	clks[TEGRA124_CLK_DSIA] = clk;
 
-	clk = tegra_clk_register_periph_gate("dsib", "plld_dsi", 0, clk_base,
-					     0, 82, periph_clk_enb_refcnt);
+	clk = tegra_clk_register_periph_gate("dsib", "pll_d_dsi_out", 0,
+					     clk_base, 0, 82,
+					     periph_clk_enb_refcnt);
 	clks[TEGRA124_CLK_DSIB] = clk;
 
 	/* emc mux */
include/dt-bindings/clock/tegra124-car-common.h +1 -1
@@ -297,7 +297,7 @@
 #define TEGRA124_CLK_PLL_C4 270
 #define TEGRA124_CLK_PLL_DP 271
 #define TEGRA124_CLK_PLL_E_MUX 272
-#define TEGRA124_CLK_PLLD_DSI 273
+#define TEGRA124_CLK_PLL_D_DSI_OUT 273
 /* 274 */
 /* 275 */
 /* 276 */
author maintainer
#159 lore raw

PATCH 165/220 clk: qcom: Fix i2c frequency table

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Stephen Boyd <[email protected]>

commit 0bf0ff82c34da02ee5795101b328225a2d519594 upstream.

PXO is 25MHz, not 27MHz. Fix the table.

Fixes 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global

clock controller (GCC)"

---
 drivers/clk/qcom/gcc-ipq806x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/gcc-ipq806x.c +1 -1
@@ -525,8 +525,8 @@ static struct freq_tbl clk_tbl_gsbi_qup[
 	{ 10800000, P_PXO,  1, 2,  5 },
 	{ 15060000, P_PLL8, 1, 2, 51 },
 	{ 24000000, P_PLL8, 4, 1,  4 },
+	{ 25000000, P_PXO,  1, 0,  0 },
 	{ 25600000, P_PLL8, 1, 1, 15 },
-	{ 27000000, P_PXO,  1, 0,  0 },
 	{ 48000000, P_PLL8, 4, 1,  2 },
 	{ 51200000, P_PLL8, 1, 2, 15 },
 	{ }
author maintainer
#160 lore raw

PATCH 166/220 clk: qcom: Properly change rates for ahbix clock

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Stephen Boyd <[email protected]>

commit 9d3745d44a7faa7d24db7facb1949a1378162f3e upstream.

The ahbix clock can never be turned off in practice. To change the rates we need to switch the mux off the M/N counter to an always on source (XO), reprogram the M/N counter to get the rate we want and finally switch back to the M/N counter. Add a new ops structure for this type of clock so that we can set the rate properly.

Fixes c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver"
---
 drivers/clk/qcom/clk-rcg.c     |   62 +++++++++++++++++++++++++++++++++++++++++
 drivers/clk/qcom/clk-rcg.h     |    1 
 drivers/clk/qcom/lcc-ipq806x.c |    5 +--
 3 files changed, 65 insertions(+), 3 deletions(-)
drivers/clk/qcom/clk-rcg.c +62 -0
@@ -495,6 +495,57 @@ static int clk_rcg_bypass_set_rate(struc
 	return __clk_rcg_set_rate(rcg, rcg->freq_tbl);
 }
 
+/*
+ * This type of clock has a glitch-free mux that switches between the output of
+ * the M/N counter and an always on clock source (XO). When clk_set_rate() is
+ * called we need to make sure that we don't switch to the M/N counter if it
+ * isn't clocking because the mux will get stuck and the clock will stop
+ * outputting a clock. This can happen if the framework isn't aware that this
+ * clock is on and so clk_set_rate() doesn't turn on the new parent. To fix
+ * this we switch the mux in the enable/disable ops and reprogram the M/N
+ * counter in the set_rate op. We also make sure to switch away from the M/N
+ * counter in set_rate if software thinks the clock is off.
+ */
+static int clk_rcg_lcc_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	const struct freq_tbl *f;
+	int ret;
+	u32 gfm = BIT(10);
+
+	f = qcom_find_freq(rcg->freq_tbl, rate);
+	if (!f)
+		return -EINVAL;
+
+	/* Switch to XO to avoid glitches */
+	regmap_update_bits(rcg->clkr.regmap, rcg->ns_reg, gfm, 0);
+	ret = __clk_rcg_set_rate(rcg, f);
+	/* Switch back to M/N if it's clocking */
+	if (__clk_is_enabled(hw->clk))
+		regmap_update_bits(rcg->clkr.regmap, rcg->ns_reg, gfm, gfm);
+
+	return ret;
+}
+
+static int clk_rcg_lcc_enable(struct clk_hw *hw)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	u32 gfm = BIT(10);
+
+	/* Use M/N */
+	return regmap_update_bits(rcg->clkr.regmap, rcg->ns_reg, gfm, gfm);
+}
+
+static void clk_rcg_lcc_disable(struct clk_hw *hw)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	u32 gfm = BIT(10);
+
+	/* Use XO */
+	regmap_update_bits(rcg->clkr.regmap, rcg->ns_reg, gfm, 0);
+}
+
 static int __clk_dyn_rcg_set_rate(struct clk_hw *hw, unsigned long rate)
 {
 	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
@@ -543,6 +594,17 @@ const struct clk_ops clk_rcg_bypass_ops
 };
 EXPORT_SYMBOL_GPL(clk_rcg_bypass_ops);
 
+const struct clk_ops clk_rcg_lcc_ops = {
+	.enable = clk_rcg_lcc_enable,
+	.disable = clk_rcg_lcc_disable,
+	.get_parent = clk_rcg_get_parent,
+	.set_parent = clk_rcg_set_parent,
+	.recalc_rate = clk_rcg_recalc_rate,
+	.determine_rate = clk_rcg_determine_rate,
+	.set_rate = clk_rcg_lcc_set_rate,
+};
+EXPORT_SYMBOL_GPL(clk_rcg_lcc_ops);
+
 const struct clk_ops clk_dyn_rcg_ops = {
 	.enable = clk_enable_regmap,
 	.is_enabled = clk_is_enabled_regmap,
drivers/clk/qcom/clk-rcg.h +1 -0
@@ -96,6 +96,7 @@ struct clk_rcg {
 
 extern const struct clk_ops clk_rcg_ops;
 extern const struct clk_ops clk_rcg_bypass_ops;
+extern const struct clk_ops clk_rcg_lcc_ops;
 
 #define to_clk_rcg(_hw) container_of(to_clk_regmap(_hw), struct clk_rcg, clkr)
 
drivers/clk/qcom/lcc-ipq806x.c +2 -3
@@ -386,13 +386,12 @@ static struct clk_rcg ahbix_clk = {
 	.freq_tbl = clk_tbl_ahbix,
 	.clkr = {
 		.enable_reg = 0x38,
-		.enable_mask = BIT(10), /* toggle the gfmux to select mn/pxo */
+		.enable_mask = BIT(11),
 		.hw.init = &(struct clk_init_data){
 			.name = "ahbix",
 			.parent_names = lcc_pxo_pll4,
 			.num_parents = 2,
-			.ops = &clk_rcg_ops,
-			.flags = CLK_SET_RATE_GATE,
+			.ops = &clk_rcg_lcc_ops,
 		},
 	},
 };
author maintainer
#161 lore raw

PATCH 167/220 clk: qcom: fix RCG M/N counter configuration

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Archit Taneja <[email protected]>

commit 0b21503dbbfa669dbd847b33578d4041513cddb2 upstream.

Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N.

In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1.

Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division.

Fixes bcd61c0f535a (clk: qcom: Add support for root clock

generators (RCGs))

---
 drivers/clk/qcom/clk-rcg2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/clk-rcg2.c +1 -1
@@ -243,7 +243,7 @@ static int clk_rcg2_configure(struct clk
 	mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK;
 	cfg = f->pre_div << CFG_SRC_DIV_SHIFT;
 	cfg |= rcg->parent_map[f->src] << CFG_SRC_SEL_SHIFT;
-	if (rcg->mnd_width && f->n)
+	if (rcg->mnd_width && f->n && (f->m != f->n))
 		cfg |= CFG_MODE_DUAL_EDGE;
 	ret = regmap_update_bits(rcg->clkr.regmap,
 			rcg->cmd_rcgr + CFG_REG, mask, cfg);
author maintainer
#162 lore raw

PATCH 168/220 clk: qcom: Fix ipq806x LCC frequency tables

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Stephen Boyd <[email protected]>

commit b3261d768bcdd4b368179ed85becf38c95461848 upstream.

These frequency tables list the wrong rates. Either they don't have the correct frequency at all, or they're specified in kHz instead of Hz. Fix it.

Fixes c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver"
---
 drivers/clk/qcom/lcc-ipq806x.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/clk/qcom/lcc-ipq806x.c +9 -9
@@ -294,14 +294,14 @@ static struct clk_regmap_mux pcm_clk = {
 };
 
 static struct freq_tbl clk_tbl_aif_osr[] = {
-	{  22050, P_PLL4, 1, 147, 20480 },
-	{  32000, P_PLL4, 1,   1,    96 },
-	{  44100, P_PLL4, 1, 147, 10240 },
-	{  48000, P_PLL4, 1,   1,    64 },
-	{  88200, P_PLL4, 1, 147,  5120 },
-	{  96000, P_PLL4, 1,   1,    32 },
-	{ 176400, P_PLL4, 1, 147,  2560 },
-	{ 192000, P_PLL4, 1,   1,    16 },
+	{  2822400, P_PLL4, 1, 147, 20480 },
+	{  4096000, P_PLL4, 1,   1,    96 },
+	{  5644800, P_PLL4, 1, 147, 10240 },
+	{  6144000, P_PLL4, 1,   1,    64 },
+	{ 11289600, P_PLL4, 1, 147,  5120 },
+	{ 12288000, P_PLL4, 1,   1,    32 },
+	{ 22579200, P_PLL4, 1, 147,  2560 },
+	{ 24576000, P_PLL4, 1,   1,    16 },
 	{ },
 };
 
@@ -360,7 +360,7 @@ static struct clk_branch spdif_clk = {
 };
 
 static struct freq_tbl clk_tbl_ahbix[] = {
-	{ 131072, P_PLL4, 1, 1, 3 },
+	{ 131072000, P_PLL4, 1, 1, 3 },
 	{ },
 };
 
author maintainer
#163 lore raw

PATCH 169/220 dm crypt: fix deadlock when async crypto algorithm returns -EBUSY

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Ben Collins <[email protected]>

commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.

I suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return -EBUSY on occasion under heavy -- which resulted in dm-crypt deadlock.

After checking the logic in some other drivers, the scheme for crypt_convert() and it's callback, kcryptd_async_done(), were not correctly laid out to properly handle -EBUSY or -EINPROGRESS.

Fix this by using the completion for both -EBUSY and -EINPROGRESS. Now crypt_convert()'s use of completion is comparable to af_alg_wait_for_completion(). Similarly, kcryptd_async_done() follows the pattern used in af_alg_complete().

Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and x86_64, and things seem perfectly happy there as well.

---
 drivers/md/dm-crypt.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +6 -6
@@ -925,11 +925,10 @@ static int crypt_convert(struct crypt_co
 
 		switch (r) {
 		/* async */
+		case -EINPROGRESS:
 		case -EBUSY:
 			wait_for_completion(&ctx->restart);
 			reinit_completion(&ctx->restart);
-			/* fall through*/
-		case -EINPROGRESS:
 			ctx->req = NULL;
 			ctx->cc_sector++;
 			continue;
@@ -1346,10 +1345,8 @@ static void kcryptd_async_done(struct cr
 	struct dm_crypt_io *io = container_of(ctx, struct dm_crypt_io, ctx);
 	struct crypt_config *cc = io->cc;
 
-	if (error == -EINPROGRESS) {
-		complete(&ctx->restart);
+	if (error == -EINPROGRESS)
 		return;
-	}
 
 	if (!error && cc->iv_gen_ops && cc->iv_gen_ops->post)
 		error = cc->iv_gen_ops->post(cc, iv_of_dmreq(cc, dmreq), dmreq);
@@ -1360,12 +1357,15 @@ static void kcryptd_async_done(struct cr
 	crypt_free_req(cc, req_of_dmreq(cc, dmreq), io->base_bio);
 
 	if (!atomic_dec_and_test(&ctx->cc_pending))
-		return;
+		goto done;
 
 	if (bio_data_dir(io->base_bio) == READ)
 		kcryptd_crypt_read_done(io);
 	else
 		kcryptd_crypt_write_io_submit(io, 1);
+done:
+	if (!completion_done(&ctx->restart))
+		complete(&ctx->restart);
 }
 
 static void kcryptd_crypt(struct work_struct *work)
author maintainer
#164 lore raw

PATCH 170/220 serial: 8250_dw: add support for AMD SOC Carrizo

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Ken Xue <[email protected]>

commit 5ef86b74209db33c133b5f18738dd8f3189b63a1 upstream.

Add ACPI identifier for UART on AMD SOC Carrizo.

---
 drivers/tty/serial/8250/8250_dw.c |    1 +
 1 file changed, 1 insertion(+)
drivers/tty/serial/8250/8250_dw.c +1 -0
@@ -629,6 +629,7 @@ static const struct acpi_device_id dw825
 	{ "80860F0A", 0 },
 	{ "8086228A", 0 },
 	{ "APMC0D08", 0},
+	{ "AMD0020", 0 },
 	{ },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
author maintainer
#165 lore raw

PATCH 172/220 serial: 8250: Check UART_SCR is writable

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Hurley <[email protected]>

commit f01a0bd8921b9d6668d41fae3198970e6318f532 upstream.

Au1x00/RT2800+ doesn't implement the 8250 scratch register (and this may be true of other h/w currently supported by the 8250 driver); read back the canary value written to the scratch register to enable the console h/w restart after resume from system suspend.

Fixes 4516d50aabedb ("serial: 8250: Use canary to restart console ...")
---
 drivers/tty/serial/8250/8250_core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_core.c +2 -1
@@ -3444,7 +3444,8 @@ void serial8250_suspend_port(int line)
 	    port->type != PORT_8250) {
 		unsigned char canary = 0xa5;
 		serial_out(up, UART_SCR, canary);
-		up->canary = canary;
+		if (serial_in(up, UART_SCR) == canary)
+			up->canary = canary;
 	}
 
 	uart_suspend_port(&serial8250_reg, port);
author maintainer
#166 lore raw

PATCH 173/220 sd: Unregister integrity profile

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "Martin K. Petersen" <[email protected]>

commit e727c42bd55794765c460b7ac2b6cc969f2a9698 upstream.

The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk.

---
 drivers/scsi/sd.c |    1 +
 1 file changed, 1 insertion(+)
drivers/scsi/sd.c +1 -0
@@ -3100,6 +3100,7 @@ static void scsi_disk_release(struct dev
 	ida_remove(&sd_index_ida, sdkp->index);
 	spin_unlock(&sd_index_lock);
 
+	blk_integrity_unregister(disk);
 	disk->private_data = NULL;
 	put_disk(disk);
 	put_device(&sdkp->device->sdev_gendev);
author maintainer
#167 lore raw

PATCH 174/220 sd: Fix missing ATO tag check

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "Martin K. Petersen" <[email protected]>

commit e557990e358934fb168d30371c9c0f63e314c6b8 upstream.

3aec2f41a8bae introduced a merge error where we would end up check for sdkp instead of sdkp->ATO. Fix this so we register app tag capability correctly.

---
 drivers/scsi/sd_dif.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/sd_dif.c +1 -1
@@ -77,7 +77,7 @@ void sd_dif_config_host(struct scsi_disk
 
 		disk->integrity->flags |= BLK_INTEGRITY_DEVICE_CAPABLE;
 
-		if (!sdkp)
+		if (!sdkp->ATO)
 			return;
 
 		if (type == SD_DIF_TYPE3_PROTECTION)
author maintainer
#168 lore raw

PATCH 175/220 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "K. Y. Srinivasan" <[email protected]>

commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream.

Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host.

---
 drivers/hv/channel.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/hv/channel.c +5 -2
@@ -135,7 +135,7 @@ int vmbus_open(struct vmbus_channel *new
 			   GFP_KERNEL);
 	if (!open_info) {
 		err = -ENOMEM;
-		goto error0;
+		goto error_gpadl;
 	}
 
 	init_completion(&open_info->waitevent);
@@ -151,7 +151,7 @@ int vmbus_open(struct vmbus_channel *new
 
 	if (userdatalen > MAX_USER_DEFINED_BYTES) {
 		err = -EINVAL;
-		goto error0;
+		goto error_gpadl;
 	}
 
 	if (userdatalen)
@@ -195,6 +195,9 @@ error1:
 	list_del(&open_info->msglistentry);
 	spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
 
+error_gpadl:
+	vmbus_teardown_gpadl(newchannel, newchannel->ringbuffer_gpadlhandle);
+
 error0:
 	free_pages((unsigned long)out,
 		get_order(send_ringbuffer_size + recv_ringbuffer_size));
author maintainer
#169 lore raw

PATCH 176/220 mvsas: fix panic on expander attached SATA devices

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: James Bottomley <[email protected]>

commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream.

mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer.

mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic.

---
 drivers/scsi/mvsas/mv_sas.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/scsi/mvsas/mv_sas.c +1 -4
@@ -441,14 +441,11 @@ static u32 mvs_get_ncq_tag(struct sas_ta
 static int mvs_task_prep_ata(struct mvs_info *mvi,
 			     struct mvs_task_exec_info *tei)
 {
-	struct sas_ha_struct *sha = mvi->sas;
 	struct sas_task *task = tei->task;
 	struct domain_device *dev = task->dev;
 	struct mvs_device *mvi_dev = dev->lldd_dev;
 	struct mvs_cmd_hdr *hdr = tei->hdr;
 	struct asd_sas_port *sas_port = dev->port;
-	struct sas_phy *sphy = dev->phy;
-	struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];
 	struct mvs_slot_info *slot;
 	void *buf_prd;
 	u32 tag = tei->tag, hdr_tag;
@@ -468,7 +465,7 @@ static int mvs_task_prep_ata(struct mvs_
 	slot->tx = mvi->tx_prod;
 	del_q = TXQ_MODE_I | tag |
 		(TXQ_CMD_STP << TXQ_CMD_SHIFT) |
-		(MVS_PHY_ID << TXQ_PHY_SHIFT) |
+		((sas_port->phy_mask & TXQ_PHY_MASK) << TXQ_PHY_SHIFT) |
 		(mvi_dev->taskfileset << TXQ_SRS_SHIFT);
 	mvi->tx[mvi->tx_prod] = cpu_to_le32(del_q);
 
author maintainer
#170 lore raw

PATCH 177/220 rc: img-ir: fix error in parameters passed to irq_free()

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sifan Naeem <[email protected]>

commit 80ccf4ad06dc9d2f06a8347b2d309cdc959f72b3 upstream.

img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure.
This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module.

WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278
__free_irq+0xb4/0x214() Trying to free already-free IRQ 58
Modules linked in: img_ir(-)
CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ...
Call Trace:
...
[<8048d420>] __free_irq+0xb4/0x214
[<8048d6b4>] free_irq+0xac/0xf4
[<c009b130>] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>]
platform_drv_remove+0x30/0x54 ...
Fixes 160a8f8aec4d ("[media] rc: img-ir: add base driver")
---
 drivers/media/rc/img-ir/img-ir-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/rc/img-ir/img-ir-core.c +1 -1
@@ -146,7 +146,7 @@ static int img_ir_remove(struct platform
 {
 	struct img_ir_priv *priv = platform_get_drvdata(pdev);
 
-	free_irq(priv->irq, img_ir_isr);
+	free_irq(priv->irq, priv);
 	img_ir_remove_hw(priv);
 	img_ir_remove_raw(priv);
 
author maintainer
#171 lore raw

PATCH 178/220 stk1160: Make sure current buffer is released

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Ezequiel Garcia <[email protected]>

commit aeff09276748b66072f2db2e668cec955cf41959 upstream.

The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it.

---
 drivers/media/usb/stk1160/stk1160-v4l.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/media/usb/stk1160/stk1160-v4l.c +15 -2
@@ -240,6 +240,11 @@ static int stk1160_stop_streaming(struct
 	if (mutex_lock_interruptible(&dev->v4l_lock))
 		return -ERESTARTSYS;
 
+	/*
+	 * Once URBs are cancelled, the URB complete handler
+	 * won't be running. This is required to safely release the
+	 * current buffer (dev->isoc_ctl.buf).
+	 */
 	stk1160_cancel_isoc(dev);
 
 	/*
@@ -620,8 +625,16 @@ void stk1160_clear_queue(struct stk1160
 		stk1160_info("buffer [%p/%d] aborted\n",
 				buf, buf->vb.v4l2_buf.index);
 	}
-	/* It's important to clear current buffer */
-	dev->isoc_ctl.buf = NULL;
+
+	/* It's important to release the current buffer */
+	if (dev->isoc_ctl.buf) {
+		buf = dev->isoc_ctl.buf;
+		dev->isoc_ctl.buf = NULL;
+
+		vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+		stk1160_info("buffer [%p/%d] aborted\n",
+				buf, buf->vb.v4l2_buf.index);
+	}
 	spin_unlock_irqrestore(&dev->buf_lock, flags);
 }
 
author maintainer
#172 lore raw

PATCH 179/220 IB/core: disallow registering 0-sized memory region

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Yann Droneaud <[email protected]>

commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.

If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller.

This should not be allowed: it's not expected for a memory region to have a size equal to 0.

This patch adds a check to explicitly refuse to register a 0-sized region.

---
 drivers/infiniband/core/umem.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/infiniband/core/umem.c +3 -0
@@ -99,6 +99,9 @@ struct ib_umem *ib_umem_get(struct ib_uc
 	if (dmasync)
 		dma_set_attr(DMA_ATTR_WRITE_BARRIER, &attrs);
 
+	if (!size)
+		return ERR_PTR(-EINVAL);
+
 	/*
 	 * If the combination of the addr and size requested for this memory
 	 * region causes an integer overflow, return error.
author maintainer
#173 lore raw

PATCH 180/220 IB/core: dont disallow registering region starting at 0x0

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Yann Droneaud <[email protected]>

commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.

In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0).

This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages().

There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check.

---
 drivers/infiniband/core/umem.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/core/umem.c +2 -2
@@ -106,8 +106,8 @@ struct ib_umem *ib_umem_get(struct ib_uc
 	 * If the combination of the addr and size requested for this memory
 	 * region causes an integer overflow, return error.
 	 */
-	if ((PAGE_ALIGN(addr + size) <= size) ||
-	    (PAGE_ALIGN(addr + size) <= addr))
+	if (((addr + size) < addr) ||
+	    PAGE_ALIGN(addr + size) < (addr + size))
 		return ERR_PTR(-EINVAL);
 
 	if (!can_do_mlock())
author maintainer
#174 lore raw

PATCH 181/220 IB/mlx4: Fix WQE LSO segment calculation

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Erez Shitrit <[email protected]>

commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.

The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers.

It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers.

The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages.

An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state.

Fixes b832be1e4007 ('IB/mlx4: Add IPoIB LSO support')
---
 drivers/infiniband/hw/mlx4/qp.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/infiniband/hw/mlx4/qp.c +1 -2
@@ -2605,8 +2605,7 @@ static int build_lso_seg(struct mlx4_wqe
 
 	memcpy(wqe->header, wr->wr.ud.header, wr->wr.ud.hlen);
 
-	*lso_hdr_sz  = cpu_to_be32((wr->wr.ud.mss - wr->wr.ud.hlen) << 16 |
-				   wr->wr.ud.hlen);
+	*lso_hdr_sz  = cpu_to_be32(wr->wr.ud.mss << 16 | wr->wr.ud.hlen);
 	*lso_seg_len = halign;
 	return 0;
 }
author maintainer
#175 lore raw

PATCH 182/220 IB/iser: Fix wrong calculation of protection buffer length

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sagi Grimberg <[email protected]>

commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f upstream.

This length miss-calculation may cause a silent data corruption in the DIX case and cause the device to reference unmapped area.

Fixes d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information')
---
 drivers/infiniband/ulp/iser/iser_initiator.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/ulp/iser/iser_initiator.c +2 -2
@@ -409,8 +409,8 @@ int iser_send_command(struct iscsi_conn
 	if (scsi_prot_sg_count(sc)) {
 		prot_buf->buf  = scsi_prot_sglist(sc);
 		prot_buf->size = scsi_prot_sg_count(sc);
-		prot_buf->data_len = data_buf->data_len >>
-				     ilog2(sc->device->sector_size) * 8;
+		prot_buf->data_len = (data_buf->data_len >>
+				     ilog2(sc->device->sector_size)) * 8;
 	}
 
 	if (hdr->flags & ISCSI_FLAG_CMD_READ) {
author maintainer
#176 lore raw

PATCH 183/220 tracing: Handle ftrace_dump() atomic context in graph_trace_open()

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Rabin Vincent <[email protected]>

commit ef99b88b16bee753fa51207abdc58ae660453ec6 upstream.

graph_trace_open() can be called in atomic context from ftrace_dump(). Use GFP_ATOMIC for the memory allocations when that's the case, in order to avoid the following splat.

 BUG: sleeping function called from invalid context at mm/slab.c:2849
 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
 Backtrace:
 ..
 [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238)
  r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0
 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0)
  r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8
  r4:810d16f0
 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c)
  r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30
 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec)
  r4:810d2580 r3:00000000
 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20)
  r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a
  r4:808d5394
 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
  r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210
 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18)
  r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60
  r4:8454fe00
 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c)
  r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60
  r4:84f01e00
 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac)
  r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000
 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c)
  r6:00000026 r5:00000000 r4:00000026 r3:8007a938
 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc)
  r4:808c1e38 r3:0000002e
 [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c)
  r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015
  r4:8880210c r3:808c7ef0
 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c)
---
 kernel/trace/trace_functions_graph.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
kernel/trace/trace_functions_graph.c +6 -2
@@ -1309,15 +1309,19 @@ void graph_trace_open(struct trace_itera
 {
 	/* pid and depth on the last trace processed */
 	struct fgraph_data *data;
+	gfp_t gfpflags;
 	int cpu;
 
 	iter->private = NULL;
 
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	/* We can be called in atomic context via ftrace_dump() */
+	gfpflags = (in_atomic() || irqs_disabled()) ? GFP_ATOMIC : GFP_KERNEL;
+
+	data = kzalloc(sizeof(*data), gfpflags);
 	if (!data)
 		goto out_err;
 
-	data->cpu_data = alloc_percpu(struct fgraph_cpu_data);
+	data->cpu_data = alloc_percpu_gfp(struct fgraph_cpu_data, gfpflags);
 	if (!data->cpu_data)
 		goto out_err_free;
 
author maintainer
#177 lore raw

PATCH 184/220 tracing: Fix incorrect enabling of trace events by boot cmdline

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Joonsoo Kim <[email protected]>

commit 84fce9db4d7eaebd6cb2ee30c15da6d4e4daf846 upstream.

There is a problem that trace events are not properly enabled with boot cmdline. The problem is that if we pass "trace_event=kmem:mm_page_alloc" to the boot cmdline, it enables all kmem trace events, and not just the page_alloc event.

This is caused by the parsing mechanism. When we parse the cmdline, the buffer contents is modified due to tokenization. And, if we use this buffer again, we will get the wrong result.

Unfortunately, this buffer is be accessed three times to set trace events properly at boot time. So, we need to handle this situation.

There is already code handling ",", but we need another for ":". This patch adds it.

[ added missing return ret; ]
---
 kernel/trace/trace_events.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
kernel/trace/trace_events.c +8 -1
@@ -565,6 +565,7 @@ static int __ftrace_set_clr_event(struct
 static int ftrace_set_clr_event(struct trace_array *tr, char *buf, int set)
 {
 	char *event = NULL, *sub = NULL, *match;
+	int ret;
 
 	/*
 	 * The buf format can be <subsystem>:<event-name>
@@ -590,7 +591,13 @@ static int ftrace_set_clr_event(struct t
 			event = NULL;
 	}
 
-	return __ftrace_set_clr_event(tr, match, sub, event, set);
+	ret = __ftrace_set_clr_event(tr, match, sub, event, set);
+
+	/* Put back the colon to allow this to be called again */
+	if (buf)
+		*(buf - 1) = ':';
+
+	return ret;
 }
 
 /**
author maintainer
#178 lore raw

PATCH 185/220 i2c: mux: use proper dev when removing "channel-X" symlinks

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Wolfram Sang <[email protected]>

commit 133778482ec6c8fde69406be380333963627c17a upstream.

Those symlinks are created for the mux_dev, so we need to remove it from there. Currently, it breaks for muxes where the mux_dev is not the device of the parent adapter like this:

[   78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78()
[   78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0'

Remove confusing comments while we are here.

---
 drivers/i2c/i2c-mux.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/i2c/i2c-mux.c +5 -3
@@ -32,8 +32,9 @@ struct i2c_mux_priv {
 	struct i2c_algorithm algo;
 
 	struct i2c_adapter *parent;
-	void *mux_priv;	/* the mux chip/device */
-	u32  chan_id;	/* the channel id */
+	struct device *mux_dev;
+	void *mux_priv;
+	u32 chan_id;
 
 	int (*select)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
 	int (*deselect)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
@@ -119,6 +120,7 @@ struct i2c_adapter *i2c_add_mux_adapter(
 
 	/* Set up private adapter data */
 	priv->parent = parent;
+	priv->mux_dev = mux_dev;
 	priv->mux_priv = mux_priv;
 	priv->chan_id = chan_id;
 	priv->select = select;
@@ -203,7 +205,7 @@ void i2c_del_mux_adapter(struct i2c_adap
 	char symlink_name[20];
 
 	snprintf(symlink_name, sizeof(symlink_name), "channel-%u", priv->chan_id);
-	sysfs_remove_link(&adap->dev.parent->kobj, symlink_name);
+	sysfs_remove_link(&priv->mux_dev->kobj, symlink_name);
 
 	sysfs_remove_link(&priv->adap.dev.kobj, "mux_device");
 	i2c_del_adapter(adap);
author maintainer
#179 lore raw

PATCH 186/220 i2c: rk3x: report number of messages transmitted

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Torokhov <[email protected]>

commit c6cbfb91b878224e78408a2e15901c79de77115a upstream.

master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes.

---
 drivers/i2c/busses/i2c-rk3x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-rk3x.c +1 -1
@@ -833,7 +833,7 @@ static int rk3x_i2c_xfer(struct i2c_adap
 	clk_disable(i2c->clk);
 	spin_unlock_irqrestore(&i2c->lock, flags);
 
-	return ret;
+	return ret < 0 ? ret : num;
 }
 
 static u32 rk3x_i2c_func(struct i2c_adapter *adap)
author maintainer
#180 lore raw

PATCH 187/220 i2c: Mark adapter devices with pm_runtime_no_callbacks

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Charles Keepax <[email protected]>

commit 6ada5c1e1b077ab98fc144d7ac132b4dcc0148ec upstream.

Commit 523c5b89640e ("i2c: Remove support for legacy PM") removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume.

This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any.

---
 drivers/i2c/i2c-core.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/i2c/i2c-core.c +2 -0
@@ -1410,6 +1410,8 @@ static int i2c_register_adapter(struct i
 
 	dev_dbg(&adap->dev, "adapter [%s] registered\n", adap->name);
 
+	pm_runtime_no_callbacks(&adap->dev);
+
 #ifdef CONFIG_I2C_COMPAT
 	res = class_compat_create_link(i2c_adapter_compat_class, &adap->dev,
 				       adap->dev.parent);
author maintainer
#181 lore raw

PATCH 188/220 i2c: core: Export bus recovery functions

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Mark Brown <[email protected]>

commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 upstream.

Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported:

ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!

Add exports to fix this.

Fixes 5f9296ba21b3c (i2c: Add bus recovery infrastructure)
---
 drivers/i2c/i2c-core.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/i2c/i2c-core.c +3 -0
@@ -596,6 +596,7 @@ int i2c_generic_scl_recovery(struct i2c_
 	adap->bus_recovery_info->set_scl(adap, 1);
 	return i2c_generic_recovery(adap);
 }
+EXPORT_SYMBOL_GPL(i2c_generic_scl_recovery);
 
 int i2c_generic_gpio_recovery(struct i2c_adapter *adap)
 {
@@ -610,6 +611,7 @@ int i2c_generic_gpio_recovery(struct i2c
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(i2c_generic_gpio_recovery);
 
 int i2c_recover_bus(struct i2c_adapter *adap)
 {
@@ -619,6 +621,7 @@ int i2c_recover_bus(struct i2c_adapter *
 	dev_dbg(&adap->dev, "Trying i2c bus recovery\n");
 	return adap->bus_recovery_info->recover_bus(adap);
 }
+EXPORT_SYMBOL_GPL(i2c_recover_bus);
 
 static int i2c_device_probe(struct device *dev)
 {
author maintainer
#182 lore raw

PATCH 189/220 drm/radeon: fix doublescan modes (v2)

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Alex Deucher <[email protected]>

commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.

Use the correct flags for atom.

v2: handle DRM_MODE_FLAG_DBLCLK

---
 drivers/gpu/drm/radeon/atombios_crtc.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/atombios_crtc.c +6 -2
@@ -330,8 +330,10 @@ atombios_set_crtc_dtd_timing(struct drm_
 		misc |= ATOM_COMPOSITESYNC;
 	if (mode->flags & DRM_MODE_FLAG_INTERLACE)
 		misc |= ATOM_INTERLACE;
-	if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
 		misc |= ATOM_DOUBLE_CLOCK_MODE;
+	if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+		misc |= ATOM_H_REPLICATIONBY2 | ATOM_V_REPLICATIONBY2;
 
 	args.susModeMiscInfo.usAccess = cpu_to_le16(misc);
 	args.ucCRTC = radeon_crtc->crtc_id;
@@ -374,8 +376,10 @@ static void atombios_crtc_set_timing(str
 		misc |= ATOM_COMPOSITESYNC;
 	if (mode->flags & DRM_MODE_FLAG_INTERLACE)
 		misc |= ATOM_INTERLACE;
-	if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
 		misc |= ATOM_DOUBLE_CLOCK_MODE;
+	if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+		misc |= ATOM_H_REPLICATIONBY2 | ATOM_V_REPLICATIONBY2;
 
 	args.susModeMiscInfo.usAccess = cpu_to_le16(misc);
 	args.ucCRTC = radeon_crtc->crtc_id;
author maintainer
#183 lore raw

PATCH 191/220 drm/i915: Dont enable CS_PARSER_ERROR interrupts at all

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Vetter <[email protected]>

commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 upstream.

We stopped handling them in

commit aaecdf611a05cac26a94713bad25297e60225c29

Author: Daniel Vetter <[email protected]>
Date:   Tue Nov 4 15:52:22 2014 +0100

drm/i915: Stop gathering error states for CS error interrupts

but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang.

Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171

---
 drivers/gpu/drm/i915/i915_irq.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_irq.c +2 -6
@@ -3718,14 +3718,12 @@ static int i8xx_irq_postinstall(struct d
 		~(I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
 		  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
 		  I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
-		  I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT |
-		  I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
+		  I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT);
 	I915_WRITE16(IMR, dev_priv->irq_mask);
 
 	I915_WRITE16(IER,
 		     I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
 		     I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
-		     I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
 		     I915_USER_INTERRUPT);
 	POSTING_READ16(IER);
 
@@ -3887,14 +3885,12 @@ static int i915_irq_postinstall(struct d
 		  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
 		  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
 		  I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
-		  I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT |
-		  I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
+		  I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT);
 
 	enable_mask =
 		I915_ASLE_INTERRUPT |
 		I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
 		I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
-		I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
 		I915_USER_INTERRUPT;
 
 	if (I915_HAS_HOTPLUG(dev)) {
author maintainer
#184 lore raw

PATCH 192/220 drm: adv7511: Fix DDC error interrupt handling

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Laurent Pinchart <[email protected]>

commit 2e96206c4f952295e11c311fbb2a7aa2105024af upstream.

The DDC error interrupt bit is located in REG_INT1, not REG_INT0. Update both the interrupt wait code and the interrupt sources reset code accordingly.

---
 drivers/gpu/drm/i2c/adv7511.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)
drivers/gpu/drm/i2c/adv7511.c +10 -4
@@ -467,14 +467,16 @@ static int adv7511_get_edid_block(void *
 				     block);
 			ret = adv7511_wait_for_interrupt(adv7511,
 					ADV7511_INT0_EDID_READY |
-					ADV7511_INT1_DDC_ERROR, 200);
+					(ADV7511_INT1_DDC_ERROR << 8), 200);
 
 			if (!(ret & ADV7511_INT0_EDID_READY))
 				return -EIO;
 		}
 
 		regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-			     ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
+			     ADV7511_INT0_EDID_READY);
+		regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
+			     ADV7511_INT1_DDC_ERROR);
 
 		/* Break this apart, hopefully more I2C controllers will
 		 * support 64 byte transfers than 256 byte transfers
@@ -528,7 +530,9 @@ static int adv7511_get_modes(struct drm_
 	/* Reading the EDID only works if the device is powered */
 	if (adv7511->dpms_mode != DRM_MODE_DPMS_ON) {
 		regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-			     ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
+			     ADV7511_INT0_EDID_READY);
+		regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
+			     ADV7511_INT1_DDC_ERROR);
 		regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
 				   ADV7511_POWER_POWER_DOWN, 0);
 		adv7511->current_edid_segment = -1;
@@ -563,7 +567,9 @@ static void adv7511_encoder_dpms(struct
 		adv7511->current_edid_segment = -1;
 
 		regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-			     ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
+			     ADV7511_INT0_EDID_READY);
+		regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
+			     ADV7511_INT1_DDC_ERROR);
 		regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
 				   ADV7511_POWER_POWER_DOWN, 0);
 		/*
author maintainer
#185 lore raw

PATCH 193/220 drm: adv7511: Fix nested sleep when reading EDID

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Laurent Pinchart <[email protected]>

commit a5241289c4139f0521b89e34a70f5f998463ae15 upstream.

The EDID read code waits for the read completion interrupt to occur using wait_event_interruptible(). The condition passed to the macro reads I2C registers. This results in sleeping with the task state set to TASK_INTERRUPTIBLE, triggering a WARN_ON() introduced in commit 8eb23b9f35aae ("sched: Debug nested sleeps").

Fix this by reworking the EDID read code. Instead of checking whether the read is complete through I2C reads, handle the interrupt registers in the interrupt handler and update a new edid_read flag accordingly. As a side effect both the IRQ and polling code paths now process the interrupt sources through the same code path, simplifying the code.

---
 drivers/gpu/drm/i2c/adv7511.c |   96 ++++++++++++++++++++----------------------
 1 file changed, 46 insertions(+), 50 deletions(-)
drivers/gpu/drm/i2c/adv7511.c +46 -50
@@ -33,6 +33,7 @@ struct adv7511 {
 
 	unsigned int current_edid_segment;
 	uint8_t edid_buf[256];
+	bool edid_read;
 
 	wait_queue_head_t wq;
 	struct drm_encoder *encoder;
@@ -379,69 +380,71 @@ static bool adv7511_hpd(struct adv7511 *
 	return false;
 }
 
-static irqreturn_t adv7511_irq_handler(int irq, void *devid)
-{
-	struct adv7511 *adv7511 = devid;
-
-	if (adv7511_hpd(adv7511))
-		drm_helper_hpd_irq_event(adv7511->encoder->dev);
-
-	wake_up_all(&adv7511->wq);
-
-	return IRQ_HANDLED;
-}
-
-static unsigned int adv7511_is_interrupt_pending(struct adv7511 *adv7511,
-						 unsigned int irq)
+static int adv7511_irq_process(struct adv7511 *adv7511)
 {
 	unsigned int irq0, irq1;
-	unsigned int pending;
 	int ret;
 
 	ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), &irq0);
 	if (ret < 0)
-		return 0;
+		return ret;
+
 	ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(1), &irq1);
 	if (ret < 0)
-		return 0;
+		return ret;
+
+	regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
+	regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
+
+	if (irq0 & ADV7511_INT0_HDP)
+		drm_helper_hpd_irq_event(adv7511->encoder->dev);
+
+	if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
+		adv7511->edid_read = true;
+
+		if (adv7511->i2c_main->irq)
+			wake_up_all(&adv7511->wq);
+	}
+
+	return 0;
+}
 
-	pending = (irq1 << 8) | irq0;
+static irqreturn_t adv7511_irq_handler(int irq, void *devid)
+{
+	struct adv7511 *adv7511 = devid;
+	int ret;
 
-	return pending & irq;
+	ret = adv7511_irq_process(adv7511);
+	return ret < 0 ? IRQ_NONE : IRQ_HANDLED;
 }
 
-static int adv7511_wait_for_interrupt(struct adv7511 *adv7511, int irq,
-				      int timeout)
+/* -----------------------------------------------------------------------------
+ * EDID retrieval
+ */
+
+static int adv7511_wait_for_edid(struct adv7511 *adv7511, int timeout)
 {
-	unsigned int pending;
 	int ret;
 
 	if (adv7511->i2c_main->irq) {
 		ret = wait_event_interruptible_timeout(adv7511->wq,
-				adv7511_is_interrupt_pending(adv7511, irq),
-				msecs_to_jiffies(timeout));
-		if (ret <= 0)
-			return 0;
-		pending = adv7511_is_interrupt_pending(adv7511, irq);
+				adv7511->edid_read, msecs_to_jiffies(timeout));
 	} else {
-		if (timeout < 25)
-			timeout = 25;
-		do {
-			pending = adv7511_is_interrupt_pending(adv7511, irq);
-			if (pending)
+		for (; timeout > 0; timeout -= 25) {
+			ret = adv7511_irq_process(adv7511);
+			if (ret < 0)
+				break;
+
+			if (adv7511->edid_read)
 				break;
+
 			msleep(25);
-			timeout -= 25;
-		} while (timeout >= 25);
+		}
 	}
 
-	return pending;
+	return adv7511->edid_read ? 0 : -EIO;
 }
 
-/* -----------------------------------------------------------------------------
- * EDID retrieval
- */
-
 static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block,
 				  size_t len)
 {
@@ -463,21 +466,14 @@ static int adv7511_get_edid_block(void *
 			return ret;
 
 		if (status != 2) {
+			adv7511->edid_read = false;
 			regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
 				     block);
-			ret = adv7511_wait_for_interrupt(adv7511,
-					ADV7511_INT0_EDID_READY |
-					(ADV7511_INT1_DDC_ERROR << 8), 200);
-
-			if (!(ret & ADV7511_INT0_EDID_READY))
-				return -EIO;
+			ret = adv7511_wait_for_edid(adv7511, 200);
+			if (ret < 0)
+				return ret;
 		}
 
-		regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-			     ADV7511_INT0_EDID_READY);
-		regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
-			     ADV7511_INT1_DDC_ERROR);
-
 		/* Break this apart, hopefully more I2C controllers will
 		 * support 64 byte transfers than 256 byte transfers
 		 */
author maintainer
#186 lore raw

PATCH 194/220 drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Imre Deak <[email protected]>

commit b5f1c97f944482e98e6e39208af356630389d1ea upstream.

Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this.

This was introduced in

commit ddeea5b0c36f3665446518c609be91f9336ef674

Author: Imre Deak <[email protected]>
Date:   Mon May 5 15:19:56 2014 +0300

drm/i915: vlv: add runtime PM support

I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel.

v2:
- resend after a missing git add -u :/

---
 drivers/gpu/drm/i915/i915_drv.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/i915_drv.c +2 -2
@@ -1042,7 +1042,7 @@ static void vlv_save_gunit_s0ix_state(st
 		s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS_BASE + i * 4);
 
 	s->media_max_req_count	= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
-	s->gfx_max_req_count	= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
+	s->gfx_max_req_count	= I915_READ(GEN7_GFX_MAX_REQ_COUNT);
 
 	s->render_hwsp		= I915_READ(RENDER_HWS_PGA_GEN7);
 	s->ecochk		= I915_READ(GAM_ECOCHK);
@@ -1124,7 +1124,7 @@ static void vlv_restore_gunit_s0ix_state
 		I915_WRITE(GEN7_LRA_LIMITS_BASE + i * 4, s->lra_limits[i]);
 
 	I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count);
-	I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->gfx_max_req_count);
+	I915_WRITE(GEN7_GFX_MAX_REQ_COUNT, s->gfx_max_req_count);
 
 	I915_WRITE(RENDER_HWS_PGA_GEN7,	s->render_hwsp);
 	I915_WRITE(GAM_ECOCHK,		s->ecochk);
author maintainer
#187 lore raw

PATCH 195/220 drm/i915: cope with large i2c transfers

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Torokhov <[email protected]>

commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.

The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues.

Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction).

---
 drivers/gpu/drm/i915/i915_reg.h  |    1 
 drivers/gpu/drm/i915/intel_i2c.c |   66 +++++++++++++++++++++++++++++++++------
 2 files changed, 57 insertions(+), 10 deletions(-)
drivers/gpu/drm/i915/i915_reg.h +1 -0
@@ -1740,6 +1740,7 @@ enum punit_power_well {
 #define   GMBUS_CYCLE_INDEX	(2<<25)
 #define   GMBUS_CYCLE_STOP	(4<<25)
 #define   GMBUS_BYTE_COUNT_SHIFT 16
+#define   GMBUS_BYTE_COUNT_MAX   256U
 #define   GMBUS_SLAVE_INDEX_SHIFT 8
 #define   GMBUS_SLAVE_ADDR_SHIFT 1
 #define   GMBUS_SLAVE_READ	(1<<0)
drivers/gpu/drm/i915/intel_i2c.c +56 -10

99 lines not on this page · raw message

author maintainer
#188 lore raw

PATCH 196/220 RCU pathwalk breakage when running into a symlink overmounting something

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Al Viro <[email protected]>

commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream.

Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput().

---
 fs/namei.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
fs/namei.c +4 -2
@@ -1591,7 +1591,8 @@ static inline int walk_component(struct
 
 	if (should_follow_link(path->dentry, follow)) {
 		if (nd->flags & LOOKUP_RCU) {
-			if (unlikely(unlazy_walk(nd, path->dentry))) {
+			if (unlikely(nd->path.mnt != path->mnt ||
+				     unlazy_walk(nd, path->dentry))) {
 				err = -ECHILD;
 				goto out_err;
 			}
@@ -3047,7 +3048,8 @@ finish_lookup:
 
 	if (should_follow_link(path->dentry, !symlink_ok)) {
 		if (nd->flags & LOOKUP_RCU) {
-			if (unlikely(unlazy_walk(nd, path->dentry))) {
+			if (unlikely(nd->path.mnt != path->mnt ||
+				     unlazy_walk(nd, path->dentry))) {
 				error = -ECHILD;
 				goto out;
 			}
author maintainer
#189 lore raw

PATCH 197/220 Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one"

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Iooss <[email protected]>

commit 3708f842e107b9b79d54a75d152e666b693649e8 upstream.

This reverts commit 5a254d08b086d80cbead2ebcee6d2a4b3a15587a.

Since commit 5a254d08b086 ("nfs: replace nfs_add_stats with nfs_inc_stats when add one"), nfs_readpage and nfs_do_writepage use nfs_inc_stats to increment NFSIOS_READPAGES and NFSIOS_WRITEPAGES instead of nfs_add_stats.

However nfs_inc_stats does not do the same thing as nfs_add_stats with value 1 because these functions work on distinct stats:
nfs_inc_stats increments stats from "enum nfs_stat_eventcounters" (in server->io_stats->events) and nfs_add_stats those from "enum nfs_stat_bytecounters" (in server->io_stats->bytes).

Fixes 5a254d08b086 ("nfs: replace nfs_add_stats with nfs_inc_stats...")
---
 fs/nfs/read.c  |    2 +-
 fs/nfs/write.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
fs/nfs/read.c +1 -1
@@ -284,7 +284,7 @@ int nfs_readpage(struct file *file, stru
 	dprintk("NFS: nfs_readpage (%p %ld@%lu)\n",
 		page, PAGE_CACHE_SIZE, page_file_index(page));
 	nfs_inc_stats(inode, NFSIOS_VFSREADPAGE);
-	nfs_inc_stats(inode, NFSIOS_READPAGES);
+	nfs_add_stats(inode, NFSIOS_READPAGES, 1);
 
 	/*
 	 * Try to flush any pending writes to the file..
fs/nfs/write.c +1 -1
@@ -580,7 +580,7 @@ static int nfs_do_writepage(struct page
 	int ret;
 
 	nfs_inc_stats(inode, NFSIOS_VFSWRITEPAGE);
-	nfs_inc_stats(inode, NFSIOS_WRITEPAGES);
+	nfs_add_stats(inode, NFSIOS_WRITEPAGES, 1);
 
 	nfs_pageio_cond_complete(pgio, page_file_index(page));
 	ret = nfs_page_async_flush(pgio, page, wbc->sync_mode == WB_SYNC_NONE);
author maintainer
#190 lore raw

PATCH 198/220 nfsd4: disallow ALLOCATE with special stateids

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "J. Bruce Fields" <[email protected]>

commit 5ba4a25ab7b13be528b23f85182f4d09cf7f71ad upstream.

vfs_fallocate will hit a NULL dereference if the client tries an ALLOCATE or DEALLOCATE with a special stateid. Fix that. (We also depend on the open to have broken any conflicting leases or delegations for us.)

(If it turns out we need to allow special stateid's then we could do a temporary open here in the special-stateid case, as we do for read and write. For now I'm assuming it's not necessary.)

Fixes 95d871f03cae "nfsd: Add ALLOCATE support"
Cc Anna Schumaker <[email protected]>
---
 fs/nfsd/nfs4proc.c |    2 ++
 1 file changed, 2 insertions(+)
fs/nfsd/nfs4proc.c +2 -0
@@ -1030,6 +1030,8 @@ nfsd4_fallocate(struct svc_rqst *rqstp,
 		dprintk("NFSD: nfsd4_fallocate: couldn't process stateid!\n");
 		return status;
 	}
+	if (!file)
+		return nfserr_bad_stateid;
 
 	status = nfsd4_vfs_fallocate(rqstp, &cstate->current_fh, file,
 				     fallocate->falloc_offset,
author maintainer
#191 lore raw

PATCH 199/220 nfsd4: fix READ permission checking

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "J. Bruce Fields" <[email protected]>

commit 6e4891dc289cd191d46ab7ba1dcb29646644f9ca upstream.

In the case we already have a struct file (derived from a stateid), we still need to do permission-checking; otherwise an unauthorized user could gain access to a file by sniffing or guessing somebody else's stateid.

Fixes dc97618ddda9 "nfsd4: separate splice and readv cases"
---
 fs/nfsd/nfs4xdr.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
fs/nfsd/nfs4xdr.c +8 -4
@@ -3422,6 +3422,7 @@ nfsd4_encode_read(struct nfsd4_compoundr
 	unsigned long maxcount;
 	struct xdr_stream *xdr = &resp->xdr;
 	struct file *file = read->rd_filp;
+	struct svc_fh *fhp = read->rd_fhp;
 	int starting_len = xdr->buf->len;
 	struct raparms *ra;
 	__be32 *p;
@@ -3445,12 +3446,15 @@ nfsd4_encode_read(struct nfsd4_compoundr
 	maxcount = min_t(unsigned long, maxcount, (xdr->buf->buflen - xdr->buf->len));
 	maxcount = min_t(unsigned long, maxcount, read->rd_length);
 
-	if (!read->rd_filp) {
+	if (read->rd_filp)
+		err = nfsd_permission(resp->rqstp, fhp->fh_export,
+				fhp->fh_dentry,
+				NFSD_MAY_READ|NFSD_MAY_OWNER_OVERRIDE);
+	else
 		err = nfsd_get_tmp_read_open(resp->rqstp, read->rd_fhp,
 						&file, &ra);
-		if (err)
-			goto err_truncate;
-	}
+	if (err)
+		goto err_truncate;
 
 	if (file->f_op->splice_read && test_bit(RQ_SPLICE_OK, &resp->rqstp->rq_flags))
 		err = nfsd4_encode_splice_read(resp, read, file, maxcount);
author maintainer
#192 lore raw

PATCH 200/220 nfsd4: disallow SEEK with special stateids

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "J. Bruce Fields" <[email protected]>

commit 980608fb50aea34993ba956b71cd4602aa42b14b upstream.

If the client uses a special stateid then we'll pass a NULL file to vfs_llseek.

Fixes 24bab491220f " NFSD: Implement SEEK"
Cc Anna Schumaker <[email protected]>
---
 fs/nfsd/nfs4proc.c |    2 ++
 1 file changed, 2 insertions(+)
fs/nfsd/nfs4proc.c +2 -0
@@ -1071,6 +1071,8 @@ nfsd4_seek(struct svc_rqst *rqstp, struc
 		dprintk("NFSD: nfsd4_seek: couldn't process stateid!\n");
 		return status;
 	}
+	if (!file)
+		return nfserr_bad_stateid;
 
 	switch (seek->seek_whence) {
 	case NFS4_CONTENT_DATA:
author maintainer
#193 lore raw

PATCH 201/220 nfsd: eliminate NFSD_DEBUG

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Mark Salter <[email protected]>

commit 135dd002c23054aaa056ea3162c1e0356905c195 upstream.

Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced use of IS_ENABLED() in a uapi header which leads to a build failure for userspace apps trying to use <linux/nfsd/debug.h>:

linux/nfsd/debug.h:18:15: error: missing binary operator before token "("

  #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
                ^

Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG.

Fixes f895b252d4edf "sunrpc: eliminate RPC_DEBUG"
---
 fs/lockd/svcsubs.c              |    2 +-
 fs/nfsd/nfs4state.c             |    2 +-
 fs/nfsd/nfsd.h                  |    2 +-
 include/uapi/linux/nfsd/debug.h |    8 --------
 4 files changed, 3 insertions(+), 11 deletions(-)
fs/lockd/svcsubs.c +1 -1
@@ -31,7 +31,7 @@
 static struct hlist_head	nlm_files[FILE_NRHASH];
 static DEFINE_MUTEX(nlm_file_mutex);
 
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
 static inline void nlm_debug_print_fh(char *msg, struct nfs_fh *f)
 {
 	u32 *fhp = (u32*)f->data;
fs/nfsd/nfs4state.c +1 -1
@@ -1139,7 +1139,7 @@ hash_sessionid(struct nfs4_sessionid *se
 	return sid->sequence % SESSION_HASH_SIZE;
 }
 
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
 static inline void
 dump_sessionid(const char *fn, struct nfs4_sessionid *sessionid)
 {
fs/nfsd/nfsd.h +1 -1
@@ -24,7 +24,7 @@
 #include "export.h"
 
 #undef ifdebug
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
 # define ifdebug(flag)		if (nfsd_debug & NFSDDBG_##flag)
 #else
 # define ifdebug(flag)		if (0)
include/uapi/linux/nfsd/debug.h +0 -8
@@ -12,14 +12,6 @@
 #include <linux/sunrpc/debug.h>
 
 /*
- * Enable debugging for nfsd.
- * Requires RPC_DEBUG.
- */
-#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
-# define NFSD_DEBUG		1
-#endif
-
-/*
  * knfsd debug flags
  */
 #define NFSDDBG_SOCK		0x0001
author maintainer
#194 lore raw

PATCH 202/220 nfsd: fix nsfd startup race triggering BUG_ON

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Giuseppe Cantavenera <[email protected]>

commit bb7ffbf29e76b89a86ca4c3ee0d4690641f2f772 upstream.

nfsd triggered a BUG_ON in net_generic(...) when rpc_pipefs_event(...) in fs/nfsd/nfs4recover.c was called before assigning ntfsd_net_id. The following was observed on a MIPS 32-core processor:
kernel: Call Trace:
kernel: [<ffffffffc00bc5e4>] rpc_pipefs_event+0x7c/0x158 [nfsd]
kernel: [<ffffffff8017a2a0>] notifier_call_chain+0x70/0xb8
kernel: [<ffffffff8017a4e4>] __blocking_notifier_call_chain+0x4c/0x70
kernel: [<ffffffff8053aff8>] rpc_fill_super+0xf8/0x1a0
kernel: [<ffffffff8022204c>] mount_ns+0xb4/0xf0
kernel: [<ffffffff80222b48>] mount_fs+0x50/0x1f8
kernel: [<ffffffff8023dc00>] vfs_kern_mount+0x58/0xf0
kernel: [<ffffffff802404ac>] do_mount+0x27c/0xa28
kernel: [<ffffffff80240cf0>] SyS_mount+0x98/0xe8
kernel: [<ffffffff80135d24>] handle_sys64+0x44/0x68
kernel:
kernel:

        Code: 0040f809  00000000  2e020001 <00020336> 3c12c00d
                3c02801a  de100000 6442eb98  0040f809

kernel: ---[ end trace 7471374335809536 ]---

Fixed this behaviour by calling register_pernet_subsys(&nfsd_net_ops) before registering rpc_pipefs_event(...) with the notifier chain.

---
 fs/nfsd/nfsctl.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
fs/nfsd/nfsctl.c +8 -8
@@ -1250,15 +1250,15 @@ static int __init init_nfsd(void)
 	int retval;
 	printk(KERN_INFO "Installing knfsd (copyright (C) 1996 [email protected]).\n");
 
-	retval = register_cld_notifier();
-	if (retval)
-		return retval;
 	retval = register_pernet_subsys(&nfsd_net_ops);
 	if (retval < 0)
-		goto out_unregister_notifier;
-	retval = nfsd4_init_slabs();
+		return retval;
+	retval = register_cld_notifier();
 	if (retval)
 		goto out_unregister_pernet;
+	retval = nfsd4_init_slabs();
+	if (retval)
+		goto out_unregister_notifier;
 	retval = nfsd4_init_pnfs();
 	if (retval)
 		goto out_free_slabs;
@@ -1290,10 +1290,10 @@ out_exit_pnfs:
 	nfsd4_exit_pnfs();
 out_free_slabs:
 	nfsd4_free_slabs();
-out_unregister_pernet:
-	unregister_pernet_subsys(&nfsd_net_ops);
 out_unregister_notifier:
 	unregister_cld_notifier();
+out_unregister_pernet:
+	unregister_pernet_subsys(&nfsd_net_ops);
 	return retval;
 }
 
@@ -1308,8 +1308,8 @@ static void __exit exit_nfsd(void)
 	nfsd4_exit_pnfs();
 	nfsd_fault_inject_cleanup();
 	unregister_filesystem(&nfsd_fs_type);
-	unregister_pernet_subsys(&nfsd_net_ops);
 	unregister_cld_notifier();
+	unregister_pernet_subsys(&nfsd_net_ops);
 }
 
 MODULE_AUTHOR("Olaf Kirch <[email protected]>");
author maintainer
#195 lore raw

PATCH 204/220 nfs: fix DIO good bytes calculation

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Peng Tao <[email protected]>

commit 1ccbad9f9f9bd36db26a10f0b17fbaf12b3ae93a upstream.

For direct read that has IO size larger than rsize, we'll split it into several READ requests and nfs_direct_good_bytes() would count completed bytes incorrectly by eating last zero count reply.

Fix it by handling mirror and non-mirror cases differently such that we only count mirrored writes differently.

This fixes 5fadeb47("nfs: count DIO good bytes correctly with mirroring").

---
 fs/nfs/direct.c |   29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)
fs/nfs/direct.c +17 -12
@@ -131,20 +131,25 @@ nfs_direct_good_bytes(struct nfs_direct_
 
 	WARN_ON_ONCE(hdr->pgio_mirror_idx >= dreq->mirror_count);
 
-	count = dreq->mirrors[hdr->pgio_mirror_idx].count;
-	if (count + dreq->io_start < hdr->io_start + hdr->good_bytes) {
-		count = hdr->io_start + hdr->good_bytes - dreq->io_start;
-		dreq->mirrors[hdr->pgio_mirror_idx].count = count;
-	}
-
-	/* update the dreq->count by finding the minimum agreed count from all
-	 * mirrors */
-	count = dreq->mirrors[0].count;
+	if (dreq->mirror_count == 1) {
+		dreq->mirrors[hdr->pgio_mirror_idx].count += hdr->good_bytes;
+		dreq->count += hdr->good_bytes;
+	} else {
+		/* mirrored writes */
+		count = dreq->mirrors[hdr->pgio_mirror_idx].count;
+		if (count + dreq->io_start < hdr->io_start + hdr->good_bytes) {
+			count = hdr->io_start + hdr->good_bytes - dreq->io_start;
+			dreq->mirrors[hdr->pgio_mirror_idx].count = count;
+		}
+		/* update the dreq->count by finding the minimum agreed count from all
+		 * mirrors */
+		count = dreq->mirrors[0].count;
 
-	for (i = 1; i < dreq->mirror_count; i++)
-		count = min(count, dreq->mirrors[i].count);
+		for (i = 1; i < dreq->mirror_count; i++)
+			count = min(count, dreq->mirrors[i].count);
 
-	dreq->count = count;
+		dreq->count = count;
+	}
 }
 
 /*
author maintainer
#196 lore raw

PATCH 205/220 nfs: remove WARN_ON_ONCE from nfs_direct_good_bytes

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Peng Tao <[email protected]>

commit 05f54903d9d370a4cd302a85681304d3ec59e5c1 upstream.

For flexfiles driver, we might choose to read from mirror index other than 0 while mirror_count is always 1 for read.

---
 fs/nfs/direct.c |    2 --
 1 file changed, 2 deletions(-)
fs/nfs/direct.c +0 -2
@@ -129,8 +129,6 @@ nfs_direct_good_bytes(struct nfs_direct_
 	int i;
 	ssize_t count;
 
-	WARN_ON_ONCE(hdr->pgio_mirror_idx >= dreq->mirror_count);
-
 	if (dreq->mirror_count == 1) {
 		dreq->mirrors[hdr->pgio_mirror_idx].count += hdr->good_bytes;
 		dreq->count += hdr->good_bytes;
author maintainer
#197 lore raw

PATCH 206/220 NFS: Add a stub for GETDEVICELIST

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Anna Schumaker <[email protected]>

commit 7c61f0d3897eeeff6f3294adb9f910ddefa8035a upstream.

d4b18c3e (pnfs: remove GETDEVICELIST implementation) removed the GETDEVICELIST operation from the NFS client, but left a "hole" in the nfs4_procedures array. This caused /proc/self/mountstats to report an operation named "51" where GETDEVICELIST used to be. This patch adds a stub to fix mountstats.

Fixes d4b18c3e (pnfs: remove GETDEVICELIST implementation)
---
 fs/nfs/nfs4xdr.c |    6 ++++++
 1 file changed, 6 insertions(+)
fs/nfs/nfs4xdr.c +6 -0
@@ -7365,6 +7365,11 @@ nfs4_stat_to_errno(int stat)
 	.p_name   = #proc,					\
 }
 
+#define STUB(proc)		\
+[NFSPROC4_CLNT_##proc] = {	\
+	.p_name = #proc,	\
+}
+
 struct rpc_procinfo	nfs4_procedures[] = {
 	PROC(READ,		enc_read,		dec_read),
 	PROC(WRITE,		enc_write,		dec_write),
@@ -7417,6 +7422,7 @@ struct rpc_procinfo	nfs4_procedures[] =
 	PROC(SECINFO_NO_NAME,	enc_secinfo_no_name,	dec_secinfo_no_name),
 	PROC(TEST_STATEID,	enc_test_stateid,	dec_test_stateid),
 	PROC(FREE_STATEID,	enc_free_stateid,	dec_free_stateid),
+	STUB(GETDEVICELIST),
 	PROC(BIND_CONN_TO_SESSION,
 			enc_bind_conn_to_session, dec_bind_conn_to_session),
 	PROC(DESTROY_CLIENTID,	enc_destroy_clientid,	dec_destroy_clientid),
author maintainer
#198 lore raw

PATCH 207/220 sched/deadline: Always enqueue on previous rq when dl_task_timer() fires

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Juri Lelli <[email protected]>

commit 4cd57f97135840f637431c92380c8da3edbe44ed upstream.

dl_task_timer() may fire on a different rq from where a task was removed after throttling. Since the call path is:

dl_task_timer() ->

    enqueue_task_dl() ->
      enqueue_dl_entity() ->
        replenish_dl_entity()

and replenish_dl_entity() uses dl_se's rq, we can't use current's rq in dl_task_timer(), but we need to lock the task's previous one.

---
 kernel/sched/deadline.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/sched/deadline.c +2 -2
@@ -514,7 +514,7 @@ static enum hrtimer_restart dl_task_time
 	unsigned long flags;
 	struct rq *rq;
 
-	rq = task_rq_lock(current, &flags);
+	rq = task_rq_lock(p, &flags);
 
 	/*
 	 * We need to take care of several possible races here:
@@ -569,7 +569,7 @@ static enum hrtimer_restart dl_task_time
 		push_dl_task(rq);
 #endif
 unlock:
-	task_rq_unlock(rq, current, &flags);
+	task_rq_unlock(rq, p, &flags);
 
 	return HRTIMER_NORESTART;
 }
author maintainer
#199 lore raw

PATCH 208/220 e1000: add dummy allocator to fix race condition between mtu change and netpoll

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sabrina Dubroca <[email protected]>

commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.

There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size:

Changing MTU frees all the rx buffers:

    e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
        e1000_clean_rx_ring

Then, close to the end of e1000_change_mtu:

    pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
        e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag

And when we come back to do the rest of the MTU change:

    e1000_up -> e1000_configure -> e1000_configure_rx ->
        e1000_alloc_jumbo_rx_buffers

alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state.

This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown):

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
    [...]
Call Trace:
 [<ffffffff81195445>] put_page+0x55/0x60
 [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200
 [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60
 [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0
 [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840
 [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170
 [<ffffffff81647050>] dev_set_mtu+0xa0/0x140
 [<ffffffff81664218>] do_setlink+0x218/0xac0
 [<ffffffff814459e9>] ? nla_parse+0xb9/0x120
 [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890
 [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40
 [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260

By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx.

Fixes edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
---
 drivers/net/ethernet/intel/e1000/e1000_main.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/e1000/e1000_main.c +9 -1
@@ -144,6 +144,11 @@ static bool e1000_clean_rx_irq(struct e1
 static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
 				     struct e1000_rx_ring *rx_ring,
 				     int *work_done, int work_to_do);
+static void e1000_alloc_dummy_rx_buffers(struct e1000_adapter *adapter,
+					 struct e1000_rx_ring *rx_ring,
+					 int cleaned_count)
+{
+}
 static void e1000_alloc_rx_buffers(struct e1000_adapter *adapter,
 				   struct e1000_rx_ring *rx_ring,
 				   int cleaned_count);
@@ -3552,8 +3557,11 @@ static int e1000_change_mtu(struct net_d
 		msleep(1);
 	/* e1000_down has a dependency on max_frame_size */
 	hw->max_frame_size = max_frame;
-	if (netif_running(netdev))
+	if (netif_running(netdev)) {
+		/* prevent buffers from being reallocated */
+		adapter->alloc_rx_buf = e1000_alloc_dummy_rx_buffers;
 		e1000_down(adapter);
+	}
 
 	/* NOTE: netdev_alloc_skb reserves 16 bytes, and typically NET_IP_ALIGN
 	 * means we reserve 2 more, this pushes us to allocate from the next
author maintainer
#200 lore raw

PATCH 209/220 mac80211: send AP probe as unicast again

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Johannes Berg <[email protected]>

commit a73f8e21f3f93159bc19e154e8f50891c22c11db upstream.

Louis reported that a static checker was complaining that the 'dst' variable was set (multiple times) but not used. This is due to a previous commit having removed the usage (apparently erroneously), so add it back.

Fixes a344d6778a98 ("mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR")
---
 net/mac80211/mlme.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/mlme.c +1 -1
@@ -2260,7 +2260,7 @@ static void ieee80211_mgd_probe_ap_send(
 		else
 			ssid_len = ssid[1];
 
-		ieee80211_send_probe_req(sdata, sdata->vif.addr, NULL,
+		ieee80211_send_probe_req(sdata, sdata->vif.addr, dst,
 					 ssid + 2, ssid_len, NULL,
 					 0, (u32) -1, true, 0,
 					 ifmgd->associated->channel, false);
author maintainer
#201 lore raw

PATCH 210/220 ebpf: verifier: check that call reg with ARG_ANYTHING is initialized

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Borkmann <[email protected]>

commit 80f1d68ccba70b1060c9c7360ca83da430f66bed upstream.

I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register).

This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API.

The underlying issue is that ARG_ANYTHING should actually be split into two different semantics:

1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and

2) ARG_ANYTHING that is an argument actually being used by a helper function and *guaranteed* to be an initialized register.

The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking.

Fixes 17a5267067f3 ("bpf: verifier (add verifier core)")
---
 include/linux/bpf.h   |    4 +++-
 kernel/bpf/verifier.c |    5 ++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
include/linux/bpf.h +3 -1
@@ -48,7 +48,7 @@ struct bpf_map *bpf_map_get(struct fd f)
 
 /* function argument constraints */
 enum bpf_arg_type {
-	ARG_ANYTHING = 0,	/* any argument is ok */
+	ARG_DONTCARE = 0,	/* unused argument in helper function */
 
 	/* the following constraints used to prototype
 	 * bpf_map_lookup/update/delete_elem() functions
@@ -62,6 +62,8 @@ enum bpf_arg_type {
 	 */
 	ARG_PTR_TO_STACK,	/* any pointer to eBPF program stack */
 	ARG_CONST_STACK_SIZE,	/* number of bytes accessed from stack */
+
+	ARG_ANYTHING,		/* any (initialized) argument is ok */
 };
 
 /* type of values returned from helper functions */
kernel/bpf/verifier.c +4 -1
@@ -755,7 +755,7 @@ static int check_func_arg(struct verifie
 	enum bpf_reg_type expected_type;
 	int err = 0;
 
-	if (arg_type == ARG_ANYTHING)
+	if (arg_type == ARG_DONTCARE)
 		return 0;
 
 	if (reg->type == NOT_INIT) {
@@ -763,6 +763,9 @@ static int check_func_arg(struct verifie
 		return -EACCES;
 	}
 
+	if (arg_type == ARG_ANYTHING)
+		return 0;
+
 	if (arg_type == ARG_PTR_TO_STACK || arg_type == ARG_PTR_TO_MAP_KEY ||
 	    arg_type == ARG_PTR_TO_MAP_VALUE) {
 		expected_type = PTR_TO_STACK;
author maintainer
#202 lore raw

PATCH 211/220 mm, thp: really limit transparent hugepage allocation to local node

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: David Rientjes <[email protected]>

commit 5265047ac30191ea24b16503165000c225f54feb upstream.

Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node") restructured alloc_hugepage_vma() with the intent of only allocating transparent hugepages locally when there was not an effective interleave mempolicy.

alloc_pages_exact_node() does not limit the allocation to the single node, however, but rather prefers it. This is because __GFP_THISNODE is not set which would cause the node-local nodemask to be passed. Without it, only a nodemask that prefers the local node is passed.

Fix this by passing __GFP_THISNODE and falling back to small pages when the allocation fails.

Commit 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target node") suffers from a similar problem for khugepaged, which is also fixed.

Fixes 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node")
Fixes 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target node")
Cc Christoph Lameter <[email protected]>
Cc Pekka Enberg <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Mel Gorman <[email protected]>
Cc Pravin Shelar <[email protected]>
Cc Jarno Rajahalme <[email protected]>
Cc Li Zefan <[email protected]>
Cc Greg Thelen <[email protected]>
Cc Tejun Heo <[email protected]>
---
 mm/huge_memory.c |    9 +++++++--
 mm/mempolicy.c   |    3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)
mm/huge_memory.c +7 -2
@@ -2316,8 +2316,14 @@ static struct page
 		       struct vm_area_struct *vma, unsigned long address,
 		       int node)
 {
+	gfp_t flags;
+
 	VM_BUG_ON_PAGE(*hpage, *hpage);
 
+	/* Only allocate from the target node */
+	flags = alloc_hugepage_gfpmask(khugepaged_defrag(), __GFP_OTHER_NODE) |
+	        __GFP_THISNODE;
+
 	/*
 	 * Before allocating the hugepage, release the mmap_sem read lock.
 	 * The allocation can take potentially a long time if it involves
@@ -2326,8 +2332,7 @@ static struct page
 	 */
 	up_read(&mm->mmap_sem);
 
-	*hpage = alloc_pages_exact_node(node, alloc_hugepage_gfpmask(
-		khugepaged_defrag(), __GFP_OTHER_NODE), HPAGE_PMD_ORDER);
+	*hpage = alloc_pages_exact_node(node, flags, HPAGE_PMD_ORDER);
 	if (unlikely(!*hpage)) {
 		count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
 		*hpage = ERR_PTR(-ENOMEM);
mm/mempolicy.c +2 -1
@@ -1985,7 +1985,8 @@ retry_cpuset:
 		nmask = policy_nodemask(gfp, pol);
 		if (!nmask || node_isset(node, *nmask)) {
 			mpol_cond_put(pol);
-			page = alloc_pages_exact_node(node, gfp, order);
+			page = alloc_pages_exact_node(node,
+						gfp | __GFP_THISNODE, order);
 			goto out;
 		}
 	}
author maintainer
#203 lore raw

PATCH 212/220 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: mancha security <[email protected]>

commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream.

OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization.

For the random driver and crypto drivers, calls are emitted ...

  $ gdb vmlinux
  (gdb) disassemble memzero_explicit
  Dump of assembler code for function memzero_explicit:
    0xffffffff813a18b0 <+0>:	push   %rbp
    0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
    0xffffffff813a18b4 <+4>:	xor    %esi,%esi
    0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
    0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 <memset>
    0xffffffff813a18be <+14>:	pop    %rbp
    0xffffffff813a18bf <+15>:	retq
  End of assembler dump.

(gdb) disassemble extract_entropy
[...]

    0xffffffff814a5009 <+313>:	mov    %r12,%rdi
    0xffffffff814a500c <+316>:	mov    $0xa,%esi
    0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0 <memzero_explicit>
    0xffffffff814a5016 <+326>:	mov    -0x48(%rbp),%rax

[...]

... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead.

Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead:

  static inline void memzero_explicit(void *s, size_t count)
  {
    memset(s, 0, count);
    <foo>
  }

  int main(void)
  {
    char buff[20];
    snprintf(buff, sizeof(buff) - 1, "test");
    printf("%s", buff);

    memzero_explicit(buff, sizeof(buff));
    return 0;

}

With <foo> := OPTIMIZER_HIDE_VAR():

(gdb) disassemble main
Dump of assembler code for function main:
[...]

   0x0000000000400464 <+36>:	callq  0x400410 <printf@plt>
   0x0000000000400469 <+41>:	xor    %eax,%eax
   0x000000000040046b <+43>:	add    $0x28,%rsp

0x000000000040046f <+47>: retq
End of assembler dump.

With <foo> := barrier():

(gdb) disassemble main
Dump of assembler code for function main:
[...]

   0x0000000000400464 <+36>:	callq  0x400410 <printf@plt>
   0x0000000000400469 <+41>:	movq   $0x0,(%rsp)
   0x0000000000400471 <+49>:	movq   $0x0,0x8(%rsp)
   0x000000000040047a <+58>:	movl   $0x0,0x10(%rsp)
   0x0000000000400482 <+66>:	xor    %eax,%eax
   0x0000000000400484 <+68>:	add    $0x28,%rsp

0x0000000000400488 <+72>: retq
End of assembler dump.

As can be seen, movq, movq, movl are being emitted inlined via memset().

Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/

Fixes d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data")
Cc Theodore Ts'o <[email protected]>
---
 lib/string.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
lib/string.c +1 -1
@@ -607,7 +607,7 @@ EXPORT_SYMBOL(memset);
 void memzero_explicit(void *s, size_t count)
 {
 	memset(s, 0, count);
-	OPTIMIZER_HIDE_VAR(s);
+	barrier();
 }
 EXPORT_SYMBOL(memzero_explicit);
 
author maintainer
#204 lore raw

PATCH 213/220 wl18xx: show rx_frames_per_rates as an array as it really is

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Iooss <[email protected]>

commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 upstream.

In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead.

This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'".

Fixes c5d94169e818 ("wl18xx: use new fw stats structures")
---
 drivers/net/wireless/ti/wl18xx/debugfs.c |    2 +-
 drivers/net/wireless/ti/wlcore/debugfs.h |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/net/wireless/ti/wl18xx/debugfs.c +1 -1
@@ -139,7 +139,7 @@ WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, p
 WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, accum_arp_pend_requests, "%u");
 WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, max_arp_queue_dep, "%u");
 
-WL18XX_DEBUGFS_FWSTATS_FILE(rx_rate, rx_frames_per_rates, "%u");
+WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(rx_rate, rx_frames_per_rates, 50);
 
 WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(aggr_size, tx_agg_vs_rate,
 				  AGGR_STATS_TX_AGG*AGGR_STATS_TX_RATE);
drivers/net/wireless/ti/wlcore/debugfs.h +2 -2
@@ -26,8 +26,8 @@
 
 #include "wlcore.h"
 
-int wl1271_format_buffer(char __user *userbuf, size_t count,
-			 loff_t *ppos, char *fmt, ...);
+__printf(4, 5) int wl1271_format_buffer(char __user *userbuf, size_t count,
+					loff_t *ppos, char *fmt, ...);
 
 int wl1271_debugfs_init(struct wl1271 *wl);
 void wl1271_debugfs_exit(struct wl1271 *wl);
author maintainer
#205 lore raw

PATCH 214/220 crypto: omap-aes - Fix support for unequal lengths

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: "Vutla, Lokesh" <[email protected]>

commit 6d7e7e02a044025237b6f62a20521170b794537f upstream.

For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver.

To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths.

Fixes 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned lengths")
---
 drivers/crypto/omap-aes.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/crypto/omap-aes.c +11 -3
@@ -554,15 +554,23 @@ static int omap_aes_crypt_dma_stop(struc
 	return err;
 }
 
-static int omap_aes_check_aligned(struct scatterlist *sg)
+static int omap_aes_check_aligned(struct scatterlist *sg, int total)
 {
+	int len = 0;
+
 	while (sg) {
 		if (!IS_ALIGNED(sg->offset, 4))
 			return -1;
 		if (!IS_ALIGNED(sg->length, AES_BLOCK_SIZE))
 			return -1;
+
+		len += sg->length;
 		sg = sg_next(sg);
 	}
+
+	if (len != total)
+		return -1;
+
 	return 0;
 }
 
@@ -633,8 +641,8 @@ static int omap_aes_handle_queue(struct
 	dd->in_sg = req->src;
 	dd->out_sg = req->dst;
 
-	if (omap_aes_check_aligned(dd->in_sg) ||
-	    omap_aes_check_aligned(dd->out_sg)) {
+	if (omap_aes_check_aligned(dd->in_sg, dd->total) ||
+	    omap_aes_check_aligned(dd->out_sg, dd->total)) {
 		if (omap_aes_copy_sgs(dd))
 			pr_err("Failed to copy SGs for unaligned cases\n");
 		dd->sgs_copied = 1;
author maintainer
#206 lore raw

PATCH 215/220 C6x: time: Ensure consistency in __init

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Nishanth Menon <[email protected]>

commit f4831605f2dacd12730fe73961c77253cc2ea425 upstream.

time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well.

This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y

WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references
the function __init timer64_init().
This is often because time_init lacks a __init
annotation or the annotation of timer64_init is wrong.

Fixes 546a39546c64 ("C6X: time management")
---
 arch/c6x/kernel/time.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/c6x/kernel/time.c +1 -1
@@ -49,7 +49,7 @@ u64 sched_clock(void)
 	return (tsc * sched_clock_multiplier) >> SCHED_CLOCK_SHIFT;
 }
 
-void time_init(void)
+void __init time_init(void)
 {
 	u64 tmp = (u64)NSEC_PER_SEC << SCHED_CLOCK_SHIFT;
 
author maintainer
#207 lore raw

PATCH 216/220 memstick: mspro_block: add missing curly braces

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.

Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly.

Fixes f1d82698029b ('memstick: use fully asynchronous request processing')
Cc Alex Dubov <[email protected]>
---
 drivers/memstick/core/mspro_block.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/memstick/core/mspro_block.c +2 -1
@@ -758,7 +758,7 @@ static int mspro_block_complete_req(stru
 
 		if (error || (card->current_mrq.tpc == MSPRO_CMD_STOP)) {
 			if (msb->data_dir == READ) {
-				for (cnt = 0; cnt < msb->current_seg; cnt++)
+				for (cnt = 0; cnt < msb->current_seg; cnt++) {
 					t_len += msb->req_sg[cnt].length
 						 / msb->page_size;
 
@@ -766,6 +766,7 @@ static int mspro_block_complete_req(stru
 						t_len += msb->current_page - 1;
 
 					t_len *= msb->page_size;
+				}
 			}
 		} else
 			t_len = blk_rq_bytes(msb->block_req);
author maintainer
#208 lore raw

PATCH 217/220 drivers: platform: parse IRQ flags from resources

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Linus Walleij <[email protected]>

commit 7085a7401ba54e92bbb5aa24d6f428071e18e509 upstream.

This fixes a regression from the net subsystem:
After commit d52fdbb735c36a209f36a628d40ca9185b349ba7 "smc91x: retrieve IRQ and trigger flags in a modern way" a regression would appear on some legacy platforms such as the ARM PXA Zylonite that specify IRQ resources like this:

static struct resource r = {

       .start  = X,
       .end    = X,
       .flags  = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,

};

The previous code would retrieve the resource and parse the high edge setting in the SMC91x driver, a use pattern that means every driver specifying an IRQ flag from a static resource need to parse resource flags and apply them at runtime.

As we switched the code to use IRQ descriptors to retrieve the the trigger type like this:

  irqd_get_trigger_type(irq_get_irq_data(...));

the code would work for new platforms using e.g. device tree as the backing irq descriptor would have its flags properly set, whereas this kind of oldstyle static resources at no point assign the trigger flags to the corresponding IRQ descriptor.

To make the behaviour identical on modern device tree and legacy static platform data platforms, modify platform_get_irq() to assign the trigger flags to the irq descriptor when a client looks up an IRQ from static resources.

Fixes d52fdbb735c3 ("smc91x: retrieve IRQ and trigger flags in a modern way")
---
 drivers/base/platform.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/base/platform.c +9 -0
@@ -101,6 +101,15 @@ int platform_get_irq(struct platform_dev
 	}
 
 	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+	/*
+	 * The resources may pass trigger flags to the irqs that need
+	 * to be set up. It so happens that the trigger flags for
+	 * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
+	 * settings.
+	 */
+	if (r && r->flags & IORESOURCE_BITS)
+		irqd_set_trigger_type(irq_get_irq_data(r->start),
+				      r->flags & IORESOURCE_BITS);
 
 	return r ? r->start : -ENXIO;
 #endif
author maintainer
#209 lore raw

PATCH 218/220 driver core: bus: Goto appropriate labels on failure in bus_add_device

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Junjie Mao <[email protected]>

commit 1c34203a1496d1849ba978021b878b3447d433c8 upstream.

It is not necessary to call device_remove_groups() when device_add_groups() fails.

The group added by device_add_groups() should be removed if sysfs_create_link() fails.

Fixes fa6fdb33b486 ("driver core: bus_type: add dev_groups")
---
 drivers/base/bus.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/base/bus.c +2 -2
@@ -515,11 +515,11 @@ int bus_add_device(struct device *dev)
 			goto out_put;
 		error = device_add_groups(dev, bus->dev_groups);
 		if (error)
-			goto out_groups;
+			goto out_id;
 		error = sysfs_create_link(&bus->p->devices_kset->kobj,
 						&dev->kobj, dev_name(dev));
 		if (error)
-			goto out_id;
+			goto out_groups;
 		error = sysfs_create_link(&dev->kobj,
 				&dev->bus->p->subsys.kobj, "subsystem");
 		if (error)
author maintainer
#210 lore raw

PATCH 219/220 netfilter: x_tables: fix cgroup matching on non-full sks

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Borkmann <[email protected]>

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting.

Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash.

Fixes a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks")
Cc Alexey Perevalov <[email protected]>
---
 net/netfilter/xt_cgroup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/xt_cgroup.c +1 -1
@@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str
 {
 	const struct xt_cgroup_info *info = par->matchinfo;
 
-	if (skb->sk == NULL)
+	if (skb->sk == NULL || !sk_fullsock(skb->sk))
 		return false;
 
 	return (info->id == skb->sk->sk_classid) ^ info->invert;
#211 lore raw

Re: [PATCH 4.0 219/220] netfilter: x_tables: fix cgroup matching on non-full sks

Hi

Quoted 13 lines · Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Borkmann <[email protected]>

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting.

Quoted 7 lines

Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash.

This introduces the same build failure into queue-4.0, as previously reported by Thomas Backlund for queue-3.19 in

	http://lkml.kernel.org/r/<[email protected]>

/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration]
if (skb->sk == NULL || !sk_fullsock(skb->sk))
^
cc1: some warnings being treated as errors
/tmp/buildd/linux-aptosid-4.0/scripts/Makefile.build:264: recipe for target 'net/netfilter/xt_cgroup.o' failed
make[7]: *** [net/netfilter/xt_cgroup.o] Error 1

Regards
Stefan Lippers-Hollmann

author maintainer
#212 lore raw

Re: [PATCH 4.0 219/220] netfilter: x_tables: fix cgroup matching on non-full sks

Quoted 37 lines · Stefan Lippers-Hollmann

Hi

Quoted 13 lines · Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Borkmann <[email protected]>

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting.

Quoted 7 lines

Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash.

This introduces the same build failure into queue-4.0, as previously reported by Thomas Backlund for queue-3.19 in

	http://lkml.kernel.org/r/<[email protected]>

/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration]
if (skb->sk == NULL || !sk_fullsock(skb->sk))
^
cc1: some warnings being treated as errors
/tmp/buildd/linux-aptosid-4.0/scripts/Makefile.build:264: recipe for target 'net/netfilter/xt_cgroup.o' failed
make[7]: *** [net/netfilter/xt_cgroup.o] Error 1

Quoted 2 lines

Regards
Stefan Lippers-Hollmann

Thanks, now removed.

greg k-h

author maintainer
#213 lore raw

PATCH 220/220 netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Florian Westphal <[email protected]>

commit 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream.

We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well.

Fixes 93fdd47e5 ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING')
---
 net/bridge/br_netfilter.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
net/bridge/br_netfilter.c +15 -2
@@ -651,6 +651,13 @@ static int br_nf_forward_finish(struct s
 	struct net_device *in;
 
 	if (!IS_ARP(skb) && !IS_VLAN_ARP(skb)) {
+		int frag_max_size;
+
+		if (skb->protocol == htons(ETH_P_IP)) {
+			frag_max_size = IPCB(skb)->frag_max_size;
+			BR_INPUT_SKB_CB(skb)->frag_max_size = frag_max_size;
+		}
+
 		in = nf_bridge->physindev;
 		if (nf_bridge->mask & BRNF_PKT_TYPE) {
 			skb->pkt_type = PACKET_OTHERHOST;
@@ -710,8 +717,14 @@ static unsigned int br_nf_forward_ip(con
 		nf_bridge->mask |= BRNF_PKT_TYPE;
 	}
 
-	if (pf == NFPROTO_IPV4 && br_parse_ip_options(skb))
-		return NF_DROP;
+	if (pf == NFPROTO_IPV4) {
+		int frag_max = BR_INPUT_SKB_CB(skb)->frag_max_size;
+
+		if (br_parse_ip_options(skb))
+			return NF_DROP;
+
+		IPCB(skb)->frag_max_size = frag_max;
+	}
 
 	/* The physdev module checks on this */
 	nf_bridge->mask |= BRNF_BRIDGED;
#214 lore raw
In reply to Greg Kroah-Hartman

Hi

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

[...]

This file doesn't exist(404). While I'm aware that the mirroring probably hasn't caught up yet, the URL seems to have multiple issues besides just that.

http://kernel.org/pub/linux/kernel/v4.0/ doesn't exist, there doesn't appear to be a symlink from v4.x to v4.0 (imho for good reasons), while such a smylink did exist for v3.x --> v3.0.

So fixing the obvious problem and adapting the URL to
http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz
doesn't work either, as there is no "stable-review" directory under
http://kernel.org/pub/linux/kernel/v4.x/ yet (which probably should be created).

Your previous, "[PATCH 4.0 0/7] 4.0.1-stable review"[1], mail referenced kernel.org/pub/linux/kernel/v3.0/stable-review/patch-4.0.1-rc1.gz which does exist. However patch-4.0.2-rc1.gz is still missing there or at the more sensible location at
http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz

Given that the patch files of the other stable-review patches posted today are already available[2], I assume that it's not just a problem with the mirroring.

Regards
Stefan Lippers-Hollmann

[1] http://lkml.kernel.org/r/<[email protected]>
[2] https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz

	https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gz
	https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz
author maintainer
#215 lore raw
Quoted 35 lines · Stefan Lippers-Hollmann

Hi

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

[...]

This file doesn't exist(404). While I'm aware that the mirroring probably hasn't caught up yet, the URL seems to have multiple issues besides just that.

http://kernel.org/pub/linux/kernel/v4.0/ doesn't exist, there doesn't appear to be a symlink from v4.x to v4.0 (imho for good reasons), while such a smylink did exist for v3.x --> v3.0.

So fixing the obvious problem and adapting the URL to
http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz
doesn't work either, as there is no "stable-review" directory under
http://kernel.org/pub/linux/kernel/v4.x/ yet (which probably should be created).

Your previous, "[PATCH 4.0 0/7] 4.0.1-stable review"[1], mail referenced kernel.org/pub/linux/kernel/v3.0/stable-review/patch-4.0.1-rc1.gz which does exist. However patch-4.0.2-rc1.gz is still missing there or at the more sensible location at
http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz

Quoted 3 lines

Given that the patch files of the other stable-review patches posted today are already available[2], I assume that it's not just a problem with the mirroring.

Yeah, the directory needs to be created, the proper people have been alerted, it might take a day or so to happen.

thanks,

greg k-h

#216 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Build results:

	total: 125 pass: 123 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 28 fail: 2

Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

Error log:

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,' [ and so on ]

Similar to 3.19, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

Guenter

author maintainer
#217 lore raw
Quoted 24 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Build results:

	total: 125 pass: 123 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 28 fail: 2

Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

Error log:

Quoted 7 lines

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,' [ and so on ]

Similar to 3.19, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

The powerpc patch is now removed.

greg k-h

#218 lore raw
In reply to Guenter Roeck
Quoted 24 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Build results:

     total: 125 pass: 123 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

     total: 30 pass: 28 fail: 2

Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

Error log:

Quoted 8 lines

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,' [ and so on ]

Similar to 3.19, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

Build and qemu test results for 4.0.x are now ok; no more failures.

Guenter

author maintainer
#219 lore raw
Quoted 30 lines · Guenter Roeck
Quoted 29 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Build results:

    total: 125 pass: 123 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

    total: 30 pass: 28 fail: 2

Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

Error log:

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,' [ and so on ]

Quoted 5 lines
Quoted 3 lines

Similar to 3.19, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

Build and qemu test results for 4.0.x are now ok; no more failures.

Thanks, I've done a -rc2 just to be sure.

greg k-h

#220 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Quoted 7 lines

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
author maintainer
#221 lore raw
In reply to Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

-rc2 is out that should not have any issues:

kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

#222 lore raw

Hi

Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

Review

Quoted 3 lines
(quoted diff) +0 -1
-rc2 is out that should not have any issues:
 
 	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

^^^^

Please change your script to use

kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc2.gz

	                            ^^^^

instead. As reported before, there is no v4.0/ directory (symlink), while using v3.x/ is safe either way.

Regards
Stefan Lippers-Hollmann

author maintainer
#223 lore raw
Quoted 19 lines · Stefan Lippers-Hollmann

Hi

Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

Review

Quoted 3 lines
(quoted diff) +0 -1
-rc2 is out that should not have any issues:
 
 	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz
Quoted 8 lines

^^^^

Please change your script to use

   	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc2.gz
	                            ^^^^

instead. As reported before, there is no v4.0/ directory (symlink), while using v3.x/ is safe either way.

The script has this in it, I did this email "by hand" and forgot it, sorry.

greg k-h

#224 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

Quoted 7 lines
Quoted 3 lines

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

-rc2 is out that should not have any issues:

kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

Build results:

	total: 125 pass: 125 fail: 0
Qemu test results:
	total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

author maintainer
#225 lore raw
Quoted 16 lines · Guenter Roeck
Quoted 15 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

-rc2 is out that should not have any issues:

Quoted 8 lines
Quoted 1 line

kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

Build results:

	total: 125 pass: 125 fail: 0
Qemu test results:
	total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing all 4 of these and letting me know.

greg k-h

#226 lore raw
In reply to Greg Kroah-Hartman
Quoted 14 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

Review

Quoted 3 lines
(quoted diff) +0 -1
-rc2 is out that should not have any issues:
 
 	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

rc2 is good. Compiled and booted. No dmesg regressions.

-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
author maintainer
#227 lore raw
Quoted 14 lines · Shuah Khan
Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.2 release. There are 220 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 Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz

and the diffstat can be found below.

Quoted 6 lines

Review

Quoted 4 lines
(quoted diff) +0 -1
-rc2 is out that should not have any issues:
 
 	kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz

rc2 is good. Compiled and booted. No dmesg regressions.

Thanks for testing all 4 of these and letting me know.

greg k-h