linux-stable.git/drivers/staging, branch linux-4.1.y

staging: wlan-ng: prism2mgmt.c: fixed a double endian conversion before calling hfa384x_drvr_setconfig16, also fixes relative sparse warning

2018-05-23T01:36:24+00:00

[ Upstream commit dea20579a69ab68cdca6adf79bb7c0c162eb9b72 ]

staging: wlan-ng: prism2mgmt.c: This patches fixes a double endian conversion.
cpu_to_le16() was called twice first in prism2mgmt_scan and again inside
hfa384x_drvr_setconfig16() for the same variable, hence it was swapped
twice. Incidentally, it also fixed the following sparse warning:

drivers/staging/wlan-ng/prism2mgmt.c:173:30: warning: incorrect type in assignment (different base types)
drivers/staging/wlan-ng/prism2mgmt.c:173:30:    expected unsigned short [unsigned] [usertype] word
drivers/staging/wlan-ng/prism2mgmt.c:173:30:    got restricted __le16 [usertype] 

Unfortunately, only compile tested.

Signed-off-by: Andrea della Porta 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: speakup: Replace BUG_ON() with WARN_ON().

2018-05-23T01:33:42+00:00

[ Upstream commit d351c2db5420bb17dcd2d9aac7ddb5f64c6d04b3 ]

BUG_ON() is replaced with WARN_ON() and EINVAL is returned, when
WARN_ON() is true. This fixes the following checkpatch issue:

Avoid crashing the kernel - try using WARN_ON & recovery code rather
than BUG() or BUG_ON().

Signed-off-by: Varsha Rao 
Reviewed-by: Samuel Thibault 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: android: ashmem: Fix lockdep issue during llseek

2018-03-21T03:49:53+00:00

[ Upstream commit cb57469c9573f6018cd1302953dd45d6e05aba7b ]

ashmem_mutex create a chain of dependencies like so:

(1)
mmap syscall ->
  mmap_sem ->  (acquired)
  ashmem_mmap
  ashmem_mutex (try to acquire)
  (block)

(2)
llseek syscall ->
  ashmem_llseek ->
  ashmem_mutex ->  (acquired)
  inode_lock ->
  inode->i_rwsem (try to acquire)
  (block)

(3)
getdents ->
  iterate_dir ->
  inode_lock ->
  inode->i_rwsem   (acquired)
  copy_to_user ->
  mmap_sem         (try to acquire)

There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.

[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48

Acked-by: Todd Kjos 
Cc: Arve Hjonnevag 
Cc: stable@vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes 
Acked-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: ste_rmi4: avoid unused function warnings

2018-03-04T15:28:29+00:00

[ Upstream commit 9045a4a7e686a6316129d6d0b21b4fe2520968e4 ]

The rmi4 touchscreen driver encloses the power-management
functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
functions are only really used when CONFIG_PM_SLEEP is also
set, as a frequent gcc warning shows:

ste_rmi4/synaptics_i2c_rmi4.c:1050:12: warning: 'synaptics_rmi4_suspend' defined but not used
ste_rmi4/synaptics_i2c_rmi4.c:1084:12: warning: 'synaptics_rmi4_resume' defined but not used

This changes the driver to remove the #ifdef and instead mark
the functions as __maybe_unused, which is a nicer anyway, as it
provides build testing for all the code in all configurations
and is harder to get wrong.

Signed-off-by: Arnd Bergmann 
Acked-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

2018-03-01T03:09:47+00:00

[ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ]

When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.

Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.

This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.

Signed-off-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl

2018-03-01T03:09:36+00:00

[ Upstream commit 443064cb0b1fb4569fe0a71209da7625129fb760 ]

A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a
race condition when mmap is called. After the !asma->file check, before
setting asma->size, asma->file can be set in mmap. That would result in
having different asma->size than the mapped memory size. Combined with
ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory
corruption.

Signed-off-by: Viktor Slavkovic 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend

2018-01-17T17:55:40+00:00

[ Upstream commit 42c8eb3f6e15367981b274cb79ee4657e2c6949d ]

The driver may sleep under a spinlock, and the function call path is:
vt6655_suspend (acquire the spinlock)
  pci_set_power_state
    __pci_start_power_transition (drivers/pci/pci.c)
      msleep --> may sleep

To fix it, pci_set_power_state is called without having a spinlock.

This bug is found by my static analysis tool and my code review.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers

2018-01-17T17:55:20+00:00

[ Upstream commit 0911d0041c22922228ca52a977d7b0b0159fee4b ]

Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return
code (GFS2 or Lustre can definitely do this).  However VM_FAULT_RETRY
from ->page_mkwrite is completely unhandled by the mm code and results
in locking and writeably mapping the page which definitely is not what
the caller wanted.

Fix Lustre and block_page_mkwrite_ret() used by other filesystems
(notably GFS2) to return VM_FAULT_NOPAGE instead which results in
bailing out from the fault code, the CPU then retries the access, and we
fault again effectively doing what the handler wanted.

Link: http://lkml.kernel.org/r/20170203150729.15863-1-jack@suse.cz
Signed-off-by: Jan Kara 
Reported-by: Al Viro 
Reviewed-by: Jinshan Xiong 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

staging: iio: cdc: fix improper return value

2017-12-08T23:01:10+00:00

[ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ]

At the end of function ad7150_write_event_config(), directly returns 0.
As a result, the errors will be ignored by the callers. It may be better
to return variable "ret".

Signed-off-by: Pan Bian 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

staging: rtl8188eu: fix incorrect ERROR tags from logs

2017-12-07T02:20:11+00:00

[ Upstream commit 401579c22ccbcb54244494069973e64b1fe980d2 ]

Several lifecycle events in the rtl8188eu driver are logged using the
DBG_88E_LEVEL macro from rtw_debug.h, which is tagged as ERROR
regardless of the actual level.  Below are dmesg excerpts after loading
and unloading the module, the messages are misleading as there was no
error.

    [517434.916239] usbcore: registered new interface driver r8188eu
    [517435.680653] R8188EU: ERROR indicate disassoc
    [517437.122606] R8188EU: ERROR assoc success
    [517797.735611] usbcore: deregistering interface driver r8188eu
    [517797.736069] R8188EU: ERROR indicate disassoc

Remove the ERROR prefix from the logs.  After the patch, logs are:

    [517949.873976] usbcore: registered new interface driver r8188eu
    [517950.592845] R8188EU: indicate disassoc
    [517951.993973] R8188EU: assoc success
    [521778.784448] usbcore: deregistering interface driver r8188eu
    [521778.784838] R8188EU: indicate disassoc

Signed-off-by: Galo Navarro 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin