[PATCH 3.16 010/294] net: bcmgenet: fix off-by-one in incrementing read pointer

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Florian Fainelli 

commit cf377d886f7944a5ccdbd164b89949e13617b096 upstream.

Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
harder for out of memory conditions") moved the increment of the local
read pointer *before* reading from the hardware descriptor using
dmadesc_get_length_status(), which creates an off-by-one situation.

Fix this by moving again the read_ptr increment after we have read the
hardware descriptor to get both the control block and the read pointer
back in sync.

Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
Signed-off-by: Jaedon Shin 
Signed-off-by: Florian Fainelli 
Acked-by: Petri Gynther 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1354,11 +1354,6 @@ static unsigned int bcmgenet_desc_rx(str
cb = >rx_cbs[priv->rx_read_ptr];
skb = cb->skb;
 
-   rxpktprocessed++;
-
-   priv->rx_read_ptr++;
-   priv->rx_read_ptr &= (priv->num_rx_bds - 1);
-
/* We do not have a backing SKB, so we do not have a
 * corresponding DMA mapping for this incoming packet since
 * bcmgenet_rx_refill always either has both skb and mapping or
@@ -1471,6 +1466,10 @@ refill:
err = bcmgenet_rx_refill(priv, cb);
if (err)
netif_err(priv, rx_err, dev, "Rx refill failed\n");
+
+   rxpktprocessed++;
+   priv->rx_read_ptr++;
+   priv->rx_read_ptr &= (priv->num_rx_bds - 1);
}
 
return rxpktprocessed;

[PATCH 3.16 229/294] tty: nozomi: avoid a harmless gcc warning

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit a4f642a8a3c2838ad09fe8313d45db46600e1478 upstream.

The nozomi wireless data driver has its own helper function to
transfer data from a FIFO, doing an extra byte swap on big-endian
architectures, presumably to bring the data back into byte-serial
order after readw() or readl() perform their implicit byteswap.

This helper function is used in the receive_data() function to
first read the length into a 32-bit variable, which causes
a compile-time warning:

drivers/tty/nozomi.c: In function 'receive_data':
drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this 
function [-Wmaybe-uninitialized]

The problem is that gcc is unsure whether the data was actually
read or not. We know that it is at this point, so we can replace
it with a single readl() to shut up that warning.

I am leaving the byteswap in there, to preserve the existing
behavior, even though this seems fishy: Reading the length of
the data into a cpu-endian variable should normally not use
a second byteswap on big-endian systems, unless the hardware
is aware of the CPU endianess.

There appears to be a lot more confusion about endianess in this
driver, so it probably has not worked on big-endian systems in
a long time, if ever, and I have no way to test it. It's well
possible that this driver has not been used by anyone in a while,
the last patch that looks like it was tested on the hardware is
from 2008.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/tty/nozomi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/nozomi.c
+++ b/drivers/tty/nozomi.c
@@ -823,7 +823,7 @@ static int receive_data(enum port_type i
struct tty_struct *tty = tty_port_tty_get(>port);
int i, ret;
 
-   read_mem32((u32 *) , addr, 4);
+   size = __le32_to_cpu(readl(addr));
/*  DBG1( "%d bytes port: %d", size, index); */
 
if (tty && test_bit(TTY_THROTTLED, >flags)) {

[PATCH 3.16 256/294] brcmfmac: avoid gcc-5.1 warning

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 22f44150aad7a1d6b074ab6cf59abee61c7187c6 upstream.

gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
driver:

drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 
'brcmf_fws_txs_process':
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may 
be used uninitialized in this function [-Wmaybe-uninitialized]

This is a false positive, and marking the brcmf_fws_hanger_poppkt function
as 'static inline' makes the warning go away. I have checked the object
file output and while a little code gets moved around, the size of
the binary remains identical.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
@@ -607,7 +607,7 @@ static int brcmf_fws_hanger_pushpkt(stru
return 0;
 }
 
-static int brcmf_fws_hanger_poppkt(struct brcmf_fws_hanger *h,
+static inline int brcmf_fws_hanger_poppkt(struct brcmf_fws_hanger *h,
  u32 slot_id, struct sk_buff **pktout,
  bool remove_item)
 {

[PATCH 3.16 256/294] brcmfmac: avoid gcc-5.1 warning

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 22f44150aad7a1d6b074ab6cf59abee61c7187c6 upstream.

gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
driver:

drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 
'brcmf_fws_txs_process':
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may 
be used uninitialized in this function [-Wmaybe-uninitialized]

This is a false positive, and marking the brcmf_fws_hanger_poppkt function
as 'static inline' makes the warning go away. I have checked the object
file output and while a little code gets moved around, the size of
the binary remains identical.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
@@ -607,7 +607,7 @@ static int brcmf_fws_hanger_pushpkt(stru
return 0;
 }
 
-static int brcmf_fws_hanger_poppkt(struct brcmf_fws_hanger *h,
+static inline int brcmf_fws_hanger_poppkt(struct brcmf_fws_hanger *h,
  u32 slot_id, struct sk_buff **pktout,
  bool remove_item)
 {

[PATCH 3.16 281/294] MIPS: MSP71xx: remove odd locking in PCI config space access code

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sergey Ryazanov 

commit c4a305374bbf36414515d2ae00d588c67051e67d upstream.

Caller (generic PCI code) already do proper locking so no need to add
another one here.

Signed-off-by: Sergey Ryazanov 
Cc: Linux MIPS 
Patchwork: https://patchwork.linux-mips.org/patch/7601/
Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 arch/mips/pci/ops-pmcmsp.c | 12 
 1 file changed, 12 deletions(-)

--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -193,8 +193,6 @@ static void pci_proc_init(void)
 }
 #endif /* CONFIG_PROC_FS && PCI_COUNTERS */
 
-static DEFINE_SPINLOCK(bpci_lock);
-
 /*
  *
  *  STRUCT: pci_io_resource
@@ -368,7 +366,6 @@ int msp_pcibios_config_access(unsigned c
struct msp_pci_regs *preg = (void *)PCI_BASE_REG;
unsigned char bus_num = bus->number;
unsigned char dev_fn = (unsigned char)devfn;
-   unsigned long flags;
unsigned long intr;
unsigned long value;
static char pciirqflag;
@@ -401,10 +398,7 @@ int msp_pcibios_config_access(unsigned c
}
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
-   local_irq_save(flags);
vpe_status = dvpe();
-#else
-   spin_lock_irqsave(_lock, flags);
 #endif
 
/*
@@ -457,9 +451,6 @@ int msp_pcibios_config_access(unsigned c
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
evpe(vpe_status);
-   local_irq_restore(flags);
-#else
-   spin_unlock_irqrestore(_lock, flags);
 #endif
 
return -1;
@@ -467,9 +458,6 @@ int msp_pcibios_config_access(unsigned c
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
evpe(vpe_status);
-   local_irq_restore(flags);
-#else
-   spin_unlock_irqrestore(_lock, flags);
 #endif
 
return PCIBIOS_SUCCESSFUL;

[PATCH 3.16 281/294] MIPS: MSP71xx: remove odd locking in PCI config space access code

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sergey Ryazanov 

commit c4a305374bbf36414515d2ae00d588c67051e67d upstream.

Caller (generic PCI code) already do proper locking so no need to add
another one here.

Signed-off-by: Sergey Ryazanov 
Cc: Linux MIPS 
Patchwork: https://patchwork.linux-mips.org/patch/7601/
Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 arch/mips/pci/ops-pmcmsp.c | 12 
 1 file changed, 12 deletions(-)

--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -193,8 +193,6 @@ static void pci_proc_init(void)
 }
 #endif /* CONFIG_PROC_FS && PCI_COUNTERS */
 
-static DEFINE_SPINLOCK(bpci_lock);
-
 /*
  *
  *  STRUCT: pci_io_resource
@@ -368,7 +366,6 @@ int msp_pcibios_config_access(unsigned c
struct msp_pci_regs *preg = (void *)PCI_BASE_REG;
unsigned char bus_num = bus->number;
unsigned char dev_fn = (unsigned char)devfn;
-   unsigned long flags;
unsigned long intr;
unsigned long value;
static char pciirqflag;
@@ -401,10 +398,7 @@ int msp_pcibios_config_access(unsigned c
}
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
-   local_irq_save(flags);
vpe_status = dvpe();
-#else
-   spin_lock_irqsave(_lock, flags);
 #endif
 
/*
@@ -457,9 +451,6 @@ int msp_pcibios_config_access(unsigned c
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
evpe(vpe_status);
-   local_irq_restore(flags);
-#else
-   spin_unlock_irqrestore(_lock, flags);
 #endif
 
return -1;
@@ -467,9 +458,6 @@ int msp_pcibios_config_access(unsigned c
 
 #if defined(CONFIG_PMC_MSP7120_GW) || defined(CONFIG_PMC_MSP7120_EVAL)
evpe(vpe_status);
-   local_irq_restore(flags);
-#else
-   spin_unlock_irqrestore(_lock, flags);
 #endif
 
return PCIBIOS_SUCCESSFUL;

[PATCH 3.16 223/294] ASoC: adau1977: Fix truncation warning on 64 bit architectures

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mark Brown 

commit d8df26bb57d2a86365de46a5421b97417401e39a upstream.

Negating ADAU1977_BLOCK_POWER_SAI_LDO_EN creates an unsigned long constant
with all bits set which on 64 bit architectures needs to be truncated to
an unsigned int, generating a warning. Add an explicit cast since we know
this is OK.

Signed-off-by: Mark Brown 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 sound/soc/codecs/adau1977.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/adau1977.c
+++ b/sound/soc/codecs/adau1977.c
@@ -968,7 +968,7 @@ int adau1977_probe(struct device *dev, s
if (adau1977->dvdd_reg)
power_off_mask = ~0;
else
-   power_off_mask = ~ADAU1977_BLOCK_POWER_SAI_LDO_EN;
+   power_off_mask = (unsigned int)~ADAU1977_BLOCK_POWER_SAI_LDO_EN;
 
ret = regmap_update_bits(adau1977->regmap, ADAU1977_REG_BLOCK_POWER_SAI,
power_off_mask, 0x00);

[PATCH 3.16 223/294] ASoC: adau1977: Fix truncation warning on 64 bit architectures

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mark Brown 

commit d8df26bb57d2a86365de46a5421b97417401e39a upstream.

Negating ADAU1977_BLOCK_POWER_SAI_LDO_EN creates an unsigned long constant
with all bits set which on 64 bit architectures needs to be truncated to
an unsigned int, generating a warning. Add an explicit cast since we know
this is OK.

Signed-off-by: Mark Brown 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 sound/soc/codecs/adau1977.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/adau1977.c
+++ b/sound/soc/codecs/adau1977.c
@@ -968,7 +968,7 @@ int adau1977_probe(struct device *dev, s
if (adau1977->dvdd_reg)
power_off_mask = ~0;
else
-   power_off_mask = ~ADAU1977_BLOCK_POWER_SAI_LDO_EN;
+   power_off_mask = (unsigned int)~ADAU1977_BLOCK_POWER_SAI_LDO_EN;
 
ret = regmap_update_bits(adau1977->regmap, ADAU1977_REG_BLOCK_POWER_SAI,
power_off_mask, 0x00);

[PATCH 3.16 225/294] clk/efm32gg: fix dt init prototype

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Uwe Kleine-König 

commit 8ce8ebeb572d70e672a8d158e93ffaac80ea7576 upstream.

Since commit 54196ccbe0ba (of: consolidate linker section OF match table
declarations) which went into 3.16-rc1 the following compiler warning is
generated:

In file included from drivers/clk/clk-efm32gg.c:12:0: 
include/linux/of.h:772:20:
warning: comparison of distinct pointer types lacks a cast [enabled by 
default]
.data = (fn == (fn_type)NULL) ? fn : fn  }
^
include/linux/of.h:785:3: note: in expansion of macro '_OF_DECLARE'
   _OF_DECLARE(table, name, compat, fn, of_init_fn_1)
   ^
include/linux/clk-provider.h:545:42: note: in expansion of macro 
'OF_DECLARE_1'
 #define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, 
compat, fn)
  ^
drivers/clk/clk-efm32gg.c:81:1: note: in expansion of macro 
'CLK_OF_DECLARE'
 CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);
 ^

Fix it by making efm32gg_cmu_init return void.

Cc: Rob Herring 
Reported-by: Bryan Hundven 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Mike Turquette 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 drivers/clk/clk-efm32gg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/clk/clk-efm32gg.c
+++ b/drivers/clk/clk-efm32gg.c
@@ -22,7 +22,7 @@ static struct clk_onecell_data clk_data
.clk_num = ARRAY_SIZE(clk),
 };
 
-static int __init efm32gg_cmu_init(struct device_node *np)
+static void __init efm32gg_cmu_init(struct device_node *np)
 {
int i;
void __iomem *base;
@@ -33,7 +33,7 @@ static int __init efm32gg_cmu_init(struc
base = of_iomap(np, 0);
if (!base) {
pr_warn("Failed to map address range for efm32gg,cmu node\n");
-   return -EADDRNOTAVAIL;
+   return;
}
 
clk[clk_HFXO] = clk_register_fixed_rate(NULL, "HFXO", NULL,
@@ -76,6 +76,6 @@ static int __init efm32gg_cmu_init(struc
clk[clk_HFPERCLKDAC0] = clk_register_gate(NULL, "HFPERCLK.DAC0",
"HFXO", 0, base + CMU_HFPERCLKEN0, 17, 0, NULL);
 
-   return of_clk_add_provider(np, of_clk_src_onecell_get, _data);
+   of_clk_add_provider(np, of_clk_src_onecell_get, _data);
 }
 CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);

[PATCH 3.16 225/294] clk/efm32gg: fix dt init prototype

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Uwe Kleine-König 

commit 8ce8ebeb572d70e672a8d158e93ffaac80ea7576 upstream.

Since commit 54196ccbe0ba (of: consolidate linker section OF match table
declarations) which went into 3.16-rc1 the following compiler warning is
generated:

In file included from drivers/clk/clk-efm32gg.c:12:0: 
include/linux/of.h:772:20:
warning: comparison of distinct pointer types lacks a cast [enabled by 
default]
.data = (fn == (fn_type)NULL) ? fn : fn  }
^
include/linux/of.h:785:3: note: in expansion of macro '_OF_DECLARE'
   _OF_DECLARE(table, name, compat, fn, of_init_fn_1)
   ^
include/linux/clk-provider.h:545:42: note: in expansion of macro 
'OF_DECLARE_1'
 #define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, 
compat, fn)
  ^
drivers/clk/clk-efm32gg.c:81:1: note: in expansion of macro 
'CLK_OF_DECLARE'
 CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);
 ^

Fix it by making efm32gg_cmu_init return void.

Cc: Rob Herring 
Reported-by: Bryan Hundven 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Mike Turquette 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 drivers/clk/clk-efm32gg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/clk/clk-efm32gg.c
+++ b/drivers/clk/clk-efm32gg.c
@@ -22,7 +22,7 @@ static struct clk_onecell_data clk_data
.clk_num = ARRAY_SIZE(clk),
 };
 
-static int __init efm32gg_cmu_init(struct device_node *np)
+static void __init efm32gg_cmu_init(struct device_node *np)
 {
int i;
void __iomem *base;
@@ -33,7 +33,7 @@ static int __init efm32gg_cmu_init(struc
base = of_iomap(np, 0);
if (!base) {
pr_warn("Failed to map address range for efm32gg,cmu node\n");
-   return -EADDRNOTAVAIL;
+   return;
}
 
clk[clk_HFXO] = clk_register_fixed_rate(NULL, "HFXO", NULL,
@@ -76,6 +76,6 @@ static int __init efm32gg_cmu_init(struc
clk[clk_HFPERCLKDAC0] = clk_register_gate(NULL, "HFPERCLK.DAC0",
"HFXO", 0, base + CMU_HFPERCLKEN0, 17, 0, NULL);
 
-   return of_clk_add_provider(np, of_clk_src_onecell_get, _data);
+   of_clk_add_provider(np, of_clk_src_onecell_get, _data);
 }
 CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);

[PATCH 3.16 278/294] MIPS: DEC: Avoid la pseudo-instruction in delay slots

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ralf Baechle 

commit 3021773c7c3e75e20b693931a19362681e744ea9 upstream.

When expanding the la or dla pseudo-instruction in a delay slot the GNU
assembler will complain should the pseudo-instruction expand to multiple
actual instructions, since only the first of them will be in the delay
slot leading to the pseudo-instruction being only partially executed if
the branch is taken. Use of PTR_LA in the dec int-handler.S leads to
such warnings:

  arch/mips/dec/int-handler.S: Assembler messages:
  arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into 
multiple instructions in a branch delay slot
  arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into 
multiple instructions in a branch delay slot

Avoid this by open coding the PTR_LA macros.

Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 arch/mips/dec/int-handler.S | 40 ++--
 1 file changed, 38 insertions(+), 2 deletions(-)

--- a/arch/mips/dec/int-handler.S
+++ b/arch/mips/dec/int-handler.S
@@ -146,7 +146,25 @@
/*
 * Find irq with highest priority
 */
-PTR_LA t1,cpu_mask_nr_tbl
+   # open coded PTR_LA t1, cpu_mask_nr_tbl
+#if (_MIPS_SZPTR == 32)
+   # open coded la t1, cpu_mask_nr_tbl
+   lui t1, %hi(cpu_mask_nr_tbl)
+   addiu   t1, %lo(cpu_mask_nr_tbl)
+
+#endif
+#if (_MIPS_SZPTR == 64)
+   # open coded dla t1, cpu_mask_nr_tbl
+   .setpush
+   .setnoat
+   lui t1, %highest(cpu_mask_nr_tbl)
+   lui AT, %hi(cpu_mask_nr_tbl)
+   daddiu  t1, t1, %higher(cpu_mask_nr_tbl)
+   daddiu  AT, AT, %lo(cpu_mask_nr_tbl)
+   dsllt1, 32
+   daddu   t1, t1, AT
+   .setpop
+#endif
 1: lw  t2,(t1)
nop
and t2,t0
@@ -195,7 +213,25 @@
/*
 * Find irq with highest priority
 */
-PTR_LA t1,asic_mask_nr_tbl
+   # open coded PTR_LA t1,asic_mask_nr_tbl
+#if (_MIPS_SZPTR == 32)
+   # open coded la t1, asic_mask_nr_tbl
+   lui t1, %hi(asic_mask_nr_tbl)
+   addiu   t1, %lo(asic_mask_nr_tbl)
+
+#endif
+#if (_MIPS_SZPTR == 64)
+   # open coded dla t1, asic_mask_nr_tbl
+   .setpush
+   .setnoat
+   lui t1, %highest(asic_mask_nr_tbl)
+   lui AT, %hi(asic_mask_nr_tbl)
+   daddiu  t1, t1, %higher(asic_mask_nr_tbl)
+   daddiu  AT, AT, %lo(asic_mask_nr_tbl)
+   dsllt1, 32
+   daddu   t1, t1, AT
+   .setpop
+#endif
 2: lw  t2,(t1)
nop
and t2,t0

[PATCH 3.16 278/294] MIPS: DEC: Avoid la pseudo-instruction in delay slots

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ralf Baechle 

commit 3021773c7c3e75e20b693931a19362681e744ea9 upstream.

When expanding the la or dla pseudo-instruction in a delay slot the GNU
assembler will complain should the pseudo-instruction expand to multiple
actual instructions, since only the first of them will be in the delay
slot leading to the pseudo-instruction being only partially executed if
the branch is taken. Use of PTR_LA in the dec int-handler.S leads to
such warnings:

  arch/mips/dec/int-handler.S: Assembler messages:
  arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into 
multiple instructions in a branch delay slot
  arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into 
multiple instructions in a branch delay slot

Avoid this by open coding the PTR_LA macros.

Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 arch/mips/dec/int-handler.S | 40 ++--
 1 file changed, 38 insertions(+), 2 deletions(-)

--- a/arch/mips/dec/int-handler.S
+++ b/arch/mips/dec/int-handler.S
@@ -146,7 +146,25 @@
/*
 * Find irq with highest priority
 */
-PTR_LA t1,cpu_mask_nr_tbl
+   # open coded PTR_LA t1, cpu_mask_nr_tbl
+#if (_MIPS_SZPTR == 32)
+   # open coded la t1, cpu_mask_nr_tbl
+   lui t1, %hi(cpu_mask_nr_tbl)
+   addiu   t1, %lo(cpu_mask_nr_tbl)
+
+#endif
+#if (_MIPS_SZPTR == 64)
+   # open coded dla t1, cpu_mask_nr_tbl
+   .setpush
+   .setnoat
+   lui t1, %highest(cpu_mask_nr_tbl)
+   lui AT, %hi(cpu_mask_nr_tbl)
+   daddiu  t1, t1, %higher(cpu_mask_nr_tbl)
+   daddiu  AT, AT, %lo(cpu_mask_nr_tbl)
+   dsllt1, 32
+   daddu   t1, t1, AT
+   .setpop
+#endif
 1: lw  t2,(t1)
nop
and t2,t0
@@ -195,7 +213,25 @@
/*
 * Find irq with highest priority
 */
-PTR_LA t1,asic_mask_nr_tbl
+   # open coded PTR_LA t1,asic_mask_nr_tbl
+#if (_MIPS_SZPTR == 32)
+   # open coded la t1, asic_mask_nr_tbl
+   lui t1, %hi(asic_mask_nr_tbl)
+   addiu   t1, %lo(asic_mask_nr_tbl)
+
+#endif
+#if (_MIPS_SZPTR == 64)
+   # open coded dla t1, asic_mask_nr_tbl
+   .setpush
+   .setnoat
+   lui t1, %highest(asic_mask_nr_tbl)
+   lui AT, %hi(asic_mask_nr_tbl)
+   daddiu  t1, t1, %higher(asic_mask_nr_tbl)
+   daddiu  AT, AT, %lo(asic_mask_nr_tbl)
+   dsllt1, 32
+   daddu   t1, t1, AT
+   .setpop
+#endif
 2: lw  t2,(t1)
nop
and t2,t0

[PATCH 3.16 280/294] MIPS: ip22: Fix ip28 build for modern gcc

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 23ca9b522383d3b9b7991d8586db30118992af4a upstream.

kernelci reports a failure of the ip28_defconfig build after upgrading its
gcc version:

arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option 
-mr10k-cache-barrier=store.  Stop.

The problem apparently is that the -mr10k-cache-barrier=store option is now
rejected for CPUs other than r10k. Explicitly including the CPU in the
check fixes this and is safe because both options were introduced in
gcc-4.4.

Signed-off-by: Arnd Bergmann 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15049/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
---
 arch/mips/sgi-ip22/Platform | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/sgi-ip22/Platform
+++ b/arch/mips/sgi-ip22/Platform
@@ -25,7 +25,7 @@ endif
 # Simplified: what IP22 does at 128MB+ in ksegN, IP28 does at 512MB+ in xkphys
 #
 ifdef CONFIG_SGI_IP28
-  ifeq ($(call cc-option-yn,-mr10k-cache-barrier=store), n)
+  ifeq ($(call cc-option-yn,-march=r1 -mr10k-cache-barrier=store), n)
   $(error gcc doesn't support needed option -mr10k-cache-barrier=store)
   endif
 endif

[PATCH 3.16 280/294] MIPS: ip22: Fix ip28 build for modern gcc

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 23ca9b522383d3b9b7991d8586db30118992af4a upstream.

kernelci reports a failure of the ip28_defconfig build after upgrading its
gcc version:

arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option 
-mr10k-cache-barrier=store.  Stop.

The problem apparently is that the -mr10k-cache-barrier=store option is now
rejected for CPUs other than r10k. Explicitly including the CPU in the
check fixes this and is safe because both options were introduced in
gcc-4.4.

Signed-off-by: Arnd Bergmann 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15049/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
---
 arch/mips/sgi-ip22/Platform | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/sgi-ip22/Platform
+++ b/arch/mips/sgi-ip22/Platform
@@ -25,7 +25,7 @@ endif
 # Simplified: what IP22 does at 128MB+ in ksegN, IP28 does at 512MB+ in xkphys
 #
 ifdef CONFIG_SGI_IP28
-  ifeq ($(call cc-option-yn,-mr10k-cache-barrier=store), n)
+  ifeq ($(call cc-option-yn,-march=r1 -mr10k-cache-barrier=store), n)
   $(error gcc doesn't support needed option -mr10k-cache-barrier=store)
   endif
 endif

[PATCH 3.16 226/294] spi: rspi: Remove unused variable in rspi_rz_transfer_one()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Geert Uytterhoeven 

commit 95029a00886f0c8d79e700cb8983b881c75af0f1 upstream.

Introduced by commit 8b983e90ea1a3dd82070f96c062ad521a06b7cc0 ("spi: rspi:
Extract rspi_common_transfer()"), which removed its users.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 drivers/spi/spi-rspi.c | 1 -
 1 file changed, 1 deletion(-)

--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -630,7 +630,6 @@ static int rspi_rz_transfer_one(struct s
struct spi_transfer *xfer)
 {
struct rspi_data *rspi = spi_master_get_devdata(master);
-   int ret;
 
rspi_rz_receive_init(rspi);
 

[PATCH 3.16 226/294] spi: rspi: Remove unused variable in rspi_rz_transfer_one()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Geert Uytterhoeven 

commit 95029a00886f0c8d79e700cb8983b881c75af0f1 upstream.

Introduced by commit 8b983e90ea1a3dd82070f96c062ad521a06b7cc0 ("spi: rspi:
Extract rspi_common_transfer()"), which removed its users.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings 
---
 drivers/spi/spi-rspi.c | 1 -
 1 file changed, 1 deletion(-)

--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -630,7 +630,6 @@ static int rspi_rz_transfer_one(struct s
struct spi_transfer *xfer)
 {
struct rspi_data *rspi = spi_master_get_devdata(master);
-   int ret;
 
rspi_rz_receive_init(rspi);
 

[PATCH 3.16 019/294] USB: serial: cp210x: add support for Qivicon USB ZigBee dongle

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Stefan Triller 

commit 9585e340db9f6cc1c0928d82c3a23cc4460f0a3f upstream.

The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
for their SmartHome Home Base in its 1. Generation. The productId is not
known by the according kernel module, this patch adds support for it.

Signed-off-by: Stefan Triller 
Reviewed-by: Frans Klaver 
Signed-off-by: Johan Hovold 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -135,6 +135,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0x8A5E) }, /* CEL EM3588 ZigBee USB Stick Long 
Range */
+   { USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */

[PATCH 3.16 019/294] USB: serial: cp210x: add support for Qivicon USB ZigBee dongle

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Stefan Triller 

commit 9585e340db9f6cc1c0928d82c3a23cc4460f0a3f upstream.

The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
for their SmartHome Home Base in its 1. Generation. The productId is not
known by the according kernel module, this patch adds support for it.

Signed-off-by: Stefan Triller 
Reviewed-by: Frans Klaver 
Signed-off-by: Johan Hovold 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -135,6 +135,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0x8A5E) }, /* CEL EM3588 ZigBee USB Stick Long 
Range */
+   { USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */

[PATCH 3.16 082/294] drm/msm: Fix potential buffer overflow issue

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kasin Li 

commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.

In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.

Signed-off-by: Kasin Li 
Signed-off-by: Jordan Crouse 
Signed-off-by: Rob Clark 
[bwh: Backported to 3.16: submit_create() only supports a variable number of 
bos]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -34,10 +34,13 @@ static inline void __user *to_user_ptr(u
 }
 
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-   struct msm_gpu *gpu, int nr)
+   struct msm_gpu *gpu, uint32_t nr)
 {
struct msm_gem_submit *submit;
-   int sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+   uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+
+   if (sz > SIZE_MAX)
+   return NULL;
 
submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
if (submit) {

[PATCH 3.16 082/294] drm/msm: Fix potential buffer overflow issue

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kasin Li 

commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.

In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.

Signed-off-by: Kasin Li 
Signed-off-by: Jordan Crouse 
Signed-off-by: Rob Clark 
[bwh: Backported to 3.16: submit_create() only supports a variable number of 
bos]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -34,10 +34,13 @@ static inline void __user *to_user_ptr(u
 }
 
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-   struct msm_gpu *gpu, int nr)
+   struct msm_gpu *gpu, uint32_t nr)
 {
struct msm_gem_submit *submit;
-   int sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+   uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+
+   if (sz > SIZE_MAX)
+   return NULL;
 
submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
if (submit) {

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Mathieu Desnoyers]

- On Nov 6, 2017, at 7:37 PM, Nicholas Piggin npig...@gmail.com wrote:

> On Mon,  6 Nov 2017 15:56:40 -0500
> Mathieu Desnoyers  wrote:
> 
>> diff --git a/arch/powerpc/include/uapi/asm/unistd.h
>> b/arch/powerpc/include/uapi/asm/unistd.h
>> index b1980fcd56d5..972a7d68c143 100644
>> --- a/arch/powerpc/include/uapi/asm/unistd.h
>> +++ b/arch/powerpc/include/uapi/asm/unistd.h
>> @@ -396,5 +396,6 @@
>>  #define __NR_kexec_file_load382
>>  #define __NR_statx  383
>>  #define __NR_rseq   384
>> +#define __NR_cpu_opv385
> 
> Sorry for bike shedding, but could we invest a few more keystrokes to
> make these names a bit more readable?

Whenever I try to make variables or function names more explicit, I can
literally feel my consciousness (taking the form of an angry Peter Zijlstra)
breathing down my neck asking me to make them shorter. So I guess this is
where it becomes a question of taste.

I think the "rseq" syscall name is short, to the point, and should be mostly
fine.

For "cpu_opv", it was just a short name that fit the bill until a
better idea would come.

I'm open to suggestions. Any color preference ? ;-)

Thanks,

Mathieu


> 
> Thanks,
> Nick

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Mathieu Desnoyers]

- On Nov 6, 2017, at 7:37 PM, Nicholas Piggin npig...@gmail.com wrote:

> On Mon,  6 Nov 2017 15:56:40 -0500
> Mathieu Desnoyers  wrote:
> 
>> diff --git a/arch/powerpc/include/uapi/asm/unistd.h
>> b/arch/powerpc/include/uapi/asm/unistd.h
>> index b1980fcd56d5..972a7d68c143 100644
>> --- a/arch/powerpc/include/uapi/asm/unistd.h
>> +++ b/arch/powerpc/include/uapi/asm/unistd.h
>> @@ -396,5 +396,6 @@
>>  #define __NR_kexec_file_load382
>>  #define __NR_statx  383
>>  #define __NR_rseq   384
>> +#define __NR_cpu_opv385
> 
> Sorry for bike shedding, but could we invest a few more keystrokes to
> make these names a bit more readable?

Whenever I try to make variables or function names more explicit, I can
literally feel my consciousness (taking the form of an angry Peter Zijlstra)
breathing down my neck asking me to make them shorter. So I guess this is
where it becomes a question of taste.

I think the "rseq" syscall name is short, to the point, and should be mostly
fine.

For "cpu_opv", it was just a short name that fit the bill until a
better idea would come.

I'm open to suggestions. Any color preference ? ;-)

Thanks,

Mathieu


> 
> Thanks,
> Nick

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[PATCH 3.16 125/294] iio: imu: adis16480: Fix acceleration scale factor for adis16480

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dragos Bogdan 

commit fdd0d32eb95f135041236a6885d9006315aa9a1d upstream.

According to the datasheet, the range of the acceleration is [-10 g, + 10 g],
so the scale factor should be 10 instead of 5.

Signed-off-by: Dragos Bogdan 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings 
---
 drivers/iio/imu/adis16480.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/imu/adis16480.c
+++ b/drivers/iio/imu/adis16480.c
@@ -724,7 +724,7 @@ static const struct adis16480_chip_info
.gyro_max_val = IIO_RAD_TO_DEGREE(22500),
.gyro_max_scale = 450,
.accel_max_val = IIO_M_S_2_TO_G(12500),
-   .accel_max_scale = 5,
+   .accel_max_scale = 10,
},
[ADIS16485] = {
.channels = adis16485_channels,

[PATCH 3.16 125/294] iio: imu: adis16480: Fix acceleration scale factor for adis16480

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dragos Bogdan 

commit fdd0d32eb95f135041236a6885d9006315aa9a1d upstream.

According to the datasheet, the range of the acceleration is [-10 g, + 10 g],
so the scale factor should be 10 instead of 5.

Signed-off-by: Dragos Bogdan 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings 
---
 drivers/iio/imu/adis16480.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/imu/adis16480.c
+++ b/drivers/iio/imu/adis16480.c
@@ -724,7 +724,7 @@ static const struct adis16480_chip_info
.gyro_max_val = IIO_RAD_TO_DEGREE(22500),
.gyro_max_scale = 450,
.accel_max_val = IIO_M_S_2_TO_G(12500),
-   .accel_max_scale = 5,
+   .accel_max_scale = 10,
},
[ADIS16485] = {
.channels = adis16485_channels,

[PATCH 3.16 146/294] ipv6: add rcu grace period before freeing fib6_node

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Wang 

commit c5cff8561d2d0006e972bd114afd51f082fee77c upstream.

We currently keep rt->rt6i_node pointing to the fib6_node for the route.
And some functions make use of this pointer to dereference the fib6_node
from rt structure, e.g. rt6_check(). However, as there is neither
refcount nor rcu taken when dereferencing rt->rt6i_node, it could
potentially cause crashes as rt->rt6i_node could be set to NULL by other
CPUs when doing a route deletion.
This patch introduces an rcu grace period before freeing fib6_node and
makes sure the functions that dereference it takes rcu_read_lock().

Note: there is no "Fixes" tag because this bug was there in a very
early stage.

Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Acked-by: Martin KaFai Lau 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 include/net/ip6_fib.h | 30 +-
 net/ipv6/ip6_fib.c| 20 
 net/ipv6/route.c  | 14 +++---
 3 files changed, 56 insertions(+), 8 deletions(-)

--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -66,6 +66,7 @@ struct fib6_node {
__u16   fn_flags;
__u32   fn_sernum;
struct rt6_info *rr_ptr;
+   struct rcu_head rcu;
 };
 
 #ifndef CONFIG_IPV6_SUBTREES
@@ -193,9 +194,36 @@ static inline void rt6_set_from(struct r
rt->dst.from = new;
 }
 
+/* Function to safely get fn->sernum for passed in rt
+ * and store result in passed in cookie.
+ * Return true if we can get cookie safely
+ * Return false if not
+ */
+static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
+  u32 *cookie)
+{
+   struct fib6_node *fn;
+   bool status = false;
+
+   rcu_read_lock();
+   fn = rcu_dereference(rt->rt6i_node);
+
+   if (fn) {
+   *cookie = fn->fn_sernum;
+   status = true;
+   }
+
+   rcu_read_unlock();
+   return status;
+}
+
 static inline u32 rt6_get_cookie(const struct rt6_info *rt)
 {
-   return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
+   u32 cookie = 0;
+
+   rt6_get_cookie_safe(rt, );
+
+   return cookie;
 }
 
 static inline void ip6_rt_put(struct rt6_info *rt)
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -151,11 +151,23 @@ static __inline__ struct fib6_node *node
return fn;
 }
 
-static __inline__ void node_free(struct fib6_node *fn)
+static void node_free_immediate(struct fib6_node *fn)
 {
kmem_cache_free(fib6_node_kmem, fn);
 }
 
+static void node_free_rcu(struct rcu_head *head)
+{
+   struct fib6_node *fn = container_of(head, struct fib6_node, rcu);
+
+   kmem_cache_free(fib6_node_kmem, fn);
+}
+
+static void node_free(struct fib6_node *fn)
+{
+   call_rcu(>rcu, node_free_rcu);
+}
+
 static __inline__ void rt6_release(struct rt6_info *rt)
 {
if (atomic_dec_and_test(>rt6i_ref))
@@ -551,9 +563,9 @@ insert_above:
 
if (!in || !ln) {
if (in)
-   node_free(in);
+   node_free_immediate(in);
if (ln)
-   node_free(ln);
+   node_free_immediate(ln);
return ERR_PTR(-ENOMEM);
}
 
@@ -977,7 +989,7 @@ int fib6_add(struct fib6_node *root, str
   root, and then (in st_failure) stale node
   in main tree.
 */
-   node_free(sfn);
+   node_free_immediate(sfn);
err = PTR_ERR(sn);
goto st_failure;
}
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1090,6 +1090,7 @@ struct dst_entry *ip6_blackhole_route(st
 static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
 {
struct rt6_info *rt;
+   u32 rt_cookie;
 
rt = (struct rt6_info *) dst;
 
@@ -1097,7 +1098,7 @@ static struct dst_entry *ip6_dst_check(s
 * DST_OBSOLETE_FORCE_CHK which forces validation calls down
 * into this function always.
 */
-   if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
+   if (!rt6_get_cookie_safe(rt, _cookie) || rt_cookie != cookie)
return NULL;
 
if (rt6_check_expired(rt))
@@ -1136,8 +1137,14 @@ static void ip6_link_failure(struct sk_b
dst_hold(>dst);
if (ip6_del_rt(rt))
dst_free(>dst);
-   } else if (rt->rt6i_node && (rt->rt6i_flags & 

[PATCH 3.16 146/294] ipv6: add rcu grace period before freeing fib6_node

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Wang 

commit c5cff8561d2d0006e972bd114afd51f082fee77c upstream.

We currently keep rt->rt6i_node pointing to the fib6_node for the route.
And some functions make use of this pointer to dereference the fib6_node
from rt structure, e.g. rt6_check(). However, as there is neither
refcount nor rcu taken when dereferencing rt->rt6i_node, it could
potentially cause crashes as rt->rt6i_node could be set to NULL by other
CPUs when doing a route deletion.
This patch introduces an rcu grace period before freeing fib6_node and
makes sure the functions that dereference it takes rcu_read_lock().

Note: there is no "Fixes" tag because this bug was there in a very
early stage.

Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Acked-by: Martin KaFai Lau 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 include/net/ip6_fib.h | 30 +-
 net/ipv6/ip6_fib.c| 20 
 net/ipv6/route.c  | 14 +++---
 3 files changed, 56 insertions(+), 8 deletions(-)

--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -66,6 +66,7 @@ struct fib6_node {
__u16   fn_flags;
__u32   fn_sernum;
struct rt6_info *rr_ptr;
+   struct rcu_head rcu;
 };
 
 #ifndef CONFIG_IPV6_SUBTREES
@@ -193,9 +194,36 @@ static inline void rt6_set_from(struct r
rt->dst.from = new;
 }
 
+/* Function to safely get fn->sernum for passed in rt
+ * and store result in passed in cookie.
+ * Return true if we can get cookie safely
+ * Return false if not
+ */
+static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
+  u32 *cookie)
+{
+   struct fib6_node *fn;
+   bool status = false;
+
+   rcu_read_lock();
+   fn = rcu_dereference(rt->rt6i_node);
+
+   if (fn) {
+   *cookie = fn->fn_sernum;
+   status = true;
+   }
+
+   rcu_read_unlock();
+   return status;
+}
+
 static inline u32 rt6_get_cookie(const struct rt6_info *rt)
 {
-   return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
+   u32 cookie = 0;
+
+   rt6_get_cookie_safe(rt, );
+
+   return cookie;
 }
 
 static inline void ip6_rt_put(struct rt6_info *rt)
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -151,11 +151,23 @@ static __inline__ struct fib6_node *node
return fn;
 }
 
-static __inline__ void node_free(struct fib6_node *fn)
+static void node_free_immediate(struct fib6_node *fn)
 {
kmem_cache_free(fib6_node_kmem, fn);
 }
 
+static void node_free_rcu(struct rcu_head *head)
+{
+   struct fib6_node *fn = container_of(head, struct fib6_node, rcu);
+
+   kmem_cache_free(fib6_node_kmem, fn);
+}
+
+static void node_free(struct fib6_node *fn)
+{
+   call_rcu(>rcu, node_free_rcu);
+}
+
 static __inline__ void rt6_release(struct rt6_info *rt)
 {
if (atomic_dec_and_test(>rt6i_ref))
@@ -551,9 +563,9 @@ insert_above:
 
if (!in || !ln) {
if (in)
-   node_free(in);
+   node_free_immediate(in);
if (ln)
-   node_free(ln);
+   node_free_immediate(ln);
return ERR_PTR(-ENOMEM);
}
 
@@ -977,7 +989,7 @@ int fib6_add(struct fib6_node *root, str
   root, and then (in st_failure) stale node
   in main tree.
 */
-   node_free(sfn);
+   node_free_immediate(sfn);
err = PTR_ERR(sn);
goto st_failure;
}
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1090,6 +1090,7 @@ struct dst_entry *ip6_blackhole_route(st
 static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
 {
struct rt6_info *rt;
+   u32 rt_cookie;
 
rt = (struct rt6_info *) dst;
 
@@ -1097,7 +1098,7 @@ static struct dst_entry *ip6_dst_check(s
 * DST_OBSOLETE_FORCE_CHK which forces validation calls down
 * into this function always.
 */
-   if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
+   if (!rt6_get_cookie_safe(rt, _cookie) || rt_cookie != cookie)
return NULL;
 
if (rt6_check_expired(rt))
@@ -1136,8 +1137,14 @@ static void ip6_link_failure(struct sk_b
dst_hold(>dst);
if (ip6_del_rt(rt))
dst_free(>dst);
-   } else if (rt->rt6i_node && (rt->rt6i_flags & RTF_DEFAULT)) {
-   rt->rt6i_node->fn_sernum = -1;
+   } else {
+   struct 

Re: [PATCH v10 9/9] MANTAINERS: Add maintainer for HiSilicon LPC driver

[Bjorn Helgaas]

s/MANTAINERS/MAINTAINERS/

On Fri, Oct 27, 2017 at 05:11:27PM +0100, Gabriele Paoloni wrote:
> Added maintainer for drivers/bus/hisi_lpc.c
> 
> Signed-off-by: Gabriele Paoloni 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f66488d..b49d4c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6130,6 +6130,13 @@ F: include/uapi/linux/if_hippi.h
>  F:   net/802/hippi.c
>  F:   drivers/net/hippi/
>  
> +HISILICON LPC BUS DRIVER
> +L:   linux...@huawei.com
> +W:   http://www.hisilicon.com
> +S:   Maintained
> +F:   drivers/bus/hisi_lpc.c
> +F:   
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt

Does this really count as a "maintainer" since it's only a mailing
list, not a real person?  I personally prefer a specific person
because there's no accountability with a mailing list.

> +
>  HISILICON NETWORK SUBSYSTEM DRIVER
>  M:   Yisen Zhuang 
>  M:   Salil Mehta 
> -- 
> 2.7.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 9/9] MANTAINERS: Add maintainer for HiSilicon LPC driver

[Bjorn Helgaas]

s/MANTAINERS/MAINTAINERS/

On Fri, Oct 27, 2017 at 05:11:27PM +0100, Gabriele Paoloni wrote:
> Added maintainer for drivers/bus/hisi_lpc.c
> 
> Signed-off-by: Gabriele Paoloni 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f66488d..b49d4c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6130,6 +6130,13 @@ F: include/uapi/linux/if_hippi.h
>  F:   net/802/hippi.c
>  F:   drivers/net/hippi/
>  
> +HISILICON LPC BUS DRIVER
> +L:   linux...@huawei.com
> +W:   http://www.hisilicon.com
> +S:   Maintained
> +F:   drivers/bus/hisi_lpc.c
> +F:   
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt

Does this really count as a "maintainer" since it's only a mailing
list, not a real person?  I personally prefer a specific person
because there's no accountability with a mailing list.

> +
>  HISILICON NETWORK SUBSYSTEM DRIVER
>  M:   Yisen Zhuang 
>  M:   Salil Mehta 
> -- 
> 2.7.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.16 078/294] iwlwifi: mvm: set the RTS_MIMO_PROT bit in flag mask when sending sta to fw

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Naftali Goldstein 

commit 8addabf8e6e299f790038fdc92ddceaaf76adab8 upstream.

Set the STA_FLG_RTS_MIMO_PROT bit in station_flags_msk of the add sta
command, so that when smps mode changes, the FW will know about it.

In particular, in AP mode, clients are added upon receival of an auth
request, at which point there's no knowledge of the client's smps mode.
When the assoc request arrives, the add_sta command is resent to modify
the station parameters. At this point the driver knows the smps mode,
but since the corresponding bit in the mask is not set, the fw doesn't
update this field so there's no rts protection for mimo.

Fixes: 5bc5aaad407c ("iwlwifi: mvm: set up initial SMPS/NSS station info")
Signed-off-by: Naftali Goldstein 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename, context, indentation]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/iwlwifi/mvm/sta.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -114,7 +114,8 @@ int iwl_mvm_sta_send_to_fw(struct iwl_mv
add_sta_cmd.add_modify = update ? 1 : 0;
 
add_sta_cmd.station_flags_msk |= cpu_to_le32(STA_FLG_FAT_EN_MSK |
-STA_FLG_MIMO_EN_MSK);
+STA_FLG_MIMO_EN_MSK |
+STA_FLG_RTS_MIMO_PROT);
 
switch (sta->bandwidth) {
case IEEE80211_STA_RX_BW_160:

[PATCH 3.16 130/294] arm64: mm: abort uaccess retries upon fatal signal

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mark Rutland 

commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.

When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Cc: Catalin Marinas 
Cc: Laura Abbott 
Reviewed-by: Steve Capper 
Tested-by: Steve Capper 
Reviewed-by: James Morse 
Tested-by: James Morse 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/arm64/mm/fault.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -252,8 +252,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial

[PATCH 3.16 078/294] iwlwifi: mvm: set the RTS_MIMO_PROT bit in flag mask when sending sta to fw

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Naftali Goldstein 

commit 8addabf8e6e299f790038fdc92ddceaaf76adab8 upstream.

Set the STA_FLG_RTS_MIMO_PROT bit in station_flags_msk of the add sta
command, so that when smps mode changes, the FW will know about it.

In particular, in AP mode, clients are added upon receival of an auth
request, at which point there's no knowledge of the client's smps mode.
When the assoc request arrives, the add_sta command is resent to modify
the station parameters. At this point the driver knows the smps mode,
but since the corresponding bit in the mask is not set, the fw doesn't
update this field so there's no rts protection for mimo.

Fixes: 5bc5aaad407c ("iwlwifi: mvm: set up initial SMPS/NSS station info")
Signed-off-by: Naftali Goldstein 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename, context, indentation]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/iwlwifi/mvm/sta.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -114,7 +114,8 @@ int iwl_mvm_sta_send_to_fw(struct iwl_mv
add_sta_cmd.add_modify = update ? 1 : 0;
 
add_sta_cmd.station_flags_msk |= cpu_to_le32(STA_FLG_FAT_EN_MSK |
-STA_FLG_MIMO_EN_MSK);
+STA_FLG_MIMO_EN_MSK |
+STA_FLG_RTS_MIMO_PROT);
 
switch (sta->bandwidth) {
case IEEE80211_STA_RX_BW_160:

[PATCH 3.16 130/294] arm64: mm: abort uaccess retries upon fatal signal

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mark Rutland 

commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.

When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Cc: Catalin Marinas 
Cc: Laura Abbott 
Reviewed-by: Steve Capper 
Tested-by: Steve Capper 
Reviewed-by: James Morse 
Tested-by: James Morse 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/arm64/mm/fault.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -252,8 +252,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial

[PATCH 3.16 103/294] net: skb_needs_check() accepts CHECKSUM_NONE for tx

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

commit 6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.

My recent change missed fact that UFO would perform a complete
UDP checksum before segmenting in frags.

In this case skb->ip_summed is set to CHECKSUM_NONE.

We need to add this valid case to skb_needs_check()

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/core/dev.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2413,9 +2413,10 @@ EXPORT_SYMBOL(skb_mac_gso_segment);
 static inline bool skb_needs_check(struct sk_buff *skb, bool tx_path)
 {
if (tx_path)
-   return skb->ip_summed != CHECKSUM_PARTIAL;
-   else
-   return skb->ip_summed == CHECKSUM_NONE;
+   return skb->ip_summed != CHECKSUM_PARTIAL &&
+  skb->ip_summed != CHECKSUM_NONE;
+
+   return skb->ip_summed == CHECKSUM_NONE;
 }
 
 /**

[PATCH 3.16 103/294] net: skb_needs_check() accepts CHECKSUM_NONE for tx

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

commit 6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.

My recent change missed fact that UFO would perform a complete
UDP checksum before segmenting in frags.

In this case skb->ip_summed is set to CHECKSUM_NONE.

We need to add this valid case to skb_needs_check()

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/core/dev.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2413,9 +2413,10 @@ EXPORT_SYMBOL(skb_mac_gso_segment);
 static inline bool skb_needs_check(struct sk_buff *skb, bool tx_path)
 {
if (tx_path)
-   return skb->ip_summed != CHECKSUM_PARTIAL;
-   else
-   return skb->ip_summed == CHECKSUM_NONE;
+   return skb->ip_summed != CHECKSUM_PARTIAL &&
+  skb->ip_summed != CHECKSUM_NONE;
+
+   return skb->ip_summed == CHECKSUM_NONE;
 }
 
 /**

[PATCH 3.16 036/294] x86/acpi: Prevent out of bound access caused by broken ACPI tables

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Seunghun Han 

commit dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream.

The bus_irq argument of mp_override_legacy_irq() is used as the index into
the isa_irq_to_gsi[] array. The bus_irq argument originates from
ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI
tables, but is nowhere sanity checked.

That allows broken or malicious ACPI tables to overwrite memory, which
might cause malfunction, panic or arbitrary code execution.

Add a sanity check and emit a warning when that triggers.

[ tglx: Added warning and rewrote changelog ]

Signed-off-by: Seunghun Han 
Signed-off-by: Thomas Gleixner 
Cc: secur...@kernel.org
Cc: "Rafael J. Wysocki" 
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/acpi/boot.c | 8 
 1 file changed, 8 insertions(+)

--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -910,6 +910,14 @@ void __init mp_override_legacy_irq(u8 bu
struct mpc_intsrc mp_irq;
 
/*
+* Check bus_irq boundary.
+*/
+   if (bus_irq >= NR_IRQS_LEGACY) {
+   pr_warn("Invalid bus_irq %u for legacy override\n", bus_irq);
+   return;
+   }
+
+   /*
 * Convert 'gsi' to 'ioapic.pin'.
 */
ioapic = mp_find_ioapic(gsi);

[PATCH 3.16 036/294] x86/acpi: Prevent out of bound access caused by broken ACPI tables

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Seunghun Han 

commit dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream.

The bus_irq argument of mp_override_legacy_irq() is used as the index into
the isa_irq_to_gsi[] array. The bus_irq argument originates from
ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI
tables, but is nowhere sanity checked.

That allows broken or malicious ACPI tables to overwrite memory, which
might cause malfunction, panic or arbitrary code execution.

Add a sanity check and emit a warning when that triggers.

[ tglx: Added warning and rewrote changelog ]

Signed-off-by: Seunghun Han 
Signed-off-by: Thomas Gleixner 
Cc: secur...@kernel.org
Cc: "Rafael J. Wysocki" 
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/acpi/boot.c | 8 
 1 file changed, 8 insertions(+)

--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -910,6 +910,14 @@ void __init mp_override_legacy_irq(u8 bu
struct mpc_intsrc mp_irq;
 
/*
+* Check bus_irq boundary.
+*/
+   if (bus_irq >= NR_IRQS_LEGACY) {
+   pr_warn("Invalid bus_irq %u for legacy override\n", bus_irq);
+   return;
+   }
+
+   /*
 * Convert 'gsi' to 'ioapic.pin'.
 */
ioapic = mp_find_ioapic(gsi);

[PATCH 3.16 035/294] mount: copy the port field into the cloned nfs_server structure.

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Steve Dickson 

commit 89a6814d9b665b196aa3a102f96b6dc7e8cb669e upstream.

Doing this copy eliminates the "port=0" entry in
the /proc/mounts entries

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=69241

Signed-off-by: Steve Dickson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings 
---
 fs/nfs/client.c | 1 +
 1 file changed, 1 insertion(+)

--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -931,6 +931,7 @@ void nfs_server_copy_userdata(struct nfs
target->caps = source->caps;
target->options = source->options;
target->auth_info = source->auth_info;
+   target->port = source->port;
 }
 EXPORT_SYMBOL_GPL(nfs_server_copy_userdata);
 

[PATCH 3.16 035/294] mount: copy the port field into the cloned nfs_server structure.

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Steve Dickson 

commit 89a6814d9b665b196aa3a102f96b6dc7e8cb669e upstream.

Doing this copy eliminates the "port=0" entry in
the /proc/mounts entries

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=69241

Signed-off-by: Steve Dickson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings 
---
 fs/nfs/client.c | 1 +
 1 file changed, 1 insertion(+)

--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -931,6 +931,7 @@ void nfs_server_copy_userdata(struct nfs
target->caps = source->caps;
target->options = source->options;
target->auth_info = source->auth_info;
+   target->port = source->port;
 }
 EXPORT_SYMBOL_GPL(nfs_server_copy_userdata);
 

[PATCH 3.16 041/294] xhci: fix 20000ms port resume timeout

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mathias Nyman 

commit a54408d0a004757789863d74e29c2297edae0b4d upstream.

A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 2ms while waiting to get the final port event
interrupt for resume -> U0 state change.

This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.

The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/xhci-hub.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -644,6 +644,9 @@ static u32 xhci_get_port_status(struct u
clear_bit(wIndex, _state->resuming_ports);
 
set_bit(wIndex, _state->rexit_ports);
+
+   xhci_test_and_clear_bit(xhci, port_array, wIndex,
+   PORT_PLC);
xhci_set_link_state(xhci, port_array, wIndex,
XDEV_U0);
 

[PATCH 3.16 041/294] xhci: fix 20000ms port resume timeout

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mathias Nyman 

commit a54408d0a004757789863d74e29c2297edae0b4d upstream.

A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 2ms while waiting to get the final port event
interrupt for resume -> U0 state change.

This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.

The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/xhci-hub.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -644,6 +644,9 @@ static u32 xhci_get_port_status(struct u
clear_bit(wIndex, _state->resuming_ports);
 
set_bit(wIndex, _state->rexit_ports);
+
+   xhci_test_and_clear_bit(xhci, port_array, wIndex,
+   PORT_PLC);
xhci_set_link_state(xhci, port_array, wIndex,
XDEV_U0);
 

[PATCH 3.16 051/294] RDMA/core: Initialize port_num in qp_attr

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Ismail, Mustafa" 

commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream.

Initialize the port_num for iWARP in rdma_init_qp_attr.

Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds")
Reviewed-by: Steve Wise 
Signed-off-by: Mustafa Ismail 
Tested-by: Mike Marciniszyn 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/infiniband/core/cma.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -753,6 +753,8 @@ int rdma_init_qp_attr(struct rdma_cm_id
} else
ret = iw_cm_init_qp_attr(id_priv->cm_id.iw, qp_attr,
 qp_attr_mask);
+   qp_attr->port_num = id_priv->id.port_num;
+   *qp_attr_mask |= IB_QP_PORT;
break;
default:
ret = -ENOSYS;

[PATCH 3.16 051/294] RDMA/core: Initialize port_num in qp_attr

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Ismail, Mustafa" 

commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream.

Initialize the port_num for iWARP in rdma_init_qp_attr.

Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds")
Reviewed-by: Steve Wise 
Signed-off-by: Mustafa Ismail 
Tested-by: Mike Marciniszyn 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/infiniband/core/cma.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -753,6 +753,8 @@ int rdma_init_qp_attr(struct rdma_cm_id
} else
ret = iw_cm_init_qp_attr(id_priv->cm_id.iw, qp_attr,
 qp_attr_mask);
+   qp_attr->port_num = id_priv->id.port_num;
+   *qp_attr_mask |= IB_QP_PORT;
break;
default:
ret = -ENOSYS;

[PATCH 3.16 064/294] media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b upstream.

Since commit e8f4818895b3 ("[media] lirc: advertise
LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
the hardware can detect. This breaks decoding in lirc because lircd
expects the answer in microseconds, but nanoseconds is returned.

Reported-by: Derek 
Tested-by: Derek 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/media/rc/ir-lirc-codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -257,7 +257,7 @@ static long ir_lirc_ioctl(struct file *f
return 0;
 
case LIRC_GET_REC_RESOLUTION:
-   val = dev->rx_resolution;
+   val = dev->rx_resolution / 1000;
break;
 
case LIRC_SET_WIDEBAND_RECEIVER:

[PATCH 3.16 064/294] media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b upstream.

Since commit e8f4818895b3 ("[media] lirc: advertise
LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
the hardware can detect. This breaks decoding in lirc because lircd
expects the answer in microseconds, but nanoseconds is returned.

Reported-by: Derek 
Tested-by: Derek 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/media/rc/ir-lirc-codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -257,7 +257,7 @@ static long ir_lirc_ioctl(struct file *f
return 0;
 
case LIRC_GET_REC_RESOLUTION:
-   val = dev->rx_resolution;
+   val = dev->rx_resolution / 1000;
break;
 
case LIRC_SET_WIDEBAND_RECEIVER:

[PATCH 3.16 165/294] x86/ldt: Fix off by one in get_segment_base()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit eaa2f87c6b840b83827c40db6eb8481689570259 upstream.

ldt->entries[] is allocated in alloc_ldt_struct().  It has
ldt->nr_entries elements and ldt->nr_entries is capped at LDT_ENTRIES.
So if "idx" is == ldt->nr_entries then we're reading beyond the end of
the buffer.  It seems duplicative to have two limit checks when one
would work just as well so I removed the check against LDT_ENTRIES.

The gdt_page.gdt[] array has GDT_ENTRIES entries.

Signed-off-by: Dan Carpenter 
Acked-by: Andy Lutomirski 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Fixes: d07bdfd322d3 ("perf/x86: Fix USER/KERNEL tagging of samples properly")
Link: http://lkml.kernel.org/r/20170818102516.gqwm4xdvvuvjw5ho@mwanda
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/cpu/perf_event.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -2009,17 +2009,14 @@ static unsigned long get_segment_base(un
if ((segment & SEGMENT_TI_MASK) == SEGMENT_LDT) {
struct ldt_struct *ldt;
 
-   if (idx > LDT_ENTRIES)
-   return 0;
-
/* IRQs are off, so this synchronizes with smp_store_release */
ldt = lockless_dereference(current->active_mm->context.ldt);
-   if (!ldt || idx > ldt->size)
+   if (!ldt || idx >= ldt->size)
return 0;
 
desc = >entries[idx];
} else {
-   if (idx > GDT_ENTRIES)
+   if (idx >= GDT_ENTRIES)
return 0;
 
desc = __this_cpu_ptr(_page.gdt[0]) + idx;

[PATCH 3.16 165/294] x86/ldt: Fix off by one in get_segment_base()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit eaa2f87c6b840b83827c40db6eb8481689570259 upstream.

ldt->entries[] is allocated in alloc_ldt_struct().  It has
ldt->nr_entries elements and ldt->nr_entries is capped at LDT_ENTRIES.
So if "idx" is == ldt->nr_entries then we're reading beyond the end of
the buffer.  It seems duplicative to have two limit checks when one
would work just as well so I removed the check against LDT_ENTRIES.

The gdt_page.gdt[] array has GDT_ENTRIES entries.

Signed-off-by: Dan Carpenter 
Acked-by: Andy Lutomirski 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Fixes: d07bdfd322d3 ("perf/x86: Fix USER/KERNEL tagging of samples properly")
Link: http://lkml.kernel.org/r/20170818102516.gqwm4xdvvuvjw5ho@mwanda
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/cpu/perf_event.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -2009,17 +2009,14 @@ static unsigned long get_segment_base(un
if ((segment & SEGMENT_TI_MASK) == SEGMENT_LDT) {
struct ldt_struct *ldt;
 
-   if (idx > LDT_ENTRIES)
-   return 0;
-
/* IRQs are off, so this synchronizes with smp_store_release */
ldt = lockless_dereference(current->active_mm->context.ldt);
-   if (!ldt || idx > ldt->size)
+   if (!ldt || idx >= ldt->size)
return 0;
 
desc = >entries[idx];
} else {
-   if (idx > GDT_ENTRIES)
+   if (idx >= GDT_ENTRIES)
return 0;
 
desc = __this_cpu_ptr(_page.gdt[0]) + idx;

[PATCH 3.16 055/294] iwlwifi: dvm: prevent an out of bounds access

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Emmanuel Grumbach 

commit 0b0f934e92a8eaed2e6c48a50eae6f84661f74f3 upstream.

iwlagn_check_ratid_empty takes the tid as a parameter, but
it doesn't check that it is not IWL_TID_NON_QOS.
Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array
with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS]
is a bad idea.
This happened in iwlagn_rx_reply_tx. Since
iwlagn_check_ratid_empty is relevant only to check whether
we can open A-MPDU, this flow is irrelevant if tid is
IWL_TID_NON_QOS. Call iwlagn_check_ratid_empty only inside
the
if (tid != IWL_TID_NON_QOS)

a few lines earlier in the function.

Reported-by: Seraphime Kirkovski 
Tested-by: Seraphime Kirkovski 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/iwlwifi/dvm/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ int iwlagn_rx_reply_tx(struct iwl_priv *
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
  next_reclaimed);
+   iwlagn_check_ratid_empty(priv, sta_id, tid);
}
 
iwl_trans_reclaim(priv->trans, txq_id, ssn, );
 
-   iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;
 
/* process frames */

[PATCH 3.16 089/294] ALSA: hda - Fix speaker output from VAIO VPCL14M1R

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Sergei A. Trusov" 

commit 3f3c371421e601fa93b6cb7fb52da9ad59ec90b4 upstream.

Sony VAIO VPCL14M1R needs the quirk to make the speaker working properly.

Tested-by: Dmitriy 
Signed-off-by: Sergei A. Trusov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2285,6 +2285,7 @@ static const struct snd_pci_quirk alc882
SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", 
ALC882_FIXUP_GPIO3),
SND_PCI_QUIRK(0x104d, 0x9047, "Sony Vaio TT", ALC889_FIXUP_VAIO_TT),
SND_PCI_QUIRK(0x104d, 0x905a, "Sony Vaio Z", 
ALC882_FIXUP_NO_PRIMARY_HP),
+   SND_PCI_QUIRK(0x104d, 0x9060, "Sony Vaio VPCL14M1R", 
ALC882_FIXUP_NO_PRIMARY_HP),
SND_PCI_QUIRK(0x104d, 0x9043, "Sony Vaio VGC-LN51JGB", 
ALC882_FIXUP_NO_PRIMARY_HP),
SND_PCI_QUIRK(0x104d, 0x9044, "Sony VAIO AiO", 
ALC882_FIXUP_NO_PRIMARY_HP),
 

[PATCH 3.16 055/294] iwlwifi: dvm: prevent an out of bounds access

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Emmanuel Grumbach 

commit 0b0f934e92a8eaed2e6c48a50eae6f84661f74f3 upstream.

iwlagn_check_ratid_empty takes the tid as a parameter, but
it doesn't check that it is not IWL_TID_NON_QOS.
Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array
with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS]
is a bad idea.
This happened in iwlagn_rx_reply_tx. Since
iwlagn_check_ratid_empty is relevant only to check whether
we can open A-MPDU, this flow is irrelevant if tid is
IWL_TID_NON_QOS. Call iwlagn_check_ratid_empty only inside
the
if (tid != IWL_TID_NON_QOS)

a few lines earlier in the function.

Reported-by: Seraphime Kirkovski 
Tested-by: Seraphime Kirkovski 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/iwlwifi/dvm/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ int iwlagn_rx_reply_tx(struct iwl_priv *
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
  next_reclaimed);
+   iwlagn_check_ratid_empty(priv, sta_id, tid);
}
 
iwl_trans_reclaim(priv->trans, txq_id, ssn, );
 
-   iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;
 
/* process frames */

[PATCH 3.16 089/294] ALSA: hda - Fix speaker output from VAIO VPCL14M1R

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Sergei A. Trusov" 

commit 3f3c371421e601fa93b6cb7fb52da9ad59ec90b4 upstream.

Sony VAIO VPCL14M1R needs the quirk to make the speaker working properly.

Tested-by: Dmitriy 
Signed-off-by: Sergei A. Trusov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2285,6 +2285,7 @@ static const struct snd_pci_quirk alc882
SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", 
ALC882_FIXUP_GPIO3),
SND_PCI_QUIRK(0x104d, 0x9047, "Sony Vaio TT", ALC889_FIXUP_VAIO_TT),
SND_PCI_QUIRK(0x104d, 0x905a, "Sony Vaio Z", 
ALC882_FIXUP_NO_PRIMARY_HP),
+   SND_PCI_QUIRK(0x104d, 0x9060, "Sony Vaio VPCL14M1R", 
ALC882_FIXUP_NO_PRIMARY_HP),
SND_PCI_QUIRK(0x104d, 0x9043, "Sony Vaio VGC-LN51JGB", 
ALC882_FIXUP_NO_PRIMARY_HP),
SND_PCI_QUIRK(0x104d, 0x9044, "Sony VAIO AiO", 
ALC882_FIXUP_NO_PRIMARY_HP),
 

[PATCH 3.16 167/294] i2c: ismt: Don't duplicate the receive length for block reads

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Stephen Douthit 

commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.

According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.

desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte.  So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:

count data1 data2 data3 data4
 0x04  0xde  0xad  0xbe  0xef

That's what we want to return in data->block to the next level.

Instead we were actually prefixing that with desc->rxbytes:

bad
count count data1 data2 data3 data4
 0x05  0x04  0xde  0xad  0xbe  0xef

This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.

Signed-off-by: Stephen Douthit 
Tested-by: Dan Priamo 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Ben Hutchings 
---
 drivers/i2c/busses/i2c-ismt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/i2c/busses/i2c-ismt.c
+++ b/drivers/i2c/busses/i2c-ismt.c
@@ -344,8 +344,8 @@ static int ismt_process_desc(const struc
break;
case I2C_SMBUS_BLOCK_DATA:
case I2C_SMBUS_I2C_BLOCK_DATA:
-   memcpy(>block[1], dma_buffer, desc->rxbytes);
-   data->block[0] = desc->rxbytes;
+   memcpy(data->block, dma_buffer, desc->rxbytes);
+   data->block[0] = desc->rxbytes - 1;
break;
}
return 0;

[PATCH 3.16 167/294] i2c: ismt: Don't duplicate the receive length for block reads

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Stephen Douthit 

commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.

According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.

desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte.  So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:

count data1 data2 data3 data4
 0x04  0xde  0xad  0xbe  0xef

That's what we want to return in data->block to the next level.

Instead we were actually prefixing that with desc->rxbytes:

bad
count count data1 data2 data3 data4
 0x05  0x04  0xde  0xad  0xbe  0xef

This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.

Signed-off-by: Stephen Douthit 
Tested-by: Dan Priamo 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Ben Hutchings 
---
 drivers/i2c/busses/i2c-ismt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/i2c/busses/i2c-ismt.c
+++ b/drivers/i2c/busses/i2c-ismt.c
@@ -344,8 +344,8 @@ static int ismt_process_desc(const struc
break;
case I2C_SMBUS_BLOCK_DATA:
case I2C_SMBUS_I2C_BLOCK_DATA:
-   memcpy(>block[1], dma_buffer, desc->rxbytes);
-   data->block[0] = desc->rxbytes;
+   memcpy(data->block, dma_buffer, desc->rxbytes);
+   data->block[0] = desc->rxbytes - 1;
break;
}
return 0;

Re: [PATCH] coccinelle: grep Options and Requires fields more precisely

[Masahiro Yamada]

2017-10-26 16:26 GMT+09:00 Nicolas Palix (LIG) :
> Le 26/10/17 à 06:59, Julia Lawall a écrit :
>>
>>
>>
>> On Thu, 26 Oct 2017, Masahiro Yamada wrote:
>>
>>> Currently, the required version for badzero.cocci is picked up from
>>> its "Comments:" line since it contains the word "Requires".
>>>
>>> Surprisingly, ld-version.sh can extract the version number from the
>>> string "Requires Coccinelle version 1.0.0-rc20 or later", but this
>>> expectation is fragile.  Fix the .cocci file.  I removed "-rc20"
>>> because ld-version.sh cannot handle it.
>>
>>
>> OK.
>>
>>> Make the coccicheck script to see exact patterns for "Options:" and
>>> "Requires:" in order to avoid accidental matching to what just happens
>>> to appear in comment lines.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>
>>
>> Thanks for checking on this!
>>
>> Acked-by: Julia Lawall 
>
> Acked-by: Nicolas Palix 
>
>>
>>> ---
>>>
>>>   scripts/coccicheck| 4 ++--
>>>   scripts/coccinelle/null/badzero.cocci | 2 +-
>>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/scripts/coccicheck b/scripts/coccicheck
>>> index 3e21a1b..1bfa2d2 100755
>>> --- a/scripts/coccicheck
>>> +++ b/scripts/coccicheck
>>> @@ -168,8 +168,8 @@ OPTIONS="$OPTIONS $SPFLAGS"
>>>   coccinelle () {
>>>   COCCI="$1"
>>>
>>> -OPT=`grep "Option" $COCCI | cut -d':' -f2`
>>> -REQ=`grep "Requires" $COCCI | cut -d':' -f2 | sed "s| ||"`
>>> +OPT=`grep "Options:" $COCCI | cut -d':' -f2`
>>> +REQ=`grep "Requires:" $COCCI | cut -d':' -f2 | sed "s| ||"`
>>>   REQ_NUM=$(echo $REQ | ${DIR}/scripts/ld-version.sh)
>>>   if [ "$REQ_NUM" != "0" ] ; then
>>> if [ "$SPATCH_VERSION_NUM" -lt "$REQ_NUM" ] ; then
>>> diff --git a/scripts/coccinelle/null/badzero.cocci
>>> b/scripts/coccinelle/null/badzero.cocci
>>> index 5551da2..f597c80 100644
>>> --- a/scripts/coccinelle/null/badzero.cocci
>>> +++ b/scripts/coccinelle/null/badzero.cocci
>>> @@ -10,7 +10,7 @@
>>>   // Copyright: (C) 2012 Julia Lawall, INRIA/LIP6.  GPLv2.
>>>   // Copyright: (C) 2012 Gilles Muller, INRIA/LiP6.  GPLv2.
>>>   // URL: http://coccinelle.lip6.fr/
>>> -// Comments: Requires Coccinelle version 1.0.0-rc20 or later
>>> +// Requires: 1.0.0
>>>   // Options:
>>>
>>>   virtual patch
>>> --
>>> 2.7.4
>>>
>>>
>
>
> --
> Nicolas Palix
> http://lig-membres.imag.fr/palix/
>


Applied to linux-kbuild/misc.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] coccinelle: grep Options and Requires fields more precisely

[Masahiro Yamada]

2017-10-26 16:26 GMT+09:00 Nicolas Palix (LIG) :
> Le 26/10/17 à 06:59, Julia Lawall a écrit :
>>
>>
>>
>> On Thu, 26 Oct 2017, Masahiro Yamada wrote:
>>
>>> Currently, the required version for badzero.cocci is picked up from
>>> its "Comments:" line since it contains the word "Requires".
>>>
>>> Surprisingly, ld-version.sh can extract the version number from the
>>> string "Requires Coccinelle version 1.0.0-rc20 or later", but this
>>> expectation is fragile.  Fix the .cocci file.  I removed "-rc20"
>>> because ld-version.sh cannot handle it.
>>
>>
>> OK.
>>
>>> Make the coccicheck script to see exact patterns for "Options:" and
>>> "Requires:" in order to avoid accidental matching to what just happens
>>> to appear in comment lines.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>
>>
>> Thanks for checking on this!
>>
>> Acked-by: Julia Lawall 
>
> Acked-by: Nicolas Palix 
>
>>
>>> ---
>>>
>>>   scripts/coccicheck| 4 ++--
>>>   scripts/coccinelle/null/badzero.cocci | 2 +-
>>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/scripts/coccicheck b/scripts/coccicheck
>>> index 3e21a1b..1bfa2d2 100755
>>> --- a/scripts/coccicheck
>>> +++ b/scripts/coccicheck
>>> @@ -168,8 +168,8 @@ OPTIONS="$OPTIONS $SPFLAGS"
>>>   coccinelle () {
>>>   COCCI="$1"
>>>
>>> -OPT=`grep "Option" $COCCI | cut -d':' -f2`
>>> -REQ=`grep "Requires" $COCCI | cut -d':' -f2 | sed "s| ||"`
>>> +OPT=`grep "Options:" $COCCI | cut -d':' -f2`
>>> +REQ=`grep "Requires:" $COCCI | cut -d':' -f2 | sed "s| ||"`
>>>   REQ_NUM=$(echo $REQ | ${DIR}/scripts/ld-version.sh)
>>>   if [ "$REQ_NUM" != "0" ] ; then
>>> if [ "$SPATCH_VERSION_NUM" -lt "$REQ_NUM" ] ; then
>>> diff --git a/scripts/coccinelle/null/badzero.cocci
>>> b/scripts/coccinelle/null/badzero.cocci
>>> index 5551da2..f597c80 100644
>>> --- a/scripts/coccinelle/null/badzero.cocci
>>> +++ b/scripts/coccinelle/null/badzero.cocci
>>> @@ -10,7 +10,7 @@
>>>   // Copyright: (C) 2012 Julia Lawall, INRIA/LIP6.  GPLv2.
>>>   // Copyright: (C) 2012 Gilles Muller, INRIA/LiP6.  GPLv2.
>>>   // URL: http://coccinelle.lip6.fr/
>>> -// Comments: Requires Coccinelle version 1.0.0-rc20 or later
>>> +// Requires: 1.0.0
>>>   // Options:
>>>
>>>   virtual patch
>>> --
>>> 2.7.4
>>>
>>>
>
>
> --
> Nicolas Palix
> http://lig-membres.imag.fr/palix/
>


Applied to linux-kbuild/misc.


-- 
Best Regards
Masahiro Yamada

[PATCH 3.16 037/294] ARM: kexec: Make .text R/W in machine_kexec

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Borisov 

commit 42d720d1731a9d7035c2812437c35e271ec4dd78 upstream.

With the introduction of Kees Cook's patch to make the kernel .text
read-only the existing method by which kexec works got broken since it
directly pokes some values in the template code, which resides in the
.text section.

The current patch changes the way those values are inserted so that poking
.text section occurs only in machine_kexec (e.g when we are about to nuke
the old kernel and are beyond the point of return). This allows to use
set_kernel_text_rw() to directly patch the values in the .text section.

I had already sent a patch which achieved this but it was significantly
more complicated, so this is a cleaner/straight-forward approach.

Signed-off-by: Nikolay Borisov 
Acked-by: Will Deacon 
[kees: collapsed kexec_boot_atags (will.daecon)]
[kees: for bisectability, moved set_kernel_text_rw() to RODATA patch]
Signed-off-by: Kees Cook 
Acked-by: Nicolas Pitre 
Signed-off-by: Ben Hutchings 
---
 arch/arm/kernel/machine_kexec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -29,6 +29,7 @@ extern unsigned long kexec_boot_atags;
 
 static atomic_t waiting_for_crash_ipi;
 
+static unsigned long dt_mem;
 /*
  * Provide a dummy crash_notes definition while crash dump arrives to arm.
  * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
@@ -64,7 +65,7 @@ int machine_kexec_prepare(struct kimage
return err;
 
if (be32_to_cpu(header) == OF_DT_HEADER)
-   kexec_boot_atags = current_segment->mem;
+   dt_mem = current_segment->mem;
}
return 0;
 }
@@ -166,9 +167,8 @@ void machine_kexec(struct kimage *image)
kexec_start_address = image->start;
kexec_indirection_page = page_list;
kexec_mach_type = machine_arch_type;
-   if (!kexec_boot_atags)
-   kexec_boot_atags = image->start - KEXEC_ARM_ZIMAGE_OFFSET + 
KEXEC_ARM_ATAGS_OFFSET;
-
+   kexec_boot_atags = dt_mem ?: image->start - KEXEC_ARM_ZIMAGE_OFFSET
++ KEXEC_ARM_ATAGS_OFFSET;
 
/* copy our kernel relocation code to the control code page */
reboot_entry = fncpy(reboot_code_buffer,

[PATCH 3.16 037/294] ARM: kexec: Make .text R/W in machine_kexec

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Borisov 

commit 42d720d1731a9d7035c2812437c35e271ec4dd78 upstream.

With the introduction of Kees Cook's patch to make the kernel .text
read-only the existing method by which kexec works got broken since it
directly pokes some values in the template code, which resides in the
.text section.

The current patch changes the way those values are inserted so that poking
.text section occurs only in machine_kexec (e.g when we are about to nuke
the old kernel and are beyond the point of return). This allows to use
set_kernel_text_rw() to directly patch the values in the .text section.

I had already sent a patch which achieved this but it was significantly
more complicated, so this is a cleaner/straight-forward approach.

Signed-off-by: Nikolay Borisov 
Acked-by: Will Deacon 
[kees: collapsed kexec_boot_atags (will.daecon)]
[kees: for bisectability, moved set_kernel_text_rw() to RODATA patch]
Signed-off-by: Kees Cook 
Acked-by: Nicolas Pitre 
Signed-off-by: Ben Hutchings 
---
 arch/arm/kernel/machine_kexec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -29,6 +29,7 @@ extern unsigned long kexec_boot_atags;
 
 static atomic_t waiting_for_crash_ipi;
 
+static unsigned long dt_mem;
 /*
  * Provide a dummy crash_notes definition while crash dump arrives to arm.
  * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
@@ -64,7 +65,7 @@ int machine_kexec_prepare(struct kimage
return err;
 
if (be32_to_cpu(header) == OF_DT_HEADER)
-   kexec_boot_atags = current_segment->mem;
+   dt_mem = current_segment->mem;
}
return 0;
 }
@@ -166,9 +167,8 @@ void machine_kexec(struct kimage *image)
kexec_start_address = image->start;
kexec_indirection_page = page_list;
kexec_mach_type = machine_arch_type;
-   if (!kexec_boot_atags)
-   kexec_boot_atags = image->start - KEXEC_ARM_ZIMAGE_OFFSET + 
KEXEC_ARM_ATAGS_OFFSET;
-
+   kexec_boot_atags = dt_mem ?: image->start - KEXEC_ARM_ZIMAGE_OFFSET
++ KEXEC_ARM_ATAGS_OFFSET;
 
/* copy our kernel relocation code to the control code page */
reboot_entry = fncpy(reboot_code_buffer,

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 9:31 AM, Eric Dumazet wrote:
> On Mon, Nov 6, 2017 at 4:29 PM, David Ahern  wrote:
>> On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote:
>>> I've hit this 6 times now, across 3 boots:
>>>
>>> Nov  3 11:04:54 turing-police kernel: [  547.814748] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>>
>>> Nov  3 20:24:11 turing-police kernel: [   60.093793] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>> Nov  4 20:20:54 turing-police kernel: [86264.366955] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>> Nov  5 19:17:40 turing-police kernel: [172469.769179] BUG: sleeping 
>>> function called from invalid context at mm/slab.h:422
>>> Nov  6 06:07:37 turing-police kernel: [211467.239460] BUG: sleeping 
>>> function called from invalid context at mm/slab.h:422
>>>
>>> Nov  6 14:12:43 turing-police kernel: [   54.891848] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>>
>>> Something seems to be going astray while handling a RA packet.
>>
>> Odd. I tested RA before sending the patches and again just now - no
>> traceback with an RCU / lock debugging kernel. What is sending the RA's
>> in your case? I'd like to understand the config and add a test for this.
> 
> Do you have CONFIG_DEBUG_ATOMIC_SLEEP=y in your .config ?
> 

I needed to set sysctl -w net.ipv6.conf.eth1.use_tempaddr=1. With that I
see the trace.

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 9:31 AM, Eric Dumazet wrote:
> On Mon, Nov 6, 2017 at 4:29 PM, David Ahern  wrote:
>> On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote:
>>> I've hit this 6 times now, across 3 boots:
>>>
>>> Nov  3 11:04:54 turing-police kernel: [  547.814748] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>>
>>> Nov  3 20:24:11 turing-police kernel: [   60.093793] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>> Nov  4 20:20:54 turing-police kernel: [86264.366955] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>> Nov  5 19:17:40 turing-police kernel: [172469.769179] BUG: sleeping 
>>> function called from invalid context at mm/slab.h:422
>>> Nov  6 06:07:37 turing-police kernel: [211467.239460] BUG: sleeping 
>>> function called from invalid context at mm/slab.h:422
>>>
>>> Nov  6 14:12:43 turing-police kernel: [   54.891848] BUG: sleeping function 
>>> called from invalid context at mm/slab.h:422
>>>
>>> Something seems to be going astray while handling a RA packet.
>>
>> Odd. I tested RA before sending the patches and again just now - no
>> traceback with an RCU / lock debugging kernel. What is sending the RA's
>> in your case? I'd like to understand the config and add a test for this.
> 
> Do you have CONFIG_DEBUG_ATOMIC_SLEEP=y in your .config ?
> 

I needed to set sysctl -w net.ipv6.conf.eth1.use_tempaddr=1. With that I
see the trace.

[PATCH 3.16 116/294] ipv4: fix NULL dereference in free_fib_info_rcu()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

commit 187e5b3ac84d3421d2de3aca949b2791fbcad554 upstream.

If fi->fib_metrics could not be allocated in fib_create_info()
we attempt to dereference a NULL pointer in free_fib_info_rcu() :

m = fi->fib_metrics;
if (m != _default_metrics && atomic_dec_and_test(>refcnt))
kfree(m);

Before my recent patch, we used to call kfree(NULL) and nothing wrong
happened.

Instead of using RCU to defer freeing while we are under memory stress,
it seems better to take immediate action.

This was reported by syzkaller team.

Fixes: 3fb07daff8e9 ("ipv4: add reference counting to metrics")
Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/fib_semantics.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -823,15 +823,17 @@ struct fib_info *fib_create_info(struct
fi = kzalloc(sizeof(*fi)+nhs*sizeof(struct fib_nh), GFP_KERNEL);
if (fi == NULL)
goto failure;
-   fib_info_cnt++;
if (cfg->fc_mx) {
fi->fib_metrics = dst_alloc_metrics(GFP_KERNEL | __GFP_ZERO);
-   if (!fi->fib_metrics)
-   goto failure;
+   if (unlikely(!fi->fib_metrics)) {
+   kfree(fi);
+   return ERR_PTR(err);
+   }
atomic_set(>fib_metrics->refcnt, 1);
-   } else
+   } else {
fi->fib_metrics = (struct dst_metrics *)_default_metrics;
-
+   }
+   fib_info_cnt++;
fi->fib_net = hold_net(net);
fi->fib_protocol = cfg->fc_protocol;
fi->fib_scope = cfg->fc_scope;

[PATCH 3.16 116/294] ipv4: fix NULL dereference in free_fib_info_rcu()

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

commit 187e5b3ac84d3421d2de3aca949b2791fbcad554 upstream.

If fi->fib_metrics could not be allocated in fib_create_info()
we attempt to dereference a NULL pointer in free_fib_info_rcu() :

m = fi->fib_metrics;
if (m != _default_metrics && atomic_dec_and_test(>refcnt))
kfree(m);

Before my recent patch, we used to call kfree(NULL) and nothing wrong
happened.

Instead of using RCU to defer freeing while we are under memory stress,
it seems better to take immediate action.

This was reported by syzkaller team.

Fixes: 3fb07daff8e9 ("ipv4: add reference counting to metrics")
Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/fib_semantics.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -823,15 +823,17 @@ struct fib_info *fib_create_info(struct
fi = kzalloc(sizeof(*fi)+nhs*sizeof(struct fib_nh), GFP_KERNEL);
if (fi == NULL)
goto failure;
-   fib_info_cnt++;
if (cfg->fc_mx) {
fi->fib_metrics = dst_alloc_metrics(GFP_KERNEL | __GFP_ZERO);
-   if (!fi->fib_metrics)
-   goto failure;
+   if (unlikely(!fi->fib_metrics)) {
+   kfree(fi);
+   return ERR_PTR(err);
+   }
atomic_set(>fib_metrics->refcnt, 1);
-   } else
+   } else {
fi->fib_metrics = (struct dst_metrics *)_default_metrics;
-
+   }
+   fib_info_cnt++;
fi->fib_net = hold_net(net);
fi->fib_protocol = cfg->fc_protocol;
fi->fib_scope = cfg->fc_scope;

Business Proposal.

[Douglas Flint]

Dear Friend,

I am interested in establishing and operating a very viable business as a means 
of investment abroad. I do not know too well on how this is done in your 
country, So I will need you to help me in this regard.

My preference is any good profit yielding business and I would appreciate any 
viable ideas you could come up with. I will also need you to help me look for 
properties like homes and lands for sale as I am proposing to invest the sum of 
Ten Million Great British Pounds (10,000,000 GBP) for this. I do not know if 
you can and will be of help to me.

For a brief on my personality; 

My need for this business proposition and to acquire these properties is very 
urgent as I am planing to retire from my position as the newly retired chairman 
of HSBC bank, I did stepped down on the 30th/September/2017.
As business inclined person, I want you to come up with your individual 
business/ investment ideas as I will welcome it from the bottom of my heart.


Please I expect your good and prompt reply so that we can proceed swiftly on 
how the funds can be sent to you as the beneficiary. 

Best Regards,
Douglas J Flint.

Business Proposal.

[Douglas Flint]

Dear Friend,

I am interested in establishing and operating a very viable business as a means 
of investment abroad. I do not know too well on how this is done in your 
country, So I will need you to help me in this regard.

My preference is any good profit yielding business and I would appreciate any 
viable ideas you could come up with. I will also need you to help me look for 
properties like homes and lands for sale as I am proposing to invest the sum of 
Ten Million Great British Pounds (10,000,000 GBP) for this. I do not know if 
you can and will be of help to me.

For a brief on my personality; 

My need for this business proposition and to acquire these properties is very 
urgent as I am planing to retire from my position as the newly retired chairman 
of HSBC bank, I did stepped down on the 30th/September/2017.
As business inclined person, I want you to come up with your individual 
business/ investment ideas as I will welcome it from the bottom of my heart.


Please I expect your good and prompt reply so that we can proceed swiftly on 
how the funds can be sent to you as the beneficiary. 

Best Regards,
Douglas J Flint.

[PATCH 3.16 049/294] IB/cma: Fix reference count leak when no ipv4 addresses are set

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Kalderon, Michal" 

commit 963916fdb3e5ad4af57ac959b5a03bf23f7568ca upstream.

Once in_dev_get is called to receive in_device pointer, the
in_device reference counter is increased, but if there are
no ipv4 addresses configured on the net-device the ifa_list
will be null, resulting in a flow that doesn't call in_dev_put
to decrease the ref_cnt.
This was exposed when running RoCE over ipv6 without any ipv4
addresses configured

Fixes: commit 8e3867310c90 ("IB/cma: Fix a race condition in 
iboe_addr_get_sgid()")

Signed-off-by: Michal Kalderon 
Signed-off-by: Ariel Elior 
Signed-off-by: Doug Ledford 
Signed-off-by: Ben Hutchings 
---
 include/rdma/ib_addr.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -185,11 +185,13 @@ static inline void iboe_addr_get_sgid(st
dev = dev_get_by_index(_net, dev_addr->bound_dev_if);
if (dev) {
ip4 = in_dev_get(dev);
-   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
+   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
   (struct in6_addr *)gid);
+
+   if (ip4)
in_dev_put(ip4);
-   }
+
dev_put(dev);
}
 }

[PATCH 3.16 049/294] IB/cma: Fix reference count leak when no ipv4 addresses are set

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Kalderon, Michal" 

commit 963916fdb3e5ad4af57ac959b5a03bf23f7568ca upstream.

Once in_dev_get is called to receive in_device pointer, the
in_device reference counter is increased, but if there are
no ipv4 addresses configured on the net-device the ifa_list
will be null, resulting in a flow that doesn't call in_dev_put
to decrease the ref_cnt.
This was exposed when running RoCE over ipv6 without any ipv4
addresses configured

Fixes: commit 8e3867310c90 ("IB/cma: Fix a race condition in 
iboe_addr_get_sgid()")

Signed-off-by: Michal Kalderon 
Signed-off-by: Ariel Elior 
Signed-off-by: Doug Ledford 
Signed-off-by: Ben Hutchings 
---
 include/rdma/ib_addr.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -185,11 +185,13 @@ static inline void iboe_addr_get_sgid(st
dev = dev_get_by_index(_net, dev_addr->bound_dev_if);
if (dev) {
ip4 = in_dev_get(dev);
-   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
+   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
   (struct in6_addr *)gid);
+
+   if (ip4)
in_dev_put(ip4);
-   }
+
dev_put(dev);
}
 }

[PATCH 3.16 024/294] spmi: Include OF based modalias in device uevent

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

commit d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream.

Include the OF-based modalias in the uevent sent when registering SPMI
devices, so that user space has a chance to autoload the kernel module
for the device.

Tested-by: Rob Clark 
Reported-by: Rob Clark 
Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/spmi/spmi.c | 12 
 1 file changed, 12 insertions(+)

--- a/drivers/spmi/spmi.c
+++ b/drivers/spmi/spmi.c
@@ -354,11 +354,23 @@ static int spmi_drv_remove(struct device
return 0;
 }
 
+static int spmi_drv_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+   int ret;
+
+   ret = of_device_uevent_modalias(dev, env);
+   if (ret != -ENODEV)
+   return ret;
+
+   return 0;
+}
+
 static struct bus_type spmi_bus_type = {
.name   = "spmi",
.match  = spmi_device_match,
.probe  = spmi_drv_probe,
.remove = spmi_drv_remove,
+   .uevent = spmi_drv_uevent,
 };
 
 /**

[PATCH 3.16 024/294] spmi: Include OF based modalias in device uevent

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

commit d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream.

Include the OF-based modalias in the uevent sent when registering SPMI
devices, so that user space has a chance to autoload the kernel module
for the device.

Tested-by: Rob Clark 
Reported-by: Rob Clark 
Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/spmi/spmi.c | 12 
 1 file changed, 12 insertions(+)

--- a/drivers/spmi/spmi.c
+++ b/drivers/spmi/spmi.c
@@ -354,11 +354,23 @@ static int spmi_drv_remove(struct device
return 0;
 }
 
+static int spmi_drv_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+   int ret;
+
+   ret = of_device_uevent_modalias(dev, env);
+   if (ret != -ENODEV)
+   return ret;
+
+   return 0;
+}
+
 static struct bus_type spmi_bus_type = {
.name   = "spmi",
.match  = spmi_device_match,
.probe  = spmi_drv_probe,
.remove = spmi_drv_remove,
+   .uevent = spmi_drv_uevent,
 };
 
 /**

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Nicholas Piggin]

On Mon,  6 Nov 2017 15:56:40 -0500
Mathieu Desnoyers  wrote:

> diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
> b/arch/powerpc/include/uapi/asm/unistd.h
> index b1980fcd56d5..972a7d68c143 100644
> --- a/arch/powerpc/include/uapi/asm/unistd.h
> +++ b/arch/powerpc/include/uapi/asm/unistd.h
> @@ -396,5 +396,6 @@
>  #define __NR_kexec_file_load 382
>  #define __NR_statx   383
>  #define __NR_rseq384
> +#define __NR_cpu_opv 385

Sorry for bike shedding, but could we invest a few more keystrokes to
make these names a bit more readable?

Thanks,
Nick

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Nicholas Piggin]

On Mon,  6 Nov 2017 15:56:40 -0500
Mathieu Desnoyers  wrote:

> diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
> b/arch/powerpc/include/uapi/asm/unistd.h
> index b1980fcd56d5..972a7d68c143 100644
> --- a/arch/powerpc/include/uapi/asm/unistd.h
> +++ b/arch/powerpc/include/uapi/asm/unistd.h
> @@ -396,5 +396,6 @@
>  #define __NR_kexec_file_load 382
>  #define __NR_statx   383
>  #define __NR_rseq384
> +#define __NR_cpu_opv 385

Sorry for bike shedding, but could we invest a few more keystrokes to
make these names a bit more readable?

Thanks,
Nick

[PATCH 3.16 086/294] i40e: Initialize 64-bit statistics TX ring seqcount

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Florian Fainelli 

commit 7d6d067790289e4f61f59fa60550ca5918aa25bd upstream.

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.

Fixes: 980e9b118642 ("i40e: Add support for 64 bit netstats")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -914,6 +914,8 @@ int i40e_setup_tx_descriptors(struct i40
if (!tx_ring->tx_bi)
goto err;
 
+   u64_stats_init(_ring->syncp);
+
/* round up to nearest 4K */
tx_ring->size = tx_ring->count * sizeof(struct i40e_tx_desc);
/* add u32 for head writeback, align after this takes care of

[PATCH 3.16 086/294] i40e: Initialize 64-bit statistics TX ring seqcount

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Florian Fainelli 

commit 7d6d067790289e4f61f59fa60550ca5918aa25bd upstream.

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.

Fixes: 980e9b118642 ("i40e: Add support for 64 bit netstats")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -914,6 +914,8 @@ int i40e_setup_tx_descriptors(struct i40
if (!tx_ring->tx_bi)
goto err;
 
+   u64_stats_init(_ring->syncp);
+
/* round up to nearest 4K */
tx_ring->size = tx_ring->count * sizeof(struct i40e_tx_desc);
/* add u32 for head writeback, align after this takes care of

[PATCH 3.16 038/294] ARM: kexec: fix failure to boot crash kernel

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Russell King 

commit 0d70262a2d60886da6fe5b1fc8bbcd76cbbc306d upstream.

When kexec was converted to DTB, the dtb address was passed between
machine_kexec_prepare() and machine_kexec() using a static variable.
This is bad news if you load a crash kernel followed by a normal
kernel or vice versa - the last loaded kernel overwrites the dtb
address.

This can result in kexec failures, as (eg) we try to boot the crash
kernel with the last loaded dtb.  For example, with:

the crash kernel fails to find the dtb.

Avoid this by defining a kimage architecture structure, and store
the address to be passed in r2 there, which will either be the ATAGs
or the dtb blob.

Fixes: 4cabd1d9625c ("ARM: 7539/1: kexec: scan for dtb magic in segments")
Fixes: 42d720d1731a ("ARM: kexec: Make .text R/W in machine_kexec")
Reported-by: Keerthy 
Tested-by: Keerthy 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings 
---
 arch/arm/include/asm/kexec.h|  5 +
 arch/arm/kernel/machine_kexec.c | 11 ++-
 2 files changed, 11 insertions(+), 5 deletions(-)

--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -19,6 +19,11 @@
 
 #ifndef __ASSEMBLY__
 
+#define ARCH_HAS_KIMAGE_ARCH
+struct kimage_arch {
+   u32 kernel_r2;
+};
+
 /**
  * crash_setup_regs() - save registers for the panic kernel
  * @newregs: registers are saved here
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -29,7 +29,6 @@ extern unsigned long kexec_boot_atags;
 
 static atomic_t waiting_for_crash_ipi;
 
-static unsigned long dt_mem;
 /*
  * Provide a dummy crash_notes definition while crash dump arrives to arm.
  * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
@@ -41,6 +40,9 @@ int machine_kexec_prepare(struct kimage
__be32 header;
int i, err;
 
+   image->arch.kernel_r2 = image->start - KEXEC_ARM_ZIMAGE_OFFSET
++ KEXEC_ARM_ATAGS_OFFSET;
+
/*
 * Validate that if the current HW supports SMP, then the SW supports
 * and implements CPU hotplug for the current HW. If not, we won't be
@@ -64,8 +66,8 @@ int machine_kexec_prepare(struct kimage
if (err)
return err;
 
-   if (be32_to_cpu(header) == OF_DT_HEADER)
-   dt_mem = current_segment->mem;
+   if (header == cpu_to_be32(OF_DT_HEADER))
+   image->arch.kernel_r2 = current_segment->mem;
}
return 0;
 }
@@ -167,8 +169,7 @@ void machine_kexec(struct kimage *image)
kexec_start_address = image->start;
kexec_indirection_page = page_list;
kexec_mach_type = machine_arch_type;
-   kexec_boot_atags = dt_mem ?: image->start - KEXEC_ARM_ZIMAGE_OFFSET
-+ KEXEC_ARM_ATAGS_OFFSET;
+   kexec_boot_atags = image->arch.kernel_r2;
 
/* copy our kernel relocation code to the control code page */
reboot_entry = fncpy(reboot_code_buffer,

[PATCH 3.16 043/294] tracing: Fix kmemleak in instance_rmdir

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Chunyu Hu 

commit db9108e054700c96322b0f0028546aa4e643cf0b upstream.

Hit the kmemleak when executing instance_rmdir, it forgot releasing
mem of tracing_cpumask. With this fix, the warn does not appear any
more.

unreferenced object 0x93a8dfaa7c18 (size 8):
  comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
  hex dump (first 8 bytes):
ff ff ff ff ff ff ff ff  
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] __kmalloc_node+0xf1/0x280
[] alloc_cpumask_var_node+0x23/0x30
[] alloc_cpumask_var+0xe/0x10
[] instance_mkdir+0x90/0x240
[] tracefs_syscall_mkdir+0x40/0x70
[] vfs_mkdir+0x109/0x1b0
[] SyS_mkdir+0xd0/0x100
[] do_syscall_64+0x67/0x150
[] return_from_SYSCALL_64+0x0/0x6a
[] 0x

Link: 
http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-ch...@redhat.com

Fixes: ccfe9e42e451 ("tracing: Make tracing_cpumask available for all 
instances")
Signed-off-by: Chunyu Hu 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Ben Hutchings 
---
 kernel/trace/trace.c | 1 +
 1 file changed, 1 insertion(+)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6373,6 +6373,7 @@ static int instance_delete(const char *n
debugfs_remove_recursive(tr->dir);
free_trace_buffers(tr);
 
+   free_cpumask_var(tr->tracing_cpumask);
kfree(tr->name);
kfree(tr);
 

[PATCH 3.16 073/294] xtensa: fix cache aliasing handling code for WT cache

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Max Filippov 

commit 6d0f581d1768d3eaba15776e7dd1fdfec10cfe36 upstream.

Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:

  mm/memory.c:2152: undefined reference to `flush_dcache_page'
  mm/memory.c:2332: undefined reference to `local_flush_cache_page'
  mm/memory.c:1919: undefined reference to `local_flush_cache_range'
  mm/memory.c:4179: undefined reference to `copy_to_user_page'
  mm/memory.c:4183: undefined reference to `copy_from_user_page'

This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).

Fix this by providing the same implementation of the above functions for
both WB and WT cache.

Signed-off-by: Max Filippov 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/arch/xtensa/mm/cache.c
+++ b/arch/xtensa/mm/cache.c
@@ -63,7 +63,7 @@
 #error "HIGHMEM is not supported on cores with aliasing cache."
 #endif
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
 /*
  * Any time the kernel writes to a user page cache page, or it is about to
@@ -148,7 +148,7 @@ void local_flush_cache_page(struct vm_ar
__invalidate_icache_page_alias(virt, phys);
 }
 
-#endif
+#endif /* DCACHE_WAY_SIZE > PAGE_SIZE */
 
 void
 update_mmu_cache(struct vm_area_struct * vma, unsigned long addr, pte_t *ptep)
@@ -165,7 +165,7 @@ update_mmu_cache(struct vm_area_struct *
 
flush_tlb_page(vma, addr);
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
if (!PageReserved(page) && test_bit(PG_arch_1, >flags)) {
 
@@ -197,7 +197,7 @@ update_mmu_cache(struct vm_area_struct *
  * flush_dcache_page() on the page.
  */
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
 void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long vaddr, void *dst, const void *src,

[PATCH 3.16 081/294] USB: serial: option: add D-Link DWM-222 device ID

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hector Martin 

commit fd1b8668af59a11bb754a6c9b0051c6c5ce73b74 upstream.

Add device id for D-Link DWM-222.

Signed-off-by: Hector Martin 
Signed-off-by: Johan Hovold 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2036,6 +2036,8 @@ static const struct usb_device_id option
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e35, 0xff), 
/* D-Link DWM-222 */
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-156/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x7e11, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-156/A3 */

[PATCH 3.16 043/294] tracing: Fix kmemleak in instance_rmdir

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Chunyu Hu 

commit db9108e054700c96322b0f0028546aa4e643cf0b upstream.

Hit the kmemleak when executing instance_rmdir, it forgot releasing
mem of tracing_cpumask. With this fix, the warn does not appear any
more.

unreferenced object 0x93a8dfaa7c18 (size 8):
  comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
  hex dump (first 8 bytes):
ff ff ff ff ff ff ff ff  
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] __kmalloc_node+0xf1/0x280
[] alloc_cpumask_var_node+0x23/0x30
[] alloc_cpumask_var+0xe/0x10
[] instance_mkdir+0x90/0x240
[] tracefs_syscall_mkdir+0x40/0x70
[] vfs_mkdir+0x109/0x1b0
[] SyS_mkdir+0xd0/0x100
[] do_syscall_64+0x67/0x150
[] return_from_SYSCALL_64+0x0/0x6a
[] 0x

Link: 
http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-ch...@redhat.com

Fixes: ccfe9e42e451 ("tracing: Make tracing_cpumask available for all 
instances")
Signed-off-by: Chunyu Hu 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Ben Hutchings 
---
 kernel/trace/trace.c | 1 +
 1 file changed, 1 insertion(+)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6373,6 +6373,7 @@ static int instance_delete(const char *n
debugfs_remove_recursive(tr->dir);
free_trace_buffers(tr);
 
+   free_cpumask_var(tr->tracing_cpumask);
kfree(tr->name);
kfree(tr);
 

[PATCH 3.16 038/294] ARM: kexec: fix failure to boot crash kernel

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Russell King 

commit 0d70262a2d60886da6fe5b1fc8bbcd76cbbc306d upstream.

When kexec was converted to DTB, the dtb address was passed between
machine_kexec_prepare() and machine_kexec() using a static variable.
This is bad news if you load a crash kernel followed by a normal
kernel or vice versa - the last loaded kernel overwrites the dtb
address.

This can result in kexec failures, as (eg) we try to boot the crash
kernel with the last loaded dtb.  For example, with:

the crash kernel fails to find the dtb.

Avoid this by defining a kimage architecture structure, and store
the address to be passed in r2 there, which will either be the ATAGs
or the dtb blob.

Fixes: 4cabd1d9625c ("ARM: 7539/1: kexec: scan for dtb magic in segments")
Fixes: 42d720d1731a ("ARM: kexec: Make .text R/W in machine_kexec")
Reported-by: Keerthy 
Tested-by: Keerthy 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings 
---
 arch/arm/include/asm/kexec.h|  5 +
 arch/arm/kernel/machine_kexec.c | 11 ++-
 2 files changed, 11 insertions(+), 5 deletions(-)

--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -19,6 +19,11 @@
 
 #ifndef __ASSEMBLY__
 
+#define ARCH_HAS_KIMAGE_ARCH
+struct kimage_arch {
+   u32 kernel_r2;
+};
+
 /**
  * crash_setup_regs() - save registers for the panic kernel
  * @newregs: registers are saved here
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -29,7 +29,6 @@ extern unsigned long kexec_boot_atags;
 
 static atomic_t waiting_for_crash_ipi;
 
-static unsigned long dt_mem;
 /*
  * Provide a dummy crash_notes definition while crash dump arrives to arm.
  * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
@@ -41,6 +40,9 @@ int machine_kexec_prepare(struct kimage
__be32 header;
int i, err;
 
+   image->arch.kernel_r2 = image->start - KEXEC_ARM_ZIMAGE_OFFSET
++ KEXEC_ARM_ATAGS_OFFSET;
+
/*
 * Validate that if the current HW supports SMP, then the SW supports
 * and implements CPU hotplug for the current HW. If not, we won't be
@@ -64,8 +66,8 @@ int machine_kexec_prepare(struct kimage
if (err)
return err;
 
-   if (be32_to_cpu(header) == OF_DT_HEADER)
-   dt_mem = current_segment->mem;
+   if (header == cpu_to_be32(OF_DT_HEADER))
+   image->arch.kernel_r2 = current_segment->mem;
}
return 0;
 }
@@ -167,8 +169,7 @@ void machine_kexec(struct kimage *image)
kexec_start_address = image->start;
kexec_indirection_page = page_list;
kexec_mach_type = machine_arch_type;
-   kexec_boot_atags = dt_mem ?: image->start - KEXEC_ARM_ZIMAGE_OFFSET
-+ KEXEC_ARM_ATAGS_OFFSET;
+   kexec_boot_atags = image->arch.kernel_r2;
 
/* copy our kernel relocation code to the control code page */
reboot_entry = fncpy(reboot_code_buffer,

[PATCH 3.16 073/294] xtensa: fix cache aliasing handling code for WT cache

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Max Filippov 

commit 6d0f581d1768d3eaba15776e7dd1fdfec10cfe36 upstream.

Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:

  mm/memory.c:2152: undefined reference to `flush_dcache_page'
  mm/memory.c:2332: undefined reference to `local_flush_cache_page'
  mm/memory.c:1919: undefined reference to `local_flush_cache_range'
  mm/memory.c:4179: undefined reference to `copy_to_user_page'
  mm/memory.c:4183: undefined reference to `copy_from_user_page'

This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).

Fix this by providing the same implementation of the above functions for
both WB and WT cache.

Signed-off-by: Max Filippov 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/arch/xtensa/mm/cache.c
+++ b/arch/xtensa/mm/cache.c
@@ -63,7 +63,7 @@
 #error "HIGHMEM is not supported on cores with aliasing cache."
 #endif
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
 /*
  * Any time the kernel writes to a user page cache page, or it is about to
@@ -148,7 +148,7 @@ void local_flush_cache_page(struct vm_ar
__invalidate_icache_page_alias(virt, phys);
 }
 
-#endif
+#endif /* DCACHE_WAY_SIZE > PAGE_SIZE */
 
 void
 update_mmu_cache(struct vm_area_struct * vma, unsigned long addr, pte_t *ptep)
@@ -165,7 +165,7 @@ update_mmu_cache(struct vm_area_struct *
 
flush_tlb_page(vma, addr);
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
if (!PageReserved(page) && test_bit(PG_arch_1, >flags)) {
 
@@ -197,7 +197,7 @@ update_mmu_cache(struct vm_area_struct *
  * flush_dcache_page() on the page.
  */
 
-#if (DCACHE_WAY_SIZE > PAGE_SIZE) && XCHAL_DCACHE_IS_WRITEBACK
+#if (DCACHE_WAY_SIZE > PAGE_SIZE)
 
 void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long vaddr, void *dst, const void *src,

[PATCH 3.16 081/294] USB: serial: option: add D-Link DWM-222 device ID

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hector Martin 

commit fd1b8668af59a11bb754a6c9b0051c6c5ce73b74 upstream.

Add device id for D-Link DWM-222.

Signed-off-by: Hector Martin 
Signed-off-by: Johan Hovold 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2036,6 +2036,8 @@ static const struct usb_device_id option
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e35, 0xff), 
/* D-Link DWM-222 */
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-156/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x7e11, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-156/A3 */

[PATCH 3.16 061/294] md/raid5: add thread_group worker async_tx_issue_pending_all

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ofer Heifetz 

commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream.

Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.

Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.

Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.

Signed-off-by: Ofer Heifetz 
Signed-off-by: Shaohua Li 
Signed-off-by: Ben Hutchings 
---
 drivers/md/raid5.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5240,6 +5240,8 @@ static void raid5_do_work(struct work_st
pr_debug("%d stripes handled\n", handled);
 
spin_unlock_irq(>device_lock);
+
+   async_tx_issue_pending_all();
blk_finish_plug();
 
pr_debug("--- raid5worker inactive\n");

[PATCH 3.16 061/294] md/raid5: add thread_group worker async_tx_issue_pending_all

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ofer Heifetz 

commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream.

Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.

Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.

Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.

Signed-off-by: Ofer Heifetz 
Signed-off-by: Shaohua Li 
Signed-off-by: Ben Hutchings 
---
 drivers/md/raid5.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5240,6 +5240,8 @@ static void raid5_do_work(struct work_st
pr_debug("%d stripes handled\n", handled);
 
spin_unlock_irq(>device_lock);
+
+   async_tx_issue_pending_all();
blk_finish_plug();
 
pr_debug("--- raid5worker inactive\n");

[PATCH 3.16 160/294] l2tp: hold tunnel while handling genl TUNNEL_GET commands

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Guillaume Nault 

commit 4e4b21da3acc68a7ea55f850cacc13706b7480e9 upstream.

Use l2tp_tunnel_get() instead of l2tp_tunnel_find() so that we get
a reference on the tunnel, preventing l2tp_tunnel_destruct() from
freeing it from under us.

Also move l2tp_tunnel_get() below nlmsg_new() so that we only take
the reference when needed.

Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/l2tp/l2tp_netlink.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -349,34 +349,37 @@ static int l2tp_nl_cmd_tunnel_get(struct
 
if (!info->attrs[L2TP_ATTR_CONN_ID]) {
ret = -EINVAL;
-   goto out;
+   goto err;
}
 
tunnel_id = nla_get_u32(info->attrs[L2TP_ATTR_CONN_ID]);
 
-   tunnel = l2tp_tunnel_find(net, tunnel_id);
-   if (tunnel == NULL) {
-   ret = -ENODEV;
-   goto out;
-   }
-
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg) {
ret = -ENOMEM;
-   goto out;
+   goto err;
+   }
+
+   tunnel = l2tp_tunnel_get(net, tunnel_id);
+   if (!tunnel) {
+   ret = -ENODEV;
+   goto err_nlmsg;
}
 
ret = l2tp_nl_tunnel_send(msg, info->snd_portid, info->snd_seq,
  NLM_F_ACK, tunnel);
if (ret < 0)
-   goto err_out;
+   goto err_nlmsg_tunnel;
+
+   l2tp_tunnel_dec_refcount(tunnel);
 
return genlmsg_unicast(net, msg, info->snd_portid);
 
-err_out:
+err_nlmsg_tunnel:
+   l2tp_tunnel_dec_refcount(tunnel);
+err_nlmsg:
nlmsg_free(msg);
-
-out:
+err:
return ret;
 }
 

[PATCH 3.16 160/294] l2tp: hold tunnel while handling genl TUNNEL_GET commands

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Guillaume Nault 

commit 4e4b21da3acc68a7ea55f850cacc13706b7480e9 upstream.

Use l2tp_tunnel_get() instead of l2tp_tunnel_find() so that we get
a reference on the tunnel, preventing l2tp_tunnel_destruct() from
freeing it from under us.

Also move l2tp_tunnel_get() below nlmsg_new() so that we only take
the reference when needed.

Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/l2tp/l2tp_netlink.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -349,34 +349,37 @@ static int l2tp_nl_cmd_tunnel_get(struct
 
if (!info->attrs[L2TP_ATTR_CONN_ID]) {
ret = -EINVAL;
-   goto out;
+   goto err;
}
 
tunnel_id = nla_get_u32(info->attrs[L2TP_ATTR_CONN_ID]);
 
-   tunnel = l2tp_tunnel_find(net, tunnel_id);
-   if (tunnel == NULL) {
-   ret = -ENODEV;
-   goto out;
-   }
-
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg) {
ret = -ENOMEM;
-   goto out;
+   goto err;
+   }
+
+   tunnel = l2tp_tunnel_get(net, tunnel_id);
+   if (!tunnel) {
+   ret = -ENODEV;
+   goto err_nlmsg;
}
 
ret = l2tp_nl_tunnel_send(msg, info->snd_portid, info->snd_seq,
  NLM_F_ACK, tunnel);
if (ret < 0)
-   goto err_out;
+   goto err_nlmsg_tunnel;
+
+   l2tp_tunnel_dec_refcount(tunnel);
 
return genlmsg_unicast(net, msg, info->snd_portid);
 
-err_out:
+err_nlmsg_tunnel:
+   l2tp_tunnel_dec_refcount(tunnel);
+err_nlmsg:
nlmsg_free(msg);
-
-out:
+err:
return ret;
 }
 

[PATCH 3.16 123/294] ipv6: reset fn->rr_ptr when replacing route

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Wang 

commit 383143f31d7d3525a1dbff733d52fff917f82f15 upstream.

syzcaller reported the following use-after-free issue in rt6_select():
BUG: KASAN: use-after-free in rt6_select net/ipv6/route.c:755 [inline] at addr 
8800bc6994e8
BUG: KASAN: use-after-free in ip6_pol_route.isra.46+0x1429/0x1470 
net/ipv6/route.c:1084 at addr 8800bc6994e8
Read of size 4 by task syz-executor1/439628
CPU: 0 PID: 439628 Comm: syz-executor1 Not tainted 4.3.5+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
  88018fe435b0 81ca384d 8801d3588c00
 8800bc699380 8800bc699500 dc00 8801d40a47c0
 88018fe435d8 81735751 88018fe43660 8800bc699380
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xc1/0x124 lib/dump_stack.c:51
sctp: [Deprecated]: syz-executor0 (pid 439615) Use of struct sctp_assoc_value 
in delayed_ack socket option.
Use struct sctp_sack_info instead
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:158
 [] print_address_description mm/kasan/report.c:196 [inline]
 [] kasan_report_error+0x1b4/0x4a0 mm/kasan/report.c:285
 [] kasan_report mm/kasan/report.c:305 [inline]
 [] __asan_report_load4_noabort+0x43/0x50 
mm/kasan/report.c:325
 [] rt6_select net/ipv6/route.c:755 [inline]
 [] ip6_pol_route.isra.46+0x1429/0x1470 net/ipv6/route.c:1084
 [] ip6_pol_route_output+0x81/0xb0 net/ipv6/route.c:1203
 [] fib6_rule_action+0x1f0/0x680 net/ipv6/fib6_rules.c:95
 [] fib_rules_lookup+0x2a6/0x7a0 net/core/fib_rules.c:223
 [] fib6_rule_lookup+0xd0/0x250 net/ipv6/fib6_rules.c:41
 [] ip6_route_output+0x1d6/0x2c0 net/ipv6/route.c:1224
 [] ip6_dst_lookup_tail+0x4d2/0x890 net/ipv6/ip6_output.c:943
 [] ip6_dst_lookup_flow+0x9a/0x250 net/ipv6/ip6_output.c:1079
 [] ip6_datagram_dst_update+0x538/0xd40 net/ipv6/datagram.c:91
 [] __ip6_datagram_connect net/ipv6/datagram.c:251 [inline]
 [] ip6_datagram_connect+0x518/0xe50 net/ipv6/datagram.c:272
 [] ip6_datagram_connect_v6_only+0x63/0x90 
net/ipv6/datagram.c:284
 [] inet_dgram_connect+0x170/0x1f0 net/ipv4/af_inet.c:564
 [] SYSC_connect+0x1a7/0x2f0 net/socket.c:1582
 [] SyS_connect+0x29/0x30 net/socket.c:1563
 [] entry_SYSCALL_64_fastpath+0x12/0x17
Object at 8800bc699380, in cache ip6_dst_cache size: 384

The root cause of it is that in fib6_add_rt2node(), when it replaces an
existing route with the new one, it does not update fn->rr_ptr.
This commit resets fn->rr_ptr to NULL when it points to a route which is
replaced in fib6_add_rt2node().

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ip6_fib.c | 4 
 1 file changed, 4 insertions(+)

--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -859,6 +859,8 @@ add:
}
nsiblings = iter->rt6i_nsiblings;
fib6_purge_rt(iter, fn, info->nl_net);
+   if (fn->rr_ptr == iter)
+   fn->rr_ptr = NULL;
rt6_release(iter);
 
if (nsiblings) {
@@ -871,6 +873,8 @@ add:
if (rt6_qualify_for_ecmp(iter)) {
*ins = iter->dst.rt6_next;
fib6_purge_rt(iter, fn, info->nl_net);
+   if (fn->rr_ptr == iter)
+   fn->rr_ptr = NULL;
rt6_release(iter);
nsiblings--;
} else {

[PATCH 3.16 123/294] ipv6: reset fn->rr_ptr when replacing route

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Wang 

commit 383143f31d7d3525a1dbff733d52fff917f82f15 upstream.

syzcaller reported the following use-after-free issue in rt6_select():
BUG: KASAN: use-after-free in rt6_select net/ipv6/route.c:755 [inline] at addr 
8800bc6994e8
BUG: KASAN: use-after-free in ip6_pol_route.isra.46+0x1429/0x1470 
net/ipv6/route.c:1084 at addr 8800bc6994e8
Read of size 4 by task syz-executor1/439628
CPU: 0 PID: 439628 Comm: syz-executor1 Not tainted 4.3.5+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
  88018fe435b0 81ca384d 8801d3588c00
 8800bc699380 8800bc699500 dc00 8801d40a47c0
 88018fe435d8 81735751 88018fe43660 8800bc699380
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xc1/0x124 lib/dump_stack.c:51
sctp: [Deprecated]: syz-executor0 (pid 439615) Use of struct sctp_assoc_value 
in delayed_ack socket option.
Use struct sctp_sack_info instead
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:158
 [] print_address_description mm/kasan/report.c:196 [inline]
 [] kasan_report_error+0x1b4/0x4a0 mm/kasan/report.c:285
 [] kasan_report mm/kasan/report.c:305 [inline]
 [] __asan_report_load4_noabort+0x43/0x50 
mm/kasan/report.c:325
 [] rt6_select net/ipv6/route.c:755 [inline]
 [] ip6_pol_route.isra.46+0x1429/0x1470 net/ipv6/route.c:1084
 [] ip6_pol_route_output+0x81/0xb0 net/ipv6/route.c:1203
 [] fib6_rule_action+0x1f0/0x680 net/ipv6/fib6_rules.c:95
 [] fib_rules_lookup+0x2a6/0x7a0 net/core/fib_rules.c:223
 [] fib6_rule_lookup+0xd0/0x250 net/ipv6/fib6_rules.c:41
 [] ip6_route_output+0x1d6/0x2c0 net/ipv6/route.c:1224
 [] ip6_dst_lookup_tail+0x4d2/0x890 net/ipv6/ip6_output.c:943
 [] ip6_dst_lookup_flow+0x9a/0x250 net/ipv6/ip6_output.c:1079
 [] ip6_datagram_dst_update+0x538/0xd40 net/ipv6/datagram.c:91
 [] __ip6_datagram_connect net/ipv6/datagram.c:251 [inline]
 [] ip6_datagram_connect+0x518/0xe50 net/ipv6/datagram.c:272
 [] ip6_datagram_connect_v6_only+0x63/0x90 
net/ipv6/datagram.c:284
 [] inet_dgram_connect+0x170/0x1f0 net/ipv4/af_inet.c:564
 [] SYSC_connect+0x1a7/0x2f0 net/socket.c:1582
 [] SyS_connect+0x29/0x30 net/socket.c:1563
 [] entry_SYSCALL_64_fastpath+0x12/0x17
Object at 8800bc699380, in cache ip6_dst_cache size: 384

The root cause of it is that in fib6_add_rt2node(), when it replaces an
existing route with the new one, it does not update fn->rr_ptr.
This commit resets fn->rr_ptr to NULL when it points to a route which is
replaced in fib6_add_rt2node().

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ip6_fib.c | 4 
 1 file changed, 4 insertions(+)

--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -859,6 +859,8 @@ add:
}
nsiblings = iter->rt6i_nsiblings;
fib6_purge_rt(iter, fn, info->nl_net);
+   if (fn->rr_ptr == iter)
+   fn->rr_ptr = NULL;
rt6_release(iter);
 
if (nsiblings) {
@@ -871,6 +873,8 @@ add:
if (rt6_qualify_for_ecmp(iter)) {
*ins = iter->dst.rt6_next;
fib6_purge_rt(iter, fn, info->nl_net);
+   if (fn->rr_ptr == iter)
+   fn->rr_ptr = NULL;
rt6_release(iter);
nsiblings--;
} else {

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote:
> I've hit this 6 times now, across 3 boots:
> 
> Nov  3 11:04:54 turing-police kernel: [  547.814748] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Nov  3 20:24:11 turing-police kernel: [   60.093793] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  4 20:20:54 turing-police kernel: [86264.366955] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  5 19:17:40 turing-police kernel: [172469.769179] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  6 06:07:37 turing-police kernel: [211467.239460] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Nov  6 14:12:43 turing-police kernel: [   54.891848] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Something seems to be going astray while handling a RA packet.

Odd. I tested RA before sending the patches and again just now - no
traceback with an RCU / lock debugging kernel. What is sending the RA's
in your case? I'd like to understand the config and add a test for this.

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote:
> I've hit this 6 times now, across 3 boots:
> 
> Nov  3 11:04:54 turing-police kernel: [  547.814748] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Nov  3 20:24:11 turing-police kernel: [   60.093793] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  4 20:20:54 turing-police kernel: [86264.366955] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  5 19:17:40 turing-police kernel: [172469.769179] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> Nov  6 06:07:37 turing-police kernel: [211467.239460] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Nov  6 14:12:43 turing-police kernel: [   54.891848] BUG: sleeping function 
> called from invalid context at mm/slab.h:422
> 
> Something seems to be going astray while handling a RA packet.

Odd. I tested RA before sending the patches and again just now - no
traceback with an RCU / lock debugging kernel. What is sending the RA's
in your case? I'd like to understand the config and add a test for this.

[PATCH 3.16 067/294] powerpc/mm/hash: Free the subpage_prot_table correctly

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Aneesh Kumar K.V" 

commit 0da12a7a81f1e2255e89dc783c565e84801475a2 upstream.

Fixes: dad6f37c2602e ("powerpc: subpage_protect: Increase the array size to 
take care of 64TB")
Signed-off-by: Aneesh Kumar K.V 
Tested-by: Ram Pai 
Signed-off-by: Michael Ellerman 
Signed-off-by: Ben Hutchings 
---
 arch/powerpc/mm/subpage-prot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -36,7 +36,7 @@ void subpage_prot_free(struct mm_struct
}
}
addr = 0;
-   for (i = 0; i < 2; ++i) {
+   for (i = 0; i < (TASK_SIZE_USER64 >> 43); ++i) {
p = spt->protptrs[i];
if (!p)
continue;

[PATCH 3.16 067/294] powerpc/mm/hash: Free the subpage_prot_table correctly

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Aneesh Kumar K.V" 

commit 0da12a7a81f1e2255e89dc783c565e84801475a2 upstream.

Fixes: dad6f37c2602e ("powerpc: subpage_protect: Increase the array size to 
take care of 64TB")
Signed-off-by: Aneesh Kumar K.V 
Tested-by: Ram Pai 
Signed-off-by: Michael Ellerman 
Signed-off-by: Ben Hutchings 
---
 arch/powerpc/mm/subpage-prot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -36,7 +36,7 @@ void subpage_prot_free(struct mm_struct
}
}
addr = 0;
-   for (i = 0; i < 2; ++i) {
+   for (i = 0; i < (TASK_SIZE_USER64 >> 43); ++i) {
p = spt->protptrs[i];
if (!p)
continue;

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 9:31 AM, Eric Dumazet wrote:
> Do you have CONFIG_DEBUG_ATOMIC_SLEEP=y in your .config ?


dsa@kenny:mgmt:~/kernel-2.git$ grep CONFIG_DEBUG_ATOMIC_SLEEP
kbuild/rcu-lock-debug/.config
CONFIG_DEBUG_ATOMIC_SLEEP=y

Yep, that is on.

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

[David Ahern]

On 11/7/17 9:31 AM, Eric Dumazet wrote:
> Do you have CONFIG_DEBUG_ATOMIC_SLEEP=y in your .config ?


dsa@kenny:mgmt:~/kernel-2.git$ grep CONFIG_DEBUG_ATOMIC_SLEEP
kbuild/rcu-lock-debug/.config
CONFIG_DEBUG_ATOMIC_SLEEP=y

Yep, that is on.

Re: [PATCH] pci: fix kernel-doc build warning

[Bjorn Helgaas]

On Sun, Oct 29, 2017 at 05:07:11PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build error in kernel-doc notation:
> 
> ../drivers/pci/pci.c:3479: ERROR: Unexpected indentation.
> 
> Signed-off-by: Randy Dunlap 
> Cc:   Bjorn Helgaas 
> Cc:   linux-...@vger.kernel.org
> ---
>  drivers/pci/pci.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- lnx-414-rc7.orig/drivers/pci/pci.c
> +++ lnx-414-rc7/drivers/pci/pci.c
> @@ -3471,7 +3471,7 @@ EXPORT_SYMBOL(devm_pci_remap_cfgspace);
>   * All operations are managed and will be undone on driver detach.
>   *
>   * Returns a pointer to the remapped memory or an ERR_PTR() encoded error 
> code
> - * on failure. Usage example:
> + * on failure. Usage example::

I don't understand what's going on here.  Apparently there's something
special about two colons?  I saw plenty of double colons in
Documentation/, but I couldn't quickly find out what it means.

If kernel-doc thinks "example:" is a mistake, maybe we could recast
the sentence as "Example usage:"?  Putting a double colon here makes
the text look like a mistake to this human reader.

>   *
>   *   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   *   base = devm_pci_remap_cfg_resource(>dev, res);
> 
> 

[PATCH 3.16 054/294] perf/core: Fix locking for children siblings group read

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 2aeb1883547626d82c597cce2c99f0b9c62e2425 upstream.

We're missing ctx lock when iterating children siblings
within the perf_read path for group reading. Following
race and crash can happen:

User space doing read syscall on event group leader:

T1:
  perf_read
lock event->ctx->mutex
perf_read_group
  lock leader->child_mutex
  __perf_read_group_add(child)
list_for_each_entry(sub, >sibling_list, group_entry)

>   sub might be invalid at this point, because it could
get removed via perf_event_exit_task_context in T2

Child exiting and cleaning up its events:

T2:
  perf_event_exit_task_context
lock ctx->mutex
list_for_each_entry_safe(child_event, next, _ctx->event_list,...
  perf_event_exit_event(child)
lock ctx->lock
perf_group_detach(child)
unlock ctx->lock

>   child is removed from sibling_list without any sync
with T1 path above

...
free_event(child)

Before the child is removed from the leader's child_list,
(and thus is omitted from perf_read_group processing), we
need to ensure that perf_read_group touches child's
siblings under its ctx->lock.

Peter further notes:

| One additional note; this bug got exposed by commit:
|
|   ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
|
| which made it possible to actually trigger this code-path.

Tested-by: Andi Kleen 
Signed-off-by: Jiri Olsa 
Acked-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
Link: http://lkml.kernel.org/r/20170720141455.2106-1-jo...@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3568,7 +3568,9 @@ EXPORT_SYMBOL_GPL(perf_event_read_value)
 static void __perf_read_group_add(struct perf_event *leader,
u64 read_format, u64 *values)
 {
+   struct perf_event_context *ctx = leader->ctx;
struct perf_event *sub;
+   unsigned long flags;
int n = 1; /* skip @nr */
u64 count, enabled, running;
 
@@ -3591,11 +3593,15 @@ static void __perf_read_group_add(struct
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
 
+   raw_spin_lock_irqsave(>lock, flags);
+
list_for_each_entry(sub, >sibling_list, group_entry) {
values[n++] = perf_event_read_value(sub, , );
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
}
+
+   raw_spin_unlock_irqrestore(>lock, flags);
 }
 
 static int perf_event_read_group(struct perf_event *event,

Re: [PATCH] pci: fix kernel-doc build warning

[Bjorn Helgaas]

On Sun, Oct 29, 2017 at 05:07:11PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build error in kernel-doc notation:
> 
> ../drivers/pci/pci.c:3479: ERROR: Unexpected indentation.
> 
> Signed-off-by: Randy Dunlap 
> Cc:   Bjorn Helgaas 
> Cc:   linux-...@vger.kernel.org
> ---
>  drivers/pci/pci.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- lnx-414-rc7.orig/drivers/pci/pci.c
> +++ lnx-414-rc7/drivers/pci/pci.c
> @@ -3471,7 +3471,7 @@ EXPORT_SYMBOL(devm_pci_remap_cfgspace);
>   * All operations are managed and will be undone on driver detach.
>   *
>   * Returns a pointer to the remapped memory or an ERR_PTR() encoded error 
> code
> - * on failure. Usage example:
> + * on failure. Usage example::

I don't understand what's going on here.  Apparently there's something
special about two colons?  I saw plenty of double colons in
Documentation/, but I couldn't quickly find out what it means.

If kernel-doc thinks "example:" is a mistake, maybe we could recast
the sentence as "Example usage:"?  Putting a double colon here makes
the text look like a mistake to this human reader.

>   *
>   *   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   *   base = devm_pci_remap_cfg_resource(>dev, res);
> 
> 

[PATCH 3.16 054/294] perf/core: Fix locking for children siblings group read

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 2aeb1883547626d82c597cce2c99f0b9c62e2425 upstream.

We're missing ctx lock when iterating children siblings
within the perf_read path for group reading. Following
race and crash can happen:

User space doing read syscall on event group leader:

T1:
  perf_read
lock event->ctx->mutex
perf_read_group
  lock leader->child_mutex
  __perf_read_group_add(child)
list_for_each_entry(sub, >sibling_list, group_entry)

>   sub might be invalid at this point, because it could
get removed via perf_event_exit_task_context in T2

Child exiting and cleaning up its events:

T2:
  perf_event_exit_task_context
lock ctx->mutex
list_for_each_entry_safe(child_event, next, _ctx->event_list,...
  perf_event_exit_event(child)
lock ctx->lock
perf_group_detach(child)
unlock ctx->lock

>   child is removed from sibling_list without any sync
with T1 path above

...
free_event(child)

Before the child is removed from the leader's child_list,
(and thus is omitted from perf_read_group processing), we
need to ensure that perf_read_group touches child's
siblings under its ctx->lock.

Peter further notes:

| One additional note; this bug got exposed by commit:
|
|   ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
|
| which made it possible to actually trigger this code-path.

Tested-by: Andi Kleen 
Signed-off-by: Jiri Olsa 
Acked-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
Link: http://lkml.kernel.org/r/20170720141455.2106-1-jo...@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3568,7 +3568,9 @@ EXPORT_SYMBOL_GPL(perf_event_read_value)
 static void __perf_read_group_add(struct perf_event *leader,
u64 read_format, u64 *values)
 {
+   struct perf_event_context *ctx = leader->ctx;
struct perf_event *sub;
+   unsigned long flags;
int n = 1; /* skip @nr */
u64 count, enabled, running;
 
@@ -3591,11 +3593,15 @@ static void __perf_read_group_add(struct
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
 
+   raw_spin_lock_irqsave(>lock, flags);
+
list_for_each_entry(sub, >sibling_list, group_entry) {
values[n++] = perf_event_read_value(sub, , );
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
}
+
+   raw_spin_unlock_irqrestore(>lock, flags);
 }
 
 static int perf_event_read_group(struct perf_event *event,

Re: [PATCH] Coccinelle: use false positive annotation

[Masahiro Yamada]

2017-10-30 12:52 GMT+09:00 Julia Lawall :
>
>
> On Mon, 30 Oct 2017, Masahiro Yamada wrote:
>
>> Hi Julia,
>>
>>
>> 2017-10-29 8:43 GMT+09:00 Julia Lawall :
>> > /// is to describe the semantic patch, while //# indicates reasons
>> > for false positives.
>> >
>> > Signed-off-by: Julia Lawall 
>> >
>> > ---
>> >  scripts/coccinelle/misc/ifcol.cocci |6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/scripts/coccinelle/misc/ifcol.cocci 
>> > b/scripts/coccinelle/misc/ifcol.cocci
>> > index d0d00ef..30b248b 100644
>> > --- a/scripts/coccinelle/misc/ifcol.cocci
>> > +++ b/scripts/coccinelle/misc/ifcol.cocci
>> > @@ -3,9 +3,9 @@
>> >  /// Sometimes, code after an if that is indented is actually intended to 
>> > be
>> >  /// part of the if branch.
>> >  ///
>> > -/// This has a high rate of false positives, because Coccinelle's column
>> > -/// calculation does not distinguish between spaces and tabs, so code that
>> > -/// is not visually aligned may be considered to be in the same column.
>> > +//# This has a high rate of false positives, because Coccinelle's column
>> > +//# calculation does not distinguish between spaces and tabs, so code that
>> > +//# is not visually aligned may be considered to be in the same column.
>> >  ///
>>
>> Just a nit.
>>
>> The last /// should be turned into //
>> if you want to avoid two blank lines in a series
>> after the semantic patch information.
>>
>> (I can fix it locally if you agree with it and I am supposed to pick up 
>> this.)
>
> Thanks for detecting the problem.  It would be great if you could pick it
> up, since I haven't heard confirmation from Michal that he will start this
> again.  The change seems fine.  Thanks for your help.
>
> julia
>
>>

Fix up the second ///
and applied to linux-kbuild/misc.





-- 
Best Regards
Masahiro Yamada

Re: [PATCH] Coccinelle: use false positive annotation

[Masahiro Yamada]

2017-10-30 12:52 GMT+09:00 Julia Lawall :
>
>
> On Mon, 30 Oct 2017, Masahiro Yamada wrote:
>
>> Hi Julia,
>>
>>
>> 2017-10-29 8:43 GMT+09:00 Julia Lawall :
>> > /// is to describe the semantic patch, while //# indicates reasons
>> > for false positives.
>> >
>> > Signed-off-by: Julia Lawall 
>> >
>> > ---
>> >  scripts/coccinelle/misc/ifcol.cocci |6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/scripts/coccinelle/misc/ifcol.cocci 
>> > b/scripts/coccinelle/misc/ifcol.cocci
>> > index d0d00ef..30b248b 100644
>> > --- a/scripts/coccinelle/misc/ifcol.cocci
>> > +++ b/scripts/coccinelle/misc/ifcol.cocci
>> > @@ -3,9 +3,9 @@
>> >  /// Sometimes, code after an if that is indented is actually intended to 
>> > be
>> >  /// part of the if branch.
>> >  ///
>> > -/// This has a high rate of false positives, because Coccinelle's column
>> > -/// calculation does not distinguish between spaces and tabs, so code that
>> > -/// is not visually aligned may be considered to be in the same column.
>> > +//# This has a high rate of false positives, because Coccinelle's column
>> > +//# calculation does not distinguish between spaces and tabs, so code that
>> > +//# is not visually aligned may be considered to be in the same column.
>> >  ///
>>
>> Just a nit.
>>
>> The last /// should be turned into //
>> if you want to avoid two blank lines in a series
>> after the semantic patch information.
>>
>> (I can fix it locally if you agree with it and I am supposed to pick up 
>> this.)
>
> Thanks for detecting the problem.  It would be great if you could pick it
> up, since I haven't heard confirmation from Michal that he will start this
> again.  The change seems fine.  Thanks for your help.
>
> julia
>
>>

Fix up the second ///
and applied to linux-kbuild/misc.





-- 
Best Regards
Masahiro Yamada

[PATCH 3.16 062/294] workqueue: implicit ordered attribute should be overridable

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 0a94efb5acbb6980d7c9ab604372d93cd507e4d8 upstream.

5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered") automatically enabled ordered attribute for unbound
workqueues w/ max_active == 1.  Because ordered workqueues reject
max_active and some attribute changes, this implicit ordered mode
broke cases where the user creates an unbound workqueue w/ max_active
== 1 and later explicitly changes the related attributes.

This patch distinguishes explicit and implicit ordered setting and
overrides from attribute changes if implict.

Signed-off-by: Tejun Heo 
Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be 
ordered")
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 include/linux/workqueue.h |  4 +++-
 kernel/workqueue.c| 13 +
 2 files changed, 12 insertions(+), 5 deletions(-)

--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -315,6 +315,7 @@ enum {
 
__WQ_DRAINING   = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered */
+   __WQ_ORDERED_EXPLICIT   = 1 << 18, /* internal: 
alloc_ordered_workqueue() */
 
WQ_MAX_ACTIVE   = 512,/* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU  = 4,  /* 4 * #cpus for unbound wq */
@@ -412,7 +413,8 @@ __alloc_workqueue_key(const char *fmt, u
  * Pointer to the allocated workqueue on success, %NULL on failure.
  */
 #define alloc_ordered_workqueue(fmt, flags, args...)   \
-   alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | (flags), 1, ##args)
+   alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED |\
+   __WQ_ORDERED_EXPLICIT | (flags), 1, ##args)
 
 #define create_workqueue(name) \
alloc_workqueue("%s", WQ_MEM_RECLAIM, 1, (name))
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3324,7 +3324,7 @@ int workqueue_sysfs_register(struct work
 * attributes breaks ordering guarantee.  Disallow exposing ordered
 * workqueues.
 */
-   if (WARN_ON(wq->flags & __WQ_ORDERED))
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
return -EINVAL;
 
wq->wq_dev = wq_dev = kzalloc(sizeof(*wq_dev), GFP_KERNEL);
@@ -3907,8 +3907,12 @@ int apply_workqueue_attrs(struct workque
return -EINVAL;
 
/* creating multiple pwqs breaks ordering guarantee */
-   if (WARN_ON((wq->flags & __WQ_ORDERED) && !list_empty(>pwqs)))
-   return -EINVAL;
+   if (!list_empty(>pwqs)) {
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
+   return -EINVAL;
+
+   wq->flags &= ~__WQ_ORDERED;
+   }
 
pwq_tbl = kzalloc(wq_numa_tbl_len * sizeof(pwq_tbl[0]), GFP_KERNEL);
new_attrs = alloc_workqueue_attrs(GFP_KERNEL);
@@ -4354,13 +4358,14 @@ void workqueue_set_max_active(struct wor
struct pool_workqueue *pwq;
 
/* disallow meddling with max_active for ordered workqueues */
-   if (WARN_ON(wq->flags & __WQ_ORDERED))
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
return;
 
max_active = wq_clamp_max_active(max_active, wq->flags, wq->name);
 
mutex_lock(>mutex);
 
+   wq->flags &= ~__WQ_ORDERED;
wq->saved_max_active = max_active;
 
for_each_pwq(pwq, wq)

[PATCH 3.16 062/294] workqueue: implicit ordered attribute should be overridable

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 0a94efb5acbb6980d7c9ab604372d93cd507e4d8 upstream.

5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered") automatically enabled ordered attribute for unbound
workqueues w/ max_active == 1.  Because ordered workqueues reject
max_active and some attribute changes, this implicit ordered mode
broke cases where the user creates an unbound workqueue w/ max_active
== 1 and later explicitly changes the related attributes.

This patch distinguishes explicit and implicit ordered setting and
overrides from attribute changes if implict.

Signed-off-by: Tejun Heo 
Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be 
ordered")
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 include/linux/workqueue.h |  4 +++-
 kernel/workqueue.c| 13 +
 2 files changed, 12 insertions(+), 5 deletions(-)

--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -315,6 +315,7 @@ enum {
 
__WQ_DRAINING   = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered */
+   __WQ_ORDERED_EXPLICIT   = 1 << 18, /* internal: 
alloc_ordered_workqueue() */
 
WQ_MAX_ACTIVE   = 512,/* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU  = 4,  /* 4 * #cpus for unbound wq */
@@ -412,7 +413,8 @@ __alloc_workqueue_key(const char *fmt, u
  * Pointer to the allocated workqueue on success, %NULL on failure.
  */
 #define alloc_ordered_workqueue(fmt, flags, args...)   \
-   alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | (flags), 1, ##args)
+   alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED |\
+   __WQ_ORDERED_EXPLICIT | (flags), 1, ##args)
 
 #define create_workqueue(name) \
alloc_workqueue("%s", WQ_MEM_RECLAIM, 1, (name))
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3324,7 +3324,7 @@ int workqueue_sysfs_register(struct work
 * attributes breaks ordering guarantee.  Disallow exposing ordered
 * workqueues.
 */
-   if (WARN_ON(wq->flags & __WQ_ORDERED))
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
return -EINVAL;
 
wq->wq_dev = wq_dev = kzalloc(sizeof(*wq_dev), GFP_KERNEL);
@@ -3907,8 +3907,12 @@ int apply_workqueue_attrs(struct workque
return -EINVAL;
 
/* creating multiple pwqs breaks ordering guarantee */
-   if (WARN_ON((wq->flags & __WQ_ORDERED) && !list_empty(>pwqs)))
-   return -EINVAL;
+   if (!list_empty(>pwqs)) {
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
+   return -EINVAL;
+
+   wq->flags &= ~__WQ_ORDERED;
+   }
 
pwq_tbl = kzalloc(wq_numa_tbl_len * sizeof(pwq_tbl[0]), GFP_KERNEL);
new_attrs = alloc_workqueue_attrs(GFP_KERNEL);
@@ -4354,13 +4358,14 @@ void workqueue_set_max_active(struct wor
struct pool_workqueue *pwq;
 
/* disallow meddling with max_active for ordered workqueues */
-   if (WARN_ON(wq->flags & __WQ_ORDERED))
+   if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))
return;
 
max_active = wq_clamp_max_active(max_active, wq->flags, wq->name);
 
mutex_lock(>mutex);
 
+   wq->flags &= ~__WQ_ORDERED;
wq->saved_max_active = max_active;
 
for_each_pwq(pwq, wq)

[PATCH 3.16 034/294] workqueue: restore WQ_UNBOUND/max_active==1 to be ordered

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 5c0338c68706be53b3dc472e4308961c36e4ece1 upstream.

The combination of WQ_UNBOUND and max_active == 1 used to imply
ordered execution.  After NUMA affinity 4c16bd327c74 ("workqueue:
implement NUMA affinity for unbound workqueues"), this is no longer
true due to per-node worker pools.

While the right way to create an ordered workqueue is
alloc_ordered_workqueue(), the documentation has been misleading for a
long time and people do use WQ_UNBOUND and max_active == 1 for ordered
workqueues which can lead to subtle bugs which are very difficult to
trigger.

It's unlikely that we'd see noticeable performance impact by enforcing
ordering on WQ_UNBOUND / max_active == 1 workqueues.  Let's
automatically set __WQ_ORDERED for those workqueues.

Signed-off-by: Tejun Heo 
Reported-by: Christoph Hellwig 
Reported-by: Alexei Potashnik 
Fixes: 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound 
workqueues")
Signed-off-by: Ben Hutchings 
---
 kernel/workqueue.c | 10 ++
 1 file changed, 10 insertions(+)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4152,6 +4152,16 @@ struct workqueue_struct *__alloc_workque
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
 
+   /*
+* Unbound && max_active == 1 used to imply ordered, which is no
+* longer the case on NUMA machines due to per-node pools.  While
+* alloc_ordered_workqueue() is the right way to create an ordered
+* workqueue, keep the previous behavior to avoid subtle breakages
+* on NUMA.
+*/
+   if ((flags & WQ_UNBOUND) && max_active == 1)
+   flags |= __WQ_ORDERED;
+
/* see the comment above the definition of WQ_POWER_EFFICIENT */
if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
flags |= WQ_UNBOUND;

[PATCH 3.16 034/294] workqueue: restore WQ_UNBOUND/max_active==1 to be ordered

[Ben Hutchings]

3.16.50-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 5c0338c68706be53b3dc472e4308961c36e4ece1 upstream.

The combination of WQ_UNBOUND and max_active == 1 used to imply
ordered execution.  After NUMA affinity 4c16bd327c74 ("workqueue:
implement NUMA affinity for unbound workqueues"), this is no longer
true due to per-node worker pools.

While the right way to create an ordered workqueue is
alloc_ordered_workqueue(), the documentation has been misleading for a
long time and people do use WQ_UNBOUND and max_active == 1 for ordered
workqueues which can lead to subtle bugs which are very difficult to
trigger.

It's unlikely that we'd see noticeable performance impact by enforcing
ordering on WQ_UNBOUND / max_active == 1 workqueues.  Let's
automatically set __WQ_ORDERED for those workqueues.

Signed-off-by: Tejun Heo 
Reported-by: Christoph Hellwig 
Reported-by: Alexei Potashnik 
Fixes: 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound 
workqueues")
Signed-off-by: Ben Hutchings 
---
 kernel/workqueue.c | 10 ++
 1 file changed, 10 insertions(+)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4152,6 +4152,16 @@ struct workqueue_struct *__alloc_workque
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
 
+   /*
+* Unbound && max_active == 1 used to imply ordered, which is no
+* longer the case on NUMA machines due to per-node pools.  While
+* alloc_ordered_workqueue() is the right way to create an ordered
+* workqueue, keep the previous behavior to avoid subtle breakages
+* on NUMA.
+*/
+   if ((flags & WQ_UNBOUND) && max_active == 1)
+   flags |= __WQ_ORDERED;
+
/* see the comment above the definition of WQ_POWER_EFFICIENT */
if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
flags |= WQ_UNBOUND;