[PATCH 3.2 17/59] [media] gspca: konica: add missing endpoint sanity check

[Ben Hutchings]

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

--

From: Johan Hovold 

commit aa58fedb8c7b6cf2f05941d238495f9e2f29655c upstream.

Make sure to check the number of endpoints to avoid accessing memory
beyond the endpoint array should a device lack the expected endpoints.

Note that, as far as I can tell, the gspca framework has already made
sure there is at least one endpoint in the current alternate setting so
there should be no risk for a NULL-pointer dereference here.

Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for
konica chipset using cams")

Cc: Hans de Goede 
Signed-off-by: Johan Hovold 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/video/gspca/konica.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/media/video/gspca/konica.c
+++ b/drivers/media/video/gspca/konica.c
@@ -290,6 +290,9 @@ static int sd_start(struct gspca_dev *gs
return -EIO;
}
 
+   if (alt->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
packet_size = le16_to_cpu(alt->endpoint[0].desc.wMaxPacketSize);
 
reg_w(gspca_dev, sd->brightness, BRIGHTNESS_REG);

[PATCH 3.2 10/59] zd1211rw: fix NULL-deref at probe

[Ben Hutchings]

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

--

From: Johan Hovold 

commit ca260ece6a57dc7d751e0685f51fa2c55d851873 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into 
WLAN device")
Cc: Daniel Drake 
Signed-off-by: Johan Hovold 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/zd1211rw/zd_usb.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -1281,6 +1281,9 @@ static int eject_installer(struct usb_in
u8 bulk_out_ep;
int r;
 
+   if (iface_desc->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
/* Find bulk out endpoint */
for (r = 1; r >= 0; r--) {
endpoint = _desc->endpoint[r].desc;

[PATCH 3.2 12/59] usb: hub: Do not attempt to autosuspend disconnected devices

[Ben Hutchings]

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

--

From: Guenter Roeck 

commit f5cccf49428447dfbc9edb7a04bb8fc316269781 upstream.

While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
the following crash was observed.

Unable to handle kernel NULL pointer dereference at virtual address 0218
pgd = ffc00165f000
[0218] *pgd=0174f003, *pud=0174f003,
*pmd=01750003, *pte=00e801751713
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
ppp_generic slhc tun
CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
Hardware name: Google Kevin (DT)
Workqueue: pm pm_runtime_work
task: ffc0ac54 ti: ffc0af4d4000 task.ti: ffc0af4d4000
PC is at autosuspend_check+0x74/0x174
LR is at autosuspend_check+0x70/0x174
...
Call trace:
[] autosuspend_check+0x74/0x174
[] usb_runtime_idle+0x20/0x40
[] __rpm_callback+0x48/0x7c
[] rpm_idle+0x1e8/0x498
[] pm_runtime_work+0x88/0xcc
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

Source:

(gdb) l *0xffc00080dcc0
0xffc00080dcc0 is in autosuspend_check
(drivers/usb/core/driver.c:1778).
1773/* We don't need to check interfaces that are
1774 * disabled for runtime PM.  Either they are unbound
1775 * or else their drivers don't support autosuspend
1776 * and so they are permanently active.
1777 */
1778if (intf->dev.power.disable_depth)
1779continue;
1780if (atomic_read(>dev.power.usage_count) > 0)
1781return -EBUSY;
1782w |= intf->needs_remote_wakeup;

Code analysis shows that intf is set to NULL in usb_disable_device() prior
to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
lock the usb device, and neither does any of the functions in the
traceback. This means that there is no protection against a race condition
where usb_disable_device() is removing dev->actconfig->interface[] pointers
while those are being accessed from autosuspend_check().

To solve the problem, synchronize and validate device state between
autosuspend_check() and usb_disconnect().

Acked-by: Alan Stern 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/driver.c | 3 +++
 drivers/usb/core/hub.c| 6 ++
 2 files changed, 9 insertions(+)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1649,6 +1649,9 @@ static int autosuspend_check(struct usb_
int w, i;
struct usb_interface*intf;
 
+   if (udev->state == USB_STATE_NOTATTACHED)
+   return -ENODEV;
+
/* Fail if autosuspend is disabled, or any interfaces are in use, or
 * any interface drivers require remote wakeup but it isn't available.
 */
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1781,6 +1781,12 @@ void usb_disconnect(struct usb_device **
dev_info(>dev, "USB disconnect, device number %d\n",
udev->devnum);
 
+   /*
+* Ensure that the pm runtime code knows that the USB device
+* is in the process of being disconnected.
+*/
+   pm_runtime_barrier(>dev);
+
usb_lock_device(udev);
 
/* Free up all the children before we remove this device */

[PATCH 3.2 02/59] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()

[Ben Hutchings]

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

--

From: Arnd Bergmann 

commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.

The driver uses a relatively large data structure on the stack, which
showed up on my radar as we get a warning with the "latent entropy"
GCC plugin:

drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

The warning is usually hidden as we raise the warning limit to 2048
when the plugin is enabled, but I'd like to lower that again in the
future, and making this function smaller helps to do that without
build regressions.

Further analysis shows that putting an 'i2c_client' structure on
the stack is not really supported, as the embedded 'struct device'
is not initialized here, and we are only saved by the fact that
the function that is called here does not use the pointer at all.

Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/video/pvrusb2/pvrusb2-eeprom.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

--- a/drivers/media/video/pvrusb2/pvrusb2-eeprom.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-eeprom.c
@@ -123,15 +123,10 @@ int pvr2_eeprom_analyze(struct pvr2_hdw
memset(,0,sizeof(tvdata));
 
eeprom = pvr2_eeprom_fetch(hdw);
-   if (!eeprom) return -EINVAL;
+   if (!eeprom)
+   return -EINVAL;
 
-   {
-   struct i2c_client fake_client;
-   /* Newer version expects a useless client interface */
-   fake_client.addr = hdw->eeprom_addr;
-   fake_client.adapter = >i2c_adap;
-   tveeprom_hauppauge_analog(_client,,eeprom);
-   }
+   tveeprom_hauppauge_analog(NULL, , eeprom);
 
trace_eeprom("eeprom assumed v4l tveeprom module");
trace_eeprom("eeprom direct call results:");

[PATCH 3.2 04/59] ath9k_htc: Add PID/VID for a Ubiquiti WiFiStation

[Ben Hutchings]

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

--

From: Mohammed Shafi Shajakhan 

commit 763cbac07674a648f1377b21ca66f577c103fa9a upstream.

Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter.  One
has an internal antenna, the other has an external antenna and
name suffix EXT.  They have separate USB ids and in distribution
openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows:

  0cf3  Atheros Communications, Inc.
   ...
   b002  Ubiquiti WiFiStation 802.11n [Atheros AR9271]
   b003  Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271]

Add b002 Ubiquiti WiFiStation in the PID/VID list.

Reported-by: Roger Price 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -38,6 +38,7 @@ static struct usb_device_id ath9k_hif_us
{ USB_DEVICE(0x04CA, 0x4605) }, /* Liteon */
{ USB_DEVICE(0x040D, 0x3801) }, /* VIA */
{ USB_DEVICE(0x0cf3, 0xb003) }, /* Ubiquiti WifiStation Ext */
+   { USB_DEVICE(0x0cf3, 0xb002) }, /* Ubiquiti WifiStation */
{ USB_DEVICE(0x057c, 0x8403) }, /* AVM FRITZ!WLAN 11N v2 USB */
 
{ USB_DEVICE(0x0cf3, 0x7015),

[PATCH 3.2 00/59] 3.2.92-rc1 review

[Ben Hutchings]

This is the start of the stable review cycle for the 3.2.92 release.
There are 59 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Aug 21 18:00:00 UTC 2017.
Anything received after that time might be too late.

A combined patch relative to 3.2.91 will be posted as an additional
response to this.  A shortlog and diffstat can be found below.

Ben.

-

Ajay Kaher (1):
  USB: Proper handling of Race Condition when two USB class drivers try to 
call init_usb_class simultaneously
 [2f86a96be0ccb1302b7eee7855dbee5ce4dc5dfb]

Alexander Tsoy (1):
  ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080
 [aea57edf80c6e96d6dc24757599396af99c02b19]

Alexey Brodkin (1):
  usb: Make sure usb/phy/of gets built-in
 [3d6159640da9c9175d1ca42f151fc1a14caded59]

Alexey Khoroshilov (1):
  [media] cx231xx: fix double free and leaks on failure path in 
cx231xx_usb_probe()
 [256d013a9bcc9a39b2e4b34ab19219bd054cf270]

Alyssa Milburn (4):
  [media] digitv: limit messages to buffer size
 [821117dc21083a99dd99174c10848d70ff43de29]
  [media] dw2102: limit messages to buffer size
 [950e252cb469f323740d78e4907843acef89eedb]
  [media] ttusb2: limit messages to buffer size
 [a12b8ab8c5ff7ccd7b107a564743507c850a441d]
  [media] zr364xx: enforce minimum size when reading header
 [ee0fe833d96793853335844b6d99fb76bd12cbeb]

Andrey Ryabinin (1):
  drm/i915: fix use-after-free in page_flip_completed()
 [05c41f926fcc7ef838c80a6a99d84f67b4e0b824]

Arnd Bergmann (2):
  [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
 [6830733d53a4517588e56227b9c8538633f0c496]
  fbdev: sti: don't select CONFIG_VT
 [34bf129a7f068e3108dbb051b4b05674e2a270e7]

Ashish Kalra (1):
  x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup
 [d594aa0277e541bb997aef0bc0a55172d8138340]

Bjorn Helgaas (1):
  PCI: Ignore write combining when mapping I/O port space
 [3a92c319c44a7bcee9f48dff9d97d001943b54c6]

Christoph Hellwig (1):
  libata: reject passthrough WRITE SAME requests
 [c6ade20f5e50e188d20b711a618b20dd1d50457e]

Christophe Leroy (1):
  net: ethernet: ucc_geth: fix MEM_PART_MURAM mode
 [8b8642af15ed14b9a7a34d3401afbcc274533e13]

Cong Wang (1):
  mqueue: fix a use-after-free in sys_mq_notify()
 [f991af3daabaecff34684fd51fac80319d1baad1]

Craig Gallek (1):
  ip6_tunnel: Fix missing tunnel encapsulation limit option
 [89a23c8b528bd2c89f3981573d6cd7d23840c8a6]

Dan Carpenter (2):
  [media] dw2102: some missing unlocks on error
 [324ed533bf0b23c309b805272c4ffcc5d51493a6]
  cifs: small underflow in cnvrtDosUnixTm()
 [564277eceeca01e02b1ef3e141cfb939184601b4]

David S. Miller (1):
  ipv6: Need to export ipv6_push_frag_opts for tunneling now.
 [5b8481fa42ac58484d633b558579e302aead64c1]

David Woodhouse (3):
  PCI: Fix another sanity check bug in /proc/pci mmap
 [17caf56731311c9596e7d38a70c88fcb6afa6a1b]
  PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms
 [6bccc7f426abd640f08d8c75fb22f99483f201b4]
  PCI: Only allow WC mmap on prefetchable resources
 [cef4d02305a06be581bb7f4353446717a1b319ec]

Dmitry Tunin (1):
  ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device
 [16ff1fb0e32f76a5d285a6f23b82d21aa52813c6]

Eric Dumazet (1):
  tcp: fix wraparound issue in tcp_lp
 [a9f11f963a546fea9144f6a6d1a307e814a387e7]

Frank Schaefer (1):
  [media] ov2640: fix vflip control
 [7f140fc2064bcd23e0490d8210650e2ef21c1c89]

Guenter Roeck (2):
  usb: hub: Do not attempt to autosuspend disconnected devices
 [f5cccf49428447dfbc9edb7a04bb8fc316269781]
  usb: hub: Fix error loop seen after hub communication errors
 [245b2eecee2aac6fdc77dcafaa73c33f9644c3c7]

Jason A. Donenfeld (1):
  padata: free correct variable
 [07a77929ba672d93642a56dc2255dd21e6e2290b]

Johan Hovold (8):
  [media] cx231xx-audio: fix NULL-deref at probe
 [65f921647f4c89a2068478c89691f39b309b58f7]
  [media] cx231xx-audio: fix init error path
 [fff1abc4d54e469140a699612b4db8d6397bfcba]
  [media] cx231xx-cards: fix NULL-deref at probe
 [0cd273bb5e4d1828efaaa8dfd11b7928131ed149]
  [media] gspca: konica: add missing endpoint sanity check
 [aa58fedb8c7b6cf2f05941d238495f9e2f29655c]
  [media] mceusb: fix NULL-deref at probe
 [03eb2a557ed552e920a0942b774aaf931596eec1]
  [media] usbvision: fix NULL-deref at probe
 [eacb975b48272f54532b62f515a3cf7eefa35123]
  ath9k_htc: fix NULL-deref at probe
 [ebeb36670ecac36c179b5fb5d5c88ff03ba191ec]
  zd1211rw: fix NULL-deref at probe
 [ca260ece6a57dc7d751e0685f51fa2c55d851873]

Josh 

[PATCH 3.2 11/59] usb: hub: Fix error loop seen after hub communication errors

[Ben Hutchings]

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

--

From: Guenter Roeck 

commit 245b2eecee2aac6fdc77dcafaa73c33f9644c3c7 upstream.

While stress testing a usb controller using a bind/unbind looop, the
following error loop was observed.

usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
usb 7-1.2: hub failed to enable device, error -108
usb 7-1-port2: cannot disable (err = -22)
usb 7-1-port2: couldn't allocate usb_device
usb 7-1-port2: cannot disable (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = 
-22)

This continues forever. After adding tracebacks into the code,
the call sequence leading to this is found to be as follows.

[] hub_activate+0x368/0x7b8
[] hub_resume+0x2c/0x3c
[] usb_resume_interface.isra.6+0x128/0x158
[] usb_suspend_both+0x1e8/0x288
[] usb_runtime_suspend+0x3c/0x98
[] __rpm_callback+0x48/0x7c
[] rpm_callback+0xa8/0xd4
[] rpm_suspend+0x84/0x758
[] rpm_idle+0x2c8/0x498
[] __pm_runtime_idle+0x60/0xac
[] usb_autopm_put_interface+0x6c/0x7c
[] hub_event+0x10ac/0x12ac
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

kick_hub_wq() is called from hub_activate() even after failures to
communicate with the hub. This results in an endless sequence of
hub event -> hub activate -> wq trigger -> hub event -> ...

Provide two solutions for the problem.

- Only trigger the hub event queue if communication with the hub
  is successful.
- After a suspend failure, only resume already suspended interfaces
  if the communication with the device is still possible.

Each of the changes fixes the observed problem. Use both to improve
robustness.

Acked-by: Alan Stern 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/driver.c | 18 ++
 drivers/usb/core/hub.c|  5 -
 2 files changed, 22 insertions(+), 1 deletion(-)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1218,6 +1218,24 @@ static int usb_suspend_both(struct usb_d
 */
if (udev->parent && !PMSG_IS_AUTO(msg))
status = 0;
+
+   /*
+* If the device is inaccessible, don't try to resume
+* suspended interfaces and just return the error.
+*/
+   if (status && status != -EBUSY) {
+   int err;
+   u16 devstat;
+
+   err = usb_get_status(udev, USB_RECIP_DEVICE, 0,
+);
+   if (err) {
+   dev_err(>dev,
+   "Failed to suspend device, error %d\n",
+   status);
+   goto done;
+   }
+   }
}
 
/* If the suspend failed, resume interfaces that did get suspended */
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -884,6 +884,9 @@ static void hub_activate(struct usb_hub
 
portstatus = portchange = 0;
status = hub_port_status(hub, port1, , );
+   if (status)
+   goto abort;
+
if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
dev_dbg(hub->intfdev,
"port %d: status %04x change %04x\n",
@@ -1011,7 +1014,7 @@ static void hub_activate(struct usb_hub
 
/* Scan 

[PATCH 3.2 07/59] ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080

[Ben Hutchings]

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

--

From: Alexander Tsoy 

commit aea57edf80c6e96d6dc24757599396af99c02b19 upstream.

This device is available under different marketing names:
WLM-20U2 - Wireless USB Dongle for Toshiba TVs
GN-1080 - Wireless LAN Module for Toshiba MFPs.

Signed-off-by: Alexander Tsoy 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -59,6 +59,8 @@ static struct usb_device_id ath9k_hif_us
  .driver_info = AR9280_USB },  /* Buffalo WLI-UV-AG300P */
{ USB_DEVICE(0x04da, 0x3904),
  .driver_info = AR9280_USB },
+   { USB_DEVICE(0x0930, 0x0a08),
+ .driver_info = AR9280_USB },  /* Toshiba WLM-20U2 and GN-1080 */
 
{ USB_DEVICE(0x0cf3, 0x20ff),
  .driver_info = STORAGE_DEVICE },

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[annie li]

On 8/18/2017 5:14 AM, Roger Pau Monné wrote:

On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:

If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
device or guest is gone.
And this could cause some problems, for example, if the backend device type
is file, some loop devices and blkback thread always lingers there forever
after guest is destroyed, and this causes failure of umounting repositories
unless rebooting the dom0. So stop all threads properly and return -EBUSY
if any queue has inflight I/O.

Signed-off-by: Annie Li 
Reviewed-by: Herbert van den Bergh 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Adnan Misherfi 
---
  drivers/block/xen-blkback/xenbus.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 792da68..2adb859 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
  {
struct pending_req *req, *n;
unsigned int j, r;
+   bool busy = false;
  
  	for (r = 0; r < blkif->nr_rings; r++) {

struct xen_blkif_ring *ring = >rings[r];
@@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 * don't have any discard_io or other_io requests. So, checking
 * for inflight IO is enough.
 */
-   if (atomic_read(>inflight) > 0)
-   return -EBUSY;
+   if (atomic_read(>inflight) > 0) {
+   busy = true;
+   continue;
+   }

I guess I'm missing something, but I don't see how this is solving the
problem described in the description.

If the problem is that xen_blkif_disconnect returns without cleaning
all the queues, this patch keeps the current behavior, just that it
will try to remove more queues before returning, as opposed to
returning when finding the first busy queue.

Before checking inflight, following code stops the blkback thread,
if (ring->xenblkd) {
kthread_stop(ring->xenblkd);
wake_up(>shutdown_wq);
}
This patch allows thread of every queue has the chance to get stopped. 
Otherwise, only thread of queue before(including) first busy one get 
stopped, threads of remaining queue will still run, and these blkthread 
and corresponding loop device will linger forever even after guest is 
destroyed.


Thanks
Annie

Re: [PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue

[Hans Verkuil]

On 08/18/17 16:16, Stanimir Varbanov wrote:
> This change is intended to give to the v4l2 drivers a choice to
> change the default behavior of the v4l2-core DMA mapping direction
> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.
> 
> Initially the issue with DMA mapping direction has been found in
> Venus encoder driver where the hardware (firmware side) adds few
> lines padding on bottom of the image buffer, and the consequence
> is triggering of IOMMU protection faults.
> 
> This will help supporting venus encoder (and probably other drivers
> in the future) which wants to map output type of buffers as
> read/write.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 17 -
>  include/media/videobuf2-core.h   | 13 +
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 0924594989b4..cb115ba6a1d2 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
>  static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   void *mem_priv;
>   int plane;
>   int ret = -ENOMEM;
> @@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>  
>   mem_priv = call_ptr_memop(vb, alloc,
>   q->alloc_devs[plane] ? : q->dev,
> - q->dma_attrs, size, dma_dir, q->gfp_flags);
> + q->dma_attrs, size, q->dma_dir, q->gfp_flags);
>   if (IS_ERR_OR_NULL(mem_priv)) {
>   if (mem_priv)
>   ret = PTR_ERR(mem_priv);
> @@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
> void *pb)
>   void *mem_priv;
>   unsigned int plane;
>   int ret = 0;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   bool reacquired = vb->planes[0].mem_priv == NULL;
>  
>   memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
> @@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
> const void *pb)
>   mem_priv = call_ptr_memop(vb, get_userptr,
>   q->alloc_devs[plane] ? : q->dev,
>   planes[plane].m.userptr,
> - planes[plane].length, dma_dir);
> + planes[plane].length, q->dma_dir);
>   if (IS_ERR(mem_priv)) {
>   dprintk(1, "failed acquiring userspace memory for plane 
> %d\n",
>   plane);
> @@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> const void *pb)
>   void *mem_priv;
>   unsigned int plane;
>   int ret = 0;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   bool reacquired = vb->planes[0].mem_priv == NULL;
>  
>   memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
> @@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> const void *pb)
>   /* Acquire each plane's memory */
>   mem_priv = call_ptr_memop(vb, attach_dmabuf,
>   q->alloc_devs[plane] ? : q->dev,
> - dbuf, planes[plane].length, dma_dir);
> + dbuf, planes[plane].length, q->dma_dir);
>   if (IS_ERR(mem_priv)) {
>   dprintk(1, "failed to attach dmabuf\n");
>   ret = PTR_ERR(mem_priv);
> @@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q)
>   if (q->buf_struct_size == 0)
>   q->buf_struct_size = sizeof(struct vb2_buffer);
>  
> + if (q->bidirectional)
> + q->dma_dir = DMA_BIDIRECTIONAL;
> + else
> + q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> +
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(vb2_core_queue_init);
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index cb97c224be73..ede09fff1de8 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -427,6 +427,17 @@ struct vb2_buf_ops {
>   * @dev: device to use for the default allocation context if the driver
>   *   doesn't fill in the @alloc_devs array.
>   * @dma_attrs:   DMA attributes to use for the DMA.
> + * @dma_dir: DMA mapping direction.

This one should be moved to the 'Private elements' section. This is set and used
by the vb2 core, drivers won't 

Re: [PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue

[Stanimir Varbanov]

Hi Hans,

On 08/18/2017 05:30 PM, Hans Verkuil wrote:
> On 08/18/17 16:16, Stanimir Varbanov wrote:
>> This change is intended to give to the v4l2 drivers a choice to
>> change the default behavior of the v4l2-core DMA mapping direction
>> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
>> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.
>>
>> Initially the issue with DMA mapping direction has been found in
>> Venus encoder driver where the hardware (firmware side) adds few
>> lines padding on bottom of the image buffer, and the consequence
>> is triggering of IOMMU protection faults.
>>
>> This will help supporting venus encoder (and probably other drivers
>> in the future) which wants to map output type of buffers as
>> read/write.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/v4l2-core/videobuf2-core.c | 17 -
>>  include/media/videobuf2-core.h   | 13 +
>>  2 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 0924594989b4..cb115ba6a1d2 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
>>  static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>>  {
>>  struct vb2_queue *q = vb->vb2_queue;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  void *mem_priv;
>>  int plane;
>>  int ret = -ENOMEM;
>> @@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>>  
>>  mem_priv = call_ptr_memop(vb, alloc,
>>  q->alloc_devs[plane] ? : q->dev,
>> -q->dma_attrs, size, dma_dir, q->gfp_flags);
>> +q->dma_attrs, size, q->dma_dir, q->gfp_flags);
>>  if (IS_ERR_OR_NULL(mem_priv)) {
>>  if (mem_priv)
>>  ret = PTR_ERR(mem_priv);
>> @@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
>> const void *pb)
>>  void *mem_priv;
>>  unsigned int plane;
>>  int ret = 0;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  bool reacquired = vb->planes[0].mem_priv == NULL;
>>  
>>  memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
>> @@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
>> const void *pb)
>>  mem_priv = call_ptr_memop(vb, get_userptr,
>>  q->alloc_devs[plane] ? : q->dev,
>>  planes[plane].m.userptr,
>> -planes[plane].length, dma_dir);
>> +planes[plane].length, q->dma_dir);
>>  if (IS_ERR(mem_priv)) {
>>  dprintk(1, "failed acquiring userspace memory for plane 
>> %d\n",
>>  plane);
>> @@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
>> const void *pb)
>>  void *mem_priv;
>>  unsigned int plane;
>>  int ret = 0;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  bool reacquired = vb->planes[0].mem_priv == NULL;
>>  
>>  memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
>> @@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
>> const void *pb)
>>  /* Acquire each plane's memory */
>>  mem_priv = call_ptr_memop(vb, attach_dmabuf,
>>  q->alloc_devs[plane] ? : q->dev,
>> -dbuf, planes[plane].length, dma_dir);
>> +dbuf, planes[plane].length, q->dma_dir);
>>  if (IS_ERR(mem_priv)) {
>>  dprintk(1, "failed to attach dmabuf\n");
>>  ret = PTR_ERR(mem_priv);
>> @@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q)
>>  if (q->buf_struct_size == 0)
>>  q->buf_struct_size = sizeof(struct vb2_buffer);
>>  
>> +if (q->bidirectional)
>> +q->dma_dir = DMA_BIDIRECTIONAL;
>> +else
>> +q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>> +
>>  return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_core_queue_init);
>> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
>> index cb97c224be73..ede09fff1de8 100644
>> --- a/include/media/videobuf2-core.h
>> +++ b/include/media/videobuf2-core.h
>> @@ -427,6 +427,17 @@ struct vb2_buf_ops {
>>   * @dev:device to use for the default allocation context if the driver
>>   *  doesn't fill in the @alloc_devs array.
>>   * @dma_attrs:  DMA attributes to use for the DMA.
>> + * @dma_dir:DMA mapping direction.
> 

Re: [PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay

[jeffy]

Hi Mark,

On 08/18/2017 07:52 PM, Mark Brown wrote:

On Fri, Aug 18, 2017 at 09:41:54AM +0800, jeffy wrote:

On 08/18/2017 01:11 AM, Mark Brown wrote:

On Thu, Aug 17, 2017 at 12:44:10PM +0800, Jeffy Chen wrote:



-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
-  If this option is specified, which means it's required dmic need
-  delay for DMIC to ready so that rt5514 can avoid recording before
-  DMIC send valid data



Why would nobody ever want to use this in future?



hmmm, check again, rt5514 fixed this issue in there driver instead in:
a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.



so we don't need this...


You don't need it on your board for new DTs but why is it not possible
that another board might need it?



this property is added in:
3a6f9dce6116 ASoC: rk3399_gru_sound: fix recording pop at first attempt

to fix pop noise by performing a delay after set dmic clk.

the binding said "dmic-wakeup-delay-ms", but actually driver parses 
"dmic-delay":


+   /* Set DMIC delay */
+   ret = device_property_read_u32(>dev, "dmic-delay",
+   _dmic_delay);

@@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct 
snd_pcm_subst

ream *substream,
return ret;
}

+   /* Wait for DMIC stable */
+   msleep(rt5514_dmic_delay); <-- perform a delay after set dmic clk
+
return 0;
 }

then realtek guys fixed this issue in the rt5514 codec driver:
a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.

+   device_property_read_u32(dev, "realtek,dmic-init-delay-ms",
+   >pdata.dmic_init_delay);

@@ -452,6 +452,9 @@ static int rt5514_set_dmic_clk(struct 
snd_soc_dapm_widget *w,

RT5514_CLK_DMIC_OUT_SEL_MASK,
idx << RT5514_CLK_DMIC_OUT_SEL_SFT);

+   if (rt5514->pdata.dmic_init_delay)
+   msleep(rt5514->pdata.dmic_init_delay); <-- perform a 
delay after set dmic clk



so we don't need to deal with it in every boards' drivers which using 
rt5514 codec, and we are using this new property now:

ag dmic arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
620:realtek,dmic-init-delay = <20>;   < oops, seems 
missing "-ms" at the end, guess due to realtek patch ends up differently 
on upstream. will send a patch to fix it later.



anyway, i think it's ok to remove that out-dated property in our driver :)

Re: [PATCH 3.16 000/134] 3.16.47-rc1 review

[Guenter Roeck]

On 08/18/2017 06:13 AM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.47 release.
There are 134 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Aug 21 18:00:00 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 107 pass: 107 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

RE: [PATCH net-next] net: hns3: Add support to change MTU in hardware & netdev

[Salil Mehta]

Hi Andrew

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Friday, August 18, 2017 2:31 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); lipeng (Y);
> dan.carpen...@oracle.com; mehta.salil@gmail.com;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> r...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH net-next] net: hns3: Add support to change MTU in
> hardware & netdev
> 
> On Fri, Aug 18, 2017 at 12:35:58PM +0100, Salil Mehta wrote:
> > This patch adds the following support to the HNS3 driver:
> > 1. Support to change the Maximum Transmission Unit of a
> >netdevice and of a port in hardware .
> > 2. Initializes the supported MTU range for the netdevice.
> >
> > Signed-off-by: lipeng 
> > Signed-off-by: Salil Mehta 
> > ---
> >  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> ++
> >  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h |  1 +
> >  2 files changed, 47 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> > index e731f87..8e3711e 100644
> > --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> > @@ -1278,11 +1278,53 @@ static int hns3_ndo_set_vf_vlan(struct
> net_device *netdev, int vf, u16 vlan,
> > return ret;
> >  }
> >
> > +static int hns3_nic_change_mtu(struct net_device *netdev, int
> new_mtu)
> > +{
> > +   struct hns3_nic_priv *priv = netdev_priv(netdev);
> > +   struct hnae3_handle *h = priv->ae_handle;
> > +   bool if_running = netif_running(netdev);
> > +   int ret;
> > +
> > +   /* no change in MTU */
> > +   if (new_mtu == netdev->mtu)
> > +   return 0;
> 
> Hi Salil
> 
> It is worth reading the core code:
> 
> http://elixir.free-
> electrons.com/linux/latest/source/net/core/dev.c#L6713
Right. Looks like it is already being done since 4.10-rc1 because of
the patches Floated by Jarod Wilson .
Link: https://lkml.org/lkml/2016/10/13/270

Will remove this duplicate check!

Thanks
Salil 
>  +
> > +   if (!h->ae_algo->ops->set_mtu)
> > +   return -ENOTSUPP;
> > +
> > +   /* if this was called with netdev up then bring netdevice down */
> > +   if (if_running) {
> > +   (void)hns3_nic_net_stop(netdev);
> > +   msleep(100);
> > +   }
> > +
> > +   ret = h->ae_algo->ops->set_mtu(h, new_mtu);
> > +   if (ret) {
> > +   netdev_err(netdev, "failed to change MTU in hardware %d\n",
> > +  ret);
> > +   return ret;
> > +   }
> > +
> > +   /* assign newly changed mtu to netdevice as well */
> > +   netdev->mtu = new_mtu;
> 
> http://elixir.free-
> electrons.com/linux/latest/source/net/core/dev.c#L6698
Again, it is being done by core now since 4.10-rc1.
Link: https://lkml.org/lkml/2016/10/13/270

Will remove this duplicate code!

Thanks
Salil
> 
> > +
> > +   /* if the netdev was running earlier, bring it up again */
> > +   if (if_running) {
> > +   if (hns3_nic_net_open(netdev)) {
> > +   netdev_err(netdev, "MTU, couldnt up netdev again\n");
> > +   ret = -EINVAL;
> > +   }
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static const struct net_device_ops hns3_nic_netdev_ops = {
> > .ndo_open   = hns3_nic_net_open,
> > .ndo_stop   = hns3_nic_net_stop,
> > .ndo_start_xmit = hns3_nic_net_xmit,
> > .ndo_set_mac_address= hns3_nic_net_set_mac_address,
> > +   .ndo_change_mtu = hns3_nic_change_mtu,
> > .ndo_set_features   = hns3_nic_set_features,
> > .ndo_get_stats64= hns3_nic_get_stats64,
> > .ndo_setup_tc   = hns3_nic_setup_tc,
> > @@ -2752,6 +2794,10 @@ static int hns3_client_init(struct
> hnae3_handle *handle)
> > goto out_reg_netdev_fail;
> > }
> >
> > +   /* MTU range: 68 - 9706 */
> > +   netdev->min_mtu = ETH_MIN_MTU;
> 
> http://elixir.free-
> electrons.com/linux/latest/source/net/ethernet/eth.c#L361
Supported range of Min and Max MTU should be at the discretion
of the driver. Therefore, initialization looks fine to me.

I could not clearly understand the problem being highlighted
over here. Could you further clarify?

Thanks
Salil
> 
> > +   netdev->max_mtu = HNS3_MAX_MTU - (ETH_HLEN + ETH_FCS_LEN +
> VLAN_HLEN);
> > +
> > return ret;
> >
> >  out_reg_netdev_fail:
> > diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> > index a6e8f15..7e87461 100644
> > --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> > @@ -76,6 +76,7 @@ enum hns3_nic_state {
> >  #define HNS3_RING_NAME_LEN 16
> >  #define HNS3_BUFFER_SIZE_2048  2048
> >  #define 

Re: [PATCH 3.2 00/59] 3.2.92-rc1 review

[Guenter Roeck]

On 08/18/2017 06:13 AM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.92 release.
There are 59 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Aug 21 18:00:00 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 86 pass: 86 fail: 0
Qemu test results:
total: 69 pass: 69 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[PATCH 09/18] PCI: endpoint: functions/pci-epf-test: Remove the ->remove() callback

[Kishon Vijay Abraham I]

From: Shawn Lin 

epf_test is allocated using devm_kzalloc. Hence it's not required to
explicitly free it in remove() callback. Since ->remove() callback
doesn't do anything other than freeing epf_test, remove the
->remove() callback.

Signed-off-by: Shawn Lin 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index a0aea2500690..4ddc6e8f9fe7 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -496,14 +496,6 @@ static int pci_epf_test_probe(struct pci_epf *epf)
return 0;
 }
 
-static int pci_epf_test_remove(struct pci_epf *epf)
-{
-   struct pci_epf_test *epf_test = epf_get_drvdata(epf);
-
-   kfree(epf_test);
-   return 0;
-}
-
 static struct pci_epf_ops ops = {
.unbind = pci_epf_test_unbind,
.bind   = pci_epf_test_bind,
@@ -513,7 +505,6 @@ static struct pci_epf_ops ops = {
 static struct pci_epf_driver test_driver = {
.driver.name= "pci_epf_test",
.probe  = pci_epf_test_probe,
-   .remove = pci_epf_test_remove,
.id_table   = pci_epf_test_ids,
.ops= ,
.owner  = THIS_MODULE,
-- 
2.11.0

[PATCH 07/18] PCI: endpoint: functions/pci-epf-test: Add support to use _any_ BAR's to map PCI_ENDPOINT_TEST regs

[Kishon Vijay Abraham I]

pci_epf_test always maps the PCI_ENDPOINT_TEST registers to BAR_0. But if
BAR_0 is reserved for some other purpose (like in TI's K2G BAR_0 is
mapped to application registers and cannot be used to map any other
regions), PCI_ENDPOINT_TEST registers cannot be mapped making pci_epf_test
unusable. Add support to use any BAR's to map PCI_ENDPOINT_TEST registers.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 60 +++
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 1a27d7950f2c..e378dae9e510 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -54,6 +54,7 @@ static struct workqueue_struct *kpcitest_workqueue;
 struct pci_epf_test {
void*reg[6];
struct pci_epf  *epf;
+   enum pci_barno  test_reg_bar;
struct delayed_work cmd_handler;
 };
 
@@ -74,7 +75,11 @@ static struct pci_epf_header test_header = {
.interrupt_pin  = PCI_INTERRUPT_INTA,
 };
 
-static int bar_size[] = { 512, 1024, 16384, 131072, 1048576 };
+struct pci_epf_test_data {
+   enum pci_barno  test_reg_bar;
+};
+
+static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
 
 static int pci_epf_test_copy(struct pci_epf_test *epf_test)
 {
@@ -86,7 +91,8 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test)
struct pci_epf *epf = epf_test->epf;
struct device *dev = >dev;
struct pci_epc *epc = epf->epc;
-   struct pci_epf_test_reg *reg = epf_test->reg[0];
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
+   struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
 
src_addr = pci_epc_mem_alloc_addr(epc, _phys_addr, reg->size);
if (!src_addr) {
@@ -145,7 +151,8 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test)
struct pci_epf *epf = epf_test->epf;
struct device *dev = >dev;
struct pci_epc *epc = epf->epc;
-   struct pci_epf_test_reg *reg = epf_test->reg[0];
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
+   struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
 
src_addr = pci_epc_mem_alloc_addr(epc, _addr, reg->size);
if (!src_addr) {
@@ -195,7 +202,8 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
struct pci_epf *epf = epf_test->epf;
struct device *dev = >dev;
struct pci_epc *epc = epf->epc;
-   struct pci_epf_test_reg *reg = epf_test->reg[0];
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
+   struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
 
dst_addr = pci_epc_mem_alloc_addr(epc, _addr, reg->size);
if (!dst_addr) {
@@ -247,7 +255,8 @@ static void pci_epf_test_raise_irq(struct pci_epf_test 
*epf_test)
u8 msi_count;
struct pci_epf *epf = epf_test->epf;
struct pci_epc *epc = epf->epc;
-   struct pci_epf_test_reg *reg = epf_test->reg[0];
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
+   struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
 
reg->status |= STATUS_IRQ_RAISED;
msi_count = pci_epc_get_msi(epc);
@@ -268,13 +277,15 @@ static void pci_epf_test_cmd_handler(struct work_struct 
*work)
 cmd_handler.work);
struct pci_epf *epf = epf_test->epf;
struct pci_epc *epc = epf->epc;
-   volatile struct pci_epf_test_reg *reg = epf_test->reg[0];
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
+   struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
 
command = reg->command;
if (!command)
goto reset_handler;
 
reg->command = 0;
+   reg->status = 0;
 
if (command & COMMAND_RAISE_LEGACY_IRQ) {
reg->status = STATUS_IRQ_RAISED;
@@ -360,6 +371,7 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
struct pci_epc *epc = epf->epc;
struct device *dev = >dev;
struct pci_epf_test *epf_test = epf_get_drvdata(epf);
+   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
 
flags = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32;
if (sizeof(dma_addr_t) == 0x8)
@@ -372,7 +384,7 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
if (ret) {
pci_epf_free_space(epf, epf_test->reg[bar], bar);
dev_err(dev, "failed to set BAR%d\n", bar);
-   if (bar == BAR_0)
+   if (bar == test_reg_bar)
return ret;
}
}
@@ -386,17 +398,20 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
struct device *dev = >dev;
void *base;
int 

[PATCH 10/18] PCI: dwc: designware: Provide page_size to pci_epc_mem

[Kishon Vijay Abraham I]

Use the newly introduced __pci_epc_mem_init instead of pci_epc_mem_init
to provide page_size to pci_epc_mem. This is in preparation for
adding EP support to K2G which has a restriction that the
address region should be either divided into 1MB/2MB/4MB or 8MB
sizes (Ref: 11.14.4.9.1 Outbound Address Translation in K2G TRM SPRUHY8F
January 2016 – Revised May 2017).

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/pcie-designware-ep.c | 3 ++-
 drivers/pci/dwc/pcie-designware.h| 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index 398406393f37..e70ebe3b9b6f 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -328,7 +328,8 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ret < 0)
epc->max_functions = 1;
 
-   ret = pci_epc_mem_init(epc, ep->phys_base, ep->addr_size);
+   ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
+ep->page_size);
if (ret < 0) {
dev_err(dev, "Failed to initialize address space\n");
return ret;
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index b4d2a89f8e58..714f6f21ea93 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -186,6 +186,7 @@ struct dw_pcie_ep {
struct dw_pcie_ep_ops   *ops;
phys_addr_t phys_base;
size_t  addr_size;
+   size_t  page_size;
u8  bar_to_atu[6];
phys_addr_t *outbound_addr;
unsigned long   ib_window_map;
-- 
2.11.0

[PATCH 18/18] tools: PCI: Add a missing option help line

[Kishon Vijay Abraham I]

From: Stan Drozd 

Add a missing option help line for performing legacy interrupt
test.

Signed-off-by: Stan Drozd 
Signed-off-by: Kishon Vijay Abraham I 
---
 tools/pci/pcitest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index ad54a58d7dda..caf38c3959bf 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -173,6 +173,7 @@ int main(int argc, char **argv)
"\t-D  PCI endpoint test device 
{default: /dev/pci-endpoint-test.0}\n"
"\t-b  BAR test (bar number between 
0..5)\n"
"\t-m  MSI test (msi number between 
1..32)\n"
+   "\t-l   Legacy irq test\n"
"\t-r   Read buffer test\n"
"\t-w   Write buffer test\n"
"\t-c   Copy buffer test\n"
-- 
2.11.0

[PATCH 17/18] misc: pci_endpoint_test: Enable/Disable MSI using module param

[Kishon Vijay Abraham I]

In certain platforms like TI's DRA7 SoCs, use of legacy PCI
interrupt is exclusive with use of MSI (Section 24.9.4.6.2.1
Legacy PCI Interrupts in
http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf).

However pci_endpoint_test driver enables MSI by default in probe.
In order for pci_endpoint_test to be able to test legacy interrupt,
MSI should be disabled. Add a module param 'no_msi' to disable MSI
(only when legacy interrupt has to be tested).

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/pci_endpoint_test.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 1f37ad39b169..1f64d943794d 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -72,6 +72,11 @@ static DEFINE_IDA(pci_endpoint_test_ida);
 
 #define to_endpoint_test(priv) container_of((priv), struct pci_endpoint_test, \
miscdev)
+
+bool no_msi;
+module_param(no_msi, bool, 0444);
+MODULE_PARM_DESC(no_msi, "Disable MSI interrupt in pci_endpoint_test");
+
 enum pci_barno {
BAR_0,
BAR_1,
@@ -451,7 +456,6 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
int err;
int irq = 0;
int id;
-   bool no_msi = false;
char name[20];
enum pci_barno bar;
void __iomem *base;
-- 
2.11.0

[PATCH 13/18] misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR

[Kishon Vijay Abraham I]

pci_endpoint_test driver assumes the PCI_ENDPOINT_TEST registers will
always be mapped to BAR_0. This need not always be the case like in
TI's K2G where BAR_0 is mapped to PCI controller application registers.
Add support so that PCI_ENDPOINT_TEST registers can be mapped to any BAR.
Change the bar_size used for BAR test accordingly.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/pci_endpoint_test.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 09c10f426b64..5fc0f6c6a9e5 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -90,9 +90,14 @@ struct pci_endpoint_test {
/* mutex to protect the ioctls */
struct mutexmutex;
struct miscdevice miscdev;
+   enum pci_barno test_reg_bar;
 };
 
-static int bar_size[] = { 4, 512, 1024, 16384, 131072, 1048576 };
+struct pci_endpoint_test_data {
+   enum pci_barno test_reg_bar;
+};
+
+static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
 
 static inline u32 pci_endpoint_test_readl(struct pci_endpoint_test *test,
  u32 offset)
@@ -147,6 +152,9 @@ static bool pci_endpoint_test_bar(struct pci_endpoint_test 
*test,
 
size = bar_size[barno];
 
+   if (barno == test->test_reg_bar)
+   size = 0x4;
+
for (j = 0; j < size; j += 4)
pci_endpoint_test_bar_writel(test, barno, j, 0xA0A0A0A0);
 
@@ -390,6 +398,8 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
void __iomem *base;
struct device *dev = >dev;
struct pci_endpoint_test *test;
+   struct pci_endpoint_test_data *data;
+   enum pci_barno test_reg_bar = BAR_0;
struct miscdevice *misc_device;
 
if (pci_is_bridge(pdev))
@@ -399,7 +409,13 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
if (!test)
return -ENOMEM;
 
+   test->test_reg_bar = 0;
test->pdev = pdev;
+
+   data = (struct pci_endpoint_test_data *)ent->driver_data;
+   if (data)
+   test_reg_bar = data->test_reg_bar;
+
init_completion(>irq_raised);
mutex_init(>mutex);
 
@@ -441,14 +457,15 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
base = pci_ioremap_bar(pdev, bar);
if (!base) {
dev_err(dev, "failed to read BAR%d\n", bar);
-   WARN_ON(bar == BAR_0);
+   WARN_ON(bar == test_reg_bar);
}
test->bar[bar] = base;
}
 
-   test->base = test->bar[0];
+   test->base = test->bar[test_reg_bar];
if (!test->base) {
-   dev_err(dev, "Cannot perform PCI test without BAR0\n");
+   dev_err(dev, "Cannot perform PCI test without BAR%d\n",
+   test_reg_bar);
goto err_iounmap;
}
 
-- 
2.11.0

[PATCH 15/18] misc: pci_endpoint_test: Add support to not enable MSI interrupts

[Kishon Vijay Abraham I]

Some platforms like TI's K2G have a restriction that the host side
buffer address should be aligned to either 1MB/2MB/4MB or 8MB
addresses depending on how it is configured in the endpoint
(Ref: 11.14.4.9.1 Outbound Address Translation in K2G TRM SPRUHY8F
January 2016 – Revised May 2017). This restriction also applies to
the MSI addresses provided by the RC. However it's not possible
for the RC to know about this restriction and it may not provide
1MB/2MB/4MB or 8MB aligned address. So MSI interrupts should be
disabled even if the K2G EP has MSI capabiltiy register. Add
support to not enable MSI interrupts in pci_endpoint_test driver
so that it can be used to test K2G EP.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/pci_endpoint_test.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 5f6bd23ab657..5cbb25cf276c 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -97,6 +97,7 @@ struct pci_endpoint_test {
 struct pci_endpoint_test_data {
enum pci_barno test_reg_bar;
size_t alignment;
+   bool no_msi;
 };
 
 static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
@@ -449,8 +450,9 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
 {
int i;
int err;
-   int irq;
+   int irq = 0;
int id;
+   bool no_msi = false;
char name[20];
enum pci_barno bar;
void __iomem *base;
@@ -475,6 +477,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
if (data) {
test_reg_bar = data->test_reg_bar;
test->alignment = data->alignment;
+   no_msi = data->no_msi;
}
 
init_completion(>irq_raised);
@@ -494,9 +497,11 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
 
pci_set_master(pdev);
 
-   irq = pci_alloc_irq_vectors(pdev, 1, 32, PCI_IRQ_MSI);
-   if (irq < 0)
-   dev_err(dev, "failed to get MSI interrupts\n");
+   if (!no_msi) {
+   irq = pci_alloc_irq_vectors(pdev, 1, 32, PCI_IRQ_MSI);
+   if (irq < 0)
+   dev_err(dev, "failed to get MSI interrupts\n");
+   }
 
err = devm_request_irq(dev, pdev->irq, pci_endpoint_test_irqhandler,
   IRQF_SHARED, DRV_MODULE_NAME, test);
-- 
2.11.0

[PATCH 01/18] PCI: endpoint: pci-epc-core: Use of_dma_configure() to set initial dma mask

[Kishon Vijay Abraham I]

Use of_dma_configure() to set the initial dma mask of epf device. This
helps to get rid of "Coherent DMA mask 0x0 (pfn 0x0-0x1) covers a smaller
range of system memory than the DMA zone pfn" warning in certain platforms
like TI's K2G resulting in coherent dma mask not being set.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index caa7be10e473..42c2a1156325 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -370,6 +371,7 @@ EXPORT_SYMBOL_GPL(pci_epc_write_header);
 int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf)
 {
unsigned long flags;
+   struct device *dev = epc->dev.parent;
 
if (epf->epc)
return -EBUSY;
@@ -381,8 +383,12 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf 
*epf)
return -EINVAL;
 
epf->epc = epc;
-   dma_set_coherent_mask(>dev, epc->dev.coherent_dma_mask);
-   epf->dev.dma_mask = epc->dev.dma_mask;
+   if (dev->of_node) {
+   of_dma_configure(>dev, dev->of_node);
+   } else {
+   dma_set_coherent_mask(>dev, epc->dev.coherent_dma_mask);
+   epf->dev.dma_mask = epc->dev.dma_mask;
+   }
 
spin_lock_irqsave(>lock, flags);
list_add_tail(>list, >pci_epf);
@@ -500,6 +506,7 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
epc->dev.class = pci_epc_class;
epc->dev.dma_mask = dev->dma_mask;
+   epc->dev.parent = dev;
epc->ops = ops;
 
ret = dev_set_name(>dev, "%s", dev_name(dev));
-- 
2.11.0

[PATCH 04/18] PCI: endpoint: pci-epc-mem: Add support for configurable page size

[Kishon Vijay Abraham I]

pci-epc-mem uses a page size equal to *PAGE_SIZE* (usually 4KB) to
manage the address space. However certain platforms like TI's K2G
has a restriction that this address space should be either divided
into 1MB/2MB/4MB or 8MB sizes (Ref: 11.14.4.9.1 Outbound Address
Translation in K2G TRM SPRUHY8F January 2016 – Revised May 2017).
Add support to handle different page sizes here.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-mem.c | 59 --
 include/linux/pci-epc.h|  8 +-
 2 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-mem.c 
b/drivers/pci/endpoint/pci-epc-mem.c
index 3a94cc1caf22..83b7d5d3fc3e 100644
--- a/drivers/pci/endpoint/pci-epc-mem.c
+++ b/drivers/pci/endpoint/pci-epc-mem.c
@@ -24,21 +24,54 @@
 #include 
 
 /**
- * pci_epc_mem_init() - initialize the pci_epc_mem structure
+ * pci_epc_mem_get_order() - determine the allocation order of a memory size
+ * @mem: address space of the endpoint controller
+ * @size: the size for which to get the order
+ *
+ * Reimplement get_order() for mem->page_size since the generic get_order
+ * always gets order with a constant PAGE_SIZE.
+ */
+static int pci_epc_mem_get_order(struct pci_epc_mem *mem, size_t size)
+{
+   int order;
+   unsigned int page_shift = ilog2(mem->page_size);
+
+   size--;
+   size >>= page_shift;
+#if BITS_PER_LONG == 32
+   order = fls(size);
+#else
+   order = fls64(size);
+#endif
+   return order;
+}
+
+/**
+ * __pci_epc_mem_init() - initialize the pci_epc_mem structure
  * @epc: the EPC device that invoked pci_epc_mem_init
  * @phys_base: the physical address of the base
  * @size: the size of the address space
+ * @page_size: size of each page
  *
  * Invoke to initialize the pci_epc_mem structure used by the
  * endpoint functions to allocate mapped PCI address.
  */
-int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_base, size_t size)
+int __pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_base, size_t size,
+  size_t page_size)
 {
int ret;
struct pci_epc_mem *mem;
unsigned long *bitmap;
-   int pages = size >> PAGE_SHIFT;
-   int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
+   unsigned int page_shift;
+   int pages;
+   int bitmap_size;
+
+   if (page_size < PAGE_SIZE)
+   page_size = PAGE_SIZE;
+
+   page_shift = ilog2(page_size);
+   pages = size >> page_shift;
+   bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
 
mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem) {
@@ -54,6 +87,7 @@ int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t 
phys_base, size_t size)
 
mem->bitmap = bitmap;
mem->phys_base = phys_base;
+   mem->page_size = page_size;
mem->pages = pages;
mem->size = size;
 
@@ -67,7 +101,7 @@ int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t 
phys_base, size_t size)
 err:
 return ret;
 }
-EXPORT_SYMBOL_GPL(pci_epc_mem_init);
+EXPORT_SYMBOL_GPL(__pci_epc_mem_init);
 
 /**
  * pci_epc_mem_exit() - cleanup the pci_epc_mem structure
@@ -101,13 +135,17 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
int pageno;
void __iomem *virt_addr;
struct pci_epc_mem *mem = epc->mem;
-   int order = get_order(size);
+   unsigned int page_shift = ilog2(mem->page_size);
+   int order;
+
+   size = ALIGN(size, mem->page_size);
+   order = pci_epc_mem_get_order(mem, size);
 
pageno = bitmap_find_free_region(mem->bitmap, mem->pages, order);
if (pageno < 0)
return NULL;
 
-   *phys_addr = mem->phys_base + (pageno << PAGE_SHIFT);
+   *phys_addr = mem->phys_base + (pageno << page_shift);
virt_addr = ioremap(*phys_addr, size);
if (!virt_addr)
bitmap_release_region(mem->bitmap, pageno, order);
@@ -129,11 +167,14 @@ void pci_epc_mem_free_addr(struct pci_epc *epc, 
phys_addr_t phys_addr,
   void __iomem *virt_addr, size_t size)
 {
int pageno;
-   int order = get_order(size);
struct pci_epc_mem *mem = epc->mem;
+   unsigned int page_shift = ilog2(mem->page_size);
+   int order;
 
iounmap(virt_addr);
-   pageno = (phys_addr - mem->phys_base) >> PAGE_SHIFT;
+   pageno = (phys_addr - mem->phys_base) >> page_shift;
+   size = ALIGN(size, mem->page_size);
+   order = pci_epc_mem_get_order(mem, size);
bitmap_release_region(mem->bitmap, pageno, order);
 }
 EXPORT_SYMBOL_GPL(pci_epc_mem_free_addr);
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index af5edbf3eea3..f7a04e1af112 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -62,11 +62,13 @@ struct pci_epc_ops {
  * @size: the size of the PCI address space
  * @bitmap: bitmap to manage the PCI address space
  * @pages: number of bits 

[PATCH 05/18] PCI: endpoint: functions/pci-epf-test: Add "volatile" to pci_epf_test_reg

[Kishon Vijay Abraham I]

struct pci_epf_test_reg is the MEMSPACE of pci-epf-test function driver
that will be accessed by the "host" for programming the pci-epf-test
device. So this structure shouldn't be subjected to compiler optimization
in pci_epf_test_cmd_handler() since the values can be changed by code
outside the scope of current code at any time.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 53fff8030337..5cbc05a0762d 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -267,7 +267,7 @@ static void pci_epf_test_cmd_handler(struct work_struct 
*work)
 cmd_handler.work);
struct pci_epf *epf = epf_test->epf;
struct pci_epc *epc = epf->epc;
-   struct pci_epf_test_reg *reg = epf_test->reg[0];
+   volatile struct pci_epf_test_reg *reg = epf_test->reg[0];
 
if (!reg->command)
goto reset_handler;
-- 
2.11.0

[PATCH 03/18] PCI: endpoint: pci-epf-core: Make ->remove() callback optional

[Kishon Vijay Abraham I]

Make ->remove() callback optional so that endpoint function drivers
don't have to populate empty ->remove() callback functions.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epf-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index 60ea0c51161e..ae6fac5995e3 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -333,11 +333,12 @@ static int pci_epf_device_probe(struct device *dev)
 
 static int pci_epf_device_remove(struct device *dev)
 {
-   int ret;
+   int ret = 0;
struct pci_epf *epf = to_pci_epf(dev);
struct pci_epf_driver *driver = to_pci_epf_driver(dev->driver);
 
-   ret = driver->remove(epf);
+   if (driver->remove)
+   ret = driver->remove(epf);
epf->driver = NULL;
 
return ret;
-- 
2.11.0

Re: Possible null pointer dereference in adutux.ko

[Anton Volkov]

On 15.08.2017 18:58, Oliver Neukum wrote:

Am Dienstag, den 15.08.2017, 16:38 +0300 schrieb Anton Volkov:

On 15.08.2017 16:20, Oliver Neukum wrote:


Am Dienstag, den 15.08.2017, 15:59 +0300 schrieb Anton Volkov:


Hello.

While searching for races in the Linux kernel I've come across
"drivers/usb/misc/adutux.ko" module. Here is a question that I came up
with while analyzing results. Lines are given using the info from Linux
v4.12.

Consider the following case:

Thread 1:   Thread 2:
adu_release
->adu_release_internal  adu_disconnect
   udev->dev>dev->udev = NULL
   (adutux.c: line 298)  (adutux.c: line 771)
 usb_deregister_dev

Comments in the source code point at the possibility of adu_release()
being called separately from adu_disconnect(). adu_release() and
adu_disconnect() acquire different mutexes, so they are not protected
from one another. If adu_disconnect() changes dev->udev before its value
is read in adu_release_internal() there will be a NULL pointer
dereference on a read attempt. Is this case feasible from your point of
view?

Thank you for your time.


Hi,

your analysis seems correct to me. In fact it looks like

66d4bc30d128e7c7ac4cf64aa78cb76e971cec5b
USB: adutux: remove custom debug macro

more or less broke disconnect on this driver
(the URBs can also finish after dev->udev = NULL)

Do you want to do a fix or do you want me to do it?

Regards
Oliver



Hello, Oliver.

I am not sure about the best way to solve this problem. If you have any
ideas about it then it would probably be better if you could handle the
fix. Or if you share the ideas I can prepare a patch.


Hi,

given the age of the drivers I would suggest to simply remove the debugging 
statements

Regards
Oliver



Hello, Oliver.

Looks like deletion of lots of debug print won't solve the race problem 
because there are other places that could potentially try to dereference 
dev->udev when disconnect has already poisoned it. For example in 
adu_open there are calls to usb_fill_int_urb with dev->udev as a 
parameter to be dereferenced inside the function.


There are other possible solutions, if I understand correctly:
1) although it is described that adutux_mutex should be used to protect 
only open_count, it usually protects the whole body of a function, so we 
could probably place it before the locking of dev->mtx;
2) move poisoning of dev->udev after usb_deregister_dev in order to wait 
for all other callbacks to finish.


What do you think?

Regards,
Anton

-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru

[PATCH 3.16 117/134] fbdev: sti: don't select CONFIG_VT

[Ben Hutchings]

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

--

From: Arnd Bergmann 

commit 34bf129a7f068e3108dbb051b4b05674e2a270e7 upstream.

While working on another build error, I ran into several variations of
this dependency loop:

subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8:symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:677:symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by 
DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:137:symbol DRM_KMS_CMA_HELPER is selected by 
DRM_HDLCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/arm/Kconfig:6:  symbol DRM_HDLCD depends on OF
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/of/Kconfig:4:   symbol OF is selected by X86_INTEL_CE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:523:   symbol X86_INTEL_CE depends on X86_IO_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1011:  symbol X86_IO_APIC depends on X86_LOCAL_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1005:  symbol X86_LOCAL_APIC depends on X86_UP_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:980:   symbol X86_UP_APIC depends on PCI_MSI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/pci/Kconfig:11: symbol PCI_MSI is selected by AMD_IOMMU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:106:  symbol AMD_IOMMU depends on IOMMU_SUPPORT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:5:symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2:  symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5:  symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:183:   symbol ACPI_VIDEO is selected by INPUT

This doesn't currently show up as I fixed the 'THERMAL' part of it,
but I noticed that the FB_STI dependency should not be there but
was introduced by slightly incorrect bug-fix patch that tried to
fix a link error.

Instead of selecting 'VT' to make us enter the drivers/video/console
directory at compile-time, it's sufficient to build the
drivers/video/console/sticore.c file by adding its directory
to when CONFIG_FB_STI is enabled. Alternatively, we could move the
sticore code to another directory that is always built when we
have at STI_CONSOLE or FB_STI enabled.

Fixes: 17085a934592 ("parisc: stifb: should depend on STI_CONSOLE")
Signed-off-by: Arnd Bergmann 
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: Alexander Beregalov 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings 
---
 drivers/video/Makefile  | 1 +
 drivers/video/fbdev/Kconfig | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_VGASTATE)+= vga
 obj-$(CONFIG_HDMI)+= hdmi.o
 
 obj-$(CONFIG_VT) += console/
+obj-$(CONFIG_FB_STI) += 

[PATCH 3.16 121/134] x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init()

[Ben Hutchings]

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

--

From: Laura Abbott 

commit 861ce4a3244c21b0af64f880d5bfe5e6e2fb9e4a upstream.

'__vmalloc_start_set' currently only gets set in initmem_init() when
!CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address
with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing
a kernel crash:

  [mm/usercopy] 517e1fbeb6: kernel BUG at arch/x86/mm/physaddr.c:78!

Set '__vmalloc_start_set' appropriately for that case as well.

Reported-by: kbuild test robot 
Signed-off-by: Laura Abbott 
Reviewed-by: Kees Cook 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: dc16ecf7fd1f ("x86-32: use specific __vmalloc_start_set flag in 
__virt_addr_valid")
Link: 
http://lkml.kernel.org/r/1494278596-30373-1-git-send-email-labb...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings 
---
 arch/x86/mm/numa_32.c | 1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/mm/numa_32.c
+++ b/arch/x86/mm/numa_32.c
@@ -100,5 +100,6 @@ void __init initmem_init(void)
printk(KERN_DEBUG "High memory starts at vaddr %08lx\n",
(ulong) pfn_to_kaddr(highstart_pfn));
 
+   __vmalloc_start_set = true;
setup_bootmem_allocator();
 }

[PATCH 3.16 133/134] ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output

[Ben Hutchings]

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

--

From: Zheng Li 

commit e4c5e13aa45c23692e4acf56f0b3533f328199b2 upstream.

There is an inconsistent conditional judgement between __ip6_append_data
and ip6_finish_output functions, the variable length in __ip6_append_data
just include the length of application's payload and udp6 header, don't
include the length of ipv6 header, but in ip6_finish_output use
(skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the
length of ipv6 header.

That causes some particular application's udp6 payloads whose length are
between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even
though the rst->dev support UFO feature.

Add the length of ipv6 header to length in __ip6_append_data to keep
consistent conditional judgement as ip6_finish_output for ip6 fragment.

Signed-off-by: Zheng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ip6_output.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1291,7 +1291,7 @@ emsgsize:
 
skb = skb_peek_tail(>sk_write_queue);
cork->length += length;
-   if (((length > mtu) ||
+   if length + fragheaderlen) > mtu) ||
 (skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !dst_xfrm(>dst) &&

[PATCH 3.16 120/134] fs/xattr.c: zero out memory copied to userspace in getxattr

[Ben Hutchings]

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

--

From: Michal Hocko 

commit 81be3dee96346fbe08c31be5ef74f03f6b63cf68 upstream.

getxattr uses vmalloc to allocate memory if kzalloc fails.  This is
filled by vfs_getxattr and then copied to the userspace.  vmalloc,
however, doesn't zero out the memory so if the specific implementation
of the xattr handler is sloppy we can theoretically expose a kernel
memory.  There is no real sign this is really the case but let's make
sure this will not happen and use vzalloc instead.

Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation 
failures")
Link: http://lkml.kernel.org/r/20170306103327.2766-1-mho...@kernel.org
Acked-by: Kees Cook 
Reported-by: Vlastimil Babka 
Signed-off-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/xattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -455,7 +455,7 @@ getxattr(struct dentry *d, const char __
size = XATTR_SIZE_MAX;
kvalue = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
if (!kvalue) {
-   vvalue = vmalloc(size);
+   vvalue = vzalloc(size);
if (!vvalue)
return -ENOMEM;
kvalue = vvalue;

[PATCH 3.2 59/59] packet: fix tp_reserve race in packet_set_ring

[Ben Hutchings]

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

--

From: Willem de Bruijn 

commit c27927e372f0785f3303e8fad94b85945e2c97b7 upstream.

Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.

This bug was discovered by syzkaller.

Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Reported-by: Andrey Konovalov 
Signed-off-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/packet/af_packet.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3132,14 +3132,19 @@ packet_setsockopt(struct socket *sock, i
 
if (optlen != sizeof(val))
return -EINVAL;
-   if (po->rx_ring.pg_vec || po->tx_ring.pg_vec)
-   return -EBUSY;
if (copy_from_user(, optval, sizeof(val)))
return -EFAULT;
if (val > INT_MAX)
return -EINVAL;
-   po->tp_reserve = val;
-   return 0;
+   lock_sock(sk);
+   if (po->rx_ring.pg_vec || po->tx_ring.pg_vec) {
+   ret = -EBUSY;
+   } else {
+   po->tp_reserve = val;
+   ret = 0;
+   }
+   release_sock(sk);
+   return ret;
}
case PACKET_LOSS:
{

[PATCH 3.16 122/134] virtio_net: fix support for small rings

[Ben Hutchings]

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

--

From: "Michael S. Tsirkin" 

commit d85b758f72b05a774045545f24d70980e3e9aac4 upstream.

When ring size is small (<32 entries) making buffers smaller means a
full ring might not be able to hold enough buffers to fit a single large
packet.

Make sure a ring full of buffers is large enough to allow at least one
packet of max size.

Fixes: 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag 
allocators")
Signed-off-by: Michael S. Tsirkin 
[bwh: Backported to 3.16:
 - There's no net_device::max_mtu, so always set packet_len = IP_MAX_MTU
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/virtio_net.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int napi_weight = NAPI_POLL_WEIGHT;
 module_param(napi_weight, int, 0444);
@@ -92,6 +93,9 @@ struct receive_queue {
/* RX: fragments + linear part + virtio header */
struct scatterlist sg[MAX_SKB_FRAGS + 2];
 
+   /* Min single buffer size for mergeable buffers case. */
+   unsigned int min_buf_len;
+
/* Name of this receive queue: input.$index */
char name[40];
 };
@@ -600,13 +604,14 @@ static int add_recvbuf_big(struct receiv
return err;
 }
 
-static unsigned int get_mergeable_buf_len(struct ewma *avg_pkt_len)
+static unsigned int get_mergeable_buf_len(struct receive_queue *rq,
+ struct ewma *avg_pkt_len)
 {
const size_t hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
unsigned int len;
 
len = hdr_len + clamp_t(unsigned int, ewma_read(avg_pkt_len),
-   GOOD_PACKET_LEN, PAGE_SIZE - hdr_len);
+   rq->min_buf_len - hdr_len, PAGE_SIZE - hdr_len);
return ALIGN(len, MERGEABLE_BUFFER_ALIGN);
 }
 
@@ -618,7 +623,7 @@ static int add_recvbuf_mergeable(struct
int err;
unsigned int len, hole;
 
-   len = get_mergeable_buf_len(>mrg_avg_pkt_len);
+   len = get_mergeable_buf_len(rq, >mrg_avg_pkt_len);
if (unlikely(!skb_page_frag_refill(len, alloc_frag, gfp)))
return -ENOMEM;
 
@@ -1462,6 +1467,21 @@ static void virtnet_del_vqs(struct virtn
virtnet_free_queues(vi);
 }
 
+/* How large should a single buffer be so a queue full of these can fit at
+ * least one full packet?
+ * Logic below assumes the mergeable buffer header is used.
+ */
+static unsigned int mergeable_min_buf_len(struct virtnet_info *vi, struct 
virtqueue *vq)
+{
+   const unsigned int hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
+   unsigned int rq_size = virtqueue_get_vring_size(vq);
+   unsigned int packet_len = IP_MAX_MTU;
+   unsigned int buf_len = hdr_len + ETH_HLEN + VLAN_HLEN + packet_len;
+   unsigned int min_buf_len = DIV_ROUND_UP(buf_len, rq_size);
+
+   return max(min_buf_len, hdr_len);
+}
+
 static int virtnet_find_vqs(struct virtnet_info *vi)
 {
vq_callback_t **callbacks;
@@ -1517,6 +1537,7 @@ static int virtnet_find_vqs(struct virtn
 
for (i = 0; i < vi->max_queue_pairs; i++) {
vi->rq[i].vq = vqs[rxq2vq(i)];
+   vi->rq[i].min_buf_len = mergeable_min_buf_len(vi, vi->rq[i].vq);
vi->sq[i].vq = vqs[txq2vq(i)];
}
 
@@ -1601,7 +1622,8 @@ static ssize_t mergeable_rx_buffer_size_
 
BUG_ON(queue_index >= vi->max_queue_pairs);
avg = >rq[queue_index].mrg_avg_pkt_len;
-   return sprintf(buf, "%u\n", get_mergeable_buf_len(avg));
+   return sprintf(buf, "%u\n",
+  get_mergeable_buf_len(>rq[queue_index], avg));
 }
 
 static struct rx_queue_attribute mergeable_rx_buffer_size_attribute =

[PATCH 3.16 102/134] arm64: KVM: Fix decoding of Rt/Rt2 when trapping AArch32 CP accesses

[Ben Hutchings]

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

--

From: Marc Zyngier 

commit c667186f1c01ca8970c78568b7ffd74e51ee upstream.

Our 32bit CP14/15 handling inherited some of the ARMv7 code for handling
the trapped system registers, completely missing the fact that the
fields for Rt and Rt2 are now 5 bit wide, and not 4...

Let's fix it, and provide an accessor for the most common Rt case.

Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
[bwh: Backported to 3.16:
 - Use literal numbers in kvm_vcpu_sys_get_rt()
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/arm64/include/asm/kvm_emulate.h | 6 ++
 arch/arm64/kvm/sys_regs.c| 8 
 2 files changed, 10 insertions(+), 4 deletions(-)

--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -187,6 +187,12 @@ static inline u8 kvm_vcpu_trap_get_fault
return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_FSC_TYPE;
 }
 
+static inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
+{
+   u32 esr = kvm_vcpu_get_hsr(vcpu);
+   return (esr >> 5) & 0x1f;
+}
+
 static inline unsigned long kvm_vcpu_get_mpidr(struct kvm_vcpu *vcpu)
 {
return vcpu_sys_reg(vcpu, MPIDR_EL1);
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -504,12 +504,12 @@ int kvm_handle_cp15_64(struct kvm_vcpu *
 {
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
-   int Rt2 = (hsr >> 10) & 0xf;
+   int Rt2 = (hsr >> 10) & 0x1f;
 
params.is_aarch32 = true;
params.is_32bit = false;
params.CRm = (hsr >> 1) & 0xf;
-   params.Rt = (hsr >> 5) & 0xf;
+   params.Rt = kvm_vcpu_sys_get_rt(vcpu);
params.is_write = ((hsr & 1) == 0);
 
params.Op0 = 0;
@@ -554,7 +554,7 @@ int kvm_handle_cp15_32(struct kvm_vcpu *
params.is_aarch32 = true;
params.is_32bit = true;
params.CRm = (hsr >> 1) & 0xf;
-   params.Rt  = (hsr >> 5) & 0xf;
+   params.Rt  = kvm_vcpu_sys_get_rt(vcpu);
params.is_write = ((hsr & 1) == 0);
params.CRn = (hsr >> 10) & 0xf;
params.Op0 = 0;
@@ -629,7 +629,7 @@ int kvm_handle_sys_reg(struct kvm_vcpu *
params.CRn = (esr >> 10) & 0xf;
params.CRm = (esr >> 1) & 0xf;
params.Op2 = (esr >> 17) & 0x7;
-   params.Rt = (esr >> 5) & 0x1f;
+   params.Rt = kvm_vcpu_sys_get_rt(vcpu);
params.is_write = !(esr & 1);
 
return emulate_sys_reg(vcpu, );

[PATCH 3.16 124/134] net/mlx4_en: Avoid adding steering rules with invalid ring

[Ben Hutchings]

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

--

From: Talat Batheesh 

commit 89c557687a32c294e9d25670a96e9287c09f2d5f upstream.

Inserting steering rules with illegal ring is an invalid operation,
block it.

Fixes: 820672812f82 ('net/mlx4_en: Manage flow steering rules with ethtool')
Signed-off-by: Talat Batheesh 
Signed-off-by: Tariq Toukan 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 5 +
 1 file changed, 5 insertions(+)

--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -930,6 +930,11 @@ static int mlx4_en_flow_replace(struct n
qpn = priv->drop_qp.qpn;
else if (cmd->fs.ring_cookie & EN_ETHTOOL_QP_ATTACH) {
qpn = cmd->fs.ring_cookie & (EN_ETHTOOL_QP_ATTACH - 1);
+   if (qpn < priv->rss_map.base_qpn ||
+   qpn >= priv->rss_map.base_qpn + priv->rx_ring_num) {
+   en_warn(priv, "rxnfc: QP (0x%x) doesn't exist\n", qpn);
+   return -EINVAL;
+   }
} else {
if (cmd->fs.ring_cookie >= priv->rx_ring_num) {
en_warn(priv, "rxnfc: RX ring (%llu) doesn't exist\n",

[PATCH 3/6] MIPS: math-emu: CLASS.D: Zero bits 32-63 of the result

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix content of CLASS.D output bits 32-63 to match hardware behavior.

Prior to this patch, bits 32-63 of CLASS.D output were not
initialized, causing differnet 32-63 bits content of CLASS.D, based on
circumstances. However, the hardware consistently returns all these
bits zeroed. The documentation is not clear whether these bits should
be zero or unpredicible. Since technically "all zero" case still can
be viewed as belonging to "unpredictible" class of results, it is
better to zero bits 32-63.

Signed-off-by: Miodrag Dinic 
Signed-off-by: Goran Ferenc 
Signed-off-by: Aleksandar Markovic 
---
 arch/mips/math-emu/cp1emu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index cabcf2c..1ad15f8 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -2144,8 +2144,8 @@ static int fpu_emu(struct pt_regs *xcp, struct 
mips_fpu_struct *ctx,
return SIGILL;
 
DPFROMREG(fs, MIPSInst_FS(ir));
-   rv.w = ieee754dp_2008class(fs);
-   rfmt = w_fmt;
+   rv.l = ieee754dp_2008class(fs);
+   rfmt = l_fmt;
break;
}
 
-- 
2.7.4

[PATCH 2/6] MIPS: math-emu: RINT.<D|S>: Fix several problems by reimplementation

[Aleksandar Markovic]

From: Aleksandar Markovic 

Reimplement RINT. kernel emulation so that all RINT.
specifications are met.

For the sake of simplicity, let's analyze RINT.S only. Prior to
this patch, RINT.S emulation was essentially implemented as (in
pseudocode)  = ieee754sp_flong(ieee754sp_tlong()),
where ieee754sp_tlong() and ieee754sp_flong() are functions
providing conversion from double to integer, and from integer
to double, rescpectively. On surface, this implementation looks
correct, but actually fails in many cases. Following problems
were detected:

1. NaN and infinity cases will not be handled properly. The
   function ieee754sp_flong() never returns NaN nor infinity.
2. For RINT.S, for all inputs larger than LONG_MAX, and smaller
   than FLT_MAX, the result will be wrong, and the overflow
   exception will be erroneously set. A similar problem for
   negative inputs exists as well.
3. For some rounding modes, for some negative inputs close to zero,
   the return value will be zero, and should be -zero. This is
   because ieee754sp_flong() never returns -zero.

This patch removes the problems above by implementing dedicated
functions for RINT. emulation.

The core of the new function functionality is adapted version of
the core of the function ieee754sp_tlong(). However, there are many
details that are implemented to match RINT. specification. It
should be said that the functionality of ieee754sp_tlong() actually
closely corresponds to CVT.L.S instruction, and it is used while
emulating CVT.L.S. However, RINT.S and CVT.L.S instructions differ
in many aspects. This patch fulfills missing support for RINT..

Signed-off-by: Miodrag Dinic 
Signed-off-by: Goran Ferenc 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS  |  7 
 arch/mips/math-emu/Makefile  |  6 ++-
 arch/mips/math-emu/cp1emu.c  |  6 +--
 arch/mips/math-emu/dp_rint.c | 89 +++
 arch/mips/math-emu/ieee754.h |  2 +
 arch/mips/math-emu/sp_rint.c | 90 
 6 files changed, 194 insertions(+), 6 deletions(-)
 create mode 100644 arch/mips/math-emu/dp_rint.c
 create mode 100644 arch/mips/math-emu/sp_rint.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..88bea9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8803,6 +8803,13 @@ F:   arch/mips/include/asm/mach-loongson32/
 F: drivers/*/*loongson1*
 F: drivers/*/*/*loongson1*
 
+MIPS RINT INSTRUCTION EMULATION
+M: Aleksandar Markovic 
+L: linux-m...@linux-mips.org
+S: Supported
+F: arch/mips/math-emu/sp_rint.c
+F: arch/mips/math-emu/dp_rint.c
+
 MIROSOUND PCM20 FM RADIO RECEIVER DRIVER
 M: Hans Verkuil 
 L: linux-me...@vger.kernel.org
diff --git a/arch/mips/math-emu/Makefile b/arch/mips/math-emu/Makefile
index e9bbc2a..e9f10b8 100644
--- a/arch/mips/math-emu/Makefile
+++ b/arch/mips/math-emu/Makefile
@@ -4,9 +4,11 @@
 
 obj-y  += cp1emu.o ieee754dp.o ieee754sp.o ieee754.o \
   dp_div.o dp_mul.o dp_sub.o dp_add.o dp_fsp.o dp_cmp.o dp_simple.o \
-  dp_tint.o dp_fint.o dp_maddf.o dp_2008class.o dp_fmin.o dp_fmax.o \
+  dp_tint.o dp_fint.o dp_rint.o dp_maddf.o dp_2008class.o dp_fmin.o \
+  dp_fmax.o \
   sp_div.o sp_mul.o sp_sub.o sp_add.o sp_fdp.o sp_cmp.o sp_simple.o \
-  sp_tint.o sp_fint.o sp_maddf.o sp_2008class.o sp_fmin.o sp_fmax.o \
+  sp_tint.o sp_fint.o sp_rint.o sp_maddf.o sp_2008class.o sp_fmin.o \
+  sp_fmax.o \
   dsemul.o
 
 lib-y  += ieee754d.o \
diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index 520a5ac..cabcf2c 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -1805,8 +1805,7 @@ static int fpu_emu(struct pt_regs *xcp, struct 
mips_fpu_struct *ctx,
return SIGILL;
 
SPFROMREG(fs, MIPSInst_FS(ir));
-   rv.l = ieee754sp_tlong(fs);
-   rv.s = ieee754sp_flong(rv.l);
+   rv.s = ieee754sp_rint(fs);
goto copcsr;
}
 
@@ -2134,8 +2133,7 @@ static int fpu_emu(struct pt_regs *xcp, struct 
mips_fpu_struct *ctx,
return SIGILL;
 
DPFROMREG(fs, MIPSInst_FS(ir));
-   rv.l = ieee754dp_tlong(fs);
-   rv.d = ieee754dp_flong(rv.l);
+   rv.d = ieee754dp_rint(fs);
goto copcsr;
}
 
diff --git a/arch/mips/math-emu/dp_rint.c b/arch/mips/math-emu/dp_rint.c
new file mode 100644
index 000..c3b9077
--- /dev/null
+++ b/arch/mips/math-emu/dp_rint.c
@@ 

[PATCH 3.16 127/134] ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080

[Ben Hutchings]

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

--

From: Alexander Tsoy 

commit aea57edf80c6e96d6dc24757599396af99c02b19 upstream.

This device is available under different marketing names:
WLM-20U2 - Wireless USB Dongle for Toshiba TVs
GN-1080 - Wireless LAN Module for Toshiba MFPs.

Signed-off-by: Alexander Tsoy 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -60,6 +60,8 @@ static struct usb_device_id ath9k_hif_us
  .driver_info = AR9280_USB },  /* Buffalo WLI-UV-AG300P */
{ USB_DEVICE(0x04da, 0x3904),
  .driver_info = AR9280_USB },
+   { USB_DEVICE(0x0930, 0x0a08),
+ .driver_info = AR9280_USB },  /* Toshiba WLM-20U2 and GN-1080 */
 
{ USB_DEVICE(0x0cf3, 0x20ff),
  .driver_info = STORAGE_DEVICE },

Re: [PATCH 2/3] MIPS: dts: Add VoCore2 board

[Harvey Hunt]

Hi Rob,

Thanks for the review.

On 17/08/17 22:36, Rob Herring wrote:

On Tue, Aug 15, 2017 at 05:32:52PM +0100, Harvey Hunt wrote:

The VoCore2 board is a low cost MT7628A based board with 128MB RAM, 16MB
flash and multiple external peripherals.

This initial DTS provides enough support to get to userland and use the USB
port.

Signed-off-by: Harvey Hunt 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
  MAINTAINERS   |  6 ++
  arch/mips/boot/dts/ralink/Makefile|  1 +
  arch/mips/boot/dts/ralink/vocore2.dts | 18 ++
  arch/mips/ralink/Kconfig  |  5 +
  4 files changed, 30 insertions(+)
  create mode 100644 arch/mips/boot/dts/ralink/vocore2.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..82dcc6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14127,6 +14127,12 @@ L: net...@vger.kernel.org
  S:Maintained
  F:drivers/net/vmxnet3/
  
+VOCORE VOCORE2 BOARD

+M: Harvey Hunt 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: arch/mips/boot/dts/ralink/vocore2.dts
+
  VOLTAGE AND CURRENT REGULATOR FRAMEWORK
  M:Liam Girdwood 
  M:Mark Brown 
diff --git a/arch/mips/boot/dts/ralink/Makefile 
b/arch/mips/boot/dts/ralink/Makefile
index 2a72259..a191788 100644
--- a/arch/mips/boot/dts/ralink/Makefile
+++ b/arch/mips/boot/dts/ralink/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_DTB_RT2880_EVAL)   += rt2880_eval.dtb
  dtb-$(CONFIG_DTB_RT305X_EVAL) += rt3052_eval.dtb
  dtb-$(CONFIG_DTB_RT3883_EVAL) += rt3883_eval.dtb
  dtb-$(CONFIG_DTB_MT7620A_EVAL)+= mt7620a_eval.dtb
+dtb-$(CONFIG_DTB_VOCORE2)  += vocore2.dtb
  
  obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
  
diff --git a/arch/mips/boot/dts/ralink/vocore2.dts b/arch/mips/boot/dts/ralink/vocore2.dts

new file mode 100644
index 000..7591340
--- /dev/null
+++ b/arch/mips/boot/dts/ralink/vocore2.dts
@@ -0,0 +1,18 @@
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "vocore,vocore2", "ralink,mt7628a-soc";


Is vocore,vocore2 documented?


It's not, do you want me to add a file in 
Documentation/devicetree/bindings/mips?


If so, shall I just create a vocore.txt file or create a "vocore" 
directory with vocore2.txt in it?


Thanks,

Harvey




+   model = "VoCore2";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = "serial2:115200";
+   };
+};
diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig
index 710b04c..c2b2c2d 100644
--- a/arch/mips/ralink/Kconfig
+++ b/arch/mips/ralink/Kconfig
@@ -82,6 +82,11 @@ choice
depends on SOC_MT7620
select BUILTIN_DTB
  
+	config DTB_VOCORE2

+   bool "VoCore2"
+   depends on SOC_MT7620
+   select BUILTIN_DTB
+
  endchoice
  
  endif

--
2.7.4

[PATCH 3.16 109/134] metag/uaccess: Check access_ok in strncpy_from_user

[Ben Hutchings]

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

--

From: James Hogan 

commit 3a158a62da0673db918b53ac1440845a5b64fd90 upstream.

The metag implementation of strncpy_from_user() doesn't validate the src
pointer, which could allow reading of arbitrary kernel memory. Add a
short access_ok() check to prevent that.

Its still possible for it to read across the user/kernel boundary, but
it will invariably reach a NUL character after only 9 bytes, leaking
only a static kernel address being loaded into D0Re0 at the beginning of
__start, which is acceptable for the immediate fix.

Reported-by: Al Viro 
Signed-off-by: James Hogan 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ben Hutchings 
---
 arch/metag/include/asm/uaccess.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -189,8 +189,13 @@ do {
 extern long __must_check __strncpy_from_user(char *dst, const char __user *src,
 long count);
 
-#define strncpy_from_user(dst, src, count) __strncpy_from_user(dst, src, count)
-
+static inline long
+strncpy_from_user(char *dst, const char __user *src, long count)
+{
+   if (!access_ok(VERIFY_READ, src, 1))
+   return -EFAULT;
+   return __strncpy_from_user(dst, src, count);
+}
 /*
  * Return the size of a string (including the ending 0)
  *

Re: [PATCH] sdhci: remove redundant check of zero slots

[Adrian Hunter]

On 18/08/17 15:37, Colin King wrote:
> From: Colin Ian King 
> 
> Slots can never be zero, PCI_SLOTS_INFO_SLOTS returns a value in the
> range 0..7; slots is one more than this, 1..8 so cannot be zero and
> so the zero check is redundant and can be removed.
> 
> Detected by CoverityScan, CID#744269 ("Logically Dead Code")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/mmc/host/sdhci-pci-core.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-pci-core.c 
> b/drivers/mmc/host/sdhci-pci-core.c
> index 2c853cfa8389..43b2b09131bd 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -1669,8 +1669,6 @@ static int sdhci_pci_probe(struct pci_dev *pdev,
>  
>   slots = PCI_SLOT_INFO_SLOTS(slots) + 1;
>   dev_dbg(>dev, "found %d slot(s)\n", slots);
> - if (slots == 0)
> - return -ENODEV;
>  
>   BUG_ON(slots > MAX_SLOTS);

Isn't MAX_SLOTS == 8? So that is dead too.

>  
> 

Re: [PATCH] spmi: pmic-arb: Enforce the ownership check optionally

[Shawn Guo]

On Fri, Aug 18, 2017 at 05:24:36PM +0530, Kiran Gunda wrote:
> The peripheral ownership check is not necessary on single master
> platforms. Hence, enforce the peripheral ownership check optioanlly.
> 
> Signed-off-by: Kiran Gunda 

Tested-by: Shawn Guo 

[PATCH 3.16 131/134] mqueue: fix a use-after-free in sys_mq_notify()

[Ben Hutchings]

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

--

From: Cong Wang 

commit f991af3daabaecff34684fd51fac80319d1baad1 upstream.

The retry logic for netlink_attachskb() inside sys_mq_notify()
is nasty and vulnerable:

1) The sock refcnt is already released when retry is needed
2) The fd is controllable by user-space because we already
   release the file refcnt

so we when retry but the fd has been just closed by user-space
during this small window, we end up calling netlink_detachskb()
on the error path which releases the sock again, later when
the user-space closes this socket a use-after-free could be
triggered.

Setting 'sock' to NULL here should be sufficient to fix it.

Reported-by: GeneBlue 
Signed-off-by: Cong Wang 
Cc: Andrew Morton 
Cc: Manfred Spraul 
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 ipc/mqueue.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -1239,8 +1239,10 @@ retry:
 
timeo = MAX_SCHEDULE_TIMEOUT;
ret = netlink_attachskb(sock, nc, , NULL);
-   if (ret == 1)
+   if (ret == 1) {
+   sock = NULL;
goto retry;
+   }
if (ret) {
sock = NULL;
nc = NULL;

[PATCH 3.16 111/134] CIFS: fix oplock break deadlocks

[Ben Hutchings]

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

--

From: Rabin Vincent 

commit 3998e6b87d4258a70df358296d6f1c7234012bfe upstream.

When the final cifsFileInfo_put() is called from cifsiod and an oplock
break work is queued, lockdep complains loudly:

 =
 [ INFO: possible recursive locking detected ]
 4.11.0+ #21 Not tainted
 -
 kworker/0:2/78 is trying to acquire lock:
  ("cifsiod"){.+}, at: flush_work+0x215/0x350

 but task is already holding lock:
  ("cifsiod"){.+}, at: process_one_work+0x255/0x8e0

 other info that might help us debug this:
  Possible unsafe locking scenario:

CPU0

   lock("cifsiod");
   lock("cifsiod");

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 2 locks held by kworker/0:2/78:
  #0:  ("cifsiod"){.+}, at: process_one_work+0x255/0x8e0
  #1:  ((>work)){+.+...}, at: process_one_work+0x255/0x8e0

 stack backtrace:
 CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted 4.11.0+ #21
 Workqueue: cifsiod cifs_writev_complete
 Call Trace:
  dump_stack+0x85/0xc2
  __lock_acquire+0x17dd/0x2260
  ? match_held_lock+0x20/0x2b0
  ? trace_hardirqs_off_caller+0x86/0x130
  ? mark_lock+0xa6/0x920
  lock_acquire+0xcc/0x260
  ? lock_acquire+0xcc/0x260
  ? flush_work+0x215/0x350
  flush_work+0x236/0x350
  ? flush_work+0x215/0x350
  ? destroy_worker+0x170/0x170
  __cancel_work_timer+0x17d/0x210
  ? ___preempt_schedule+0x16/0x18
  cancel_work_sync+0x10/0x20
  cifsFileInfo_put+0x338/0x7f0
  cifs_writedata_release+0x2a/0x40
  ? cifs_writedata_release+0x2a/0x40
  cifs_writev_complete+0x29d/0x850
  ? preempt_count_sub+0x18/0xd0
  process_one_work+0x304/0x8e0
  worker_thread+0x9b/0x6a0
  kthread+0x1b2/0x200
  ? process_one_work+0x8e0/0x8e0
  ? kthread_create_on_node+0x40/0x40
  ret_from_fork+0x31/0x40

This is a real warning.  Since the oplock is queued on the same
workqueue this can deadlock if there is only one worker thread active
for the workqueue (which will be the case during memory pressure when
the rescuer thread is handling it).

Furthermore, there is at least one other kind of hang possible due to
the oplock break handling if there is only worker.  (This can be
reproduced without introducing memory pressure by having passing 1 for
the max_active parameter of cifsiod.) cifs_oplock_break() can wait
indefintely in the filemap_fdatawait() while the cifs_writev_complete()
work is blocked:

 sysrq: SysRq : Show Blocked State
   taskPC stack   pid father
 kworker/0:1 D016  2 0x
 Workqueue: cifsiod cifs_oplock_break
 Call Trace:
  __schedule+0x562/0xf40
  ? mark_held_locks+0x4a/0xb0
  schedule+0x57/0xe0
  io_schedule+0x21/0x50
  wait_on_page_bit+0x143/0x190
  ? add_to_page_cache_lru+0x150/0x150
  __filemap_fdatawait_range+0x134/0x190
  ? do_writepages+0x51/0x70
  filemap_fdatawait_range+0x14/0x30
  filemap_fdatawait+0x3b/0x40
  cifs_oplock_break+0x651/0x710
  ? preempt_count_sub+0x18/0xd0
  process_one_work+0x304/0x8e0
  worker_thread+0x9b/0x6a0
  kthread+0x1b2/0x200
  ? process_one_work+0x8e0/0x8e0
  ? kthread_create_on_node+0x40/0x40
  ret_from_fork+0x31/0x40
 dd  D0   683171 0x
 Call Trace:
  __schedule+0x562/0xf40
  ? mark_held_locks+0x29/0xb0
  schedule+0x57/0xe0
  io_schedule+0x21/0x50
  wait_on_page_bit+0x143/0x190
  ? add_to_page_cache_lru+0x150/0x150
  __filemap_fdatawait_range+0x134/0x190
  ? do_writepages+0x51/0x70
  filemap_fdatawait_range+0x14/0x30
  filemap_fdatawait+0x3b/0x40
  filemap_write_and_wait+0x4e/0x70
  cifs_flush+0x6a/0xb0
  filp_close+0x52/0xa0
  __close_fd+0xdc/0x150
  SyS_close+0x33/0x60
  entry_SYSCALL_64_fastpath+0x1f/0xbe

 Showing all locks held in the system:
 2 locks held by kworker/0:1/16:
  #0:  ("cifsiod"){.+.+.+}, at: process_one_work+0x255/0x8e0
  #1:  ((>oplock_break)){+.+.+.}, at: process_one_work+0x255/0x8e0

 Showing busy workqueues and worker pools:
 workqueue cifsiod: flags=0xc
   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
 in-flight: 16:cifs_oplock_break
 delayed: cifs_writev_complete, cifs_echo_request
 pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 750 3

Fix these problems by creating a a new workqueue (with a rescuer) for
the oplock break work.

Signed-off-by: Rabin Vincent 
Signed-off-by: Steve French 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/cifs/cifsfs.c   | 15 +--
 fs/cifs/cifsglob.h |  1 +
 fs/cifs/misc.c |  2 +-
 fs/cifs/smb2misc.c |  5 +++--
 4 files changed, 18 insertions(+), 5 deletions(-)

--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -86,6 +86,7 @@ extern mempool_t *cifs_req_poolp;
 extern mempool_t *cifs_mid_poolp;
 
 struct workqueue_struct*cifsiod_wq;
+struct workqueue_struct*cifsoplockd_wq;
 
 /*
  * Bumps refcount 

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[Shawn Guo]

On Fri, Aug 18, 2017 at 04:43:23PM +0530, kgu...@codeaurora.org wrote:
> From the logs the ownership for these GPIOs is not assigned to the
> application processor but to another master. Considering this is a
> (apq8016-sbc) APSS only platform ideally the fix for this would be
> to update the ownership table in the boot loader. The other option
> would be to make the  existing ownership check in SW optional for a
> platform via DT. I will push a patch shortly for this. Could you
> please give that a try.

I just tested it on db410c board, and it fixes the problem for me.
Thanks for the patch.

Shawn

[PATCH 3.16 132/134] packet: fix tp_reserve race in packet_set_ring

[Ben Hutchings]

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

--

From: Willem de Bruijn 

commit c27927e372f0785f3303e8fad94b85945e2c97b7 upstream.

Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.

This bug was discovered by syzkaller.

Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Reported-by: Andrey Konovalov 
Signed-off-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/packet/af_packet.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3345,14 +3345,19 @@ packet_setsockopt(struct socket *sock, i
 
if (optlen != sizeof(val))
return -EINVAL;
-   if (po->rx_ring.pg_vec || po->tx_ring.pg_vec)
-   return -EBUSY;
if (copy_from_user(, optval, sizeof(val)))
return -EFAULT;
if (val > INT_MAX)
return -EINVAL;
-   po->tp_reserve = val;
-   return 0;
+   lock_sock(sk);
+   if (po->rx_ring.pg_vec || po->tx_ring.pg_vec) {
+   ret = -EBUSY;
+   } else {
+   po->tp_reserve = val;
+   ret = 0;
+   }
+   release_sock(sk);
+   return ret;
}
case PACKET_LOSS:
{

[PATCH 3.16 114/134] SMB3: Work around mount failure when using SMB3 dialect to Macs

[Ben Hutchings]

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

--

From: Steve French 

commit 7db0a6efdc3e990cdfd4b24820d010e9eb7890ad upstream.

Macs send the maximum buffer size in response on ioctl to validate
negotiate security information, which causes us to fail the mount
as the response buffer is larger than the expected response.

Changed ioctl response processing to allow for padding of validate
negotiate ioctl response and limit the maximum response size to
maximum buffer size.

Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings 
---
 fs/cifs/smb2pdu.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -524,8 +524,12 @@ int smb3_validate_negotiate(const unsign
}
 
if (rsplen != sizeof(struct validate_negotiate_info_rsp)) {
-   cifs_dbg(VFS, "invalid size of protocol negotiate response\n");
-   return -EIO;
+   cifs_dbg(VFS, "invalid protocol negotiate response size: %d\n",
+rsplen);
+
+   /* relax check since Mac returns max bufsize allowed on ioctl */
+   if (rsplen > CIFSMaxBufSize)
+   return -EIO;
}
 
/* check validate negotiate info response matches what we got earlier */
@@ -1293,8 +1297,12 @@ SMB2_ioctl(const unsigned int xid, struc
 * than one credit. Windows typically sets this smaller, but for some
 * ioctls it may be useful to allow server to send more. No point
 * limiting what the server can send as long as fits in one credit
+* Unfortunately - we can not handle more than CIFS_MAX_MSG_SIZE
+* (by default, note that it can be overridden to make max larger)
+* in responses (except for read responses which can be bigger.
+* We may want to bump this limit up
 */
-   req->MaxOutputResponse = cpu_to_le32(0xFF00); /* < 64K uses 1 credit */
+   req->MaxOutputResponse = cpu_to_le32(CIFSMaxBufSize);
 
if (is_fsctl)
req->Flags = cpu_to_le32(SMB2_0_IOCTL_IS_FSCTL);

[PATCH 3.16 116/134] of: fix sparse warning in of_pci_range_parser_one

[Ben Hutchings]

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

--

From: Rob Herring 

commit eb3100365791b06242b8bb5c3c2854ba41dabfbc upstream.

sparse gives the following warning for 'pci_space':

../drivers/of/address.c:266:26: warning: incorrect type in assignment 
(different base types)
../drivers/of/address.c:266:26:expected unsigned int [unsigned] [usertype] 
pci_space
../drivers/of/address.c:266:26:got restricted __be32 const [usertype] 


It appears that pci_space is only ever accessed on powerpc, so the endian
swap is often not needed.

Signed-off-by: Rob Herring 
Signed-off-by: Ben Hutchings 
---
 drivers/of/address.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -258,7 +258,7 @@ struct of_pci_range *of_pci_range_parser
if (!parser->range || parser->range + parser->np > parser->end)
return NULL;
 
-   range->pci_space = parser->range[0];
+   range->pci_space = be32_to_cpup(parser->range);
range->flags = of_bus_pci_get_flags(parser->range);
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,

[PATCH 3.16 115/134] ceph: fix memory leak in __ceph_setxattr()

[Ben Hutchings]

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

--

From: Luis Henriques 

commit eeca958dce0a9231d1969f86196653eb50fcc9b3 upstream.

The ceph_inode_xattr needs to be released when removing an xattr.  Easily
reproducible running the 'generic/020' test from xfstests or simply by
doing:

  attr -s attr0 -V 0 /mnt/test && attr -r attr0 /mnt/test

While there, also fix the error path.

Here's the kmemleak splat:

unreferenced object 0x88001f86fbc0 (size 64):
  comm "attr", pid 244, jiffies 4294904246 (age 98.464s)
  hex dump (first 32 bytes):
40 fa 86 1f 00 88 ff ff 80 32 38 1f 00 88 ff ff  @28.
00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de  
  backtrace:
[] kmemleak_alloc+0x49/0xa0
[] kmem_cache_alloc+0x9b/0xf0
[] __ceph_setxattr+0x17e/0x820
[] ceph_set_xattr_handler+0x37/0x40
[] __vfs_removexattr+0x4b/0x60
[] vfs_removexattr+0x77/0xd0
[] removexattr+0x41/0x60
[] path_removexattr+0x75/0xa0
[] SyS_lremovexattr+0xb/0x10
[] entry_SYSCALL_64_fastpath+0x13/0x94
[] 0x

Signed-off-by: Luis Henriques 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Ben Hutchings 
---
 fs/ceph/xattr.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/fs/ceph/xattr.c
+++ b/fs/ceph/xattr.c
@@ -369,6 +369,7 @@ static int __set_xattr(struct ceph_inode
 
if (update_xattr) {
int err = 0;
+
if (xattr && (flags & XATTR_CREATE))
err = -EEXIST;
else if (!xattr && (flags & XATTR_REPLACE))
@@ -376,12 +377,14 @@ static int __set_xattr(struct ceph_inode
if (err) {
kfree(name);
kfree(val);
+   kfree(*newxattr);
return err;
}
if (update_xattr < 0) {
if (xattr)
__remove_xattr(ci, xattr);
kfree(name);
+   kfree(*newxattr);
return 0;
}
}

[PATCH 3.16 134/134] udp: consistently apply ufo or fragmentation

[Ben Hutchings]

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

--

From: Willem de Bruijn 

commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa upstream.

When iteratively building a UDP datagram with MSG_MORE and that
datagram exceeds MTU, consistently choose UFO or fragmentation.

Once skb_is_gso, always apply ufo. Conversely, once a datagram is
split across multiple skbs, do not consider ufo.

Sendpage already maintains the first invariant, only add the second.
IPv6 does not have a sendpage implementation to modify.

A gso skb must have a partial checksum, do not follow sk_no_check_tx
in udp_send_skb.

Found by syzkaller.

Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Reported-by: Andrey Konovalov 
Signed-off-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - ip6_append_data() doesn't take a queue parameter; use >sk_write_queue
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/ip_output.c  |7 +--
 net/ipv4/udp.c|2 +-
 net/ipv6/ip6_output.c |7 ---
 3 files changed, 10 insertions(+), 6 deletions(-)

--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -885,10 +885,12 @@ static int __ip_append_data(struct sock
csummode = CHECKSUM_PARTIAL;
 
cork->length += length;
-   if (((length > mtu) || (skb && skb_is_gso(skb))) &&
+   if ((skb && skb_is_gso(skb)) ||
+   ((length > mtu) &&
+   (skb_queue_len(queue) <= 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !dst_xfrm(>dst) &&
-   (sk->sk_type == SOCK_DGRAM)) {
+   (sk->sk_type == SOCK_DGRAM))) {
err = ip_ufo_append_data(sk, queue, getfrag, from, length,
 hh_len, fragheaderlen, transhdrlen,
 maxfraglen, flags);
@@ -1203,6 +1205,7 @@ ssize_t   ip_append_page(struct sock *sk,
 
cork->length += size;
if ((size + skb->len > mtu) &&
+   (skb_queue_len(>sk_write_queue) == 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO)) {
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -824,7 +824,7 @@ static int udp_send_skb(struct sk_buff *
if (is_udplite)  /* UDP-Lite  */
csum = udplite_csum(skb);
 
-   else if (sk->sk_no_check_tx) {   /* UDP csum disabled */
+   else if (sk->sk_no_check_tx && !skb_is_gso(skb)) {   /* UDP csum off */
 
skb->ip_summed = CHECKSUM_NONE;
goto send;
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1291,11 +1291,12 @@ emsgsize:
 
skb = skb_peek_tail(>sk_write_queue);
cork->length += length;
-   if length + fragheaderlen) > mtu) ||
-(skb && skb_is_gso(skb))) &&
+   if ((skb && skb_is_gso(skb)) ||
+   (((length + fragheaderlen) > mtu) &&
+   (skb_queue_len(>sk_write_queue) <= 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !dst_xfrm(>dst) &&
-   (sk->sk_type == SOCK_DGRAM)) {
+   (sk->sk_type == SOCK_DGRAM))) {
err = ip6_ufo_append_data(sk, getfrag, from, length,
  hh_len, fragheaderlen, exthdrlen,
  transhdrlen, mtu, flags, rt);

[PATCH 3.16 110/134] tg3: don't clear stats while tg3_close

[Ben Hutchings]

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

--

From: YueHaibing 

commit 37a7fdf2892be124545ddaf99b85de576121476c upstream.

Now tg3 NIC's stats will be cleared after ifdown/ifup. bond_get_stats traverse
its salves to get statistics,cumulative the increment.If a tg3 NIC is added to
bonding as a slave,ifdown/ifup will cause bonding's stats become tremendous 
value
(ex.1638.3 PiB) because of negative increment.

Fixes: 92feeabf3f67 ("tg3: Save stats across chip resets")
Signed-off-by: YueHaibing 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/broadcom/tg3.c | 4 
 1 file changed, 4 deletions(-)

--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -11709,10 +11709,6 @@ static int tg3_close(struct net_device *
 
tg3_stop(tp);
 
-   /* Clear stats across close / open calls */
-   memset(>net_stats_prev, 0, sizeof(tp->net_stats_prev));
-   memset(>estats_prev, 0, sizeof(tp->estats_prev));
-
if (pci_device_is_present(tp->pdev)) {
tg3_power_down_prepare(tp);
 

[PATCH 3.16 081/134] fanotify: don't expose EOPENSTALE to userspace

[Ben Hutchings]

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

--

From: Amir Goldstein 

commit 4ff33aafd32e084f5ee7faa54ba06e95f8b1b8af upstream.

When delivering an event to userspace for a file on an NFS share,
if the file is deleted on server side before user reads the event,
user will not get the event.

If the event queue contained several events, the stale event is
quietly dropped and read() returns to user with events read so far
in the buffer.

If the event queue contains a single stale event or if the stale
event is a permission event, read() returns to user with the kernel
internal error code 518 (EOPENSTALE), which is not a POSIX error code.

Check the internal return value -EOPENSTALE in fanotify_read(), just
the same as it is checked in path_openat() and drop the event in the
cases that it is not already dropped.

This is a reproducer from Marko Rauhamaa:

Just take the example program listed under "man fanotify" ("fantest")
and follow these steps:

==
NFS ServerNFS Client(1) NFS Client(2)
==
# echo foo >/nfsshare/bar.txt
  # cat /nfsshare/bar.txt
  foo
# ./fantest /nfsshare
Press enter key to terminate.
Listening for events.
# rm -f /nfsshare/bar.txt
  # cat /nfsshare/bar.txt
read: Unknown error 518
  cat: /nfsshare/bar.txt: Operation not permitted
==

where NFS Client (1) and (2) are two terminal sessions on a single NFS
Client machine.

Reported-by: Marko Rauhamaa 
Tested-by: Marko Rauhamaa 
Cc: 
Signed-off-by: Amir Goldstein 
Signed-off-by: Jan Kara 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/notify/fanotify/fanotify_user.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -294,27 +294,37 @@ static ssize_t fanotify_read(struct file
}
 
ret = copy_event_to_user(group, kevent, buf);
+   if (unlikely(ret == -EOPENSTALE)) {
+   /*
+* We cannot report events with stale fd so drop it.
+* Setting ret to 0 will continue the event loop and
+* do the right thing if there are no more events to
+* read (i.e. return bytes read, -EAGAIN or wait).
+*/
+   ret = 0;
+   }
+
/*
 * Permission events get queued to wait for response.  Other
 * events can be destroyed now.
 */
if (!(kevent->mask & FAN_ALL_PERM_EVENTS)) {
fsnotify_destroy_event(group, kevent);
-   if (ret < 0)
-   break;
} else {
 #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
-   if (ret < 0) {
+   if (ret <= 0) {
FANOTIFY_PE(kevent)->response = FAN_DENY;
wake_up(>fanotify_data.access_waitq);
-   break;
+   } else {
+   spin_lock(>fanotify_data.access_lock);
+   list_add_tail(>list,
+   >fanotify_data.access_list);
+   spin_unlock(>fanotify_data.access_lock);
}
-   spin_lock(>fanotify_data.access_lock);
-   list_add_tail(>list,
- >fanotify_data.access_list);
-   spin_unlock(>fanotify_data.access_lock);
 #endif
}
+   if (ret < 0)
+   break;
buf += ret;
count -= ret;
}

[PATCH 3.16 103/134] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

[Ben Hutchings]

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

--

From: Mario Kleiner 

commit e345da82bd6bdfa8492f80b3ce4370acfd868d95 upstream.

The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.

Add a quirk to get the full 10 bpc.

Signed-off-by: Mario Kleiner 
Acked-by: Harry Wentland 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner...@gmail.com
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 8 insertions(+)

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -74,6 +74,8 @@
 #define EDID_QUIRK_FORCE_12BPC (1 << 9)
 /* Force 6bpc */
 #define EDID_QUIRK_FORCE_6BPC  (1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC (1 << 11)
 
 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -116,6 +118,9 @@ static struct edid_quirk {
{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
  EDID_QUIRK_DETAILED_IN_CM },
 
+   /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+   { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -3678,6 +3683,9 @@ int drm_add_edid_modes(struct drm_connec
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
 
+   if (quirks & EDID_QUIRK_FORCE_10BPC)
+   connector->display_info.bpc = 10;
+
if (quirks & EDID_QUIRK_FORCE_12BPC)
connector->display_info.bpc = 12;
 

[PATCH 3.16 106/134] tcp: fix wraparound issue in tcp_lp

[Ben Hutchings]

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

--

From: Eric Dumazet 

commit a9f11f963a546fea9144f6a6d1a307e814a387e7 upstream.

Be careful when comparing tcp_time_stamp to some u32 quantity,
otherwise result can be surprising.

Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/tcp_lp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct soc
 {
struct tcp_sock *tp = tcp_sk(sk);
struct lp *lp = inet_csk_ca(sk);
+   u32 delta;
 
if (rtt_us > 0)
tcp_lp_rtt_sample(sk, rtt_us);
 
/* calc inference */
-   if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
-   lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+   delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
+   if ((s32)delta > 0)
+   lp->inference = 3 * delta;
 
/* test if within inference */
if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))

[PATCH 3.16 108/134] Set unicode flag on cifs echo request to avoid Mac error

[Ben Hutchings]

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

--

From: Steve French 

commit 26c9cb668c7fbf9830516b75d8bee70b699ed449 upstream.

Mac requires the unicode flag to be set for cifs, even for the smb
echo request (which doesn't have strings).

Without this Mac rejects the periodic echo requests (when mounting
with cifs) that we use to check if server is down

Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings 
---
 fs/cifs/cifssmb.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -720,6 +720,9 @@ CIFSSMBEcho(struct TCP_Server_Info *serv
if (rc)
return rc;
 
+   if (server->capabilities & CAP_UNICODE)
+   smb->hdr.Flags2 |= SMBFLG2_UNICODE;
+
/* set up echo request */
smb->hdr.Tid = 0x;
smb->hdr.WordCount = 1;

[PATCH 3.16 099/134] ip6_tunnel: Fix missing tunnel encapsulation limit option

[Ben Hutchings]

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

--

From: Craig Gallek 

commit 89a23c8b528bd2c89f3981573d6cd7d23840c8a6 upstream.

The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
IPV6_TLV_PADN options when an encapsulation limit is defined (the
default is a limit of 4).  An MTU adjustment is done to account for
these options as well.  However, the options are never present in the
generated packets.

The issue appears to be a subtlety between IPV6_DSTOPTS and
IPV6_RTHDRDSTOPTS defined in RFC 3542.  When the IPIP tunnel driver was
written, the encap limit options were included as IPV6_RTHDRDSTOPTS in
dst0opt of struct ipv6_txoptions.  Later, ipv6_push_nfrags_opts was
(correctly) updated to require IPV6_RTHDR options when IPV6_RTHDRDSTOPTS
are to be used.  This caused the options to no longer be included in v6
encapsulated packets.

The fix is to use IPV6_DSTOPTS (in dst1opt of struct ipv6_txoptions)
instead.  IPV6_DSTOPTS do not have the additional IPV6_RTHDR requirement.

Fixes: 1df64a8569c7: ("[IPV6]: Add ip6ip6 tunnel driver.")
Fixes: 333fad5364d6: ("[IPV6]: Support several new sockopt / ancillary data in 
Advanced API (RFC3542)")
Signed-off-by: Craig Gallek 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ip6_tunnel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -883,7 +883,7 @@ static void init_tel_txopt(struct ipv6_t
opt->dst_opt[5] = IPV6_TLV_PADN;
opt->dst_opt[6] = 1;
 
-   opt->ops.dst0opt = (struct ipv6_opt_hdr *) opt->dst_opt;
+   opt->ops.dst1opt = (struct ipv6_opt_hdr *) opt->dst_opt;
opt->ops.opt_nflen = 8;
 }
 
@@ -1051,7 +1051,7 @@ static int ip6_tnl_xmit2(struct sk_buff
proto = fl6->flowi6_proto;
if (encap_limit >= 0) {
init_tel_txopt(, encap_limit);
-   ipv6_push_nfrag_opts(skb, , , NULL);
+   ipv6_push_frag_opts(skb, , );
}
 
if (likely(!skb->encapsulation)) {

[PATCH 3.2 49/59] ipv6: Need to export ipv6_push_frag_opts for tunneling now.

[Ben Hutchings]

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

--

From: "David S. Miller" 

commit 5b8481fa42ac58484d633b558579e302aead64c1 upstream.

Since that change also made the nfrag function not necessary
for exports, remove it.

Fixes: 89a23c8b528b ("ip6_tunnel: Fix missing tunnel encapsulation limit 
option")
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv6/exthdrs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -723,13 +723,13 @@ void ipv6_push_nfrag_opts(struct sk_buff
ipv6_push_exthdr(skb, proto, NEXTHDR_HOP, opt->hopopt);
 }
 
-EXPORT_SYMBOL(ipv6_push_nfrag_opts);
 
 void ipv6_push_frag_opts(struct sk_buff *skb, struct ipv6_txoptions *opt, u8 
*proto)
 {
if (opt->dst1opt)
ipv6_push_exthdr(skb, proto, NEXTHDR_DEST, opt->dst1opt);
 }
+EXPORT_SYMBOL(ipv6_push_frag_opts);
 
 struct ipv6_txoptions *
 ipv6_dup_options(struct sock *sk, struct ipv6_txoptions *opt)

[PATCH 3.16 098/134] Input: twl4030-pwrbutton - use correct device for irq request

[Ben Hutchings]

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

--

From: Sebastian Reichel 

commit 3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 upstream.

The interrupt should be requested for the platform device
and not for the input device.

Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
Signed-off-by: Sebastian Reichel 
Signed-off-by: Dmitry Torokhov 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/input/misc/twl4030-pwrbutton.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -70,7 +70,7 @@ static int twl4030_pwrbutton_probe(struc
pwr->phys = "twl4030_pwrbutton/input0";
pwr->dev.parent = >dev;
 
-   err = devm_request_threaded_irq(>dev, irq, NULL, powerbutton_irq,
+   err = devm_request_threaded_irq(>dev, irq, NULL, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"twl4030_pwrbutton", pwr);
if (err < 0) {

Re: [PATCH v2] irqchip/armada-370-xp: Enable MSI-X support

[Marc Zyngier]

On 18/08/17 13:59, Stefan Roese wrote:
> Armada XP does not only support MSI, but also MSI-X. This patch sets
> the MSI_FLAG_PCI_MSIX flag in the interrupt controller driver which
> is the only change necessary to enable MSI-X support on this SoC. As
> the Linux PCI MSI-X infrastructure takes care of writing the data and
> address structures into the BAR specified by the MSI-X controller.
> 
> Signed-off-by: Stefan Roese 
> Reviewed-by: Thomas Petazzoni 
> Cc: Marc Zyngier 
> Cc: Jason Cooper 
> Cc: Thomas Gleixner 
> Cc: Bjorn Helgaas 
> Cc: Gregory CLEMENT 
> ---
> v2:
> - Added Reviewed-by tag from Thomas
> - Added usual irqchip maintainers
> 
>  drivers/irqchip/irq-armada-370-xp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-armada-370-xp.c 
> b/drivers/irqchip/irq-armada-370-xp.c
> index 33982cbd8a57..b17039ed8735 100644
> --- a/drivers/irqchip/irq-armada-370-xp.c
> +++ b/drivers/irqchip/irq-armada-370-xp.c
> @@ -124,7 +124,7 @@ static struct irq_chip armada_370_xp_msi_irq_chip = {
>  
>  static struct msi_domain_info armada_370_xp_msi_domain_info = {
>   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> -MSI_FLAG_MULTI_PCI_MSI),
> +MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
>   .chip   = _370_xp_msi_irq_chip,
>  };
>  
> 

Queued for 4.14.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 0/3] JFS: Adjustments for several function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 18 Aug 2017 15:22:11 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in diMount()
  Improve size determinations in five functions
  Adjust 67 checks for null pointers

 fs/jfs/jfs_dmap.c | 44 ++--
 fs/jfs/jfs_dtree.c|  6 +++---
 fs/jfs/jfs_imap.c | 31 ++-
 fs/jfs/jfs_logmgr.c   | 26 ++
 fs/jfs/jfs_metapage.c |  7 +++
 fs/jfs/jfs_mount.c|  6 +++---
 fs/jfs/jfs_txnmgr.c   |  6 +++---
 fs/jfs/jfs_unicode.c  |  3 +--
 fs/jfs/jfs_xtree.c|  6 +++---
 fs/jfs/namei.c|  3 +--
 fs/jfs/resize.c   |  2 +-
 fs/jfs/super.c|  6 +++---
 fs/jfs/xattr.c| 10 +-
 13 files changed, 76 insertions(+), 80 deletions(-)

-- 
2.14.0

Re: [PATCH net-next] net: hns3: Add support to change MTU in hardware & netdev

[Andrew Lunn]

On Fri, Aug 18, 2017 at 12:35:58PM +0100, Salil Mehta wrote:
> This patch adds the following support to the HNS3 driver:
> 1. Support to change the Maximum Transmission Unit of a
>netdevice and of a port in hardware .
> 2. Initializes the supported MTU range for the netdevice.
> 
> Signed-off-by: lipeng 
> Signed-off-by: Salil Mehta 
> ---
>  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 
> ++
>  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h |  1 +
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> index e731f87..8e3711e 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> @@ -1278,11 +1278,53 @@ static int hns3_ndo_set_vf_vlan(struct net_device 
> *netdev, int vf, u16 vlan,
>   return ret;
>  }
>  
> +static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
> +{
> + struct hns3_nic_priv *priv = netdev_priv(netdev);
> + struct hnae3_handle *h = priv->ae_handle;
> + bool if_running = netif_running(netdev);
> + int ret;
> +
> + /* no change in MTU */
> + if (new_mtu == netdev->mtu)
> + return 0;

Hi Salil

It is worth reading the core code:

http://elixir.free-electrons.com/linux/latest/source/net/core/dev.c#L6713

 +
> + if (!h->ae_algo->ops->set_mtu)
> + return -ENOTSUPP;
> +
> + /* if this was called with netdev up then bring netdevice down */
> + if (if_running) {
> + (void)hns3_nic_net_stop(netdev);
> + msleep(100);
> + }
> +
> + ret = h->ae_algo->ops->set_mtu(h, new_mtu);
> + if (ret) {
> + netdev_err(netdev, "failed to change MTU in hardware %d\n",
> +ret);
> + return ret;
> + }
> +
> + /* assign newly changed mtu to netdevice as well */
> + netdev->mtu = new_mtu;

http://elixir.free-electrons.com/linux/latest/source/net/core/dev.c#L6698

> +
> + /* if the netdev was running earlier, bring it up again */
> + if (if_running) {
> + if (hns3_nic_net_open(netdev)) {
> + netdev_err(netdev, "MTU, couldnt up netdev again\n");
> + ret = -EINVAL;
> + }
> + }
> +
> + return ret;
> +}
> +
>  static const struct net_device_ops hns3_nic_netdev_ops = {
>   .ndo_open   = hns3_nic_net_open,
>   .ndo_stop   = hns3_nic_net_stop,
>   .ndo_start_xmit = hns3_nic_net_xmit,
>   .ndo_set_mac_address= hns3_nic_net_set_mac_address,
> + .ndo_change_mtu = hns3_nic_change_mtu,
>   .ndo_set_features   = hns3_nic_set_features,
>   .ndo_get_stats64= hns3_nic_get_stats64,
>   .ndo_setup_tc   = hns3_nic_setup_tc,
> @@ -2752,6 +2794,10 @@ static int hns3_client_init(struct hnae3_handle 
> *handle)
>   goto out_reg_netdev_fail;
>   }
>  
> + /* MTU range: 68 - 9706 */
> + netdev->min_mtu = ETH_MIN_MTU;

http://elixir.free-electrons.com/linux/latest/source/net/ethernet/eth.c#L361

> + netdev->max_mtu = HNS3_MAX_MTU - (ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN);
> +
>   return ret;
>  
>  out_reg_netdev_fail:
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> index a6e8f15..7e87461 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> @@ -76,6 +76,7 @@ enum hns3_nic_state {
>  #define HNS3_RING_NAME_LEN   16
>  #define HNS3_BUFFER_SIZE_20482048
>  #define HNS3_RING_MAX_PENDING32768
> +#define HNS3_MAX_MTU 9728

It seems odd that it does not already exists somewhere. The core does
not enforce the MTU.  You could be passed a frame which is bigger. So
you should check before trying to pass something to the hardware which
the hardware cannot handle.

Andrew

Re: [PATCH v7 2/2] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Fri, 18 Aug 2017 15:05:13 +0900
Byungchul Park  wrote:

> It would be better to avoid pushing tasks to other cpu within
> a SD_PREFER_SIBLING domain, instead, get more chances to check other
> siblings.
> 
> Signed-off-by: Byungchul Park 

Reviewed-by: Steven Rostedt (VMware) 

Note, we really should consolidate the rt.c and deadline.c find lowest
rqs code, especially since they should be aware of each other (rt and
deadline tasks should take notice of other rt and deadline tasks, not
just their own kind).

-- Steve

[PATCH 3.16 094/134] net: ethernet: ucc_geth: fix MEM_PART_MURAM mode

[Ben Hutchings]

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

--

From: Christophe Leroy 

commit 8b8642af15ed14b9a7a34d3401afbcc274533e13 upstream.

Since commit 5093bb965a163 ("powerpc/QE: switch to the cpm_muram
implementation"), muram area is not part of immrbar mapping anymore
so immrbar_virt_to_phys() is not usable anymore.

Fixes: 5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation")
Signed-off-by: Christophe Leroy 
Acked-by: David S. Miller 
Acked-by: Li Yang 
Signed-off-by: Scott Wood 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings 
---
 arch/powerpc/include/asm/qe.h | 1 +
 drivers/net/ethernet/freescale/ucc_geth.c | 8 +++-
 2 files changed, 4 insertions(+), 5 deletions(-)

--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -193,6 +193,7 @@ static inline int qe_alive_during_sleep(
 #define qe_muram_free cpm_muram_free
 #define qe_muram_addr cpm_muram_addr
 #define qe_muram_offset cpm_muram_offset
+#define qe_muram_dma cpm_muram_dma
 
 /* Structure that defines QE firmware binary files.
  *
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -2590,11 +2590,10 @@ static int ucc_geth_startup(struct ucc_g
} else if (ugeth->ug_info->uf_info.bd_mem_part ==
   MEM_PART_MURAM) {
out_be32(>p_send_q_mem_reg->sqqd[i].bd_ring_base,
-(u32) immrbar_virt_to_phys(ugeth->
-   p_tx_bd_ring[i]));
+(u32)qe_muram_dma(ugeth->p_tx_bd_ring[i]));
out_be32(>p_send_q_mem_reg->sqqd[i].
 last_bd_completed_address,
-(u32) immrbar_virt_to_phys(endOfRing));
+(u32)qe_muram_dma(endOfRing));
}
}
 
@@ -2840,8 +2839,7 @@ static int ucc_geth_startup(struct ucc_g
} else if (ugeth->ug_info->uf_info.bd_mem_part ==
   MEM_PART_MURAM) {
out_be32(>p_rx_bd_qs_tbl[i].externalbdbaseptr,
-(u32) immrbar_virt_to_phys(ugeth->
-   p_rx_bd_ring[i]));
+(u32)qe_muram_dma(ugeth->p_rx_bd_ring[i]));
}
/* rest of fields handled by QE */
}

[PATCH 3.16 083/134] x86/mm: Fix flush_tlb_page() on Xen

[Ben Hutchings]

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

--

From: Andy Lutomirski 

commit dbd68d8e84c606673ebbcf15862f8c155fa92326 upstream.

flush_tlb_page() passes a bogus range to flush_tlb_others() and
expects the latter to fix it up.  native_flush_tlb_others() has the
fixup but Xen's version doesn't.  Move the fixup to
flush_tlb_others().

AFAICS the only real effect is that, without this fix, Xen would
flush everything instead of just the one page on remote vCPUs in
when flush_tlb_page() was called.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Boris Ostrovsky 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Michal Hocko 
Cc: Nadav Amit 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Fixes: e7b52ffd45a6 ("x86/flush_tlb: try flush_tlb_single one by one in 
flush_tlb_range")
Link: 
http://lkml.kernel.org/r/10ed0e4dfea64daef10b87fb85df1746999b4dba.1492844372.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: the special case was handled in flush_tlb_func(), not
 native_flush_tlb_others()]
Signed-off-by: Ben Hutchings 
---
 arch/x86/mm/tlb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -107,8 +107,6 @@ static void flush_tlb_func(void *info)
if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
if (f->flush_end == TLB_FLUSH_ALL)
local_flush_tlb();
-   else if (!f->flush_end)
-   __flush_tlb_single(f->flush_start);
else {
unsigned long addr;
addr = f->flush_start;
@@ -248,7 +246,7 @@ void flush_tlb_page(struct vm_area_struc
}
 
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
-   flush_tlb_others(mm_cpumask(mm), mm, start, 0UL);
+   flush_tlb_others(mm_cpumask(mm), mm, start, start + PAGE_SIZE);
 
preempt_enable();
 }

Re: [PATCH V10 1/3] PCI: introduce pci_bus_wait_crs() function

[Sinan Kaya]

On 8/17/2017 11:00 PM, Bjorn Helgaas wrote:
> On Fri, Aug 11, 2017 at 12:56:34PM -0400, Sinan Kaya wrote:
>> Kernel is hiding Configuration Request Retry Status (CRS) inside
>> pci_bus_read_dev_vendor_id() function. We are looking to add support for
>> Function Level Reset (FLR) where vendor id read returns ~0.
>>
>> Move CRS handling into its own function so that it can be called from other
>> places as well.
> 
> I think this is a much better idea than what I proposed.  I still have
> a few questions proposals.  I'll post a v11 to show what I'm thinking.
> 

Sure, let me know. I can test it.

>> Signed-off-by: Sinan Kaya 
>> ---
>>  drivers/pci/pci.h   |  2 ++
>>  drivers/pci/probe.c | 44 ++--
>>  2 files changed, 32 insertions(+), 14 deletions(-)
>>

>>  msleep(delay);
>>  delay *= 2;
>>  if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
>> @@ -1858,6 +1846,34 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, 
>> int devfn, u32 *l,
>> PCI_FUNC(devfn));
>>  return false;
> 
> While staring at this, I think I found a pre-existing bug in
> pci_bus_read_dev_vendor_id().  It looks like this:
> 
>   while ((*l & 0x) == 0x0001) {
> pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l);
> if (delay > crs_timeout)
>   return false;
>   }
> 
> The problem is that the config read may have *succeeded* that last
> time before we time out.  I think the correct sequence is:
> 
>   - check for timeout
>   - read PCI_VENDOR_ID
>   - check for CRS
> 

Yeah, it makes sense.

>>  }
>> +} while ((*l & 0x) == 0x0001);
>> +
>> +return true;
>> +}
>> +EXPORT_SYMBOL(pci_bus_wait_crs);
> 
> I don't think we need EXPORT_SYMBOL here, do we?

copy/paste mistake. 

> 
>> +bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
>> +int crs_timeout)
>> +{
>> +if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
>> +return false;
>> +
>> +/* some broken boards return 0 or ~0 if a slot is empty: */
>> +if (*l == 0x || *l == 0x ||
>> +*l == 0x || *l == 0x)
>> +return false;
>> +
>> +/*
>> + * Configuration Request Retry Status.  Some root ports return the
>> + * actual device ID instead of the synthetic ID (0x) required
>> + * by the PCIe spec.  Ignore the device ID and only check for
>> + * (vendor id == 1).
>> + */
>> +if ((*l & 0x) == 0x0001) {
>> +if (!crs_timeout)
>> +return false;
> 
> One thing I don't like is that every caller of pci_bus_wait_crs() has
> to know about the 0x0001 value.

Another helper function? I was trying to poll for CRS completion only
if we know that we are observing CRS.

> 
>> +return pci_bus_wait_crs(bus, devfn, l, crs_timeout);
>>  }
>>  
>>  return true;
>> -- 
>> 1.9.1
>>
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 3.16 090/134] IB/core: If the MGID/MLID pair is not on the list return an error

[Ben Hutchings]

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

--

From: "Michael J. Ruhl" 

commit 20c7840a77ddcb2ed2fbd66e8197db2868495751 upstream.

A list of MGID/MLID pairs is built when doing a multicast attach.  When
the multicast detach is called, the list is searched, and regardless of
the search outcome, the driver detach is called.

If an MGID/MLID pair is not on the list, driver detach should not be
called, and an error should be returned.  Calling the driver without
removing an MGID/MLID pair from the list can leave the core and driver
out of sync.

Fixes: f4e401562c11 ("IB/uverbs: track multicast group membership for userspace 
QPs")
Reviewed-by: Ira Weiny 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Michael J. Ruhl 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/infiniband/core/uverbs_cmd.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2577,6 +2577,7 @@ ssize_t ib_uverbs_detach_mcast(struct ib
struct ib_qp *qp;
struct ib_uverbs_mcast_entry *mcast;
int   ret = -EINVAL;
+   bool  found = false;
 
if (copy_from_user(, buf, sizeof cmd))
return -EFAULT;
@@ -2585,10 +2586,6 @@ ssize_t ib_uverbs_detach_mcast(struct ib
if (!qp)
return -EINVAL;
 
-   ret = ib_detach_mcast(qp, (union ib_gid *) cmd.gid, cmd.mlid);
-   if (ret)
-   goto out_put;
-
obj = container_of(qp->uobject, struct ib_uqp_object, uevent.uobject);
 
list_for_each_entry(mcast, >mcast_list, list)
@@ -2596,9 +2593,17 @@ ssize_t ib_uverbs_detach_mcast(struct ib
!memcmp(cmd.gid, mcast->gid.raw, sizeof mcast->gid.raw)) {
list_del(>list);
kfree(mcast);
+   found = true;
break;
}
 
+   if (!found) {
+   ret = -EINVAL;
+   goto out_put;
+   }
+
+   ret = ib_detach_mcast(qp, (union ib_gid *)cmd.gid, cmd.mlid);
+
 out_put:
put_qp_write(qp);
 

[PATCH 3.16 092/134] libata: reject passthrough WRITE SAME requests

[Ben Hutchings]

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

--

From: Christoph Hellwig 

commit c6ade20f5e50e188d20b711a618b20dd1d50457e upstream.

The WRITE SAME to TRIM translation rewrites the DATA OUT buffer.  While
the SCSI code accomodates for this by passing a read-writable buffer
userspace applications don't cater for this behavior.  In fact it can
be used to rewrite e.g. a readonly file through mmap and should be
considered as a security fix.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Tejun Heo 
[bwh: Backported to 3.16:
 - Open-code blk_rq_is_passthrough()
 - We don't distinguish which field is invaid so goto invalid_fld
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/ata/libata-scsi.c | 8 
 1 file changed, 8 insertions(+)

--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3097,6 +3097,14 @@ static unsigned int ata_scsi_write_same_
if (unlikely(!dev->dma_mode))
goto invalid_fld;
 
+   /*
+* We only allow sending this command through the block layer,
+* as it modifies the DATA OUT buffer, which would corrupt user
+* memory for SG_IO commands.
+*/
+   if (unlikely(scmd->request->cmd_type != REQ_TYPE_FS))
+   goto invalid_fld;
+
if (unlikely(scmd->cmd_len < 16))
goto invalid_fld;
scsi_16_lba_len(cdb, , _block);

[PATCH 3.16 085/134] mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode

[Ben Hutchings]

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

--

From: Tony Lindgren 

commit 8b8a84c54aff4256d592dc18346c65ecf6811b45 upstream.

Commit 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
added support for USB TLL, but uses OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
bit the wrong way. The comments in the code are correct, but the inverted
use of OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF causes the register to be
enabled instead of disabled unlike what the comments say.

Without this change the Wrigley 3G LTE modem on droid 4 EHCI bus can
be only pinged few times before it stops responding.

Fixes: 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
Signed-off-by: Tony Lindgren 
Acked-by: Roger Quadros 
Signed-off-by: Lee Jones 
Signed-off-by: Ben Hutchings 
---
 drivers/mfd/omap-usb-tll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -376,8 +376,8 @@ int omap_tll_init(struct usbhs_omap_plat
 * and use SDR Mode
 */
reg &= ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
-   | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
| OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE);
+   reg |= OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF;
} else if (pdata->port_mode[i] ==
OMAP_EHCI_PORT_MODE_HSIC) {
/*

[PATCH 3.16 087/134] staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data()

[Ben Hutchings]

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

--

From: Dan Carpenter 

commit 784047eb2d3405a35087af70cba46170c5576b25 upstream.

The "len" could be as low as -14 so we should check for negatives.

Fixes: 9a7fe54ddc3a ("staging: r8188eu: Add source files for new driver - part 
1")
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -881,7 +881,7 @@ int rtw_check_beacon_data(struct adapter
return _FAIL;
 
 
-   if (len > MAX_IE_SZ)
+   if (len < 0 || len > MAX_IE_SZ)
return _FAIL;
 
pbss_network->IELength = len;

[PATCH 3.16 089/134] staging: gdm724x: gdm_mux: fix use-after-free on module unload

[Ben Hutchings]

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

--

From: Johan Hovold 

commit b58f45c8fc301fe83ee28cad3e64686c19e78f1c upstream.

Make sure to deregister the USB driver before releasing the tty driver
to avoid use-after-free in the USB disconnect callback where the tty
devices are deregistered.

Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Cc: Won Kang 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/gdm724x/gdm_mux.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -666,9 +666,8 @@ static int __init gdm_usb_mux_init(void)
 
 static void __exit gdm_usb_mux_exit(void)
 {
-   unregister_lte_tty_driver();
-
usb_deregister(_mux_driver);
+   unregister_lte_tty_driver();
 }
 
 module_init(gdm_usb_mux_init);

[PATCH 3.16 086/134] dm ioctl: prevent stack leak in dm ioctl call

[Ben Hutchings]

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

--

From: Adrian Salido 

commit 4617f564c06117c7d1b611be49521a4430042287 upstream.

When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
dm_ioctl are left initialized.  Current code is incorrectly extending
the size of data copied back to user, causing the contents of kernel
stack to be leaked to user.  Fix by only copying contents before data
and allow the functions processing the ioctl to override.

Signed-off-by: Adrian Salido 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Mike Snitzer 
Signed-off-by: Ben Hutchings 
---
 drivers/md/dm-ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1839,7 +1839,7 @@ static int ctl_ioctl(uint command, struc
if (r)
goto out;
 
-   param->data_size = sizeof(*param);
+   param->data_size = offsetof(struct dm_ioctl, data);
r = fn(param, input_param_size);
 
if (unlikely(param->flags & DM_BUFFER_FULL_FLAG) &&

[PATCH 3.2 50/59] tcp: fix wraparound issue in tcp_lp

[Ben Hutchings]

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

--

From: Eric Dumazet 

commit a9f11f963a546fea9144f6a6d1a307e814a387e7 upstream.

Be careful when comparing tcp_time_stamp to some u32 quantity,
otherwise result can be surprising.

Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/tcp_lp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct soc
 {
struct tcp_sock *tp = tcp_sk(sk);
struct lp *lp = inet_csk_ca(sk);
+   u32 delta;
 
if (rtt_us > 0)
tcp_lp_rtt_sample(sk, rtt_us);
 
/* calc inference */
-   if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
-   lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+   delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
+   if ((s32)delta > 0)
+   lp->inference = 3 * delta;
 
/* test if within inference */
if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))

[PATCH 3.16 088/134] staging: gdm724x: gdm_mux: Remove create_workqueue()

[Ben Hutchings]

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

--

From: Amitoj Kaur Chawla 

commit c272dc2da14cde0bfd9495a5aafb8e3e94f35601 upstream.

With concurrency managed workqueues, use of dedicated workqueues
can be replaced by using system_wq. Drop mux_rx_wq by using system_wq.

Since there is only one work item per mux_dev and different mux_devs
do not need to be ordered, increase of concurrency level by switching
to system_wq should not break anything.

cancel_work_sync() is used to ensure that work is not pending or
executing on any CPU.

Lastly, since all devices are suspended, which shutdowns the work item
before the driver can be unregistered, it is guaranteed that no work
item is pending or executing by the time exit path runs.

Signed-off-by: Amitoj Kaur Chawla 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/staging/gdm724x/gdm_mux.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -26,8 +26,6 @@
 
 #include "gdm_mux.h"
 
-static struct workqueue_struct *mux_rx_wq;
-
 static u16 packet_type[TTY_MAX_COUNT] = {0xF011, 0xF010};
 
 #define USB_DEVICE_CDC_DATA(vid, pid) \
@@ -277,7 +275,7 @@ static void gdm_mux_rcv_complete(struct
r->len = r->urb->actual_length;
spin_lock_irqsave(>to_host_lock, flags);
list_add_tail(>to_host_list, >to_host_list);
-   queue_work(mux_rx_wq, _dev->work_rx.work);
+   schedule_work(_dev->work_rx.work);
spin_unlock_irqrestore(>to_host_lock, flags);
}
 }
@@ -604,6 +602,8 @@ static int gdm_mux_suspend(struct usb_in
mux_dev = tty_dev->priv_dev;
rx = _dev->rx;
 
+   cancel_work_sync(_dev->work_rx.work);
+
if (mux_dev->usb_state != PM_NORMAL) {
pr_err("usb suspend - invalid state\n");
return -1;
@@ -659,13 +659,6 @@ static struct usb_driver gdm_mux_driver
 
 static int __init gdm_usb_mux_init(void)
 {
-
-   mux_rx_wq = create_workqueue("mux_rx_wq");
-   if (mux_rx_wq == NULL) {
-   pr_err("work queue create fail\n");
-   return -1;
-   }
-
register_lte_tty_driver();
 
return usb_register(_mux_driver);
@@ -675,11 +668,6 @@ static void __exit gdm_usb_mux_exit(void
 {
unregister_lte_tty_driver();
 
-   if (mux_rx_wq) {
-   flush_workqueue(mux_rx_wq);
-   destroy_workqueue(mux_rx_wq);
-   }
-
usb_deregister(_mux_driver);
 }
 

[PATCH 3.16 079/134] dm era: save spacemap metadata root after the pre-commit

[Ben Hutchings]

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

--

From: Somasundaram Krishnasamy 

commit 117aceb030307dcd431fdcff87ce988d3016c34a upstream.

When committing era metadata to disk, it doesn't always save the latest
spacemap metadata root in superblock. Due to this, metadata is getting
corrupted sometimes when reopening the device. The correct order of update
should be, pre-commit (shadows spacemap root), save the spacemap root
(newly shadowed block) to in-core superblock and then the final commit.

Signed-off-by: Somasundaram Krishnasamy 
Signed-off-by: Mike Snitzer 
Signed-off-by: Ben Hutchings 
---
 drivers/md/dm-era-target.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/md/dm-era-target.c
+++ b/drivers/md/dm-era-target.c
@@ -957,15 +957,15 @@ static int metadata_commit(struct era_me
}
}
 
-   r = save_sm_root(md);
+   r = dm_tm_pre_commit(md->tm);
if (r) {
-   DMERR("%s: save_sm_root failed", __func__);
+   DMERR("%s: pre commit failed", __func__);
return r;
}
 
-   r = dm_tm_pre_commit(md->tm);
+   r = save_sm_root(md);
if (r) {
-   DMERR("%s: pre commit failed", __func__);
+   DMERR("%s: save_sm_root failed", __func__);
return r;
}
 

[PATCH 3.16 069/134] x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup

[Ben Hutchings]

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

--

From: Ashish Kalra 

commit d594aa0277e541bb997aef0bc0a55172d8138340 upstream.

The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
when the bootloader does not setup/provide a stack for the early boot components
is not "enough".

The setup code executing as part of early kernel startup code, uses the stack
beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
section. This is exposed mostly in the early video setup code, where
it was corrupting BSS variables like force_x, force_y, which in-turn affected
kernel parameters such as screen_info (screen_info.orig_video_cols) and
later caused an exception/panic in console_init().

Most recent boot loaders setup the stack for early boot components, so this
stack overwriting into BSS section issue has not been exposed.

Signed-off-by: Ashish Kalra 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.local
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings 
---
 arch/x86/boot/boot.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
 #ifndef BOOT_BOOT_H
 #define BOOT_BOOT_H
 
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+#define STACK_SIZE 1024/* Minimum number of bytes for stack */
 
 #ifndef __ASSEMBLY__
 

[PATCH 3.16 072/134] HSI: ssi_protocol: double free in ssip_pn_xmit()

[Ben Hutchings]

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

--

From: Dan Carpenter 

commit 3026050179a3a9a6f5c892c414b5e36ecf092081 upstream.

If skb_pad() fails then it frees skb and we don't need to free it again
at the end of the function.

Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol")
Signed-off-by: Dan Carpenter 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Ben Hutchings 
---
 drivers/hsi/clients/ssi_protocol.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -976,7 +976,7 @@ static int ssip_pn_xmit(struct sk_buff *
goto drop;
/* Pad to 32-bits - FIXME: Revisit*/
if ((skb->len & 3) && skb_pad(skb, 4 - (skb->len & 3)))
-   goto drop;
+   goto inc_dropped;
 
/*
 * Modem sends Phonet messages over SSI with its own endianess...
@@ -1028,8 +1028,9 @@ static int ssip_pn_xmit(struct sk_buff *
 drop2:
hsi_free_msg(msg);
 drop:
-   dev->stats.tx_dropped++;
dev_kfree_skb(skb);
+inc_dropped:
+   dev->stats.tx_dropped++;
 
return 0;
 }

Re: [PATCH v8 2/2] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Fri, 18 Aug 2017 17:21:59 +0900
Byungchul Park  wrote:

> It would be better to try to check other siblings first if
> SD_PREFER_SIBLING is flaged when pushing tasks - migration.
> 
> Signed-off-by: Byungchul Park 

Looks good.

Reviewed-by: Steven Rostedt (VMware) 

-- Steve

[PATCH 3.16 068/134] mwifiex: pcie: fix cmd_buf use-after-free in remove/reset

[Ben Hutchings]

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

--

From: Brian Norris 

commit 3c8cb9ad032d737b874e402c59eb51e3c991a144 upstream.

Command buffers (skb's) are allocated by the main driver, and freed upon
the last use. That last use is often in mwifiex_free_cmd_buffer(). In
the meantime, if the command buffer gets used by the PCI driver, we map
it as DMA-able, and store the mapping information in the 'cb' memory.

However, if a command was in-flight when resetting the device (and
therefore was still mapped), we don't get a chance to unmap this memory
until after the core has cleaned up its command handling.

Let's keep a refcount within the PCI driver, so we ensure the memory
only gets freed after we've finished unmapping it.

Noticed by KASAN when forcing a reset via:

  echo 1 > /sys/bus/pci/.../reset

The same code path can presumably be exercised in remove() and
shutdown().

[  205.390377] mwifiex_pcie :01:00.0: info: shutdown mwifiex...
[  205.400393] 
==
[  205.407719] BUG: KASAN: use-after-free in 
mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr 
ffc0ad471b28
[  205.419040] Read of size 16 by task bash/1913
[  205.423421] 
=
[  205.431625] BUG skbuff_head_cache (Tainted: GB  ): kasan: bad 
access detected
[  205.439815] 
-
[  205.439815]
[  205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
[  205.456709]  alloc_debug_processing+0x124/0x178
[  205.461282]  ___slab_alloc.constprop.58+0x528/0x608
[  205.466196]  __slab_alloc.isra.54.constprop.57+0x44/0x54
[  205.471542]  kmem_cache_alloc+0xcc/0x278
[  205.475497]  __build_skb+0x48/0x114
[  205.479019]  __netdev_alloc_skb+0xe0/0x170
[  205.483244]  mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
[  205.488759]  mwifiex_init_fw+0x40/0x6cc [mwifiex]
[  205.493584]  _mwifiex_fw_dpc+0x158/0x520 [mwifiex]
[  205.498491]  mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
[  205.503510]  mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
[  205.509643]  pci_reset_notify+0x5c/0x6c
[  205.513519]  pci_reset_function+0x6c/0x7c
[  205.517567]  reset_store+0x68/0x98
[  205.521003]  dev_attr_store+0x54/0x60
[  205.524705]  sysfs_kf_write+0x9c/0xb0
[  205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
[  205.535064]  free_debug_processing+0x264/0x370
[  205.539550]  __slab_free+0x84/0x40c
[  205.543075]  kmem_cache_free+0x1c8/0x2a0
[  205.547030]  __kfree_skb+0xb0/0xbc
[  205.550465]  consume_skb+0x164/0x178
[  205.554079]  __dev_kfree_skb_any+0x58/0x64
[  205.558304]  mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
[  205.563817]  mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
[  205.569164]  mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
[  205.574353]  mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.580398]  pci_reset_notify+0x5c/0x6c
[  205.584274]  pci_dev_save_and_disable+0x24/0x6c
[  205.588837]  pci_reset_function+0x30/0x7c
[  205.592885]  reset_store+0x68/0x98
[  205.596324]  dev_attr_store+0x54/0x60
[  205.600017]  sysfs_kf_write+0x9c/0xb0
...
[  205.800488] Call trace:
[  205.802980] [] dump_backtrace+0x0/0x190
[  205.808415] [] show_stack+0x20/0x28
[  205.813506] [] dump_stack+0xa4/0xcc
[  205.818598] [] print_trailer+0x158/0x168
[  205.824120] [] object_err+0x4c/0x5c
[  205.829210] [] kasan_report+0x334/0x500
[  205.834641] [] check_memory_region+0x20/0x14c
[  205.840593] [] __asan_loadN+0x14/0x1c
[  205.845879] [] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 
[mwifiex_pcie]
[  205.854282] [] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 
[mwifiex_pcie]
[  205.862421] [] mwifiex_pcie_free_buffers+0x11c/0x158 
[mwifiex_pcie]
[  205.870302] [] mwifiex_pcie_down_dev+0x70/0x80 
[mwifiex_pcie]
[  205.877736] [] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[  205.884658] [] mwifiex_pcie_reset_notify+0xd4/0x15c 
[mwifiex_pcie]
[  205.892446] [] pci_reset_notify+0x5c/0x6c
[  205.898048] [] pci_dev_save_and_disable+0x24/0x6c
[  205.904350] [] pci_reset_function+0x30/0x7c
[  205.910134] [] reset_store+0x68/0x98
[  205.915312] [] dev_attr_store+0x54/0x60
[  205.920750] [] sysfs_kf_write+0x9c/0xb0
[  205.926182] [] kernfs_fop_write+0x184/0x1f8
[  205.931963] [] __vfs_write+0x6c/0x17c
[  205.937221] [] vfs_write+0xf0/0x1c4
[  205.942310] [] SyS_write+0x78/0xd8
[  205.947312] [] el0_svc_naked+0x24/0x28
...
[  205.998268] 
==

This bug has been around in different forms for a while. It was sort of
noticed in commit 955ab095c51a ("mwifiex: Do not kfree cmd buf while
unregistering PCIe"), but it just fixed the double-free, without
acknowledging the potential for use-after-free.

Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")

[PATCH 3.16 070/134] NFS: Use GFP_NOIO for two allocations in writeback

[Ben Hutchings]

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

--

From: Benjamin Coddington 

commit ae97aa524ef495b6276fd26f5d5449fb22975d7c upstream.

Prevent a deadlock that can occur if we wait on allocations
that try to write back our pages.

Signed-off-by: Benjamin Coddington 
Fixes: 00bfa30abe869 ("NFS: Create a common pgio_alloc and pgio_release...")
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.16:
 - Drop changes in nfs_pageio_init()
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/nfs/pagelist.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -29,13 +29,14 @@
 static struct kmem_cache *nfs_page_cachep;
 static const struct rpc_call_ops nfs_pgio_common_ops;
 
-static bool nfs_pgarray_set(struct nfs_page_array *p, unsigned int pagecount)
+static bool nfs_pgarray_set(struct nfs_page_array *p, unsigned int pagecount,
+   gfp_t gfp_flags)
 {
p->npages = pagecount;
if (pagecount <= ARRAY_SIZE(p->page_array))
p->pagevec = p->page_array;
else {
-   p->pagevec = kcalloc(pagecount, sizeof(struct page *), 
GFP_KERNEL);
+   p->pagevec = kcalloc(pagecount, sizeof(struct page *), 
gfp_flags);
if (!p->pagevec)
p->npages = 0;
}
@@ -739,9 +740,12 @@ int nfs_generic_pgio(struct nfs_pageio_d
struct list_head *head = >pg_list;
struct nfs_commit_info cinfo;
unsigned int pagecount, pageused;
+   gfp_t gfp_flags = GFP_KERNEL;
 
pagecount = nfs_page_array_len(desc->pg_base, desc->pg_count);
-   if (!nfs_pgarray_set(>page_array, pagecount))
+   if (desc->pg_rw_ops->rw_mode == FMODE_WRITE)
+   gfp_flags = GFP_NOIO;
+   if (!nfs_pgarray_set(>page_array, pagecount, gfp_flags))
return nfs_pgio_error(desc, hdr);
 
nfs_init_cinfo(, desc->pg_inode, desc->pg_dreq);

[PATCH 3.16 071/134] IB/ipoib: Update broadcast object if PKey value was changed in index 0

[Ben Hutchings]

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

--

From: Feras Daoud 

commit 9a9b8112699d78e7f317019b37f377e90023f3ed upstream.

Update the broadcast address in the priv->broadcast object when the
Pkey value changes in index 0, otherwise the multicast GID value will
keep the previous value of the PKey, and will not be updated.
This leads to interface state down because the interface will keep the
old PKey value.

For example, in SR-IOV environment, if the PF changes the value of PKey
index 0 for one of the VFs, then the VF receives PKey change event that
triggers heavy flush. This flush calls update_parent_pkey that update the
broadcast object and its relevant members. If in this case the multicast
GID will not be updated, the interface state will be down.

Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization 
environments")
Signed-off-by: Feras Daoud 
Signed-off-by: Erez Shitrit 
Reviewed-by: Alex Vesker 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Ben Hutchings 
---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +
 1 file changed, 13 insertions(+)

--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -961,6 +961,19 @@ static inline int update_parent_pkey(str
 */
priv->dev->broadcast[8] = priv->pkey >> 8;
priv->dev->broadcast[9] = priv->pkey & 0xff;
+
+   /*
+* Update the broadcast address in the priv->broadcast object,
+* in case it already exists, otherwise no one will do that.
+*/
+   if (priv->broadcast) {
+   spin_lock_irq(>lock);
+   memcpy(priv->broadcast->mcmember.mgid.raw,
+  priv->dev->broadcast + 4,
+   sizeof(union ib_gid));
+   spin_unlock_irq(>lock);
+   }
+
return 0;
}
 

[PATCH 3.16 064/134] [media] ov2640: fix vflip control

[Ben Hutchings]

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

--

From: Frank Schaefer 

commit 7f140fc2064bcd23e0490d8210650e2ef21c1c89 upstream.

Enabling vflip currently causes wrong colors.
It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only
changes the vertical readout direction.
Because pixels are arranged RGRG... in odd lines and GBGB... in even lines,
either a one line shift or even/odd line swap is required, too, but
apparently this doesn't happen.

I finally figured out that this can be done manually by setting
REG04_VREF_EN.
Looking at hflip, it turns out that bit REG04_HREF_EN is set there
permanetly, but according to my tests has no effect on the pixel readout
order.
So my conclusion is that the current documentation of sensor register 0x04
is wrong (has changed after preliminary datasheet version 2.2).

I'm pretty sure that automatic vertical line shift/switch can be enabled,
too, but until anyone finds ot how this works, we have to stick with manual
switching.

Signed-off-by: Frank Schäfer 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/i2c/soc_camera/ov2640.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -713,8 +713,10 @@ static int ov2640_s_ctrl(struct v4l2_ctr
 
switch (ctrl->id) {
case V4L2_CID_VFLIP:
-   val = ctrl->val ? REG04_VFLIP_IMG : 0x00;
-   return ov2640_mask_set(client, REG04, REG04_VFLIP_IMG, val);
+   val = ctrl->val ? REG04_VFLIP_IMG | REG04_VREF_EN : 0x00;
+   return ov2640_mask_set(client, REG04,
+  REG04_VFLIP_IMG | REG04_VREF_EN, val);
+   /* NOTE: REG04_VREF_EN: 1 line shift / even/odd line swap */
case V4L2_CID_HFLIP:
val = ctrl->val ? REG04_HFLIP_IMG : 0x00;
return ov2640_mask_set(client, REG04, REG04_HFLIP_IMG, val);

[PATCH 3.16 060/134] PCI: Freeze PME scan before suspending devices

[Ben Hutchings]

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

--

From: Lukas Wunner 

commit ea00353f36b64375518662a8ad15e39218a1f324 upstream.

Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790)
crashes during suspend tests.  Geert Uytterhoeven managed to reproduce the
issue on an M2-W Koelsch board (r8a7791):

  It occurs when the PME scan runs, once per second.  During PME scan, the
  PCI host bridge (rcar-pci) registers are accessed while its module clock
  has already been disabled, leading to the crash.

One reproducer is to configure s2ram to use "s2idle" instead of "deep"
suspend:

  # echo 0 > /sys/module/printk/parameters/console_suspend
  # echo s2idle > /sys/power/mem_sleep
  # echo mem > /sys/power/state

Another reproducer is to write either "platform" or "processors" to
/sys/power/pm_test.  It does not (or is less likely) to happen during full
system suspend ("core" or "none") because system suspend also disables
timers, and thus the workqueue handling PME scans no longer runs.  Geert
believes the issue may still happen in the small window between disabling
module clocks and disabling timers:

  # echo 0 > /sys/module/printk/parameters/console_suspend
  # echo platform > /sys/power/pm_test# Or "processors"
  # echo mem > /sys/power/state

(Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.)

Rafael Wysocki agrees that PME scans should be suspended before the host
bridge registers become inaccessible.  To that end, queue the task on a
workqueue that gets frozen before devices suspend.

Rafael notes however that as a result, some wakeup events may be missed if
they are delivered via PME from a device without working IRQ (which hence
must be polled) and occur after the workqueue has been frozen.  If that
turns out to be an issue in practice, it may be possible to solve it by
calling pci_pme_list_scan() once directly from one of the host bridge's
pm_ops callbacks.

Stacktrace for posterity:

  PM: Syncing filesystems ... [   38.566237] done.
  PM: Preparing system for sleep (mem)
  Freezing user space processes ... [   38.579813] (elapsed 0.001 seconds) done.
  Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
  PM: Suspending system (mem)
  PM: suspend of devices complete after 152.456 msecs
  PM: late suspend of devices complete after 2.809 msecs
  PM: noirq suspend of devices complete after 29.863 msecs
  suspend debug: Waiting for 5 second(s).
  Unhandled fault: asynchronous external abort (0x1211) at 0x
  pgd = c0003000
  [] *pgd=8040004003, *pmd=
  Internal error: : 1211 [#1] SMP ARM
  Modules linked in:
  CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
  4.9.0-rc1-koelsch-00011-g68db9bc814362e7f #3383
  Hardware name: Generic R8A7791 (Flattened Device Tree)
  Workqueue: events pci_pme_list_scan
  task: eb56e140 task.stack: eb58e000
  PC is at pci_generic_config_read+0x64/0x6c
  LR is at rcar_pci_cfg_base+0x64/0x84
  pc : []lr : []psr: 600d0093
  sp : eb58fe98  ip : c041d750  fp : 0008
  r10: c0e2283c  r9 :   r8 : 600d0013
  r7 : 0008  r6 : eb58fed6  r5 : 0002  r4 : eb58feb4
  r3 :   r2 : 0044  r1 : 0008  r0 : 
  Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
  Control: 30c5387d  Table: 6a9f6c80  DAC: 
  Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210)
  Stack: (0xeb58fe98 to 0xeb59)
  fe80:   0002 0044
  fea0: eb6f5800 c041d9b0 eb58feb4 0008 0044  eb78a000 eb78a000
  fec0: 0044  eb9aff00 c0424bf0 eb78a000  eb78a000 c0e22830
  fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc
  ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100
  ff20: eb55f398 c02366c4 eb56e140 eb5631c0  eb55f380 c023641c 
  ff40:    c023a928 cd105598  40506a34 eb55f380
  ff60:   dead4ead   eb58ff74 eb58ff74 
  ff80:  dead4ead   eb58ff90 eb58ff90 eb58ffac eb5631c0
  ffa0: c023a844   c0206d68    
  ffc0:        
  ffe0:     0013  3a81336c 10ccd1dd
  [] (pci_generic_config_read) from []
  (pci_bus_read_config_word+0x58/0x80)
  [] (pci_bus_read_config_word) from []
  (pci_check_pme_status+0x34/0x78)
  [] (pci_check_pme_status) from [] 
(pci_pme_wakeup+0x28/0x54)
  [] (pci_pme_wakeup) from [] (pci_pme_list_scan+0x58/0xb4)
  [] (pci_pme_list_scan) from []
  (process_one_work+0x1bc/0x308)
  [] (process_one_work) from [] (worker_thread+0x2a8/0x3e0)
  [] (worker_thread) from [] (kthread+0xe4/0xfc)
  [] (kthread) from [] (ret_from_fork+0x14/0x2c)
  Code: ea00 e5903000 f57ff04f e3a0 

[PATCH 3.16 065/134] ath9k: off by one in ath9k_hw_nvram_read_array()

[Ben Hutchings]

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

--

From: Dan Carpenter 

commit b7dcf68f383a05567bd16a390907b67022a62d3d upstream.

The > should be >= or we read one space beyond the end of the array.

Fixes: ab5c4f71d8c7 ("ath9k: allow to load EEPROM content via firmware API")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -118,7 +118,7 @@ static bool ath9k_hw_nvram_read_blob(str
 {
u16 *blob_data;
 
-   if (off * sizeof(u16) > ah->eeprom_blob->size)
+   if (off * sizeof(u16) >= ah->eeprom_blob->size)
return false;
 
blob_data = (u16 *)ah->eeprom_blob->data;

[PATCH 3.16 066/134] KVM: arm/arm64: fix races in kvm_psci_vcpu_on

[Ben Hutchings]

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

--

From: Andrew Jones 

commit 6c7a5dce22b3f3cc44be098e2837fa6797edb8b8 upstream.

Fix potential races in kvm_psci_vcpu_on() by taking the kvm->lock
mutex.  In general, it's a bad idea to allow more than one PSCI_CPU_ON
to process the same target VCPU at the same time.  One such problem
that may arise is that one PSCI_CPU_ON could be resetting the target
vcpu, which fills the entire sys_regs array with a temporary value
including the MPIDR register, while another looks up the VCPU based
on the MPIDR value, resulting in no target VCPU found.  Resolves both
races found with the kvm-unit-tests/arm/psci unit test.

Reviewed-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Reported-by: Levente Kurusa 
Suggested-by: Christoffer Dall 
Signed-off-by: Andrew Jones 
Signed-off-by: Christoffer Dall 
Signed-off-by: Ben Hutchings 
---
 arch/arm/kvm/psci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -191,9 +191,10 @@ int kvm_psci_version(struct kvm_vcpu *vc
 
 static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
 {
-   int ret = 1;
+   struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
+   int ret = 1;
 
switch (psci_fn) {
case PSCI_0_2_FN_PSCI_VERSION:
@@ -213,7 +214,9 @@ static int kvm_psci_0_2_call(struct kvm_
break;
case PSCI_0_2_FN_CPU_ON:
case PSCI_0_2_FN64_CPU_ON:
+   mutex_lock(>lock);
val = kvm_psci_vcpu_on(vcpu);
+   mutex_unlock(>lock);
break;
case PSCI_0_2_FN_AFFINITY_INFO:
case PSCI_0_2_FN64_AFFINITY_INFO:
@@ -269,6 +272,7 @@ static int kvm_psci_0_2_call(struct kvm_
 
 static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
 {
+   struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
 
@@ -278,7 +282,9 @@ static int kvm_psci_0_1_call(struct kvm_
val = PSCI_RET_SUCCESS;
break;
case KVM_PSCI_FN_CPU_ON:
+   mutex_lock(>lock);
val = kvm_psci_vcpu_on(vcpu);
+   mutex_unlock(>lock);
break;
case KVM_PSCI_FN_CPU_SUSPEND:
case KVM_PSCI_FN_MIGRATE:

[PATCH 3.16 067/134] usb: host: xhci: print correct command ring address

[Ben Hutchings]

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

--

From: Peter Chen 

commit 6fc091fb0459ade939a795bfdcaf645385b951d4 upstream.

Print correct command ring address using 'val_64'.

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/xhci-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2459,7 +2459,7 @@ int xhci_mem_init(struct xhci_hcd *xhci,
(xhci->cmd_ring->first_seg->dma & (u64) ~CMD_RING_RSVD_BITS) |
xhci->cmd_ring->cycle_state;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
-   "// Setting command ring address to 0x%x", val);
+   "// Setting command ring address to 0x%016llx", val_64);
xhci_write_64(xhci, val_64, >op_regs->cmd_ring);
xhci_dbg_cmd_ptrs(xhci);
 

[PATCH 3.16 053/134] net: ipv6: send unsolicited NA on admin up

[Ben Hutchings]

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

--

From: David Ahern 

commit 4a6e3c5def13c91adf2acc613837001f09af3baa upstream.

ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is
set to 1, gratuitous arp requests are sent when the device is brought up.
The same is expected when ndisc_notify is set to 1 (per ndisc_notify in
Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP
event; add it.

Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer 
address change")
Signed-off-by: David Ahern 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ndisc.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1605,6 +1605,8 @@ static int ndisc_netdev_event(struct not
case NETDEV_CHANGEADDR:
neigh_changeaddr(_tbl, dev);
fib6_run_gc(0, net, false);
+   /* fallthrough */
+   case NETDEV_UP:
idev = in6_dev_get(dev);
if (!idev)
break;

[PATCH 3.2 45/59] net: ethernet: ucc_geth: fix MEM_PART_MURAM mode

[Ben Hutchings]

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

--

From: Christophe Leroy 

commit 8b8642af15ed14b9a7a34d3401afbcc274533e13 upstream.

Since commit 5093bb965a163 ("powerpc/QE: switch to the cpm_muram
implementation"), muram area is not part of immrbar mapping anymore
so immrbar_virt_to_phys() is not usable anymore.

Fixes: 5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation")
Signed-off-by: Christophe Leroy 
Acked-by: David S. Miller 
Acked-by: Li Yang 
Signed-off-by: Scott Wood 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 arch/powerpc/include/asm/qe.h | 1 +
 drivers/net/ethernet/freescale/ucc_geth.c | 8 +++-
 2 files changed, 4 insertions(+), 5 deletions(-)

--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -193,6 +193,7 @@ static inline int qe_alive_during_sleep(
 #define qe_muram_free cpm_muram_free
 #define qe_muram_addr cpm_muram_addr
 #define qe_muram_offset cpm_muram_offset
+#define qe_muram_dma cpm_muram_dma
 
 /* Structure that defines QE firmware binary files.
  *
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -2591,11 +2591,10 @@ static int ucc_geth_startup(struct ucc_g
} else if (ugeth->ug_info->uf_info.bd_mem_part ==
   MEM_PART_MURAM) {
out_be32(>p_send_q_mem_reg->sqqd[i].bd_ring_base,
-(u32) immrbar_virt_to_phys(ugeth->
-   p_tx_bd_ring[i]));
+(u32)qe_muram_dma(ugeth->p_tx_bd_ring[i]));
out_be32(>p_send_q_mem_reg->sqqd[i].
 last_bd_completed_address,
-(u32) immrbar_virt_to_phys(endOfRing));
+(u32)qe_muram_dma(endOfRing));
}
}
 
@@ -2856,8 +2855,7 @@ static int ucc_geth_startup(struct ucc_g
} else if (ugeth->ug_info->uf_info.bd_mem_part ==
   MEM_PART_MURAM) {
out_be32(>p_rx_bd_qs_tbl[i].externalbdbaseptr,
-(u32) immrbar_virt_to_phys(ugeth->
-   p_rx_bd_ring[i]));
+(u32)qe_muram_dma(ugeth->p_rx_bd_ring[i]));
}
/* rest of fields handled by QE */
}

[PATCH 3.16 052/134] ftrace: Fix removing of second function probe

[Ben Hutchings]

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

--

From: "Steven Rostedt (VMware)" 

commit 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae upstream.

When two function probes are added to set_ftrace_filter, and then one of
them is removed, the update to the function locations is not performed, and
the record keeping of the function states are corrupted, and causes an
ftrace_bug() to occur.

This is easily reproducable by adding two probes, removing one, and then
adding it back again.

 # cd /sys/kernel/debug/tracing
 # echo schedule:traceoff > set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter
 # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter

Causes:
 [ cut here ]
 WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 
ftrace_get_addr_curr+0x143/0x220
 Modules linked in: [...]
 CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 
05/07/2012
 Call Trace:
  dump_stack+0x68/0x9f
  __warn+0x111/0x130
  ? trace_irq_work_interrupt+0xa0/0xa0
  warn_slowpath_null+0x1d/0x20
  ftrace_get_addr_curr+0x143/0x220
  ? __fentry__+0x10/0x10
  ftrace_replace_code+0xe3/0x4f0
  ? ftrace_int3_handler+0x90/0x90
  ? printk+0x99/0xb5
  ? 0x8100
  ftrace_modify_all_code+0x97/0x110
  arch_ftrace_update_code+0x10/0x20
  ftrace_run_update_code+0x1c/0x60
  ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
  register_ftrace_function_probe+0x4b6/0x590
  ? ftrace_startup+0x310/0x310
  ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
  ? update_stack_state+0x88/0x110
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? preempt_count_sub+0x18/0xd0
  ? mutex_lock_nested+0x104/0x800
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? __unwind_start+0x1c0/0x1c0
  ? _mutex_lock_nest_lock+0x800/0x800
  ftrace_trace_probe_callback.isra.3+0xc0/0x130
  ? func_set_flag+0xe0/0xe0
  ? __lock_acquire+0x642/0x1790
  ? __might_fault+0x1e/0x20
  ? trace_get_user+0x398/0x470
  ? strcmp+0x35/0x60
  ftrace_trace_onoff_callback+0x48/0x70
  ftrace_regex_write.isra.43.part.44+0x251/0x320
  ? match_records+0x420/0x420
  ftrace_filter_write+0x2b/0x30
  __vfs_write+0xd7/0x330
  ? do_loop_readv_writev+0x120/0x120
  ? locks_remove_posix+0x90/0x2f0
  ? do_lock_file_wait+0x160/0x160
  ? __lock_is_held+0x93/0x100
  ? rcu_read_lock_sched_held+0x5c/0xb0
  ? preempt_count_sub+0x18/0xd0
  ? __sb_start_write+0x10a/0x230
  ? vfs_write+0x222/0x240
  vfs_write+0xef/0x240
  SyS_write+0xab/0x130
  ? SyS_read+0x130/0x130
  ? trace_hardirqs_on_caller+0x182/0x280
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL_64_fastpath+0x18/0xad
 RIP: 0033:0x7fe61c157c30
 RSP: 002b:7ffe87890258 EFLAGS: 0246 ORIG_RAX: 0001
 RAX: ffda RBX: 8114a410 RCX: 7fe61c157c30
 RDX: 0010 RSI: 55814798f5e0 RDI: 0001
 RBP: 8800c9027f98 R08: 7fe61c422740 R09: 7fe61ca53700
 R10: 0073 R11: 0246 R12: 558147a36400
 R13: 7ffe8788f160 R14: 0024 R15: 7ffe8788f15c
  ? trace_hardirqs_off_caller+0xc0/0x110
 ---[ end trace 99fa09b3d9869c2c ]---
 Bad trampoline accounting at: 81cc3b00 (do_IRQ+0x0/0x150)

Fixes: 59df055f1991 ("ftrace: trace different functions with a different 
tracer")
Signed-off-by: Steven Rostedt (VMware) 
[bwh: Backported to 3.16:
 - Use ftrace_run_update_code() instead of ftrace_run_modify_code(), and
   don't define old_hash
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3119,23 +3119,24 @@ static void __enable_ftrace_function_pro
ftrace_probe_registered = 1;
 }
 
-static void __disable_ftrace_function_probe(void)
+static bool __disable_ftrace_function_probe(void)
 {
int i;
 
if (!ftrace_probe_registered)
-   return;
+   return false;
 
for (i = 0; i < FTRACE_FUNC_HASHSIZE; i++) {
struct hlist_head *hhd = _func_hash[i];
if (hhd->first)
-   return;
+   return false;
}
 
/* no more funcs left */
ftrace_shutdown(_probe_ops, 0);
 
ftrace_probe_registered = 0;
+   return true;
 }
 
 
@@ -3263,6 +3264,7 @@ __unregister_ftrace_function_probe(char
int type = MATCH_FULL;
int i, len = 0;
char *search;
+   bool disabled;
 
if (glob && (strcmp(glob, "*") == 0 || !strlen(glob)))
glob = NULL;
@@ -3316,12 +3318,16 @@ __unregister_ftrace_function_probe(char
}
}
mutex_lock(_lock);
-   __disable_ftrace_function_probe();
+   disabled = __disable_ftrace_function_probe();
/*
 * Remove after the disable is called. Otherwise, if the last
 * probe 

[PATCH 3.16 057/134] PCI: Ignore write combining when mapping I/O port space

[Ben Hutchings]

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

--

From: Bjorn Helgaas 

commit 3a92c319c44a7bcee9f48dff9d97d001943b54c6 upstream.

PCI exposes files like /proc/bus/pci/00/00.0 in procfs.  These files
support operations like this:

  ioctl(fd, PCIIOC_MMAP_IS_IO);   # request I/O port space
  ioctl(fd, PCIIOC_WRITE_COMBINE, 1); # request write-combining
  mmap(fd, ...)

Write combining is useful on PCI memory space, but I don't think it makes
sense on PCI I/O port space.

We *could* change proc_bus_pci_ioctl() to make it impossible to set
mmap_state == pci_mmap_io and write_combine at the same time, but that
would break the following sequence, which is currently legal:

  mmap(fd, ...)   # default is I/O, non-combining
  ioctl(fd, PCIIOC_WRITE_COMBINE, 1); # request write-combining
  ioctl(fd, PCIIOC_MMAP_IS_MEM);  # request memory space
  mmap(fd, ...)   # get write-combining mapping

Ignore the write-combining flag when mapping I/O port space.

This patch should have no functional effect, based on this analysis of all
implementations of pci_mmap_page_range():

  - ia64 mips parisc sh unicore32 x86 do not support mapping of I/O port
space at all.

  - arm cris microblaze mn10300 sparc xtensa support mapping of I/O port
space, but ignore the write_combine argument to pci_mmap_page_range().

  - powerpc supports mapping of I/O port space and uses write_combine, and
it disables write combining for I/O port space in
__pci_mmap_set_pgprot().

This patch makes it possible to remove __pci_mmap_set_pgprot() from
powerpc, which simplifies that path.

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Ben Hutchings 
---
 drivers/pci/proc.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -231,7 +231,7 @@ static int proc_bus_pci_mmap(struct file
 {
struct pci_dev *dev = PDE_DATA(file_inode(file));
struct pci_filp_private *fpriv = file->private_data;
-   int i, ret;
+   int i, ret, write_combine;
 
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
@@ -245,9 +245,12 @@ static int proc_bus_pci_mmap(struct file
if (i >= PCI_ROM_RESOURCE)
return -ENODEV;
 
+   if (fpriv->mmap_state == pci_mmap_mem)
+   write_combine = fpriv->write_combine;
+   else
+   write_combine = 0;
ret = pci_mmap_page_range(dev, vma,
- fpriv->mmap_state,
- fpriv->write_combine);
+ fpriv->mmap_state, write_combine);
if (ret < 0)
return ret;
 

[PATCH 3.16 048/134] perf/x86/pebs: Fix handling of PEBS buffer overflows

[Ben Hutchings]

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

--

From: Stephane Eranian 

commit daa864b8f8e34477bde817f26d736d89dc6032f3 upstream.

This patch solves a race condition between PEBS and the PMU handler.

In case multiple PEBS events are sampled at the same time,
it is possible to have GLOBAL_STATUS bit 62 set indicating
PEBS buffer overflow and also seeing at most 3 PEBS counters
having their bits set in the status register. This is a sign
that there was at least one PEBS record pending at the time
of the PMU interrupt. PEBS counters must only be processed
via the drain_pebs() calls, and not via the regular sample
processing loop coming after that the function, otherwise
phony regular samples may be generated in the sampling buffer
not marked with the EXACT tag.

Another possibility is to have one PEBS event and at least
one non-PEBS event whic hoverflows while PEBS has armed. In this
case, bit 62 of GLOBAL_STATUS will not be set, yet the overflow
status bit for the PEBS counter will be on Skylake.

To avoid this problem, we systematically ignore the PEBS-enabled
counters from the GLOBAL_STATUS mask and we always process PEBS
events via drain_pebs().

The problem manifested itself by having non-exact samples when
sampling only PEBS events, i.e., the PERF_SAMPLE_RECORD would
not have the EXACT flag set.

Note that this problem is only present on Skylake processor.
This fix is harmless on older processors.

Reported-by: Peter Zijlstra 
Signed-off-by: Stephane Eranian 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Link: 
http://lkml.kernel.org/r/1482395366-8992-1-git-send-email-eran...@google.com
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/cpu/perf_event_intel.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1402,20 +1402,33 @@ again:
}
 
/*
+* In case multiple PEBS events are sampled at the same time,
+* it is possible to have GLOBAL_STATUS bit 62 set indicating
+* PEBS buffer overflow and also seeing at most 3 PEBS counters
+* having their bits set in the status register. This is a sign
+* that there was at least one PEBS record pending at the time
+* of the PMU interrupt. PEBS counters must only be processed
+* via the drain_pebs() calls and not via the regular sample
+* processing loop coming after that the function, otherwise
+* phony regular samples may be generated in the sampling buffer
+* not marked with the EXACT tag. Another possibility is to have
+* one PEBS event and at least one non-PEBS event whic hoverflows
+* while PEBS has armed. In this case, bit 62 of GLOBAL_STATUS will
+* not be set, yet the overflow status bit for the PEBS counter will
+* be on Skylake.
+*
+* To avoid this problem, we systematically ignore the PEBS-enabled
+* counters from the GLOBAL_STATUS mask and we always process PEBS
+* events via drain_pebs().
+*/
+   status &= ~cpuc->pebs_enabled;
+
+   /*
 * PEBS overflow sets bit 62 in the global status register
 */
if (__test_and_clear_bit(62, (unsigned long *))) {
handled++;
x86_pmu.drain_pebs(regs);
-   /*
-* There are cases where, even though, the PEBS ovfl bit is set
-* in GLOBAL_OVF_STATUS, the PEBS events may also have their
-* overflow bits set for their counters. We must clear them
-* here because they have been processed as exact samples in
-* the drain_pebs() routine. They must not be processed again
-* in the for_each_bit_set() loop for regular samples below.
-*/
-   status &= ~cpuc->pebs_enabled;
status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI;
}
 

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

[Jan Glauber]

On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote:
> On Thu, 17 Aug 2017 10:14:23 +0200
> Jan Glauber  wrote:
> 
> > If a PCI device supports neither function-level reset, nor slot
> > or bus reset then refuse to probe it. A line is printed to inform
> > the user.
> 
> But that's not what this does, this requires that the device is on a
> reset-able bus.  This is a massive regression.  With this we could no
> longer assign devices on the root complex or any device which doesn't
> return from bus reset and currently makes use of the NO_BUS_RESET flag
> and works happily otherwise.  Full NAK.  Thanks,

Looks like I missed the slot reset check. So how about this:

if (pci_probe_reset_slot(pdev->slot) && pci_probe_reset_bus(pdev->bus)) {
dev_warn(...);
return -ENODEV;
}

Or am I still missing something here?

thanks,
Jan

> Alex
>  
> > Without this change starting qemu with a vfio-pci device can lead to
> > a kernel panic on some Cavium cn8xxx systems, depending on the used
> > device.
> > 
> > Signed-off-by: Jan Glauber 
> > ---
> >  drivers/vfio/pci/vfio_pci.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 063c1ce..029ba13 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -1196,6 +1196,12 @@ static int vfio_pci_probe(struct pci_dev *pdev, 
> > const struct pci_device_id *id)
> > if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
> > return -EINVAL;
> >  
> > +   ret = pci_probe_reset_bus(pdev->bus);
> > +   if (ret) {
> > +   dev_warn(>dev, "Refusing to probe because reset is not 
> > possible.\n");
> > +   return ret;
> > +   }
> > +
> > group = vfio_iommu_group_get(>dev);
> > if (!group)
> > return -EINVAL;

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

[Waiman Long]

On 08/17/2017 07:23 PM, Steven Rostedt wrote:
> On Thu, 17 Aug 2017 18:18:18 -0400
> Steven Rostedt  wrote:
>
>> On Thu, 17 Aug 2017 18:13:20 -0400
>> Steven Rostedt  wrote:
>>
>>> On Thu, 17 Aug 2017 17:27:22 -0400
>>> Waiman Long  wrote:
>>>
>>>   
 It is actually what the patch is trying to do by checking for the
 deletion flag in the mutex_trylock loop. Please note that mutex does not
 guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call
 mutex_lock() and wait for it while cpu2 can set the deletion flag later
 and get the mutex first before cpu1. So checking for the deletion flag
 before taking the mutex isn't enough.
>>> Yeah, I figured that out already (crossed emails). BTW, how did you
>>> trigger this warning. I'm playing around with adding loop devices,
>>> volume groups, and logical volumes, and reading the trace files
>>> created in the sysfs directory, then removing those items, but it's
>>> not triggering the "delete" path. What operation deletes the partition?  
>> I'm guessing that deleting an actual partition may work (unfortunately,
>> my test box has no partition to delete ;-) I'll find another box to
>> test on.
>>
> OK, deleting a partition doesn't trigger the lockdep splat. But I also
> added a printk in the BLKPG_DEL_PARTITION case switch, which also
> doesn't print. What command do I need to do to trigger that path?
>
> Thanks,
>
> -- Steve

Attached is a reproducer that was used to trigger the warning. Some
tuning may be needed depend on the actual configuration of the test machine.

Cheers,
Longman



run_test.sh
Description: application/shellscript

Re: [PATCH v3 0/2] cpuset: Allow v2 behavior in v1 cgroup

[Waiman Long]

On 08/18/2017 07:29 AM, Tejun Heo wrote:
> On Thu, Aug 17, 2017 at 03:33:08PM -0400, Waiman Long wrote:
>> v2->v3:
>>  - Change the generic CGRP_ROOT_V2_MODE flag to a cpuset specific
>>CGRP_ROOT_CPUSET_V2_MODE flag.
>>
>> v1->v2:
>>  - Drop the kernel command line option and use cgroupfs mount option
>>instead to enable v2 controller behavior in v1 cgroup.
>>
>> v1: https://lkml.org/lkml/2017/8/15/570
> Waiman, patches look good to me but can you please take care of the
> kbuild warnings on 32bit and maybe merge the two patches into one?

The kbuild warning is in the __init code of the v1 patch for checking
the boot time argument. The __init code was gone in the v3 patch. So if
there is no further kbuild warning after a couple of days, I think it
should be OK.

Cheers,
Longman

[PATCH 3.16 051/134] iio: proximity: as3935: fix as3935_write

[Ben Hutchings]

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

--

From: Matt Ranostay 

commit 84ca8e364acb26aba3292bc113ca8ed4335380fd upstream.

AS3935_WRITE_DATA macro bit is incorrect and the actual write
sequence is two leading zeros.

Cc: George McCollister 
Signed-off-by: Matt Ranostay 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings 
---
 drivers/iio/proximity/as3935.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -50,7 +50,6 @@
 #define AS3935_TUNE_CAP0x08
 #define AS3935_CALIBRATE   0x3D
 
-#define AS3935_WRITE_DATA  BIT(15)
 #define AS3935_READ_DATA   BIT(14)
 #define AS3935_ADDRESS(x)  ((x) << 8)
 
@@ -105,7 +104,7 @@ static int as3935_write(struct as3935_st
 {
u8 *buf = st->buf;
 
-   buf[0] = (AS3935_WRITE_DATA | AS3935_ADDRESS(reg)) >> 8;
+   buf[0] = AS3935_ADDRESS(reg) >> 8;
buf[1] = val;
 
return spi_write(st->spi, buf, 2);

Re: [PATCH v4] livepatch: introduce shadow variable API

[Joe Lawrence]

On 08/17/2017 10:05 AM, Petr Mladek wrote:
> On Mon 2017-08-14 16:02:43, Joe Lawrence wrote:
>> [ ... snip ... ]
>> diff --git a/samples/livepatch/livepatch-shadow-fix1.c 
>> b/samples/livepatch/livepatch-shadow-fix1.c
>> new file mode 100644
>> index ..5acc838463d1
>> --- /dev/null
>> +++ b/samples/livepatch/livepatch-shadow-fix1.c
>> +void livepatch_fix1_dummy_free(struct dummy *d)
>> +{
>> +void **shadow_leak;
>> +
>> +/*
>> + * Patch: fetch the saved SV_LEAK shadow variable, detach and
>> + * free it.  Note: handle cases where this shadow variable does
>> + * not exist (ie, dummy structures allocated before this livepatch
>> + * was loaded.)
>> + */
>> +shadow_leak = klp_shadow_get(d, SV_LEAK);
>> +if (shadow_leak) {
>> +klp_shadow_detach(d, SV_LEAK);
>> +kfree(*shadow_leak);
> 
> This should get removed. The buffer used for the shadow variable
> is freed by kfree_rcu() called from klp_shadow_detach().
> 
> Same problem is also in the other livepatch.
> 
>> +pr_info("%s: dummy @ %p, prevented leak @ %p\n",
>> + __func__, d, *shadow_leak);
> 
> This might access shadow_leak after it was (double) freed.
> 
>> +} else {
>> +pr_info("%s: dummy @ %p leaked!\n", __func__, d);
>> +}
>> +
>> +kfree(d);
>> +}

Hi Petr,

I think you're half correct.

The kfree is the crux of the memory leak patch, so it needs to stay.
However, the shadow variable is holding a copy of the pointer to the
memory leak area, so you're right that it can't be safely dereferenced
after the shadow variable is detached*.

The code should to be rearranged like:

void livepatch_fix1_dummy_free(struct dummy *d)
{
void **p_shadow_leak, *shadow_leak;

p_shadow_leak = klp_shadow_get(d, SV_LEAK);
if (p_shadow_leak) {
shadow_leak = *p_shadow_leak;   << deref before detach
klp_shadow_detach(d, SV_LEAK);
kfree(shadow_leak);
...

* Aside: I usually develop with slub_debug=FZPU set to catch silly
use-after-frees like this.  However, since the shadow variable is
released via kfree_rcu(), I think there was a window before the grace
period where this one worked out okay...  once I added a
synchronize_rcu() call in between the klp_shadow_detch() and kfree()
calls, I did see the poison pattern.  This is my first time using
kfree_rcu(), so it was interesting to dig into.

Thanks,

-- Joe

[PATCH 3.16 044/134] vfio/type1: Remove locked page accounting workqueue

[Ben Hutchings]

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

--

From: Alex Williamson 

commit 0cfef2b7410b64d7a430947e0b533314c4f97153 upstream.

If the mmap_sem is contented then the vfio type1 IOMMU backend will
defer locked page accounting updates to a workqueue task.  This has a
few problems and depending on which side the user tries to play, they
might be over-penalized for unmaps that haven't yet been accounted or
race the workqueue to enter more mappings than they're allowed.  The
original intent of this workqueue mechanism seems to be focused on
reducing latency through the ioctl, but we cannot do so at the cost
of correctness.  Remove this workqueue mechanism and update the
callers to allow for failure.  We can also now recheck the limit under
write lock to make sure we don't exceed it.

vfio_pin_pages_remote() also now necessarily includes an unwind path
which we can jump to directly if the consecutive page pinning finds
that we're exceeding the user's memory limits.  This avoids the
current lazy approach which does accounting and mapping up to the
fault, only to return an error on the next iteration to unwind the
entire vfio_dma.

Reviewed-by: Peter Xu 
Reviewed-by: Kirti Wankhede 
Signed-off-by: Alex Williamson 
[bwh: Backported to 3.16:
 - vfio_lock_acct() always operates on current->mm
 - Drop changes to vfio_{,un}pin_page_external() and
   vfio_iommu_unmap_unpin_reaccount()
 - Drop test of rsvd flag
 - Fix up the disable_hugepages case in vfio_pin_pages()
 - Use down_write() instead of down_write_killable()
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -128,57 +128,37 @@ static void vfio_unlink_dma(struct vfio_
rb_erase(>node, >dma_list);
 }
 
-struct vwork {
-   struct mm_struct*mm;
-   longnpage;
-   struct work_struct  work;
-};
-
-/* delayed decrement/increment for locked_vm */
-static void vfio_lock_acct_bg(struct work_struct *work)
+static int vfio_lock_acct(long npage, bool *lock_cap)
 {
-   struct vwork *vwork = container_of(work, struct vwork, work);
struct mm_struct *mm;
+   int ret;
 
-   mm = vwork->mm;
-   down_write(>mmap_sem);
-   mm->locked_vm += vwork->npage;
-   up_write(>mmap_sem);
-   mmput(mm);
-   kfree(vwork);
-}
+   if (!npage)
+   return 0;
 
-static void vfio_lock_acct(long npage)
-{
-   struct vwork *vwork;
-   struct mm_struct *mm;
+   mm = current->mm;
+   if (!mm)
+   return -ESRCH; /* process exited */
 
-   if (!current->mm || !npage)
-   return; /* process exited or nothing to do */
+   ret = 0;
+   down_write(>mmap_sem);
+   if (npage > 0) {
+   if (lock_cap ? !*lock_cap : !capable(CAP_IPC_LOCK)) {
+   unsigned long limit;
 
-   if (down_write_trylock(>mm->mmap_sem)) {
-   current->mm->locked_vm += npage;
-   up_write(>mm->mmap_sem);
-   return;
-   }
+   limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
 
-   /*
-* Couldn't get mmap_sem lock, so must setup to update
-* mm->locked_vm later. If locked_vm were atomic, we
-* wouldn't need this silliness
-*/
-   vwork = kmalloc(sizeof(struct vwork), GFP_KERNEL);
-   if (!vwork)
-   return;
-   mm = get_task_mm(current);
-   if (!mm) {
-   kfree(vwork);
-   return;
+   if (mm->locked_vm + npage > limit)
+   ret = -ENOMEM;
+   }
}
-   INIT_WORK(>work, vfio_lock_acct_bg);
-   vwork->mm = mm;
-   vwork->npage = npage;
-   schedule_work(>work);
+
+   if (!ret)
+   mm->locked_vm += npage;
+
+   up_write(>mmap_sem);
+
+   return ret;
 }
 
 /*
@@ -260,7 +240,7 @@ static int vaddr_get_pfn(unsigned long v
 static long vfio_pin_pages(unsigned long vaddr, long npage,
   int prot, unsigned long *pfn_base)
 {
-   unsigned long limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+   unsigned long pfn = 0, limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
bool lock_cap = capable(CAP_IPC_LOCK);
long ret, i;
 
@@ -282,14 +262,13 @@ static long vfio_pin_pages(unsigned long
}
 
if (unlikely(disable_hugepages)) {
-   vfio_lock_acct(1);
-   return 1;
+   ret = vfio_lock_acct(1, _cap);
+   i = 1;
+   goto unpin_out;
}
 
/* Lock all the consecutive pages from pfn_base */
for (i = 1, vaddr += PAGE_SIZE; i < npage; i++, vaddr += PAGE_SIZE) {
-   unsigned long pfn = 0;
-
ret = 

[PATCH 3.16 041/134] serial: omap: fix runtime-pm handling on unbind

[Ben Hutchings]

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

--

From: Johan Hovold 

commit 099bd73dc17ed77aa8c98323e043613b6e8f54fc upstream.

An unbalanced and misplaced synchronous put was used to suspend the
device on driver unbind, something which with a likewise misplaced
pm_runtime_disable leads to external aborts when an open port is being
removed.

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010
...
[] (serial_omap_set_mctrl) from [] 
(uart_update_mctrl+0x50/0x60)
[] (uart_update_mctrl) from [] (uart_shutdown+0xbc/0x138)
[] (uart_shutdown) from [] (uart_hangup+0x94/0x190)
[] (uart_hangup) from [] (__tty_hangup+0x404/0x41c)
[] (__tty_hangup) from [] (tty_vhangup+0x1c/0x20)
[] (tty_vhangup) from [] (uart_remove_one_port+0xec/0x260)
[] (uart_remove_one_port) from [] 
(serial_omap_remove+0x40/0x60)
[] (serial_omap_remove) from [] 
(platform_drv_remove+0x34/0x4c)

Fix this up by resuming the device before deregistering the port and by
suspending and disabling runtime pm only after the port has been
removed.

Also make sure to disable autosuspend before disabling runtime pm so
that the usage count is balanced and device actually suspended before
returning.

Note that due to a negative autosuspend delay being set in probe, the
unbalanced put would actually suspend the device on first driver unbind,
while rebinding and again unbinding would result in a negative
power.usage_count.

Fixes: 7e9c8e7dbf3b ("serial: omap: make sure to suspend device before remove")
Cc: Felipe Balbi 
Cc: Santosh Shilimkar 
Signed-off-by: Johan Hovold 
Acked-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/tty/serial/omap-serial.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1754,9 +1754,13 @@ static int serial_omap_remove(struct pla
 {
struct uart_omap_port *up = platform_get_drvdata(dev);
 
+   pm_runtime_get_sync(up->dev);
+
+   uart_remove_one_port(_omap_reg, >port);
+
+   pm_runtime_dont_use_autosuspend(up->dev);
pm_runtime_put_sync(up->dev);
pm_runtime_disable(up->dev);
-   uart_remove_one_port(_omap_reg, >port);
pm_qos_remove_request(>pm_qos_request);
device_init_wakeup(>dev, false);
 

[PATCH 3.16 050/134] iio: dac: ad7303: fix channel description

[Ben Hutchings]

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

--

From: Pavel Roskin 

commit ce420fd4251809b4c3119b3b20c8b13bd8eba150 upstream.

realbits, storagebits and shift should be numbers, not ASCII characters.

Signed-off-by: Pavel Roskin 
Reviewed-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings 
---
 drivers/iio/dac/ad7303.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/iio/dac/ad7303.c
+++ b/drivers/iio/dac/ad7303.c
@@ -184,9 +184,9 @@ static const struct iio_chan_spec_ext_in
.address = (chan),  \
.scan_type = {  \
.sign = 'u',\
-   .realbits = '8',\
-   .storagebits = '8', \
-   .shift = '0',   \
+   .realbits = 8,  \
+   .storagebits = 8,   \
+   .shift = 0, \
},  \
.ext_info = ad7303_ext_info,\
 }

[PATCH v5 7/7] arm64: kvm: handle SEI notification and inject virtual SError

[Dongjiu Geng]

After receive SError, KVM firstly call memory failure to
deal with the Error. If memory failure wants user space to
handle it, it will notify user space. This patch adds support
to userspace that injects virtual SError with specified
syndrome. This syndrome value will be set to the VSESR_EL2.
VSESR_EL2 is a new RAS extensions register which provides the
syndrome value reported to software on taking a virtual SError
interrupt exception.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 
---
 arch/arm/include/asm/kvm_host.h  |  2 ++
 arch/arm/kvm/guest.c |  5 +
 arch/arm64/include/asm/kvm_emulate.h | 10 ++
 arch/arm64/include/asm/kvm_host.h|  2 ++
 arch/arm64/include/asm/sysreg.h  |  3 +++
 arch/arm64/include/asm/system_misc.h |  1 +
 arch/arm64/kvm/guest.c   | 13 +
 arch/arm64/kvm/handle_exit.c | 21 +++--
 arch/arm64/kvm/hyp/switch.c  | 14 ++
 include/uapi/linux/kvm.h |  2 ++
 virt/kvm/arm/arm.c   |  7 +++
 11 files changed, 78 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 127e2dd2e21c..bdb6ea690257 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -244,6 +244,8 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const 
struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int exception_index);
 
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
+
 static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
   unsigned long hyp_stack_ptr,
   unsigned long vector_ptr)
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 1e0784ebbfd6..c23df72d9bec 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome)
+{
+   return 0;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index 47983db27de2..74213bd539dc 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -155,6 +155,16 @@ static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu 
*vcpu)
return vcpu->arch.fault.esr_el2;
 }
 
+static inline u32 kvm_vcpu_get_vsesr(const struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.fault.vsesr_el2;
+}
+
+static inline void kvm_vcpu_set_vsesr(struct kvm_vcpu *vcpu, unsigned long val)
+{
+   vcpu->arch.fault.vsesr_el2 = val;
+}
+
 static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
 {
u32 esr = kvm_vcpu_get_hsr(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index d68630007b14..57b011261597 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -88,6 +88,7 @@ struct kvm_vcpu_fault_info {
u32 esr_el2;/* Hyp Syndrom Register */
u64 far_el2;/* Hyp Fault Address Register */
u64 hpfar_el2;  /* Hyp IPA Fault Address Register */
+   u32 vsesr_el2;  /* Virtual SError Exception Syndrome Register */
 };
 
 /*
@@ -381,6 +382,7 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
   struct kvm_device_attr *attr);
 int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
   struct kvm_device_attr *attr);
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
 
 static inline void __cpu_init_stage2(void)
 {
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 35b786b43ee4..06059eef0f5d 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -86,6 +86,9 @@
 #define REG_PSTATE_PAN_IMM sys_reg(0, 0, 4, 0, 4)
 #define REG_PSTATE_UAO_IMM sys_reg(0, 0, 4, 0, 3)
 
+/* virtual SError exception syndrome register in armv8.2 */
+#define REG_VSESR_EL2  sys_reg(3, 4, 5, 2, 3)
+
 #define SET_PSTATE_PAN(x) __emit_inst(0xd500 | REG_PSTATE_PAN_IMM |
\
  (!!x)<<8 | 0x1f)
 #define SET_PSTATE_UAO(x) __emit_inst(0xd500 | REG_PSTATE_UAO_IMM |
\
diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 07aa8e3c5630..7d07aeb02bc4 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, 
const char *cmd);
 })
 
 int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(phys_addr_t addr, unsigned int esr);
 
 

[GIT PULL] apparmor updates for next

[John Johansen]

Hi James,

Please pull these apparmor changes for next.

Thanks!

-Kees

The following changes since commit 706224ae390ddbf1871abb7938245be45bf04104:

  samples: Unrename SECCOMP_RET_KILL (2017-08-17 14:17:07 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor for-security

for you to fetch changes up to 76e22e212a850bbd16cf49f9c586d4635507e0b5:

  apparmor: fix incorrect type assignment when freeing proxies (2017-08-18 
06:45:37 -0700)


Christos Gkekas (1):
  apparmor: Fix logical error in verify_header()

Dan Carpenter (1):
  apparmor: Fix an error code in aafs_create()

Geert Uytterhoeven (1):
  apparmor: Fix shadowed local variable in unpack_trans_table()

John Johansen (12):
  apparmor: Redundant condition: prev_ns. in [label.c:1498]
  apparmor: add the ability to mediate signals
  apparmor: add mount mediation
  apparmor: cleanup conditional check for label in label_print
  apparmor: add support for absolute root view based labels
  apparmor: make policy_unpack able to audit different info messages
  apparmor: add more debug asserts to apparmorfs
  apparmor: add base infastructure for socket mediation
  apparmor: move new_null_profile to after profile lookup fns()
  apparmor: fix race condition in null profile creation
  apparmor: ensure unconfined profiles have dfas initialized
  apparmor: fix incorrect type assignment when freeing proxies

 security/apparmor/.gitignore  |   1 +
 security/apparmor/Makefile|  43 ++-
 security/apparmor/apparmorfs.c|  37 +-
 security/apparmor/domain.c|   4 +-
 security/apparmor/file.c  |  30 ++
 security/apparmor/include/apparmor.h  |   2 +
 security/apparmor/include/audit.h |  39 +-
 security/apparmor/include/domain.h|   5 +
 security/apparmor/include/ipc.h   |   6 +
 security/apparmor/include/label.h |   1 +
 security/apparmor/include/mount.h |  54 +++
 security/apparmor/include/net.h   | 114 ++
 security/apparmor/include/perms.h |   5 +-
 security/apparmor/include/policy.h|  13 +
 security/apparmor/include/sig_names.h |  95 +
 security/apparmor/ipc.c   |  99 +
 security/apparmor/label.c |  36 +-
 security/apparmor/lib.c   |   5 +-
 security/apparmor/lsm.c   | 472 +++
 security/apparmor/mount.c | 696 ++
 security/apparmor/net.c   | 184 +
 security/apparmor/policy.c| 166 
 security/apparmor/policy_ns.c |   2 +
 security/apparmor/policy_unpack.c | 105 -
 24 files changed, 2081 insertions(+), 133 deletions(-)
 create mode 100644 security/apparmor/include/mount.h
 create mode 100644 security/apparmor/include/net.h
 create mode 100644 security/apparmor/include/sig_names.h
 create mode 100644 security/apparmor/mount.c
 create mode 100644 security/apparmor/net.c