4.0.2-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 160/220 xtensa: ISS: fix locking in TAP network adapter
In reply to Greg Kroah-Hartman4.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_devicstruct 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_devicwhile ((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_devicmod_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_deif (!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
Greg Kroah-Hartman
maintainerPATCH 161/220 gpio: mvebu: Fix mask/unmask managment per irq chip type
In reply to Greg Kroah-Hartman4.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); }
Greg Kroah-Hartman
maintainerPATCH 162/220 clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC
In reply to Greg Kroah-Hartman4.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
--- 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(strusamsung_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);
Greg Kroah-Hartman
maintainerPATCH 163/220 clk: tegra: Register the proper number of resets
In reply to Greg Kroah-Hartman4.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.
--- 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(structof_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); }
Greg Kroah-Hartman
maintainerPATCH 164/220 clk: tegra: Use the proper parent for plld_dsi
In reply to Greg Kroah-Hartman4.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.
--- 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 */
Greg Kroah-Hartman
maintainerPATCH 165/220 clk: qcom: Fix i2c frequency table
In reply to Greg Kroah-Hartman4.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.
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 }, { }
Greg Kroah-Hartman
maintainerPATCH 166/220 clk: qcom: Properly change rates for ahbix clock
In reply to Greg Kroah-Hartman4.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.
--- 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(strucreturn __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, }, }, };
Greg Kroah-Hartman
maintainerPATCH 167/220 clk: qcom: fix RCG M/N counter configuration
In reply to Greg Kroah-Hartman4.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.
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);
Greg Kroah-Hartman
maintainerPATCH 168/220 clk: qcom: Fix ipq806x LCC frequency tables
In reply to Greg Kroah-Hartman4.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.
--- 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 }, { }, };
Greg Kroah-Hartman
maintainerPATCH 169/220 dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Greg Kroah-Hartman4.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_coswitch (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 crcrypt_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)
Greg Kroah-Hartman
maintainerPATCH 170/220 serial: 8250_dw: add support for AMD SOC Carrizo
In reply to Greg Kroah-Hartman4.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);
Greg Kroah-Hartman
maintainerPATCH 172/220 serial: 8250: Check UART_SCR is writable
In reply to Greg Kroah-Hartman4.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.
--- 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);
Greg Kroah-Hartman
maintainerPATCH 173/220 sd: Unregister integrity profile
In reply to Greg Kroah-Hartman4.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 devida_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);
Greg Kroah-Hartman
maintainerPATCH 174/220 sd: Fix missing ATO tag check
In reply to Greg Kroah-Hartman4.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 )
Greg Kroah-Hartman
maintainerPATCH 175/220 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
In reply to Greg Kroah-Hartman4.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 *newif (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));
Greg Kroah-Hartman
maintainerPATCH 176/220 mvsas: fix panic on expander attached SATA devices
In reply to Greg Kroah-Hartman4.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_tastatic 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);
Greg Kroah-Hartman
maintainerPATCH 177/220 rc: img-ir: fix error in parameters passed to irq_free()
In reply to Greg Kroah-Hartman4.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 ...
--- 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);
Greg Kroah-Hartman
maintainerPATCH 178/220 stk1160: Make sure current buffer is released
In reply to Greg Kroah-Hartman4.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(structif (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 stk1160stk1160_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); }
Greg Kroah-Hartman
maintainerPATCH 179/220 IB/core: disallow registering 0-sized memory region
In reply to Greg Kroah-Hartman4.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_ucif (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.
Greg Kroah-Hartman
maintainerPATCH 180/220 IB/core: dont disallow registering region starting at 0x0
In reply to Greg Kroah-Hartman4.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 ())
Greg Kroah-Hartman
maintainerPATCH 181/220 IB/mlx4: Fix WQE LSO segment calculation
In reply to Greg Kroah-Hartman4.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.
--- 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_wqememcpy (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 ; }
Greg Kroah-Hartman
maintainerPATCH 182/220 IB/iser: Fix wrong calculation of protection buffer length
In reply to Greg Kroah-Hartman4.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.
--- 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_connif (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 ) {
Greg Kroah-Hartman
maintainerPATCH 183/220 tracing: Handle ftrace_dump() atomic context in graph_trace_open()
In reply to Greg Kroah-Hartman4.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;
Greg Kroah-Hartman
maintainerPATCH 184/220 tracing: Fix incorrect enabling of trace events by boot cmdline
In reply to Greg Kroah-Hartman4.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.
--- 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(structstatic 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; }/**
Greg Kroah-Hartman
maintainerPATCH 185/220 i2c: mux: use proper dev when removing "channel-X" symlinks
In reply to Greg Kroah-Hartman4.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_adapchar 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);
Greg Kroah-Hartman
maintainerPATCH 186/220 i2c: rk3x: report number of messages transmitted
In reply to Greg Kroah-Hartman4.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_adapclk_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)
Greg Kroah-Hartman
maintainerPATCH 187/220 i2c: Mark adapter devices with pm_runtime_no_callbacks
In reply to Greg Kroah-Hartman4.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 idev_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);
Greg Kroah-Hartman
maintainerPATCH 188/220 i2c: core: Export bus recovery functions
In reply to Greg Kroah-Hartman4.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.
--- 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 i2creturn 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) {
Greg Kroah-Hartman
maintainerPATCH 189/220 drm/radeon: fix doublescan modes (v2)
In reply to Greg Kroah-Hartman4.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;
Greg Kroah-Hartman
maintainerPATCH 191/220 drm/i915: Dont enable CS_PARSER_ERROR interrupts at all
In reply to Greg Kroah-Hartman4.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 dI915_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)) {
Greg Kroah-Hartman
maintainerPATCH 192/220 drm: adv7511: Fix DDC error interrupt handling
In reply to Greg Kroah-Hartman4.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 );/*
Greg Kroah-Hartman
maintainerPATCH 193/220 drm: adv7511: Fix nested sleep when reading EDID
In reply to Greg Kroah-Hartman4.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 */
Greg Kroah-Hartman
maintainerPATCH 194/220 drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
In reply to Greg Kroah-Hartman4.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_stateI915_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);
Greg Kroah-Hartman
maintainerPATCH 195/220 drm/i915: cope with large i2c transfers
In reply to Greg Kroah-Hartman4.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
Greg Kroah-Hartman
maintainerPATCH 196/220 RCU pathwalk breakage when running into a symlink overmounting something
In reply to Greg Kroah-Hartman4.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(structif (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; }
Greg Kroah-Hartman
maintainerPATCH 197/220 Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one"
In reply to Greg Kroah-Hartman4.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).
--- 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, strudprintk ("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 pageint 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 );
Greg Kroah-Hartman
maintainerPATCH 198/220 nfsd4: disallow ALLOCATE with special stateids
In reply to Greg Kroah-Hartman4.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.)
--- 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,
Greg Kroah-Hartman
maintainerPATCH 199/220 nfsd4: fix READ permission checking
In reply to Greg Kroah-Hartman4.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.
--- 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_compoundrunsigned 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);
Greg Kroah-Hartman
maintainerPATCH 200/220 nfsd4: disallow SEEK with special stateids
In reply to Greg Kroah-Hartman4.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.
--- 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, strucdprintk ("NFSD: nfsd4_seek: couldn't process stateid!\n" );return status; } +if (!file) +return nfserr_bad_stateid;switch (seek->seek_whence) {case NFS4_CONTENT_DATA :
Greg Kroah-Hartman
maintainerPATCH 201/220 nfsd: eliminate NFSD_DEBUG
In reply to Greg Kroah-Hartman4.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.
--- 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 *sereturn 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
Greg Kroah-Hartman
maintainerPATCH 202/220 nfsd: fix nsfd startup race triggering BUG_ON
In reply to Greg Kroah-Hartman4.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 0040f809kernel: ---[ 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]>" );
Greg Kroah-Hartman
maintainerPATCH 204/220 nfs: fix DIO good bytes calculation
In reply to Greg Kroah-Hartman4.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; + } }/*
Greg Kroah-Hartman
maintainerPATCH 205/220 nfs: remove WARN_ON_ONCE from nfs_direct_good_bytes
In reply to Greg Kroah-Hartman4.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;
Greg Kroah-Hartman
maintainerPATCH 206/220 NFS: Add a stub for GETDEVICELIST
In reply to Greg Kroah-Hartman4.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.
--- 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),
Greg Kroah-Hartman
maintainerPATCH 207/220 sched/deadline: Always enqueue on previous rq when dl_task_timer() fires
In reply to Greg Kroah-Hartman4.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_timeunsigned 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_timepush_dl_task (rq);#endif unlock: -task_rq_unlock (rq, current, &flags); +task_rq_unlock (rq, p, &flags);return HRTIMER_NORESTART ; }
Greg Kroah-Hartman
maintainerPATCH 208/220 e1000: add dummy allocator to fix race condition between mtu change and netpoll
In reply to Greg Kroah-Hartman4.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_ringThen, 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_fragAnd when we come back to do the rest of the MTU change:
e1000_up -> e1000_configure -> e1000_configure_rx ->
e1000_alloc_jumbo_rx_buffersalloc_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.
--- 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 e1static 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_dmsleep (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
Greg Kroah-Hartman
maintainerPATCH 209/220 mac80211: send AP probe as unicast again
In reply to Greg Kroah-Hartman4.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.
--- 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);
Greg Kroah-Hartman
maintainerPATCH 210/220 ebpf: verifier: check that call reg with ARG_ANYTHING is initialized
In reply to Greg Kroah-Hartman4.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.
--- 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 verifieenum 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 verifiereturn -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 ;
Greg Kroah-Hartman
maintainerPATCH 211/220 mm, thp: really limit transparent hugepage allocation to local node
In reply to Greg Kroah-Hartman4.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.
--- 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; } }
Greg Kroah-Hartman
maintainerPATCH 212/220 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
In reply to Greg Kroah-Hartman4.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/
--- 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);
Greg Kroah-Hartman
maintainerPATCH 213/220 wl18xx: show rx_frames_per_rates as an array as it really is
In reply to Greg Kroah-Hartman4.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 *'".
--- 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, pWL18XX_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);
Greg Kroah-Hartman
maintainerPATCH 214/220 crypto: omap-aes - Fix support for unequal lengths
In reply to Greg Kroah-Hartman4.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.
--- 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(strucreturn 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 ;
Greg Kroah-Hartman
maintainerPATCH 215/220 C6x: time: Ensure consistency in __init
In reply to Greg Kroah-Hartman4.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.
--- 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 ;
Greg Kroah-Hartman
maintainerPATCH 216/220 memstick: mspro_block: add missing curly braces
In reply to Greg Kroah-Hartman4.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.
--- 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(struif (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);
Greg Kroah-Hartman
maintainerPATCH 217/220 drivers: platform: parse IRQ flags from resources
In reply to Greg Kroah-Hartman4.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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 218/220 driver core: bus: Goto appropriate labels on failure in bus_add_device
In reply to Greg Kroah-Hartman4.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.
--- 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)
Greg Kroah-Hartman
maintainerPATCH 219/220 netfilter: x_tables: fix cgroup matching on non-full sks
In reply to Greg Kroah-Hartman4.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.
--- 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;
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
afb7718016fcb0370ac29a83b2839c78b76c2960upstream.While originally only being intended for outgoing traffic, commit
a00e76349f35("netfilter:x_tables: allow to use cgroup match forLOCAL_INnf hooks") enabledxt_cgroupsfor theNF_INET_LOCAL_INhook as well, in order to allow for nfacct accounting.
Quoted 7 lines
Besides being currently limited to early demuxes only, commit
a00e76349f35forgot 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 ask_classidmember; probing forsk_classidmember 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
Greg Kroah-Hartman
maintainerRe: [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
afb7718016fcb0370ac29a83b2839c78b76c2960upstream.While originally only being intended for outgoing traffic, commit
a00e76349f35("netfilter:x_tables: allow to use cgroup match forLOCAL_INnf hooks") enabledxt_cgroupsfor theNF_INET_LOCAL_INhook as well, in order to allow for nfacct accounting.Quoted 7 lines
Besides being currently limited to early demuxes only, commit
a00e76349f35forgot 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 ask_classidmember; probing forsk_classidmember 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
Greg Kroah-Hartman
maintainerPATCH 220/220 netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING
In reply to Greg Kroah-Hartman4.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.
--- 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 sstruct 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 ;
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
Greg Kroah-Hartman
maintainerQuoted 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
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
Greg Kroah-Hartman
maintainerQuoted 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: 2Failed builds:
powerpc:defconfig
powerpc:allmodconfigQemu test results:
total: 30 pass: 28 fail: 2Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfigError 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: Includelinux/jump_label.hto getHAVE_JUMP_LABELdefine'.
The powerpc patch is now removed.
greg k-h
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: 2Failed builds:
powerpc:defconfig
powerpc:allmodconfigQemu test results:
total: 30 pass: 28 fail: 2Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfigError 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: Includelinux/jump_label.hto getHAVE_JUMP_LABELdefine'.
Build and qemu test results for 4.0.x are now ok; no more failures.
Guenter
Greg Kroah-Hartman
maintainerQuoted 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: 2Failed builds:
powerpc:defconfig
powerpc:allmodconfigQemu test results:
total: 30 pass: 28 fail: 2Failed tests:
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfigError 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: Includelinux/jump_label.hto getHAVE_JUMP_LABELdefine'.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
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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: 0Details are available at http://server.roeck-us.net:8010/builders.
Thanks for testing all 4 of these and letting me know.
greg k-h
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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.gzrc2 is good. Compiled and booted. No dmesg regressions.
Thanks for testing all 4 of these and letting me know.
greg k-h