[PATCH 5.1 194/371] net: usb: asix: init MAC address buffers

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 78226f6eaac80bf30256a33a4926c194ceefdf36 ]

This is for fixing bug KMSAN: uninit-value in ax88772_bind

Tested by
https://groups.google.com/d/msg/syzkaller-bugs/aFQurGotng4/eB_HlNhhCwAJ

Reported-by: syzbot+8a3fc6674bbc3978e...@syzkaller.appspotmail.com

syzbot found the following crash on:

HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
git tree:   kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=136d720ea0
kernel config:
https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a
dashboard link:
https://syzkaller.appspot.com/bug?extid=8a3fc6674bbc3978ed4e
compiler:   clang version 9.0.0 (/home/glider/llvm/clang
06d00afa61eef8f7f501ebdb4e8612ea43ec2d78)
syz repro:
https://syzkaller.appspot.com/x/repro.syz?x=12788316a0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=120359aaa0

==
BUG: KMSAN: uninit-value in is_valid_ether_addr
include/linux/etherdevice.h:200 [inline]
BUG: KMSAN: uninit-value in asix_set_netdev_dev_addr
drivers/net/usb/asix_devices.c:73 [inline]
BUG: KMSAN: uninit-value in ax88772_bind+0x93d/0x11e0
drivers/net/usb/asix_devices.c:724
CPU: 0 PID: 3348 Comm: kworker/0:2 Not tainted 5.1.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
  __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
  is_valid_ether_addr include/linux/etherdevice.h:200 [inline]
  asix_set_netdev_dev_addr drivers/net/usb/asix_devices.c:73 [inline]
  ax88772_bind+0x93d/0x11e0 drivers/net/usb/asix_devices.c:724
  usbnet_probe+0x10f5/0x3940 drivers/net/usb/usbnet.c:1728
  usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361
  really_probe+0xdae/0x1d80 drivers/base/dd.c:513
  driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
  __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
  bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
  __device_attach+0x454/0x730 drivers/base/dd.c:844
  device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
  bus_probe_device+0x137/0x390 drivers/base/bus.c:514
  device_add+0x288d/0x30e0 drivers/base/core.c:2106
  usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027
  generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210
  usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266
  really_probe+0xdae/0x1d80 drivers/base/dd.c:513
  driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
  __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
  bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
  __device_attach+0x454/0x730 drivers/base/dd.c:844
  device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
  bus_probe_device+0x137/0x390 drivers/base/bus.c:514
  device_add+0x288d/0x30e0 drivers/base/core.c:2106
  usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534
  hub_port_connect drivers/usb/core/hub.c:5089 [inline]
  hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
  port_event drivers/usb/core/hub.c:5350 [inline]
  hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432
  process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269
  process_scheduled_works kernel/workqueue.c:2331 [inline]
  worker_thread+0x189c/0x2460 kernel/workqueue.c:2417
  kthread+0x4b5/0x4f0 kernel/kthread.c:254
  ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355

Signed-off-by: Phong Tran 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/asix_devices.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 3d93993e74da..2eca4168af2f 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -238,7 +238,7 @@ static void asix_phy_reset(struct usbnet *dev, unsigned int 
reset_bits)
 static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf)
 {
int ret = 0;
-   u8 buf[ETH_ALEN];
+   u8 buf[ETH_ALEN] = {0};
int i;
unsigned long gpio_bits = dev->driver_info->data;
 
@@ -689,7 +689,7 @@ static int asix_resume(struct usb_interface *intf)
 static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
 {
int ret, i;
-   u8 buf[ETH_ALEN], chipcode = 0;
+   u8 buf[ETH_ALEN] = {0}, chipcode = 0;
u32 phyid;
struct asix_common_private *priv;
 
@@ -1073,7 +1073,7 @@ static const struct net_device_ops ax88178_netdev_ops = {
 static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf)
 {
int ret;
-   u8 buf[ETH_ALEN];
+   u8 buf[ETH_ALEN] = {0};
 
usbnet_get_endpoints(dev,intf);
 
-- 
2.20.1





Re: [PATCH] drivers: thermal: processor_thermal_device: Export sysfs inteface for TCC offset

2019-07-24 Thread Benjamin Berg
Tested-by: Benjamin Berg 

Hi,

this patch allows performance improvements of some machines. It would
be nice if this could still make 5.3.

Benjamin

On Mon, 2019-07-22 at 18:03 -0700, Srinivas Pandruvada wrote:
> This change exports an interface to read tcc offset and allow writing if
> the platform is not locked.
> 
> Refer to Intel SDM for details on the MSR: MSR_TEMPERATURE_TARGET.
> Here TCC Activation Offset (R/W) bits allow temperature offset in degrees
> in relation to TjMAX.
> 
> This change will be useful for improving performance from user space for
> some platforms, if the current offset is not optimal.
> 
> Signed-off-by: Srinivas Pandruvada 
> ---
>  .../processor_thermal_device.c| 91
> ++-
>  1 file changed, 87 insertions(+), 4 deletions(-)
> 
> diff --git
> a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> index 213ab3cc6b80..a35635129fed 100644
> ---
> a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> +++
> b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> @@ -137,6 +137,72 @@ static const struct attribute_group
> power_limit_attribute_group = {
>   .name = "power_limits"
>  };
>  
> +static ssize_t tcc_offset_degree_celsius_show(struct device *dev,
> +struct device_attribute *attr, char
> *buf)
> +{
> + u64 val;
> + int err;
> +
> + err = rdmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, &val);
> + if (err)
> + return err;
> +
> + val = (val >> 24) & 0xff;
> + return sprintf(buf, "%d\n", (int)val);
> +}
> +
> +static int tcc_offset_update(int tcc)
> +{
> + u64 val;
> + int err;
> +
> + if (!tcc)
> + return -EINVAL;
> +
> + err = rdmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, &val);
> + if (err)
> + return err;
> +
> + val = ~GENMASK_ULL(31, 24);
> + val = (tcc & 0xff) << 24;
> +
> + err = wrmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, val);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
> +static int tcc_offset_save;
> +
> +static ssize_t tcc_offset_degree_celsius_store(struct device *dev,
> + struct device_attribute *attr, const
> char *buf,
> + size_t count)
> +{
> + u64 val;
> + int tcc, err;
> +
> + err = rdmsrl_safe(MSR_PLATFORM_INFO, &val);
> + if (err)
> + return err;
> +
> + if (!(val & BIT(30)))
> + return -EACCES;
> +
> + if (kstrtoint(buf, 0, &tcc))
> + return -EINVAL;
> +
> + err = tcc_offset_update(tcc);
> + if (err)
> + return err;
> +
> + tcc_offset_save = tcc;
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR_RW(tcc_offset_degree_celsius);
> +
>  static int stored_tjmax; /* since it is fixed, we can have local
> storage */
>  
>  static int get_tjmax(void)
> @@ -332,6 +398,7 @@ static void proc_thermal_remove(struct
> proc_thermal_device *proc_priv)
>   acpi_remove_notify_handler(proc_priv->adev->handle,
>  ACPI_DEVICE_NOTIFY,
> proc_thermal_notify);
>   int340x_thermal_zone_remove(proc_priv->int340x_zone);
> + sysfs_remove_file(&proc_priv->dev->kobj,
> &dev_attr_tcc_offset_degree_celsius.attr);
>   sysfs_remove_group(&proc_priv->dev->kobj,
>  &power_limit_attribute_group);
>  }
> @@ -355,8 +422,15 @@ static int int3401_add(struct platform_device
> *pdev)
>  
>   dev_info(&pdev->dev, "Creating sysfs group for
> PROC_THERMAL_PLATFORM_DEV\n");
>  
> - return sysfs_create_group(&pdev->dev.kobj,
> -  &power_limit_attribute_group);
> + ret = sysfs_create_file(&pdev->dev.kobj,
> &dev_attr_tcc_offset_degree_celsius.attr);
> + if (ret)
> + return ret;
> +
> + ret = sysfs_create_group(&pdev->dev.kobj,
> &power_limit_attribute_group);
> + if (ret)
> + sysfs_remove_file(&pdev->dev.kobj,
> &dev_attr_tcc_offset_degree_celsius.attr);
> +
> + return ret;
>  }
>  
>  static int int3401_remove(struct platform_device *pdev)
> @@ -584,8 +658,15 @@ static int  proc_thermal_pci_probe(struct
> pci_dev *pdev,
>  
>   dev_info(&pdev->dev, "Creating sysfs group for
> PROC_THERMAL_PCI\n");
>  
> - return sysfs_create_group(&pdev->dev.kobj,
> -  &power_limit_attribute_group);
> + ret = sysfs_create_file(&pdev->dev.kobj,
> &dev_attr_tcc_offset_degree_celsius.attr);
> + if (ret)
> + return ret;
> +
> + ret = sysfs_create_group(&pdev->dev.kobj,
> &power_limit_attribute_group);
> + if (ret)
> + sysfs_remove_file(&pdev->dev.kobj,
> &dev_attr_tcc_offset_degree_celsius.attr);
> +
> + return ret;
>  }
>  
>  static void  proc_thermal_pci_remove(struct pci_dev *pdev)
> @@ -611,6 +692,8 @@ static int proc_thermal_resume(struct device
> 

[PATCH 5.1 196/371] libbpf: fix GCC8 warning for strncpy

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit cdfc7f888c2a355b01308e97c6df108f1c2b64e8 ]

GCC8 started emitting warning about using strncpy with number of bytes
exactly equal destination size, which is generally unsafe, as can lead
to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
of bytes to ensure name is always zero-terminated.

Signed-off-by: Andrii Nakryiko 
Cc: Magnus Karlsson 
Acked-by: Yonghong Song 
Acked-by: Magnus Karlsson 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/xsk.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index af5f310ecca1..1fe0e1eec738 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -336,7 +336,8 @@ static int xsk_get_max_queues(struct xsk_socket *xsk)
 
channels.cmd = ETHTOOL_GCHANNELS;
ifr.ifr_data = (void *)&channels;
-   strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ);
+   strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1);
+   ifr.ifr_name[IFNAMSIZ - 1] = '\0';
err = ioctl(fd, SIOCETHTOOL, &ifr);
if (err && errno != EOPNOTSUPP) {
ret = -errno;
-- 
2.20.1





[PATCH 5.1 198/371] selftests: bpf: fix inlines in test_lwt_seg6local

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 11aca65ec4db09527d3e9b6b41a0615b7da4386b ]

Selftests are reporting this failure in test_lwt_seg6local.sh:

+ ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj 
test_lwt_seg6local.o sec encap_srh dev veth2
Error fetching program/map!
Failed to parse eBPF program: Operation not permitted

The problem is __attribute__((always_inline)) alone is not enough to prevent
clang from inserting those functions in .text. In that case, .text is not
marked as relocateable.

See the output of objdump -h test_lwt_seg6local.o:

Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 3530      0040  2**3
  CONTENTS, ALLOC, LOAD, READONLY, CODE

This causes the iproute bpf loader to fail in bpf_fetch_prog_sec:
bpf_has_call_data returns true but bpf_fetch_prog_relo fails as there's no
relocateable .text section in the file.

To fix this, convert to 'static __always_inline'.

v2: Use 'static __always_inline' instead of 'static inline
__attribute__((always_inline))'

Fixes: c99a84eac026 ("selftests/bpf: test for seg6local End.BPF action")
Signed-off-by: Jiri Benc 
Acked-by: Yonghong Song 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 .../testing/selftests/bpf/progs/test_lwt_seg6local.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c 
b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
index 0575751bc1bc..e2f6ed0a583d 100644
--- a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
+++ b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
@@ -61,7 +61,7 @@ struct sr6_tlv_t {
unsigned char value[0];
 } BPF_PACKET_HEADER;
 
-__attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
+static __always_inline struct ip6_srh_t *get_srh(struct __sk_buff *skb)
 {
void *cursor, *data_end;
struct ip6_srh_t *srh;
@@ -95,7 +95,7 @@ __attribute__((always_inline)) struct ip6_srh_t 
*get_srh(struct __sk_buff *skb)
return srh;
 }
 
-__attribute__((always_inline))
+static __always_inline
 int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
   uint32_t old_pad, uint32_t pad_off)
 {
@@ -125,7 +125,7 @@ int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
return 0;
 }
 
-__attribute__((always_inline))
+static __always_inline
 int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
  uint32_t *tlv_off, uint32_t *pad_size,
  uint32_t *pad_off)
@@ -184,7 +184,7 @@ int is_valid_tlv_boundary(struct __sk_buff *skb, struct 
ip6_srh_t *srh,
return 0;
 }
 
-__attribute__((always_inline))
+static __always_inline
 int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
struct sr6_tlv_t *itlv, uint8_t tlv_size)
 {
@@ -228,7 +228,7 @@ int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, 
uint32_t tlv_off,
return update_tlv_pad(skb, new_pad, pad_size, pad_off);
 }
 
-__attribute__((always_inline))
+static __always_inline
 int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
   uint32_t tlv_off)
 {
@@ -266,7 +266,7 @@ int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
return update_tlv_pad(skb, new_pad, pad_size, pad_off);
 }
 
-__attribute__((always_inline))
+static __always_inline
 int has_egr_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh)
 {
int tlv_offset = sizeof(struct ip6_t) + sizeof(struct ip6_srh_t) +
-- 
2.20.1





[PATCH 5.1 200/371] gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 3285170f28a850638794cdfe712eb6d93e51e706 ]

Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed
the functions to use a "gpiod" prefix, and commit 79a9becda8940deb
("gpiolib: export descriptor-based GPIO interface") introduced the "raw"
variants, but both changes forgot to update the comments.

Readd a similar reference to gpiod_set_value(), which was accidentally
removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source
handling to gpiod_set_value_cansleep()").

Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+rene...@glider.be
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/gpio/gpiolib.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index fd1344056e1d..b8a5c1e3b99d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3012,7 +3012,7 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,
 int gpiod_get_raw_value(const struct gpio_desc *desc)
 {
VALIDATE_DESC(desc);
-   /* Should be using gpio_get_value_cansleep() */
+   /* Should be using gpiod_get_raw_value_cansleep() */
WARN_ON(desc->gdev->chip->can_sleep);
return gpiod_get_raw_value_commit(desc);
 }
@@ -3033,7 +3033,7 @@ int gpiod_get_value(const struct gpio_desc *desc)
int value;
 
VALIDATE_DESC(desc);
-   /* Should be using gpio_get_value_cansleep() */
+   /* Should be using gpiod_get_value_cansleep() */
WARN_ON(desc->gdev->chip->can_sleep);
 
value = gpiod_get_raw_value_commit(desc);
@@ -3304,7 +3304,7 @@ int gpiod_set_array_value_complex(bool raw, bool 
can_sleep,
 void gpiod_set_raw_value(struct gpio_desc *desc, int value)
 {
VALIDATE_DESC_VOID(desc);
-   /* Should be using gpiod_set_value_cansleep() */
+   /* Should be using gpiod_set_raw_value_cansleep() */
WARN_ON(desc->gdev->chip->can_sleep);
gpiod_set_raw_value_commit(desc, value);
 }
@@ -3345,6 +3345,7 @@ static void gpiod_set_value_nocheck(struct gpio_desc 
*desc, int value)
 void gpiod_set_value(struct gpio_desc *desc, int value)
 {
VALIDATE_DESC_VOID(desc);
+   /* Should be using gpiod_set_value_cansleep() */
WARN_ON(desc->gdev->chip->can_sleep);
gpiod_set_value_nocheck(desc, value);
 }
-- 
2.20.1





[PATCH 5.1 166/371] wil6210: drop old event after wmi_call timeout

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 1a276003111c0404f6bfeffe924c5a21f482428b ]

This change fixes a rare race condition of handling WMI events after
wmi_call expires.

wmi_recv_cmd immediately handles an event when reply_buf is defined and
a wmi_call is waiting for the event.
However, in case the wmi_call has already timed-out, there will be no
waiting/running wmi_call and the event will be queued in WMI queue and
will be handled later in wmi_event_handle.
Meanwhile, a new similar wmi_call for the same command and event may
be issued. In this case, when handling the queued event we got WARN_ON
printed.

Fixing this case as a valid timeout and drop the unexpected event.

Signed-off-by: Ahmad Masri 
Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/wmi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index 63116f4b62c7..de52e532c105 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -3211,7 +3211,18 @@ static void wmi_event_handle(struct wil6210_priv *wil,
/* check if someone waits for this event */
if (wil->reply_id && wil->reply_id == id &&
wil->reply_mid == mid) {
-   WARN_ON(wil->reply_buf);
+   if (wil->reply_buf) {
+   /* event received while wmi_call is waiting
+* with a buffer. Such event should be handled
+* in wmi_recv_cmd function. Handling the event
+* here means a previous wmi_call was timeout.
+* Drop the event and do not handle it.
+*/
+   wil_err(wil,
+   "Old event (%d, %s) while wmi_call is 
waiting. Drop it and Continue waiting\n",
+   id, eventid2name(id));
+   return;
+   }
 
wmi_evt_call_handler(vif, id, evt_data,
 len - sizeof(*wmi));
-- 
2.20.1





[PATCH 5.1 202/371] tools: bpftool: Fix json dump crash on powerpc

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit aa52bcbe0e72fac36b1862db08b9c09c4caefae3 ]

Michael reported crash with by bpf program in json mode on powerpc:

  # bpftool prog -p dump jited id 14
  [{
"name": "0xda9aa760",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
  Segmentation fault (core dumped)

The code is assuming char pointers in format, which is not always
true at least for powerpc. Fixing this by dumping the whole string
into buffer based on its format.

Please note that libopcodes code does not check return values from
fprintf callback, but as per Jakub suggestion returning -1 on allocation
failure so we do the best effort to propagate the error.

Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump 
jited *` command")
Reported-by: Michael Petlan 
Signed-off-by: Jiri Olsa 
Reviewed-by: Quentin Monnet 
Reviewed-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 tools/bpf/bpftool/jit_disasm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
index 3ef3093560ba..bfed711258ce 100644
--- a/tools/bpf/bpftool/jit_disasm.c
+++ b/tools/bpf/bpftool/jit_disasm.c
@@ -11,6 +11,8 @@
  * Licensed under the GNU General Public License, version 2.0 (GPLv2)
  */
 
+#define _GNU_SOURCE
+#include 
 #include 
 #include 
 #include 
@@ -44,11 +46,13 @@ static int fprintf_json(void *out, const char *fmt, ...)
char *s;
 
va_start(ap, fmt);
+   if (vasprintf(&s, fmt, ap) < 0)
+   return -1;
+   va_end(ap);
+
if (!oper_count) {
int i;
 
-   s = va_arg(ap, char *);
-
/* Strip trailing spaces */
i = strlen(s) - 1;
while (s[i] == ' ')
@@ -61,11 +65,10 @@ static int fprintf_json(void *out, const char *fmt, ...)
} else if (!strcmp(fmt, ",")) {
   /* Skip */
} else {
-   s = va_arg(ap, char *);
jsonw_string(json_wtr, s);
oper_count++;
}
-   va_end(ap);
+   free(s);
return 0;
 }
 
-- 
2.20.1





[PATCH 5.1 203/371] net: hns3: enable broadcast promisc mode when initializing VF

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 2d5066fc175ea77a733d84df9ef414b34f311641 ]

For revision 0x20, the broadcast promisc is enabled by firmware,
it's unnecessary to enable it when initializing VF.

For revision 0x21, it's necessary to enable broadcast promisc mode
when initializing or re-initializing VF, otherwise, it will be
unable to send and receive promisc packets.

Fixes: f01f5559cac8 ("net: hns3: don't allow vf to enable promisc mode")
Signed-off-by: Jian Shen 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 8dd7fef863f6..d7a15d5b6b61 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2425,6 +2425,12 @@ static int hclgevf_reset_hdev(struct hclgevf_dev *hdev)
return ret;
}
 
+   if (pdev->revision >= 0x21) {
+   ret = hclgevf_set_promisc_mode(hdev, true);
+   if (ret)
+   return ret;
+   }
+
dev_info(&hdev->pdev->dev, "Reset done\n");
 
return 0;
@@ -2504,9 +2510,11 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
 * firmware makes sure broadcast packets can be accepted.
 * For revision 0x21, default to enable broadcast promisc mode.
 */
-   ret = hclgevf_set_promisc_mode(hdev, true);
-   if (ret)
-   goto err_config;
+   if (pdev->revision >= 0x21) {
+   ret = hclgevf_set_promisc_mode(hdev, true);
+   if (ret)
+   goto err_config;
+   }
 
/* Initialize RSS for this VF */
ret = hclgevf_rss_init_hw(hdev);
-- 
2.20.1





[PATCH 5.1 167/371] EDAC: Fix global-out-of-bounds write when setting edac_mc_poll_msec

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit d8655e7630dafa88bc37f101640e39c736399771 ]

Commit 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2") assumes
edac_mc_poll_msec to be unsigned long, but the type of the variable still
remained as int. Setting edac_mc_poll_msec can trigger out-of-bounds
write.

Reproducer:

  # echo 1001 > /sys/module/edac_core/parameters/edac_mc_poll_msec

KASAN report:

  BUG: KASAN: global-out-of-bounds in edac_set_poll_msec+0x140/0x150
  Write of size 8 at addr b91b2d00 by task bash/1996

  CPU: 1 PID: 1996 Comm: bash Not tainted 5.2.0-rc6+ #23
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 
04/01/2014
  Call Trace:
   dump_stack+0xca/0x13e
   print_address_description.cold+0x5/0x246
   __kasan_report.cold+0x75/0x9a
   ? edac_set_poll_msec+0x140/0x150
   kasan_report+0xe/0x20
   edac_set_poll_msec+0x140/0x150
   ? dimmdev_location_show+0x30/0x30
   ? vfs_lock_file+0xe0/0xe0
   ? _raw_spin_lock+0x87/0xe0
   param_attr_store+0x1b5/0x310
   ? param_array_set+0x4f0/0x4f0
   module_attr_store+0x58/0x80
   ? module_attr_show+0x80/0x80
   sysfs_kf_write+0x13d/0x1a0
   kernfs_fop_write+0x2bc/0x460
   ? sysfs_kf_bin_read+0x270/0x270
   ? kernfs_notify+0x1f0/0x1f0
   __vfs_write+0x81/0x100
   vfs_write+0x1e1/0x560
   ksys_write+0x126/0x250
   ? __ia32_sys_read+0xb0/0xb0
   ? do_syscall_64+0x1f/0x390
   do_syscall_64+0xc1/0x390
   entry_SYSCALL_64_after_hwframe+0x49/0xbe
  RIP: 0033:0x7fa7caa5e970
  Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 
00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 04
  RSP: 002b:7fff6acfdfe8 EFLAGS: 0246 ORIG_RAX: 0001
  RAX: ffda RBX: 0005 RCX: 7fa7caa5e970
  RDX: 0005 RSI: 00e95c08 RDI: 0001
  RBP: 00e95c08 R08: 7fa7cad1e760 R09: 7fa7cb36a700
  R10: 0073 R11: 0246 R12: 0005
  R13: 0001 R14: 7fa7cad1d600 R15: 0005

  The buggy address belongs to the variable:
   edac_mc_poll_msec+0x0/0x40

  Memory state around the buggy address:
   b91b2c00: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
   b91b2c80: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
  >b91b2d00: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
 ^
   b91b2d80: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
   b91b2e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Fix it by changing the type of edac_mc_poll_msec to unsigned int.
The reason why this patch adopts unsigned int rather than unsigned long
is msecs_to_jiffies() assumes arg to be unsigned int. We can avoid
integer conversion bugs and unsigned int will be large enough for
edac_mc_poll_msec.

Reviewed-by: James Morse 
Fixes: 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2")
Signed-off-by: Eiichi Tsukata 
Signed-off-by: Tony Luck 
Signed-off-by: Sasha Levin 
---
 drivers/edac/edac_mc_sysfs.c | 16 
 drivers/edac/edac_module.h   |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 7c01e1cc030c..4386ea4b9b5a 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -26,7 +26,7 @@
 static int edac_mc_log_ue = 1;
 static int edac_mc_log_ce = 1;
 static int edac_mc_panic_on_ue;
-static int edac_mc_poll_msec = 1000;
+static unsigned int edac_mc_poll_msec = 1000;
 
 /* Getter functions for above */
 int edac_mc_get_log_ue(void)
@@ -45,30 +45,30 @@ int edac_mc_get_panic_on_ue(void)
 }
 
 /* this is temporary */
-int edac_mc_get_poll_msec(void)
+unsigned int edac_mc_get_poll_msec(void)
 {
return edac_mc_poll_msec;
 }
 
 static int edac_set_poll_msec(const char *val, const struct kernel_param *kp)
 {
-   unsigned long l;
+   unsigned int i;
int ret;
 
if (!val)
return -EINVAL;
 
-   ret = kstrtoul(val, 0, &l);
+   ret = kstrtouint(val, 0, &i);
if (ret)
return ret;
 
-   if (l < 1000)
+   if (i < 1000)
return -EINVAL;
 
-   *((unsigned long *)kp->arg) = l;
+   *((unsigned int *)kp->arg) = i;
 
/* notify edac_mc engine to reset the poll period */
-   edac_mc_reset_delay_period(l);
+   edac_mc_reset_delay_period(i);
 
return 0;
 }
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(edac_mc_log_ue,
 module_param(edac_mc_log_ce, int, 0644);
 MODULE_PARM_DESC(edac_mc_log_ce,
 "Log correctable error to console: 0=off 1=on");
-module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_int,
+module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_uint,
  &edac_mc_poll_msec, 0644);
 MODULE_PARM_DESC(edac_mc_poll_msec, "Polling period in milliseconds");
 
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index dd7d0b509aa3..75528f07abd5 100644
--- a/drivers/edac/edac_module.h
+++ b/

[PATCH 5.1 204/371] Bluetooth: hci_bcsp: Fix memory leak in rx_skb

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 4ce9146e0370fcd573f0372d9b4e5a22567c ]

Syzkaller found that it is possible to provoke a memory leak by
never freeing rx_skb in struct bcsp_struct.

Fix by freeing in bcsp_close()

Signed-off-by: Tomas Bortoli 
Reported-by: syzbot+98162c885993b72f1...@syzkaller.appspotmail.com
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/hci_bcsp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index 1a7f0c82fb36..66fe1e6dc631 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -759,6 +759,11 @@ static int bcsp_close(struct hci_uart *hu)
skb_queue_purge(&bcsp->rel);
skb_queue_purge(&bcsp->unrel);
 
+   if (bcsp->rx_skb) {
+   kfree_skb(bcsp->rx_skb);
+   bcsp->rx_skb = NULL;
+   }
+
kfree(bcsp);
return 0;
 }
-- 
2.20.1





[PATCH 5.1 199/371] bonding: validate ip header before check IPPROTO_IGMP

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 9d1bc24b52fb8c5d859f9a47084bf1179470e04c ]

bond_xmit_roundrobin() checks for IGMP packets but it parses
the IP header even before checking skb->protocol.

We should validate the IP header with pskb_may_pull() before
using iph->protocol.

Reported-and-tested-by: syzbot+e5be16aa39ad6e755...@syzkaller.appspotmail.com
Fixes: a2fd940f4cff ("bonding: fix broken multicast with round-robin mode")
Cc: Jay Vosburgh 
Cc: Veaceslav Falico 
Cc: Andy Gospodarek 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/bonding/bond_main.c | 37 -
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 59e919b92873..7b9a18e36a93 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3866,8 +3866,8 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff 
*skb,
struct net_device *bond_dev)
 {
struct bonding *bond = netdev_priv(bond_dev);
-   struct iphdr *iph = ip_hdr(skb);
struct slave *slave;
+   int slave_cnt;
u32 slave_id;
 
/* Start with the curr_active_slave that joined the bond as the
@@ -3876,23 +3876,32 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff 
*skb,
 * send the join/membership reports.  The curr_active_slave found
 * will send all of this type of traffic.
 */
-   if (iph->protocol == IPPROTO_IGMP && skb->protocol == htons(ETH_P_IP)) {
-   slave = rcu_dereference(bond->curr_active_slave);
-   if (slave)
-   bond_dev_queue_xmit(bond, skb, slave->dev);
-   else
-   bond_xmit_slave_id(bond, skb, 0);
-   } else {
-   int slave_cnt = READ_ONCE(bond->slave_cnt);
+   if (skb->protocol == htons(ETH_P_IP)) {
+   int noff = skb_network_offset(skb);
+   struct iphdr *iph;
 
-   if (likely(slave_cnt)) {
-   slave_id = bond_rr_gen_slave_id(bond);
-   bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
-   } else {
-   bond_tx_drop(bond_dev, skb);
+   if (unlikely(!pskb_may_pull(skb, noff + sizeof(*iph
+   goto non_igmp;
+
+   iph = ip_hdr(skb);
+   if (iph->protocol == IPPROTO_IGMP) {
+   slave = rcu_dereference(bond->curr_active_slave);
+   if (slave)
+   bond_dev_queue_xmit(bond, skb, slave->dev);
+   else
+   bond_xmit_slave_id(bond, skb, 0);
+   return NETDEV_TX_OK;
}
}
 
+non_igmp:
+   slave_cnt = READ_ONCE(bond->slave_cnt);
+   if (likely(slave_cnt)) {
+   slave_id = bond_rr_gen_slave_id(bond);
+   bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
+   } else {
+   bond_tx_drop(bond_dev, skb);
+   }
return NETDEV_TX_OK;
 }
 
-- 
2.20.1





[PATCH 5.1 201/371] ASoC: audio-graph-card: fix use-after-free in graph_for_each_link

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 1bcc1fd64e4dd903f4d868a9e053986e3b102713 ]

After calling of_node_put() on the codec_ep and codec_port variables,
they are still being used, which may result in use-after-free.
We fix this issue by calling of_node_put() after the last usage.

Fixes: fce9b90c1ab7 ("ASoC: audio-graph-card: cleanup DAI link loop method - 
step2")
Signed-off-by: Wen Yang 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Kuninori Morimoto 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Link: 
https://lore.kernel.org/r/1562229530-8121-1-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/generic/audio-graph-card.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/generic/audio-graph-card.c 
b/sound/soc/generic/audio-graph-card.c
index 69bc4848d787..f730830fb36c 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -460,9 +460,6 @@ static int graph_for_each_link(struct graph_priv *priv,
codec_ep = of_graph_get_remote_endpoint(cpu_ep);
codec_port = of_get_parent(codec_ep);
 
-   of_node_put(codec_ep);
-   of_node_put(codec_port);
-
/* get convert-xxx property */
memset(&adata, 0, sizeof(adata));
graph_get_conversion(dev, codec_ep, &adata);
@@ -482,6 +479,9 @@ static int graph_for_each_link(struct graph_priv *priv,
else
ret = func_noml(priv, cpu_ep, codec_ep, li);
 
+   of_node_put(codec_ep);
+   of_node_put(codec_port);
+
if (ret < 0)
return ret;
 
-- 
2.20.1





[PATCH 5.1 168/371] bcache: check CACHE_SET_IO_DISABLE in allocator code

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit e775339e1ae1205b47d94881db124c11385e597c ]

If CACHE_SET_IO_DISABLE of a cache set flag is set by too many I/O
errors, currently allocator routines can still continue allocate
space which may introduce inconsistent metadata state.

This patch checkes CACHE_SET_IO_DISABLE bit in following allocator
routines,
- bch_bucket_alloc()
- __bch_bucket_alloc_set()
Once CACHE_SET_IO_DISABLE is set on cache set, the allocator routines
may reject allocation request earlier to avoid potential inconsistent
metadata.

Signed-off-by: Coly Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/alloc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/md/bcache/alloc.c b/drivers/md/bcache/alloc.c
index f8986effcb50..6f776823b9ba 100644
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -393,6 +393,11 @@ long bch_bucket_alloc(struct cache *ca, unsigned int 
reserve, bool wait)
struct bucket *b;
long r;
 
+
+   /* No allocation if CACHE_SET_IO_DISABLE bit is set */
+   if (unlikely(test_bit(CACHE_SET_IO_DISABLE, &ca->set->flags)))
+   return -1;
+
/* fastpath */
if (fifo_pop(&ca->free[RESERVE_NONE], r) ||
fifo_pop(&ca->free[reserve], r))
@@ -484,6 +489,10 @@ int __bch_bucket_alloc_set(struct cache_set *c, unsigned 
int reserve,
 {
int i;
 
+   /* No allocation if CACHE_SET_IO_DISABLE bit is set */
+   if (unlikely(test_bit(CACHE_SET_IO_DISABLE, &c->flags)))
+   return -1;
+
lockdep_assert_held(&c->bucket_lock);
BUG_ON(!n || n > c->caches_loaded || n > MAX_CACHES_PER_SET);
 
-- 
2.20.1





[PATCH 5.1 205/371] Bluetooth: Add new 13d3:3491 QCA_ROME device

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 44d34af2e4cfd0c5357182f8b43f3e0a1fe30a2e ]

Without the QCA ROME setup routine this adapter fails to establish a SCO
connection.

T:  Bus=01 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3491 Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: João Paulo Rechi Vita 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7db48ae65cd2..0e2c86da6479 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -279,6 +279,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x3015), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x04ca, 0x3016), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x04ca, 0x301a), .driver_info = BTUSB_QCA_ROME },
+   { USB_DEVICE(0x13d3, 0x3491), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3496), .driver_info = BTUSB_QCA_ROME },
 
/* Broadcom BCM2035 */
-- 
2.20.1





[PATCH 5.1 226/371] floppy: fix invalid pointer dereference in drive_name

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 9b04609b784027968348796a18f601aed9db3789 ]

This fixes the invalid pointer dereference in the drive_name function of
the floppy driver.

The native_format field of the struct floppy_drive_params is used as
floppy_type array index in the drive_name function.  Thus, the field
should be checked the same way as the autodetect field.

To trigger the bug, one could use a value out of range and set the drive
parameters with the FDSETDRVPRM ioctl.  Next, FDGETDRVTYP ioctl should
be used to call the drive_name.  A floppy disk is not required to be
inserted.

CAP_SYS_ADMIN is required to call FDSETDRVPRM.

The patch adds the check for a value of the native_format field to be in
the '0 <= x < ARRAY_SIZE(floppy_type)' range of the floppy_type array
indices.

The bug was found by syzkaller.

Signed-off-by: Denis Efremov 
Tested-by: Willy Tarreau 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 drivers/block/floppy.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 77c527db5134..8b443ee1d005 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3379,7 +3379,8 @@ static int fd_getgeo(struct block_device *bdev, struct 
hd_geometry *geo)
return 0;
 }
 
-static bool valid_floppy_drive_params(const short autodetect[8])
+static bool valid_floppy_drive_params(const short autodetect[8],
+   int native_format)
 {
size_t floppy_type_size = ARRAY_SIZE(floppy_type);
size_t i = 0;
@@ -3390,6 +3391,9 @@ static bool valid_floppy_drive_params(const short 
autodetect[8])
return false;
}
 
+   if (native_format < 0 || native_format >= floppy_type_size)
+   return false;
+
return true;
 }
 
@@ -3519,7 +3523,8 @@ static int fd_locked_ioctl(struct block_device *bdev, 
fmode_t mode, unsigned int
SUPBOUND(size, strlen((const char *)outparam) + 1);
break;
case FDSETDRVPRM:
-   if (!valid_floppy_drive_params(inparam.dp.autodetect))
+   if (!valid_floppy_drive_params(inparam.dp.autodetect,
+   inparam.dp.native_format))
return -EINVAL;
*UDP = inparam.dp;
break;
@@ -3718,7 +3723,7 @@ static int compat_setdrvprm(int drive,
return -EPERM;
if (copy_from_user(&v, arg, sizeof(struct compat_floppy_drive_params)))
return -EFAULT;
-   if (!valid_floppy_drive_params(v.autodetect))
+   if (!valid_floppy_drive_params(v.autodetect, v.native_format))
return -EINVAL;
mutex_lock(&floppy_mutex);
UDP->cmos = v.cmos;
-- 
2.20.1





[PATCH 5.1 208/371] genirq: Update irq stats from NMI handlers

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit c09cb1293523dd786ae54a12fd88001542cba2f6 ]

The NMI handlers handle_percpu_devid_fasteoi_nmi() and handle_fasteoi_nmi()
do not update the interrupt counts. Due to that the NMI interrupt count
does not show up correctly in /proc/interrupts.

Add the statistics and treat the NMI handlers in the same way as per cpu
interrupts and prevent them from updating irq_desc::tot_count as this might
be corrupted due to concurrency.

[ tglx: Massaged changelog ]

Fixes: 2dcf1fbcad35 ("genirq: Provide NMI handlers")
Signed-off-by: Shijith Thotton 
Signed-off-by: Thomas Gleixner 
Link: 
https://lkml.kernel.org/r/1562313336-11888-1-git-send-email-sthot...@marvell.com
Signed-off-by: Sasha Levin 
---
 kernel/irq/chip.c| 4 
 kernel/irq/irqdesc.c | 8 +++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 04fe4f989bd8..bfac4d6761b3 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -754,6 +754,8 @@ void handle_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
 
+   __kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
/*
 * NMIs cannot be shared, there is only one action.
@@ -968,6 +970,8 @@ void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
 
+   __kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
trace_irq_handler_exit(irq, action, res);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 9f8a709337cf..8a93df71673d 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -945,6 +945,11 @@ unsigned int kstat_irqs_cpu(unsigned int irq, int cpu)
*per_cpu_ptr(desc->kstat_irqs, cpu) : 0;
 }
 
+static bool irq_is_nmi(struct irq_desc *desc)
+{
+   return desc->istate & IRQS_NMI;
+}
+
 /**
  * kstat_irqs - Get the statistics for an interrupt
  * @irq:   The interrupt number
@@ -962,7 +967,8 @@ unsigned int kstat_irqs(unsigned int irq)
if (!desc || !desc->kstat_irqs)
return 0;
if (!irq_settings_is_per_cpu_devid(desc) &&
-   !irq_settings_is_per_cpu(desc))
+   !irq_settings_is_per_cpu(desc) &&
+   !irq_is_nmi(desc))
return desc->tot_count;
 
for_each_possible_cpu(cpu)
-- 
2.20.1





[PATCH 5.1 171/371] bcache: check c->gc_thread by IS_ERR_OR_NULL in cache_set_flush()

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit b387e9b58679c60f5b1e4313939bd4878204fc37 ]

When system memory is in heavy pressure, bch_gc_thread_start() from
run_cache_set() may fail due to out of memory. In such condition,
c->gc_thread is assigned to -ENOMEM, not NULL pointer. Then in following
failure code path bch_cache_set_error(), when cache_set_flush() gets
called, the code piece to stop c->gc_thread is broken,
 if (!IS_ERR_OR_NULL(c->gc_thread))
 kthread_stop(c->gc_thread);

And KASAN catches such NULL pointer deference problem, with the warning
information:

[  561.207881] 
==
[  561.207900] BUG: KASAN: null-ptr-deref in kthread_stop+0x3b/0x440
[  561.207904] Write of size 4 at addr 001c by task kworker/15:1/313

[  561.207913] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: GW 
5.0.0-vanilla+ #3
[  561.207916] Hardware name: Lenovo ThinkSystem SR650 
-[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019
[  561.207935] Workqueue: events cache_set_flush [bcache]
[  561.207940] Call Trace:
[  561.207948]  dump_stack+0x9a/0xeb
[  561.207955]  ? kthread_stop+0x3b/0x440
[  561.207960]  ? kthread_stop+0x3b/0x440
[  561.207965]  kasan_report+0x176/0x192
[  561.207973]  ? kthread_stop+0x3b/0x440
[  561.207981]  kthread_stop+0x3b/0x440
[  561.207995]  cache_set_flush+0xd4/0x6d0 [bcache]
[  561.208008]  process_one_work+0x856/0x1620
[  561.208015]  ? find_held_lock+0x39/0x1d0
[  561.208028]  ? drain_workqueue+0x380/0x380
[  561.208048]  worker_thread+0x87/0xb80
[  561.208058]  ? __kthread_parkme+0xb6/0x180
[  561.208067]  ? process_one_work+0x1620/0x1620
[  561.208072]  kthread+0x326/0x3e0
[  561.208079]  ? kthread_create_worker_on_cpu+0xc0/0xc0
[  561.208090]  ret_from_fork+0x3a/0x50
[  561.208110] 
==
[  561.208113] Disabling lock debugging due to kernel taint
[  561.208115] irq event stamp: 11800231
[  561.208126] hardirqs last  enabled at (11800231): [] 
do_syscall_64+0x18/0x410
[  561.208127] BUG: unable to handle kernel NULL pointer dereference at 
001c
[  561.208129] #PF error: [WRITE]
[  561.312253] hardirqs last disabled at (11800230): [] 
trace_hardirqs_off_thunk+0x1a/0x1c
[  561.312259] softirqs last  enabled at (11799832): [] 
__do_softirq+0x5c7/0x8c3
[  561.405975] PGD 0 P4D 0
[  561.442494] softirqs last disabled at (11799821): [] 
irq_exit+0x1ac/0x1e0
[  561.791359] Oops: 0002 [#1] SMP KASAN NOPTI
[  561.791362] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: GB   W 
5.0.0-vanilla+ #3
[  561.791363] Hardware name: Lenovo ThinkSystem SR650 
-[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019
[  561.791371] Workqueue: events cache_set_flush [bcache]
[  561.791374] RIP: 0010:kthread_stop+0x3b/0x440
[  561.791376] Code: 00 00 65 8b 05 26 d5 e0 7c 89 c0 48 0f a3 05 ec aa df 02 
0f 82 dc 02 00 00 4c 8d 63 20 be 04 00 00 00 4c 89 e7 e8 65 c5 53 00  ff 43 
20 48 8d 7b 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48
[  561.791377] RSP: 0018:88872fc8fd10 EFLAGS: 00010286
[  561.838895] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838916] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838934] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838948] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838966] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838979] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  561.838996] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  563.067028] RAX:  RBX: fffc RCX: 832dd314
[  563.067030] RDX:  RSI: 0004 RDI: 0297
[  563.067032] RBP: 88872fc8fe88 R08: fbfff0b8213d R09: fbfff0b8213d
[  563.067034] R10: 0001 R11: fbfff0b8213c R12: 001c
[  563.408618] R13: 88dc61cc0f68 R14: 888102b94900 R15: 88dc61cc0f68
[  563.408620] FS:  () GS:888f7dc0() 
knlGS:
[  563.408622] CS:  0010 DS:  ES:  CR0: 80050033
[  563.408623] CR2: 001c CR3: 000f48a1a004 CR4: 007606e0
[  563.408625] DR0:  DR1:  DR2: 
[  563.408627] DR3:  DR6: fffe0ff0 DR7: 0400
[  563.904795] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  563.915796] PKRU: 5554
[  563.915797] Call Trace:
[  563.915807]  cache_set_flush+0xd4/0x6d0 [bcache]
[  563.915812]  process_one_work+0x856/0x1620
[  564.001226] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
[  564.033563]  ? find_held_lock+0x39/0x1d0
[  564.033567]  ? drain_workqueue+0x380/0x380
[  564.033574]  worker_thread+0x87/0xb80
[  564.062823] bcache: bch_count_io_errors() nvme0n1: IO e

[PATCH 5.1 218/371] xdp: fix race on generic receive path

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit bf0bdd1343efbbf65b4d53aef1fce14acbd79d50 ]

Unlike driver mode, generic xdp receive could be triggered
by different threads on different CPU cores at the same time
leading to the fill and rx queue breakage. For example, this
could happen while sending packets from two processes to the
first interface of veth pair while the second part of it is
open with AF_XDP socket.

Need to take a lock for each generic receive to avoid race.

Fixes: c497176cb2e4 ("xsk: add Rx receive functions and poll support")
Signed-off-by: Ilya Maximets 
Acked-by: Magnus Karlsson 
Tested-by: William Tu 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 include/net/xdp_sock.h |  2 ++
 net/xdp/xsk.c  | 31 ++-
 2 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index d074b6d60f8a..ac3c047d058c 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -67,6 +67,8 @@ struct xdp_sock {
 * in the SKB destructor callback.
 */
spinlock_t tx_completion_lock;
+   /* Protects generic receive. */
+   spinlock_t rx_lock;
u64 rx_dropped;
 };
 
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index a14e8864e4fa..5e0637db92ea 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -123,13 +123,17 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff 
*xdp)
u64 addr;
int err;
 
-   if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
-   return -EINVAL;
+   spin_lock_bh(&xs->rx_lock);
+
+   if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index) {
+   err = -EINVAL;
+   goto out_unlock;
+   }
 
if (!xskq_peek_addr(xs->umem->fq, &addr) ||
len > xs->umem->chunk_size_nohr - XDP_PACKET_HEADROOM) {
-   xs->rx_dropped++;
-   return -ENOSPC;
+   err = -ENOSPC;
+   goto out_drop;
}
 
addr += xs->umem->headroom;
@@ -138,13 +142,21 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff 
*xdp)
memcpy(buffer, xdp->data_meta, len + metalen);
addr += metalen;
err = xskq_produce_batch_desc(xs->rx, addr, len);
-   if (!err) {
-   xskq_discard_addr(xs->umem->fq);
-   xsk_flush(xs);
-   return 0;
-   }
+   if (err)
+   goto out_drop;
+
+   xskq_discard_addr(xs->umem->fq);
+   xskq_produce_flush_desc(xs->rx);
 
+   spin_unlock_bh(&xs->rx_lock);
+
+   xs->sk.sk_data_ready(&xs->sk);
+   return 0;
+
+out_drop:
xs->rx_dropped++;
+out_unlock:
+   spin_unlock_bh(&xs->rx_lock);
return err;
 }
 
@@ -765,6 +777,7 @@ static int xsk_create(struct net *net, struct socket *sock, 
int protocol,
 
xs = xdp_sk(sk);
mutex_init(&xs->mutex);
+   spin_lock_init(&xs->rx_lock);
spin_lock_init(&xs->tx_completion_lock);
 
mutex_lock(&net->xdp.lock);
-- 
2.20.1





[PATCH 5.1 220/371] net: hns3: fix __QUEUE_STATE_STACK_XOFF not cleared issue

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit f96315f2f17e7b2580d2fec7c4d6a706a131d904 ]

When change MTU or other operations, which just calling .reset_notify
to do HNAE3_DOWN_CLIENT and HNAE3_UP_CLIENT, then
the netdev_tx_reset_queue() in the hns3_clear_all_ring() will be
ignored. So the dev_watchdog() may misdiagnose a TX timeout.

This patch separates netdev_tx_reset_queue() from
hns3_clear_all_ring(), and unifies hns3_clear_all_ring() and
hns3_force_clear_all_ring into one, since they are doing
similar things.

Fixes: 3a30964a2eef ("net: hns3: delay ring buffer clearing during reset")
Signed-off-by: Huazhong Tan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 .../net/ethernet/hisilicon/hns3/hns3_enet.c   | 54 +--
 1 file changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 7e7c10513d2c..ecf6ad5bdc2d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -27,8 +27,7 @@
 #define hns3_set_field(origin, shift, val) ((origin) |= ((val) << (shift)))
 #define hns3_tx_bd_count(S)DIV_ROUND_UP(S, HNS3_MAX_BD_SIZE)
 
-static void hns3_clear_all_ring(struct hnae3_handle *h);
-static void hns3_force_clear_all_ring(struct hnae3_handle *h);
+static void hns3_clear_all_ring(struct hnae3_handle *h, bool force);
 static void hns3_remove_hw_addr(struct net_device *netdev);
 
 static const char hns3_driver_name[] = "hns3";
@@ -459,6 +458,20 @@ static int hns3_nic_net_open(struct net_device *netdev)
return 0;
 }
 
+static void hns3_reset_tx_queue(struct hnae3_handle *h)
+{
+   struct net_device *ndev = h->kinfo.netdev;
+   struct hns3_nic_priv *priv = netdev_priv(ndev);
+   struct netdev_queue *dev_queue;
+   u32 i;
+
+   for (i = 0; i < h->kinfo.num_tqps; i++) {
+   dev_queue = netdev_get_tx_queue(ndev,
+   priv->ring_data[i].queue_index);
+   netdev_tx_reset_queue(dev_queue);
+   }
+}
+
 static void hns3_nic_net_down(struct net_device *netdev)
 {
struct hns3_nic_priv *priv = netdev_priv(netdev);
@@ -489,7 +502,9 @@ static void hns3_nic_net_down(struct net_device *netdev)
 * to disable the ring through firmware when downing the netdev.
 */
if (!hns3_nic_resetting(netdev))
-   hns3_clear_all_ring(priv->ae_handle);
+   hns3_clear_all_ring(priv->ae_handle, false);
+
+   hns3_reset_tx_queue(priv->ae_handle);
 }
 
 static int hns3_nic_net_stop(struct net_device *netdev)
@@ -3742,7 +3757,7 @@ static void hns3_client_uninit(struct hnae3_handle 
*handle, bool reset)
 
hns3_del_all_fd_rules(netdev, true);
 
-   hns3_force_clear_all_ring(handle);
+   hns3_clear_all_ring(handle, true);
 
hns3_uninit_phy(netdev);
 
@@ -3914,43 +3929,26 @@ static void hns3_force_clear_rx_ring(struct 
hns3_enet_ring *ring)
}
 }
 
-static void hns3_force_clear_all_ring(struct hnae3_handle *h)
-{
-   struct net_device *ndev = h->kinfo.netdev;
-   struct hns3_nic_priv *priv = netdev_priv(ndev);
-   struct hns3_enet_ring *ring;
-   u32 i;
-
-   for (i = 0; i < h->kinfo.num_tqps; i++) {
-   ring = priv->ring_data[i].ring;
-   hns3_clear_tx_ring(ring);
-
-   ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
-   hns3_force_clear_rx_ring(ring);
-   }
-}
-
-static void hns3_clear_all_ring(struct hnae3_handle *h)
+static void hns3_clear_all_ring(struct hnae3_handle *h, bool force)
 {
struct net_device *ndev = h->kinfo.netdev;
struct hns3_nic_priv *priv = netdev_priv(ndev);
u32 i;
 
for (i = 0; i < h->kinfo.num_tqps; i++) {
-   struct netdev_queue *dev_queue;
struct hns3_enet_ring *ring;
 
ring = priv->ring_data[i].ring;
hns3_clear_tx_ring(ring);
-   dev_queue = netdev_get_tx_queue(ndev,
-   priv->ring_data[i].queue_index);
-   netdev_tx_reset_queue(dev_queue);
 
ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
/* Continue to clear other rings even if clearing some
 * rings failed.
 */
-   hns3_clear_rx_ring(ring);
+   if (force)
+   hns3_force_clear_rx_ring(ring);
+   else
+   hns3_clear_rx_ring(ring);
}
 }
 
@@ -4153,8 +4151,8 @@ static int hns3_reset_notify_uninit_enet(struct 
hnae3_handle *handle)
return 0;
}
 
-   hns3_clear_all_ring(handle);
-   hns3_force_clear_all_ring(handle);
+   hns3_clear_all_ring(handle, true);
+   hns3_reset_tx_queue(priv->ae_handle);
 
hns3_nic_uninit_vector_data(priv);
 
-- 
2.20.1





[PATCH 5.1 169/371] bcache: check CACHE_SET_IO_DISABLE bit in bch_journal()

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 383ff2183ad16a8842d1fbd9dd3e1cbd66813e64 ]

When too many I/O errors happen on cache set and CACHE_SET_IO_DISABLE
bit is set, bch_journal() may continue to work because the journaling
bkey might be still in write set yet. The caller of bch_journal() may
believe the journal still work but the truth is in-memory journal write
set won't be written into cache device any more. This behavior may
introduce potential inconsistent metadata status.

This patch checks CACHE_SET_IO_DISABLE bit at the head of bch_journal(),
if the bit is set, bch_journal() returns NULL immediately to notice
caller to know journal does not work.

Signed-off-by: Coly Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/journal.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c
index 6c94fa007796..ac3cec56ec19 100644
--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -810,6 +810,10 @@ atomic_t *bch_journal(struct cache_set *c,
struct journal_write *w;
atomic_t *ret;
 
+   /* No journaling if CACHE_SET_IO_DISABLE set already */
+   if (unlikely(test_bit(CACHE_SET_IO_DISABLE, &c->flags)))
+   return NULL;
+
if (!CACHE_SYNC(&c->sb))
return NULL;
 
-- 
2.20.1





[PATCH 5.1 223/371] libbpf: fix another GCC8 warning for strncpy

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 763ff0e7d9c72e7094b31e7fb84a859be9325635 ]

Similar issue was fixed in cdfc7f888c2a ("libbpf: fix GCC8 warning for
strncpy") already. This one was missed. Fixing now.

Cc: Magnus Karlsson 
Signed-off-by: Andrii Nakryiko 
Acked-by: Magnus Karlsson 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/xsk.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 1fe0e1eec738..4ecd33ff46ec 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -560,7 +560,8 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const 
char *ifname,
err = -errno;
goto out_socket;
}
-   strncpy(xsk->ifname, ifname, IFNAMSIZ);
+   strncpy(xsk->ifname, ifname, IFNAMSIZ - 1);
+   xsk->ifname[IFNAMSIZ - 1] = '\0';
 
err = xsk_set_xdp_socket_config(&xsk->config, usr_config);
if (err)
-- 
2.20.1





[PATCH 5.1 224/371] floppy: fix div-by-zero in setup_format_params

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit f3554aeb991214cbfafd17d55e2bfddb50282e32 ]

This fixes a divide by zero error in the setup_format_params function of
the floppy driver.

Two consecutive ioctls can trigger the bug: The first one should set the
drive geometry with such .sect and .rate values for the F_SECT_PER_TRACK
to become zero.  Next, the floppy format operation should be called.

A floppy disk is not required to be inserted.  An unprivileged user
could trigger the bug if the device is accessible.

The patch checks F_SECT_PER_TRACK for a non-zero value in the
set_geometry function.  The proper check should involve a reasonable
upper limit for the .sect and .rate fields, but it could change the
UAPI.

The patch also checks F_SECT_PER_TRACK in the setup_format_params, and
cancels the formatting operation in case of zero.

The bug was found by syzkaller.

Signed-off-by: Denis Efremov 
Tested-by: Willy Tarreau 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 drivers/block/floppy.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 95f608d1a098..e2f742e17683 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -2119,6 +2119,9 @@ static void setup_format_params(int track)
raw_cmd->kernel_data = floppy_track_buffer;
raw_cmd->length = 4 * F_SECT_PER_TRACK;
 
+   if (!F_SECT_PER_TRACK)
+   return;
+
/* allow for about 30ms for data transport per track */
head_shift = (F_SECT_PER_TRACK + 5) / 6;
 
@@ -3231,6 +3234,8 @@ static int set_geometry(unsigned int cmd, struct 
floppy_struct *g,
/* sanity checking for parameters. */
if (g->sect <= 0 ||
g->head <= 0 ||
+   /* check for zero in F_SECT_PER_TRACK */
+   (unsigned char)((g->sect << 2) >> FD_SIZECODE(g)) == 0 ||
g->track <= 0 || g->track > UDP->tracks >> STRETCH(g) ||
/* check if reserved bits are set */
(g->stretch & ~(FD_STRETCH | FD_SWAPSIDES | FD_SECTBASEMASK)) != 0)
-- 
2.20.1





[PATCH 5.1 170/371] bcache: acquire bch_register_lock later in cached_dev_free()

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 80265d8dfd77792e133793cef44a21323aac2908 ]

When enable lockdep engine, a lockdep warning can be observed when
reboot or shutdown system,

[ 3142.764557][T1] bcache: bcache_reboot() Stopping all devices:
[ 3142.776265][ T2649]
[ 3142.777159][ T2649] ==
[ 3142.780039][ T2649] WARNING: possible circular locking dependency detected
[ 3142.782869][ T2649] 5.2.0-rc4-lp151.20-default+ #1 Tainted: GW
[ 3142.785684][ T2649] --
[ 3142.788479][ T2649] kworker/3:67/2649 is trying to acquire lock:
[ 3142.790738][ T2649] aaf02291 
((wq_completion)bcache_writeback_wq){+.+.}, at: flush_workqueue+0x87/0x4c0
[ 3142.794678][ T2649]
[ 3142.794678][ T2649] but task is already holding lock:
[ 3142.797402][ T2649] 4fcf89c5 (&bch_register_lock){+.+.}, at: 
cached_dev_free+0x17/0x120 [bcache]
[ 3142.801462][ T2649]
[ 3142.801462][ T2649] which lock already depends on the new lock.
[ 3142.801462][ T2649]
[ 3142.805277][ T2649]
[ 3142.805277][ T2649] the existing dependency chain (in reverse order) is:
[ 3142.808902][ T2649]
[ 3142.808902][ T2649] -> #2 (&bch_register_lock){+.+.}:
[ 3142.812396][ T2649]__mutex_lock+0x7a/0x9d0
[ 3142.814184][ T2649]cached_dev_free+0x17/0x120 [bcache]
[ 3142.816415][ T2649]process_one_work+0x2a4/0x640
[ 3142.818413][ T2649]worker_thread+0x39/0x3f0
[ 3142.820276][ T2649]kthread+0x125/0x140
[ 3142.822061][ T2649]ret_from_fork+0x3a/0x50
[ 3142.823965][ T2649]
[ 3142.823965][ T2649] -> #1 ((work_completion)(&cl->work)#2){+.+.}:
[ 3142.827244][ T2649]process_one_work+0x277/0x640
[ 3142.829160][ T2649]worker_thread+0x39/0x3f0
[ 3142.830958][ T2649]kthread+0x125/0x140
[ 3142.832674][ T2649]ret_from_fork+0x3a/0x50
[ 3142.834915][ T2649]
[ 3142.834915][ T2649] -> #0 ((wq_completion)bcache_writeback_wq){+.+.}:
[ 3142.838121][ T2649]lock_acquire+0xb4/0x1c0
[ 3142.840025][ T2649]flush_workqueue+0xae/0x4c0
[ 3142.842035][ T2649]drain_workqueue+0xa9/0x180
[ 3142.844042][ T2649]destroy_workqueue+0x17/0x250
[ 3142.846142][ T2649]cached_dev_free+0x52/0x120 [bcache]
[ 3142.848530][ T2649]process_one_work+0x2a4/0x640
[ 3142.850663][ T2649]worker_thread+0x39/0x3f0
[ 3142.852464][ T2649]kthread+0x125/0x140
[ 3142.854106][ T2649]ret_from_fork+0x3a/0x50
[ 3142.855880][ T2649]
[ 3142.855880][ T2649] other info that might help us debug this:
[ 3142.855880][ T2649]
[ 3142.859663][ T2649] Chain exists of:
[ 3142.859663][ T2649]   (wq_completion)bcache_writeback_wq --> 
(work_completion)(&cl->work)#2 --> &bch_register_lock
[ 3142.859663][ T2649]
[ 3142.865424][ T2649]  Possible unsafe locking scenario:
[ 3142.865424][ T2649]
[ 3142.868022][ T2649]CPU0CPU1
[ 3142.869885][ T2649]
[ 3142.871751][ T2649]   lock(&bch_register_lock);
[ 3142.873379][ T2649]
lock((work_completion)(&cl->work)#2);
[ 3142.876399][ T2649]lock(&bch_register_lock);
[ 3142.879727][ T2649]   lock((wq_completion)bcache_writeback_wq);
[ 3142.882064][ T2649]
[ 3142.882064][ T2649]  *** DEADLOCK ***
[ 3142.882064][ T2649]
[ 3142.885060][ T2649] 3 locks held by kworker/3:67/2649:
[ 3142.887245][ T2649]  #0: e774cdd0 ((wq_completion)events){+.+.}, at: 
process_one_work+0x21e/0x640
[ 3142.890815][ T2649]  #1: f7df89da 
((work_completion)(&cl->work)#2){+.+.}, at: process_one_work+0x21e/0x640
[ 3142.894884][ T2649]  #2: 4fcf89c5 (&bch_register_lock){+.+.}, at: 
cached_dev_free+0x17/0x120 [bcache]
[ 3142.898797][ T2649]
[ 3142.898797][ T2649] stack backtrace:
[ 3142.900961][ T2649] CPU: 3 PID: 2649 Comm: kworker/3:67 Tainted: GW  
   5.2.0-rc4-lp151.20-default+ #1
[ 3142.904789][ T2649] Hardware name: VMware, Inc. VMware Virtual 
Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 3142.909168][ T2649] Workqueue: events cached_dev_free [bcache]
[ 3142.911422][ T2649] Call Trace:
[ 3142.912656][ T2649]  dump_stack+0x85/0xcb
[ 3142.914181][ T2649]  print_circular_bug+0x19a/0x1f0
[ 3142.916193][ T2649]  __lock_acquire+0x16cd/0x1850
[ 3142.917936][ T2649]  ? __lock_acquire+0x6a8/0x1850
[ 3142.919704][ T2649]  ? lock_acquire+0xb4/0x1c0
[ 3142.921335][ T2649]  ? find_held_lock+0x34/0xa0
[ 3142.923052][ T2649]  lock_acquire+0xb4/0x1c0
[ 3142.924635][ T2649]  ? flush_workqueue+0x87/0x4c0
[ 3142.926375][ T2649]  flush_workqueue+0xae/0x4c0
[ 3142.928047][ T2649]  ? flush_workqueue+0x87/0x4c0
[ 3142.929824][ T2649]  ? drain_workqueue+0xa9/0x180
[ 3142.931686][ T2649]  drain_workqueue+0xa9/0x180
[ 3142.933534][ T2649]  destroy_workqueue+0x17/0x250
[ 3142.935787][ T2649]  cached_dev_free+0x52/0x120 [bcache]
[ 3142.937795][ T2649]  process_one_work+0x2a4/0x640
[ 3142.939803][ T2649]  worker_thread+0x39/0x3f0
[ 314

[PATCH 5.1 217/371] gtp: fix use-after-free in gtp_newlink()

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ]

Current gtp_newlink() could be called after unregister_pernet_subsys().
gtp_newlink() uses gtp_net but it can be destroyed by
unregister_pernet_subsys().
So unregister_pernet_subsys() should be called after
rtnl_link_unregister().

Test commands:
   #SHELL 1
   while :
   do
   for i in {1..5}
   do
./gtp-link add gtp$i &
   done
   killall gtp-link
   done

   #SHELL 2
   while :
   do
modprobe -rv gtp
   done

Splat looks like:
[  753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp]
[  753.177722] Read of size 8 at addr 8880d48f2458 by task gtp-link/7126
[  753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: GW 
5.2.0-rc6+ #50
[  753.185801] Call Trace:
[  753.186264]  dump_stack+0x7c/0xbb
[  753.186863]  ? gtp_newlink+0x9b4/0xa5c [gtp]
[  753.187583]  print_address_description+0xc7/0x240
[  753.188382]  ? gtp_newlink+0x9b4/0xa5c [gtp]
[  753.189097]  ? gtp_newlink+0x9b4/0xa5c [gtp]
[  753.189846]  __kasan_report+0x12a/0x16f
[  753.190542]  ? gtp_newlink+0x9b4/0xa5c [gtp]
[  753.191298]  kasan_report+0xe/0x20
[  753.191893]  gtp_newlink+0x9b4/0xa5c [gtp]
[  753.192580]  ? __netlink_ns_capable+0xc3/0xf0
[  753.193370]  __rtnl_newlink+0xb9f/0x11b0
[ ... ]
[  753.241201] Allocated by task 7186:
[  753.241844]  save_stack+0x19/0x80
[  753.242399]  __kasan_kmalloc.constprop.3+0xa0/0xd0
[  753.243192]  __kmalloc+0x13e/0x300
[  753.243764]  ops_init+0xd6/0x350
[  753.244314]  register_pernet_operations+0x249/0x6f0
[ ... ]
[  753.251770] Freed by task 7178:
[  753.252288]  save_stack+0x19/0x80
[  753.252833]  __kasan_slab_free+0x111/0x150
[  753.253962]  kfree+0xc7/0x280
[  753.254509]  ops_free_list.part.11+0x1c4/0x2d0
[  753.255241]  unregister_pernet_operations+0x262/0x390
[ ... ]
[  753.285883] list_add corruption. next->prev should be prev 
(8880d48f2458), but was 8880d497d878. (next.
[  753.287241] [ cut here ]
[  753.287794] kernel BUG at lib/list_debug.c:25!
[  753.288364] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[  753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: GB   W 
5.2.0-rc6+ #50
[  753.291036] RIP: 0010:__list_add_valid+0x74/0xd0
[  753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 
b8 01 00 00 00 5b 5d c3 48 89 d9 48b
[  753.293779] RSP: 0018:8880cae8f398 EFLAGS: 00010286
[  753.294401] RAX: 0075 RBX: 8880d497d878 RCX: 
[  753.296260] RDX: 0075 RSI: 0008 RDI: ed10195d1e69
[  753.297070] RBP: 8880cd250ae0 R08: ed101b4bff21 R09: ed101b4bff21
[  753.297899] R10: 0001 R11: ed101b4bff20 R12: 8880d497d878
[  753.298703] R13:  R14: 8880cd250ae0 R15: 8880d48f2458
[  753.299564] FS:  7f5f79805740() GS:8880da40() 
knlGS:
[  753.300533] CS:  0010 DS:  ES:  CR0: 80050033
[  753.301231] CR2: 7fe8c7ef4f10 CR3: b71a6006 CR4: 000606f0
[  753.302183] Call Trace:
[  753.302530]  gtp_newlink+0x5f6/0xa5c [gtp]
[  753.303037]  ? __netlink_ns_capable+0xc3/0xf0
[  753.303576]  __rtnl_newlink+0xb9f/0x11b0
[  753.304092]  ? rtnl_link_unregister+0x230/0x230

Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling 
Protocol (GTP-U)")
Signed-off-by: Taehee Yoo 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/gtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 61e9b288d2dc..d178d5bad7e4 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -1385,9 +1385,9 @@ late_initcall(gtp_init);
 
 static void __exit gtp_fini(void)
 {
-   unregister_pernet_subsys(>p_net_ops);
genl_unregister_family(>p_genl_family);
rtnl_link_unregister(>p_link_ops);
+   unregister_pernet_subsys(>p_net_ops);
 
pr_info("GTP module unloaded\n");
 }
-- 
2.20.1





[PATCH 5.1 221/371] iavf: fix dereference of null rx_buffer pointer

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 9fe06a51287b2d41baef7ece94df34b5abf19b90 ]

A recent commit efa14c3985828d ("iavf: allow null RX descriptors") added
a null pointer sanity check on rx_buffer, however, rx_buffer is being
dereferenced before that check, which implies a null pointer dereference
bug can potentially occur.  Fix this by only dereferencing rx_buffer
until after the null pointer check.

Addresses-Coverity: ("Dereference before null check")
Signed-off-by: Colin Ian King 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/iavf/iavf_txrx.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c 
b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
index 9cc2a617c9f3..2a261d849d5a 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
@@ -1296,7 +1296,7 @@ static struct sk_buff *iavf_construct_skb(struct 
iavf_ring *rx_ring,
  struct iavf_rx_buffer *rx_buffer,
  unsigned int size)
 {
-   void *va = page_address(rx_buffer->page) + rx_buffer->page_offset;
+   void *va;
 #if (PAGE_SIZE < 8192)
unsigned int truesize = iavf_rx_pg_size(rx_ring) / 2;
 #else
@@ -1308,6 +1308,7 @@ static struct sk_buff *iavf_construct_skb(struct 
iavf_ring *rx_ring,
if (!rx_buffer)
return NULL;
/* prefetch first cache line of first page */
+   va = page_address(rx_buffer->page) + rx_buffer->page_offset;
prefetch(va);
 #if L1_CACHE_BYTES < 128
prefetch(va + L1_CACHE_BYTES);
@@ -1362,7 +1363,7 @@ static struct sk_buff *iavf_build_skb(struct iavf_ring 
*rx_ring,
  struct iavf_rx_buffer *rx_buffer,
  unsigned int size)
 {
-   void *va = page_address(rx_buffer->page) + rx_buffer->page_offset;
+   void *va;
 #if (PAGE_SIZE < 8192)
unsigned int truesize = iavf_rx_pg_size(rx_ring) / 2;
 #else
@@ -1374,6 +1375,7 @@ static struct sk_buff *iavf_build_skb(struct iavf_ring 
*rx_ring,
if (!rx_buffer)
return NULL;
/* prefetch first cache line of first page */
+   va = page_address(rx_buffer->page) + rx_buffer->page_offset;
prefetch(va);
 #if L1_CACHE_BYTES < 128
prefetch(va + L1_CACHE_BYTES);
-- 
2.20.1





[PATCH 5.1 216/371] gtp: fix use-after-free in gtp_encap_destroy()

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ]

gtp_encap_destroy() is called twice.
1. When interface is deleted.
2. When udp socket is destroyed.
either gtp->sk0 or gtp->sk1u could be freed by sock_put() in
gtp_encap_destroy(). so, when gtp_encap_destroy() is called again,
it would uses freed sk pointer.

patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to
null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected
by rtnl_lock. so, rtnl_lock() is added.

Test command:
   gtp-link add gtp1 &
   killall gtp-link
   ip link del gtp1

Splat looks like:
[   83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0
[   83.184128] Read of size 8 at addr 8880cc7d5360 by task ip/1008
[   83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50
[   83.188469] Call Trace:
[ ... ]
[   83.200126]  lock_acquire+0x141/0x380
[   83.200575]  ? lock_sock_nested+0x3a/0xf0
[   83.201069]  _raw_spin_lock_bh+0x38/0x70
[   83.201551]  ? lock_sock_nested+0x3a/0xf0
[   83.202044]  lock_sock_nested+0x3a/0xf0
[   83.202520]  gtp_encap_destroy+0x18/0xe0 [gtp]
[   83.203065]  gtp_encap_disable.isra.14+0x13/0x50 [gtp]
[   83.203687]  gtp_dellink+0x56/0x170 [gtp]
[   83.204190]  rtnl_delete_link+0xb4/0x100
[ ... ]
[   83.236513] Allocated by task 976:
[   83.236925]  save_stack+0x19/0x80
[   83.237332]  __kasan_kmalloc.constprop.3+0xa0/0xd0
[   83.237894]  kmem_cache_alloc+0xd8/0x280
[   83.238360]  sk_prot_alloc.isra.42+0x50/0x200
[   83.238874]  sk_alloc+0x32/0x940
[   83.239264]  inet_create+0x283/0xc20
[   83.239684]  __sock_create+0x2dd/0x540
[   83.240136]  __sys_socket+0xca/0x1a0
[   83.240550]  __x64_sys_socket+0x6f/0xb0
[   83.240998]  do_syscall_64+0x9c/0x450
[   83.241466]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   83.242061]
[   83.242249] Freed by task 0:
[   83.242616]  save_stack+0x19/0x80
[   83.243013]  __kasan_slab_free+0x111/0x150
[   83.243498]  kmem_cache_free+0x89/0x250
[   83.24]  __sk_destruct+0x38f/0x5a0
[   83.245366]  rcu_core+0x7e9/0x1c20
[   83.245766]  __do_softirq+0x213/0x8fa

Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/gtp.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 6f1ad7ccaea6..61e9b288d2dc 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -289,13 +289,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, 
struct sk_buff *skb)
return gtp_rx(pctx, skb, hdrlen, gtp->role);
 }
 
-static void gtp_encap_destroy(struct sock *sk)
+static void __gtp_encap_destroy(struct sock *sk)
 {
struct gtp_dev *gtp;
 
lock_sock(sk);
gtp = sk->sk_user_data;
if (gtp) {
+   if (gtp->sk0 == sk)
+   gtp->sk0 = NULL;
+   else
+   gtp->sk1u = NULL;
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
@@ -303,12 +307,19 @@ static void gtp_encap_destroy(struct sock *sk)
release_sock(sk);
 }
 
+static void gtp_encap_destroy(struct sock *sk)
+{
+   rtnl_lock();
+   __gtp_encap_destroy(sk);
+   rtnl_unlock();
+}
+
 static void gtp_encap_disable_sock(struct sock *sk)
 {
if (!sk)
return;
 
-   gtp_encap_destroy(sk);
+   __gtp_encap_destroy(sk);
 }
 
 static void gtp_encap_disable(struct gtp_dev *gtp)
@@ -1047,6 +1058,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct 
genl_info *info)
return -EINVAL;
}
 
+   rtnl_lock();
rcu_read_lock();
 
gtp = gtp_find_dev(sock_net(skb->sk), info->attrs);
@@ -1071,6 +1083,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct 
genl_info *info)
 
 out_unlock:
rcu_read_unlock();
+   rtnl_unlock();
return err;
 }
 
-- 
2.20.1





[PATCH 5.1 234/371] scsi: zfcp: fix request object use-after-free in send path causing seqno errors

2019-07-24 Thread Greg Kroah-Hartman
From: Benjamin Block 

commit b76becde2b84137faa29bbc9a3b20953b5980e48 upstream.

With a recent change to our send path for FSF commands we introduced a
possible use-after-free of request-objects, that might further lead to
zfcp crafting bad requests, which the FCP channel correctly complains
about with an error (FSF_PROT_SEQ_NUMB_ERROR). This error is then handled
by an adapter-wide recovery.

The following sequence illustrates the possible use-after-free:

Send Path:

int zfcp_fsf_open_port(struct zfcp_erp_action *erp_action)
{
struct zfcp_fsf_req *req;
...
spin_lock_irq(&qdio->req_q_lock);
// 
// protects QDIO queue during sending
...
req = zfcp_fsf_req_create(qdio,
  FSF_QTCB_OPEN_PORT_WITH_DID,
  SBAL_SFLAGS0_TYPE_READ,
  qdio->adapter->pool.erp_req);
//^^^
//allocation of the request-object
...
retval = zfcp_fsf_req_send(req);
...
spin_unlock_irq(&qdio->req_q_lock);
return retval;
}

static int zfcp_fsf_req_send(struct zfcp_fsf_req *req)
{
struct zfcp_adapter *adapter = req->adapter;
struct zfcp_qdio *qdio = adapter->qdio;
...
zfcp_reqlist_add(adapter->req_list, req);
//  
//  add request to our driver-internal hash-table for tracking
//  (protected by separate lock req_list->lock)
...
if (zfcp_qdio_send(qdio, &req->qdio_req)) {
//  ^^
//  hand-off the request to FCP channel;
//  the request can complete at any point now
...
}

/* Don't increase for unsolicited status */
if (!zfcp_fsf_req_is_status_read_buffer(req))
//   ^^
//   possible use-after-free
adapter->fsf_req_seq_no++;
//   
//   because of the use-after-free we might
//   miss this accounting, and as follow-up
//   this results in the FCP channel error
//   FSF_PROT_SEQ_NUMB_ERROR
adapter->req_no++;

return 0;
}

static inline bool
zfcp_fsf_req_is_status_read_buffer(struct zfcp_fsf_req *req)
{
return req->qtcb == NULL;
// ^
// possible use-after-free
}

Response Path:

void zfcp_fsf_reqid_check(struct zfcp_qdio *qdio, int sbal_idx)
{
...
struct zfcp_fsf_req *fsf_req;
...
for (idx = 0; idx < QDIO_MAX_ELEMENTS_PER_BUFFER; idx++) {
...
fsf_req = zfcp_reqlist_find_rm(adapter->req_list,
   req_id);
//
//remove request from our driver-internal
//hash-table (lock req_list->lock)
...
zfcp_fsf_req_complete(fsf_req);
}
}

static void zfcp_fsf_req_complete(struct zfcp_fsf_req *req)
{
...
if (likely(req->status & ZFCP_STATUS_FSFREQ_CLEANUP))
zfcp_fsf_req_free(req);
//  ^
//  free memory for request-object
else
complete(&req->completion);
//  
//  completion notification for code-paths that wait
//  synchronous for the completion of the request; in
//  those the memory is freed separately
}

The result of the use-after-free only affects the send path, and can not
lead to any data corruption. In case we miss the sequence-number
accounting, because the memory was already re-purposed, the next FSF
command will fail with said FCP channel error, and we will recover the
whole adapter. This causes no additional errors, but it slows down
traffic.  There is a slight chance of the same thing happen again
recursively after the adapter recovery, but so far this has not been seen.

This was seen under z/VM, where the send path might run on a virtual CPU
that gets scheduled away by z/VM, while the return path might still run,
and so create the necessar

[PATCH 5.1 228/371] xen: let alloc_xenballooned_pages() fail if not enough memory free

2019-07-24 Thread Greg Kroah-Hartman
From: Juergen Gross 

commit a1078e821b605813b63bf6bca414a85f804d5c66 upstream.

Instead of trying to allocate pages with GFP_USER in
add_ballooned_pages() check the available free memory via
si_mem_available(). GFP_USER is far less limiting memory exhaustion
than the test via si_mem_available().

This will avoid dom0 running out of memory due to excessive foreign
page mappings especially on ARM and on x86 in PVH mode, as those don't
have a pre-ballooned area which can be used for foreign mappings.

As the normal ballooning suffers from the same problem don't balloon
down more than si_mem_available() pages in one iteration. At the same
time limit the default maximum number of retries.

This is part of XSA-300.

Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/balloon.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -538,8 +538,15 @@ static void balloon_process(struct work_
state = reserve_additional_memory();
}
 
-   if (credit < 0)
-   state = decrease_reservation(-credit, GFP_BALLOON);
+   if (credit < 0) {
+   long n_pages;
+
+   n_pages = min(-credit, si_mem_available());
+   state = decrease_reservation(n_pages, GFP_BALLOON);
+   if (state == BP_DONE && n_pages != -credit &&
+   n_pages < totalreserve_pages)
+   state = BP_EAGAIN;
+   }
 
state = update_schedule(state);
 
@@ -578,6 +585,9 @@ static int add_ballooned_pages(int nr_pa
}
}
 
+   if (si_mem_available() < nr_pages)
+   return -ENOMEM;
+
st = decrease_reservation(nr_pages, GFP_USER);
if (st != BP_DONE)
return -ENOMEM;
@@ -710,7 +720,7 @@ static int __init balloon_init(void)
balloon_stats.schedule_delay = 1;
balloon_stats.max_schedule_delay = 32;
balloon_stats.retry_count = 1;
-   balloon_stats.max_retry_count = RETRY_UNLIMITED;
+   balloon_stats.max_retry_count = 4;
 
 #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
set_online_page_callback(&xen_online_page);




[PATCH 5.1 231/371] Revert "scsi: ncr5380: Increase register polling limit"

2019-07-24 Thread Greg Kroah-Hartman
From: Finn Thain 

commit 25fcf94a2fa89dd3e73e965ebb0b38a2a4f72aa4 upstream.

This reverts commit 4822827a69d7cd3bc5a07b7637484ebd2cf88db6.

The purpose of that commit was to suppress a timeout warning message which
appeared to be caused by target latency. But suppressing the warning is
undesirable as the warning may indicate a messed up transfer count.

Another problem with that commit is that 15 ms is too long to keep
interrupts disabled as interrupt latency can cause system clock drift and
other problems.

Cc: Michael Schmitz 
Cc: sta...@vger.kernel.org
Fixes: 4822827a69d7 ("scsi: ncr5380: Increase register polling limit")
Signed-off-by: Finn Thain 
Tested-by: Stan Johnson 
Tested-by: Michael Schmitz 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/NCR5380.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -235,7 +235,7 @@ struct NCR5380_cmd {
 #define NCR5380_PIO_CHUNK_SIZE 256
 
 /* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA 
*/
-#define NCR5380_REG_POLL_TIME  15
+#define NCR5380_REG_POLL_TIME  10
 
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {




[PATCH 5.1 238/371] scsi: mac_scsi: Fix pseudo DMA implementation, take 2

2019-07-24 Thread Greg Kroah-Hartman
From: Finn Thain 

commit 78ff751f8e6a9446e9fb26b2bff0b8d3f8974cbd upstream.

A system bus error during a PDMA transfer can mess up the calculation of
the transfer residual (the PDMA handshaking hardware lacks a byte
counter). This results in data corruption.

The algorithm in this patch anticipates a bus error by starting each
transfer with a MOVE.B instruction. If a bus error is caught the transfer
will be retried. If a bus error is caught later in the transfer (for a
MOVE.W instruction) the transfer gets failed and subsequent requests for
that target will use PIO instead of PDMA.

This avoids the "!REQ and !ACK" error so the severity level of that message
is reduced to KERN_DEBUG.

Cc: Michael Schmitz 
Cc: Geert Uytterhoeven 
Cc: sta...@vger.kernel.org # v4.14+
Fixes: 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation")
Signed-off-by: Finn Thain 
Reported-by: Chris Jones 
Tested-by: Stan Johnson 
Tested-by: Michael Schmitz 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/mac_scsi.c |  369 
 1 file changed, 217 insertions(+), 152 deletions(-)

--- a/drivers/scsi/mac_scsi.c
+++ b/drivers/scsi/mac_scsi.c
@@ -3,6 +3,8 @@
  *
  * Copyright 1998, Michael Schmitz 
  *
+ * Copyright 2019 Finn Thain
+ *
  * derived in part from:
  */
 /*
@@ -11,6 +13,7 @@
  * Copyright 1995, Russell King
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -89,101 +92,217 @@ static int __init mac_scsi_setup(char *s
 __setup("mac5380=", mac_scsi_setup);
 #endif /* !MODULE */
 
-/* Pseudo DMA asm originally by Ove Edlund */
+/*
+ * According to "Inside Macintosh: Devices", Mac OS requires disk drivers to
+ * specify the number of bytes between the delays expected from a SCSI target.
+ * This allows the operating system to "prevent bus errors when a target fails
+ * to deliver the next byte within the processor bus error timeout period."
+ * Linux SCSI drivers lack knowledge of the timing behaviour of SCSI targets
+ * so bus errors are unavoidable.
+ *
+ * If a MOVE.B instruction faults, we assume that zero bytes were transferred
+ * and simply retry. That assumption probably depends on target behaviour but
+ * seems to hold up okay. The NOP provides synchronization: without it the
+ * fault can sometimes occur after the program counter has moved past the
+ * offending instruction. Post-increment addressing can't be used.
+ */
+
+#define MOVE_BYTE(operands) \
+   asm volatile ( \
+   "1: moveb " operands " \n" \
+   "11:nop\n" \
+   "   addq #1,%0 \n" \
+   "   subq #1,%1 \n" \
+   "40:   \n" \
+   "  \n" \
+   ".section .fixup,\"ax\"\n" \
+   ".even \n" \
+   "90:movel #1, %2   \n" \
+   "   jra 40b\n" \
+   ".previous \n" \
+   "  \n" \
+   ".section __ex_table,\"a\" \n" \
+   ".align  4 \n" \
+   ".long   1b,90b\n" \
+   ".long  11b,90b\n" \
+   ".previous \n" \
+   : "+a" (addr), "+r" (n), "+r" (result) : "a" (io))
 
-#define CP_IO_TO_MEM(s,d,n)\
-__asm__ __volatile__   \
-("cmp.w  #4,%2\n"  \
- "bls8f\n" \
- "move.w %1,%%d0\n"\
- "neg.b  %%d0\n"   \
- "and.w  #3,%%d0\n"\
- "sub.w  %%d0,%2\n"\
- "bra2f\n" \
- " 1: move.b (%0),(%1)+\n" \
- " 2: dbf%%d0,1b\n"\
- "move.w %2,%%d0\n"\
- "lsr.w  #5,%%d0\n"\
- "bra4f\n" \
- " 3: move.l (%0),(%1)+\n" \
- "31: move.l (%0),(%1)+\n" \
- "32: move.l (%0),(%1)+\n" \
- "33: move.l (%0),(%1)+\n" \
- "34: move.l (%0),(%1)+\n" \
- "35: move.l (%0),(%1)+\n" \
- "36: move.l (%0),(%1)+\n" \
- "37: move.l (%0),(%1)+\n" \
- " 4: dbf%%d0,3b\n"\
- "move.w %2,%%d0\n"\
- "lsr.w  #2,%%d0\n"\
- "and.w  #7,%%d0\n"\
- "bra6f\n"   

[PATCH 5.1 243/371] crypto: arm64/sha2-ce - correct digest for empty data in finup

2019-07-24 Thread Greg Kroah-Hartman
From: Elena Petrova 

commit 6bd934de1e393466b319d29c4427598fda096c57 upstream.

The sha256-ce finup implementation for ARM64 produces wrong digest
for empty input (len=0). Expected: the actual digest, result: initial
value of SHA internal state. The error is in sha256_ce_finup:
for empty data `finalize` will be 1, so the code is relying on
sha2_ce_transform to make the final round. However, in
sha256_base_do_update, the block function will not be called when
len == 0.

Fix it by setting finalize to 0 if data is empty.

Fixes: 03802f6a80b3a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 
implementation to base layer")
Cc: sta...@vger.kernel.org
Signed-off-by: Elena Petrova 
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/crypto/sha2-ce-glue.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/crypto/sha2-ce-glue.c
+++ b/arch/arm64/crypto/sha2-ce-glue.c
@@ -59,7 +59,7 @@ static int sha256_ce_finup(struct shash_
   unsigned int len, u8 *out)
 {
struct sha256_ce_state *sctx = shash_desc_ctx(desc);
-   bool finalize = !sctx->sst.count && !(len % SHA256_BLOCK_SIZE);
+   bool finalize = !sctx->sst.count && !(len % SHA256_BLOCK_SIZE) && len;
 
if (!may_use_simd()) {
if (len)




[PATCH 5.1 241/371] crypto: ccp - Validate the the error value used to index error messages

2019-07-24 Thread Greg Kroah-Hartman
From: Hook, Gary 

commit 52393d617af7b554f03531e6756facf2ea687d2e upstream.

The error code read from the queue status register is only 6 bits wide,
but we need to verify its value is within range before indexing the error
messages.

Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable")
Cc: 
Reported-by: Cfir Cohen 
Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/crypto/ccp/ccp-dev.c |   96 ++-
 drivers/crypto/ccp/ccp-dev.h |2 
 2 files changed, 52 insertions(+), 46 deletions(-)

--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -35,56 +35,62 @@ struct ccp_tasklet_data {
 };
 
 /* Human-readable error strings */
+#define CCP_MAX_ERROR_CODE 64
 static char *ccp_error_codes[] = {
"",
-   "ERR 01: ILLEGAL_ENGINE",
-   "ERR 02: ILLEGAL_KEY_ID",
-   "ERR 03: ILLEGAL_FUNCTION_TYPE",
-   "ERR 04: ILLEGAL_FUNCTION_MODE",
-   "ERR 05: ILLEGAL_FUNCTION_ENCRYPT",
-   "ERR 06: ILLEGAL_FUNCTION_SIZE",
-   "ERR 07: Zlib_MISSING_INIT_EOM",
-   "ERR 08: ILLEGAL_FUNCTION_RSVD",
-   "ERR 09: ILLEGAL_BUFFER_LENGTH",
-   "ERR 10: VLSB_FAULT",
-   "ERR 11: ILLEGAL_MEM_ADDR",
-   "ERR 12: ILLEGAL_MEM_SEL",
-   "ERR 13: ILLEGAL_CONTEXT_ID",
-   "ERR 14: ILLEGAL_KEY_ADDR",
-   "ERR 15: 0xF Reserved",
-   "ERR 16: Zlib_ILLEGAL_MULTI_QUEUE",
-   "ERR 17: Zlib_ILLEGAL_JOBID_CHANGE",
-   "ERR 18: CMD_TIMEOUT",
-   "ERR 19: IDMA0_AXI_SLVERR",
-   "ERR 20: IDMA0_AXI_DECERR",
-   "ERR 21: 0x15 Reserved",
-   "ERR 22: IDMA1_AXI_SLAVE_FAULT",
-   "ERR 23: IDMA1_AIXI_DECERR",
-   "ERR 24: 0x18 Reserved",
-   "ERR 25: ZLIBVHB_AXI_SLVERR",
-   "ERR 26: ZLIBVHB_AXI_DECERR",
-   "ERR 27: 0x1B Reserved",
-   "ERR 27: ZLIB_UNEXPECTED_EOM",
-   "ERR 27: ZLIB_EXTRA_DATA",
-   "ERR 30: ZLIB_BTYPE",
-   "ERR 31: ZLIB_UNDEFINED_SYMBOL",
-   "ERR 32: ZLIB_UNDEFINED_DISTANCE_S",
-   "ERR 33: ZLIB_CODE_LENGTH_SYMBOL",
-   "ERR 34: ZLIB _VHB_ILLEGAL_FETCH",
-   "ERR 35: ZLIB_UNCOMPRESSED_LEN",
-   "ERR 36: ZLIB_LIMIT_REACHED",
-   "ERR 37: ZLIB_CHECKSUM_MISMATCH0",
-   "ERR 38: ODMA0_AXI_SLVERR",
-   "ERR 39: ODMA0_AXI_DECERR",
-   "ERR 40: 0x28 Reserved",
-   "ERR 41: ODMA1_AXI_SLVERR",
-   "ERR 42: ODMA1_AXI_DECERR",
-   "ERR 43: LSB_PARITY_ERR",
+   "ILLEGAL_ENGINE",
+   "ILLEGAL_KEY_ID",
+   "ILLEGAL_FUNCTION_TYPE",
+   "ILLEGAL_FUNCTION_MODE",
+   "ILLEGAL_FUNCTION_ENCRYPT",
+   "ILLEGAL_FUNCTION_SIZE",
+   "Zlib_MISSING_INIT_EOM",
+   "ILLEGAL_FUNCTION_RSVD",
+   "ILLEGAL_BUFFER_LENGTH",
+   "VLSB_FAULT",
+   "ILLEGAL_MEM_ADDR",
+   "ILLEGAL_MEM_SEL",
+   "ILLEGAL_CONTEXT_ID",
+   "ILLEGAL_KEY_ADDR",
+   "0xF Reserved",
+   "Zlib_ILLEGAL_MULTI_QUEUE",
+   "Zlib_ILLEGAL_JOBID_CHANGE",
+   "CMD_TIMEOUT",
+   "IDMA0_AXI_SLVERR",
+   "IDMA0_AXI_DECERR",
+   "0x15 Reserved",
+   "IDMA1_AXI_SLAVE_FAULT",
+   "IDMA1_AIXI_DECERR",
+   "0x18 Reserved",
+   "ZLIBVHB_AXI_SLVERR",
+   "ZLIBVHB_AXI_DECERR",
+   "0x1B Reserved",
+   "ZLIB_UNEXPECTED_EOM",
+   "ZLIB_EXTRA_DATA",
+   "ZLIB_BTYPE",
+   "ZLIB_UNDEFINED_SYMBOL",
+   "ZLIB_UNDEFINED_DISTANCE_S",
+   "ZLIB_CODE_LENGTH_SYMBOL",
+   "ZLIB _VHB_ILLEGAL_FETCH",
+   "ZLIB_UNCOMPRESSED_LEN",
+   "ZLIB_LIMIT_REACHED",
+   "ZLIB_CHECKSUM_MISMATCH0",
+   "ODMA0_AXI_SLVERR",
+   "ODMA0_AXI_DECERR",
+   "0x28 Reserved",
+   "ODMA1_AXI_SLVERR",
+   "ODMA1_AXI_DECERR",
 };
 
-void ccp_log_error(struct ccp_device *d, int e)
+void ccp_log_error(struct ccp_device *d, unsigned int e)
 {
-   dev_err(d->dev, "CCP error: %s (0x%x)\n", ccp_error_codes[e], e);
+   if (WARN_ON(e >= CCP_MAX_ERROR_CODE))
+   return;
+
+   if (e < ARRAY_SIZE(ccp_error_codes))
+   dev_err(d->dev, "CCP error %d: %s\n", e, ccp_error_codes[e]);
+   else
+   dev_err(d->dev, "CCP error %d: Unknown Error\n", e);
 }
 
 /* List of CCPs, CCP count, read-write access lock, and access functions
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -632,7 +632,7 @@ struct ccp5_desc {
 void ccp_add_device(struct ccp_device *ccp);
 void ccp_del_device(struct ccp_device *ccp);
 
-extern void ccp_log_error(struct ccp_device *, int);
+extern void ccp_log_error(struct ccp_device *, unsigned int);
 
 struct ccp_device *ccp_alloc_struct(struct sp_device *sp);
 bool ccp_queues_suspended(struct ccp_device *ccp);




[PATCH 5.1 235/371] scsi: zfcp: fix request object use-after-free in send path causing wrong traces

2019-07-24 Thread Greg Kroah-Hartman
From: Benjamin Block 

commit 106d45f350c7cac876844dc685845cba4ffdb70b upstream.

When tracing instances where we open and close WKA ports, we also pass the
request-ID of the respective FSF command.

But after successfully sending the FSF command we must not use the
request-object anymore, as this might result in an use-after-free (see
"zfcp: fix request object use-after-free in send path causing seqno
errors" ).

To fix this add a new variable that caches the request-ID before sending
the request. This won't change during the hand-off to the FCP channel,
and so it's safe to trace this cached request-ID later, instead of using
the request object.

Signed-off-by: Benjamin Block 
Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
Cc:  #2.6.38+
Reviewed-by: Steffen Maier 
Reviewed-by: Jens Remus 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/s390/scsi/zfcp_fsf.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -1627,6 +1627,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_f
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
struct zfcp_fsf_req *req;
+   unsigned long req_id = 0;
int retval = -EIO;
 
spin_lock_irq(&qdio->req_q_lock);
@@ -1649,6 +1650,8 @@ int zfcp_fsf_open_wka_port(struct zfcp_f
hton24(req->qtcb->bottom.support.d_id, wka_port->d_id);
req->data = wka_port;
 
+   req_id = req->req_id;
+
zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
retval = zfcp_fsf_req_send(req);
if (retval)
@@ -1657,7 +1660,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_f
 out:
spin_unlock_irq(&qdio->req_q_lock);
if (!retval)
-   zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
+   zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req_id);
return retval;
 }
 
@@ -1683,6 +1686,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
struct zfcp_fsf_req *req;
+   unsigned long req_id = 0;
int retval = -EIO;
 
spin_lock_irq(&qdio->req_q_lock);
@@ -1705,6 +1709,8 @@ int zfcp_fsf_close_wka_port(struct zfcp_
req->data = wka_port;
req->qtcb->header.port_handle = wka_port->handle;
 
+   req_id = req->req_id;
+
zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
retval = zfcp_fsf_req_send(req);
if (retval)
@@ -1713,7 +1719,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_
 out:
spin_unlock_irq(&qdio->req_q_lock);
if (!retval)
-   zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req->req_id);
+   zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req_id);
return retval;
 }
 




[PATCH 5.1 245/371] crypto: crypto4xx - fix AES CTR blocksize value

2019-07-24 Thread Greg Kroah-Hartman
From: Christian Lamparter 

commit bfa2ba7d9e6b20aca82b99e6842fe18842ae3a0f upstream.

This patch fixes a issue with crypto4xx's ctr(aes) that was
discovered by libcapi's kcapi-enc-test.sh test.

The some of the ctr(aes) encryptions test were failing on the
non-power-of-two test:

kcapi-enc - Error: encryption failed with error 0
kcapi-enc - Error: decryption failed with error 0
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits):
original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated CT): original file (e3b0..5) and generated file (3..8e)
[PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated PT)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password):
original file (1d1..84c) and generated file (e3b..852b855)

But the 16, 32, 512, 65536 tests always worked.

Thankfully, this isn't a hidden hardware problem like previously,
instead this turned out to be a copy and paste issue.

With this patch, all the tests are passing with and
kcapi-enc-test.sh gives crypto4xx's a clean bill of health:
 "Number of failures: 0" :).

Cc: sta...@vger.kernel.org
Fixes: 98e87e3d933b ("crypto: crypto4xx - add aes-ctr support")
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB 
offloads")
Signed-off-by: Christian Lamparter 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/crypto/amcc/crypto4xx_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1259,7 +1259,7 @@ static struct crypto4xx_alg_common crypt
.cra_flags = CRYPTO_ALG_NEED_FALLBACK |
CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
-   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},
@@ -1279,7 +1279,7 @@ static struct crypto4xx_alg_common crypt
.cra_priority = CRYPTO4XX_CRYPTO_PRIORITY,
.cra_flags = CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
-   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},




[PATCH 5.1 244/371] crypto: chacha20poly1305 - fix atomic sleep when using async algorithm

2019-07-24 Thread Greg Kroah-Hartman
From: Eric Biggers 

commit 7545b6c2087f4ef0287c8c9b7eba6a728c67ff8e upstream.

Clear the CRYPTO_TFM_REQ_MAY_SLEEP flag when the chacha20poly1305
operation is being continued from an async completion callback, since
sleeping may not be allowed in that context.

This is basically the same bug that was recently fixed in the xts and
lrw templates.  But, it's always been broken in chacha20poly1305 too.
This was found using syzkaller in combination with the updated crypto
self-tests which actually test the MAY_SLEEP flag now.

Reproducer:

python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(
   ("aead", "rfc7539(cryptd(chacha20-generic),poly1305-generic)"))'

Kernel output:

BUG: sleeping function called from invalid context at 
include/crypto/algapi.h:426
in_atomic(): 1, irqs_disabled(): 0, pid: 1001, name: kworker/2:2
[...]
CPU: 2 PID: 1001 Comm: kworker/2:2 Not tainted 5.2.0-rc2 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-20181126_142135-anatol 04/01/2014
Workqueue: crypto cryptd_queue_worker
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x4d/0x6a lib/dump_stack.c:113
 ___might_sleep kernel/sched/core.c:6138 [inline]
 ___might_sleep.cold.19+0x8e/0x9f kernel/sched/core.c:6095
 crypto_yield include/crypto/algapi.h:426 [inline]
 crypto_hash_walk_done+0xd6/0x100 crypto/ahash.c:113
 shash_ahash_update+0x41/0x60 crypto/shash.c:251
 shash_async_update+0xd/0x10 crypto/shash.c:260
 crypto_ahash_update include/crypto/hash.h:539 [inline]
 poly_setkey+0xf6/0x130 crypto/chacha20poly1305.c:337
 poly_init+0x51/0x60 crypto/chacha20poly1305.c:364
 async_done_continue crypto/chacha20poly1305.c:78 [inline]
 poly_genkey_done+0x15/0x30 crypto/chacha20poly1305.c:369
 cryptd_skcipher_complete+0x29/0x70 crypto/cryptd.c:279
 cryptd_skcipher_decrypt+0xcd/0x110 crypto/cryptd.c:339
 cryptd_queue_worker+0x70/0xa0 crypto/cryptd.c:184
 process_one_work+0x1ed/0x420 kernel/workqueue.c:2269
 worker_thread+0x3e/0x3a0 kernel/workqueue.c:2415
 kthread+0x11f/0x140 kernel/kthread.c:255
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

Fixes: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD 
construction, RFC7539")
Cc:  # v4.2+
Cc: Martin Willi 
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 crypto/chacha20poly1305.c |   30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -65,6 +65,8 @@ struct chachapoly_req_ctx {
unsigned int cryptlen;
/* Actual AD, excluding IV */
unsigned int assoclen;
+   /* request flags, with MAY_SLEEP cleared if needed */
+   u32 flags;
union {
struct poly_req poly;
struct chacha_req chacha;
@@ -74,8 +76,12 @@ struct chachapoly_req_ctx {
 static inline void async_done_continue(struct aead_request *req, int err,
   int (*cont)(struct aead_request *))
 {
-   if (!err)
+   if (!err) {
+   struct chachapoly_req_ctx *rctx = aead_request_ctx(req);
+
+   rctx->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
err = cont(req);
+   }
 
if (err != -EINPROGRESS && err != -EBUSY)
aead_request_complete(req, err);
@@ -142,7 +148,7 @@ static int chacha_decrypt(struct aead_re
dst = scatterwalk_ffwd(rctx->dst, req->dst, req->assoclen);
}
 
-   skcipher_request_set_callback(&creq->req, aead_request_flags(req),
+   skcipher_request_set_callback(&creq->req, rctx->flags,
  chacha_decrypt_done, req);
skcipher_request_set_tfm(&creq->req, ctx->chacha);
skcipher_request_set_crypt(&creq->req, src, dst,
@@ -186,7 +192,7 @@ static int poly_tail(struct aead_request
memcpy(&preq->tail.cryptlen, &len, sizeof(len));
sg_set_buf(preq->src, &preq->tail, sizeof(preq->tail));
 
-   ahash_request_set_callback(&preq->req, aead_request_flags(req),
+   ahash_request_set_callback(&preq->req, rctx->flags,
   poly_tail_done, req);
ahash_request_set_tfm(&preq->req, ctx->poly);
ahash_request_set_crypt(&preq->req, preq->src,
@@ -217,7 +223,7 @@ static int poly_cipherpad(struct aead_re
sg_init_table(preq->src, 1);
sg_set_buf(preq->src, &preq->pad, padlen);
 
-   ahash_request_set_callback(&preq->req, aead_request_flags(req),
+   ahash_request_set_callback(&preq->req, rctx->flags,
   poly_cipherpad_done, req);
ahash_request_set_tfm(&preq->req, ctx->poly);
ahash_request_set_crypt(&preq->req, preq->src, NULL, padlen);
@@ -248,7 +254,7 @@ static int poly_cipher(struct aead_reque
sg_init_table(rctx->src, 2);
cry

[PATCH 5.1 240/371] crypto: caam - limit output IV to CBC to work around CTR mode DMA issue

2019-07-24 Thread Greg Kroah-Hartman
From: Ard Biesheuvel 

commit ed527b13d800dd515a9e6c582f0a73eca65b2e1b upstream.

The CAAM driver currently violates an undocumented and slightly
controversial requirement imposed by the crypto stack that a buffer
referred to by the request structure via its virtual address may not
be modified while any scatterlists passed via the same request
structure are mapped for inbound DMA.

This may result in errors like

  alg: aead: decryption failed on test 1 for 
gcm_base(ctr-aes-caam,ghash-generic): ret=74
  alg: aead: Failed to load transform for gcm(aes): -2

on non-cache coherent systems, due to the fact that the GCM driver
passes an IV buffer by virtual address which shares a cacheline with
the auth_tag buffer passed via a scatterlist, resulting in corruption
of the auth_tag when the IV is updated while the DMA mapping is live.

Since the IV that is returned to the caller is only valid for CBC mode,
and given that the in-kernel users of CBC (such as CTS) don't trigger the
same issue as the GCM driver, let's just disable the output IV generation
for all modes except CBC for the time being.

Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt")
Cc: Horia Geanta 
Cc: Iuliana Prodan 
Reported-by: Sascha Hauer 
Cc: 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Horia Geanta 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/crypto/caam/caamalg.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -965,6 +965,7 @@ static void skcipher_encrypt_done(struct
struct skcipher_request *req = context;
struct skcipher_edesc *edesc;
struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
+   struct caam_ctx *ctx = crypto_skcipher_ctx(skcipher);
int ivsize = crypto_skcipher_ivsize(skcipher);
 
 #ifdef DEBUG
@@ -989,9 +990,9 @@ static void skcipher_encrypt_done(struct
 
/*
 * The crypto API expects us to set the IV (req->iv) to the last
-* ciphertext block. This is used e.g. by the CTS mode.
+* ciphertext block when running in CBC mode.
 */
-   if (ivsize)
+   if ((ctx->cdata.algtype & OP_ALG_AAI_MASK) == OP_ALG_AAI_CBC)
scatterwalk_map_and_copy(req->iv, req->dst, req->cryptlen -
 ivsize, ivsize, 0);
 
@@ -1809,9 +1810,9 @@ static int skcipher_decrypt(struct skcip
 
/*
 * The crypto API expects us to set the IV (req->iv) to the last
-* ciphertext block.
+* ciphertext block when running in CBC mode.
 */
-   if (ivsize)
+   if ((ctx->cdata.algtype & OP_ALG_AAI_MASK) == OP_ALG_AAI_CBC)
scatterwalk_map_and_copy(req->iv, req->src, req->cryptlen -
 ivsize, ivsize, 0);
 




[PATCH 5.1 246/371] crypto: crypto4xx - fix blocksize for cfb and ofb

2019-07-24 Thread Greg Kroah-Hartman
From: Christian Lamparter 

commit 70c4997f34b6c6888b3ac157adec49e01d0df2d5 upstream.

While the hardware consider them to be blockciphers, the
reference implementation defines them as streamciphers.

Do the right thing and set the blocksize to 1. This
was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS.

This fixes the following issues:
skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1)
skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1)

Cc: Eric Biggers 
Cc: sta...@vger.kernel.org
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB 
offloads")
Signed-off-by: Christian Lamparter 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/crypto/amcc/crypto4xx_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1238,7 +1238,7 @@ static struct crypto4xx_alg_common crypt
.cra_priority = CRYPTO4XX_CRYPTO_PRIORITY,
.cra_flags = CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
-   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},
@@ -1318,7 +1318,7 @@ static struct crypto4xx_alg_common crypt
.cra_priority = CRYPTO4XX_CRYPTO_PRIORITY,
.cra_flags = CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
-   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},




[PATCH 5.1 236/371] scsi: megaraid_sas: Fix calculation of target ID

2019-07-24 Thread Greg Kroah-Hartman
From: Shivasharan S 

commit c8f96df5b8e633056b7ebf5d52a9d6fb1b156ce3 upstream.

In megasas_get_target_prop(), driver is incorrectly calculating the target
ID for devices with channel 1 and 3.  Due to this, firmware will either
fail the command (if there is no device with the target id sent from
driver) or could return the properties for a target which was not
intended.  Devices could end up with the wrong queue depth due to this.

Fix target id calculation for channel 1 and 3.

Fixes: 96188a89cc6d ("scsi: megaraid_sas: NVME interface target prop added")
Cc: sta...@vger.kernel.org
Signed-off-by: Shivasharan S 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/megaraid/megaraid_sas_base.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6168,7 +6168,8 @@ megasas_get_target_prop(struct megasas_i
int ret;
struct megasas_cmd *cmd;
struct megasas_dcmd_frame *dcmd;
-   u16 targetId = (sdev->channel % 2) + sdev->id;
+   u16 targetId = ((sdev->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) +
+   sdev->id;
 
cmd = megasas_get_cmd(instance);
 




[PATCH 5.1 213/371] Bluetooth: validate BLE connection interval updates

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit c49a8682fc5d298d44e8d911f4fa14690ea9485e ]

Problem: The Linux Bluetooth stack yields complete control over the BLE
connection interval to the remote device.

The Linux Bluetooth stack provides access to the BLE connection interval
min and max values through /sys/kernel/debug/bluetooth/hci0/
conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
These values are used for initial BLE connections, but the remote device
has the ability to request a connection parameter update. In the event
that the remote side requests to change the connection interval, the Linux
kernel currently only validates that the desired value is within the
acceptable range in the Bluetooth specification (6 - 3200, corresponding to
7.5ms - 4000ms). There is currently no validation that the desired value
requested by the remote device is within the min/max limits specified in
the conn_min_interval/conn_max_interval configurations. This essentially
leads to Linux yielding complete control over the connection interval to
the remote device.

The proposed patch adds a verification step to the connection parameter
update mechanism, ensuring that the desired value is within the min/max
bounds of the current connection. If the desired value is outside of the
current connection min/max values, then the connection parameter update
request is rejected and the negative response is returned to the remote
device. Recall that the initial connection is established using the local
conn_min_interval/conn_max_interval values, so this allows the Linux
administrator to retain control over the BLE connection interval.

The one downside that I see is that the current default Linux values for
conn_min_interval and conn_max_interval typically correspond to 30ms and
50ms respectively. If this change were accepted, then it is feasible that
some devices would no longer be able to negotiate to their desired
connection interval values. This might be remedied by setting the default
Linux conn_min_interval and conn_max_interval values to the widest
supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
behavior as the current implementation, where the remote device could
request to change the connection interval value to any value that is
permitted by the Bluetooth specification, and Linux would accept the
desired value.

Signed-off-by: Carey Sonsino 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/hci_event.c  | 5 +
 net/bluetooth/l2cap_core.c | 9 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 8b893baf9bbe..31eb0449479b 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5588,6 +5588,11 @@ static void hci_le_remote_conn_param_req_evt(struct 
hci_dev *hdev,
return send_conn_param_neg_reply(hdev, handle,
 HCI_ERROR_UNKNOWN_CONN_ID);
 
+   if (min < hcon->le_conn_min_interval ||
+   max > hcon->le_conn_max_interval)
+   return send_conn_param_neg_reply(hdev, handle,
+HCI_ERROR_INVALID_LL_PARAMS);
+
if (hci_check_conn_params(min, max, latency, timeout))
return send_conn_param_neg_reply(hdev, handle,
 HCI_ERROR_INVALID_LL_PARAMS);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 771e3e17bb6a..32d2be9d6858 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5297,7 +5297,14 @@ static inline int l2cap_conn_param_update_req(struct 
l2cap_conn *conn,
 
memset(&rsp, 0, sizeof(rsp));
 
-   err = hci_check_conn_params(min, max, latency, to_multiplier);
+   if (min < hcon->le_conn_min_interval ||
+   max > hcon->le_conn_max_interval) {
+   BT_DBG("requested connection interval exceeds current bounds.");
+   err = -EINVAL;
+   } else {
+   err = hci_check_conn_params(min, max, latency, to_multiplier);
+   }
+
if (err)
rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
else
-- 
2.20.1





[PATCH 5.1 269/371] iwlwifi: add support for hr1 RF ID

2019-07-24 Thread Greg Kroah-Hartman
From: Oren Givon 

commit 498d3eb5bfbb2e05e40005152976a7b9eadfb59c upstream.

The 22000 series FW that was meant to be used with hr is
also the FW that is used for hr1 and has a different RF ID.
Add support to load the hr FW when hr1 RF ID is detected.

Cc: sta...@vger.kernel.org # 5.1+
Signed-off-by: Oren Givon 
Signed-off-by: Luciano Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/intel/iwlwifi/iwl-csr.h|1 +
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c |8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
@@ -335,6 +335,7 @@ enum {
 /* RF_ID value */
 #define CSR_HW_RF_ID_TYPE_JF   (0x00105100)
 #define CSR_HW_RF_ID_TYPE_HR   (0x0010A000)
+#define CSR_HW_RF_ID_TYPE_HR1  (0x0010c100)
 #define CSR_HW_RF_ID_TYPE_HRCDB(0x00109F00)
 #define CSR_HW_RF_ID_TYPE_GF   (0x0010D000)
 
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3562,9 +3562,11 @@ struct iwl_trans *iwl_trans_pcie_alloc(s
trans->cfg = &iwlax210_2ax_cfg_so_gf_a0;
}
} else if (cfg == &iwl_ax101_cfg_qu_hr) {
-   if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
-   CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
-   trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
+   if ((CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
+trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) ||
+   (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR1))) {
trans->cfg = &iwl22000_2ax_cfg_qnj_hr_b0;
} else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR)) {




[PATCH v2] drm/panel: check failure cases in the probe func

2019-07-24 Thread Navid Emamdoost
The following function calls may fail and return NULL, so the null check
is added.
of_graph_get_next_endpoint
of_graph_get_remote_port_parent
of_graph_get_remote_port

Update: Thanks to Sam Ravnborg, for suggession on the use of goto to avoid
leaking endpoint.

Signed-off-by: Navid Emamdoost 
---
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c   | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 28c0620dfe0f..b5b14aa059ea 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -399,7 +399,13 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
 
/* Look up the DSI host.  It needs to probe before we do. */
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+   if (!endpoint)
+   return -ENODEV;
+
dsi_host_node = of_graph_get_remote_port_parent(endpoint);
+   if (!dsi_host_node)
+   goto error;
+
host = of_find_mipi_dsi_host_by_node(dsi_host_node);
of_node_put(dsi_host_node);
if (!host) {
@@ -408,6 +414,9 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
}
 
info.node = of_graph_get_remote_port(endpoint);
+   if (!info.node)
+   goto error;
+
of_node_put(endpoint);
 
ts->dsi = mipi_dsi_device_register_full(host, &info);
@@ -428,6 +437,10 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
return ret;
 
return 0;
+
+error:
+   of_node_put(endpoint);
+   return -ENODEV;
 }
 
 static int rpi_touchscreen_remove(struct i2c_client *i2c)
-- 
2.17.1



[PATCH 5.1 162/371] ixgbe: Check DDM existence in transceiver before access

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 655c91414579d7bb115a4f7898ee726fc18e0984 ]

Some transceivers may comply with SFF-8472 but not implement the Digital
Diagnostic Monitoring (DDM) interface described in it. The existence of
such area is specified by bit 6 of byte 92, set to 1 if implemented.

Currently, due to not checking this bit ixgbe fails trying to read SFP
module's eeprom with the follow message:

ethtool -m enP51p1s0f0
Cannot get Module EEPROM data: Input/output error

Because it fails to read the additional 256 bytes in which it was assumed
to exist the DDM data.

This issue was noticed using a Mellanox Passive DAC PN 01FT738. The eeprom
data was confirmed by Mellanox as correct and present in other Passive
DACs in from other manufacturers.

Signed-off-by: "Mauro S. M. Rodrigues" 
Reviewed-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 ++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index acba067cc15a..7c52ae8ac005 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -3226,7 +3226,8 @@ static int ixgbe_get_module_info(struct net_device *dev,
page_swap = true;
}
 
-   if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap) {
+   if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap ||
+   !(addr_mode & IXGBE_SFF_DDM_IMPLEMENTED)) {
/* We have a SFP, but it does not support SFF-8472 */
modinfo->type = ETH_MODULE_SFF_8079;
modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
index 214b01085718..6544c4539c0d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
@@ -45,6 +45,7 @@
 #define IXGBE_SFF_SOFT_RS_SELECT_10G   0x8
 #define IXGBE_SFF_SOFT_RS_SELECT_1G0x0
 #define IXGBE_SFF_ADDRESSING_MODE  0x4
+#define IXGBE_SFF_DDM_IMPLEMENTED  0x40
 #define IXGBE_SFF_QSFP_DA_ACTIVE_CABLE 0x1
 #define IXGBE_SFF_QSFP_DA_PASSIVE_CABLE0x8
 #define IXGBE_SFF_QSFP_CONNECTOR_NOT_SEPARABLE 0x23
-- 
2.20.1





[PATCH 5.1 261/371] bcache: destroy dc->writeback_write_wq if failed to create dc->writeback_thread

2019-07-24 Thread Greg Kroah-Hartman
From: Coly Li 

commit f54d801dda14942dbefa00541d10603015b7859c upstream.

Commit 9baf30972b55 ("bcache: fix for gc and write-back race") added a
new work queue dc->writeback_write_wq, but forgot to destroy it in the
error condition when creating dc->writeback_thread failed.

This patch destroys dc->writeback_write_wq if kthread_create() returns
error pointer to dc->writeback_thread, then a memory leak is avoided.

Fixes: 9baf30972b55 ("bcache: fix for gc and write-back race")
Signed-off-by: Coly Li 
Cc: sta...@vger.kernel.org
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -834,6 +834,7 @@ int bch_cached_dev_writeback_start(struc
  "bcache_writeback");
if (IS_ERR(dc->writeback_thread)) {
cached_dev_put(dc);
+   destroy_workqueue(dc->writeback_write_wq);
return PTR_ERR(dc->writeback_thread);
}
dc->writeback_running = true;




[PATCH 5.1 264/371] Input: synaptics - whitelist Lenovo T580 SMBus intertouch

2019-07-24 Thread Greg Kroah-Hartman
From: Nick Black 

commit 1976d7d200c5a32e72293a2ada36b7b7c9d6dd6e upstream.

Adds the Lenovo T580 to the SMBus intertouch list for Synaptics
touchpads. I've tested with this for a week now, and it seems a great
improvement. It's also nice to have the complaint gone from dmesg.

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

---
 drivers/input/mouse/synaptics.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -179,6 +179,7 @@ static const char * const smbus_pnp_ids[
"LEN0093", /* T480 */
"LEN0096", /* X280 */
"LEN0097", /* X280 -> ALPS trackpoint */
+   "LEN009b", /* T580 */
"LEN200f", /* T450s */
"LEN2054", /* E480 */
"LEN2055", /* E580 */




[PATCH 5.1 215/371] gtp: fix Illegal context switch in RCU read-side critical section.

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ]

ipv4_pdp_add() is called in RCU read-side critical section.
So GFP_KERNEL should not be used in the function.
This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL.

Test commands:
gtp-link add gtp1 &
gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2

Splat looks like:
[  130.618881] =
[  130.626382] WARNING: suspicious RCU usage
[  130.626994] 5.2.0-rc6+ #50 Not tainted
[  130.627622] -
[  130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU 
read-side critical section!
[  130.629684]
[  130.629684] other info that might help us debug this:
[  130.629684]
[  130.631022]
[  130.631022] rcu_scheduler_active = 2, debug_locks = 1
[  130.632136] 4 locks held by gtp-tunnel/1025:
[  130.632925]  #0: 2b93c8b7 (cb_lock){}, at: genl_rcv+0x15/0x40
[  130.634159]  #1: f17bc999 (genl_mutex){+.+.}, at: 
genl_rcv_msg+0xfb/0x130
[  130.635487]  #2: c644ed8e (rtnl_mutex){+.+.}, at: 
gtp_genl_new_pdp+0x18c/0x1150 [gtp]
[  130.636936]  #3: 07a1cde7 (rcu_read_lock){}, at: 
gtp_genl_new_pdp+0x187/0x1150 [gtp]
[  130.638348]
[  130.638348] stack backtrace:
[  130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50
[  130.641318] Call Trace:
[  130.641707]  dump_stack+0x7c/0xbb
[  130.642252]  ___might_sleep+0x2c0/0x3b0
[  130.642862]  kmem_cache_alloc_trace+0x1cd/0x2b0
[  130.643591]  gtp_genl_new_pdp+0x6c5/0x1150 [gtp]
[  130.644371]  genl_family_rcv_msg+0x63a/0x1030
[  130.645074]  ? mutex_lock_io_nested+0x1090/0x1090
[  130.645845]  ? genl_unregister_family+0x630/0x630
[  130.646592]  ? debug_show_all_locks+0x2d0/0x2d0
[  130.647293]  ? check_flags.part.40+0x440/0x440
[  130.648099]  genl_rcv_msg+0xa3/0x130
[ ... ]

Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling 
Protocol (GTP-U)")
Signed-off-by: Taehee Yoo 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/gtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index f45a806b6c06..6f1ad7ccaea6 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -958,7 +958,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock 
*sk,
 
}
 
-   pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL);
+   pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC);
if (pctx == NULL)
return -ENOMEM;
 
-- 
2.20.1





[PATCH 5.1 206/371] Bluetooth: Add new 13d3:3501 QCA_ROME device

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit 881cec4f6b4da78e54b73c046a60f39315964c7d ]

Without the QCA ROME setup routine this adapter fails to establish a SCO
connection.

T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3501 Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: João Paulo Rechi Vita 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0e2c86da6479..4c9f11766e82 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -281,6 +281,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x301a), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3491), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3496), .driver_info = BTUSB_QCA_ROME },
+   { USB_DEVICE(0x13d3, 0x3501), .driver_info = BTUSB_QCA_ROME },
 
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
-- 
2.20.1





[PATCH 5.1 207/371] Bluetooth: 6lowpan: search for destination address in all peers

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit b188b03270b7f8568fc714101ce82fbf5e811c5a ]

Handle overlooked case where the target address is assigned to a peer
and neither route nor gateway exist.

For one peer, no checks are performed to see if it is meant to receive
packets for a given address.

As soon as there is a second peer however, checks are performed
to deal with routes and gateways for handling complex setups with
multiple hops to a target address.
This logic assumed that no route and no gateway imply that the
destination address can not be reached, which is false in case of a
direct peer.

Acked-by: Jukka Rissanen 
Tested-by: Michael Scott 
Signed-off-by: Josua Mayer 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/6lowpan.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index a7cd23f00bde..50530561da98 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -187,10 +187,16 @@ static inline struct lowpan_peer *peer_lookup_dst(struct 
lowpan_btle_dev *dev,
}
 
if (!rt) {
-   nexthop = &lowpan_cb(skb)->gw;
-
-   if (ipv6_addr_any(nexthop))
-   return NULL;
+   if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
+   /* There is neither route nor gateway,
+* probably the destination is a direct peer.
+*/
+   nexthop = daddr;
+   } else {
+   /* There is a known gateway
+*/
+   nexthop = &lowpan_cb(skb)->gw;
+   }
} else {
nexthop = rt6_nexthop(rt, daddr);
 
-- 
2.20.1





[PATCH 5.1 214/371] gtp: fix suspicious RCU usage

2019-07-24 Thread Greg Kroah-Hartman
[ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ]

gtp_encap_enable_socket() and gtp_encap_destroy() are not protected
by rcu_read_lock(). and it's not safe to write sk->sk_user_data.
This patch make these functions to use lock_sock() instead of
rcu_dereference_sk_user_data().

Test commands:
gtp-link add gtp1

Splat looks like:
[   83.238315] =
[   83.239127] WARNING: suspicious RCU usage
[   83.239702] 5.2.0-rc6+ #49 Not tainted
[   83.240268] -
[   83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage!
[   83.243828]
[   83.243828] other info that might help us debug this:
[   83.243828]
[   83.246325]
[   83.246325] rcu_scheduler_active = 2, debug_locks = 1
[   83.247314] 1 lock held by gtp-link/1008:
[   83.248523]  #0: 17772c7f (rtnl_mutex){+.+.}, at: 
__rtnl_newlink+0x5f5/0x11b0
[   83.251503]
[   83.251503] stack backtrace:
[   83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49
[   83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
VirtualBox 12/01/2006
[   83.254562] Call Trace:
[   83.254995]  dump_stack+0x7c/0xbb
[   83.255567]  gtp_encap_enable_socket+0x2df/0x360 [gtp]
[   83.256415]  ? gtp_find_dev+0x1a0/0x1a0 [gtp]
[   83.257161]  ? memset+0x1f/0x40
[   83.257843]  gtp_newlink+0x90/0xa21 [gtp]
[   83.258497]  ? __netlink_ns_capable+0xc3/0xf0
[   83.259260]  __rtnl_newlink+0xb9f/0x11b0
[   83.260022]  ? rtnl_link_unregister+0x230/0x230
[ ... ]

Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/gtp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 83488f2bf7a0..f45a806b6c06 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -293,12 +293,14 @@ static void gtp_encap_destroy(struct sock *sk)
 {
struct gtp_dev *gtp;
 
-   gtp = rcu_dereference_sk_user_data(sk);
+   lock_sock(sk);
+   gtp = sk->sk_user_data;
if (gtp) {
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
}
+   release_sock(sk);
 }
 
 static void gtp_encap_disable_sock(struct sock *sk)
@@ -800,7 +802,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int 
type,
goto out_sock;
}
 
-   if (rcu_dereference_sk_user_data(sock->sk)) {
+   lock_sock(sock->sk);
+   if (sock->sk->sk_user_data) {
sk = ERR_PTR(-EBUSY);
goto out_sock;
}
@@ -816,6 +819,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int 
type,
setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg);
 
 out_sock:
+   release_sock(sock->sk);
sockfd_put(sock);
return sk;
 }
-- 
2.20.1





[PATCH 5.1 273/371] iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices

2019-07-24 Thread Greg Kroah-Hartman
From: Emmanuel Grumbach 

commit ed3e4c6d3cd8f093a3636cb05492429fe2af228d upstream.

Newest devices have a new firmware load mechanism. This
mechanism is called the context info. It means that the
driver doesn't need to load the sections of the firmware.
The driver rather prepares a place in DRAM, with pointers
to the relevant sections of the firmware, and the firmware
loads itself.
At the end of the process, the firmware sends the ALIVE
interrupt. This is different from the previous scheme in
which the driver expected the FH_TX interrupt after each
section being transferred over the DMA.

In order to support this new flow, we enabled all the
interrupts. This broke the assumption that we have in the
code that the RF-Kill interrupt can't interrupt the firmware
load flow.

Change the context info flow to enable only the ALIVE
interrupt, and re-enable all the other interrupts only
after the firmware is alive. Then, we won't see the RF-Kill
interrupt until then. Getting the RF-Kill interrupt while
loading the firmware made us kill the firmware while it is
loading and we ended up dumping garbage instead of the firmware
state.

Re-enable the ALIVE | RX interrupts from the ISR when we
get the ALIVE interrupt to be able to get the RX interrupt
that comes immediately afterwards for the ALIVE
notification. This is needed for non MSI-X only.

Cc: sta...@vger.kernel.org
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c |2 -
 drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c  |2 -
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h   |   27 +++
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c |5 ++
 drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c |9 +
 5 files changed, 43 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
@@ -168,7 +168,7 @@ int iwl_pcie_ctxt_info_gen3_init(struct
 
memcpy(iml_img, trans->iml, trans->iml_len);
 
-   iwl_enable_interrupts(trans);
+   iwl_enable_fw_load_int_ctx_info(trans);
 
/* kick FW self load */
iwl_write64(trans, CSR_CTXT_INFO_ADDR,
--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c
@@ -222,7 +222,7 @@ int iwl_pcie_ctxt_info_init(struct iwl_t
 
trans_pcie->ctxt_info = ctxt_info;
 
-   iwl_enable_interrupts(trans);
+   iwl_enable_fw_load_int_ctx_info(trans);
 
/* Configure debug, if exists */
if (iwl_pcie_dbg_on(trans))
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -894,6 +894,33 @@ static inline void iwl_enable_fw_load_in
}
 }
 
+static inline void iwl_enable_fw_load_int_ctx_info(struct iwl_trans *trans)
+{
+   struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+
+   IWL_DEBUG_ISR(trans, "Enabling ALIVE interrupt only\n");
+
+   if (!trans_pcie->msix_enabled) {
+   /*
+* When we'll receive the ALIVE interrupt, the ISR will call
+* iwl_enable_fw_load_int_ctx_info again to set the ALIVE
+* interrupt (which is not really needed anymore) but also the
+* RX interrupt which will allow us to receive the ALIVE
+* notification (which is Rx) and continue the flow.
+*/
+   trans_pcie->inta_mask =  CSR_INT_BIT_ALIVE | CSR_INT_BIT_FH_RX;
+   iwl_write32(trans, CSR_INT_MASK, trans_pcie->inta_mask);
+   } else {
+   iwl_enable_hw_int_msk_msix(trans,
+  MSIX_HW_INT_CAUSES_REG_ALIVE);
+   /*
+* Leave all the FH causes enabled to get the ALIVE
+* notification.
+*/
+   iwl_enable_fh_int_msk_msix(trans, trans_pcie->fh_init_mask);
+   }
+}
+
 static inline u16 iwl_pcie_get_cmd_index(const struct iwl_txq *q, u32 index)
 {
return index & (q->n_window - 1);
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1850,6 +1850,8 @@ irqreturn_t iwl_pcie_irq_handler(int irq
 */
iwl_pcie_rxmq_restock(trans, trans_pcie->rxq);
}
+
+   handled |= CSR_INT_BIT_ALIVE;
}
 
/* Safely ignore these bits for debug checks below */
@@ -1968,6 +1970,9 @@ irqreturn_t iwl_pcie_irq_handler(int irq
/* Re-enable RF_KILL if it occurred */
else if (handled & CSR_INT_BIT_RF_KILL)
iwl_enable_rfkill_int(trans);
+   /* Re-enable the ALIVE / Rx interrupt if it occurred */
+   else if (handled & (CSR_INT_BIT_ALIVE | CSR_INT_BIT_FH_RX))
+   iwl_enable_fw_load_int_ctx_info(trans

[PATCH 5.1 276/371] opp: Dont use IS_ERR on invalid supplies

2019-07-24 Thread Greg Kroah-Hartman
From: Dmitry Osipenko 

commit 560d1bcad715c215e7ffe5d7cffe045974b623d0 upstream.

_set_opp_custom() receives a set of OPP supplies as its arguments and
the caller of it passes NULL when the supplies are not valid. But
_set_opp_custom(), by mistake, checks for error by performing
IS_ERR(old_supply) on it which will always evaluate to false.

The problem was spotted during of testing of upcoming update for the
NVIDIA Tegra CPUFreq driver.

Cc: stable 
Fixes: 7e535993fa4f ("OPP: Separate out custom OPP handler specific code")
Reported-by: Marc Dietrich 
Signed-off-by: Dmitry Osipenko 
[ Viresh: Massaged changelog ]
Signed-off-by: Viresh Kumar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/opp/core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -631,7 +631,7 @@ static int _set_opp_custom(const struct
 
data->old_opp.rate = old_freq;
size = sizeof(*old_supply) * opp_table->regulator_count;
-   if (IS_ERR(old_supply))
+   if (!old_supply)
memset(data->old_opp.supplies, 0, size);
else
memcpy(data->old_opp.supplies, old_supply, size);




[PATCH 5.1 271/371] iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X

2019-07-24 Thread Greg Kroah-Hartman
From: Emmanuel Grumbach 

commit ec46ae30245ecb41d73f8254613db07c653fb498 upstream.

We added code to restock the buffer upon ALIVE interrupt
when MSI-X is disabled. This was added as part of the context
info code. This code was added only if the ISR debug level
is set which is very unlikely to be related.
Move this code to run even when the ISR debug level is not
set.

Note that gen2 devices work with MSI-X in most cases so that
this path is seldom used.

Cc: sta...@vger.kernel.org
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c |   34 ---
 1 file changed, 16 insertions(+), 18 deletions(-)

--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1832,25 +1832,23 @@ irqreturn_t iwl_pcie_irq_handler(int irq
goto out;
}
 
-   if (iwl_have_debug_level(IWL_DL_ISR)) {
-   /* NIC fires this, but we don't use it, redundant with WAKEUP */
-   if (inta & CSR_INT_BIT_SCD) {
-   IWL_DEBUG_ISR(trans,
- "Scheduler finished to transmit the 
frame/frames.\n");
-   isr_stats->sch++;
-   }
+   /* NIC fires this, but we don't use it, redundant with WAKEUP */
+   if (inta & CSR_INT_BIT_SCD) {
+   IWL_DEBUG_ISR(trans,
+ "Scheduler finished to transmit the 
frame/frames.\n");
+   isr_stats->sch++;
+   }
 
-   /* Alive notification via Rx interrupt will do the real work */
-   if (inta & CSR_INT_BIT_ALIVE) {
-   IWL_DEBUG_ISR(trans, "Alive interrupt\n");
-   isr_stats->alive++;
-   if (trans->cfg->gen2) {
-   /*
-* We can restock, since firmware configured
-* the RFH
-*/
-   iwl_pcie_rxmq_restock(trans, trans_pcie->rxq);
-   }
+   /* Alive notification via Rx interrupt will do the real work */
+   if (inta & CSR_INT_BIT_ALIVE) {
+   IWL_DEBUG_ISR(trans, "Alive interrupt\n");
+   isr_stats->alive++;
+   if (trans->cfg->gen2) {
+   /*
+* We can restock, since firmware configured
+* the RFH
+*/
+   iwl_pcie_rxmq_restock(trans, trans_pcie->rxq);
}
}
 




Re: [PATCH] ARM: dts: rockchip: Limit WiFi TX power on rk3288-veyron-jerry

2019-07-24 Thread Doug Anderson
Hi,

On Tue, Jul 23, 2019 at 3:53 PM Matthias Kaehlcke  wrote:
>
> The downstream Chrome OS 3.14 kernel for jerry limits WiFi TX power
> through calibration data in the device tree [1]. Add a DT node for
> the WiFi chip and use the downstream calibration data.
>
> Not all calibration data entries have the length specified in the
> binding (Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt),
> however this is the data used by the downstream ('official') kernel
> and the binding mentions that "the length can vary between hw
> versions".
>
> [1] https://crrev.com/c/271237
>
> Signed-off-by: Matthias Kaehlcke 
> ---
>  arch/arm/boot/dts/rk3288-veyron-jerry.dts | 147 ++
>  1 file changed, 147 insertions(+)

I agree that this matches what's downstream and seems right.

As you pointed out the bindings are a bit on the sketchy side,
claiming a certain length in one place but then saying that the length
depends on the HW version in another place.  I'll also point out that
the bindings are inconsistent about the name that should be used.
AKA:

marvell,caldata-txpwrlimit-2g
 -vs-
marvell,caldata_00_txpwrlimit_2g_cfg_set

...but I think the answer is that it doesn't matter at all from a
practical point of view.  The code seems to just find everything that
starts with "marvell,caldata" and send the binary blindly to the WiFi
card.  Presumably there is enough of a header in the opaque binary
data that the card can make sense of what it's being sent.


So it seems like this is the best we can do given the current state of
the world.

Reviewed-by: Douglas Anderson 


[PATCH 5.1 274/371] iwlwifi: mvm: delay GTK setting in FW in AP mode

2019-07-24 Thread Greg Kroah-Hartman
From: Johannes Berg 

commit c56e00a3feaee2b46b7d33875fb7f52efd30241f upstream.

In AP (and IBSS) mode, we can only set GTKs to firmware after we have
sent down the multicast station, but this we can only do after we've
enabled beaconing, etc.

However, during rfkill exit, hostapd will configure the keys before
starting the AP, and cfg80211/mac80211 accept it happily.

On earlier devices, this didn't bother us as GTK TX wasn't really
handled in firmware, we just put the key material into the TX cmd
and thus it only mattered when we actually transmitted a frame.

On newer devices, however, the firmware needs to track all of this
and that doesn't work if we add the key before the (multicast) sta
it belongs to.

To fix this, keep a list of keys to add during AP enable, and call
the function there.

Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |   53 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  |3 +
 2 files changed, 54 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -207,6 +207,12 @@ static const struct cfg80211_pmsr_capabi
},
 };
 
+static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
+  enum set_key_cmd cmd,
+  struct ieee80211_vif *vif,
+  struct ieee80211_sta *sta,
+  struct ieee80211_key_conf *key);
+
 void iwl_mvm_ref(struct iwl_mvm *mvm, enum iwl_mvm_ref_type ref_type)
 {
if (!iwl_mvm_is_d0i3_supported(mvm))
@@ -2535,7 +2541,7 @@ static int iwl_mvm_start_ap_ibss(struct
 {
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
-   int ret;
+   int ret, i;
 
/*
 * iwl_mvm_mac_ctxt_add() might read directly from the device
@@ -2609,6 +2615,20 @@ static int iwl_mvm_start_ap_ibss(struct
/* must be set before quota calculations */
mvmvif->ap_ibss_active = true;
 
+   /* send all the early keys to the device now */
+   for (i = 0; i < ARRAY_SIZE(mvmvif->ap_early_keys); i++) {
+   struct ieee80211_key_conf *key = mvmvif->ap_early_keys[i];
+
+   if (!key)
+   continue;
+
+   mvmvif->ap_early_keys[i] = NULL;
+
+   ret = iwl_mvm_mac_set_key(hw, SET_KEY, vif, NULL, key);
+   if (ret)
+   goto out_quota_failed;
+   }
+
if (vif->type == NL80211_IFTYPE_AP && !vif->p2p) {
iwl_mvm_vif_set_low_latency(mvmvif, true,
LOW_LATENCY_VIF_TYPE);
@@ -3378,11 +3398,12 @@ static int iwl_mvm_mac_set_key(struct ie
   struct ieee80211_sta *sta,
   struct ieee80211_key_conf *key)
 {
+   struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
struct iwl_mvm_sta *mvmsta;
struct iwl_mvm_key_pn *ptk_pn;
int keyidx = key->keyidx;
-   int ret;
+   int ret, i;
u8 key_offset;
 
if (iwlwifi_mod_params.swcrypto) {
@@ -3455,6 +3476,22 @@ static int iwl_mvm_mac_set_key(struct ie
key->hw_key_idx = STA_KEY_IDX_INVALID;
break;
}
+
+   if (!mvmvif->ap_ibss_active) {
+   for (i = 0;
+i < ARRAY_SIZE(mvmvif->ap_early_keys);
+i++) {
+   if (!mvmvif->ap_early_keys[i]) {
+   mvmvif->ap_early_keys[i] = key;
+   break;
+   }
+   }
+
+   if (i >= ARRAY_SIZE(mvmvif->ap_early_keys))
+   ret = -ENOSPC;
+
+   break;
+   }
}
 
/* During FW restart, in order to restore the state as it was,
@@ -3523,6 +3560,18 @@ static int iwl_mvm_mac_set_key(struct ie
 
break;
case DISABLE_KEY:
+   ret = -ENOENT;
+   for (i = 0; i < ARRAY_SIZE(mvmvif->ap_early_keys); i++) {
+   if (mvmvif->ap_early_keys[i] == key) {
+   mvmvif->ap_early_keys[i] = NULL;
+   ret = 0;
+   }
+   }
+
+   /* found in pending list - don't do anything else */
+   if (ret == 0)
+   break;
+
if (key->hw_key_idx == STA_KEY_IDX_INVA

[PATCH 5.1 281/371] pnfs: Fix a problem where we gratuitously start doing I/O through the MDS

2019-07-24 Thread Greg Kroah-Hartman
From: Trond Myklebust 

commit 58bbeab425c6c5e318f5b6ae31d351331ddfb34b upstream.

If the client has to stop in pnfs_update_layout() to wait for another
layoutget to complete, it currently exits and defaults to I/O through
the MDS if the layoutget was successful.

Fixes: d03360aaf5cc ("pNFS: Ensure we return the error if someone kills...")
Signed-off-by: Trond Myklebust 
Cc: sta...@vger.kernel.org # v4.20+
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1890,7 +1890,7 @@ lookup_again:
spin_unlock(&ino->i_lock);
lseg = ERR_PTR(wait_var_event_killable(&lo->plh_outstanding,
!atomic_read(&lo->plh_outstanding)));
-   if (IS_ERR(lseg) || !list_empty(&lo->plh_segs))
+   if (IS_ERR(lseg))
goto out_put_layout_hdr;
pnfs_put_layout_hdr(lo);
goto lookup_again;




[PATCH 5.1 286/371] raid5-cache: Need to do start() part job after adding journal device

2019-07-24 Thread Greg Kroah-Hartman
From: Xiao Ni 

commit d9771f5ec46c282d518b453c793635dbdc3a2a94 upstream.

commit d5d885fd514f ("md: introduce new personality funciton start()")
splits the init job to two parts. The first part run() does the jobs that
do not require the md threads. The second part start() does the jobs that
require the md threads.

Now it just does run() in adding new journal device. It needs to do the
second part start() too.

Fixes: d5d885fd514f ("md: introduce new personality funciton start()")
Cc: sta...@vger.kernel.org #v4.9+
Reported-by: Michal Soltys 
Signed-off-by: Xiao Ni 
Signed-off-by: Song Liu 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid5.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7674,7 +7674,7 @@ abort:
 static int raid5_add_disk(struct mddev *mddev, struct md_rdev *rdev)
 {
struct r5conf *conf = mddev->private;
-   int err = -EEXIST;
+   int ret, err = -EEXIST;
int disk;
struct disk_info *p;
int first = 0;
@@ -7689,7 +7689,14 @@ static int raid5_add_disk(struct mddev *
 * The array is in readonly mode if journal is missing, so no
 * write requests running. We should be safe
 */
-   log_init(conf, rdev, false);
+   ret = log_init(conf, rdev, false);
+   if (ret)
+   return ret;
+
+   ret = r5l_start(conf->log);
+   if (ret)
+   return ret;
+
return 0;
}
if (mddev->recovery_disabled == conf->recovery_disabled)




Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading

2019-07-24 Thread Saeed Mahameed
On Mon, 2019-04-29 at 12:03 +, Jeroen Hofstee wrote:
> As already mentioned in [1] and included in [2], there is an off by
> one
> issue since the high bank is already enabled when the _next_ mailbox
> to
> be read has index 12, so the mailbox being read was 13. The message
> can
> therefore go into mailbox 31 and the driver will be repolled until
> the
> mailbox 12 eventually receives a msg. Or the message might end up in
> the
> 12th mailbox, but then it would become disabled after reading it and
> only
> be enabled again in the next "round" after mailbox 13 was read, which
> can
> cause out of order messages, since the lower priority mailboxes can
> accept messages in the meantime.
> 
> As mentioned in [3] there is a hardware race condition when changing
> the
> CANME register while messages are being received. Even when including
> a
> busy poll on reception, like in [2] there are still overflows and out
> of
> order messages at times, but less then without the busy loop polling.
> Unlike what the patch suggests, the polling time is not in the
> microsecond
> range, but takes as long as a current CAN bus reception needs to
> finish,
> so typically more in the fraction of millisecond range. Since the
> timeout
> is in jiffies it won't timeout.
> 
> Even with these additional fixes the driver is still not able to
> provide a
> proper FIFO which doesn't drop packages. So change the driver to use
> rx-offload and base order on timestamp instead of message box
> numbers. As
> a side affect, this also fixes [4] and [5].
> 
> Before this change messages with a single byte counter were dropped /
> received out of order at a bitrate of 250kbit/s on an am3517. With
> this
> patch that no longer occurs up to and including 1Mbit/s.
> 
> [1] 
> https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
> [2] 
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
> [3] 
> https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
> [4] https://patchwork.ozlabs.org/patch/895956/
> [5] https://www.spinics.net/lists/netdev/msg494971.html
> 
> Cc: Anant Gole 
> Cc: AnilKumar Ch 
> Signed-off-by: Jeroen Hofstee 
> ---
>  drivers/net/can/ti_hecc.c | 189 +---
> --
>  1 file changed, 53 insertions(+), 136 deletions(-)
> 
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index db6ea93..fe7 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -5,6 +5,7 @@
>   * specs for the same is available at 
>   *
>   * Copyright (C) 2009 Texas Instruments Incorporated - 
> http://www.ti.com/
> + * Copyright (C) 2019 Jeroen Hofstee 
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -34,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRV_NAME "ti_hecc"
>  #define HECC_MODULE_VERSION "0.7"
> @@ -63,29 +65,16 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>  #define HECC_TX_PRIO_MASK(MAX_TX_PRIO << HECC_MB_TX_SHIFT)
>  #define HECC_TX_MB_MASK  (HECC_MAX_TX_MBOX - 1)
>  #define HECC_TX_MASK ((HECC_MAX_TX_MBOX - 1) |
> HECC_TX_PRIO_MASK)
> -#define HECC_TX_MBOX_MASK(~(BIT(HECC_MAX_TX_MBOX) - 1))
> -#define HECC_DEF_NAPI_WEIGHT HECC_MAX_RX_MBOX
>  
>  /*
> - * Important Note: RX mailbox configuration
> - * RX mailboxes are further logically split into two - main and
> buffer
> - * mailboxes. The goal is to get all packets into main mailboxes as
> - * driven by mailbox number and receive priority (higher to lower)
> and
> - * buffer mailboxes are used to receive pkts while main mailboxes
> are being
> - * processed. This ensures in-order packet reception.
> - *
> - * Here are the recommended values for buffer mailbox. Note that RX
> mailboxes
> - * start after TX mailboxes:
> - *
> - * HECC_MAX_RX_MBOX  HECC_RX_BUFFER_MBOX No of buffer
> mailboxes
> - * 2812  8
> - * 1620  4
> + * RX mailbox configuration
> + * The remaining mailboxes are used for reception and are delivered
> based on
> + * their timestamp, to avoid a hardware race when CANME is changed
> while
> + * CAN-bus traffix is being received.
>   */
>  
>  #define HECC_MAX_RX_MBOX (HECC_MAX_MAILBOXES - HECC_MAX_TX_MBOX)
> -#define HECC_RX_BUFFER_MBOX  12 /* as per table above */
>  #define HECC_RX_FIRST_MBOX   (HECC_MAX_MAILBOXES - 1)
> -#define HECC_RX_HIGH_MBOX_MASK   (~(BIT(HECC_RX_BUFFER_MBOX) -
> 1))
>  
>  /* TI HECC module registers */
>  #define HECC_CANME   0x0 /* Mailbox enable */
> @@ -123,6 +112,8 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>  #define HECC_CANMDL  0x8
>  #define HECC_CANMDH  0xC
>  
> +#define HECC_CANMOTS

[PATCH 5.1 280/371] pnfs/flexfiles: Fix PTR_ERR() dereferences in ff_layout_track_ds_error

2019-07-24 Thread Greg Kroah-Hartman
From: Trond Myklebust 

commit 8e04fdfadda75a849c649f7e50fe7d97772e1fcb upstream.

mirror->mirror_ds can be NULL if uninitialised, but can contain
a PTR_ERR() if call to GETDEVICEINFO failed.

Fixes: 65990d1afbd2 ("pNFS/flexfiles: Fix a deadlock on LAYOUTGET")
Signed-off-by: Trond Myklebust 
Cc: sta...@vger.kernel.org # 4.10+
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -257,7 +257,7 @@ int ff_layout_track_ds_error(struct nfs4
if (status == 0)
return 0;
 
-   if (mirror->mirror_ds == NULL)
+   if (IS_ERR_OR_NULL(mirror->mirror_ds))
return -EINVAL;
 
dserr = kmalloc(sizeof(*dserr), gfp_flags);




[PATCH 5.1 277/371] arm64: Fix interrupt tracing in the presence of NMIs

2019-07-24 Thread Greg Kroah-Hartman
From: Julien Thierry 

commit 17ce302f3117e9518395847a3120c8a108b587b8 upstream.

In the presence of any form of instrumentation, nmi_enter() should be
done before calling any traceable code and any instrumentation code.

Currently, nmi_enter() is done in handle_domain_nmi(), which is much
too late as instrumentation code might get called before. Move the
nmi_enter/exit() calls to the arch IRQ vector handler.

On arm64, it is not possible to know if the IRQ vector handler was
called because of an NMI before acknowledging the interrupt. However, It
is possible to know whether normal interrupts could be taken in the
interrupted context (i.e. if taking an NMI in that context could
introduce a potential race condition).

When interrupting a context with IRQs disabled, call nmi_enter() as soon
as possible. In contexts with IRQs enabled, defer this to the interrupt
controller, which is in a better position to know if an interrupt taken
is an NMI.

Fixes: bc3c03ccb464 ("arm64: Enable the support of pseudo-NMIs")
Cc:  # 5.1.x-
Cc: Will Deacon 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Mark Rutland 
Reviewed-by: Marc Zyngier 
Signed-off-by: Julien Thierry 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/entry.S|   44 ---
 arch/arm64/kernel/irq.c  |   17 
 drivers/irqchip/irq-gic-v3.c |7 ++
 kernel/irq/irqdesc.c |8 +--
 4 files changed, 63 insertions(+), 13 deletions(-)

--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -420,6 +420,20 @@ tsk.reqx28 // current thread_info
irq_stack_exit
.endm
 
+#ifdef CONFIG_ARM64_PSEUDO_NMI
+   /*
+* Set res to 0 if irqs were unmasked in interrupted context.
+* Otherwise set res to non-0 value.
+*/
+   .macro  test_irqs_unmasked res:req, pmr:req
+alternative_if ARM64_HAS_IRQ_PRIO_MASKING
+   sub \res, \pmr, #GIC_PRIO_IRQON
+alternative_else
+   mov \res, xzr
+alternative_endif
+   .endm
+#endif
+
.text
 
 /*
@@ -616,19 +630,19 @@ ENDPROC(el1_sync)
 el1_irq:
kernel_entry 1
enable_da_f
-#ifdef CONFIG_TRACE_IRQFLAGS
+
 #ifdef CONFIG_ARM64_PSEUDO_NMI
 alternative_if ARM64_HAS_IRQ_PRIO_MASKING
ldr x20, [sp, #S_PMR_SAVE]
-alternative_else
-   mov x20, #GIC_PRIO_IRQON
-alternative_endif
-   cmp x20, #GIC_PRIO_IRQOFF
-   /* Irqs were disabled, don't trace */
-   b.ls1f
+alternative_else_nop_endif
+   test_irqs_unmasked  res=x0, pmr=x20
+   cbz x0, 1f
+   bl  asm_nmi_enter
+1:
 #endif
+
+#ifdef CONFIG_TRACE_IRQFLAGS
bl  trace_hardirqs_off
-1:
 #endif
 
irq_handler
@@ -647,14 +661,22 @@ alternative_else_nop_endif
bl  preempt_schedule_irq// irq en/disable is done inside
 1:
 #endif
-#ifdef CONFIG_TRACE_IRQFLAGS
+
 #ifdef CONFIG_ARM64_PSEUDO_NMI
/*
 * if IRQs were disabled when we received the interrupt, we have an NMI
 * and we are not re-enabling interrupt upon eret. Skip tracing.
 */
-   cmp x20, #GIC_PRIO_IRQOFF
-   b.ls1f
+   test_irqs_unmasked  res=x0, pmr=x20
+   cbz x0, 1f
+   bl  asm_nmi_exit
+1:
+#endif
+
+#ifdef CONFIG_TRACE_IRQFLAGS
+#ifdef CONFIG_ARM64_PSEUDO_NMI
+   test_irqs_unmasked  res=x0, pmr=x20
+   cbnzx0, 1f
 #endif
bl  trace_hardirqs_on
 1:
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -27,8 +27,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 unsigned long irq_err_count;
@@ -76,3 +78,18 @@ void __init init_IRQ(void)
if (!handle_arch_irq)
panic("No interrupt controller found.");
 }
+
+/*
+ * Stubs to make nmi_enter/exit() code callable from ASM
+ */
+asmlinkage void notrace asm_nmi_enter(void)
+{
+   nmi_enter();
+}
+NOKPROBE_SYMBOL(asm_nmi_enter);
+
+asmlinkage void notrace asm_nmi_exit(void)
+{
+   nmi_exit();
+}
+NOKPROBE_SYMBOL(asm_nmi_exit);
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -472,8 +472,12 @@ static void gic_deactivate_unhandled(u32
 
 static inline void gic_handle_nmi(u32 irqnr, struct pt_regs *regs)
 {
+   bool irqs_enabled = interrupts_enabled(regs);
int err;
 
+   if (irqs_enabled)
+   nmi_enter();
+
if (static_branch_likely(&supports_deactivate_key))
gic_write_eoir(irqnr);
/*
@@ -485,6 +489,9 @@ static inline void gic_handle_nmi(u32 ir
err = handle_domain_nmi(gic_data.domain, irqnr, regs);
if (err)
gic_deactivate_unhandled(irqnr);
+
+   if (irqs_enabled)
+   nmi_exit();
 }
 
 static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs 
*regs)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -679,6 +679,8 @@ int __handle_domain_irq(stru

[PATCH 5.1 282/371] SUNRPC: Ensure the bvecs are reset when we re-encode the RPC request

2019-07-24 Thread Greg Kroah-Hartman
From: Trond Myklebust 

commit 75369089820473eac45e9ddd970081901a373c08 upstream.

The bvec tracks the list of pages, so if the number of pages changes
due to a re-encode, we need to reset the bvec as well.

Fixes: 277e4ab7d530 ("SUNRPC: Simplify TCP receive code by switching...")
Signed-off-by: Trond Myklebust 
Cc: sta...@vger.kernel.org # v4.20+
Signed-off-by: Greg Kroah-Hartman 

---
 net/sunrpc/clnt.c |3 +--
 net/sunrpc/xprt.c |2 ++
 net/sunrpc/xprtsock.c |1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1767,6 +1767,7 @@ rpc_xdr_encode(struct rpc_task *task)
req->rq_snd_buf.head[0].iov_len = 0;
xdr_init_encode(&xdr, &req->rq_snd_buf,
req->rq_snd_buf.head[0].iov_base, req);
+   xdr_free_bvec(&req->rq_snd_buf);
if (rpc_encode_header(task, &xdr))
return;
 
@@ -1799,8 +1800,6 @@ call_encode(struct rpc_task *task)
rpc_exit(task, task->tk_status);
}
return;
-   } else {
-   xprt_request_prepare(task->tk_rqstp);
}
 
/* Add task to reply queue before transmission to avoid races */
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1006,6 +1006,8 @@ xprt_request_enqueue_receive(struct rpc_
 
if (!xprt_request_need_enqueue_receive(task, req))
return;
+
+   xprt_request_prepare(task->tk_rqstp);
spin_lock(&xprt->queue_lock);
 
/* Update the softirq receive buffer */
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -909,6 +909,7 @@ static int xs_nospace(struct rpc_rqst *r
 static void
 xs_stream_prepare_request(struct rpc_rqst *req)
 {
+   xdr_free_bvec(&req->rq_rcv_buf);
req->rq_task->tk_status = xdr_alloc_bvec(&req->rq_rcv_buf, GFP_KERNEL);
 }
 




[PATCH 5.1 254/371] cifs: flush before set-info if we have writeable handles

2019-07-24 Thread Greg Kroah-Hartman
From: Ronnie Sahlberg 

commit aa081859b10c5d8b19f5c525c78883a59d73c2b8 upstream.

Servers can defer destaging any data and updating the mtime until close().
This means that if we do a setinfo to modify the mtime while other handles
are open for write the server may overwrite our setinfo timestamps when
if flushes the file on close() of the writeable handle.

To solve this we add an explicit flush when the mtime is about to
be updated.

This fixes "cp -p" to preserve mtime when copying a file onto an SMB2 share.

CC: Stable 
Signed-off-by: Ronnie Sahlberg 
Reviewed-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/cifs/inode.c |   16 
 1 file changed, 16 insertions(+)

--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -2371,6 +2371,8 @@ cifs_setattr_nounix(struct dentry *diren
struct inode *inode = d_inode(direntry);
struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
struct cifsInodeInfo *cifsInode = CIFS_I(inode);
+   struct cifsFileInfo *wfile;
+   struct cifs_tcon *tcon;
char *full_path = NULL;
int rc = -EACCES;
__u32 dosattr = 0;
@@ -2417,6 +2419,20 @@ cifs_setattr_nounix(struct dentry *diren
mapping_set_error(inode->i_mapping, rc);
rc = 0;
 
+   if (attrs->ia_valid & ATTR_MTIME) {
+   rc = cifs_get_writable_file(cifsInode, false, &wfile);
+   if (!rc) {
+   tcon = tlink_tcon(wfile->tlink);
+   rc = tcon->ses->server->ops->flush(xid, tcon, 
&wfile->fid);
+   cifsFileInfo_put(wfile);
+   if (rc)
+   return rc;
+   } else if (rc != -EBADF)
+   return rc;
+   else
+   rc = 0;
+   }
+
if (attrs->ia_valid & ATTR_SIZE) {
rc = cifs_set_file_size(inode, attrs, xid, full_path);
if (rc != 0)




[PATCH 5.1 279/371] Revert "NFS: readdirplus optimization by cache mechanism" (memleak)

2019-07-24 Thread Greg Kroah-Hartman
From: Max Kellermann 

commit db531db951f950b86d274cc8ed7b21b9e2240036 upstream.

This reverts commit be4c2d4723a4a637f0d1b4f7c66447141a4b3564.

That commit caused a severe memory leak in nfs_readdir_make_qstr().

When listing a directory with more than 100 files (this is how many
struct nfs_cache_array_entry elements fit in one 4kB page), all
allocated file name strings past those 100 leak.

The root of the leakage is that those string pointers are managed in
pages which are never linked into the page cache.

fs/nfs/dir.c puts pages into the page cache by calling
read_cache_page(); the callback function nfs_readdir_filler() will
then fill the given page struct which was passed to it, which is
already linked in the page cache (by do_read_cache_page() calling
add_to_page_cache_lru()).

Commit be4c2d4723a4 added another (local) array of allocated pages, to
be filled with more data, instead of discarding excess items received
from the NFS server.  Those additional pages can be used by the next
nfs_readdir_filler() call (from within the same nfs_readdir() call).

The leak happens when some of those additional pages are never used
(copied to the page cache using copy_highpage()).  The pages will be
freed by nfs_readdir_free_pages(), but their contents will not.  The
commit did not invoke nfs_readdir_clear_array() (and doing so would
have been dangerous, because it did not track which of those pages
were already copied to the page cache, risking double free bugs).

How to reproduce the leak:

- Use a kernel with CONFIG_SLUB_DEBUG_ON.

- Create a directory on a NFS mount with more than 100 files with
  names long enough to use the "kmalloc-32" slab (so we can easily
  look up the allocation counts):

  for i in `seq 110`; do touch ${i}_0123456789abcdef; done

- Drop all caches:

  echo 3 >/proc/sys/vm/drop_caches

- Check the allocation counter:

  grep nfs_readdir /sys/kernel/slab/kmalloc-32/alloc_calls
  30564391 nfs_readdir_add_to_array+0x73/0xd0 age=534558/4791307/6540952 
pid=370-1048386 cpus=0-47 nodes=0-1

- Request a directory listing and check the allocation counters again:

  ls
  [...]
  grep nfs_readdir /sys/kernel/slab/kmalloc-32/alloc_calls
  30564511 nfs_readdir_add_to_array+0x73/0xd0 age=207/4792999/6542663 
pid=370-1048386 cpus=0-47 nodes=0-1

There are now 120 new allocations.

- Drop all caches and check the counters again:

  echo 3 >/proc/sys/vm/drop_caches
  grep nfs_readdir /sys/kernel/slab/kmalloc-32/alloc_calls
  30564401 nfs_readdir_add_to_array+0x73/0xd0 age=735/4793524/6543176 
pid=370-1048386 cpus=0-47 nodes=0-1

110 allocations are gone, but 10 have leaked and will never be freed.

Unhelpfully, those allocations are explicitly excluded from KMEMLEAK,
that's why my initial attempts with KMEMLEAK were not successful:

/*
 * Avoid a kmemleak false positive. The pointer to the name is stored
 * in a page cache page which kmemleak does not scan.
 */
kmemleak_not_leak(string->name);

It would be possible to solve this bug without reverting the whole
commit:

- keep track of which pages were not used, and call
  nfs_readdir_clear_array() on them, or
- manually link those pages into the page cache

But for now I have decided to just revert the commit, because the real
fix would require complex considerations, risking more dangerous
(crash) bugs, which may seem unsuitable for the stable branches.

Signed-off-by: Max Kellermann 
Cc: sta...@vger.kernel.org # v5.1+
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/dir.c  |   90 +++---
 fs/nfs/internal.h |3 -
 2 files changed, 7 insertions(+), 86 deletions(-)

--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -139,19 +139,12 @@ struct nfs_cache_array {
struct nfs_cache_array_entry array[0];
 };
 
-struct readdirvec {
-   unsigned long nr;
-   unsigned long index;
-   struct page *pages[NFS_MAX_READDIR_RAPAGES];
-};
-
 typedef int (*decode_dirent_t)(struct xdr_stream *, struct nfs_entry *, bool);
 typedef struct {
struct file *file;
struct page *page;
struct dir_context *ctx;
unsigned long   page_index;
-   struct readdirvec pvec;
u64 *dir_cookie;
u64 last_cookie;
loff_t  current_index;
@@ -531,10 +524,6 @@ int nfs_readdir_page_filler(nfs_readdir_
struct nfs_cache_array *array;
unsigned int count = 0;
int status;
-   int max_rapages = NFS_MAX_READDIR_RAPAGES;
-
-   desc->pvec.index = desc->page_index;
-   desc->pvec.nr = 0;
 
scratch = alloc_page(GFP_KERNEL);
if (scratch == NULL)
@@ -559,40 +548,20 @@ int nfs_readdir_page_filler(nfs_readdir_
if (desc->plus)
nfs_prime_dcache(file_dentry(desc->file), entry);
 
-   status = nfs_readdir_add_to_array(entry, 
desc->pvec.pages[desc->pvec.nr]);
-   if (status

[PATCH 5.1 294/371] media: v4l2: Test type instead of cfg->type in v4l2_ctrl_new_custom()

2019-07-24 Thread Greg Kroah-Hartman
From: Boris Brezillon 

commit 07d89227a983df957a6a7c56f7c040cde9ac571f upstream.

cfg->type can be overridden by v4l2_ctrl_fill() and the new value is
stored in the local type var. Fix the tests to use this local var.

Fixes: 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework")
Cc: 
Signed-off-by: Boris Brezillon 
[hverkuil-ci...@xs4all.nl: change to !qmenu and !qmenu_int (checkpatch)]
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/v4l2-core/v4l2-ctrls.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2365,16 +2365,15 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(s
v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max, &step,
&def, &flags);
 
-   is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU ||
-  cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU);
+   is_menu = (type == V4L2_CTRL_TYPE_MENU ||
+  type == V4L2_CTRL_TYPE_INTEGER_MENU);
if (is_menu)
WARN_ON(step);
else
WARN_ON(cfg->menu_skip_mask);
-   if (cfg->type == V4L2_CTRL_TYPE_MENU && qmenu == NULL)
+   if (type == V4L2_CTRL_TYPE_MENU && !qmenu) {
qmenu = v4l2_ctrl_get_menu(cfg->id);
-   else if (cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU &&
-qmenu_int == NULL) {
+   } else if (type == V4L2_CTRL_TYPE_INTEGER_MENU && !qmenu_int) {
handler_set_err(hdl, -EINVAL);
return NULL;
}




[PATCH 5.1 293/371] ceph: fix end offset in truncate_inode_pages_range call

2019-07-24 Thread Greg Kroah-Hartman
From: Luis Henriques 

commit d31d07b97a5e76f41e00eb81dcca740e84aa7782 upstream.

Commit e450f4d1a5d6 ("ceph: pass inclusive lend parameter to
filemap_write_and_wait_range()") fixed the end offset parameter used to
call filemap_write_and_wait_range and invalidate_inode_pages2_range.
Unfortunately it missed truncate_inode_pages_range, introducing a
regression that is easily detected by xfstest generic/130.

The problem is that when doing direct IO it is possible that an extra page
is truncated from the page cache when the end offset is page aligned.
This can cause data loss if that page hasn't been sync'ed to the OSDs.

While there, change code to use PAGE_ALIGN macro instead.

Cc: sta...@vger.kernel.org
Fixes: e450f4d1a5d6 ("ceph: pass inclusive lend parameter to 
filemap_write_and_wait_range()")
Signed-off-by: Luis Henriques 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -1006,7 +1006,7 @@ ceph_direct_read_write(struct kiocb *ioc
 * may block.
 */
truncate_inode_pages_range(inode->i_mapping, pos,
-   (pos+len) | (PAGE_SIZE - 1));
+  PAGE_ALIGN(pos + len) - 1);
 
req->r_mtime = mtime;
}




[PATCH 5.1 258/371] bcache: Revert "bcache: free heap cache_set->flush_btree in bch_journal_free"

2019-07-24 Thread Greg Kroah-Hartman
From: Coly Li 

commit ba82c1ac1667d6efb91a268edb13fc9cdaecec9b upstream.

This reverts commit 6268dc2c4703aabfb0b35681be709acf4c2826c6.

This patch depends on commit c4dc2497d50d ("bcache: fix high CPU
occupancy during journal") which is reverted in previous patch. So
revert this one too.

Fixes: 6268dc2c4703 ("bcache: free heap cache_set->flush_btree in 
bch_journal_free")
Signed-off-by: Coly Li 
Cc: sta...@vger.kernel.org
Cc: Shenghui Wang 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/journal.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -842,7 +842,6 @@ void bch_journal_free(struct cache_set *
free_pages((unsigned long) c->journal.w[1].data, JSET_BITS);
free_pages((unsigned long) c->journal.w[0].data, JSET_BITS);
free_fifo(&c->journal.pin);
-   free_heap(&c->flush_btree);
 }
 
 int bch_journal_alloc(struct cache_set *c)




[PATCH 5.1 306/371] arm64: tegra: Fix AGIC register range

2019-07-24 Thread Greg Kroah-Hartman
From: Jon Hunter 

commit ba24eee6686f6ed3738602b54d959253316a9541 upstream.

The Tegra AGIC interrupt controller is an ARM GIC400 interrupt
controller. Per the ARM GIC device-tree binding, the first address
region is for the GIC distributor registers and the second address
region is for the GIC CPU interface registers. The address space for
the distributor registers is 4kB, but currently this is incorrectly
defined as 8kB for the Tegra AGIC and overlaps with the CPU interface
registers. Correct the address space for the distributor to be 4kB.

Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter 
Fixes: bcdbde433542 ("arm64: tegra: Add AGIC node for Tegra210")
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1250,7 +1250,7 @@
compatible = "nvidia,tegra210-agic";
#interrupt-cells = <3>;
interrupt-controller;
-   reg = <0x702f9000 0x2000>,
+   reg = <0x702f9000 0x1000>,
  <0x702fa000 0x2000>;
interrupts = ;
clocks = <&tegra_car TEGRA210_CLK_APE>;




[PATCH 5.1 251/371] cifs: always add credits back for unsolicited PDUs

2019-07-24 Thread Greg Kroah-Hartman
From: Ronnie Sahlberg 

commit 3e2725796cbdfe4efc7eb7b27cacaeac2ddad1a5 upstream.

not just if CONFIG_CIFS_DEBUG2 is enabled.

Signed-off-by: Ronnie Sahlberg 
Reviewed-by: Pavel Shilovsky 
CC: Stable 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1221,11 +1221,11 @@ next_pdu:
 atomic_read(&midCount));
cifs_dump_mem("Received Data is: ", bufs[i],
  HEADER_SIZE(server));
+   smb2_add_credits_from_hdr(bufs[i], server);
 #ifdef CONFIG_CIFS_DEBUG2
if (server->ops->dump_detail)
server->ops->dump_detail(bufs[i],
 server);
-   smb2_add_credits_from_hdr(bufs[i], server);
cifs_dump_mids(server);
 #endif /* CIFS_DEBUG2 */
}




[PATCH 5.1 309/371] signal: Correct namespace fixups of si_pid and si_uid

2019-07-24 Thread Greg Kroah-Hartman
From: Eric W. Biederman 

commit 7a0cf094944e2540758b7f957eb6846d5126f535 upstream.

The function send_signal was split from __send_signal so that it would
be possible to bypass the namespace logic based upon current[1].  As it
turns out the si_pid and the si_uid fixup are both inappropriate in
the case of kill_pid_usb_asyncio so move that logic into send_signal.

It is difficult to arrange but possible for a signal with an si_code
of SI_TIMER or SI_SIGIO to be sent across namespace boundaries.  In
which case tests for when it is ok to change si_pid and si_uid based
on SI_FROMUSER are incorrect.  Replace the use of SI_FROMUSER with a
new test has_si_pid_and_used based on siginfo_layout.

Now that the uid fixup is no longer present after expanding
SEND_SIG_NOINFO properly calculate the si_uid that the target
task needs to read.

[1] 7978b567d315 ("signals: add from_ancestor_ns parameter to send_signal()")
Cc: sta...@vger.kernel.org
Fixes: 6588c1e3ff01 ("signals: SI_USER: Masquerade si_pid when crossing pid ns 
boundary")
Fixes: 6b550f949594 ("user namespace: make signal.c respect user namespaces")
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/signal.c |   67 +---
 1 file changed, 40 insertions(+), 27 deletions(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1053,27 +1053,6 @@ static inline bool legacy_queue(struct s
return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
 }
 
-#ifdef CONFIG_USER_NS
-static inline void userns_fixup_signal_uid(struct kernel_siginfo *info, struct 
task_struct *t)
-{
-   if (current_user_ns() == task_cred_xxx(t, user_ns))
-   return;
-
-   if (SI_FROMKERNEL(info))
-   return;
-
-   rcu_read_lock();
-   info->si_uid = from_kuid_munged(task_cred_xxx(t, user_ns),
-   make_kuid(current_user_ns(), 
info->si_uid));
-   rcu_read_unlock();
-}
-#else
-static inline void userns_fixup_signal_uid(struct kernel_siginfo *info, struct 
task_struct *t)
-{
-   return;
-}
-#endif
-
 static int __send_signal(int sig, struct kernel_siginfo *info, struct 
task_struct *t,
enum pid_type type, int from_ancestor_ns)
 {
@@ -1131,7 +1110,11 @@ static int __send_signal(int sig, struct
q->info.si_code = SI_USER;
q->info.si_pid = task_tgid_nr_ns(current,
task_active_pid_ns(t));
-   q->info.si_uid = from_kuid_munged(current_user_ns(), 
current_uid());
+   rcu_read_lock();
+   q->info.si_uid =
+   from_kuid_munged(task_cred_xxx(t, user_ns),
+current_uid());
+   rcu_read_unlock();
break;
case (unsigned long) SEND_SIG_PRIV:
clear_siginfo(&q->info);
@@ -1143,13 +1126,8 @@ static int __send_signal(int sig, struct
break;
default:
copy_siginfo(&q->info, info);
-   if (from_ancestor_ns)
-   q->info.si_pid = 0;
break;
}
-
-   userns_fixup_signal_uid(&q->info, t);
-
} else if (!is_si_special(info)) {
if (sig >= SIGRTMIN && info->si_code != SI_USER) {
/*
@@ -1193,6 +1171,28 @@ ret:
return ret;
 }
 
+static inline bool has_si_pid_and_uid(struct kernel_siginfo *info)
+{
+   bool ret = false;
+   switch (siginfo_layout(info->si_signo, info->si_code)) {
+   case SIL_KILL:
+   case SIL_CHLD:
+   case SIL_RT:
+   ret = true;
+   break;
+   case SIL_TIMER:
+   case SIL_POLL:
+   case SIL_FAULT:
+   case SIL_FAULT_MCEERR:
+   case SIL_FAULT_BNDERR:
+   case SIL_FAULT_PKUERR:
+   case SIL_SYS:
+   ret = false;
+   break;
+   }
+   return ret;
+}
+
 static int send_signal(int sig, struct kernel_siginfo *info, struct 
task_struct *t,
enum pid_type type)
 {
@@ -1202,7 +1202,20 @@ static int send_signal(int sig, struct k
from_ancestor_ns = si_fromuser(info) &&
   !task_pid_nr_ns(current, task_active_pid_ns(t));
 #endif
+   if (!is_si_special(info) && has_si_pid_and_uid(info)) {
+   struct user_namespace *t_user_ns;
+
+   rcu_read_lock();
+   t_user_ns = task_cred_xxx(t, user_ns);
+   if (current_user_ns() != t_user_ns) {
+   kuid_t uid = make_kuid(current_user_ns(), info->si_uid);
+   info->si_uid = from_kuid_munged(t_user_ns, uid);
+   }
+   rcu_read_unlock();
 
+   if (!task_pid_nr_ns(current, task_ac

[PATCH 5.1 308/371] signal/usb: Replace kill_pid_info_as_cred with kill_pid_usb_asyncio

2019-07-24 Thread Greg Kroah-Hartman
From: Eric W. Biederman 

commit 70f1b0d34bdf03065fe869e93cc17cad1ea20c4a upstream.

The usb support for asyncio encoded one of it's values in the wrong
field.  It should have used si_value but instead used si_addr which is
not present in the _rt union member of struct siginfo.

The practical result of this is that on a 64bit big endian kernel
when delivering a signal to a 32bit process the si_addr field
is set to NULL, instead of the expected pointer value.

This issue can not be fixed in copy_siginfo_to_user32 as the usb
usage of the the _sigfault (aka si_addr) member of the siginfo
union when SI_ASYNCIO is set is incompatible with the POSIX and
glibc usage of the _rt member of the siginfo union.

Therefore replace kill_pid_info_as_cred with kill_pid_usb_asyncio a
dedicated function for this one specific case.  There are no other
users of kill_pid_info_as_cred so this specialization should have no
impact on the amount of code in the kernel.  Have kill_pid_usb_asyncio
take instead of a siginfo_t which is difficult and error prone, 3
arguments, a signal number, an errno value, and an address enconded as
a sigval_t.  The encoding of the address as a sigval_t allows the
code that reads the userspace request for a signal to handle this
compat issue along with all of the other compat issues.

Add BUILD_BUG_ONs in kernel/signal.c to ensure that we can now place
the pointer value at the in si_pid (instead of si_addr).  That is the
code now verifies that si_pid and si_addr always occur at the same
location.  Further the code veries that for native structures a value
placed in si_pid and spilling into si_uid will appear in userspace in
si_addr (on a byte by byte copy of siginfo or a field by field copy of
siginfo).  The code also verifies that for a 64bit kernel and a 32bit
userspace the 32bit pointer will fit in si_pid.

I have used the usbsig.c program below written by Alan Stern and
slightly tweaked by me to run on a big endian machine to verify the
issue exists (on sparc64) and to confirm the patch below fixes the issue.

 /* usbsig.c -- test USB async signal delivery */

 #define _GNU_SOURCE
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 

 static struct usbdevfs_urb urb;
 static struct usbdevfs_disconnectsignal ds;
 static volatile sig_atomic_t done = 0;

 void urb_handler(int sig, siginfo_t *info , void *ucontext)
 {
printf("Got signal %d, signo %d errno %d code %d addr: %p urb: %p\n",
   sig, info->si_signo, info->si_errno, info->si_code,
   info->si_addr, &urb);

printf("%s\n", (info->si_addr == &urb) ? "Good" : "Bad");
 }

 void ds_handler(int sig, siginfo_t *info , void *ucontext)
 {
printf("Got signal %d, signo %d errno %d code %d addr: %p ds: %p\n",
   sig, info->si_signo, info->si_errno, info->si_code,
   info->si_addr, &ds);

printf("%s\n", (info->si_addr == &ds) ? "Good" : "Bad");
done = 1;
 }

 int main(int argc, char **argv)
 {
char *devfilename;
int fd;
int rc;
struct sigaction act;
struct usb_ctrlrequest *req;
void *ptr;
char buf[80];

if (argc != 2) {
fprintf(stderr, "Usage: usbsig device-file-name\n");
return 1;
}

devfilename = argv[1];
fd = open(devfilename, O_RDWR);
if (fd == -1) {
perror("Error opening device file");
return 1;
}

act.sa_sigaction = urb_handler;
sigemptyset(&act.sa_mask);
act.sa_flags = SA_SIGINFO;

rc = sigaction(SIGUSR1, &act, NULL);
if (rc == -1) {
perror("Error in sigaction");
return 1;
}

act.sa_sigaction = ds_handler;
sigemptyset(&act.sa_mask);
act.sa_flags = SA_SIGINFO;

rc = sigaction(SIGUSR2, &act, NULL);
if (rc == -1) {
perror("Error in sigaction");
return 1;
}

memset(&urb, 0, sizeof(urb));
urb.type = USBDEVFS_URB_TYPE_CONTROL;
urb.endpoint = USB_DIR_IN | 0;
urb.buffer = buf;
urb.buffer_length = sizeof(buf);
urb.signr = SIGUSR1;

req = (struct usb_ctrlrequest *) buf;
req->bRequestType = USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE;
req->bRequest = USB_REQ_GET_DESCRIPTOR;
req->wValue = htole16(USB_DT_DEVICE << 8);
req->wIndex = htole16(0);
req->wLength = htole16(sizeof(buf) - sizeof(*req));

rc = ioctl(fd, USBDEVFS_SUBMITURB, &urb);
if (rc == -1) {
perror("Error in SUBMITURB ioctl");
return 1;
}

rc = ioctl(fd, USBDEVFS_REAPURB, &ptr);
if (rc == -1) {
perror("Error in REAPURB ioctl");
return 1;
}

memset(&ds, 0, sizeof(ds));
ds.signr = SIGUSR2;
ds.context = &ds;
rc

[PATCH 5.1 312/371] kconfig: fix missing choice values in auto.conf

2019-07-24 Thread Greg Kroah-Hartman
From: Masahiro Yamada 

commit 8e2442a5f86e1f77b86401fce274a7f622740bc4 upstream.

Since commit 00c864f8903d ("kconfig: allow all config targets to write
auto.conf if missing"), Kconfig creates include/config/auto.conf in the
defconfig stage when it is missing.

Joonas Kylmälä reported incorrect auto.conf generation under some
circumstances.

To reproduce it, apply the following diff:

|  --- a/arch/arm/configs/imx_v6_v7_defconfig
|  +++ b/arch/arm/configs/imx_v6_v7_defconfig
|  @@ -345,14 +345,7 @@ CONFIG_USB_CONFIGFS_F_MIDI=y
|   CONFIG_USB_CONFIGFS_F_HID=y
|   CONFIG_USB_CONFIGFS_F_UVC=y
|   CONFIG_USB_CONFIGFS_F_PRINTER=y
|  -CONFIG_USB_ZERO=m
|  -CONFIG_USB_AUDIO=m
|  -CONFIG_USB_ETH=m
|  -CONFIG_USB_G_NCM=m
|  -CONFIG_USB_GADGETFS=m
|  -CONFIG_USB_FUNCTIONFS=m
|  -CONFIG_USB_MASS_STORAGE=m
|  -CONFIG_USB_G_SERIAL=m
|  +CONFIG_USB_FUNCTIONFS=y
|   CONFIG_MMC=y
|   CONFIG_MMC_SDHCI=y
|   CONFIG_MMC_SDHCI_PLTFM=y

And then, run:

$ make ARCH=arm mrproper imx_v6_v7_defconfig

You will see CONFIG_USB_FUNCTIONFS=y is correctly contained in the
.config, but not in the auto.conf.

Please note drivers/usb/gadget/legacy/Kconfig is included from a choice
block in drivers/usb/gadget/Kconfig. So USB_FUNCTIONFS is a choice value.

This is probably a similar situation described in commit beaaddb62540
("kconfig: tests: test defconfig when two choices interact").

When sym_calc_choice() is called, the choice symbol forgets the
SYMBOL_DEF_USER unless all of its choice values are explicitly set by
the user.

The choice symbol is given just one chance to recall it because
set_all_choice_values() is called if SYMBOL_NEED_SET_CHOICE_VALUES
is set.

When sym_calc_choice() is called again, the choice symbol forgets it
forever, since SYMBOL_NEED_SET_CHOICE_VALUES is a one-time aid.
Hence, we cannot call sym_clear_all_valid() again and again.

It is crazy to repeat set and unset of internal flags. However, we
cannot simply get rid of "sym->flags &= flags | ~SYMBOL_DEF_USER;"
Doing so would re-introduce the problem solved by commit 5d09598d488f
("kconfig: fix new choices being skipped upon config update").

To work around the issue, conf_write_autoconf() stopped calling
sym_clear_all_valid().

conf_write() must be changed accordingly. Currently, it clears
SYMBOL_WRITE after the symbol is written into the .config file. This
is needed to prevent it from writing the same symbol multiple times in
case the symbol is declared in two or more locations. I added the new
flag SYMBOL_WRITTEN, to track the symbols that have been written.

Anyway, this is a cheesy workaround in order to suppress the issue
as far as defconfig is concerned.

Handling of choices is totally broken. sym_clear_all_valid() is called
every time a user touches a symbol from the GUI interface. To reproduce
it, just add a new symbol drivers/usb/gadget/legacy/Kconfig, then touch
around unrelated symbols from menuconfig. USB_FUNCTIONFS will disappear
from the .config file.

I added the Fixes tag since it is more fatal than before. But, this
has been broken since long long time before, and still it is.
We should take a closer look to fix this correctly somehow.

Fixes: 00c864f8903d ("kconfig: allow all config targets to write auto.conf if 
missing")
Cc: linux-stable  # 4.19+
Reported-by: Joonas Kylmälä 
Signed-off-by: Masahiro Yamada 
Tested-by: Joonas Kylmälä 
Signed-off-by: Greg Kroah-Hartman 

---
 scripts/kconfig/confdata.c |7 +++
 scripts/kconfig/expr.h |1 +
 2 files changed, 4 insertions(+), 4 deletions(-)

--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -871,11 +871,12 @@ int conf_write(const char *name)
 "#\n"
 "# %s\n"
 "#\n", str);
-   } else if (!(sym->flags & SYMBOL_CHOICE)) {
+   } else if (!(sym->flags & SYMBOL_CHOICE) &&
+  !(sym->flags & SYMBOL_WRITTEN)) {
sym_calc_value(sym);
if (!(sym->flags & SYMBOL_WRITE))
goto next;
-   sym->flags &= ~SYMBOL_WRITE;
+   sym->flags |= SYMBOL_WRITTEN;
 
conf_write_symbol(out, sym, &kconfig_printer_cb, NULL);
}
@@ -1026,8 +1027,6 @@ int conf_write_autoconf(int overwrite)
if (!overwrite && is_present(autoconf_name))
return 0;
 
-   sym_clear_all_valid();
-
conf_write_dep("include/config/auto.conf.cmd");
 
if (conf_touch_deps())
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -141,6 +141,7 @@ struct symbol {
 #define SYMBOL_OPTIONAL   0x0100  /* choice is optional - values can be 'n' */
 #define SYMBOL_WRITE  0x0200  /* write symbol to file (KCONFIG_CONFIG) */
 #define SYMBOL_CHANGED0x0400  /* ? */
+#define SYMBOL_WRITTEN0x0800  /* track info to avoid double-write to 
.config */
 #define SYMBOL_NO_WRITE   0x

[PATCH v10 5/5] overlayfs: override_creds=off option bypass creator_cred

2019-07-24 Thread Mark Salyzyn
By default, all access to the upper, lower and work directories is the
recorded mounter's MAC and DAC credentials.  The incoming accesses are
checked against the caller's credentials.

If the principles of least privilege are applied, the mounter's
credentials might not overlap the credentials of the caller's when
accessing the overlayfs filesystem.  For example, a file that a lower
DAC privileged caller can execute, is MAC denied to the generally
higher DAC privileged mounter, to prevent an attack vector.

We add the option to turn off override_creds in the mount options; all
subsequent operations after mount on the filesystem will be only the
caller's credentials.  The module boolean parameter and mount option
override_creds is also added as a presence check for this "feature",
existence of /sys/module/overlay/parameters/override_creds.

It was not always this way.  Circa 4.6 there was no recorded mounter's
credentials, instead privileged access to upper or work directories
were temporarily increased to perform the operations.  The MAC
(selinux) policies were caller's in all cases.  override_creds=off
partially returns us to this older access model minus the insecure
temporary credential increases.  This is to permit use in a system
with non-overlapping security models for each executable including
the agent that mounts the overlayfs filesystem.  In Android
this is the case since init, which performs the mount operations,
has a minimal MAC set of privileges to reduce any attack surface,
and services that use the content have a different set of MAC
privileges (eg: read, for vendor labelled configuration, execute for
vendor libraries and modules).  The caveats are not a problem in
the Android usage model, however they should be fixed for
completeness and for general use in time.

Signed-off-by: Mark Salyzyn 
Cc: Miklos Szeredi 
Cc: Jonathan Corbet 
Cc: Vivek Goyal 
Cc: Eric W. Biederman 
Cc: Amir Goldstein 
Cc: Randy Dunlap 
Cc: Stephen Smalley 
Cc: linux-unio...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel-t...@android.com
---
v10:
- Rebase (and expand because of increased revert_cred usage)

v9:
- Add to the caveats

v8:
- drop pr_warn message after straw poll to remove it.
- added a use case in the commit message

v7:
- change name of internal parameter to ovl_override_creds_def
- report override_creds only if different than default

v6:
- Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS.
- Do better with the documentation.
- pr_warn message adjusted to report consequences.

v5:
- beefed up the caveats in the Documentation
- Is dependent on
  "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh"
  "overlayfs: check CAP_MKNOD before issuing vfs_whiteout"
- Added prwarn when override_creds=off

v4:
- spelling and grammar errors in text

v3:
- Change name from caller_credentials / creator_credentials to the
  boolean override_creds.
- Changed from creator to mounter credentials.
- Updated and fortified the documentation.
- Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS

v2:
- Forward port changed attr to stat, resulting in a build error.
- altered commit message.

a
---
 Documentation/filesystems/overlayfs.txt | 23 +++
 fs/overlayfs/copy_up.c  |  2 +-
 fs/overlayfs/dir.c  | 11 ++-
 fs/overlayfs/file.c | 20 ++--
 fs/overlayfs/inode.c| 18 +-
 fs/overlayfs/namei.c|  6 +++---
 fs/overlayfs/overlayfs.h|  1 +
 fs/overlayfs/ovl_entry.h|  1 +
 fs/overlayfs/readdir.c  |  4 ++--
 fs/overlayfs/super.c| 22 +-
 fs/overlayfs/util.c | 12 ++--
 11 files changed, 87 insertions(+), 33 deletions(-)

diff --git a/Documentation/filesystems/overlayfs.txt 
b/Documentation/filesystems/overlayfs.txt
index 1da2f1668f08..d48125076602 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -102,6 +102,29 @@ Only the lists of names from directories are merged.  
Other content
 such as metadata and extended attributes are reported for the upper
 directory only.  These attributes of the lower directory are hidden.
 
+credentials
+---
+
+By default, all access to the upper, lower and work directories is the
+recorded mounter's MAC and DAC credentials.  The incoming accesses are
+checked against the caller's credentials.
+
+In the case where caller MAC or DAC credentials do not overlap, a
+use case available in older versions of the driver, the
+override_creds mount flag can be turned off and help when the use
+pattern has caller with legitimate credentials where the mounter
+does not.  Several unintended side effects will occur though.  The
+caller without certain key capabilities or lower privilege will not
+always be able to delete files or directories, create nodes, or
+

[PATCH 5.1 310/371] fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.

2019-07-24 Thread Greg Kroah-Hartman
From: Radoslaw Burny 

commit 5ec27ec735ba0477d48c80561cc5e856f0c5dfaf upstream.

Normally, the inode's i_uid/i_gid are translated relative to s_user_ns,
but this is not a correct behavior for proc.  Since sysctl permission
check in test_perm is done against GLOBAL_ROOT_[UG]ID, it makes more
sense to use these values in u_[ug]id of proc inodes.  In other words:
although uid/gid in the inode is not read during test_perm, the inode
logically belongs to the root of the namespace.  I have confirmed this
with Eric Biederman at LPC and in this thread:
  https://lore.kernel.org/lkml/87k1kzjdff@xmission.com

Consequences


Since the i_[ug]id values of proc nodes are not used for permissions
checks, this change usually makes no functional difference.  However, it
causes an issue in a setup where:

 * a namespace container is created without root user in container -
   hence the i_[ug]id of proc nodes are set to INVALID_[UG]ID

 * container creator tries to configure it by writing /proc/sys files,
   e.g. writing /proc/sys/kernel/shmmax to configure shared memory limit

Kernel does not allow to open an inode for writing if its i_[ug]id are
invalid, making it impossible to write shmmax and thus - configure the
container.

Using a container with no root mapping is apparently rare, but we do use
this configuration at Google.  Also, we use a generic tool to configure
the container limits, and the inability to write any of them causes a
failure.

History
===

The invalid uids/gids in inodes first appeared due to 81754357770e (fs:
Update i_[ug]id_(read|write) to translate relative to s_user_ns).
However, AFAIK, this did not immediately cause any issues.  The
inability to write to these "invalid" inodes was only caused by a later
commit 0bd23d09b874 (vfs: Don't modify inodes with a uid or gid unknown
to the vfs).

Tested: Used a repro program that creates a user namespace without any
mapping and stat'ed /proc/$PID/root/proc/sys/kernel/shmmax from outside.
Before the change, it shows the overflow uid, with the change it's 0.
The overflow uid indicates that the uid in the inode is not correct and
thus it is not possible to open the file for writing.

Link: http://lkml.kernel.org/r/20190708115130.250149-1-rbu...@google.com
Fixes: 0bd23d09b874 ("vfs: Don't modify inodes with a uid or gid unknown to the 
vfs")
Signed-off-by: Radoslaw Burny 
Acked-by: Luis Chamberlain 
Cc: Kees Cook 
Cc: "Eric W . Biederman" 
Cc: Seth Forshee 
Cc: John Sperbeck 
Cc: Alexey Dobriyan 
Cc: [4.8+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/proc/proc_sysctl.c |4 
 1 file changed, 4 insertions(+)

--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -498,6 +498,10 @@ static struct inode *proc_sys_make_inode
 
if (root->set_ownership)
root->set_ownership(head, table, &inode->i_uid, &inode->i_gid);
+   else {
+   inode->i_uid = GLOBAL_ROOT_UID;
+   inode->i_gid = GLOBAL_ROOT_GID;
+   }
 
return inode;
 }




Re: [PATCH 5.3] mwifiex: fix 802.11n/WPA detection

2019-07-24 Thread Guenter Roeck

On 7/24/19 12:46 PM, Brian Norris wrote:

Commit 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant
vendor IEs") adjusted the ieee_types_vendor_header struct, which
inadvertently messed up the offsets used in
mwifiex_is_wpa_oui_present(). Add that offset back in, mirroring
mwifiex_is_rsn_oui_present().

As it stands, commit 63d7ef36103d breaks compatibility with WPA (not
WPA2) 802.11n networks, since we hit the "info: Disable 11n if AES is
not supported by AP" case in mwifiex_is_network_compatible().

Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor IEs")
Cc: 
Signed-off-by: Brian Norris 


Reviewed-by: Guenter Roeck 


---
  drivers/net/wireless/marvell/mwifiex/main.h | 1 +
  drivers/net/wireless/marvell/mwifiex/scan.c | 3 ++-
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 3e442c7f7882..095837fba300 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -124,6 +124,7 @@ enum {
  
  #define MWIFIEX_MAX_TOTAL_SCAN_TIME	(MWIFIEX_TIMER_10S - MWIFIEX_TIMER_1S)
  
+#define WPA_GTK_OUI_OFFSET2

  #define RSN_GTK_OUI_OFFSET2
  
  #define MWIFIEX_OUI_NOT_PRESENT			0

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index 0d6d41727037..21dda385f6c6 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -181,7 +181,8 @@ mwifiex_is_wpa_oui_present(struct mwifiex_bssdescriptor 
*bss_desc, u32 cipher)
u8 ret = MWIFIEX_OUI_NOT_PRESENT;
  
  	if (has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC)) {

-   iebody = (struct ie_body *) bss_desc->bcn_wpa_ie->data;
+   iebody = (struct ie_body *)((u8 *)bss_desc->bcn_wpa_ie->data +
+   WPA_GTK_OUI_OFFSET);
oui = &mwifiex_wpa_oui[cipher][0];
ret = mwifiex_search_oui_in_ie(iebody, oui);
if (ret)





[PATCH 5.1 316/371] dm zoned: fix zone state management race

2019-07-24 Thread Greg Kroah-Hartman
From: Damien Le Moal 

commit 3b8cafdd5436f9298b3bf6eb831df5eef5ee82b6 upstream.

dm-zoned uses the zone flag DMZ_ACTIVE to indicate that a zone of the
backend device is being actively read or written and so cannot be
reclaimed. This flag is set as long as the zone atomic reference
counter is not 0. When this atomic is decremented and reaches 0 (e.g.
on BIO completion), the active flag is cleared and set again whenever
the zone is reused and BIO issued with the atomic counter incremented.
These 2 operations (atomic inc/dec and flag set/clear) are however not
always executed atomically under the target metadata mutex lock and
this causes the warning:

WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));

in dmz_deactivate_zone() to be displayed. This problem is regularly
triggered with xfstests generic/209, generic/300, generic/451 and
xfs/077 with XFS being used as the file system on the dm-zoned target
device. Similarly, xfstests ext4/303, ext4/304, generic/209 and
generic/300 trigger the warning with ext4 use.

This problem can be easily fixed by simply removing the DMZ_ACTIVE flag
and managing the "ACTIVE" state by directly looking at the reference
counter value. To do so, the functions dmz_activate_zone() and
dmz_deactivate_zone() are changed to inline functions respectively
calling atomic_inc() and atomic_dec(), while the dmz_is_active() macro
is changed to an inline function calling atomic_read().

Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: sta...@vger.kernel.org
Reported-by: Masato Suzuki 
Signed-off-by: Damien Le Moal 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-zoned-metadata.c |   24 
 drivers/md/dm-zoned.h  |   28 
 2 files changed, 24 insertions(+), 28 deletions(-)

--- a/drivers/md/dm-zoned-metadata.c
+++ b/drivers/md/dm-zoned-metadata.c
@@ -1594,30 +1594,6 @@ struct dm_zone *dmz_get_zone_for_reclaim
 }
 
 /*
- * Activate a zone (increment its reference count).
- */
-void dmz_activate_zone(struct dm_zone *zone)
-{
-   set_bit(DMZ_ACTIVE, &zone->flags);
-   atomic_inc(&zone->refcount);
-}
-
-/*
- * Deactivate a zone. This decrement the zone reference counter
- * and clears the active state of the zone once the count reaches 0,
- * indicating that all BIOs to the zone have completed. Returns
- * true if the zone was deactivated.
- */
-void dmz_deactivate_zone(struct dm_zone *zone)
-{
-   if (atomic_dec_and_test(&zone->refcount)) {
-   WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
-   clear_bit_unlock(DMZ_ACTIVE, &zone->flags);
-   smp_mb__after_atomic();
-   }
-}
-
-/*
  * Get the zone mapping a chunk, if the chunk is mapped already.
  * If no mapping exist and the operation is WRITE, a zone is
  * allocated and used to map the chunk.
--- a/drivers/md/dm-zoned.h
+++ b/drivers/md/dm-zoned.h
@@ -115,7 +115,6 @@ enum {
DMZ_BUF,
 
/* Zone internal state */
-   DMZ_ACTIVE,
DMZ_RECLAIM,
DMZ_SEQ_WRITE_ERR,
 };
@@ -128,7 +127,6 @@ enum {
 #define dmz_is_empty(z)((z)->wp_block == 0)
 #define dmz_is_offline(z)  test_bit(DMZ_OFFLINE, &(z)->flags)
 #define dmz_is_readonly(z) test_bit(DMZ_READ_ONLY, &(z)->flags)
-#define dmz_is_active(z)   test_bit(DMZ_ACTIVE, &(z)->flags)
 #define dmz_in_reclaim(z)  test_bit(DMZ_RECLAIM, &(z)->flags)
 #define dmz_seq_write_err(z)   test_bit(DMZ_SEQ_WRITE_ERR, &(z)->flags)
 
@@ -188,8 +186,30 @@ void dmz_unmap_zone(struct dmz_metadata
 unsigned int dmz_nr_rnd_zones(struct dmz_metadata *zmd);
 unsigned int dmz_nr_unmap_rnd_zones(struct dmz_metadata *zmd);
 
-void dmz_activate_zone(struct dm_zone *zone);
-void dmz_deactivate_zone(struct dm_zone *zone);
+/*
+ * Activate a zone (increment its reference count).
+ */
+static inline void dmz_activate_zone(struct dm_zone *zone)
+{
+   atomic_inc(&zone->refcount);
+}
+
+/*
+ * Deactivate a zone. This decrement the zone reference counter
+ * indicating that all BIOs to the zone have completed when the count is 0.
+ */
+static inline void dmz_deactivate_zone(struct dm_zone *zone)
+{
+   atomic_dec(&zone->refcount);
+}
+
+/*
+ * Test if a zone is active, that is, has a refcount > 0.
+ */
+static inline bool dmz_is_active(struct dm_zone *zone)
+{
+   return atomic_read(&zone->refcount);
+}
 
 int dmz_lock_zone_reclaim(struct dm_zone *zone);
 void dmz_unlock_zone_reclaim(struct dm_zone *zone);




[PATCH 5.1 314/371] drm/nouveau/i2c: Enable i2c pads & busses during preinit

2019-07-24 Thread Greg Kroah-Hartman
From: Lyude Paul 

commit 7cb95eeea6706c790571042a06782e378b2561ea upstream.

It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:

commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")

We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs, as apparently said scripts can actually use the i2c
bus. Since these scripts are executed before initializing any
subdevices, we end up failing to acquire access to the i2c bus which has
left a number of cards with their fan controllers uninitialized. Luckily
this doesn't break hardware - it just means the fan gets stuck at 100%.

This also means that we've always been using our i2c busses before
initializing them during the init scripts for older GPUs, we just didn't
notice it until we started preventing them from being used until init.
It's pretty impressive this never caused us any issues before!

So, fix this by initializing our i2c pad and busses during subdev
pre-init. We skip initializing aux busses during pre-init, as those are
guaranteed to only ever be used by nouveau for DP aux transactions.

Signed-off-by: Lyude Paul 
Tested-by: Marc Meledandri 
Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c |   20 
 1 file changed, 20 insertions(+)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
@@ -185,6 +185,25 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev
 }
 
 static int
+nvkm_i2c_preinit(struct nvkm_subdev *subdev)
+{
+   struct nvkm_i2c *i2c = nvkm_i2c(subdev);
+   struct nvkm_i2c_bus *bus;
+   struct nvkm_i2c_pad *pad;
+
+   /*
+* We init our i2c busses as early as possible, since they may be
+* needed by the vbios init scripts on some cards
+*/
+   list_for_each_entry(pad, &i2c->pad, head)
+   nvkm_i2c_pad_init(pad);
+   list_for_each_entry(bus, &i2c->bus, head)
+   nvkm_i2c_bus_init(bus);
+
+   return 0;
+}
+
+static int
 nvkm_i2c_init(struct nvkm_subdev *subdev)
 {
struct nvkm_i2c *i2c = nvkm_i2c(subdev);
@@ -238,6 +257,7 @@ nvkm_i2c_dtor(struct nvkm_subdev *subdev
 static const struct nvkm_subdev_func
 nvkm_i2c = {
.dtor = nvkm_i2c_dtor,
+   .preinit = nvkm_i2c_preinit,
.init = nvkm_i2c_init,
.fini = nvkm_i2c_fini,
.intr = nvkm_i2c_intr,




[PATCH 5.1 324/371] perf/x86/amd/uncore: Set the thread mask for F17h L3 PMCs

2019-07-24 Thread Greg Kroah-Hartman
From: Kim Phillips 

commit 2f217d58a8a086d3399fecce39fb358848e799c4 upstream.

Fill in the L3 performance event select register ThreadMask
bitfield, to enable per hardware thread accounting.

Signed-off-by: Kim Phillips 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Gary Hook 
Cc: H. Peter Anvin 
Cc: Janakarajan Natarajan 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Martin Liska 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Pu Wen 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Link: https://lkml.kernel.org/r/20190628215906.4276-2-kim.phill...@amd.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/amd/uncore.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -205,15 +205,22 @@ static int amd_uncore_event_init(struct
hwc->config = event->attr.config & AMD64_RAW_EVENT_MASK_NB;
hwc->idx = -1;
 
+   if (event->cpu < 0)
+   return -EINVAL;
+
/*
 * SliceMask and ThreadMask need to be set for certain L3 events in
 * Family 17h. For other events, the two fields do not affect the count.
 */
-   if (l3_mask && is_llc_event(event))
-   hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
+   if (l3_mask && is_llc_event(event)) {
+   int thread = 2 * (cpu_data(event->cpu).cpu_core_id % 4);
 
-   if (event->cpu < 0)
-   return -EINVAL;
+   if (smp_num_siblings > 1)
+   thread += cpu_data(event->cpu).apicid & 1;
+
+   hwc->config |= (1ULL << (AMD64_L3_THREAD_SHIFT + thread) &
+   AMD64_L3_THREAD_MASK) | AMD64_L3_SLICE_MASK;
+   }
 
uncore = event_to_amd_uncore(event);
if (!uncore)




[PATCH 5.1 323/371] perf/x86/amd/uncore: Do not set ThreadMask and SliceMask for non-L3 PMCs

2019-07-24 Thread Greg Kroah-Hartman
From: Kim Phillips 

commit 16f4641166b10e199f0d7b68c2c5f004fef0bda3 upstream.

The following commit:

  d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache 
perf events")

enables L3 PMC events for all threads and slices by writing 1's in
'ChL3PmcCfg' (L3 PMC PERF_CTL) register fields.

Those bitfields overlap with high order event select bits in the Data
Fabric PMC control register, however.

So when a user requests raw Data Fabric events (-e amd_df/event=0xYYY/),
the two highest order bits get inadvertently set, changing the counter
select to events that don't exist, and for which no counts are read.

This patch changes the logic to write the L3 masks only when dealing
with L3 PMC counters.

AMD Family 16h and below Northbridge (NB) counters were not affected.

Signed-off-by: Kim Phillips 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Gary Hook 
Cc: H. Peter Anvin 
Cc: Janakarajan Natarajan 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Martin Liska 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Pu Wen 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 
Cache perf events")
Link: https://lkml.kernel.org/r/20190628215906.4276-1-kim.phill...@amd.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/amd/uncore.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -209,7 +209,7 @@ static int amd_uncore_event_init(struct
 * SliceMask and ThreadMask need to be set for certain L3 events in
 * Family 17h. For other events, the two fields do not affect the count.
 */
-   if (l3_mask)
+   if (l3_mask && is_llc_event(event))
hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
 
if (event->cpu < 0)




[PATCH 5.1 313/371] ARM: dts: gemini: Set DIR-685 SPI CS as active low

2019-07-24 Thread Greg Kroah-Hartman
From: Linus Walleij 

commit f90b8fda3a9d72a9422ea80ae95843697f94ea4a upstream.

The SPI to the display on the DIR-685 is active low, we were
just saved by the SPI library enforcing active low on everything
before, so set it as active low to avoid ambiguity.

Link: https://lore.kernel.org/r/20190715202101.16060-1-linus.wall...@linaro.org
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/gemini-dlink-dir-685.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -64,7 +64,7 @@
gpio-sck = <&gpio1 5 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio1 8 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio1 7 GPIO_ACTIVE_HIGH>;
-   cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+   cs-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
num-chipselects = <1>;
 
panel: display@0 {




[PATCH 5.1 317/371] xen/events: fix binding user event channels to cpus

2019-07-24 Thread Greg Kroah-Hartman
From: Juergen Gross 

commit bce5963bcb4f9934faa52be323994511d59fd13c upstream.

When binding an interdomain event channel to a vcpu via
IOCTL_EVTCHN_BIND_INTERDOMAIN not only the event channel needs to be
bound, but the affinity of the associated IRQi must be changed, too.
Otherwise the IRQ and the event channel won't be moved to another vcpu
in case the original vcpu they were bound to is going offline.

Cc:  # 4.13
Fixes: c48f64ab472389df ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next 
online VCPU")
Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/events/events_base.c |   12 ++--
 drivers/xen/evtchn.c |2 +-
 include/xen/events.h |3 ++-
 3 files changed, 13 insertions(+), 4 deletions(-)

--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1293,7 +1293,7 @@ void rebind_evtchn_irq(int evtchn, int i
 }
 
 /* Rebind an evtchn so that it gets delivered to a specific cpu */
-int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu)
+static int xen_rebind_evtchn_to_cpu(int evtchn, unsigned int tcpu)
 {
struct evtchn_bind_vcpu bind_vcpu;
int masked;
@@ -1327,7 +1327,6 @@ int xen_rebind_evtchn_to_cpu(int evtchn,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(xen_rebind_evtchn_to_cpu);
 
 static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
bool force)
@@ -1341,6 +1340,15 @@ static int set_affinity_irq(struct irq_d
return ret;
 }
 
+/* To be called with desc->lock held. */
+int xen_set_affinity_evtchn(struct irq_desc *desc, unsigned int tcpu)
+{
+   struct irq_data *d = irq_desc_get_irq_data(desc);
+
+   return set_affinity_irq(d, cpumask_of(tcpu), false);
+}
+EXPORT_SYMBOL_GPL(xen_set_affinity_evtchn);
+
 static void enable_dynirq(struct irq_data *data)
 {
int evtchn = evtchn_from_irq(data->irq);
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -447,7 +447,7 @@ static void evtchn_bind_interdom_next_vc
this_cpu_write(bind_last_selected_cpu, selected_cpu);
 
/* unmask expects irqs to be disabled */
-   xen_rebind_evtchn_to_cpu(evtchn, selected_cpu);
+   xen_set_affinity_evtchn(desc, selected_cpu);
raw_spin_unlock_irqrestore(&desc->lock, flags);
 }
 
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -3,6 +3,7 @@
 #define _XEN_EVENTS_H
 
 #include 
+#include 
 #ifdef CONFIG_PCI_MSI
 #include 
 #endif
@@ -59,7 +60,7 @@ void evtchn_put(unsigned int evtchn);
 
 void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);
 void rebind_evtchn_irq(int evtchn, int irq);
-int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu);
+int xen_set_affinity_evtchn(struct irq_desc *desc, unsigned int tcpu);
 
 static inline void notify_remote_via_evtchn(int port)
 {




[PATCH 5.1 298/371] KVM: nVMX: Dont dump VMCS if virtual APIC page cant be mapped

2019-07-24 Thread Greg Kroah-Hartman
From: Sean Christopherson 

commit 73cb85568433feadb79e963bf2efba9b3e9ae3df upstream.

... as a malicious userspace can run a toy guest to generate invalid
virtual-APIC page addresses in L1, i.e. flood the kernel log with error
messages.

Fixes: 690908104e39d ("KVM: nVMX: allow tests to use bad virtual-APIC page 
address")
Cc: sta...@vger.kernel.org
Cc: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/vmx/nested.c |3 ---
 1 file changed, 3 deletions(-)

--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2891,9 +2891,6 @@ static void nested_get_vmcs12_pages(stru
 */
vmcs_clear_bits(CPU_BASED_VM_EXEC_CONTROL,
CPU_BASED_TPR_SHADOW);
-   } else {
-   printk("bad virtual-APIC page address\n");
-   dump_vmcs();
}
}
 




[PATCH 5.1 315/371] padata: use smp_mb in padata_reorder to avoid orphaned padata jobs

2019-07-24 Thread Greg Kroah-Hartman
From: Daniel Jordan 

commit cf144f81a99d1a3928f90b0936accfd3f45c9a0a upstream.

Testing padata with the tcrypt module on a 5.2 kernel...

# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# modprobe tcrypt mode=211 sec=1

...produces this splat:

INFO: task modprobe:10075 blocked for more than 120 seconds.
  Not tainted 5.2.0-base+ #16
modprobeD0 10075  10064 0x80004080
Call Trace:
 ? __schedule+0x4dd/0x610
 ? ring_buffer_unlock_commit+0x23/0x100
 schedule+0x6c/0x90
 schedule_timeout+0x3b/0x320
 ? trace_buffer_unlock_commit_regs+0x4f/0x1f0
 wait_for_common+0x160/0x1a0
 ? wake_up_q+0x80/0x80
 { crypto_wait_req } # entries in braces added by hand
 { do_one_aead_op }
 { test_aead_jiffies }
 test_aead_speed.constprop.17+0x681/0xf30 [tcrypt]
 do_test+0x4053/0x6a2b [tcrypt]
 ? 0xa00f4000
 tcrypt_mod_init+0x50/0x1000 [tcrypt]
 ...

The second modprobe command never finishes because in padata_reorder,
CPU0's load of reorder_objects is executed before the unlocking store in
spin_unlock_bh(pd->lock), causing CPU0 to miss CPU1's increment:

CPU0 CPU1

padata_reorder   padata_do_serial
  LOAD reorder_objects  // 0
   INC reorder_objects  // 1
   padata_reorder
 TRYLOCK pd->lock   // failed
  UNLOCK pd->lock

CPU0 deletes the timer before returning from padata_reorder and since no
other job is submitted to padata, modprobe waits indefinitely.

Add a pair of full barriers to guarantee proper ordering:

CPU0 CPU1

padata_reorder   padata_do_serial
  UNLOCK pd->lock
  smp_mb()
  LOAD reorder_objects
   INC reorder_objects
   smp_mb__after_atomic()
   padata_reorder
 TRYLOCK pd->lock

smp_mb__after_atomic is needed so the read part of the trylock operation
comes after the INC, as Andrea points out.   Thanks also to Andrea for
help with writing a litmus test.

Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface")
Signed-off-by: Daniel Jordan 
Cc: 
Cc: Andrea Parri 
Cc: Boqun Feng 
Cc: Herbert Xu 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Steffen Klassert 
Cc: linux-a...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/padata.c |   12 
 1 file changed, 12 insertions(+)

--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -267,7 +267,12 @@ static void padata_reorder(struct parall
 * The next object that needs serialization might have arrived to
 * the reorder queues in the meantime, we will be called again
 * from the timer function if no one else cares for it.
+*
+* Ensure reorder_objects is read after pd->lock is dropped so we see
+* an increment from another task in padata_do_serial.  Pairs with
+* smp_mb__after_atomic in padata_do_serial.
 */
+   smp_mb();
if (atomic_read(&pd->reorder_objects)
&& !(pinst->flags & PADATA_RESET))
mod_timer(&pd->timer, jiffies + HZ);
@@ -387,6 +392,13 @@ void padata_do_serial(struct padata_priv
list_add_tail(&padata->list, &pqueue->reorder.list);
spin_unlock(&pqueue->reorder.lock);
 
+   /*
+* Ensure the atomic_inc of reorder_objects above is ordered correctly
+* with the trylock of pd->lock in padata_reorder.  Pairs with smp_mb
+* in padata_reorder.
+*/
+   smp_mb__after_atomic();
+
put_cpu();
 
/* If we're running on the wrong CPU, call padata_reorder() via a




[PATCH 5.1 299/371] KVM: nVMX: Always sync GUEST_BNDCFGS when it comes from vmcs01

2019-07-24 Thread Greg Kroah-Hartman
From: Sean Christopherson 

commit 3b013a2972d5bc344d6eaa8f24fdfe268211e45f upstream.

If L1 does not set VM_ENTRY_LOAD_BNDCFGS, then L1's BNDCFGS value must
be propagated to vmcs02 since KVM always runs with VM_ENTRY_LOAD_BNDCFGS
when MPX is supported.  Because the value effectively comes from vmcs01,
vmcs02 must be updated even if vmcs12 is clean.

Fixes: 62cf9bd8118c4 ("KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS")
Cc: sta...@vger.kernel.org
Cc: Liran Alon 
Signed-off-by: Sean Christopherson 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/vmx/nested.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2243,13 +2243,9 @@ static void prepare_vmcs02_full(struct v
 
set_cr4_guest_host_mask(vmx);
 
-   if (kvm_mpx_supported()) {
-   if (vmx->nested.nested_run_pending &&
-   (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
-   vmcs_write64(GUEST_BNDCFGS, vmcs12->guest_bndcfgs);
-   else
-   vmcs_write64(GUEST_BNDCFGS, 
vmx->nested.vmcs01_guest_bndcfgs);
-   }
+   if (kvm_mpx_supported() && vmx->nested.nested_run_pending &&
+   (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
+   vmcs_write64(GUEST_BNDCFGS, vmcs12->guest_bndcfgs);
 }
 
 /*
@@ -2292,6 +2288,9 @@ static int prepare_vmcs02(struct kvm_vcp
kvm_set_dr(vcpu, 7, vcpu->arch.dr7);
vmcs_write64(GUEST_IA32_DEBUGCTL, vmx->nested.vmcs01_debugctl);
}
+   if (kvm_mpx_supported() && (!vmx->nested.nested_run_pending ||
+   !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS)))
+   vmcs_write64(GUEST_BNDCFGS, vmx->nested.vmcs01_guest_bndcfgs);
vmx_set_rflags(vcpu, vmcs12->guest_rflags);
 
/* EXCEPTION_BITMAP and CR0_GUEST_HOST_MASK should basically be the




[PATCH 5.1 330/371] PCI: hv: Fix a use-after-free bug in hv_eject_device_work()

2019-07-24 Thread Greg Kroah-Hartman
From: Dexuan Cui 

commit 4df591b20b80cb77920953812d894db259d85bd7 upstream.

Fix a use-after-free in hv_eject_device_work().

Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()")
Signed-off-by: Dexuan Cui 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Michael Kelley 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/controller/pci-hyperv.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1875,6 +1875,7 @@ static void hv_pci_devices_present(struc
 static void hv_eject_device_work(struct work_struct *work)
 {
struct pci_eject_response *ejct_pkt;
+   struct hv_pcibus_device *hbus;
struct hv_pci_dev *hpdev;
struct pci_dev *pdev;
unsigned long flags;
@@ -1885,6 +1886,7 @@ static void hv_eject_device_work(struct
} ctxt;
 
hpdev = container_of(work, struct hv_pci_dev, wrk);
+   hbus = hpdev->hbus;
 
WARN_ON(hpdev->state != hv_pcichild_ejecting);
 
@@ -1895,8 +1897,7 @@ static void hv_eject_device_work(struct
 * because hbus->pci_bus may not exist yet.
 */
wslot = wslot_to_devfn(hpdev->desc.win_slot.slot);
-   pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
-  wslot);
+   pdev = pci_get_domain_bus_and_slot(hbus->sysdata.domain, 0, wslot);
if (pdev) {
pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
@@ -1904,9 +1905,9 @@ static void hv_eject_device_work(struct
pci_unlock_rescan_remove();
}
 
-   spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
+   spin_lock_irqsave(&hbus->device_list_lock, flags);
list_del(&hpdev->list_entry);
-   spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
+   spin_unlock_irqrestore(&hbus->device_list_lock, flags);
 
if (hpdev->pci_slot)
pci_destroy_slot(hpdev->pci_slot);
@@ -1915,7 +1916,7 @@ static void hv_eject_device_work(struct
ejct_pkt = (struct pci_eject_response *)&ctxt.pkt.message;
ejct_pkt->message_type.type = PCI_EJECTION_COMPLETE;
ejct_pkt->wslot.slot = hpdev->desc.win_slot.slot;
-   vmbus_sendpacket(hpdev->hbus->hdev->channel, ejct_pkt,
+   vmbus_sendpacket(hbus->hdev->channel, ejct_pkt,
 sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt,
 VM_PKT_DATA_INBAND, 0);
 
@@ -1924,7 +1925,9 @@ static void hv_eject_device_work(struct
/* For the two refs got in new_pcichild_device() */
put_pcichild(hpdev);
put_pcichild(hpdev);
-   put_hvpcibus(hpdev->hbus);
+   /* hpdev has been freed. Do not use it any more. */
+
+   put_hvpcibus(hbus);
 }
 
 /**




[PATCH 5.1 331/371] PCI: Do not poll for PME if the device is in D3cold

2019-07-24 Thread Greg Kroah-Hartman
From: Mika Westerberg 

commit 000dd5316e1c756a1c028f22e01d06a38249dd4d upstream.

PME polling does not take into account that a device that is directly
connected to the host bridge may go into D3cold as well. This leads to a
situation where the PME poll thread reads from a config space of a
device that is in D3cold and gets incorrect information because the
config space is not accessible.

Here is an example from Intel Ice Lake system where two PCIe root ports
are in D3cold (I've instrumented the kernel to log the PMCSR register
contents):

  [   62.971442] pcieport :00:07.1: Check PME status, PMCSR=0x
  [   62.971504] pcieport :00:07.0: Check PME status, PMCSR=0x

Since 0x is interpreted so that PME is pending, the root ports will
be runtime resumed. This repeats over and over again essentially
blocking all runtime power management.

Prevent this from happening by checking whether the device is in D3cold
before its PME status is read.

Fixes: 71a83bd727cc ("PCI/PM: add runtime PM support to PCIe port")
Signed-off-by: Mika Westerberg 
Reviewed-by: Lukas Wunner 
Cc: 3.6+  # v3.6+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/pci.c |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2052,6 +2052,13 @@ static void pci_pme_list_scan(struct wor
 */
if (bridge && bridge->current_state != PCI_D0)
continue;
+   /*
+* If the device is in D3cold it should not be
+* polled either.
+*/
+   if (pme_dev->dev->current_state == PCI_D3cold)
+   continue;
+
pci_pme_wakeup(pme_dev->dev, NULL);
} else {
list_del(&pme_dev->list);




[PATCH 5.1 333/371] Btrfs: fix data loss after inode eviction, renaming it, and fsync it

2019-07-24 Thread Greg Kroah-Hartman
From: Filipe Manana 

commit d1d832a0b51dd9570429bb4b81b2a6c1759e681a upstream.

When we log an inode, regardless of logging it completely or only that it
exists, we always update it as logged (logged_trans and last_log_commit
fields of the inode are updated). This is generally fine and avoids future
attempts to log it from having to do repeated work that brings no value.

However, if we write data to a file, then evict its inode after all the
dealloc was flushed (and ordered extents completed), rename the file and
fsync it, we end up not logging the new extents, since the rename may
result in logging that the inode exists in case the parent directory was
logged before. The following reproducer shows and explains how this can
happen:

  $ mkfs.btrfs -f /dev/sdb
  $ mount /dev/sdb /mnt

  $ mkdir /mnt/dir
  $ touch /mnt/dir/foo
  $ touch /mnt/dir/bar

  # Do a direct IO write instead of a buffered write because with a
  # buffered write we would need to make sure dealloc gets flushed and
  # complete before we do the inode eviction later, and we can not do that
  # from user space with call to things such as sync(2) since that results
  # in a transaction commit as well.
  $ xfs_io -d -c "pwrite -S 0xd3 0 4K" /mnt/dir/bar

  # Keep the directory dir in use while we evict inodes. We want our file
  # bar's inode to be evicted but we don't want our directory's inode to
  # be evicted (if it were evicted too, we would not be able to reproduce
  # the issue since the first fsync below, of file foo, would result in a
  # transaction commit.
  $ ( cd /mnt/dir; while true; do :; done ) &
  $ pid=$!

  # Wait a bit to give time for the background process to chdir.
  $ sleep 0.1

  # Evict all inodes, except the inode for the directory dir because it is
  # currently in use by our background process.
  $ echo 2 > /proc/sys/vm/drop_caches

  # fsync file foo, which ends up persisting information about the parent
  # directory because it is a new inode.
  $ xfs_io -c fsync /mnt/dir/foo

  # Rename bar, this results in logging that this inode exists (inode item,
  # names, xattrs) because the parent directory is in the log.
  $ mv /mnt/dir/bar /mnt/dir/baz

  # Now fsync baz, which ends up doing absolutely nothing because of the
  # rename operation which logged that the inode exists only.
  $ xfs_io -c fsync /mnt/dir/baz

  

  $ mount /dev/sdb /mnt
  $ od -t x1 -A d /mnt/dir/baz
  000

--> Empty file, data we wrote is missing.

Fix this by not updating last_sub_trans of an inode when we are logging
only that it exists and the inode was not yet logged since it was loaded
from disk (full_sync bit set), this is enough to make btrfs_inode_in_log()
return false for this scenario and make us log the inode. The logged_trans
of the inode is still always setsince that alone is used to track if names
need to be deleted as part of unlink operations.

Fixes: 257c62e1bce03e ("Btrfs: avoid tree log commit when there are no changes")
CC: sta...@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/tree-log.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5407,9 +5407,19 @@ log_extents:
}
}
 
+   /*
+* Don't update last_log_commit if we logged that an inode exists after
+* it was loaded to memory (full_sync bit set).
+* This is to prevent data loss when we do a write to the inode, then
+* the inode gets evicted after all delalloc was flushed, then we log
+* it exists (due to a rename for example) and then fsync it. This last
+* fsync would do nothing (not logging the extents previously written).
+*/
spin_lock(&inode->lock);
inode->logged_trans = trans->transid;
-   inode->last_log_commit = inode->last_sub_trans;
+   if (inode_only != LOG_INODE_EXISTS ||
+   !test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &inode->runtime_flags))
+   inode->last_log_commit = inode->last_sub_trans;
spin_unlock(&inode->lock);
 out_unlock:
mutex_unlock(&inode->log_mutex);




[PATCH 5.1 319/371] 9p/virtio: Add cleanup path in p9_virtio_init

2019-07-24 Thread Greg Kroah-Hartman
From: YueHaibing 

commit d4548543fc4ece56c6f04b8586f435fb4fd84c20 upstream.

KASAN report this:

BUG: unable to handle kernel paging request at a0097000
PGD 3870067 P4D 3870067 PUD 3871063 PMD 2326e2067 PTE 0
Oops:  [#1
CPU: 0 PID: 5340 Comm: modprobe Not tainted 5.1.0-rc7+ #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:__list_add_valid+0x10/0x70
Code: c3 48 8b 06 55 48 89 e5 5d 48 39 07 0f 94 c0 0f b6 c0 c3 90 90 90 90 90 
90 90 55 48 89 d0 48 8b 52 08 48 89 e5 48 39 f2 75 19 <48> 8b 32 48 39 f0 75 3a

RSP: 0018:c9e23c68 EFLAGS: 00010246
RAX: a00ad000 RBX: a009d000 RCX: 
RDX: a0097000 RSI: a0097000 RDI: a009d000
RBP: c9e23c68 R08: 0001 R09: 
R10:  R11:  R12: a0097000
R13: 888231797180 R14:  R15: c9e23e78
FS:  7fb215285540() GS:888237a0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: a0097000 CR3: 00022f144000 CR4: 06f0
Call Trace:
 v9fs_register_trans+0x2f/0x60 [9pnet
 ? 0xa0087000
 p9_virtio_init+0x25/0x1000 [9pnet_virtio
 do_one_initcall+0x6c/0x3cc
 ? kmem_cache_alloc_trace+0x248/0x3b0
 do_init_module+0x5b/0x1f1
 load_module+0x1db1/0x2690
 ? m_show+0x1d0/0x1d0
 __do_sys_finit_module+0xc5/0xd0
 __x64_sys_finit_module+0x15/0x20
 do_syscall_64+0x6b/0x1d0
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fb214d8e839
Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01

RSP: 002b:7ffc96554278 EFLAGS: 0246 ORIG_RAX: 0139
RAX: ffda RBX: 55e67eed2aa0 RCX: 7fb214d8e839
RDX:  RSI: 55e67ce95c2e RDI: 0003
RBP: 55e67ce95c2e R08:  R09: 55e67eed2aa0
R10: 0003 R11: 0246 R12: 
R13: 55e67eeda500 R14: 0004 R15: 55e67eed2aa0
Modules linked in: 9pnet_virtio(+) 9pnet gre rfkill 
vmw_vsock_virtio_transport_common vsock [last unloaded: 9pnet_virtio
CR2: a0097000
---[ end trace 4a52bb13ff07b761

If register_virtio_driver() fails in p9_virtio_init,
we should call v9fs_unregister_trans() to do cleanup.

Link: http://lkml.kernel.org/r/20190430115942.41840-1-yuehaib...@huawei.com
Cc: sta...@vger.kernel.org
Reported-by: Hulk Robot 
Fixes: b530cc794024 ("9p: add virtio transport")
Signed-off-by: YueHaibing 
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman 

---
 net/9p/trans_virtio.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -782,10 +782,16 @@ static struct p9_trans_module p9_virtio_
 /* The standard init function */
 static int __init p9_virtio_init(void)
 {
+   int rc;
+
INIT_LIST_HEAD(&virtio_chan_list);
 
v9fs_register_trans(&p9_virtio_trans);
-   return register_virtio_driver(&p9_virtio_drv);
+   rc = register_virtio_driver(&p9_virtio_drv);
+   if (rc)
+   v9fs_unregister_trans(&p9_virtio_trans);
+
+   return rc;
 }
 
 static void __exit p9_virtio_cleanup(void)




[PATCH 5.1 337/371] HID: wacom: generic: only switch the mode on devices with LEDs

2019-07-24 Thread Greg Kroah-Hartman
From: Aaron Armstrong Skomra 

commit d8e9806005f28bbb49899dab2068e3359e22ba35 upstream.

Currently, the driver will attempt to set the mode on all
devices with a center button, but some devices with a center
button lack LEDs, and attempting to set the LEDs on devices
without LEDs results in the kernel error message of the form:

"leds input8::wacom-0.1: Setting an LED's brightness failed (-32)"

This is because the generic codepath erroneously assumes that the
BUTTON_CENTER usage indicates that the device has LEDs, the
previously ignored TOUCH_RING_SETTING usage is a more accurate
indication of the existence of LEDs on the device.

Fixes: 10c55cacb8b2 ("HID: wacom: generic: support LEDs")
Cc:  # v4.11+
Signed-off-by: Aaron Armstrong Skomra 
Reviewed-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/wacom_sys.c |3 +++
 drivers/hid/wacom_wac.c |2 --
 drivers/hid/wacom_wac.h |1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -307,6 +307,9 @@ static void wacom_feature_mapping(struct
wacom_hid_usage_quirk(hdev, field, usage);
 
switch (equivalent_usage) {
+   case WACOM_HID_WD_TOUCH_RING_SETTING:
+   wacom->generic_has_leds = true;
+   break;
case HID_DG_CONTACTMAX:
/* leave touch_max as is if predefined */
if (!features->touch_max) {
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1930,8 +1930,6 @@ static void wacom_wac_pad_usage_mapping(
features->device_type |= WACOM_DEVICETYPE_PAD;
break;
case WACOM_HID_WD_BUTTONCENTER:
-   wacom->generic_has_leds = true;
-   /* fall through */
case WACOM_HID_WD_BUTTONHOME:
case WACOM_HID_WD_BUTTONUP:
case WACOM_HID_WD_BUTTONDOWN:
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -145,6 +145,7 @@
 #define WACOM_HID_WD_OFFSETBOTTOM   (WACOM_HID_UP_WACOMDIGITIZER | 0x0d33)
 #define WACOM_HID_WD_DATAMODE   (WACOM_HID_UP_WACOMDIGITIZER | 0x1002)
 #define WACOM_HID_WD_DIGITIZERINFO  (WACOM_HID_UP_WACOMDIGITIZER | 0x1013)
+#define WACOM_HID_WD_TOUCH_RING_SETTING (WACOM_HID_UP_WACOMDIGITIZER | 0x1032)
 #define WACOM_HID_UP_G9 0xff09
 #define WACOM_HID_G9_PEN(WACOM_HID_UP_G9 | 0x02)
 #define WACOM_HID_G9_TOUCHSCREEN(WACOM_HID_UP_G9 | 0x11)




[PATCH 5.1 301/371] KVM: VMX: check CPUID before allowing read/write of IA32_XSS

2019-07-24 Thread Greg Kroah-Hartman
From: Wanpeng Li 

commit 4d763b168e9c5c366b05812c7bba7662e5ea3669 upstream.

Raise #GP when guest read/write IA32_XSS, but the CPUID bits
say that it shouldn't exist.

Fixes: 203000993de5 (kvm: vmx: add MSR logic for XSAVES)
Reported-by: Xiaoyao Li 
Reported-by: Tao Xu 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: sta...@vger.kernel.org
Signed-off-by: Wanpeng Li 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/vmx/vmx.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1718,7 +1718,10 @@ static int vmx_get_msr(struct kvm_vcpu *
return vmx_get_vmx_msr(&vmx->nested.msrs, msr_info->index,
   &msr_info->data);
case MSR_IA32_XSS:
-   if (!vmx_xsaves_supported())
+   if (!vmx_xsaves_supported() ||
+   (!msr_info->host_initiated &&
+!(guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
+  guest_cpuid_has(vcpu, X86_FEATURE_XSAVES
return 1;
msr_info->data = vcpu->arch.ia32_xss;
break;
@@ -1929,7 +1932,10 @@ static int vmx_set_msr(struct kvm_vcpu *
return 1;
return vmx_set_vmx_msr(vcpu, msr_index, data);
case MSR_IA32_XSS:
-   if (!vmx_xsaves_supported())
+   if (!vmx_xsaves_supported() ||
+   (!msr_info->host_initiated &&
+!(guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
+  guest_cpuid_has(vcpu, X86_FEATURE_XSAVES
return 1;
/*
 * The only supported bit as of Skylake is bit 8, but




[PATCH 5.1 335/371] Btrfs: add missing inode version, ctime and mtime updates when punching hole

2019-07-24 Thread Greg Kroah-Hartman
From: Filipe Manana 

commit 179006688a7e888cbff39577189f2e034786d06a upstream.

If the range for which we are punching a hole covers only part of a page,
we end up updating the inode item but we skip the update of the inode's
iversion, mtime and ctime. Fix that by ensuring we update those properties
of the inode.

A patch for fstests test case generic/059 that tests this as been sent
along with this fix.

Fixes: 2aaa66558172b0 ("Btrfs: add hole punching")
Fixes: e8c1c76e804b18 ("Btrfs: add missing inode update when punching hole")
CC: sta...@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/file.c |5 +
 1 file changed, 5 insertions(+)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2713,6 +2713,11 @@ out_only_mutex:
 * for detecting, at fsync time, if the inode isn't yet in the
 * log tree or it's there but not up to date.
 */
+   struct timespec64 now = current_time(inode);
+
+   inode_inc_iversion(inode);
+   inode->i_mtime = now;
+   inode->i_ctime = now;
trans = btrfs_start_transaction(root, 1);
if (IS_ERR(trans)) {
err = PTR_ERR(trans);




[PATCH 5.1 336/371] IB/mlx5: Report correctly tag matching rendezvous capability

2019-07-24 Thread Greg Kroah-Hartman
From: Danit Goldberg 

commit 89705e92700170888236555fe91b45e4c1bb0985 upstream.

Userspace expects the IB_TM_CAP_RC bit to indicate that the device
supports RC transport tag matching with rendezvous offload. However the
firmware splits this into two capabilities for eager and rendezvous tag
matching.

Only if the FW supports both modes should userspace be told the tag
matching capability is available.

Cc:  # 4.13
Fixes: eb761894351d ("IB/mlx5: Fill XRQ capabilities")
Signed-off-by: Danit Goldberg 
Reviewed-by: Yishai Hadas 
Reviewed-by: Artemy Kovalyov 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/mlx5/main.c |8 ++--
 include/rdma/ib_verbs.h   |4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1041,15 +1041,19 @@ static int mlx5_ib_query_device(struct i
}
 
if (MLX5_CAP_GEN(mdev, tag_matching)) {
-   props->tm_caps.max_rndv_hdr_size = MLX5_TM_MAX_RNDV_MSG_SIZE;
props->tm_caps.max_num_tags =
(1 << MLX5_CAP_GEN(mdev, log_tag_matching_list_sz)) - 1;
-   props->tm_caps.flags = IB_TM_CAP_RC;
props->tm_caps.max_ops =
1 << MLX5_CAP_GEN(mdev, log_max_qp_sz);
props->tm_caps.max_sge = MLX5_TM_MAX_SGE;
}
 
+   if (MLX5_CAP_GEN(mdev, tag_matching) &&
+   MLX5_CAP_GEN(mdev, rndv_offload_rc)) {
+   props->tm_caps.flags = IB_TM_CAP_RNDV_RC;
+   props->tm_caps.max_rndv_hdr_size = MLX5_TM_MAX_RNDV_MSG_SIZE;
+   }
+
if (MLX5_CAP_GEN(dev->mdev, cq_moderation)) {
props->cq_caps.max_cq_moderation_count =
MLX5_MAX_CQ_COUNT;
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -293,8 +293,8 @@ struct ib_rss_caps {
 };
 
 enum ib_tm_cap_flags {
-   /*  Support tag matching on RC transport */
-   IB_TM_CAP_RC= 1 << 0,
+   /*  Support tag matching with rendezvous offload for RC transport */
+   IB_TM_CAP_RNDV_RC = 1 << 0,
 };
 
 struct ib_tm_caps {




[PATCH 5.1 296/371] media: videobuf2-core: Prevent size alignment wrapping buffer size to 0

2019-07-24 Thread Greg Kroah-Hartman
From: Sakari Ailus 

commit defcdc5d89ced780fb45196d539d6570ec5b1ba5 upstream.

PAGE_ALIGN() may wrap the buffer size around to 0. Prevent this by
checking that the aligned value is not smaller than the unaligned one.

Note on backporting to stable: the file used to be under
drivers/media/v4l2-core, it was moved to the current location after 4.14.

Signed-off-by: Sakari Ailus 
Cc: sta...@vger.kernel.org
Reviewed-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/common/videobuf2/videobuf2-core.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -207,6 +207,10 @@ static int __vb2_buf_mem_alloc(struct vb
for (plane = 0; plane < vb->num_planes; ++plane) {
unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
 
+   /* Did it wrap around? */
+   if (size < vb->planes[plane].length)
+   goto free;
+
mem_priv = call_ptr_memop(vb, alloc,
q->alloc_devs[plane] ? : q->dev,
q->dma_attrs, size, q->dma_dir, q->gfp_flags);




[PATCH 5.1 304/371] KVM: PPC: Book3S HV: Fix CR0 setting in TM emulation

2019-07-24 Thread Greg Kroah-Hartman
From: Michael Neuling 

commit 3fefd1cd95df04da67c83c1cb93b663f04b3324f upstream.

When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The
code currently sets:
CR0 <- 00 || MSR[TS]
but according to the ISA it should be:
CR0 <-  0 || MSR[TS] || 0

This fixes the bit shift to put the bits in the correct location.

This is a data integrity issue as CR0 is corrupted.

Fixes: 4bb3c7a0208f ("KVM: PPC: Book3S HV: Work around transactional memory 
bugs in POWER9")
Cc: sta...@vger.kernel.org # v4.17+
Tested-by: Suraj Jitindar Singh 
Signed-off-by: Michael Neuling 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kvm/book3s_hv_tm.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kvm/book3s_hv_tm.c
+++ b/arch/powerpc/kvm/book3s_hv_tm.c
@@ -131,7 +131,7 @@ int kvmhv_p9_tm_emulation(struct kvm_vcp
}
/* Set CR0 to indicate previous transactional state */
vcpu->arch.regs.ccr = (vcpu->arch.regs.ccr & 0x0fff) |
-   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 28);
+   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 29);
/* L=1 => tresume, L=0 => tsuspend */
if (instr & (1 << 21)) {
if (MSR_TM_SUSPENDED(msr))
@@ -175,7 +175,7 @@ int kvmhv_p9_tm_emulation(struct kvm_vcp
 
/* Set CR0 to indicate previous transactional state */
vcpu->arch.regs.ccr = (vcpu->arch.regs.ccr & 0x0fff) |
-   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 28);
+   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 29);
vcpu->arch.shregs.msr &= ~MSR_TS_MASK;
return RESUME_GUEST;
 
@@ -205,7 +205,7 @@ int kvmhv_p9_tm_emulation(struct kvm_vcp
 
/* Set CR0 to indicate previous transactional state */
vcpu->arch.regs.ccr = (vcpu->arch.regs.ccr & 0x0fff) |
-   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 28);
+   (((msr & MSR_TS_MASK) >> MSR_TS_S_LG) << 29);
vcpu->arch.shregs.msr = msr | MSR_TS_S;
return RESUME_GUEST;
}




[PATCH 5.1 303/371] KVM: PPC: Book3S HV: Clear pending decrementer exceptions on nested guest entry

2019-07-24 Thread Greg Kroah-Hartman
From: Suraj Jitindar Singh 

commit 3c25ab35fbc8526ac0c9b298e8a78e7ad7a55479 upstream.

If we enter an L1 guest with a pending decrementer exception then this
is cleared on guest exit if the guest has writtien a positive value
into the decrementer (indicating that it handled the decrementer
exception) since there is no other way to detect that the guest has
handled the pending exception and that it should be dequeued. In the
event that the L1 guest tries to run a nested (L2) guest immediately
after this and the L2 guest decrementer is negative (which is loaded
by L1 before making the H_ENTER_NESTED hcall), then the pending
decrementer exception isn't cleared and the L2 entry is blocked since
L1 has a pending exception, even though L1 may have already handled
the exception and written a positive value for it's decrementer. This
results in a loop of L1 trying to enter the L2 guest and L0 blocking
the entry since L1 has an interrupt pending with the outcome being
that L2 never gets to run and hangs.

Fix this by clearing any pending decrementer exceptions when L1 makes
the H_ENTER_NESTED hcall since it won't do this if it's decrementer
has gone negative, and anyway it's decrementer has been communicated
to L0 in the hdec_expires field and L0 will return control to L1 when
this goes negative by delivering an H_DECREMENTER exception.

Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on 
P9 for radix guests")
Cc: sta...@vger.kernel.org # v4.20+
Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kvm/book3s_hv.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4084,8 +4084,15 @@ int kvmhv_run_single_vcpu(struct kvm_run
 
preempt_enable();
 
-   /* cancel pending decrementer exception if DEC is now positive */
-   if (get_tb() < vcpu->arch.dec_expires && kvmppc_core_pending_dec(vcpu))
+   /*
+* cancel pending decrementer exception if DEC is now positive, or if
+* entering a nested guest in which case the decrementer is now owned
+* by L2 and the L1 decrementer is provided in hdec_expires
+*/
+   if (kvmppc_core_pending_dec(vcpu) &&
+   ((get_tb() < vcpu->arch.dec_expires) ||
+(trap == BOOK3S_INTERRUPT_SYSCALL &&
+ kvmppc_get_gpr(vcpu, 3) == H_ENTER_NESTED)))
kvmppc_core_dequeue_dec(vcpu);
 
trace_kvm_guest_exit(vcpu);




[PATCH 5.1 341/371] libnvdimm/pfn: fix fsdax-mode namespace info-block zero-fields

2019-07-24 Thread Greg Kroah-Hartman
From: Dan Williams 

commit 7e3e888dfc138089f4c15a81b418e88f0978f744 upstream.

At namespace creation time there is the potential for the "expected to
be zero" fields of a 'pfn' info-block to be filled with indeterminate
data.  While the kernel buffer is zeroed on allocation it is immediately
overwritten by nd_pfn_validate() filling it with the current contents of
the on-media info-block location.  For fields like, 'flags' and the
'padding' it potentially means that future implementations can not rely on
those fields being zero.

In preparation to stop using the 'start_pad' and 'end_trunc' fields for
section alignment, arrange for fields that are not explicitly
initialized to be guaranteed zero.  Bump the minor version to indicate
it is safe to assume the 'padding' and 'flags' are zero.  Otherwise,
this corruption is expected to benign since all other critical fields
are explicitly initialized.

Note The cc: stable is about spreading this new policy to as many
kernels as possible not fixing an issue in those kernels.  It is not
until the change titled "libnvdimm/pfn: Stop padding pmem namespaces to
section alignment" where this improper initialization becomes a problem.
So if someone decides to backport "libnvdimm/pfn: Stop padding pmem
namespaces to section alignment" (which is not tagged for stable), make
sure this pre-requisite is flagged.

Link: 
http://lkml.kernel.org/r/156092356065.979959.6681003754765958296.st...@dwillia2-desk3.amr.corp.intel.com
Fixes: 32ab0a3f5170 ("libnvdimm, pmem: 'struct page' for pmem")
Signed-off-by: Dan Williams 
Tested-by: Aneesh Kumar K.V [ppc64]
Cc: 
Cc: David Hildenbrand 
Cc: Jane Chu 
Cc: Jeff Moyer 
Cc: Jérôme Glisse 
Cc: Jonathan Corbet 
Cc: Logan Gunthorpe 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: Pavel Tatashin 
Cc: Toshi Kani 
Cc: Vlastimil Babka 
Cc: Wei Yang 
Cc: Jason Gunthorpe 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/nvdimm/dax_devs.c |2 +-
 drivers/nvdimm/pfn.h  |1 +
 drivers/nvdimm/pfn_devs.c |   18 +++---
 3 files changed, 17 insertions(+), 4 deletions(-)

--- a/drivers/nvdimm/dax_devs.c
+++ b/drivers/nvdimm/dax_devs.c
@@ -126,7 +126,7 @@ int nd_dax_probe(struct device *dev, str
nvdimm_bus_unlock(&ndns->dev);
if (!dax_dev)
return -ENOMEM;
-   pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+   pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
nd_pfn->pfn_sb = pfn_sb;
rc = nd_pfn_validate(nd_pfn, DAX_SIG);
dev_dbg(dev, "dax: %s\n", rc == 0 ? dev_name(dax_dev) : "");
--- a/drivers/nvdimm/pfn.h
+++ b/drivers/nvdimm/pfn.h
@@ -36,6 +36,7 @@ struct nd_pfn_sb {
__le32 end_trunc;
/* minor-version-2 record the base alignment of the mapping */
__le32 align;
+   /* minor-version-3 guarantee the padding and flags are zero */
u8 padding[4000];
__le64 checksum;
 };
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -420,6 +420,15 @@ static int nd_pfn_clear_memmap_errors(st
return 0;
 }
 
+/**
+ * nd_pfn_validate - read and validate info-block
+ * @nd_pfn: fsdax namespace runtime state / properties
+ * @sig: 'devdax' or 'fsdax' signature
+ *
+ * Upon return the info-block buffer contents (->pfn_sb) are
+ * indeterminate when validation fails, and a coherent info-block
+ * otherwise.
+ */
 int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 {
u64 checksum, offset;
@@ -565,7 +574,7 @@ int nd_pfn_probe(struct device *dev, str
nvdimm_bus_unlock(&ndns->dev);
if (!pfn_dev)
return -ENOMEM;
-   pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+   pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
nd_pfn = to_nd_pfn(pfn_dev);
nd_pfn->pfn_sb = pfn_sb;
rc = nd_pfn_validate(nd_pfn, PFN_SIG);
@@ -702,7 +711,7 @@ static int nd_pfn_init(struct nd_pfn *nd
u64 checksum;
int rc;
 
-   pfn_sb = devm_kzalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
+   pfn_sb = devm_kmalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
if (!pfn_sb)
return -ENOMEM;
 
@@ -711,11 +720,14 @@ static int nd_pfn_init(struct nd_pfn *nd
sig = DAX_SIG;
else
sig = PFN_SIG;
+
rc = nd_pfn_validate(nd_pfn, sig);
if (rc != -ENODEV)
return rc;
 
/* no info block, do init */;
+   memset(pfn_sb, 0, sizeof(*pfn_sb));
+
nd_region = to_nd_region(nd_pfn->dev.parent);
if (nd_region->ro) {
dev_info(&nd_pfn->dev,
@@ -768,7 +780,7 @@ static int nd_pfn_init(struct nd_pfn *nd
memcpy(pfn_sb->uuid, nd_pfn->uuid, 16);
memcpy(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16);
pfn_sb->version_major = cpu_to_le16(1);
-   pfn_sb->version_minor = cpu_to_le16(2);
+   p

[PATCH 5.1 302/371] KVM: PPC: Book3S HV: Signed extend decrementer value if not using large decrementer

2019-07-24 Thread Greg Kroah-Hartman
From: Suraj Jitindar Singh 

commit 869537709ebf1dc865e75c3fc97b23f8acf37c16 upstream.

On POWER9 the decrementer can operate in large decrementer mode where
the decrementer is 56 bits and signed extended to 64 bits. When not
operating in this mode the decrementer behaves as a 32 bit decrementer
which is NOT signed extended (as on POWER8).

Currently when reading a guest decrementer value we don't take into
account whether the large decrementer is enabled or not, and this
means the value will be incorrect when the guest is not using the
large decrementer. Fix this by sign extending the value read when the
guest isn't using the large decrementer.

Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on 
P9 for radix guests")
Cc: sta...@vger.kernel.org # v4.20+
Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kvm/book3s_hv.c |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3568,6 +3568,8 @@ int kvmhv_p9_guest_entry(struct kvm_vcpu
 
vcpu->arch.slb_max = 0;
dec = mfspr(SPRN_DEC);
+   if (!(lpcr & LPCR_LD)) /* Sign extend if not using large decrementer */
+   dec = (s32) dec;
tb = mftb();
vcpu->arch.dec_expires = dec + tb;
vcpu->cpu = -1;




[PATCH 5.1 358/371] mtd: rawnand: mtk: Correct low level time calculation of r/w cycle

2019-07-24 Thread Greg Kroah-Hartman
From: Xiaolei Li 

commit e1884ffddacc0424d7e785e6f8087bd12f7196db upstream.

At present, the flow of calculating AC timing of read/write cycle in SDR
mode is that:
At first, calculate high hold time which is valid for both read and write
cycle using the max value between tREH_min and tWH_min.
Secondly, calculate WE# pulse width using tWP_min.
Thridly, calculate RE# pulse width using the bigger one between tREA_max
and tRP_min.

But NAND SPEC shows that Controller should also meet write/read cycle time.
That is write cycle time should be more than tWC_min and read cycle should
be more than tRC_min. Obviously, we do not achieve that now.

This patch corrects the low level time calculation to meet minimum
read/write cycle time required. After getting the high hold time, WE# low
level time will be promised to meet tWP_min and tWC_min requirement,
and RE# low level time will be promised to meet tREA_max, tRP_min and
tRC_min requirement.

Fixes: edfee3619c49 ("mtd: nand: mtk: add ->setup_data_interface() hook")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Xiaolei Li 
Reviewed-by: Miquel Raynal 
Signed-off-by: Miquel Raynal 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/nand/raw/mtk_nand.c |   24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -508,7 +508,8 @@ static int mtk_nfc_setup_data_interface(
 {
struct mtk_nfc *nfc = nand_get_controller_data(chip);
const struct nand_sdr_timings *timings;
-   u32 rate, tpoecs, tprecs, tc2r, tw2r, twh, twst, trlt;
+   u32 rate, tpoecs, tprecs, tc2r, tw2r, twh, twst = 0, trlt = 0;
+   u32 thold;
 
timings = nand_get_sdr_timings(conf);
if (IS_ERR(timings))
@@ -544,11 +545,28 @@ static int mtk_nfc_setup_data_interface(
twh = DIV_ROUND_UP(twh * rate, 100) - 1;
twh &= 0xf;
 
-   twst = timings->tWP_min / 1000;
+   /* Calculate real WE#/RE# hold time in nanosecond */
+   thold = (twh + 1) * 100 / rate;
+   /* nanosecond to picosecond */
+   thold *= 1000;
+
+   /*
+* WE# low level time should be expaned to meet WE# pulse time
+* and WE# cycle time at the same time.
+*/
+   if (thold < timings->tWC_min)
+   twst = timings->tWC_min - thold;
+   twst = max(timings->tWP_min, twst) / 1000;
twst = DIV_ROUND_UP(twst * rate, 100) - 1;
twst &= 0xf;
 
-   trlt = max(timings->tREA_max, timings->tRP_min) / 1000;
+   /*
+* RE# low level time should be expaned to meet RE# pulse time,
+* RE# access time and RE# cycle time at the same time.
+*/
+   if (thold < timings->tRC_min)
+   trlt = timings->tRC_min - thold;
+   trlt = max3(trlt, timings->tREA_max, timings->tRP_min) / 1000;
trlt = DIV_ROUND_UP(trlt * rate, 100) - 1;
trlt &= 0xf;
 




[PATCH 5.1 354/371] powerpc/pseries: Fix xive=off command line

2019-07-24 Thread Greg Kroah-Hartman
From: Greg Kurz 

commit a3bf9fbdad600b1e4335dd90979f8d6072e4f602 upstream.

On POWER9, if the hypervisor supports XIVE exploitation mode, the
guest OS will unconditionally requests for the XIVE interrupt mode
even if XIVE was deactivated with the kernel command line xive=off.
Later on, when the spapr XIVE init code handles xive=off, it disables
XIVE and tries to fall back on the legacy mode XICS.

This discrepency causes a kernel panic because the hypervisor is
configured to provide the XIVE interrupt mode to the guest :

  kernel BUG at arch/powerpc/sysdev/xics/xics-common.c:135!
  ...
  NIP xics_smp_probe+0x38/0x98
  LR  xics_smp_probe+0x2c/0x98
  Call Trace:
xics_smp_probe+0x2c/0x98 (unreliable)
pSeries_smp_probe+0x40/0xa0
smp_prepare_cpus+0x62c/0x6ec
kernel_init_freeable+0x148/0x448
kernel_init+0x2c/0x148
ret_from_kernel_thread+0x5c/0x68

Look for xive=off during prom_init and don't ask for XIVE in this
case. One exception though: if the host only supports XIVE, we still
want to boot so we ignore xive=off.

Similarly, have the spapr XIVE init code to looking at the interrupt
mode negotiated during CAS, and ignore xive=off if the hypervisor only
supports XIVE.

Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt 
controller")
Cc: sta...@vger.kernel.org # v4.20
Reported-by: Pavithra R. Prakash 
Signed-off-by: Greg Kurz 
Reviewed-by: Cédric Le Goater 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/prom_init.c  |   16 +++-
 arch/powerpc/sysdev/xive/spapr.c |   52 ++-
 2 files changed, 66 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -174,6 +174,7 @@ static unsigned long __prombss prom_tce_
 
 #ifdef CONFIG_PPC_PSERIES
 static bool __prombss prom_radix_disable;
+static bool __prombss prom_xive_disable;
 #endif
 
 struct platform_support {
@@ -684,6 +685,12 @@ static void __init early_cmdline_parse(v
}
if (prom_radix_disable)
prom_debug("Radix disabled from cmdline\n");
+
+   opt = prom_strstr(prom_cmd_line, "xive=off");
+   if (opt) {
+   prom_xive_disable = true;
+   prom_debug("XIVE disabled from cmdline\n");
+   }
 #endif /* CONFIG_PPC_PSERIES */
 }
 
@@ -1092,10 +1099,17 @@ static void __init prom_parse_xive_model
switch (val) {
case OV5_FEAT(OV5_XIVE_EITHER): /* Either Available */
prom_debug("XIVE - either mode supported\n");
-   support->xive = true;
+   support->xive = !prom_xive_disable;
break;
case OV5_FEAT(OV5_XIVE_EXPLOIT): /* Only Exploitation mode */
prom_debug("XIVE - exploitation mode supported\n");
+   if (prom_xive_disable) {
+   /*
+* If we __have__ to do XIVE, we're better off ignoring
+* the command line rather than not booting.
+*/
+   prom_printf("WARNING: Ignoring cmdline option 
xive=off\n");
+   }
support->xive = true;
break;
case OV5_FEAT(OV5_XIVE_LEGACY): /* Only Legacy mode */
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -663,6 +664,55 @@ static bool xive_get_max_prio(u8 *max_pr
return true;
 }
 
+static const u8 *get_vec5_feature(unsigned int index)
+{
+   unsigned long root, chosen;
+   int size;
+   const u8 *vec5;
+
+   root = of_get_flat_dt_root();
+   chosen = of_get_flat_dt_subnode_by_name(root, "chosen");
+   if (chosen == -FDT_ERR_NOTFOUND)
+   return NULL;
+
+   vec5 = of_get_flat_dt_prop(chosen, "ibm,architecture-vec-5", &size);
+   if (!vec5)
+   return NULL;
+
+   if (size <= index)
+   return NULL;
+
+   return vec5 + index;
+}
+
+static bool xive_spapr_disabled(void)
+{
+   const u8 *vec5_xive;
+
+   vec5_xive = get_vec5_feature(OV5_INDX(OV5_XIVE_SUPPORT));
+   if (vec5_xive) {
+   u8 val;
+
+   val = *vec5_xive & OV5_FEAT(OV5_XIVE_SUPPORT);
+   switch (val) {
+   case OV5_FEAT(OV5_XIVE_EITHER):
+   case OV5_FEAT(OV5_XIVE_LEGACY):
+   break;
+   case OV5_FEAT(OV5_XIVE_EXPLOIT):
+   /* Hypervisor only supports XIVE */
+   if (xive_cmdline_disabled)
+   pr_warn("WARNING: Ignoring cmdline option 
xive=off\n");
+   return false;
+   default:
+   pr_warn("%s: Unknown xive support option: 0x%x\n",
+   __func__, val);
+   break;
+   }
+   }
+
+   r

[PATCH 5.1 353/371] powerpc/powernv: Fix stale iommu table base after VFIO

2019-07-24 Thread Greg Kroah-Hartman
From: Alexey Kardashevskiy 

commit 5636427d087a55842c1a199dfb839e6545d30e5d upstream.

The powernv platform uses @dma_iommu_ops for non-bypass DMA. These ops
need an iommu_table pointer which is stored in
dev->archdata.iommu_table_base. It is initialized during
pcibios_setup_device() which handles boot time devices. However when a
device is taken from the system in order to pass it through, the
default IOMMU table is destroyed but the pointer in a device is not
updated; also when a device is returned back to the system, a new
table pointer is not stored in dev->archdata.iommu_table_base either.
So when a just returned device tries using IOMMU, it crashes on
accessing stale iommu_table or its members.

This calls set_iommu_table_base() when the default window is created.
Note it used to be there before but was wrongly removed (see "fixes").
It did not appear before as these days most devices simply use bypass.

This adds set_iommu_table_base(NULL) when a device is taken from the
system to make it clear that IOMMU DMA cannot be used past that point.

Fixes: c4e9d3c1e65a ("powerpc/powernv/pseries: Rework device adding to IOMMU 
groups")
Cc: sta...@vger.kernel.org # v5.0+
Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/platforms/powernv/pci-ioda.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2459,6 +2459,14 @@ static long pnv_pci_ioda2_setup_default_
if (!pnv_iommu_bypass_disabled)
pnv_pci_ioda2_set_bypass(pe, true);
 
+   /*
+* Set table base for the case of IOMMU DMA use. Usually this is done
+* from dma_dev_setup() which is not called when a device is returned
+* from VFIO so do it here.
+*/
+   if (pe->pdev)
+   set_iommu_table_base(&pe->pdev->dev, tbl);
+
return 0;
 }
 
@@ -2546,6 +2554,8 @@ static void pnv_ioda2_take_ownership(str
pnv_pci_ioda2_unset_window(&pe->table_group, 0);
if (pe->pbus)
pnv_ioda_setup_bus_dma(pe, pe->pbus);
+   else if (pe->pdev)
+   set_iommu_table_base(&pe->pdev->dev, NULL);
iommu_tce_table_put(tbl);
 }
 




[PATCH 5.1 356/371] mmc: sdhci-msm: fix mutex while in spinlock

2019-07-24 Thread Greg Kroah-Hartman
From: Jorge Ramirez-Ortiz 

commit 5e6b6651d22de109ebf48ca00d0373bc2c0cc080 upstream.

mutexes can sleep and therefore should not be taken while holding a
spinlock. move clk_get_rate (can sleep) outside the spinlock protected
region.

Fixes: 83736352e0ca ("mmc: sdhci-msm: Update DLL reset sequence")
Cc: sta...@vger.kernel.org
Signed-off-by: Jorge Ramirez-Ortiz 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Vinod Koul 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci-msm.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -584,11 +584,14 @@ static int msm_init_cm_dll(struct sdhci_
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
int wait_cnt = 50;
-   unsigned long flags;
+   unsigned long flags, xo_clk = 0;
u32 config;
const struct sdhci_msm_offset *msm_offset =
msm_host->offset;
 
+   if (msm_host->use_14lpp_dll_reset && !IS_ERR_OR_NULL(msm_host->xo_clk))
+   xo_clk = clk_get_rate(msm_host->xo_clk);
+
spin_lock_irqsave(&host->lock, flags);
 
/*
@@ -636,10 +639,10 @@ static int msm_init_cm_dll(struct sdhci_
config &= CORE_FLL_CYCLE_CNT;
if (config)
mclk_freq = DIV_ROUND_CLOSEST_ULL((host->clock * 8),
-   clk_get_rate(msm_host->xo_clk));
+   xo_clk);
else
mclk_freq = DIV_ROUND_CLOSEST_ULL((host->clock * 4),
-   clk_get_rate(msm_host->xo_clk));
+   xo_clk);
 
config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config_2);




[PATCH 5.1 357/371] eCryptfs: fix a couple type promotion bugs

2019-07-24 Thread Greg Kroah-Hartman
From: Dan Carpenter 

commit 0bdf8a8245fdea6f075a5fede833a5fcf1b3466c upstream.

ECRYPTFS_SIZE_AND_MARKER_BYTES is type size_t, so if "rc" is negative
that gets type promoted to a high positive value and treated as success.

Fixes: 778aeb42a708 ("eCryptfs: Cleanup and optimize 
ecryptfs_lookup_interpose()")
Signed-off-by: Dan Carpenter 
[tyhicks: Use "if/else if" rather than "if/if"]
Cc: sta...@vger.kernel.org
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ecryptfs/crypto.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1019,8 +1019,10 @@ int ecryptfs_read_and_validate_header_re
 
rc = ecryptfs_read_lower(file_size, 0, ECRYPTFS_SIZE_AND_MARKER_BYTES,
 inode);
-   if (rc < ECRYPTFS_SIZE_AND_MARKER_BYTES)
-   return rc >= 0 ? -EINVAL : rc;
+   if (rc < 0)
+   return rc;
+   else if (rc < ECRYPTFS_SIZE_AND_MARKER_BYTES)
+   return -EINVAL;
rc = ecryptfs_validate_marker(marker);
if (!rc)
ecryptfs_i_size_init(file_size, inode);
@@ -1382,8 +1384,10 @@ int ecryptfs_read_and_validate_xattr_reg
 ecryptfs_inode_to_lower(inode),
 ECRYPTFS_XATTR_NAME, file_size,
 ECRYPTFS_SIZE_AND_MARKER_BYTES);
-   if (rc < ECRYPTFS_SIZE_AND_MARKER_BYTES)
-   return rc >= 0 ? -EINVAL : rc;
+   if (rc < 0)
+   return rc;
+   else if (rc < ECRYPTFS_SIZE_AND_MARKER_BYTES)
+   return -EINVAL;
rc = ecryptfs_validate_marker(marker);
if (!rc)
ecryptfs_i_size_init(file_size, inode);




[PATCH 5.1 342/371] coda: pass the host file in vma->vm_file on mmap

2019-07-24 Thread Greg Kroah-Hartman
From: Jan Harkes 

commit 7fa0a1da3dadfd9216df7745a1331fdaa0940d1c upstream.

Patch series "Coda updates".

The following patch series is a collection of various fixes for Coda,
most of which were collected from linux-fsdevel or linux-kernel but
which have as yet not found their way upstream.

This patch (of 22):

Various file systems expect that vma->vm_file points at their own file
handle, several use file_inode(vma->vm_file) to get at their inode or
use vma->vm_file->private_data.  However the way Coda wrapped mmap on a
host file broke this assumption, vm_file was still pointing at the Coda
file and the host file systems would scribble over Coda's inode and
private file data.

This patch fixes the incorrect expectation and wraps vm_ops->open and
vm_ops->close to allow Coda to track when the vm_area_struct is
destroyed so we still release the reference on the Coda file handle at
the right time.

Link: 
http://lkml.kernel.org/r/0e850c6e59c0b147dc2dcd51a3af004c948c3697.1558117389.git.jahar...@cs.cmu.edu
Signed-off-by: Jan Harkes 
Cc: Arnd Bergmann 
Cc: Colin Ian King 
Cc: Dan Carpenter 
Cc: David Howells 
Cc: Fabian Frederick 
Cc: Mikko Rapeli 
Cc: Sam Protsenko 
Cc: Yann Droneaud 
Cc: Zhouyang Jia 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/coda/file.c |   70 +++--
 1 file changed, 68 insertions(+), 2 deletions(-)

--- a/fs/coda/file.c
+++ b/fs/coda/file.c
@@ -27,6 +27,13 @@
 #include "coda_linux.h"
 #include "coda_int.h"
 
+struct coda_vm_ops {
+   atomic_t refcnt;
+   struct file *coda_file;
+   const struct vm_operations_struct *host_vm_ops;
+   struct vm_operations_struct vm_ops;
+};
+
 static ssize_t
 coda_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
 {
@@ -61,6 +68,34 @@ coda_file_write_iter(struct kiocb *iocb,
return ret;
 }
 
+static void
+coda_vm_open(struct vm_area_struct *vma)
+{
+   struct coda_vm_ops *cvm_ops =
+   container_of(vma->vm_ops, struct coda_vm_ops, vm_ops);
+
+   atomic_inc(&cvm_ops->refcnt);
+
+   if (cvm_ops->host_vm_ops && cvm_ops->host_vm_ops->open)
+   cvm_ops->host_vm_ops->open(vma);
+}
+
+static void
+coda_vm_close(struct vm_area_struct *vma)
+{
+   struct coda_vm_ops *cvm_ops =
+   container_of(vma->vm_ops, struct coda_vm_ops, vm_ops);
+
+   if (cvm_ops->host_vm_ops && cvm_ops->host_vm_ops->close)
+   cvm_ops->host_vm_ops->close(vma);
+
+   if (atomic_dec_and_test(&cvm_ops->refcnt)) {
+   vma->vm_ops = cvm_ops->host_vm_ops;
+   fput(cvm_ops->coda_file);
+   kfree(cvm_ops);
+   }
+}
+
 static int
 coda_file_mmap(struct file *coda_file, struct vm_area_struct *vma)
 {
@@ -68,6 +103,8 @@ coda_file_mmap(struct file *coda_file, s
struct coda_inode_info *cii;
struct file *host_file;
struct inode *coda_inode, *host_inode;
+   struct coda_vm_ops *cvm_ops;
+   int ret;
 
cfi = CODA_FTOC(coda_file);
BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
@@ -76,6 +113,13 @@ coda_file_mmap(struct file *coda_file, s
if (!host_file->f_op->mmap)
return -ENODEV;
 
+   if (WARN_ON(coda_file != vma->vm_file))
+   return -EIO;
+
+   cvm_ops = kmalloc(sizeof(struct coda_vm_ops), GFP_KERNEL);
+   if (!cvm_ops)
+   return -ENOMEM;
+
coda_inode = file_inode(coda_file);
host_inode = file_inode(host_file);
 
@@ -89,6 +133,7 @@ coda_file_mmap(struct file *coda_file, s
 * the container file on us! */
else if (coda_inode->i_mapping != host_inode->i_mapping) {
spin_unlock(&cii->c_lock);
+   kfree(cvm_ops);
return -EBUSY;
}
 
@@ -97,7 +142,29 @@ coda_file_mmap(struct file *coda_file, s
cfi->cfi_mapcount++;
spin_unlock(&cii->c_lock);
 
-   return call_mmap(host_file, vma);
+   vma->vm_file = get_file(host_file);
+   ret = call_mmap(vma->vm_file, vma);
+
+   if (ret) {
+   /* if call_mmap fails, our caller will put coda_file so we
+* should drop the reference to the host_file that we got.
+*/
+   fput(host_file);
+   kfree(cvm_ops);
+   } else {
+   /* here we add redirects for the open/close vm_operations */
+   cvm_ops->host_vm_ops = vma->vm_ops;
+   if (vma->vm_ops)
+   cvm_ops->vm_ops = *vma->vm_ops;
+
+   cvm_ops->vm_ops.open = coda_vm_open;
+   cvm_ops->vm_ops.close = coda_vm_close;
+   cvm_ops->coda_file = coda_file;
+   atomic_set(&cvm_ops->refcnt, 1);
+
+   vma->vm_ops = &cvm_ops->vm_ops;
+   }
+   return ret;
 }
 
 int coda_open(struct inode *coda_inode, struct file *coda_file)
@@ -207,4 +274,3 @@ const struct file_operations coda_

  1   2   3   4   5   6   7   8   9   10   >