[PATCH 4.4 45/72] USB: serial: ftdi_sio: add RT Systems VX-8 cable

[Greg Kroah-Hartman]

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

--

From: Major Hayden 

commit 9608e5c0f079390473b484ef92334dfd3431bb89 upstream.

This patch adds a device ID for the RT Systems cable used to
program Yaesu VX-8R/VX-8DR handheld radios. It uses the main
FTDI VID instead of the common RT Systems VID.

Signed-off-by: Major Hayden 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/serial/ftdi_sio.c |1 +
 drivers/usb/serial/ftdi_sio_ids.h |3 +++
 2 files changed, 4 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -773,6 +773,7 @@ static const struct usb_device_id id_tab
.driver_info = (kernel_ulong_t)_NDI_device_quirk },
{ USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
{ USB_DEVICE(NOVITUS_VID, NOVITUS_BONO_E_PID) },
+   { USB_DEVICE(FTDI_VID, RTSYSTEMS_USB_VX8_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -922,6 +922,9 @@
 /*
  * RT Systems programming cables for various ham radios
  */
+/* This device uses the VID of FTDI */
+#define RTSYSTEMS_USB_VX8_PID   0x9e50  /* USB-VX8 USB to 7 pin modular plug 
for Yaesu VX-8 radio */
+
 #define RTSYSTEMS_VID  0x2100  /* Vendor ID */
 #define RTSYSTEMS_USB_S03_PID  0x9001  /* RTS-03 USB to Serial Adapter */
 #define RTSYSTEMS_USB_59_PID   0x9e50  /* USB-59 USB to 8 pin plug */

[PATCH 4.4 43/72] scsi: virtio_scsi: always read VPD pages for multiqueue too

[Greg Kroah-Hartman]

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

--

From: Paolo Bonzini 

commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream.

Multi-queue virtio-scsi uses a different scsi_host_template struct.  Add
the .device_alloc field there, too.

Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: sta...@vger.kernel.org
Cc: David Gibson 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Fam Zheng 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Martin K. Petersen 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/virtio_scsi.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -819,6 +819,7 @@ static struct scsi_host_template virtscs
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
 
+   .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
.use_clustering = ENABLE_CLUSTERING,

[PATCH 4.4 15/72] dm ioctl: remove double parentheses

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.

The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().

Also remove another double parentheses that doesn't cause a warning.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Mike Snitzer 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-ioctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1773,12 +1773,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
 
-   if ((cmd == DM_DEV_CREATE_CMD)) {
+   if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
-   } else if ((*param->uuid && *param->name)) {
+   } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}

[PATCH 4.4 15/72] dm ioctl: remove double parentheses

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.

The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().

Also remove another double parentheses that doesn't cause a warning.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Mike Snitzer 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-ioctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1773,12 +1773,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
 
-   if ((cmd == DM_DEV_CREATE_CMD)) {
+   if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
-   } else if ((*param->uuid && *param->name)) {
+   } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}

[PATCH 4.4 17/72] netfilter: nf_nat_h323: fix logical-not-parentheses warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit eee6ebbac18a189ef33d25ea9b8bcae176515e49 upstream.

Clang produces the following warning:

net/ipv4/netfilter/nf_nat_h323.c:553:6: error:
logical not is only applied to the left hand side of this comparison
  [-Werror,-Wlogical-not-parentheses]
if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
^
add parentheses after the '!' to evaluate the comparison first
add parentheses around left hand side expression to silence this warning

There's not necessarily a bug here, but it's cleaner to return early,
ex:

if (x)
  return
...

rather than:

if (x == 0)
  ...
else
  return

Also added a return code check that seemed to be missing in one
instance.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Pablo Neira Ayuso 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/ipv4/netfilter/nf_nat_h323.c |   57 ---
 1 file changed, 30 insertions(+), 27 deletions(-)

--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -252,16 +252,16 @@ static int nat_rtp_rtcp(struct sk_buff *
if (set_h245_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
  htons((port & htons(1)) ? nated_port + 1 :
-   nated_port)) == 0) {
-   /* Save ports */
-   info->rtp_port[i][dir] = rtp_port;
-   info->rtp_port[i][!dir] = htons(nated_port);
-   } else {
+   nated_port))) {
nf_ct_unexpect_related(rtp_exp);
nf_ct_unexpect_related(rtcp_exp);
return -1;
}
 
+   /* Save ports */
+   info->rtp_port[i][dir] = rtp_port;
+   info->rtp_port[i][!dir] = htons(nated_port);
+
/* Success */
pr_debug("nf_nat_h323: expect RTP %pI4:%hu->%pI4:%hu\n",
 _exp->tuple.src.u3.ip,
@@ -370,15 +370,15 @@ static int nat_h245(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
pr_debug("nf_nat_q931: expect H.245 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
 ntohs(exp->tuple.src.u.tcp.port),
@@ -462,24 +462,27 @@ static int nat_q931(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, 0, [idx],
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-
-   /* Fix for Gnomemeeting */
-   if (idx > 0 &&
-   get_h225_addr(ct, *data, [0], , ) &&
-   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
-   set_h225_addr(skb, protoff, data, 0, [0],
- >tuplehash[!dir].tuple.dst.u3,
- info->sig_port[!dir]);
-   }
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
+   /* Fix for Gnomemeeting */
+   if (idx > 0 &&
+   get_h225_addr(ct, *data, [0], , ) &&
+   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
+   if (set_h225_addr(skb, protoff, data, 0, [0],
+ >tuplehash[!dir].tuple.dst.u3,
+ info->sig_port[!dir])) {
+   nf_ct_unexpect_related(exp);
+   return -1;
+   }
+   }
+
/* Success */
pr_debug("nf_nat_ras: expect Q.931 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
@@ -550,9 +553,9 @@ static int nat_callforwarding(struct sk_
}
 
/* Modify signal */
-   if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
-  >tuplehash[!dir].tuple.dst.u3,
-  htons(nated_port)) == 0) {
+   if (set_h225_addr(skb, protoff, data, 

[PATCH 4.4 17/72] netfilter: nf_nat_h323: fix logical-not-parentheses warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit eee6ebbac18a189ef33d25ea9b8bcae176515e49 upstream.

Clang produces the following warning:

net/ipv4/netfilter/nf_nat_h323.c:553:6: error:
logical not is only applied to the left hand side of this comparison
  [-Werror,-Wlogical-not-parentheses]
if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
^
add parentheses after the '!' to evaluate the comparison first
add parentheses around left hand side expression to silence this warning

There's not necessarily a bug here, but it's cleaner to return early,
ex:

if (x)
  return
...

rather than:

if (x == 0)
  ...
else
  return

Also added a return code check that seemed to be missing in one
instance.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Pablo Neira Ayuso 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/ipv4/netfilter/nf_nat_h323.c |   57 ---
 1 file changed, 30 insertions(+), 27 deletions(-)

--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -252,16 +252,16 @@ static int nat_rtp_rtcp(struct sk_buff *
if (set_h245_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
  htons((port & htons(1)) ? nated_port + 1 :
-   nated_port)) == 0) {
-   /* Save ports */
-   info->rtp_port[i][dir] = rtp_port;
-   info->rtp_port[i][!dir] = htons(nated_port);
-   } else {
+   nated_port))) {
nf_ct_unexpect_related(rtp_exp);
nf_ct_unexpect_related(rtcp_exp);
return -1;
}
 
+   /* Save ports */
+   info->rtp_port[i][dir] = rtp_port;
+   info->rtp_port[i][!dir] = htons(nated_port);
+
/* Success */
pr_debug("nf_nat_h323: expect RTP %pI4:%hu->%pI4:%hu\n",
 _exp->tuple.src.u3.ip,
@@ -370,15 +370,15 @@ static int nat_h245(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
pr_debug("nf_nat_q931: expect H.245 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
 ntohs(exp->tuple.src.u.tcp.port),
@@ -462,24 +462,27 @@ static int nat_q931(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, 0, [idx],
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-
-   /* Fix for Gnomemeeting */
-   if (idx > 0 &&
-   get_h225_addr(ct, *data, [0], , ) &&
-   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
-   set_h225_addr(skb, protoff, data, 0, [0],
- >tuplehash[!dir].tuple.dst.u3,
- info->sig_port[!dir]);
-   }
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
+   /* Fix for Gnomemeeting */
+   if (idx > 0 &&
+   get_h225_addr(ct, *data, [0], , ) &&
+   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
+   if (set_h225_addr(skb, protoff, data, 0, [0],
+ >tuplehash[!dir].tuple.dst.u3,
+ info->sig_port[!dir])) {
+   nf_ct_unexpect_related(exp);
+   return -1;
+   }
+   }
+
/* Success */
pr_debug("nf_nat_ras: expect Q.931 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
@@ -550,9 +553,9 @@ static int nat_callforwarding(struct sk_
}
 
/* Modify signal */
-   if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
-  >tuplehash[!dir].tuple.dst.u3,
-  htons(nated_port)) == 0) {
+   if (set_h225_addr(skb, protoff, data, dataoff, taddr,
+ >tuplehash[!dir].tuple.dst.u3,
+ htons(nated_port))) {
 

[PATCH 4.4 19/72] cpumask: Add helper cpumask_available()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.

With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.

Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:

kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]

Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.

Signed-off-by: Matthias Kaehlcke 
Cc: Grant Grundler 
Cc: Rusty Russell 
Cc: Greg Hackmann 
Cc: Michael Davidson 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20170412182030.83657-1-...@chromium.org
Signed-off-by: Thomas Gleixner 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/cpumask.h |   10 ++
 1 file changed, 10 insertions(+)

--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -661,6 +661,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
 void free_cpumask_var(cpumask_var_t mask);
 void free_bootmem_cpumask_var(cpumask_var_t mask);
 
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return mask != NULL;
+}
+
 #else
 typedef struct cpumask cpumask_var_t[1];
 
@@ -701,6 +706,11 @@ static inline void free_cpumask_var(cpum
 static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 }
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return true;
+}
 #endif /* CONFIG_CPUMASK_OFFSTACK */
 
 /* It's common to want to use cpu_all_mask in struct member initializers,

[PATCH 4.4 19/72] cpumask: Add helper cpumask_available()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.

With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.

Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:

kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]

Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.

Signed-off-by: Matthias Kaehlcke 
Cc: Grant Grundler 
Cc: Rusty Russell 
Cc: Greg Hackmann 
Cc: Michael Davidson 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20170412182030.83657-1-...@chromium.org
Signed-off-by: Thomas Gleixner 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/cpumask.h |   10 ++
 1 file changed, 10 insertions(+)

--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -661,6 +661,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
 void free_cpumask_var(cpumask_var_t mask);
 void free_bootmem_cpumask_var(cpumask_var_t mask);
 
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return mask != NULL;
+}
+
 #else
 typedef struct cpumask cpumask_var_t[1];
 
@@ -701,6 +706,11 @@ static inline void free_cpumask_var(cpum
 static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 }
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return true;
+}
 #endif /* CONFIG_CPUMASK_OFFSTACK */
 
 /* It's common to want to use cpu_all_mask in struct member initializers,

[PATCH 4.4 11/72] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

[Greg Kroah-Hartman]

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

--

From: Masami Hiramatsu 

commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.

Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.

Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.

Link: 
http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox

Signed-off-by: Masami Hiramatsu 
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/kprobes/core.c |9 +
 kernel/kprobes.c   |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -402,6 +403,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
 }
 
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+   set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+   module_memfree(page);
+}
+
 static int arch_copy_kprobe(struct kprobe *p)
 {
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
 }
 
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
 {
module_memfree(page);
 }

[PATCH 4.4 11/72] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

[Greg Kroah-Hartman]

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

--

From: Masami Hiramatsu 

commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.

Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.

Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.

Link: 
http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox

Signed-off-by: Masami Hiramatsu 
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/kprobes/core.c |9 +
 kernel/kprobes.c   |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -402,6 +403,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
 }
 
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+   set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+   module_memfree(page);
+}
+
 static int arch_copy_kprobe(struct kprobe *p)
 {
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
 }
 
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
 {
module_memfree(page);
 }

[PATCH 4.4 20/72] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Paul Moore 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 security/selinux/ss/services.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
 
k = 0;
-   while (p_in->perms && p_in->perms[k]) {
+   while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;

[PATCH 4.4 20/72] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Paul Moore 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 security/selinux/ss/services.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
 
k = 0;
-   while (p_in->perms && p_in->perms[k]) {
+   while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;

[PATCH 4.4 56/72] Input: i8042 - enable MUX on Sony VAIO VGN-CS series to fix touchpad

[Greg Kroah-Hartman]

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

--

From: Ondrej Zary 

commit 04bb1719c4de94700056241d4c0fe3c1413f5aff upstream.

The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
VAIO machines by the nomux blacklist, the data from touch sensor
buttons and touchpad are combined. The protocol used by the buttons is
probably similar to the touchpad protocol (both are Synaptics) so both
devices get enabled. The controller combines the data, creating a mess
which results in random button clicks, touchpad stopping working and
lost sync error messages:
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: issuing reconnect request

Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
With MUX enabled, touch sensor buttons are detected as separate device
(and left disabled as there's currently no driver), fixing all touchpad
problems.

Signed-off-by: Ondrej Zary 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |   17 +
 1 file changed, 17 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -530,6 +530,20 @@ static const struct dmi_system_id __init
{ }
 };
 
+static const struct dmi_system_id i8042_dmi_forcemux_table[] __initconst = {
+   {
+   /*
+* Sony Vaio VGN-CS series require MUX or the touch sensor
+* buttons will disturb touchpad operation
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+   },
+   },
+   { }
+};
+
 /*
  * On some Asus laptops, just running self tests cause problems.
  */
@@ -1230,6 +1244,9 @@ static int __init i8042_platform_init(vo
if (dmi_check_system(i8042_dmi_nomux_table))
i8042_nomux = true;
 
+   if (dmi_check_system(i8042_dmi_forcemux_table))
+   i8042_nomux = false;
+
if (dmi_check_system(i8042_dmi_notimeout_table))
i8042_notimeout = true;
 

[PATCH 4.4 56/72] Input: i8042 - enable MUX on Sony VAIO VGN-CS series to fix touchpad

[Greg Kroah-Hartman]

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

--

From: Ondrej Zary 

commit 04bb1719c4de94700056241d4c0fe3c1413f5aff upstream.

The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
VAIO machines by the nomux blacklist, the data from touch sensor
buttons and touchpad are combined. The protocol used by the buttons is
probably similar to the touchpad protocol (both are Synaptics) so both
devices get enabled. The controller combines the data, creating a mess
which results in random button clicks, touchpad stopping working and
lost sync error messages:
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: issuing reconnect request

Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
With MUX enabled, touch sensor buttons are detected as separate device
(and left disabled as there's currently no driver), fixing all touchpad
problems.

Signed-off-by: Ondrej Zary 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |   17 +
 1 file changed, 17 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -530,6 +530,20 @@ static const struct dmi_system_id __init
{ }
 };
 
+static const struct dmi_system_id i8042_dmi_forcemux_table[] __initconst = {
+   {
+   /*
+* Sony Vaio VGN-CS series require MUX or the touch sensor
+* buttons will disturb touchpad operation
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+   },
+   },
+   { }
+};
+
 /*
  * On some Asus laptops, just running self tests cause problems.
  */
@@ -1230,6 +1244,9 @@ static int __init i8042_platform_init(vo
if (dmi_check_system(i8042_dmi_nomux_table))
i8042_nomux = true;
 
+   if (dmi_check_system(i8042_dmi_forcemux_table))
+   i8042_nomux = false;
+
if (dmi_check_system(i8042_dmi_notimeout_table))
i8042_notimeout = true;
 

[PATCH 4.4 58/72] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 0ea66f76ba17a4b229caaadd77de694111b21769 upstream.

GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt |9 +
 1 file changed, 9 insertions(+)

--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:

[PATCH 4.4 58/72] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 0ea66f76ba17a4b229caaadd77de694111b21769 upstream.

GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt |9 +
 1 file changed, 9 insertions(+)

--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:

Re: WARNING: lock held when returning to user space!

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 4:27 PM, Jens Axboe  wrote:
> On 4/6/18 7:02 AM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +)
>> Merge tag 'armsoc-drivers' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=31e8daa8b3fc129e75f2
>>
>> So far this crash happened 9 times on upstream.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6407930337296384
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=4942413340606464
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=4764483918495744
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=-5813481738265533882
>> compiler: gcc (GCC) 8.0.1 20180301 (experimental)
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+31e8daa8b3fc129e7...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>>
>> 
>> WARNING: lock held when returning to user space!
>> 4.16.0+ #3 Not tainted
>> 
>> syzkaller433111/4462 is leaving the kernel with locks still held!
>> 1 lock held by syzkaller433111/4462:
>>   #0: 03a06fae (>lo_ctl_mutex/1){+.+.}, at: lo_ioctl+0x8d/0x1ec0
>> drivers/block/loop.c:1363
>
> Is this a new regression? Omar did just fiddle with the locking a bit,
> seems suspicious.

Looking at:
https://syzkaller.appspot.com/bug?extid=31e8daa8b3fc129e75f2
It first happened 4 hours ago and 9 times since then, so probably a
just introduced regression.


> --
> Jens Axboe
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/0e998b77-14f0-aee0-8d32-bc1dd96fcc4c%40kernel.dk.
> For more options, visit https://groups.google.com/d/optout.

Re: WARNING: lock held when returning to user space!

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 4:27 PM, Jens Axboe  wrote:
> On 4/6/18 7:02 AM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +)
>> Merge tag 'armsoc-drivers' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=31e8daa8b3fc129e75f2
>>
>> So far this crash happened 9 times on upstream.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6407930337296384
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=4942413340606464
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=4764483918495744
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=-5813481738265533882
>> compiler: gcc (GCC) 8.0.1 20180301 (experimental)
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+31e8daa8b3fc129e7...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>>
>> 
>> WARNING: lock held when returning to user space!
>> 4.16.0+ #3 Not tainted
>> 
>> syzkaller433111/4462 is leaving the kernel with locks still held!
>> 1 lock held by syzkaller433111/4462:
>>   #0: 03a06fae (>lo_ctl_mutex/1){+.+.}, at: lo_ioctl+0x8d/0x1ec0
>> drivers/block/loop.c:1363
>
> Is this a new regression? Omar did just fiddle with the locking a bit,
> seems suspicious.

Looking at:
https://syzkaller.appspot.com/bug?extid=31e8daa8b3fc129e75f2
It first happened 4 hours ago and 9 times since then, so probably a
just introduced regression.


> --
> Jens Axboe
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/0e998b77-14f0-aee0-8d32-bc1dd96fcc4c%40kernel.dk.
> For more options, visit https://groups.google.com/d/optout.

[PATCH 4.4 59/72] ARM: dts: dra7: Add power hold and power controller properties to palmas

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 7c62de5f3fc92291decc0dac5f36949bdc3fb575 upstream.

Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/dra7-evm.dts |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -410,6 +410,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+   ti,palmas-override-powerhold;
+   ti,system-power-controller;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";

[PATCH 4.4 59/72] ARM: dts: dra7: Add power hold and power controller properties to palmas

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 7c62de5f3fc92291decc0dac5f36949bdc3fb575 upstream.

Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/dra7-evm.dts |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -410,6 +410,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+   ti,palmas-override-powerhold;
+   ti,system-power-controller;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";

[PATCH 4.4 60/72] ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 1f166499ce006b3770a3166122eda64e160736ab upstream.

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -411,6 +411,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";

[PATCH 4.4 60/72] ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property

[Greg Kroah-Hartman]

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

--

From: Keerthy 

commit 1f166499ce006b3770a3166122eda64e160736ab upstream.

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -411,6 +411,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";

[PATCH 4.4 61/72] md/raid10: reset the first at the end of loop

[Greg Kroah-Hartman]

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

--

From: Guoqing Jiang 

commit 6f287ca6046edd34ed83aafb7f9033c9c2e809e2 upstream.

We need to set "first = 0' at the end of rdev_for_each
loop, so we can get the array's min_offset_diff correctly
otherwise min_offset_diff just means the last rdev's
offset diff.

[only the first chunk, due to b506335e5d2b ("md/raid10: skip spare disk as
'first' disk") being already applied - gregkh]

Suggested-by: NeilBrown 
Signed-off-by: Guoqing Jiang 
Reviewed-by: NeilBrown 
Signed-off-by: Shaohua Li 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid10.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3638,6 +3638,7 @@ static int run(struct mddev *mddev)
 
if (blk_queue_discard(bdev_get_queue(rdev->bdev)))
discard_supported = true;
+   first = 0;
}
 
if (mddev->queue) {

[PATCH 4.4 61/72] md/raid10: reset the first at the end of loop

[Greg Kroah-Hartman]

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

--

From: Guoqing Jiang 

commit 6f287ca6046edd34ed83aafb7f9033c9c2e809e2 upstream.

We need to set "first = 0' at the end of rdev_for_each
loop, so we can get the array's min_offset_diff correctly
otherwise min_offset_diff just means the last rdev's
offset diff.

[only the first chunk, due to b506335e5d2b ("md/raid10: skip spare disk as
'first' disk") being already applied - gregkh]

Suggested-by: NeilBrown 
Signed-off-by: Guoqing Jiang 
Reviewed-by: NeilBrown 
Signed-off-by: Shaohua Li 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid10.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3638,6 +3638,7 @@ static int run(struct mddev *mddev)
 
if (blk_queue_discard(bdev_get_queue(rdev->bdev)))
discard_supported = true;
+   first = 0;
}
 
if (mddev->queue) {

[PATCH 4.4 48/72] mei: remove dev_err message on an unsupported ioctl

[Greg Kroah-Hartman]

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

--

From: Colin Ian King 

commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream.

Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.

Signed-off-by: Colin Ian King 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/main.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -571,7 +571,6 @@ static long mei_ioctl(struct file *file,
break;
 
default:
-   dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd);
rets = -ENOIOCTLCMD;
}
 

[PATCH 4.4 62/72] net: hns: Fix ethtool private flags

[Greg Kroah-Hartman]

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

--

From: Matthias Brugger 

commit d61d263c8d82db7c4404a29ebc29674b1c0c05c9 upstream.

The driver implementation returns support for private flags, while
no private flags are present. When asked for the number of private
flags it returns the number of statistic flag names.

Fix this by returning EOPNOTSUPP for not implemented ethtool flags.

Signed-off-by: Matthias Brugger 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |4 +++-
 4 files changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -648,7 +648,7 @@ static void hns_gmac_get_strings(u32 str
 
 static int hns_gmac_get_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return ARRAY_SIZE(g_gmac_stats_string);
 
return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -384,7 +384,7 @@ void hns_ppe_update_stats(struct hns_ppe
 
 int hns_ppe_get_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return ETH_PPE_STATIC_NUM;
return 0;
 }
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -807,7 +807,7 @@ void hns_rcb_get_stats(struct hnae_queue
  */
 int hns_rcb_get_ring_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return HNS_RING_STATIC_REG_NUM;
 
return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -1000,8 +1000,10 @@ int hns_get_sset_count(struct net_device
cnt--;
 
return cnt;
-   } else {
+   } else if (stringset == ETH_SS_STATS) {
return (HNS_NET_STATS_CNT + ops->get_sset_count(h, stringset));
+   } else {
+   return -EOPNOTSUPP;
}
 }
 

[PATCH 4.4 64/72] nospec: Kill array_index_nospec_mask_check()

[Greg Kroah-Hartman]

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

--

From: Dan Williams 

commit 1d91c1d2c80cb70e2e553845e278b87a960c04da upstream.

There are multiple problems with the dynamic sanity checking in
array_index_nospec_mask_check():

* It causes unnecessary overhead in the 32-bit case since integer sized
  @index values will no longer cause the check to be compiled away like
  in the 64-bit case.

* In the 32-bit case it may trigger with user controllable input when
  the expectation is that should only trigger during development of new
  kernel enabling.

* The macro reuses the input parameter in multiple locations which is
  broken if someone passes an expression like 'index++' to
  array_index_nospec().

Reported-by: Linus Torvalds 
Signed-off-by: Dan Williams 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-a...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/151881604278.17395.6605847763178076520.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/nospec.h |   22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -31,26 +31,6 @@ static inline unsigned long array_index_
 #endif
 
 /*
- * Warn developers about inappropriate array_index_nospec() usage.
- *
- * Even if the CPU speculates past the WARN_ONCE branch, the
- * sign bit of @index is taken into account when generating the
- * mask.
- *
- * This warning is compiled out when the compiler can infer that
- * @index and @size are less than LONG_MAX.
- */
-#define array_index_mask_nospec_check(index, size) 
\
-({ 
\
-   if (WARN_ONCE(index > LONG_MAX || size > LONG_MAX,  
\
-   "array_index_nospec() limited to range of [0, LONG_MAX]\n"))
\
-   _mask = 0;  
\
-   else
\
-   _mask = array_index_mask_nospec(index, size);   
\
-   _mask;  
\
-})
-
-/*
  * array_index_nospec - sanitize an array index after a bounds check
  *
  * For a code sequence like:
@@ -68,7 +48,7 @@ static inline unsigned long array_index_
 ({ \
typeof(index) _i = (index); \
typeof(size) _s = (size);   \
-   unsigned long _mask = array_index_mask_nospec_check(_i, _s);\
+   unsigned long _mask = array_index_mask_nospec(_i, _s);  \
\
BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
BUILD_BUG_ON(sizeof(_s) > sizeof(long));\

[PATCH 4.4 48/72] mei: remove dev_err message on an unsupported ioctl

[Greg Kroah-Hartman]

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

--

From: Colin Ian King 

commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream.

Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.

Signed-off-by: Colin Ian King 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/main.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -571,7 +571,6 @@ static long mei_ioctl(struct file *file,
break;
 
default:
-   dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd);
rets = -ENOIOCTLCMD;
}
 

[PATCH 4.4 62/72] net: hns: Fix ethtool private flags

[Greg Kroah-Hartman]

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

--

From: Matthias Brugger 

commit d61d263c8d82db7c4404a29ebc29674b1c0c05c9 upstream.

The driver implementation returns support for private flags, while
no private flags are present. When asked for the number of private
flags it returns the number of statistic flag names.

Fix this by returning EOPNOTSUPP for not implemented ethtool flags.

Signed-off-by: Matthias Brugger 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |4 +++-
 4 files changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -648,7 +648,7 @@ static void hns_gmac_get_strings(u32 str
 
 static int hns_gmac_get_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return ARRAY_SIZE(g_gmac_stats_string);
 
return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -384,7 +384,7 @@ void hns_ppe_update_stats(struct hns_ppe
 
 int hns_ppe_get_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return ETH_PPE_STATIC_NUM;
return 0;
 }
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -807,7 +807,7 @@ void hns_rcb_get_stats(struct hnae_queue
  */
 int hns_rcb_get_ring_sset_count(int stringset)
 {
-   if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+   if (stringset == ETH_SS_STATS)
return HNS_RING_STATIC_REG_NUM;
 
return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -1000,8 +1000,10 @@ int hns_get_sset_count(struct net_device
cnt--;
 
return cnt;
-   } else {
+   } else if (stringset == ETH_SS_STATS) {
return (HNS_NET_STATS_CNT + ops->get_sset_count(h, stringset));
+   } else {
+   return -EOPNOTSUPP;
}
 }
 

[PATCH 4.4 64/72] nospec: Kill array_index_nospec_mask_check()

[Greg Kroah-Hartman]

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

--

From: Dan Williams 

commit 1d91c1d2c80cb70e2e553845e278b87a960c04da upstream.

There are multiple problems with the dynamic sanity checking in
array_index_nospec_mask_check():

* It causes unnecessary overhead in the 32-bit case since integer sized
  @index values will no longer cause the check to be compiled away like
  in the 64-bit case.

* In the 32-bit case it may trigger with user controllable input when
  the expectation is that should only trigger during development of new
  kernel enabling.

* The macro reuses the input parameter in multiple locations which is
  broken if someone passes an expression like 'index++' to
  array_index_nospec().

Reported-by: Linus Torvalds 
Signed-off-by: Dan Williams 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-a...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/151881604278.17395.6605847763178076520.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/nospec.h |   22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -31,26 +31,6 @@ static inline unsigned long array_index_
 #endif
 
 /*
- * Warn developers about inappropriate array_index_nospec() usage.
- *
- * Even if the CPU speculates past the WARN_ONCE branch, the
- * sign bit of @index is taken into account when generating the
- * mask.
- *
- * This warning is compiled out when the compiler can infer that
- * @index and @size are less than LONG_MAX.
- */
-#define array_index_mask_nospec_check(index, size) 
\
-({ 
\
-   if (WARN_ONCE(index > LONG_MAX || size > LONG_MAX,  
\
-   "array_index_nospec() limited to range of [0, LONG_MAX]\n"))
\
-   _mask = 0;  
\
-   else
\
-   _mask = array_index_mask_nospec(index, size);   
\
-   _mask;  
\
-})
-
-/*
  * array_index_nospec - sanitize an array index after a bounds check
  *
  * For a code sequence like:
@@ -68,7 +48,7 @@ static inline unsigned long array_index_
 ({ \
typeof(index) _i = (index); \
typeof(size) _s = (size);   \
-   unsigned long _mask = array_index_mask_nospec_check(_i, _s);\
+   unsigned long _mask = array_index_mask_nospec(_i, _s);  \
\
BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
BUILD_BUG_ON(sizeof(_s) > sizeof(long));\

[PATCH 4.4 68/72] Revert "cpufreq: Fix governor module removal race"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 3f7dfb7fcf98a7e73dee018c4a68537ce7fec646 which was
commit a8b149d32b663c1a4105273295184b78f53d33cf upstream.

The backport was not correct, so just drop it entirely.

Reported-by: Ben Hutchings 
Cc: Rafael J. Wysocki 
Cc: Viresh Kumar 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/cpufreq/cpufreq.c |6 --
 1 file changed, 6 deletions(-)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -551,8 +551,6 @@ static int cpufreq_parse_governor(char *
*governor = t;
err = 0;
}
-   if (t && !try_module_get(t->owner))
-   t = NULL;
 
mutex_unlock(_governor_mutex);
}
@@ -671,10 +669,6 @@ static ssize_t store_scaling_governor(st
return -EINVAL;
 
ret = cpufreq_set_policy(policy, _policy);
-
-   if (new_policy.governor)
-   module_put(new_policy.governor->owner);
-
return ret ? ret : count;
 }
 

[PATCH 4.4 68/72] Revert "cpufreq: Fix governor module removal race"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 3f7dfb7fcf98a7e73dee018c4a68537ce7fec646 which was
commit a8b149d32b663c1a4105273295184b78f53d33cf upstream.

The backport was not correct, so just drop it entirely.

Reported-by: Ben Hutchings 
Cc: Rafael J. Wysocki 
Cc: Viresh Kumar 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/cpufreq/cpufreq.c |6 --
 1 file changed, 6 deletions(-)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -551,8 +551,6 @@ static int cpufreq_parse_governor(char *
*governor = t;
err = 0;
}
-   if (t && !try_module_get(t->owner))
-   t = NULL;
 
mutex_unlock(_governor_mutex);
}
@@ -671,10 +669,6 @@ static ssize_t store_scaling_governor(st
return -EINVAL;
 
ret = cpufreq_set_policy(policy, _policy);
-
-   if (new_policy.governor)
-   module_put(new_policy.governor->owner);
-
return ret ? ret : count;
 }
 

[PATCH 4.4 69/72] Revert "mtip32xx: use runtime tag to initialize command header"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 9bf9e352ed51d4cdee107675609ba12b42d00c5b which was
commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 upstream.

Ben writes:
MQ IO schedulers were introduced in 4.11, so this shouldn't be
needed in older branches.  It also causes a performance
regression (fixed upstream).  Please revert this for 4.4 and
4.9.

So let's revert it!

Reported-by: Ben Hutchings 
Cc: Ming Lei 
Cc: Jens Axboe 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/block/mtip32xx/mtip32xx.c |   36 
 1 file changed, 12 insertions(+), 24 deletions(-)

--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -169,25 +169,6 @@ static bool mtip_check_surprise_removal(
return false; /* device present */
 }
 
-/* we have to use runtime tag to setup command header */
-static void mtip_init_cmd_header(struct request *rq)
-{
-   struct driver_data *dd = rq->q->queuedata;
-   struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
-   u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;
-
-   /* Point the command headers at the command tables. */
-   cmd->command_header = dd->port->command_list +
-   (sizeof(struct mtip_cmd_hdr) * rq->tag);
-   cmd->command_header_dma = dd->port->command_list_dma +
-   (sizeof(struct mtip_cmd_hdr) * rq->tag);
-
-   if (host_cap_64)
-   cmd->command_header->ctbau = __force_bit2int 
cpu_to_le32((cmd->command_dma >> 16) >> 16);
-
-   cmd->command_header->ctba = __force_bit2int 
cpu_to_le32(cmd->command_dma & 0x);
-}
-
 static struct mtip_cmd *mtip_get_int_command(struct driver_data *dd)
 {
struct request *rq;
@@ -199,9 +180,6 @@ static struct mtip_cmd *mtip_get_int_com
if (IS_ERR(rq))
return NULL;
 
-   /* Internal cmd isn't submitted via .queue_rq */
-   mtip_init_cmd_header(rq);
-
return blk_mq_rq_to_pdu(rq);
 }
 
@@ -3840,8 +3818,6 @@ static int mtip_queue_rq(struct blk_mq_h
struct request *rq = bd->rq;
int ret;
 
-   mtip_init_cmd_header(rq);
-
if (unlikely(mtip_check_unal_depth(hctx, rq)))
return BLK_MQ_RQ_QUEUE_BUSY;
 
@@ -3873,6 +3849,7 @@ static int mtip_init_cmd(void *data, str
 {
struct driver_data *dd = data;
struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
+   u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;
 
/*
 * For flush requests, request_idx starts at the end of the
@@ -3889,6 +3866,17 @@ static int mtip_init_cmd(void *data, str
 
memset(cmd->command, 0, CMD_DMA_ALLOC_SZ);
 
+   /* Point the command headers at the command tables. */
+   cmd->command_header = dd->port->command_list +
+   (sizeof(struct mtip_cmd_hdr) * request_idx);
+   cmd->command_header_dma = dd->port->command_list_dma +
+   (sizeof(struct mtip_cmd_hdr) * request_idx);
+
+   if (host_cap_64)
+   cmd->command_header->ctbau = __force_bit2int 
cpu_to_le32((cmd->command_dma >> 16) >> 16);
+
+   cmd->command_header->ctba = __force_bit2int 
cpu_to_le32(cmd->command_dma & 0x);
+
sg_init_table(cmd->sg, MTIP_MAX_SG);
return 0;
 }

[PATCH 4.4 69/72] Revert "mtip32xx: use runtime tag to initialize command header"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 9bf9e352ed51d4cdee107675609ba12b42d00c5b which was
commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 upstream.

Ben writes:
MQ IO schedulers were introduced in 4.11, so this shouldn't be
needed in older branches.  It also causes a performance
regression (fixed upstream).  Please revert this for 4.4 and
4.9.

So let's revert it!

Reported-by: Ben Hutchings 
Cc: Ming Lei 
Cc: Jens Axboe 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/block/mtip32xx/mtip32xx.c |   36 
 1 file changed, 12 insertions(+), 24 deletions(-)

--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -169,25 +169,6 @@ static bool mtip_check_surprise_removal(
return false; /* device present */
 }
 
-/* we have to use runtime tag to setup command header */
-static void mtip_init_cmd_header(struct request *rq)
-{
-   struct driver_data *dd = rq->q->queuedata;
-   struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
-   u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;
-
-   /* Point the command headers at the command tables. */
-   cmd->command_header = dd->port->command_list +
-   (sizeof(struct mtip_cmd_hdr) * rq->tag);
-   cmd->command_header_dma = dd->port->command_list_dma +
-   (sizeof(struct mtip_cmd_hdr) * rq->tag);
-
-   if (host_cap_64)
-   cmd->command_header->ctbau = __force_bit2int 
cpu_to_le32((cmd->command_dma >> 16) >> 16);
-
-   cmd->command_header->ctba = __force_bit2int 
cpu_to_le32(cmd->command_dma & 0x);
-}
-
 static struct mtip_cmd *mtip_get_int_command(struct driver_data *dd)
 {
struct request *rq;
@@ -199,9 +180,6 @@ static struct mtip_cmd *mtip_get_int_com
if (IS_ERR(rq))
return NULL;
 
-   /* Internal cmd isn't submitted via .queue_rq */
-   mtip_init_cmd_header(rq);
-
return blk_mq_rq_to_pdu(rq);
 }
 
@@ -3840,8 +3818,6 @@ static int mtip_queue_rq(struct blk_mq_h
struct request *rq = bd->rq;
int ret;
 
-   mtip_init_cmd_header(rq);
-
if (unlikely(mtip_check_unal_depth(hctx, rq)))
return BLK_MQ_RQ_QUEUE_BUSY;
 
@@ -3873,6 +3849,7 @@ static int mtip_init_cmd(void *data, str
 {
struct driver_data *dd = data;
struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
+   u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;
 
/*
 * For flush requests, request_idx starts at the end of the
@@ -3889,6 +3866,17 @@ static int mtip_init_cmd(void *data, str
 
memset(cmd->command, 0, CMD_DMA_ALLOC_SZ);
 
+   /* Point the command headers at the command tables. */
+   cmd->command_header = dd->port->command_list +
+   (sizeof(struct mtip_cmd_hdr) * request_idx);
+   cmd->command_header_dma = dd->port->command_list_dma +
+   (sizeof(struct mtip_cmd_hdr) * request_idx);
+
+   if (host_cap_64)
+   cmd->command_header->ctbau = __force_bit2int 
cpu_to_le32((cmd->command_dma >> 16) >> 16);
+
+   cmd->command_header->ctba = __force_bit2int 
cpu_to_le32(cmd->command_dma & 0x);
+
sg_init_table(cmd->sg, MTIP_MAX_SG);
return 0;
 }

[PATCH 4.4 72/72] Revert "ip6_vti: adjust vti mtu according to mtu of lower device"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 2fe832c678189d6b19b5ff282e7e70df79c1406b which is
commit 53c81e95df1793933f87748d36070a721f6cb287 upstream.

Ben writes that there are a number of follow-on patches needed to fix
this up, but they get complex to backport, and some custom fixes are
needed, so let's just revert this and wait for a "real" set of patches
to resolve this to be submitted if it is really needed.

Reported-by: Ben Hutchings 
Cc: Petr Vorel 
Cc: Alexey Kodanev 
Cc: David S. Miller 
Cc: Stefano Brivio 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ip6_vti.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index e4b0fb2f06a3..d7105422bc63 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -614,7 +614,6 @@ static void vti6_link_config(struct ip6_tnl *t)
 {
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = >parms;
-   struct net_device *tdev = NULL;
 
memcpy(dev->dev_addr, >laddr, sizeof(struct in6_addr));
memcpy(dev->broadcast, >raddr, sizeof(struct in6_addr));
@@ -627,25 +626,6 @@ static void vti6_link_config(struct ip6_tnl *t)
dev->flags |= IFF_POINTOPOINT;
else
dev->flags &= ~IFF_POINTOPOINT;
-
-   if (p->flags & IP6_TNL_F_CAP_XMIT) {
-   int strict = (ipv6_addr_type(>raddr) &
- (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
-   struct rt6_info *rt = rt6_lookup(t->net,
->raddr, >laddr,
-p->link, strict);
-
-   if (rt)
-   tdev = rt->dst.dev;
-   ip6_rt_put(rt);
-   }
-
-   if (!tdev && p->link)
-   tdev = __dev_get_by_index(t->net, p->link);
-
-   if (tdev)
-   dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
-IPV6_MIN_MTU);
 }
 
 /**
-- 
2.17.0

[PATCH 4.4 72/72] Revert "ip6_vti: adjust vti mtu according to mtu of lower device"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This reverts commit 2fe832c678189d6b19b5ff282e7e70df79c1406b which is
commit 53c81e95df1793933f87748d36070a721f6cb287 upstream.

Ben writes that there are a number of follow-on patches needed to fix
this up, but they get complex to backport, and some custom fixes are
needed, so let's just revert this and wait for a "real" set of patches
to resolve this to be submitted if it is really needed.

Reported-by: Ben Hutchings 
Cc: Petr Vorel 
Cc: Alexey Kodanev 
Cc: David S. Miller 
Cc: Stefano Brivio 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ip6_vti.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index e4b0fb2f06a3..d7105422bc63 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -614,7 +614,6 @@ static void vti6_link_config(struct ip6_tnl *t)
 {
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = >parms;
-   struct net_device *tdev = NULL;
 
memcpy(dev->dev_addr, >laddr, sizeof(struct in6_addr));
memcpy(dev->broadcast, >raddr, sizeof(struct in6_addr));
@@ -627,25 +626,6 @@ static void vti6_link_config(struct ip6_tnl *t)
dev->flags |= IFF_POINTOPOINT;
else
dev->flags &= ~IFF_POINTOPOINT;
-
-   if (p->flags & IP6_TNL_F_CAP_XMIT) {
-   int strict = (ipv6_addr_type(>raddr) &
- (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
-   struct rt6_info *rt = rt6_lookup(t->net,
->raddr, >laddr,
-p->link, strict);
-
-   if (rt)
-   tdev = rt->dst.dev;
-   ip6_rt_put(rt);
-   }
-
-   if (!tdev && p->link)
-   tdev = __dev_get_by_index(t->net, p->link);
-
-   if (tdev)
-   dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
-IPV6_MIN_MTU);
 }
 
 /**
-- 
2.17.0

[PATCH 4.4 71/72] net: cavium: liquidio: fix up "Avoid dma_unmap_single on uninitialized ndata"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This fixes up commit 1d1cb762524f05cfb37994e0d36b7b4b5e957134 which was
commit 8e6ce7ebeb34f0992f56de078c3744fb383657fa upstream.

Ben writes:
This goto should not have been changed, as no DMA mapping has been
attempted at this point in the function.

This seems to have been fixed upstream by commit 6a885b60dad2 "liquidio:
Introduce new octeon2/3 header".  I leave it to you to work out how it
should be fixed in 4.4-stable.

Fix this up by hand, as the referenced patch isn't worthy of being
backported.

Reported-by: Ben Hutchings 
Cc: Florian Fainelli 
Cc: David S. Miller 
Cc: Julia Lawall 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2823,7 +2823,7 @@ static int liquidio_xmit(struct sk_buff
if (!g) {
netif_info(lio, tx_err, lio->netdev,
   "Transmit scatter gather: glist null!\n");
-   goto lio_xmit_dma_failed;
+   goto lio_xmit_failed;
}
 
cmdsetup.s.gather = 1;

[PATCH 4.4 71/72] net: cavium: liquidio: fix up "Avoid dma_unmap_single on uninitialized ndata"

[Greg Kroah-Hartman]

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

--

From: Greg Kroah-Hartman 

This fixes up commit 1d1cb762524f05cfb37994e0d36b7b4b5e957134 which was
commit 8e6ce7ebeb34f0992f56de078c3744fb383657fa upstream.

Ben writes:
This goto should not have been changed, as no DMA mapping has been
attempted at this point in the function.

This seems to have been fixed upstream by commit 6a885b60dad2 "liquidio:
Introduce new octeon2/3 header".  I leave it to you to work out how it
should be fixed in 4.4-stable.

Fix this up by hand, as the referenced patch isn't worthy of being
backported.

Reported-by: Ben Hutchings 
Cc: Florian Fainelli 
Cc: David S. Miller 
Cc: Julia Lawall 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2823,7 +2823,7 @@ static int liquidio_xmit(struct sk_buff
if (!g) {
netif_info(lio, tx_err, lio->netdev,
   "Transmit scatter gather: glist null!\n");
-   goto lio_xmit_dma_failed;
+   goto lio_xmit_failed;
}
 
cmdsetup.s.gather = 1;

Re: mmotm 2018-04-05-16-59 uploaded

[Matthew Wilcox]

On Thu, Apr 05, 2018 at 05:00:09PM -0700, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-04-05-16-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/

> * page-cache-use-xa_lock.patch

Hi Andrew.  Could I trouble you to add page-cache-use-xa_lock-fix.patch?

---
 arch/nds32/include/asm/cacheflush.h | 4 ++--
 fs/dax.c| 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/nds32/include/asm/cacheflush.h 
b/arch/nds32/include/asm/cacheflush.h
index 7b9b20a381cb..1240f148ec0f 100644
--- a/arch/nds32/include/asm/cacheflush.h
+++ b/arch/nds32/include/asm/cacheflush.h
@@ -34,8 +34,8 @@ void flush_anon_page(struct vm_area_struct *vma,
 void flush_kernel_dcache_page(struct page *page);
 void flush_icache_range(unsigned long start, unsigned long end);
 void flush_icache_page(struct vm_area_struct *vma, struct page *page);
-#define flush_dcache_mmap_lock(mapping)   spin_lock_irq(&(mapping)->tree_lock)
-#define flush_dcache_mmap_unlock(mapping) 
spin_unlock_irq(&(mapping)->tree_lock)
+#define flush_dcache_mmap_lock(mapping)   xa_lock_irq(&(mapping)->i_pages)
+#define flush_dcache_mmap_unlock(mapping) xa_unlock_irq(&(mapping)->i_pages)
 
 #else
 #include 
diff --git a/fs/dax.c b/fs/dax.c
index fef7d458fd7d..aaec72ded1b6 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -499,7 +499,7 @@ static int __dax_invalidate_mapping_entry(struct 
address_space *mapping,
void *entry;
struct radix_tree_root *pages = >i_pages;
 
-   xa_lock_irq(>i_pages);
+   xa_lock_irq(pages);
entry = get_unlocked_mapping_entry(mapping, index, NULL);
if (!entry || WARN_ON_ONCE(!radix_tree_exceptional_entry(entry)))
goto out;
@@ -513,7 +513,7 @@ static int __dax_invalidate_mapping_entry(struct 
address_space *mapping,
ret = 1;
 out:
put_unlocked_mapping_entry(mapping, index, entry);
-   xa_unlock_irq(>i_pages);
+   xa_unlock_irq(pages);
return ret;
 }
 /*
@@ -600,7 +600,7 @@ static void *dax_insert_mapping_entry(struct address_space 
*mapping,
unmap_mapping_pages(mapping, vmf->pgoff, 1, false);
}
 
-   xa_lock_irq(>i_pages);
+   xa_lock_irq(pages);
new_entry = dax_radix_locked_entry(pfn, flags);
if (dax_entry_size(entry) != dax_entry_size(new_entry)) {
dax_disassociate_entry(entry, mapping, false);
-- 
2.16.3

Re: mmotm 2018-04-05-16-59 uploaded

[Matthew Wilcox]

On Thu, Apr 05, 2018 at 05:00:09PM -0700, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-04-05-16-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/

> * page-cache-use-xa_lock.patch

Hi Andrew.  Could I trouble you to add page-cache-use-xa_lock-fix.patch?

---
 arch/nds32/include/asm/cacheflush.h | 4 ++--
 fs/dax.c| 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/nds32/include/asm/cacheflush.h 
b/arch/nds32/include/asm/cacheflush.h
index 7b9b20a381cb..1240f148ec0f 100644
--- a/arch/nds32/include/asm/cacheflush.h
+++ b/arch/nds32/include/asm/cacheflush.h
@@ -34,8 +34,8 @@ void flush_anon_page(struct vm_area_struct *vma,
 void flush_kernel_dcache_page(struct page *page);
 void flush_icache_range(unsigned long start, unsigned long end);
 void flush_icache_page(struct vm_area_struct *vma, struct page *page);
-#define flush_dcache_mmap_lock(mapping)   spin_lock_irq(&(mapping)->tree_lock)
-#define flush_dcache_mmap_unlock(mapping) 
spin_unlock_irq(&(mapping)->tree_lock)
+#define flush_dcache_mmap_lock(mapping)   xa_lock_irq(&(mapping)->i_pages)
+#define flush_dcache_mmap_unlock(mapping) xa_unlock_irq(&(mapping)->i_pages)
 
 #else
 #include 
diff --git a/fs/dax.c b/fs/dax.c
index fef7d458fd7d..aaec72ded1b6 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -499,7 +499,7 @@ static int __dax_invalidate_mapping_entry(struct 
address_space *mapping,
void *entry;
struct radix_tree_root *pages = >i_pages;
 
-   xa_lock_irq(>i_pages);
+   xa_lock_irq(pages);
entry = get_unlocked_mapping_entry(mapping, index, NULL);
if (!entry || WARN_ON_ONCE(!radix_tree_exceptional_entry(entry)))
goto out;
@@ -513,7 +513,7 @@ static int __dax_invalidate_mapping_entry(struct 
address_space *mapping,
ret = 1;
 out:
put_unlocked_mapping_entry(mapping, index, entry);
-   xa_unlock_irq(>i_pages);
+   xa_unlock_irq(pages);
return ret;
 }
 /*
@@ -600,7 +600,7 @@ static void *dax_insert_mapping_entry(struct address_space 
*mapping,
unmap_mapping_pages(mapping, vmf->pgoff, 1, false);
}
 
-   xa_lock_irq(>i_pages);
+   xa_lock_irq(pages);
new_entry = dax_radix_locked_entry(pfn, flags);
if (dax_entry_size(entry) != dax_entry_size(new_entry)) {
dax_disassociate_entry(entry, mapping, false);
-- 
2.16.3

[PATCH 4.4 49/72] media: usbtv: prevent double free in error case

[Greg Kroah-Hartman]

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

--

From: Oliver Neukum 

commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream.

Quoting the original report:

It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.

usbtv_audio_fail:

usbtv_video_free(usbtv); =>

   v4l2_device_put(>v4l2_dev);

  => v4l2_device_put

  => kref_put

  => v4l2_device_release

  => usbtv_release (CALLBACK)

 => kfree(usbtv) (1st time)

usbtv_video_fail:

usb_set_intfdata(intf, NULL);

usb_put_dev(usbtv->udev);

kfree(usbtv); (2nd time)

So, as we have refcounting, use it

Reported-by: Yavuz, Tuba 
Signed-off-by: Oliver Neukum 
CC: sta...@vger.kernel.org
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/usbtv/usbtv-core.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -95,6 +95,8 @@ static int usbtv_probe(struct usb_interf
return 0;
 
 usbtv_audio_fail:
+   /* we must not free at this point */
+   usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
 
 usbtv_video_fail:

[PATCH 4.4 49/72] media: usbtv: prevent double free in error case

[Greg Kroah-Hartman]

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

--

From: Oliver Neukum 

commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream.

Quoting the original report:

It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.

usbtv_audio_fail:

usbtv_video_free(usbtv); =>

   v4l2_device_put(>v4l2_dev);

  => v4l2_device_put

  => kref_put

  => v4l2_device_release

  => usbtv_release (CALLBACK)

 => kfree(usbtv) (1st time)

usbtv_video_fail:

usb_set_intfdata(intf, NULL);

usb_put_dev(usbtv->udev);

kfree(usbtv); (2nd time)

So, as we have refcounting, use it

Reported-by: Yavuz, Tuba 
Signed-off-by: Oliver Neukum 
CC: sta...@vger.kernel.org
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/usbtv/usbtv-core.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -95,6 +95,8 @@ static int usbtv_probe(struct usb_interf
return 0;
 
 usbtv_audio_fail:
+   /* we must not free at this point */
+   usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
 
 usbtv_video_fail:

[PATCH 4.4 50/72] parport_pc: Add support for WCH CH382L PCI-E single parallel port card.

[Greg Kroah-Hartman]

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

--

From: Alexander Gerasiov 

commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream.

WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
but serial ports are not soldered on board. Detected as
Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])

Signed-off-by: Alexander Gerasiov 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/parport/parport_pc.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
+   wch_ch382l,
 };
 
 
@@ -2708,6 +2709,7 @@ static struct parport_pc_pci {
/* netmos_9901 */   { 1, { { 0, -1 }, } },
/* netmos_9865 */   { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */  { 1, { { 0, 1 }, } },
+   /* wch_ch382l */{ 1, { { 2, -1 }, } },
 };
 
 static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2797,6 +2799,8 @@ static const struct pci_device_id parpor
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
+   /* WCH CH382L PCI-E single parallel port card */
+   { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);

[PATCH 4.4 50/72] parport_pc: Add support for WCH CH382L PCI-E single parallel port card.

[Greg Kroah-Hartman]

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

--

From: Alexander Gerasiov 

commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream.

WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
but serial ports are not soldered on board. Detected as
Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])

Signed-off-by: Alexander Gerasiov 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/parport/parport_pc.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
+   wch_ch382l,
 };
 
 
@@ -2708,6 +2709,7 @@ static struct parport_pc_pci {
/* netmos_9901 */   { 1, { { 0, -1 }, } },
/* netmos_9865 */   { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */  { 1, { { 0, 1 }, } },
+   /* wch_ch382l */{ 1, { { 2, -1 }, } },
 };
 
 static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2797,6 +2799,8 @@ static const struct pci_device_id parpor
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
+   /* WCH CH382L PCI-E single parallel port card */
+   { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

[Laurent Pinchart]

Hi Philippe,

Thank you for the patch.

On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote:
> This patch clarifies the adjusted_mode documentation
> for a bridge directly connected to a crtc.
> 
> Signed-off-by: Philippe Cornu 
> ---
> This patch is linked to the discussion https://lkml.org/lkml/2018/1/25/367
> 
>  include/drm/drm_bridge.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3270fec46979..b5f3c070467c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -177,7 +177,8 @@ struct drm_bridge_funcs {
>* pipeline has been called already. If the bridge is the first element
>* then this would be _encoder_helper_funcs.mode_set. The display
>* pipe (i.e.  clocks and timing signals) is off when this function is
> -  * called.
> +  * called. If the bridge is connected to the crtc, the adjusted_mode
> +  * parameter is the one defined in _crtc_state.adjusted_mode.

Unless I'm mistaken this will always be the mode stored in 
_crtc_state.adjusted_mode (at least for atomic drivers), regardless of 
whether the bridge is the first in the chain (connected to the CRTC) or not. 
What is important to document is that we have a single adjusted_mode for the 
whole chain of bridges, and that it corresponds to the mode output by the CRTC 
for the first bridge. Bridges further in the chain can look at that mode, 
although there will probably be nothing of interest to them there.

How about the following text ?

/**
 * @mode_set:
 *
 * This callback should set the given mode on the bridge. It is called
 * after the @mode_set callback for the preceding element in the display
 * pipeline has been called already. If the bridge is the first element
 * then this would be _encoder_helper_funcs.mode_set. The display
 * pipe (i.e.  clocks and timing signals) is off when this function is
 * called.
 *
 * The adjusted_mode parameter corresponds to the mode output by the CRTC
 * for the first bridge in the chain. It can be different from the mode
 * parameter that contains the desired mode for the connector at the end
 * of the bridges chain, for instance when the first bridge in the chain
 * performs scaling. The adjusted mode is mostly useful for the first
 * bridge in the chain and is likely irrelevant for the other bridges.
 *
 * For atomic drivers the adjusted_mode is the mode stored in
 * _crtc_state.adjusted_mode.
 *
 * NOTE:
 *
 * If a need arises to store and access modes adjusted for other locations
 * than the connection between the CRTC and the first bridge, the DRM
 * framework will have to be extended with DRM bridge states.
 */

Then I think we should also update the documentation of 
drm_crtc_state.adjusted_mode accordingly:

/*
 * @adjusted_mode:
 *
 * Internal display timings which can be used by the driver to handle
 * differences between the mode requested by userspace in @mode and what
 * is actually programmed into the hardware.
 *
 * For drivers using drm_bridge, this store the hardware display timings
 * used between the CRTC and the first bridge. For other drivers, the
 * meaning of the adjusted_mode field is purely driver implementation
 * defined information, and will usually be used to store the hardware
 * display timings used between the CRTC and encoder blocks.
 */

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

[Laurent Pinchart]

Hi Philippe,

Thank you for the patch.

On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote:
> This patch clarifies the adjusted_mode documentation
> for a bridge directly connected to a crtc.
> 
> Signed-off-by: Philippe Cornu 
> ---
> This patch is linked to the discussion https://lkml.org/lkml/2018/1/25/367
> 
>  include/drm/drm_bridge.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3270fec46979..b5f3c070467c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -177,7 +177,8 @@ struct drm_bridge_funcs {
>* pipeline has been called already. If the bridge is the first element
>* then this would be _encoder_helper_funcs.mode_set. The display
>* pipe (i.e.  clocks and timing signals) is off when this function is
> -  * called.
> +  * called. If the bridge is connected to the crtc, the adjusted_mode
> +  * parameter is the one defined in _crtc_state.adjusted_mode.

Unless I'm mistaken this will always be the mode stored in 
_crtc_state.adjusted_mode (at least for atomic drivers), regardless of 
whether the bridge is the first in the chain (connected to the CRTC) or not. 
What is important to document is that we have a single adjusted_mode for the 
whole chain of bridges, and that it corresponds to the mode output by the CRTC 
for the first bridge. Bridges further in the chain can look at that mode, 
although there will probably be nothing of interest to them there.

How about the following text ?

/**
 * @mode_set:
 *
 * This callback should set the given mode on the bridge. It is called
 * after the @mode_set callback for the preceding element in the display
 * pipeline has been called already. If the bridge is the first element
 * then this would be _encoder_helper_funcs.mode_set. The display
 * pipe (i.e.  clocks and timing signals) is off when this function is
 * called.
 *
 * The adjusted_mode parameter corresponds to the mode output by the CRTC
 * for the first bridge in the chain. It can be different from the mode
 * parameter that contains the desired mode for the connector at the end
 * of the bridges chain, for instance when the first bridge in the chain
 * performs scaling. The adjusted mode is mostly useful for the first
 * bridge in the chain and is likely irrelevant for the other bridges.
 *
 * For atomic drivers the adjusted_mode is the mode stored in
 * _crtc_state.adjusted_mode.
 *
 * NOTE:
 *
 * If a need arises to store and access modes adjusted for other locations
 * than the connection between the CRTC and the first bridge, the DRM
 * framework will have to be extended with DRM bridge states.
 */

Then I think we should also update the documentation of 
drm_crtc_state.adjusted_mode accordingly:

/*
 * @adjusted_mode:
 *
 * Internal display timings which can be used by the driver to handle
 * differences between the mode requested by userspace in @mode and what
 * is actually programmed into the hardware.
 *
 * For drivers using drm_bridge, this store the hardware display timings
 * used between the CRTC and the first bridge. For other drivers, the
 * meaning of the adjusted_mode field is purely driver implementation
 * defined information, and will usually be used to store the hardware
 * display timings used between the CRTC and encoder blocks.
 */

-- 
Regards,

Laurent Pinchart

[PATCH 4.4 54/72] staging: comedi: ni_mio_common: ack ai fifo error interrupts.

[Greg Kroah-Hartman]

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

--

From: Frank Mori Hess 

commit e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 upstream.

Ack ai fifo error interrupts in interrupt handler to clear interrupt
after fifo overflow.  It should prevent lock-ups after the ai fifo
overflows.

Cc:  # v4.2+
Signed-off-by: Frank Mori Hess 
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/comedi/drivers/ni_mio_common.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1348,6 +1348,8 @@ static void ack_a_interrupt(struct comed
ack |= NISTC_INTA_ACK_AI_START;
if (a_status & NISTC_AI_STATUS1_STOP)
ack |= NISTC_INTA_ACK_AI_STOP;
+   if (a_status & NISTC_AI_STATUS1_OVER)
+   ack |= NISTC_INTA_ACK_AI_ERR;
if (ack)
ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG);
 }

[PATCH 4.4 54/72] staging: comedi: ni_mio_common: ack ai fifo error interrupts.

[Greg Kroah-Hartman]

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

--

From: Frank Mori Hess 

commit e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 upstream.

Ack ai fifo error interrupts in interrupt handler to clear interrupt
after fifo overflow.  It should prevent lock-ups after the ai fifo
overflows.

Cc:  # v4.2+
Signed-off-by: Frank Mori Hess 
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/comedi/drivers/ni_mio_common.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1348,6 +1348,8 @@ static void ack_a_interrupt(struct comed
ack |= NISTC_INTA_ACK_AI_START;
if (a_status & NISTC_AI_STATUS1_STOP)
ack |= NISTC_INTA_ACK_AI_STOP;
+   if (a_status & NISTC_AI_STATUS1_OVER)
+   ack |= NISTC_INTA_ACK_AI_ERR;
if (ack)
ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG);
 }

Re: x86/dma conversion for v4.17-rc1 breaks sound / sst-acpi (commit 6e4bf5867783)

[Dominik Brodowski]

On Fri, Apr 06, 2018 at 04:14:52PM +0200, Christoph Hellwig wrote:
> Hi Dominik,
> 
> can you try current Linus' master with the following hack applied and
> see if that works?
> 
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 47aeb04c1997..32aacd0d56a8 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -1087,6 +1087,6 @@ const struct dma_map_ops swiotlb_dma_ops = {
>   .unmap_sg   = swiotlb_unmap_sg_attrs,
>   .map_page   = swiotlb_map_page,
>   .unmap_page = swiotlb_unmap_page,
> - .dma_supported  = swiotlb_dma_supported,
> + .dma_supported  = dma_direct_supported,
>  };
>  #endif /* CONFIG_DMA_DIRECT_OPS */

Yes, it solves the issue.

Thanks,
Dominik

Re: x86/dma conversion for v4.17-rc1 breaks sound / sst-acpi (commit 6e4bf5867783)

[Dominik Brodowski]

On Fri, Apr 06, 2018 at 04:14:52PM +0200, Christoph Hellwig wrote:
> Hi Dominik,
> 
> can you try current Linus' master with the following hack applied and
> see if that works?
> 
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 47aeb04c1997..32aacd0d56a8 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -1087,6 +1087,6 @@ const struct dma_map_ops swiotlb_dma_ops = {
>   .unmap_sg   = swiotlb_unmap_sg_attrs,
>   .map_page   = swiotlb_map_page,
>   .unmap_page = swiotlb_unmap_page,
> - .dma_supported  = swiotlb_dma_supported,
> + .dma_supported  = dma_direct_supported,
>  };
>  #endif /* CONFIG_DMA_DIRECT_OPS */

Yes, it solves the issue.

Thanks,
Dominik

Re: INFO: rcu detected stall in snd_pcm_stream_lock_irq

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 3:24 PM, syzbot
 wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +)
> Merge tag 'armsoc-drivers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=74e011b2046f4322d178
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4582053840420864
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-5813481738265533882
> compiler: gcc (GCC) 8.0.1 20180301 (experimental)

+ALSA maintainers
This was misattributed to kcov.c, I will fix it.

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+74e011b2046f4322d...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> syz-executor1 (6140) used greatest stack depth: 11720 bytes left
> INFO: rcu_sched self-detected stall on CPU
> 1-: (124998 ticks this GP) idle=0b2/1/4611686018427387906
> softirq=15730/15730 fqs=31205
>  (t=125000 jiffies g=8316 c=8315 q=1529)
> NMI backtrace for cpu 1
> CPU: 1 PID: 6087 Comm: syz-executor0 Not tainted 4.16.0+ #3
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
>  nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
>  arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
>  trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
>  rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
>  print_cpu_stall kernel/rcu/tree.c:1525 [inline]
>  check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
>  __rcu_pending kernel/rcu/tree.c:3356 [inline]
>  rcu_pending kernel/rcu/tree.c:3401 [inline]
>  rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
>  update_process_times+0x2d/0x70 kernel/time/timer.c:1636
>  tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:171
>  tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1179
>  __run_hrtimer kernel/time/hrtimer.c:1337 [inline]
>  __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1399
>  hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1457
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862
>  
> RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x50 kernel/kcov.c:106
> RSP: 0018:8801920cf4d0 EFLAGS: 0216 ORIG_RAX: ff13
> RAX: 0004 RBX: 8801ceb61200 RCX: c90001eb
> RDX: 0004 RSI: 859d760f RDI: 8801ceb61200
> RBP: 8801920cf4d0 R08: 8801b4946540 R09: 0006
> R10: 8801b4946540 R11:  R12: 8826fa20
> R13: 0020 R14: 8801d3008c00 R15: 8801ceb61200
>  snd_pcm_stream_lock_irq+0xf/0xf0 sound/core/pcm_native.c:150
>  __snd_pcm_lib_xfer+0x345/0x1d10 sound/core/pcm_lib.c:2162
>  snd_pcm_oss_write3+0xe9/0x220 sound/core/oss/pcm_oss.c:1236
>  io_playback_transfer+0x274/0x310 sound/core/oss/io.c:47
>  snd_pcm_plug_write_transfer+0x36c/0x470 sound/core/oss/pcm_plugin.c:619
>  snd_pcm_oss_write2+0x25c/0x460 sound/core/oss/pcm_oss.c:1365
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1431 [inline]
>  snd_pcm_oss_write+0x55f/0xa20 sound/core/oss/pcm_oss.c:2774
>  do_loop_readv_writev fs/read_write.c:703 [inline]
>  do_iter_write+0x491/0x5f0 fs/read_write.c:961
>  vfs_writev+0x1c7/0x330 fs/read_write.c:1004
>  do_writev+0x112/0x2f0 fs/read_write.c:1039
>  SYSC_writev fs/read_write.c:1112 [inline]
>  SyS_writev+0x27/0x30 fs/read_write.c:1109
>  do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4552d9
> RSP: 002b:7f82ef52cc68 EFLAGS: 0246 ORIG_RAX: 0014
> RAX: ffda RBX: 7f82ef52d6d4 RCX: 004552d9
> RDX: 0001 RSI: 2180 RDI: 0015
> RBP: 0072bea0 R08:  R09: 
> R10:  R11: 0246 R12: 
> R13: 06cc R14: 006fd3c0 R15: 
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To 

[PATCH 4.4 53/72] fs/proc: Stop trying to report thread stacks

[Greg Kroah-Hartman]

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

--

From: Andy Lutomirski 

commit b18cb64ead400c01bf1580eeba330ace51f8087d upstream.

This reverts more of:

  b76437579d13 ("procfs: mark thread stack correctly in proc//maps")

... which was partially reverted by:

  65376df58217 ("proc: revert /proc//maps [stack:TID] annotation")

Originally, /proc/PID/task/TID/maps was the same as /proc/TID/maps.

In current kernels, /proc/PID/maps (or /proc/TID/maps even for
threads) shows "[stack]" for VMAs in the mm's stack address range.

In contrast, /proc/PID/task/TID/maps uses KSTK_ESP to guess the
target thread's stack's VMA.  This is racy, probably returns garbage
and, on arches with CONFIG_TASK_INFO_IN_THREAD=y, is also crash-prone:
KSTK_ESP is not safe to use on tasks that aren't known to be running
ordinary process-context kernel code.

This patch removes the difference and just shows "[stack]" for VMAs
in the mm's stack range.  This is IMO much more sensible -- the
actual "stack" address really is treated specially by the VM code,
and the current thread stack isn't even well-defined for programs
that frequently switch stacks on their own.

Reported-by: Jann Horn 
Signed-off-by: Andy Lutomirski 
Acked-by: Thomas Gleixner 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Johannes Weiner 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Linux API 
Cc: Peter Zijlstra 
Cc: Tycho Andersen 
Link: 
http://lkml.kernel.org/r/3e678474ec14e0a0ec34c611016753eea2e1b8ba.1475257877.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/filesystems/proc.txt |   26 --
 fs/proc/task_mmu.c |   29 ++---
 fs/proc/task_nommu.c   |   26 +-
 3 files changed, 19 insertions(+), 62 deletions(-)

--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -383,32 +383,6 @@ is not associated with a file:
 
  or if empty, the mapping is anonymous.
 
-The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
-of the individual tasks of a process. In this file you will see a mapping 
marked
-as [stack] if that task sees it as a stack. Hence, for the example above, the
-task-level map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like 
this:
-
-08048000-08049000 r-xp  03:00 8312   /opt/test
-08049000-0804a000 rw-p 1000 03:00 8312   /opt/test
-0804a000-0806b000 rw-p  00:00 0  [heap]
-a7cb1000-a7cb2000 ---p  00:00 0
-a7cb2000-a7eb2000 rw-p  00:00 0
-a7eb2000-a7eb3000 ---p  00:00 0
-a7eb3000-a7ed5000 rw-p  00:00 0  [stack]
-a7ed5000-a8008000 r-xp  03:00 4222   /lib/libc.so.6
-a8008000-a800a000 r--p 00133000 03:00 4222   /lib/libc.so.6
-a800a000-a800b000 rw-p 00135000 03:00 4222   /lib/libc.so.6
-a800b000-a800e000 rw-p  00:00 0
-a800e000-a8022000 r-xp  03:00 14462  /lib/libpthread.so.0
-a8022000-a8023000 r--p 00013000 03:00 14462  /lib/libpthread.so.0
-a8023000-a8024000 rw-p 00014000 03:00 14462  /lib/libpthread.so.0
-a8024000-a8027000 rw-p  00:00 0
-a8027000-a8043000 r-xp  03:00 8317   /lib/ld-linux.so.2
-a8043000-a8044000 r--p 0001b000 03:00 8317   /lib/ld-linux.so.2
-a8044000-a8045000 rw-p 0001c000 03:00 8317   /lib/ld-linux.so.2
-aff35000-aff4a000 rw-p  00:00 0
-e000-f000 r-xp  00:00 0  [vdso]
-
 The /proc/PID/smaps is an extension based on maps, showing the memory
 consumption for each of the process's mappings. For each of mappings there
 is a series of lines such as the following:
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -253,24 +253,15 @@ static int do_maps_open(struct inode *in
  * /proc/PID/maps that is the stack of the main task.
  */
 static int is_stack(struct proc_maps_private *priv,
-   struct vm_area_struct *vma, int is_pid)
+   struct vm_area_struct *vma)
 {
-   int stack = 0;
-
-   if (is_pid) {
-   stack = vma->vm_start <= vma->vm_mm->start_stack &&
-   vma->vm_end >= vma->vm_mm->start_stack;
-   } else {
-   struct inode *inode = priv->inode;
-   struct task_struct *task;
-
-   rcu_read_lock();
-   task = pid_task(proc_pid(inode), PIDTYPE_PID);
-   if (task)
-   stack = vma_is_stack_for_task(vma, task);
-   rcu_read_unlock();
-   }
-   return stack;
+  

Re: INFO: rcu detected stall in snd_pcm_stream_lock_irq

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 3:24 PM, syzbot
 wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +)
> Merge tag 'armsoc-drivers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=74e011b2046f4322d178
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4582053840420864
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-5813481738265533882
> compiler: gcc (GCC) 8.0.1 20180301 (experimental)

+ALSA maintainers
This was misattributed to kcov.c, I will fix it.

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+74e011b2046f4322d...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> syz-executor1 (6140) used greatest stack depth: 11720 bytes left
> INFO: rcu_sched self-detected stall on CPU
> 1-: (124998 ticks this GP) idle=0b2/1/4611686018427387906
> softirq=15730/15730 fqs=31205
>  (t=125000 jiffies g=8316 c=8315 q=1529)
> NMI backtrace for cpu 1
> CPU: 1 PID: 6087 Comm: syz-executor0 Not tainted 4.16.0+ #3
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
>  nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
>  arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
>  trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
>  rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
>  print_cpu_stall kernel/rcu/tree.c:1525 [inline]
>  check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
>  __rcu_pending kernel/rcu/tree.c:3356 [inline]
>  rcu_pending kernel/rcu/tree.c:3401 [inline]
>  rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
>  update_process_times+0x2d/0x70 kernel/time/timer.c:1636
>  tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:171
>  tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1179
>  __run_hrtimer kernel/time/hrtimer.c:1337 [inline]
>  __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1399
>  hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1457
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862
>  
> RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x50 kernel/kcov.c:106
> RSP: 0018:8801920cf4d0 EFLAGS: 0216 ORIG_RAX: ff13
> RAX: 0004 RBX: 8801ceb61200 RCX: c90001eb
> RDX: 0004 RSI: 859d760f RDI: 8801ceb61200
> RBP: 8801920cf4d0 R08: 8801b4946540 R09: 0006
> R10: 8801b4946540 R11:  R12: 8826fa20
> R13: 0020 R14: 8801d3008c00 R15: 8801ceb61200
>  snd_pcm_stream_lock_irq+0xf/0xf0 sound/core/pcm_native.c:150
>  __snd_pcm_lib_xfer+0x345/0x1d10 sound/core/pcm_lib.c:2162
>  snd_pcm_oss_write3+0xe9/0x220 sound/core/oss/pcm_oss.c:1236
>  io_playback_transfer+0x274/0x310 sound/core/oss/io.c:47
>  snd_pcm_plug_write_transfer+0x36c/0x470 sound/core/oss/pcm_plugin.c:619
>  snd_pcm_oss_write2+0x25c/0x460 sound/core/oss/pcm_oss.c:1365
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1431 [inline]
>  snd_pcm_oss_write+0x55f/0xa20 sound/core/oss/pcm_oss.c:2774
>  do_loop_readv_writev fs/read_write.c:703 [inline]
>  do_iter_write+0x491/0x5f0 fs/read_write.c:961
>  vfs_writev+0x1c7/0x330 fs/read_write.c:1004
>  do_writev+0x112/0x2f0 fs/read_write.c:1039
>  SYSC_writev fs/read_write.c:1112 [inline]
>  SyS_writev+0x27/0x30 fs/read_write.c:1109
>  do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4552d9
> RSP: 002b:7f82ef52cc68 EFLAGS: 0246 ORIG_RAX: 0014
> RAX: ffda RBX: 7f82ef52d6d4 RCX: 004552d9
> RDX: 0001 RSI: 2180 RDI: 0015
> RBP: 0072bea0 R08:  R09: 
> R10:  R11: 0246 R12: 
> R13: 06cc R14: 006fd3c0 R15: 
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please 

[PATCH 4.4 53/72] fs/proc: Stop trying to report thread stacks

[Greg Kroah-Hartman]

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

--

From: Andy Lutomirski 

commit b18cb64ead400c01bf1580eeba330ace51f8087d upstream.

This reverts more of:

  b76437579d13 ("procfs: mark thread stack correctly in proc//maps")

... which was partially reverted by:

  65376df58217 ("proc: revert /proc//maps [stack:TID] annotation")

Originally, /proc/PID/task/TID/maps was the same as /proc/TID/maps.

In current kernels, /proc/PID/maps (or /proc/TID/maps even for
threads) shows "[stack]" for VMAs in the mm's stack address range.

In contrast, /proc/PID/task/TID/maps uses KSTK_ESP to guess the
target thread's stack's VMA.  This is racy, probably returns garbage
and, on arches with CONFIG_TASK_INFO_IN_THREAD=y, is also crash-prone:
KSTK_ESP is not safe to use on tasks that aren't known to be running
ordinary process-context kernel code.

This patch removes the difference and just shows "[stack]" for VMAs
in the mm's stack range.  This is IMO much more sensible -- the
actual "stack" address really is treated specially by the VM code,
and the current thread stack isn't even well-defined for programs
that frequently switch stacks on their own.

Reported-by: Jann Horn 
Signed-off-by: Andy Lutomirski 
Acked-by: Thomas Gleixner 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Johannes Weiner 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Linux API 
Cc: Peter Zijlstra 
Cc: Tycho Andersen 
Link: 
http://lkml.kernel.org/r/3e678474ec14e0a0ec34c611016753eea2e1b8ba.1475257877.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/filesystems/proc.txt |   26 --
 fs/proc/task_mmu.c |   29 ++---
 fs/proc/task_nommu.c   |   26 +-
 3 files changed, 19 insertions(+), 62 deletions(-)

--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -383,32 +383,6 @@ is not associated with a file:
 
  or if empty, the mapping is anonymous.
 
-The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
-of the individual tasks of a process. In this file you will see a mapping 
marked
-as [stack] if that task sees it as a stack. Hence, for the example above, the
-task-level map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like 
this:
-
-08048000-08049000 r-xp  03:00 8312   /opt/test
-08049000-0804a000 rw-p 1000 03:00 8312   /opt/test
-0804a000-0806b000 rw-p  00:00 0  [heap]
-a7cb1000-a7cb2000 ---p  00:00 0
-a7cb2000-a7eb2000 rw-p  00:00 0
-a7eb2000-a7eb3000 ---p  00:00 0
-a7eb3000-a7ed5000 rw-p  00:00 0  [stack]
-a7ed5000-a8008000 r-xp  03:00 4222   /lib/libc.so.6
-a8008000-a800a000 r--p 00133000 03:00 4222   /lib/libc.so.6
-a800a000-a800b000 rw-p 00135000 03:00 4222   /lib/libc.so.6
-a800b000-a800e000 rw-p  00:00 0
-a800e000-a8022000 r-xp  03:00 14462  /lib/libpthread.so.0
-a8022000-a8023000 r--p 00013000 03:00 14462  /lib/libpthread.so.0
-a8023000-a8024000 rw-p 00014000 03:00 14462  /lib/libpthread.so.0
-a8024000-a8027000 rw-p  00:00 0
-a8027000-a8043000 r-xp  03:00 8317   /lib/ld-linux.so.2
-a8043000-a8044000 r--p 0001b000 03:00 8317   /lib/ld-linux.so.2
-a8044000-a8045000 rw-p 0001c000 03:00 8317   /lib/ld-linux.so.2
-aff35000-aff4a000 rw-p  00:00 0
-e000-f000 r-xp  00:00 0  [vdso]
-
 The /proc/PID/smaps is an extension based on maps, showing the memory
 consumption for each of the process's mappings. For each of mappings there
 is a series of lines such as the following:
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -253,24 +253,15 @@ static int do_maps_open(struct inode *in
  * /proc/PID/maps that is the stack of the main task.
  */
 static int is_stack(struct proc_maps_private *priv,
-   struct vm_area_struct *vma, int is_pid)
+   struct vm_area_struct *vma)
 {
-   int stack = 0;
-
-   if (is_pid) {
-   stack = vma->vm_start <= vma->vm_mm->start_stack &&
-   vma->vm_end >= vma->vm_mm->start_stack;
-   } else {
-   struct inode *inode = priv->inode;
-   struct task_struct *task;
-
-   rcu_read_lock();
-   task = pid_task(proc_pid(inode), PIDTYPE_PID);
-   if (task)
-   stack = vma_is_stack_for_task(vma, task);
-   rcu_read_unlock();
-   }
-   return stack;
+   /*
+* We make no effort to guess what a given thread considers to be
+* its "stack".  It's not even well-defined for programs written
+* languages like Go.
+*/
+   return vma->vm_start <= vma->vm_mm->start_stack &&
+   vma->vm_end >= vma->vm_mm->start_stack;
 }
 
 static void
@@ -337,7 +328,7 @@ 

[PATCH 4.4 55/72] Input: i8042 - add Lenovo ThinkPad L460 to i8042 reset list

[Greg Kroah-Hartman]

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

--

From: Dennis Wassenberg 

commit b56af54ac78c54a519d82813836f305d7f76ef27 upstream.

Reset i8042 before probing because of insufficient BIOS initialisation of
the i8042 serial controller. This makes Synaptics touchpad detection
possible. Without resetting the Synaptics touchpad is not detected because
there are always NACK messages from AUX port.

Signed-off-by: Dennis Wassenberg 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -693,6 +693,13 @@ static const struct dmi_system_id __init
},
},
{
+   /* Lenovo ThinkPad L460 */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L460"),
+   },
+   },
+   {
/* Clevo P650RS, 650RP6, Sager NP8152-S, and others */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),

[PATCH 4.4 55/72] Input: i8042 - add Lenovo ThinkPad L460 to i8042 reset list

[Greg Kroah-Hartman]

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

--

From: Dennis Wassenberg 

commit b56af54ac78c54a519d82813836f305d7f76ef27 upstream.

Reset i8042 before probing because of insufficient BIOS initialisation of
the i8042 serial controller. This makes Synaptics touchpad detection
possible. Without resetting the Synaptics touchpad is not detected because
there are always NACK messages from AUX port.

Signed-off-by: Dennis Wassenberg 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -693,6 +693,13 @@ static const struct dmi_system_id __init
},
},
{
+   /* Lenovo ThinkPad L460 */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L460"),
+   },
+   },
+   {
/* Clevo P650RS, 650RP6, Sager NP8152-S, and others */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),

[PATCH 4.4 52/72] crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one

[Greg Kroah-Hartman]

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

--

From: Eric Biggers 

commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream.

With ecb-cast5-avx, if a 128+ byte scatterlist element followed a
shorter one, then the algorithm accidentally encrypted/decrypted only 8
bytes instead of the expected 128 bytes.  Fix it by setting the
encryption/decryption 'fn' correctly.

Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers")
Cc:  # v3.8+
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/crypto/cast5_avx_glue.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -66,8 +66,6 @@ static int ecb_crypt(struct blkcipher_de
void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src);
int err;
 
-   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
-
err = blkcipher_walk_virt(desc, walk);
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
@@ -79,6 +77,7 @@ static int ecb_crypt(struct blkcipher_de
 
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
+   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
do {
fn(ctx, wdst, wsrc);
 

[PATCH 4.4 52/72] crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one

[Greg Kroah-Hartman]

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

--

From: Eric Biggers 

commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream.

With ecb-cast5-avx, if a 128+ byte scatterlist element followed a
shorter one, then the algorithm accidentally encrypted/decrypted only 8
bytes instead of the expected 128 bytes.  Fix it by setting the
encryption/decryption 'fn' correctly.

Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers")
Cc:  # v3.8+
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/crypto/cast5_avx_glue.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -66,8 +66,6 @@ static int ecb_crypt(struct blkcipher_de
void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src);
int err;
 
-   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
-
err = blkcipher_walk_virt(desc, walk);
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
@@ -79,6 +77,7 @@ static int ecb_crypt(struct blkcipher_de
 
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
+   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
do {
fn(ctx, wdst, wsrc);
 

[PATCH 4.9 012/102] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

[Greg Kroah-Hartman]

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

--

From: Masami Hiramatsu 

commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.

Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.

Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.

Link: 
http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox

Signed-off-by: Masami Hiramatsu 
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/kprobes/core.c |9 +
 kernel/kprobes.c   |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -405,6 +406,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
 }
 
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+   set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+   module_memfree(page);
+}
+
 static int arch_copy_kprobe(struct kprobe *p)
 {
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
 }
 
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
 {
module_memfree(page);
 }

[PATCH 4.9 012/102] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

[Greg Kroah-Hartman]

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

--

From: Masami Hiramatsu 

commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.

Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.

Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.

Link: 
http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox

Signed-off-by: Masami Hiramatsu 
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/kprobes/core.c |9 +
 kernel/kprobes.c   |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -405,6 +406,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
 }
 
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+   set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+   module_memfree(page);
+}
+
 static int arch_copy_kprobe(struct kprobe *p)
 {
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
 }
 
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
 {
module_memfree(page);
 }

[PATCH 4.9 001/102] ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]

[Greg Kroah-Hartman]

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

--

From: Fabio Estevam 

commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.

Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.

Fix it by going back to clearing vfp_current_hw_state[].

Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable 
Reported-by: Kohji Okuno 
Signed-off-by: Fabio Estevam 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/vfp/vfpmodule.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
  */
 static int vfp_dying_cpu(unsigned int cpu)
 {
-   vfp_force_reload(cpu, current_thread_info());
+   vfp_current_hw_state[cpu] = NULL;
return 0;
 }
 

[PATCH 4.9 001/102] ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]

[Greg Kroah-Hartman]

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

--

From: Fabio Estevam 

commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.

Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.

Fix it by going back to clearing vfp_current_hw_state[].

Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable 
Reported-by: Kohji Okuno 
Signed-off-by: Fabio Estevam 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/vfp/vfpmodule.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
  */
 static int vfp_dying_cpu(unsigned int cpu)
 {
-   vfp_force_reload(cpu, current_thread_info());
+   vfp_current_hw_state[cpu] = NULL;
return 0;
 }
 

[PATCH 4.9 011/102] partitions/msdos: Unable to mount UFS 44bsd partitions

[Greg Kroah-Hartman]

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

--

From: Richard Narron 

commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.

UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.

Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.

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

Signed-off-by: Richard Narron 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/partitions/msdos.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
-   if (memcmp(flavour, "bsd\0", 4) == 0)
+   /* FreeBSD has relative offset if C partition offset is zero */
+   if (memcmp(flavour, "bsd\0", 4) == 0 &&
+   le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */

[PATCH 4.9 011/102] partitions/msdos: Unable to mount UFS 44bsd partitions

[Greg Kroah-Hartman]

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

--

From: Richard Narron 

commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.

UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.

Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.

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

Signed-off-by: Richard Narron 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/partitions/msdos.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
-   if (memcmp(flavour, "bsd\0", 4) == 0)
+   /* FreeBSD has relative offset if C partition offset is zero */
+   if (memcmp(flavour, "bsd\0", 4) == 0 &&
+   le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */

[PATCH 4.9 014/102] dm ioctl: remove double parentheses

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.

The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().

Also remove another double parentheses that doesn't cause a warning.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Mike Snitzer 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-ioctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1777,12 +1777,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
 
-   if ((cmd == DM_DEV_CREATE_CMD)) {
+   if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
-   } else if ((*param->uuid && *param->name)) {
+   } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}

[PATCH 4.9 014/102] dm ioctl: remove double parentheses

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.

The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().

Also remove another double parentheses that doesn't cause a warning.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Mike Snitzer 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-ioctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1777,12 +1777,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
 
-   if ((cmd == DM_DEV_CREATE_CMD)) {
+   if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
-   } else if ((*param->uuid && *param->name)) {
+   } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}

[PATCH 4.9 016/102] netfilter: nf_nat_h323: fix logical-not-parentheses warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit eee6ebbac18a189ef33d25ea9b8bcae176515e49 upstream.

Clang produces the following warning:

net/ipv4/netfilter/nf_nat_h323.c:553:6: error:
logical not is only applied to the left hand side of this comparison
  [-Werror,-Wlogical-not-parentheses]
if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
^
add parentheses after the '!' to evaluate the comparison first
add parentheses around left hand side expression to silence this warning

There's not necessarily a bug here, but it's cleaner to return early,
ex:

if (x)
  return
...

rather than:

if (x == 0)
  ...
else
  return

Also added a return code check that seemed to be missing in one
instance.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Pablo Neira Ayuso 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/ipv4/netfilter/nf_nat_h323.c |   57 ---
 1 file changed, 30 insertions(+), 27 deletions(-)

--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -252,16 +252,16 @@ static int nat_rtp_rtcp(struct sk_buff *
if (set_h245_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
  htons((port & htons(1)) ? nated_port + 1 :
-   nated_port)) == 0) {
-   /* Save ports */
-   info->rtp_port[i][dir] = rtp_port;
-   info->rtp_port[i][!dir] = htons(nated_port);
-   } else {
+   nated_port))) {
nf_ct_unexpect_related(rtp_exp);
nf_ct_unexpect_related(rtcp_exp);
return -1;
}
 
+   /* Save ports */
+   info->rtp_port[i][dir] = rtp_port;
+   info->rtp_port[i][!dir] = htons(nated_port);
+
/* Success */
pr_debug("nf_nat_h323: expect RTP %pI4:%hu->%pI4:%hu\n",
 _exp->tuple.src.u3.ip,
@@ -370,15 +370,15 @@ static int nat_h245(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
pr_debug("nf_nat_q931: expect H.245 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
 ntohs(exp->tuple.src.u.tcp.port),
@@ -462,24 +462,27 @@ static int nat_q931(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, 0, [idx],
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-
-   /* Fix for Gnomemeeting */
-   if (idx > 0 &&
-   get_h225_addr(ct, *data, [0], , ) &&
-   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
-   set_h225_addr(skb, protoff, data, 0, [0],
- >tuplehash[!dir].tuple.dst.u3,
- info->sig_port[!dir]);
-   }
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
+   /* Fix for Gnomemeeting */
+   if (idx > 0 &&
+   get_h225_addr(ct, *data, [0], , ) &&
+   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
+   if (set_h225_addr(skb, protoff, data, 0, [0],
+ >tuplehash[!dir].tuple.dst.u3,
+ info->sig_port[!dir])) {
+   nf_ct_unexpect_related(exp);
+   return -1;
+   }
+   }
+
/* Success */
pr_debug("nf_nat_ras: expect Q.931 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
@@ -550,9 +553,9 @@ static int nat_callforwarding(struct sk_
}
 
/* Modify signal */
-   if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
-  >tuplehash[!dir].tuple.dst.u3,
-  htons(nated_port)) == 0) {
+   if (set_h225_addr(skb, protoff, data, 

[PATCH 4.9 016/102] netfilter: nf_nat_h323: fix logical-not-parentheses warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit eee6ebbac18a189ef33d25ea9b8bcae176515e49 upstream.

Clang produces the following warning:

net/ipv4/netfilter/nf_nat_h323.c:553:6: error:
logical not is only applied to the left hand side of this comparison
  [-Werror,-Wlogical-not-parentheses]
if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
^
add parentheses after the '!' to evaluate the comparison first
add parentheses around left hand side expression to silence this warning

There's not necessarily a bug here, but it's cleaner to return early,
ex:

if (x)
  return
...

rather than:

if (x == 0)
  ...
else
  return

Also added a return code check that seemed to be missing in one
instance.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Pablo Neira Ayuso 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/ipv4/netfilter/nf_nat_h323.c |   57 ---
 1 file changed, 30 insertions(+), 27 deletions(-)

--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -252,16 +252,16 @@ static int nat_rtp_rtcp(struct sk_buff *
if (set_h245_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
  htons((port & htons(1)) ? nated_port + 1 :
-   nated_port)) == 0) {
-   /* Save ports */
-   info->rtp_port[i][dir] = rtp_port;
-   info->rtp_port[i][!dir] = htons(nated_port);
-   } else {
+   nated_port))) {
nf_ct_unexpect_related(rtp_exp);
nf_ct_unexpect_related(rtcp_exp);
return -1;
}
 
+   /* Save ports */
+   info->rtp_port[i][dir] = rtp_port;
+   info->rtp_port[i][!dir] = htons(nated_port);
+
/* Success */
pr_debug("nf_nat_h323: expect RTP %pI4:%hu->%pI4:%hu\n",
 _exp->tuple.src.u3.ip,
@@ -370,15 +370,15 @@ static int nat_h245(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, dataoff, taddr,
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
pr_debug("nf_nat_q931: expect H.245 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
 ntohs(exp->tuple.src.u.tcp.port),
@@ -462,24 +462,27 @@ static int nat_q931(struct sk_buff *skb,
/* Modify signal */
if (set_h225_addr(skb, protoff, data, 0, [idx],
  >tuplehash[!dir].tuple.dst.u3,
- htons(nated_port)) == 0) {
-   /* Save ports */
-   info->sig_port[dir] = port;
-   info->sig_port[!dir] = htons(nated_port);
-
-   /* Fix for Gnomemeeting */
-   if (idx > 0 &&
-   get_h225_addr(ct, *data, [0], , ) &&
-   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
-   set_h225_addr(skb, protoff, data, 0, [0],
- >tuplehash[!dir].tuple.dst.u3,
- info->sig_port[!dir]);
-   }
-   } else {
+ htons(nated_port))) {
nf_ct_unexpect_related(exp);
return -1;
}
 
+   /* Save ports */
+   info->sig_port[dir] = port;
+   info->sig_port[!dir] = htons(nated_port);
+
+   /* Fix for Gnomemeeting */
+   if (idx > 0 &&
+   get_h225_addr(ct, *data, [0], , ) &&
+   (ntohl(addr.ip) & 0xff00) == 0x7f00) {
+   if (set_h225_addr(skb, protoff, data, 0, [0],
+ >tuplehash[!dir].tuple.dst.u3,
+ info->sig_port[!dir])) {
+   nf_ct_unexpect_related(exp);
+   return -1;
+   }
+   }
+
/* Success */
pr_debug("nf_nat_ras: expect Q.931 %pI4:%hu->%pI4:%hu\n",
 >tuple.src.u3.ip,
@@ -550,9 +553,9 @@ static int nat_callforwarding(struct sk_
}
 
/* Modify signal */
-   if (!set_h225_addr(skb, protoff, data, dataoff, taddr,
-  >tuplehash[!dir].tuple.dst.u3,
-  htons(nated_port)) == 0) {
+   if (set_h225_addr(skb, protoff, data, dataoff, taddr,
+ >tuplehash[!dir].tuple.dst.u3,
+ htons(nated_port))) {
 

[PATCH 4.9 013/102] PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.

A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".

Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Bjorn Helgaas 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/probe.c   |2 +-
 drivers/pci/setup-res.c   |2 +-
 include/uapi/linux/pci_regs.h |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -231,7 +231,7 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_ROM_ENABLE;
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
-   mask64 = (u32)PCI_ROM_ADDRESS_MASK;
+   mask64 = PCI_ROM_ADDRESS_MASK;
}
 
if (res->flags & IORESOURCE_MEM_64) {
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -63,7 +63,7 @@ static void pci_std_update_resource(stru
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
-   mask = (u32)PCI_ROM_ADDRESS_MASK;
+   mask = PCI_ROM_ADDRESS_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -106,7 +106,7 @@
 #define PCI_SUBSYSTEM_ID   0x2e
 #define PCI_ROM_ADDRESS0x30/* Bits 31..11 are address, 
10..1 reserved */
 #define  PCI_ROM_ADDRESS_ENABLE0x01
-#define PCI_ROM_ADDRESS_MASK   (~0x7ffUL)
+#define PCI_ROM_ADDRESS_MASK   (~0x7ffU)
 
 #define PCI_CAPABILITY_LIST0x34/* Offset of first capability list 
entry */
 

[PATCH 4.9 015/102] Input: mousedev - fix implicit conversion warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit dae1a432ab1fe79ae53129ededeaece35a2dc14d upstream.

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~
As the PS2 data is really a stream of bytes, let's switch to using u8 type
for it, which silences this warning.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Dmitry Torokhov 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/mousedev.c |   62 +--
 1 file changed, 34 insertions(+), 28 deletions(-)

--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -15,6 +15,7 @@
 #define MOUSEDEV_MINORS31
 #define MOUSEDEV_MIX   63
 
+#include 
 #include 
 #include 
 #include 
@@ -103,7 +104,7 @@ struct mousedev_client {
spinlock_t packet_lock;
int pos_x, pos_y;
 
-   signed char ps2[6];
+   u8 ps2[6];
unsigned char ready, buffer, bufsiz;
unsigned char imexseq, impsseq;
enum mousedev_emul mode;
@@ -291,11 +292,10 @@ static void mousedev_notify_readers(stru
}
 
client->pos_x += packet->dx;
-   client->pos_x = client->pos_x < 0 ?
-   0 : (client->pos_x >= xres ? xres : client->pos_x);
+   client->pos_x = clamp_val(client->pos_x, 0, xres);
+
client->pos_y += packet->dy;
-   client->pos_y = client->pos_y < 0 ?
-   0 : (client->pos_y >= yres ? yres : client->pos_y);
+   client->pos_y = clamp_val(client->pos_y, 0, yres);
 
p->dx += packet->dx;
p->dy += packet->dy;
@@ -571,44 +571,50 @@ static int mousedev_open(struct inode *i
return error;
 }
 
-static inline int mousedev_limit_delta(int delta, int limit)
-{
-   return delta > limit ? limit : (delta < -limit ? -limit : delta);
-}
-
-static void mousedev_packet(struct mousedev_client *client,
-   signed char *ps2_data)
+static void mousedev_packet(struct mousedev_client *client, u8 *ps2_data)
 {
struct mousedev_motion *p = >packets[client->tail];
+   s8 dx, dy, dz;
+
+   dx = clamp_val(p->dx, -127, 127);
+   p->dx -= dx;
+
+   dy = clamp_val(p->dy, -127, 127);
+   p->dy -= dy;
 
-   ps2_data[0] = 0x08 |
-   ((p->dx < 0) << 4) | ((p->dy < 0) << 5) | (p->buttons & 0x07);
-   ps2_data[1] = mousedev_limit_delta(p->dx, 127);
-   ps2_data[2] = mousedev_limit_delta(p->dy, 127);
-   p->dx -= ps2_data[1];
-   p->dy -= ps2_data[2];
+   ps2_data[0] = BIT(3);
+   ps2_data[0] |= ((dx & BIT(7)) >> 3) | ((dy & BIT(7)) >> 2);
+   ps2_data[0] |= p->buttons & 0x07;
+   ps2_data[1] = dx;
+   ps2_data[2] = dy;
 
switch (client->mode) {
case MOUSEDEV_EMUL_EXPS:
-   ps2_data[3] = mousedev_limit_delta(p->dz, 7);
-   p->dz -= ps2_data[3];
-   ps2_data[3] = (ps2_data[3] & 0x0f) | ((p->buttons & 0x18) << 1);
+   dz = clamp_val(p->dz, -7, 7);
+   p->dz -= dz;
+
+   ps2_data[3] = (dz & 0x0f) | ((p->buttons & 0x18) << 1);
client->bufsiz = 4;
break;
 
case MOUSEDEV_EMUL_IMPS:
-   ps2_data[0] |=
-   ((p->buttons & 0x10) >> 3) | ((p->buttons & 0x08) >> 1);
-   ps2_data[3] = mousedev_limit_delta(p->dz, 127);
-   p->dz -= ps2_data[3];
+   dz = clamp_val(p->dz, -127, 127);
+   p->dz -= dz;
+
+   ps2_data[0] |= ((p->buttons & 0x10) >> 3) |
+  ((p->buttons & 0x08) >> 1);
+   ps2_data[3] = dz;
+
client->bufsiz = 4;
break;
 
case MOUSEDEV_EMUL_PS2:
default:
-   ps2_data[0] |=
-   ((p->buttons & 0x10) >> 3) | ((p->buttons & 0x08) >> 1);
p->dz = 0;
+
+   ps2_data[0] |= ((p->buttons & 0x10) >> 3) |
+  ((p->buttons & 0x08) >> 1);
+
client->bufsiz = 3;
break;
}
@@ -714,7 +720,7 @@ static ssize_t mousedev_read(struct file
 {
struct mousedev_client *client = file->private_data;
struct mousedev *mousedev = client->mousedev;
-   signed char data[sizeof(client->ps2)];
+   u8 data[sizeof(client->ps2)];
int retval = 0;
 
if (!client->ready && !client->buffer && mousedev->exist &&

[PATCH 4.9 013/102] PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.

A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".

Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Bjorn Helgaas 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/probe.c   |2 +-
 drivers/pci/setup-res.c   |2 +-
 include/uapi/linux/pci_regs.h |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -231,7 +231,7 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_ROM_ENABLE;
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
-   mask64 = (u32)PCI_ROM_ADDRESS_MASK;
+   mask64 = PCI_ROM_ADDRESS_MASK;
}
 
if (res->flags & IORESOURCE_MEM_64) {
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -63,7 +63,7 @@ static void pci_std_update_resource(stru
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
-   mask = (u32)PCI_ROM_ADDRESS_MASK;
+   mask = PCI_ROM_ADDRESS_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -106,7 +106,7 @@
 #define PCI_SUBSYSTEM_ID   0x2e
 #define PCI_ROM_ADDRESS0x30/* Bits 31..11 are address, 
10..1 reserved */
 #define  PCI_ROM_ADDRESS_ENABLE0x01
-#define PCI_ROM_ADDRESS_MASK   (~0x7ffUL)
+#define PCI_ROM_ADDRESS_MASK   (~0x7ffU)
 
 #define PCI_CAPABILITY_LIST0x34/* Offset of first capability list 
entry */
 

[PATCH 4.9 015/102] Input: mousedev - fix implicit conversion warning

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit dae1a432ab1fe79ae53129ededeaece35a2dc14d upstream.

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~
As the PS2 data is really a stream of bytes, let's switch to using u8 type
for it, which silences this warning.

Signed-off-by: Nick Desaulniers 
Signed-off-by: Dmitry Torokhov 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/mousedev.c |   62 +--
 1 file changed, 34 insertions(+), 28 deletions(-)

--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -15,6 +15,7 @@
 #define MOUSEDEV_MINORS31
 #define MOUSEDEV_MIX   63
 
+#include 
 #include 
 #include 
 #include 
@@ -103,7 +104,7 @@ struct mousedev_client {
spinlock_t packet_lock;
int pos_x, pos_y;
 
-   signed char ps2[6];
+   u8 ps2[6];
unsigned char ready, buffer, bufsiz;
unsigned char imexseq, impsseq;
enum mousedev_emul mode;
@@ -291,11 +292,10 @@ static void mousedev_notify_readers(stru
}
 
client->pos_x += packet->dx;
-   client->pos_x = client->pos_x < 0 ?
-   0 : (client->pos_x >= xres ? xres : client->pos_x);
+   client->pos_x = clamp_val(client->pos_x, 0, xres);
+
client->pos_y += packet->dy;
-   client->pos_y = client->pos_y < 0 ?
-   0 : (client->pos_y >= yres ? yres : client->pos_y);
+   client->pos_y = clamp_val(client->pos_y, 0, yres);
 
p->dx += packet->dx;
p->dy += packet->dy;
@@ -571,44 +571,50 @@ static int mousedev_open(struct inode *i
return error;
 }
 
-static inline int mousedev_limit_delta(int delta, int limit)
-{
-   return delta > limit ? limit : (delta < -limit ? -limit : delta);
-}
-
-static void mousedev_packet(struct mousedev_client *client,
-   signed char *ps2_data)
+static void mousedev_packet(struct mousedev_client *client, u8 *ps2_data)
 {
struct mousedev_motion *p = >packets[client->tail];
+   s8 dx, dy, dz;
+
+   dx = clamp_val(p->dx, -127, 127);
+   p->dx -= dx;
+
+   dy = clamp_val(p->dy, -127, 127);
+   p->dy -= dy;
 
-   ps2_data[0] = 0x08 |
-   ((p->dx < 0) << 4) | ((p->dy < 0) << 5) | (p->buttons & 0x07);
-   ps2_data[1] = mousedev_limit_delta(p->dx, 127);
-   ps2_data[2] = mousedev_limit_delta(p->dy, 127);
-   p->dx -= ps2_data[1];
-   p->dy -= ps2_data[2];
+   ps2_data[0] = BIT(3);
+   ps2_data[0] |= ((dx & BIT(7)) >> 3) | ((dy & BIT(7)) >> 2);
+   ps2_data[0] |= p->buttons & 0x07;
+   ps2_data[1] = dx;
+   ps2_data[2] = dy;
 
switch (client->mode) {
case MOUSEDEV_EMUL_EXPS:
-   ps2_data[3] = mousedev_limit_delta(p->dz, 7);
-   p->dz -= ps2_data[3];
-   ps2_data[3] = (ps2_data[3] & 0x0f) | ((p->buttons & 0x18) << 1);
+   dz = clamp_val(p->dz, -7, 7);
+   p->dz -= dz;
+
+   ps2_data[3] = (dz & 0x0f) | ((p->buttons & 0x18) << 1);
client->bufsiz = 4;
break;
 
case MOUSEDEV_EMUL_IMPS:
-   ps2_data[0] |=
-   ((p->buttons & 0x10) >> 3) | ((p->buttons & 0x08) >> 1);
-   ps2_data[3] = mousedev_limit_delta(p->dz, 127);
-   p->dz -= ps2_data[3];
+   dz = clamp_val(p->dz, -127, 127);
+   p->dz -= dz;
+
+   ps2_data[0] |= ((p->buttons & 0x10) >> 3) |
+  ((p->buttons & 0x08) >> 1);
+   ps2_data[3] = dz;
+
client->bufsiz = 4;
break;
 
case MOUSEDEV_EMUL_PS2:
default:
-   ps2_data[0] |=
-   ((p->buttons & 0x10) >> 3) | ((p->buttons & 0x08) >> 1);
p->dz = 0;
+
+   ps2_data[0] |= ((p->buttons & 0x10) >> 3) |
+  ((p->buttons & 0x08) >> 1);
+
client->bufsiz = 3;
break;
}
@@ -714,7 +720,7 @@ static ssize_t mousedev_read(struct file
 {
struct mousedev_client *client = file->private_data;
struct mousedev *mousedev = client->mousedev;
-   signed char data[sizeof(client->ps2)];
+   u8 data[sizeof(client->ps2)];
int retval = 0;
 
if (!client->ready && !client->buffer && mousedev->exist &&

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

[Dave Hansen]

I'm having a really hard time tying all the pieces back together.  Let
me give it a shot and you can tell me where I go wrong.

On 02/27/2018 07:26 PM, Baoquan He wrote:
> In sparse_init(), two temporary pointer arrays, usemap_map and map_map
> are allocated with the size of NR_MEM_SECTIONS.

In sparse_init(), two temporary pointer arrays, usemap_map and map_map
are allocated to hold the maps for every possible memory section
(NR_MEM_SECTIONS).  However, we obviously only need the array sized for
nr_present_sections (introduced in patch 1).

The reason this is a problem is that, with 5-level paging,
NR_MEM_SECTIONS (8M->512M) went up dramatically and these temporary
arrays can eat all of memory, like on kdump kernels.

This patch does two things: it makes sure to give usemap_map/mem_map a
less gluttonous size on small systems, and it changes the map allocation
and handling to handle the now more compact, less sparse arrays.

---

The code looks fine to me.  It's a bit of a shame that there's no
verification to ensure that idx_present never goes beyond the shiny new
nr_present_sections.


> @@ -583,6 +592,7 @@ void __init sparse_init(void)
>   unsigned long *usemap;
>   unsigned long **usemap_map;
>   int size;
> + int idx_present = 0;

I wonder whether idx_present is a good name.  Isn't it the number of
consumed mem_map[]s or usemaps?

> 
>   if (!map) {
>   ms->section_mem_map = 0;
> + idx_present++;
>   continue;
>   }
>  


This hunk seems logically odd to me.  I would expect a non-used section
to *not* consume an entry from the temporary array.  Why does it?  The
error and success paths seem to do the same thing.

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

[Dave Hansen]

I'm having a really hard time tying all the pieces back together.  Let
me give it a shot and you can tell me where I go wrong.

On 02/27/2018 07:26 PM, Baoquan He wrote:
> In sparse_init(), two temporary pointer arrays, usemap_map and map_map
> are allocated with the size of NR_MEM_SECTIONS.

In sparse_init(), two temporary pointer arrays, usemap_map and map_map
are allocated to hold the maps for every possible memory section
(NR_MEM_SECTIONS).  However, we obviously only need the array sized for
nr_present_sections (introduced in patch 1).

The reason this is a problem is that, with 5-level paging,
NR_MEM_SECTIONS (8M->512M) went up dramatically and these temporary
arrays can eat all of memory, like on kdump kernels.

This patch does two things: it makes sure to give usemap_map/mem_map a
less gluttonous size on small systems, and it changes the map allocation
and handling to handle the now more compact, less sparse arrays.

---

The code looks fine to me.  It's a bit of a shame that there's no
verification to ensure that idx_present never goes beyond the shiny new
nr_present_sections.


> @@ -583,6 +592,7 @@ void __init sparse_init(void)
>   unsigned long *usemap;
>   unsigned long **usemap_map;
>   int size;
> + int idx_present = 0;

I wonder whether idx_present is a good name.  Isn't it the number of
consumed mem_map[]s or usemaps?

> 
>   if (!map) {
>   ms->section_mem_map = 0;
> + idx_present++;
>   continue;
>   }
>  


This hunk seems logically odd to me.  I would expect a non-used section
to *not* consume an entry from the temporary array.  Why does it?  The
error and success paths seem to do the same thing.

[PATCH 4.9 018/102] cpumask: Add helper cpumask_available()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.

With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.

Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:

kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]

Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.

Signed-off-by: Matthias Kaehlcke 
Cc: Grant Grundler 
Cc: Rusty Russell 
Cc: Greg Hackmann 
Cc: Michael Davidson 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20170412182030.83657-1-...@chromium.org
Signed-off-by: Thomas Gleixner 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/cpumask.h |   10 ++
 1 file changed, 10 insertions(+)

--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -680,6 +680,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
 void free_cpumask_var(cpumask_var_t mask);
 void free_bootmem_cpumask_var(cpumask_var_t mask);
 
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return mask != NULL;
+}
+
 #else
 typedef struct cpumask cpumask_var_t[1];
 
@@ -720,6 +725,11 @@ static inline void free_cpumask_var(cpum
 static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 }
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return true;
+}
 #endif /* CONFIG_CPUMASK_OFFSTACK */
 
 /* It's common to want to use cpu_all_mask in struct member initializers,

[PATCH 4.9 020/102] fs: compat: Remove warning from COMPATIBLE_IOCTL

[Greg Kroah-Hartman]

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

--

From: Mark Charlebois 

commit 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 upstream.

cmd in COMPATIBLE_IOCTL is always a u32, so cast it so there isn't a
warning about an overflow in XFORM.

From: Mark Charlebois 
Signed-off-by: Mark Charlebois 
Signed-off-by: Behan Webster 
Signed-off-by: Matthias Kaehlcke 
Acked-by: Arnd Bergmann 
Signed-off-by: Al Viro 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/compat_ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -833,7 +833,7 @@ static int compat_ioctl_preallocate(stru
  */
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 
-#define COMPATIBLE_IOCTL(cmd) XFORM(cmd),
+#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
 /* ioctl should not be warned about even if it's not implemented.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs

[PATCH 4.9 018/102] cpumask: Add helper cpumask_available()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.

With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.

Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:

kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]

Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.

Signed-off-by: Matthias Kaehlcke 
Cc: Grant Grundler 
Cc: Rusty Russell 
Cc: Greg Hackmann 
Cc: Michael Davidson 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20170412182030.83657-1-...@chromium.org
Signed-off-by: Thomas Gleixner 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/cpumask.h |   10 ++
 1 file changed, 10 insertions(+)

--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -680,6 +680,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
 void free_cpumask_var(cpumask_var_t mask);
 void free_bootmem_cpumask_var(cpumask_var_t mask);
 
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return mask != NULL;
+}
+
 #else
 typedef struct cpumask cpumask_var_t[1];
 
@@ -720,6 +725,11 @@ static inline void free_cpumask_var(cpum
 static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 }
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+   return true;
+}
 #endif /* CONFIG_CPUMASK_OFFSTACK */
 
 /* It's common to want to use cpu_all_mask in struct member initializers,

[PATCH 4.9 020/102] fs: compat: Remove warning from COMPATIBLE_IOCTL

[Greg Kroah-Hartman]

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

--

From: Mark Charlebois 

commit 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 upstream.

cmd in COMPATIBLE_IOCTL is always a u32, so cast it so there isn't a
warning about an overflow in XFORM.

From: Mark Charlebois 
Signed-off-by: Mark Charlebois 
Signed-off-by: Behan Webster 
Signed-off-by: Matthias Kaehlcke 
Acked-by: Arnd Bergmann 
Signed-off-by: Al Viro 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/compat_ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -833,7 +833,7 @@ static int compat_ioctl_preallocate(stru
  */
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 
-#define COMPATIBLE_IOCTL(cmd) XFORM(cmd),
+#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
 /* ioctl should not be warned about even if it's not implemented.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs

[PATCH 4.9 019/102] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Paul Moore 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 security/selinux/ss/services.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
 
k = 0;
-   while (p_in->perms && p_in->perms[k]) {
+   while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;

[PATCH 4.9 019/102] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Paul Moore 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 security/selinux/ss/services.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
 
k = 0;
-   while (p_in->perms && p_in->perms[k]) {
+   while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;

[PATCH 4.9 002/102] mtd: jedec_probe: Fix crash in jedec_read_mfr()

[Greg Kroah-Hartman]

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

--

From: Linus Walleij 

commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.

It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:

Unable to handle kernel paging request at virtual address c498
pgd = (ptrval)
[c498] *pgd=03808811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : []lr : [<0004>]psr: 6013
sp : c382dd18  ip :   fp : 
r10: c0626388  r9 : 0002  r8 : c0626340
r7 :   r6 : 0001  r5 : c3a71afc  r4 : c382dd70
r3 : 0001  r2 : c490  r1 : 0002  r0 : 0008
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 397f  Table: 4000  DAC: 0053
Process swapper (pid: 1, stack limit = 0x(ptrval))

Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.

Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank 
other than 0")
Cc: 
Signed-off-by: Linus Walleij 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/chips/jedec_probe.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+   if (ofs >= map->size)
+   return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);

[PATCH 4.9 002/102] mtd: jedec_probe: Fix crash in jedec_read_mfr()

[Greg Kroah-Hartman]

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

--

From: Linus Walleij 

commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.

It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:

Unable to handle kernel paging request at virtual address c498
pgd = (ptrval)
[c498] *pgd=03808811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : []lr : [<0004>]psr: 6013
sp : c382dd18  ip :   fp : 
r10: c0626388  r9 : 0002  r8 : c0626340
r7 :   r6 : 0001  r5 : c3a71afc  r4 : c382dd70
r3 : 0001  r2 : c490  r1 : 0002  r0 : 0008
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 397f  Table: 4000  DAC: 0053
Process swapper (pid: 1, stack limit = 0x(ptrval))

Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.

Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank 
other than 0")
Cc: 
Signed-off-by: Linus Walleij 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/chips/jedec_probe.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+   if (ofs >= map->size)
+   return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);

Re: [PATCH 2/7] arm64: dts: renesas: r8a77970: add VSPD support

[Laurent Pinchart]

On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote:
> From: Sergei Shtylyov 
> 
> Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> the next patch...
> 
> Based on the original (and large) patch by Daisuke Matsushita
> .
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77970.dtsi index 71f466d..db06c94 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -625,6 +625,16 @@
>   power-domains = < R8A77970_PD_ALWAYS_ON>;
>   resets = < 603>;
>   };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x4000>;

You need to extend the memory region to include the V6_CLUTn_TBL* registers. I 
would recommend simply extending it to 0x8000 as all other VSP instances, even 
if the registers at 0x7000-0x7fff are not implemented.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
>   };
> 
>   timer {

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/7] arm64: dts: renesas: r8a77970: add VSPD support

[Laurent Pinchart]

On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote:
> From: Sergei Shtylyov 
> 
> Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> the next patch...
> 
> Based on the original (and large) patch by Daisuke Matsushita
> .
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77970.dtsi index 71f466d..db06c94 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -625,6 +625,16 @@
>   power-domains = < R8A77970_PD_ALWAYS_ON>;
>   resets = < 603>;
>   };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x4000>;

You need to extend the memory region to include the V6_CLUTn_TBL* registers. I 
would recommend simply extending it to 0x8000 as all other VSP instances, even 
if the registers at 0x7000-0x7fff are not implemented.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
>   };
> 
>   timer {

-- 
Regards,

Laurent Pinchart

[PATCH 4.9 022/102] frv: declare jiffies to be located in the .data section

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 upstream.

Commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with
cacheline_aligned_in_smp") removed a section specification from the
jiffies declaration that caused conflicts on some platforms.

Unfortunately this change broke the build for frv:

  kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation 
truncated to fit: R_FRV_GPREL12 against symbol
  `jiffies' defined in *ABS* section in .tmp_vmlinux1
  kernel/built-in.o: In function `__do_softirq': (.text+0x6574): relocation 
truncated to fit: R_FRV_GPREL12 against symbol
  `jiffies' defined in *ABS* section in .tmp_vmlinux1
  kernel/built-in.o: In function `pwq_activate_delayed_work': 
workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
  symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
  ...

Add __jiffy_arch_data to the declaration of jiffies and use it on frv to
include the section specification.  For all other platforms
__jiffy_arch_data (currently) has no effect.

Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with 
cacheline_aligned_in_smp")
Link: http://lkml.kernel.org/r/20170516221333.177280-1-...@chromium.org
Signed-off-by: Matthias Kaehlcke 
Reported-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Reviewed-by: David Howells 
Cc: Sudip Mukherjee 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/frv/include/asm/timex.h |6 ++
 include/linux/jiffies.h  |6 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

--- a/arch/frv/include/asm/timex.h
+++ b/arch/frv/include/asm/timex.h
@@ -16,5 +16,11 @@ static inline cycles_t get_cycles(void)
 #define vxtime_lock()  do {} while (0)
 #define vxtime_unlock()do {} while (0)
 
+/* This attribute is used in include/linux/jiffies.h alongside with
+ * __cacheline_aligned_in_smp. It is assumed that __cacheline_aligned_in_smp
+ * for frv does not contain another section specification.
+ */
+#define __jiffy_arch_data  __attribute__((__section__(".data")))
+
 #endif
 
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -64,13 +64,17 @@ extern int register_refined_jiffies(long
 /* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
 #define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
 
+#ifndef __jiffy_arch_data
+#define __jiffy_arch_data
+#endif
+
 /*
  * The 64-bit value is not atomic - you MUST NOT read it
  * without sampling the sequence number in jiffies_lock.
  * get_jiffies_64() will do this for you as appropriate.
  */
 extern u64 __cacheline_aligned_in_smp jiffies_64;
-extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
+extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data 
jiffies;
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void);

[PATCH 4.9 022/102] frv: declare jiffies to be located in the .data section

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 upstream.

Commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with
cacheline_aligned_in_smp") removed a section specification from the
jiffies declaration that caused conflicts on some platforms.

Unfortunately this change broke the build for frv:

  kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation 
truncated to fit: R_FRV_GPREL12 against symbol
  `jiffies' defined in *ABS* section in .tmp_vmlinux1
  kernel/built-in.o: In function `__do_softirq': (.text+0x6574): relocation 
truncated to fit: R_FRV_GPREL12 against symbol
  `jiffies' defined in *ABS* section in .tmp_vmlinux1
  kernel/built-in.o: In function `pwq_activate_delayed_work': 
workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
  symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
  ...

Add __jiffy_arch_data to the declaration of jiffies and use it on frv to
include the section specification.  For all other platforms
__jiffy_arch_data (currently) has no effect.

Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with 
cacheline_aligned_in_smp")
Link: http://lkml.kernel.org/r/20170516221333.177280-1-...@chromium.org
Signed-off-by: Matthias Kaehlcke 
Reported-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Reviewed-by: David Howells 
Cc: Sudip Mukherjee 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/frv/include/asm/timex.h |6 ++
 include/linux/jiffies.h  |6 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

--- a/arch/frv/include/asm/timex.h
+++ b/arch/frv/include/asm/timex.h
@@ -16,5 +16,11 @@ static inline cycles_t get_cycles(void)
 #define vxtime_lock()  do {} while (0)
 #define vxtime_unlock()do {} while (0)
 
+/* This attribute is used in include/linux/jiffies.h alongside with
+ * __cacheline_aligned_in_smp. It is assumed that __cacheline_aligned_in_smp
+ * for frv does not contain another section specification.
+ */
+#define __jiffy_arch_data  __attribute__((__section__(".data")))
+
 #endif
 
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -64,13 +64,17 @@ extern int register_refined_jiffies(long
 /* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
 #define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
 
+#ifndef __jiffy_arch_data
+#define __jiffy_arch_data
+#endif
+
 /*
  * The 64-bit value is not atomic - you MUST NOT read it
  * without sampling the sequence number in jiffies_lock.
  * get_jiffies_64() will do this for you as appropriate.
  */
 extern u64 __cacheline_aligned_in_smp jiffies_64;
-extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
+extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data 
jiffies;
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void);

[PATCH 4.9 021/102] jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 7c30f352c852bae2715ad65ac4a38ca9af7d7696 upstream.

jiffies_64 is defined in kernel/time/timer.c with
cacheline_aligned_in_smp, however this macro is not part of the
declaration of jiffies and jiffies_64 in jiffies.h.

As a result clang generates the following warning:

  kernel/time/timer.c:57:26: error: section does not match previous declaration 
[-Werror,-Wsection]
  __visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
   ^
  include/linux/cache.h:39:36: note: expanded from macro 
'__cacheline_aligned_in_smp'
 ^
  include/linux/cache.h:34:4: note: expanded from macro '__cacheline_aligned'
   __section__(".data..cacheline_aligned")))
   ^
  include/linux/jiffies.h:77:12: note: previous attribute is here
  extern u64 __jiffy_data jiffies_64;
 ^
  include/linux/jiffies.h:70:38: note: expanded from macro '__jiffy_data'

Link: http://lkml.kernel.org/r/20170403190200.70273-1-...@chromium.org
Signed-off-by: Matthias Kaehlcke 
Cc: "Jason A . Donenfeld" 
Cc: Grant Grundler 
Cc: Michael Davidson 
Cc: Greg Hackmann 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/jiffies.h |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_JIFFIES_H
 #define _LINUX_JIFFIES_H
 
+#include 
 #include 
 #include 
 #include 
@@ -63,19 +64,13 @@ extern int register_refined_jiffies(long
 /* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
 #define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
 
-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data  __attribute__((section(".data")))
-
 /*
  * The 64-bit value is not atomic - you MUST NOT read it
  * without sampling the sequence number in jiffies_lock.
  * get_jiffies_64() will do this for you as appropriate.
  */
-extern u64 __jiffy_data jiffies_64;
-extern unsigned long volatile __jiffy_data jiffies;
+extern u64 __cacheline_aligned_in_smp jiffies_64;
+extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void);

[PATCH 4.9 024/102] xgene_enet: remove bogus forward declarations

[Greg Kroah-Hartman]

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

--

From: Arnd Bergmann 

commit 1f3d62090d3ba4d0c14e5271be87812fc577b197 upstream.

The device match tables for both the xgene_enet driver and its phy driver
have forward declarations that declare an array without a length, leading
to a clang warning when they are not followed by an actual defitinition:

drivers/net/ethernet/apm/xgene/../../../phy/mdio-xgene.h:135:34: warning: 
tentative array definition assumed to have one element
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning: tentative 
array definition assumed to have one element

The declarations for the mdio driver are even in a header file, so they
cause duplicate definitions of the tables for each file that includes
them.

This removes all four forward declarations and moves the actual
definitions up a little, so they are in front of their first user. For
the OF match tables, this means having to remove the #ifdef around them,
and passing the actual structure into of_match_device(). This has no
effect on the generated object code though, as the of_match_device
function has an empty stub that does not evaluate its argument, and
the symbol gets dropped either way.

Fixes: 43b3cf6634a4 ("drivers: net: phy: xgene: Add MDIO driver")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |   50 +++
 drivers/net/phy/mdio-xgene.c |   50 +++
 drivers/net/phy/mdio-xgene.h |4 -
 3 files changed, 48 insertions(+), 56 deletions(-)

--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1680,6 +1680,30 @@ static void xgene_enet_napi_add(struct x
}
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_enet_acpi_match[] = {
+   { "APMC0D05", XGENE_ENET1},
+   { "APMC0D30", XGENE_ENET1},
+   { "APMC0D31", XGENE_ENET1},
+   { "APMC0D3F", XGENE_ENET1},
+   { "APMC0D26", XGENE_ENET2},
+   { "APMC0D25", XGENE_ENET2},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
+#endif
+
+static const struct of_device_id xgene_enet_of_match[] = {
+   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
+   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
+   {},
+};
+
+MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
+
 static int xgene_enet_probe(struct platform_device *pdev)
 {
struct net_device *ndev;
@@ -1826,32 +1850,6 @@ static void xgene_enet_shutdown(struct p
xgene_enet_remove(pdev);
 }
 
-#ifdef CONFIG_ACPI
-static const struct acpi_device_id xgene_enet_acpi_match[] = {
-   { "APMC0D05", XGENE_ENET1},
-   { "APMC0D30", XGENE_ENET1},
-   { "APMC0D31", XGENE_ENET1},
-   { "APMC0D3F", XGENE_ENET1},
-   { "APMC0D26", XGENE_ENET2},
-   { "APMC0D25", XGENE_ENET2},
-   { }
-};
-MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
-#endif
-
-#ifdef CONFIG_OF
-static const struct of_device_id xgene_enet_of_match[] = {
-   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
-   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
-   {},
-};
-
-MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
-#endif
-
 static struct platform_driver xgene_enet_driver = {
.driver = {
   .name = "xgene-enet",
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -314,6 +314,30 @@ static acpi_status acpi_register_phy(acp
 }
 #endif
 
+static const struct of_device_id xgene_mdio_of_match[] = {
+   {
+   .compatible = "apm,xgene-mdio-rgmii",
+   .data = (void *)XGENE_MDIO_RGMII
+   },
+   {
+   .compatible = "apm,xgene-mdio-xfi",
+   .data = (void *)XGENE_MDIO_XFI
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, xgene_mdio_of_match);
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_mdio_acpi_match[] = {
+   { "APMC0D65", XGENE_MDIO_RGMII },
+   { "APMC0D66", XGENE_MDIO_XFI },
+   { }
+};
+
+MODULE_DEVICE_TABLE(acpi, xgene_mdio_acpi_match);
+#endif
+
+
 static int xgene_mdio_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -439,32 +463,6 @@ static int 

[PATCH 4.9 021/102] jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit 7c30f352c852bae2715ad65ac4a38ca9af7d7696 upstream.

jiffies_64 is defined in kernel/time/timer.c with
cacheline_aligned_in_smp, however this macro is not part of the
declaration of jiffies and jiffies_64 in jiffies.h.

As a result clang generates the following warning:

  kernel/time/timer.c:57:26: error: section does not match previous declaration 
[-Werror,-Wsection]
  __visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
   ^
  include/linux/cache.h:39:36: note: expanded from macro 
'__cacheline_aligned_in_smp'
 ^
  include/linux/cache.h:34:4: note: expanded from macro '__cacheline_aligned'
   __section__(".data..cacheline_aligned")))
   ^
  include/linux/jiffies.h:77:12: note: previous attribute is here
  extern u64 __jiffy_data jiffies_64;
 ^
  include/linux/jiffies.h:70:38: note: expanded from macro '__jiffy_data'

Link: http://lkml.kernel.org/r/20170403190200.70273-1-...@chromium.org
Signed-off-by: Matthias Kaehlcke 
Cc: "Jason A . Donenfeld" 
Cc: Grant Grundler 
Cc: Michael Davidson 
Cc: Greg Hackmann 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/jiffies.h |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_JIFFIES_H
 #define _LINUX_JIFFIES_H
 
+#include 
 #include 
 #include 
 #include 
@@ -63,19 +64,13 @@ extern int register_refined_jiffies(long
 /* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
 #define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
 
-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data  __attribute__((section(".data")))
-
 /*
  * The 64-bit value is not atomic - you MUST NOT read it
  * without sampling the sequence number in jiffies_lock.
  * get_jiffies_64() will do this for you as appropriate.
  */
-extern u64 __jiffy_data jiffies_64;
-extern unsigned long volatile __jiffy_data jiffies;
+extern u64 __cacheline_aligned_in_smp jiffies_64;
+extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void);

[PATCH 4.9 024/102] xgene_enet: remove bogus forward declarations

[Greg Kroah-Hartman]

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

--

From: Arnd Bergmann 

commit 1f3d62090d3ba4d0c14e5271be87812fc577b197 upstream.

The device match tables for both the xgene_enet driver and its phy driver
have forward declarations that declare an array without a length, leading
to a clang warning when they are not followed by an actual defitinition:

drivers/net/ethernet/apm/xgene/../../../phy/mdio-xgene.h:135:34: warning: 
tentative array definition assumed to have one element
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning: tentative 
array definition assumed to have one element

The declarations for the mdio driver are even in a header file, so they
cause duplicate definitions of the tables for each file that includes
them.

This removes all four forward declarations and moves the actual
definitions up a little, so they are in front of their first user. For
the OF match tables, this means having to remove the #ifdef around them,
and passing the actual structure into of_match_device(). This has no
effect on the generated object code though, as the of_match_device
function has an empty stub that does not evaluate its argument, and
the symbol gets dropped either way.

Fixes: 43b3cf6634a4 ("drivers: net: phy: xgene: Add MDIO driver")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |   50 +++
 drivers/net/phy/mdio-xgene.c |   50 +++
 drivers/net/phy/mdio-xgene.h |4 -
 3 files changed, 48 insertions(+), 56 deletions(-)

--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1680,6 +1680,30 @@ static void xgene_enet_napi_add(struct x
}
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_enet_acpi_match[] = {
+   { "APMC0D05", XGENE_ENET1},
+   { "APMC0D30", XGENE_ENET1},
+   { "APMC0D31", XGENE_ENET1},
+   { "APMC0D3F", XGENE_ENET1},
+   { "APMC0D26", XGENE_ENET2},
+   { "APMC0D25", XGENE_ENET2},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
+#endif
+
+static const struct of_device_id xgene_enet_of_match[] = {
+   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
+   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
+   {},
+};
+
+MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
+
 static int xgene_enet_probe(struct platform_device *pdev)
 {
struct net_device *ndev;
@@ -1826,32 +1850,6 @@ static void xgene_enet_shutdown(struct p
xgene_enet_remove(pdev);
 }
 
-#ifdef CONFIG_ACPI
-static const struct acpi_device_id xgene_enet_acpi_match[] = {
-   { "APMC0D05", XGENE_ENET1},
-   { "APMC0D30", XGENE_ENET1},
-   { "APMC0D31", XGENE_ENET1},
-   { "APMC0D3F", XGENE_ENET1},
-   { "APMC0D26", XGENE_ENET2},
-   { "APMC0D25", XGENE_ENET2},
-   { }
-};
-MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
-#endif
-
-#ifdef CONFIG_OF
-static const struct of_device_id xgene_enet_of_match[] = {
-   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
-   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
-   {},
-};
-
-MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
-#endif
-
 static struct platform_driver xgene_enet_driver = {
.driver = {
   .name = "xgene-enet",
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -314,6 +314,30 @@ static acpi_status acpi_register_phy(acp
 }
 #endif
 
+static const struct of_device_id xgene_mdio_of_match[] = {
+   {
+   .compatible = "apm,xgene-mdio-rgmii",
+   .data = (void *)XGENE_MDIO_RGMII
+   },
+   {
+   .compatible = "apm,xgene-mdio-xfi",
+   .data = (void *)XGENE_MDIO_XFI
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, xgene_mdio_of_match);
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_mdio_acpi_match[] = {
+   { "APMC0D65", XGENE_MDIO_RGMII },
+   { "APMC0D66", XGENE_MDIO_XFI },
+   { }
+};
+
+MODULE_DEVICE_TABLE(acpi, xgene_mdio_acpi_match);
+#endif
+
+
 static int xgene_mdio_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -439,32 +463,6 @@ static int xgene_mdio_remove(struct plat
return 0;
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id 

[PATCH 4.9 023/102] usb: gadget: remove redundant self assignment

[Greg Kroah-Hartman]

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

--

From: Stefan Agner 

commit 8a8b161df5ce06ef5a315899f83978e765be09e8 upstream.

The assignment ret = ret is redundant and can be removed.

Reviewed-by: Krzysztof Opasiak 
Reviewed-by: Peter Chen 
Signed-off-by: Stefan Agner 
Signed-off-by: Felipe Balbi 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/udc/core.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
goto out;
 
ret = ep->ops->disable(ep);
-   if (ret) {
-   ret = ret;
+   if (ret)
goto out;
-   }
 
ep->enabled = false;
 

[PATCH 4.9 023/102] usb: gadget: remove redundant self assignment

[Greg Kroah-Hartman]

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

--

From: Stefan Agner 

commit 8a8b161df5ce06ef5a315899f83978e765be09e8 upstream.

The assignment ret = ret is redundant and can be removed.

Reviewed-by: Krzysztof Opasiak 
Reviewed-by: Peter Chen 
Signed-off-by: Stefan Agner 
Signed-off-by: Felipe Balbi 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/udc/core.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
goto out;
 
ret = ep->ops->disable(ep);
-   if (ret) {
-   ret = ret;
+   if (ret)
goto out;
-   }
 
ep->enabled = false;
 

[PATCH 4.9 025/102] nl80211: Fix enum type of variable in nl80211_put_sta_rate()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit bbf67e450a5dc2a595e1e7a67b4869f1a7f5a338 upstream.

rate_flg is of type 'enum nl80211_attrs', however it is assigned with
'enum nl80211_rate_info' values. Change the type of rate_flg accordingly.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Johannes Berg 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/wireless/nl80211.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4081,7 +4081,7 @@ static bool nl80211_put_sta_rate(struct
struct nlattr *rate;
u32 bitrate;
u16 bitrate_compat;
-   enum nl80211_attrs rate_flg;
+   enum nl80211_rate_info rate_flg;
 
rate = nla_nest_start(msg, attr);
if (!rate)

[PATCH 4.9 025/102] nl80211: Fix enum type of variable in nl80211_put_sta_rate()

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit bbf67e450a5dc2a595e1e7a67b4869f1a7f5a338 upstream.

rate_flg is of type 'enum nl80211_attrs', however it is assigned with
'enum nl80211_rate_info' values. Change the type of rate_flg accordingly.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Johannes Berg 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/wireless/nl80211.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4081,7 +4081,7 @@ static bool nl80211_put_sta_rate(struct
struct nlattr *rate;
u32 bitrate;
u16 bitrate_compat;
-   enum nl80211_attrs rate_flg;
+   enum nl80211_rate_info rate_flg;
 
rate = nla_nest_start(msg, attr);
if (!rate)

[PATCH 4.9 027/102] HID: sony: Use LED_CORE_SUSPENDRESUME

[Greg Kroah-Hartman]

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

--

From: Frank Praznik 

commit 765a1077c85e5f2efcc43582f80caf43a052e903 upstream.

The LED subsystem provides the LED_CORE_SUSPENDRESUME flag to handle
automatically turning off and restoring the state of device LEDs during
suspend/resume.  Use this flag instead of saving and restoring the state
locally.

Signed-off-by: Frank Praznik 
Signed-off-by: Jiri Kosina 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-sony.c |   45 +++--
 1 file changed, 15 insertions(+), 30 deletions(-)

--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1056,7 +1056,6 @@ struct sony_sc {
u8 battery_charging;
u8 battery_capacity;
u8 led_state[MAX_LEDS];
-   u8 resume_led_state[MAX_LEDS];
u8 led_delay_on[MAX_LEDS];
u8 led_delay_off[MAX_LEDS];
u8 led_count;
@@ -1793,6 +1792,7 @@ static int sony_leds_init(struct sony_sc
led->name = name;
led->brightness = sc->led_state[n];
led->max_brightness = max_brightness[n];
+   led->flags = LED_CORE_SUSPENDRESUME;
led->brightness_get = sony_led_get_brightness;
led->brightness_set = sony_led_set_brightness;
 
@@ -2509,47 +2509,32 @@ static void sony_remove(struct hid_devic
 
 static int sony_suspend(struct hid_device *hdev, pm_message_t message)
 {
-   /*
-* On suspend save the current LED state,
-* stop running force-feedback and blank the LEDS.
-*/
-   if (SONY_LED_SUPPORT || SONY_FF_SUPPORT) {
-   struct sony_sc *sc = hid_get_drvdata(hdev);
-
 #ifdef CONFIG_SONY_FF
-   sc->left = sc->right = 0;
-#endif
 
-   memcpy(sc->resume_led_state, sc->led_state,
-   sizeof(sc->resume_led_state));
-   memset(sc->led_state, 0, sizeof(sc->led_state));
+   /* On suspend stop any running force-feedback events */
+   if (SONY_FF_SUPPORT) {
+   struct sony_sc *sc = hid_get_drvdata(hdev);
 
+   sc->left = sc->right = 0;
sony_send_output_report(sc);
}
 
+#endif
return 0;
 }
 
 static int sony_resume(struct hid_device *hdev)
 {
-   /* Restore the state of controller LEDs on resume */
-   if (SONY_LED_SUPPORT) {
-   struct sony_sc *sc = hid_get_drvdata(hdev);
-
-   memcpy(sc->led_state, sc->resume_led_state,
-   sizeof(sc->led_state));
-
-   /*
-* The Sixaxis and navigation controllers on USB need to be
-* reinitialized on resume or they won't behave properly.
-*/
-   if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
-   (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
-   sixaxis_set_operational_usb(sc->hdev);
-   sc->defer_initialization = 1;
-   }
+   struct sony_sc *sc = hid_get_drvdata(hdev);
 
-   sony_set_leds(sc);
+   /*
+* The Sixaxis and navigation controllers on USB need to be
+* reinitialized on resume or they won't behave properly.
+*/
+   if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
+   (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
+   sixaxis_set_operational_usb(sc->hdev);
+   sc->defer_initialization = 1;
}
 
return 0;

[PATCH 4.9 027/102] HID: sony: Use LED_CORE_SUSPENDRESUME

[Greg Kroah-Hartman]

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

--

From: Frank Praznik 

commit 765a1077c85e5f2efcc43582f80caf43a052e903 upstream.

The LED subsystem provides the LED_CORE_SUSPENDRESUME flag to handle
automatically turning off and restoring the state of device LEDs during
suspend/resume.  Use this flag instead of saving and restoring the state
locally.

Signed-off-by: Frank Praznik 
Signed-off-by: Jiri Kosina 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-sony.c |   45 +++--
 1 file changed, 15 insertions(+), 30 deletions(-)

--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1056,7 +1056,6 @@ struct sony_sc {
u8 battery_charging;
u8 battery_capacity;
u8 led_state[MAX_LEDS];
-   u8 resume_led_state[MAX_LEDS];
u8 led_delay_on[MAX_LEDS];
u8 led_delay_off[MAX_LEDS];
u8 led_count;
@@ -1793,6 +1792,7 @@ static int sony_leds_init(struct sony_sc
led->name = name;
led->brightness = sc->led_state[n];
led->max_brightness = max_brightness[n];
+   led->flags = LED_CORE_SUSPENDRESUME;
led->brightness_get = sony_led_get_brightness;
led->brightness_set = sony_led_set_brightness;
 
@@ -2509,47 +2509,32 @@ static void sony_remove(struct hid_devic
 
 static int sony_suspend(struct hid_device *hdev, pm_message_t message)
 {
-   /*
-* On suspend save the current LED state,
-* stop running force-feedback and blank the LEDS.
-*/
-   if (SONY_LED_SUPPORT || SONY_FF_SUPPORT) {
-   struct sony_sc *sc = hid_get_drvdata(hdev);
-
 #ifdef CONFIG_SONY_FF
-   sc->left = sc->right = 0;
-#endif
 
-   memcpy(sc->resume_led_state, sc->led_state,
-   sizeof(sc->resume_led_state));
-   memset(sc->led_state, 0, sizeof(sc->led_state));
+   /* On suspend stop any running force-feedback events */
+   if (SONY_FF_SUPPORT) {
+   struct sony_sc *sc = hid_get_drvdata(hdev);
 
+   sc->left = sc->right = 0;
sony_send_output_report(sc);
}
 
+#endif
return 0;
 }
 
 static int sony_resume(struct hid_device *hdev)
 {
-   /* Restore the state of controller LEDs on resume */
-   if (SONY_LED_SUPPORT) {
-   struct sony_sc *sc = hid_get_drvdata(hdev);
-
-   memcpy(sc->led_state, sc->resume_led_state,
-   sizeof(sc->led_state));
-
-   /*
-* The Sixaxis and navigation controllers on USB need to be
-* reinitialized on resume or they won't behave properly.
-*/
-   if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
-   (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
-   sixaxis_set_operational_usb(sc->hdev);
-   sc->defer_initialization = 1;
-   }
+   struct sony_sc *sc = hid_get_drvdata(hdev);
 
-   sony_set_leds(sc);
+   /*
+* The Sixaxis and navigation controllers on USB need to be
+* reinitialized on resume or they won't behave properly.
+*/
+   if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
+   (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
+   sixaxis_set_operational_usb(sc->hdev);
+   sc->defer_initialization = 1;
}
 
return 0;

[PATCH 4.9 026/102] cfg80211: Fix array-bounds warning in fragment copy

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream.

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to
array[-1] to increment it later to valid values. clang rightfully
generates an array-bounds warning on the initialization statement.

Initialize the pointer to array[0] and change the algorithm from
increment before to increment after consume.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Johannes Berg 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/wireless/util.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -663,7 +663,7 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
int offset, int len)
 {
struct skb_shared_info *sh = skb_shinfo(skb);
-   const skb_frag_t *frag = >frags[-1];
+   const skb_frag_t *frag = >frags[0];
struct page *frag_page;
void *frag_ptr;
int frag_len, frag_size;
@@ -676,10 +676,10 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
 
while (offset >= frag_size) {
offset -= frag_size;
-   frag++;
frag_page = skb_frag_page(frag);
frag_ptr = skb_frag_address(frag);
frag_size = skb_frag_size(frag);
+   frag++;
}
 
frag_ptr += offset;
@@ -691,12 +691,12 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
len -= cur_len;
 
while (len > 0) {
-   frag++;
frag_len = skb_frag_size(frag);
cur_len = min(len, frag_len);
__frame_add_frag(frame, skb_frag_page(frag),
 skb_frag_address(frag), cur_len, frag_len);
len -= cur_len;
+   frag++;
}
 }
 

[PATCH 4.9 026/102] cfg80211: Fix array-bounds warning in fragment copy

[Greg Kroah-Hartman]

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

--

From: Matthias Kaehlcke 

commit aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream.

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to
array[-1] to increment it later to valid values. clang rightfully
generates an array-bounds warning on the initialization statement.

Initialize the pointer to array[0] and change the algorithm from
increment before to increment after consume.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Johannes Berg 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 

---
 net/wireless/util.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -663,7 +663,7 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
int offset, int len)
 {
struct skb_shared_info *sh = skb_shinfo(skb);
-   const skb_frag_t *frag = >frags[-1];
+   const skb_frag_t *frag = >frags[0];
struct page *frag_page;
void *frag_ptr;
int frag_len, frag_size;
@@ -676,10 +676,10 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
 
while (offset >= frag_size) {
offset -= frag_size;
-   frag++;
frag_page = skb_frag_page(frag);
frag_ptr = skb_frag_address(frag);
frag_size = skb_frag_size(frag);
+   frag++;
}
 
frag_ptr += offset;
@@ -691,12 +691,12 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
len -= cur_len;
 
while (len > 0) {
-   frag++;
frag_len = skb_frag_size(frag);
cur_len = min(len, frag_len);
__frame_add_frag(frame, skb_frag_page(frag),
 skb_frag_address(frag), cur_len, frag_len);
len -= cur_len;
+   frag++;
}
 }
 

Re: [PATCH net-next] netns: filter uevents correctly

[Eric W. Biederman]

Christian Brauner  writes:

> On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> Christian Brauner  writes:
>> 
>> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> >> On 05.04.2018 17:07, Christian Brauner wrote:
>> >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300, Kirill Tkhai wrote:
>> >> >> On 04.04.2018 22:48, Christian Brauner wrote:
>> >> >>> commit 07e98962fa77 ("kobject: Send hotplug events in all network 
>> >> >>> namespaces")
>> >> >>>
>> >> >>> enabled sending hotplug events into all network namespaces back in 
>> >> >>> 2010.
>> >> >>> Over time the set of uevents that get sent into all network 
>> >> >>> namespaces has
>> >> >>> shrunk. We have now reached the point where hotplug events for all 
>> >> >>> devices
>> >> >>> that carry a namespace tag are filtered according to that namespace.
>> >> >>>
>> >> >>> Specifically, they are filtered whenever the namespace tag of the 
>> >> >>> kobject
>> >> >>> does not match the namespace tag of the netlink socket. One example 
>> >> >>> are
>> >> >>> network devices. Uevents for network devices only show up in the 
>> >> >>> network
>> >> >>> namespaces these devices are moved to or created in.
>> >> >>>
>> >> >>> However, any uevent for a kobject that does not have a namespace tag
>> >> >>> associated with it will not be filtered and we will *try* to 
>> >> >>> broadcast it
>> >> >>> into all network namespaces.
>> >> >>>
>> >> >>> The original patchset was written in 2010 before user namespaces were 
>> >> >>> a
>> >> >>> thing. With the introduction of user namespaces sending out uevents 
>> >> >>> became
>> >> >>> partially isolated as they were filtered by user namespaces:
>> >> >>>
>> >> >>> net/netlink/af_netlink.c:do_one_broadcast()
>> >> >>>
>> >> >>> if (!net_eq(sock_net(sk), p->net)) {
>> >> >>> if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
>> >> >>> return;
>> >> >>>
>> >> >>> if (!peernet_has_id(sock_net(sk), p->net))
>> >> >>> return;
>> >> >>>
>> >> >>> if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
>> >> >>>  CAP_NET_BROADCAST))
>> >> >>> j   return;
>> >> >>> }
>> >> >>>
>> >> >>> The file_ns_capable() check will check whether the caller had
>> >> >>> CAP_NET_BROADCAST at the time of opening the netlink socket in the 
>> >> >>> user
>> >> >>> namespace of interest. This check is fine in general but seems 
>> >> >>> insufficient
>> >> >>> to me when paired with uevents. The reason is that devices always 
>> >> >>> belong to
>> >> >>> the initial user namespace so uevents for kobjects that do not carry a
>> >> >>> namespace tag should never be sent into another user namespace. This 
>> >> >>> has
>> >> >>> been the intention all along. But there's one case where this breaks,
>> >> >>> namely if a new user namespace is created by root on the host and an
>> >> >>> identity mapping is established between root on the host and root in 
>> >> >>> the
>> >> >>> new user namespace. Here's a reproducer:
>> >> >>>
>> >> >>>  sudo unshare -U --map-root
>> >> >>>  udevadm monitor -k
>> >> >>>  # Now change to initial user namespace and e.g. do
>> >> >>>  modprobe kvm
>> >> >>>  # or
>> >> >>>  rmmod kvm
>> >> >>>
>> >> >>> will allow the non-initial user namespace to retrieve all uevents 
>> >> >>> from the
>> >> >>> host. This seems very anecdotal given that in the general case user
>> >> >>> namespaces do not see any uevents and also can't really do anything 
>> >> >>> useful
>> >> >>> with them.
>> >> >>>
>> >> >>> Additionally, it is now possible to send uevents from userspace. As 
>> >> >>> such we
>> >> >>> can let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
>> >> >>> namespace of the network namespace of the netlink socket) userspace 
>> >> >>> process
>> >> >>> make a decision what uevents should be sent.
>> >> >>>
>> >> >>> This makes me think that we should simply ensure that uevents for 
>> >> >>> kobjects
>> >> >>> that do not carry a namespace tag are *always* filtered by user 
>> >> >>> namespace
>> >> >>> in kobj_bcast_filter(). Specifically:
>> >> >>> - If the owning user namespace of the uevent socket is not 
>> >> >>> init_user_ns the
>> >> >>>   event will always be filtered.
>> >> >>> - If the network namespace the uevent socket belongs to was created 
>> >> >>> in the
>> >> >>>   initial user namespace but was opened from a non-initial user 
>> >> >>> namespace
>> >> >>>   the event will be filtered as well.
>> >> >>> Put another way, uevents for kobjects not carrying a namespace tag 
>> >> >>> are now
>> >> >>> always only sent to the initial user namespace. The regression 
>> >> >>> potential
>> >> >>> for this is near to non-existent since user namespaces can't really do
>> >> >>> anything with interesting devices.
>> >> >>>
>> >> >>> Signed-off-by: Christian Brauner 
>> 

Re: [PATCH net-next] netns: filter uevents correctly

[Eric W. Biederman]

Christian Brauner  writes:

> On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> Christian Brauner  writes:
>> 
>> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> >> On 05.04.2018 17:07, Christian Brauner wrote:
>> >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300, Kirill Tkhai wrote:
>> >> >> On 04.04.2018 22:48, Christian Brauner wrote:
>> >> >>> commit 07e98962fa77 ("kobject: Send hotplug events in all network 
>> >> >>> namespaces")
>> >> >>>
>> >> >>> enabled sending hotplug events into all network namespaces back in 
>> >> >>> 2010.
>> >> >>> Over time the set of uevents that get sent into all network 
>> >> >>> namespaces has
>> >> >>> shrunk. We have now reached the point where hotplug events for all 
>> >> >>> devices
>> >> >>> that carry a namespace tag are filtered according to that namespace.
>> >> >>>
>> >> >>> Specifically, they are filtered whenever the namespace tag of the 
>> >> >>> kobject
>> >> >>> does not match the namespace tag of the netlink socket. One example 
>> >> >>> are
>> >> >>> network devices. Uevents for network devices only show up in the 
>> >> >>> network
>> >> >>> namespaces these devices are moved to or created in.
>> >> >>>
>> >> >>> However, any uevent for a kobject that does not have a namespace tag
>> >> >>> associated with it will not be filtered and we will *try* to 
>> >> >>> broadcast it
>> >> >>> into all network namespaces.
>> >> >>>
>> >> >>> The original patchset was written in 2010 before user namespaces were 
>> >> >>> a
>> >> >>> thing. With the introduction of user namespaces sending out uevents 
>> >> >>> became
>> >> >>> partially isolated as they were filtered by user namespaces:
>> >> >>>
>> >> >>> net/netlink/af_netlink.c:do_one_broadcast()
>> >> >>>
>> >> >>> if (!net_eq(sock_net(sk), p->net)) {
>> >> >>> if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
>> >> >>> return;
>> >> >>>
>> >> >>> if (!peernet_has_id(sock_net(sk), p->net))
>> >> >>> return;
>> >> >>>
>> >> >>> if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
>> >> >>>  CAP_NET_BROADCAST))
>> >> >>> j   return;
>> >> >>> }
>> >> >>>
>> >> >>> The file_ns_capable() check will check whether the caller had
>> >> >>> CAP_NET_BROADCAST at the time of opening the netlink socket in the 
>> >> >>> user
>> >> >>> namespace of interest. This check is fine in general but seems 
>> >> >>> insufficient
>> >> >>> to me when paired with uevents. The reason is that devices always 
>> >> >>> belong to
>> >> >>> the initial user namespace so uevents for kobjects that do not carry a
>> >> >>> namespace tag should never be sent into another user namespace. This 
>> >> >>> has
>> >> >>> been the intention all along. But there's one case where this breaks,
>> >> >>> namely if a new user namespace is created by root on the host and an
>> >> >>> identity mapping is established between root on the host and root in 
>> >> >>> the
>> >> >>> new user namespace. Here's a reproducer:
>> >> >>>
>> >> >>>  sudo unshare -U --map-root
>> >> >>>  udevadm monitor -k
>> >> >>>  # Now change to initial user namespace and e.g. do
>> >> >>>  modprobe kvm
>> >> >>>  # or
>> >> >>>  rmmod kvm
>> >> >>>
>> >> >>> will allow the non-initial user namespace to retrieve all uevents 
>> >> >>> from the
>> >> >>> host. This seems very anecdotal given that in the general case user
>> >> >>> namespaces do not see any uevents and also can't really do anything 
>> >> >>> useful
>> >> >>> with them.
>> >> >>>
>> >> >>> Additionally, it is now possible to send uevents from userspace. As 
>> >> >>> such we
>> >> >>> can let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
>> >> >>> namespace of the network namespace of the netlink socket) userspace 
>> >> >>> process
>> >> >>> make a decision what uevents should be sent.
>> >> >>>
>> >> >>> This makes me think that we should simply ensure that uevents for 
>> >> >>> kobjects
>> >> >>> that do not carry a namespace tag are *always* filtered by user 
>> >> >>> namespace
>> >> >>> in kobj_bcast_filter(). Specifically:
>> >> >>> - If the owning user namespace of the uevent socket is not 
>> >> >>> init_user_ns the
>> >> >>>   event will always be filtered.
>> >> >>> - If the network namespace the uevent socket belongs to was created 
>> >> >>> in the
>> >> >>>   initial user namespace but was opened from a non-initial user 
>> >> >>> namespace
>> >> >>>   the event will be filtered as well.
>> >> >>> Put another way, uevents for kobjects not carrying a namespace tag 
>> >> >>> are now
>> >> >>> always only sent to the initial user namespace. The regression 
>> >> >>> potential
>> >> >>> for this is near to non-existent since user namespaces can't really do
>> >> >>> anything with interesting devices.
>> >> >>>
>> >> >>> Signed-off-by: Christian Brauner 
>> >> >>> ---
>> >> >>>  lib/kobject_uevent.c | 10 +-
>> >> >>>  1 file changed, 9