commit 7b3775017f4e6b87dfd2c7f63d1eaf057948f31d
Author: Greg Kroah-Hartman
Date: Wed Dec 20 10:10:38 2017 +0100
Linux 4.14.8
commit bed6119aa21b28f096880342f9e2445f9ad47b25
Author: Bin Liu
Date: Tue Dec 5 08:45:30 2017 -0600
usb: musb: da8xx: fix babble condition handling
commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Signed-off-by: Bin Liu
Signed-off-by: Greg Kroah-Hartman
commit d094690cbed906ca96752cb94abed50fbf1cfaa3
Author: Brian Norris
Date: Thu Oct 19 11:45:19 2017 -0700
ath10k: fix build errors with !CONFIG_PM
[ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ]
Build errors have been reported with CONFIG_PM=n:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_resume'
[-Werror=implicit-function-declaration]
These are caused by the combination of the following two commits:
6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
disabled")
Both build fine on their own.
But now that ath10k_pci_pm_{suspend,resume}() is compiled
unconditionally, we should also compile ath10k_pci_{suspend,resume}()
unconditionally.
And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they
are trivial (empty), so we're not saving much space by compiling them
out. And the alternatives would be to sprinkle more __maybe_unused, or
spread the #ifdef's further.
Build tested with the following combinations:
CONFIG_PM=y && CONFIG_PM_SLEEP=y
CONFIG_PM=y && CONFIG_PM_SLEEP=n
CONFIG_PM=n
Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled")
Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'")
Signed-off-by: Brian Norris
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 5c212b59ded7fc9382e1c55c100f82709cf542ca
Author: Brian Norris
Date: Wed Oct 4 12:22:55 2017 +0300
ath10k: fix core PCI suspend when WoWLAN is supported but disabled
[ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ]
For devices where the FW supports WoWLAN but user-space has not
configured it, we don't do any PCI-specific suspend/resume operations,
because mac80211 doesn't call drv_suspend() when !wowlan. This has
particularly bad effects for some platforms, because we don't stop the
power-save timer, and if this timer goes off after the PCI controller
has suspended the link, Bad Things will happen.
Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
got some of this right, in that it understood there was a problem on
non-WoWLAN firmware. But it forgot the $subject case.
Fix this by moving all the PCI driver suspend/resume logic exclusively
into the driver PM hooks. This shouldn't affect WoWLAN support much
(this just gets executed later on).
I would just as well kill the entirety of ath10k_hif_suspend(), as it's
not even implemented on the USB or SDIO drivers. I expect that we don't
need the callback, except to return "supported" (i.e., 0) or "not
supported" (i.e., -EOPNOTSUPP).
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
Signed-off-by: Brian Norris
Cc: Ryan Hsu
Cc: Kalle Valo
Cc: Michal Kazior
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit e37eb54a000c767e7f39b806fb048c4be75ed786
Author: Miaoqing Pan
Date: Wed Sep 27 09:13:34 2017 +0800
ath9k: fix tx99 potential info leak
[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]
When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.
Signed-off-by: Miaoqing Pan
Reviewed-by: Christoph Böhmwalder
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 99ab42f783da58540c80c91a2af8e8c764c46ca8
Author: Rakesh Pandit
Date: Fri Oct 13 14:45:56 2017 +0200
lightnvm: pblk: protect line bitmap while submitting meta io
[ Upstream commit e57903fd972a398b7140d0bc055714e13a0e58c5 ]
It seems pblk_dealloc_page would race against pblk_alloc_pages for
line bitmap for sector allocation.The chances are very low but might
as well protect the bitmap properly.
Signed-off-by: Rakesh Pandit
Reviewed-by: Javier González
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 136e415e7a6a7d3d8666560b2147145c7636a455
Author: Javier González
Date: Fri Oct 13 14:46:06 2017 +0200
lightnvm: pblk: fix min size for page mempool
[ Upstream commit bd432417681a224d9fa4a9d43be7d4edc82135b2 ]
pblk uses an internal page mempool for allocating pages on internal
bios. The main two users of this memory pool are partial reads (reads
with some sectors in cache and some on media) and padded writes, which
need to add dummy pages to an existing bio already containing valid
data (and with a large enough bioset allocated). In both cases, the
maximum number of pages per bio is defined by the maximum number of
physical sectors supported by the underlying device.
This patch fixes a bad mempool allocation, where the min_nr of elements
on the pool was fixed (to 16), which is lower than the maximum number
of sectors supported by NVMe (as of the time for this patch). Instead,
use the maximum number of allowed sectors reported by the device.
Reported-by: Jens Axboe
Signed-off-by: Javier González
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 83ef2175ba013ab5ec9b1ec50944ba60a6af888d
Author: Javier González
Date: Fri Oct 13 14:46:01 2017 +0200
lightnvm: pblk: initialize debug stat counter
[ Upstream commit a1121176ff757e3c073490a69608ea0b18a00ec1 ]
Initialize the stat counter for garbage collected reads.
Fixes: a4bd217b43268 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Javier González
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 8594a9a79c390fc99c8d8af21b3208396c94b231
Author: Javier González
Date: Fri Oct 13 14:46:02 2017 +0200
lightnvm: pblk: use right flag for GC allocation
[ Upstream commit 7d327a9ed6c4dca341ebf99012e0a6b80a3050e6 ]
The data buffer for the GC path allocates virtual memory through
vmalloc. When this change was introduced, a flag signaling kmalloc'ed
memory was wrongly introduced. Use the right flag when creating a bio
from this buffer.
Fixes: de54e703a422 ("lightnvm: pblk: use vmalloc for GC data buffer")
Signed-off-by: Javier González
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit e22f692fbabafe322db0c3821e02a5d6da350bef
Author: Rakesh Pandit
Date: Fri Oct 13 14:46:28 2017 +0200
lightnvm: pblk: fix changing GC group list for a line
[ Upstream commit 27b978725d895e704aab44b99242a0514485d798 ]
pblk_line_gc_list seems to had a bug since the introduction of pblk in
getting GC list for a line. In b20ba1bc7 while redesigning the GC
algorithm, the naming for the GC thresholds was altered, but the
values for high_thrs and mid_thrs were not. The result is that when
moving to the GC lists, the mid threshold is never evaluated.
Fixes: a4bd217b4("lightnvm: physical block device (pblk) target")
Signed-off-by: Rakesh Pandit
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 1b07f7511a773db3a165b0a2eca35df5ba6dd1d3
Author: Hans Holmberg
Date: Fri Oct 13 14:46:34 2017 +0200
lightnvm: pblk: prevent gc kicks when gc is not operational
[ Upstream commit 3e3a5b8ebd5d3b1d68facc58b0674a2564653222 ]
GC can be kicked after it has been shut down when closing the last
line during exit, resulting in accesses to freed structures.
Make sure that GC is not triggered while it is not operational.
Also make sure that GC won't be re-activated during exit when
running on another processor by using timer_del_sync.
Signed-off-by: Hans Holmberg
Signed-off-by: Matias Bjørling
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit e6a9d261e95f5ba5cda38ca9c6b7e580656032c4
Author: Matteo Croce
Date: Thu Oct 12 16:12:37 2017 +0200
icmp: don't fail on fragment reassembly time exceeded
[ Upstream commit 258bbb1b0e594ad5f5652cb526b3c63e6a7fad3d ]
The ICMP implementation currently replies to an ICMP time exceeded message
(type 11) with an ICMP host unreachable message (type 3, code 1).
However, time exceeded messages can either represent "time to live exceeded
in transit" (code 0) or "fragment reassembly time exceeded" (code 1).
Unconditionally replying to "fragment reassembly time exceeded" with
host unreachable messages might cause unjustified connection resets
which are now easily triggered as UFO has been removed, because, in turn,
sending large buffers triggers IP fragmentation.
The issue can be easily reproduced by running a lot of UDP streams
which is likely to trigger IP fragmentation:
# start netserver in the test namespace
ip netns add test
ip netns exec test netserver
# create a VETH pair
ip link add name veth0 type veth peer name veth0 netns test
ip link set veth0 up
ip -n test link set veth0 up
for i in $(seq 20 29); do
# assign addresses to both ends
ip addr add dev veth0 192.168.$i.1/24
ip -n test addr add dev veth0 192.168.$i.2/24
# start the traffic
netperf -L 192.168.$i.1 -H 192.168.$i.2 -t UDP_STREAM -l 0 &
done
# wait
send_data: data send error: No route to host (errno 113)
netperf: send_omni: send_data failed: No route to host
We need to differentiate instead: if fragment reassembly time exceeded
is reported, we need to silently drop the packet,
if time to live exceeded is reported, maintain the current behaviour.
In both cases increment the related error count "icmpInTimeExcds".
While at it, fix a typo in a comment, and convert the if statement
into a switch to mate it more readable.
Signed-off-by: Matteo Croce
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 023bff1b335860493dce3769c942b0172ea0fb5a
Author: Alex Vesker
Date: Tue Oct 10 10:36:41 2017 +0300
IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
[ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ]
When ndo_open and ndo_stop are called RTNL lock should be held.
In this specific case ipoib_ib_dev_open calls the offloaded ndo_open
which re-sets the number of TX queue assuming RTNL lock is held.
Since RTNL lock is not held, RTNL assert will fail.
Signed-off-by: Alex Vesker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 02ef1dd301c2f1ca0ffe58f75bf2f0f4bd291270
Author: Bart Van Assche
Date: Wed Oct 11 10:48:45 2017 -0700
RDMA/cma: Avoid triggering undefined behavior
[ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ]
According to the C standard the behavior of computations with
integer operands is as follows:
* A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.
* The behavior for signed integer underflow and overflow is
undefined.
Hence only use unsigned integers when checking for integer
overflow.
This patch is what I came up with after having analyzed the
following smatch warnings:
drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
Signed-off-by: Bart Van Assche
Acked-by: Sean Hefty
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 9fc290e529b4948b2b18fa943d8bd5c3a5d5b6e1
Author: Bart Van Assche
Date: Wed Oct 11 10:48:43 2017 -0700
IB/core: Fix endianness annotation in rdma_is_multicast_addr()
[ Upstream commit 1c3aea2bc8f0b2e5b57375ead40457ff75a3a2ec ]
Since ipv4_addr is a big endian 32-bit number, annotate it as such.
Fixes: commit be1d325a3358 ("IB/core: Set RoCEv2 MGID according to spec")
Signed-off-by: Bart Van Assche
Reviewed-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit f7af60377ec05e2452a73c349b4fa2a4196480c8
Author: Alexander Duyck
Date: Fri Oct 13 13:40:24 2017 -0700
macvlan: Only deliver one copy of the frame to the macvlan interface
[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.
Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit d9490e7ca55bafac97fa65a3d34244386469eb50
Author: Jan Kara
Date: Mon Oct 16 11:38:11 2017 +0200
udf: Avoid overflow when session starts at large offset
[ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ]
When session starts beyond offset 2^31 the arithmetics in
udf_check_vsd() would overflow. Make sure the computation is done in
large enough type.
Reported-by: Cezary Sliwa
Signed-off-by: Jan Kara
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 42364042b7dd4ba7fed36c1db0a157c7c48282ca
Author: Chuck Lever
Date: Mon Oct 9 12:03:26 2017 -0400
xprtrdma: Don't defer fencing an async RPC's chunks
[ Upstream commit 8f66b1a529047a972cb9602a919c53a95f3d7a2b ]
In current kernels, waiting in xprt_release appears to be safe to
do. I had erroneously believed that for ASYNC RPCs, waiting of any
kind in xprt_release->xprt_rdma_free would result in deadlock. I've
done injection testing and consulted with Trond to confirm that
waiting in the RPC release path is safe.
For the very few times where RPC resources haven't yet been released
earlier by the reply handler, it is safe to wait synchronously in
xprt_rdma_free for invalidation rather than defering it to MR
recovery.
Note: When the QP is error state, posting a LocalInvalidate should
flush and mark the MR as bad. There is no way the remote HCA can
access that MR via a QP in error state, so it is effectively already
inaccessible and thus safe for the Upper Layer to access. The next
time the MR is used it should be recognized and cleaned up properly
by frwr_op_map.
Signed-off-by: Chuck Lever
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 46788d19e137fc48d93f0a29eade2e02e05317f6
Author: Guoqing Jiang
Date: Fri Sep 29 09:16:43 2017 +0800
md-cluster: fix wrong condition check in raid1_write_request
[ Upstream commit 385f4d7f946b08f36f68b0a28e95a319925b6b62 ]
The check used here is to avoid conflict between write and
resync, however we used the wrong logic, it should be the
inverse of the checking inside "if".
Fixes: 589a1c4 ("Suspend writes in RAID1 if within range")
Signed-off-by: Guoqing Jiang
Signed-off-by: Shaohua Li
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 339aba679813ff1fabde362147919d3f6e536568
Author: Artur Paszkiewicz
Date: Fri Sep 29 22:54:19 2017 +0200
raid5-ppl: check recovery_offset when performing ppl recovery
[ Upstream commit 07719ff767dcd8cc42050f185d332052f3816546 ]
If starting an array that is undergoing rebuild, make ppl recovery honor
the recovery_offset of a member disk and don't read data that is not yet
in-sync.
Signed-off-by: Artur Paszkiewicz
Signed-off-by: Shaohua Li
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit b197f67ccfeb86d180a152796b5e3b7de1f611ef
Author: Dan Carpenter
Date: Wed Oct 4 10:50:37 2017 +0300
scsi: bfa: integer overflow in debugfs
[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]
We could allocate less memory than intended because we do:
bfad->regdata = kzalloc(len << 2, GFP_KERNEL);
The shift can overflow leading to a crash. This is debugfs code so the
impact is very small. I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").
Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit dd2581c675e4311abc68826c25ec2563bccb3337
Author: weiping zhang
Date: Thu Oct 12 14:56:44 2017 +0800
scsi: sd: change allow_restart to bool in sysfs interface
[ Upstream commit 658e9a6dc1126f21fa417cd213e1cdbff8be0ba2 ]
/sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0
unexpectedly by writing an invalid string such as the following:
echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart
Signed-off-by: weiping zhang
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 47b5dbdd983e0319cd5d135bbfe7e564f4bbaabc
Author: weiping zhang
Date: Thu Oct 12 14:57:06 2017 +0800
scsi: sd: change manage_start_stop to bool in sysfs interface
[ Upstream commit 623401ee33e42cee64d333877892be8db02951eb ]
/sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0
unexpectly by writing an invalid string.
Signed-off-by: weiping zhang
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit fc8f4ca137d9525b6f7db4b1d3e8f07a087518ec
Author: Wei Yongjun
Date: Tue Oct 17 12:11:46 2017 +0000
nullb: fix error return code in null_init()
[ Upstream commit 30c516d750396c5f3ec9cb04c9e025c25e91495e ]
Fix to return error code -ENOMEM from the null_alloc_dev() error
handling case instead of 0, as done elsewhere in this function.
Fixes: 2984c8684f96 ("nullb: factor disk parameters")
Signed-off-by: Wei Yongjun
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit c97e41076a298dbc4e910c33048e553658388eed
Author: Colin Ian King
Date: Tue Oct 17 16:54:52 2017 +0100
ipmi_si: fix memory leak on new_smi
[ Upstream commit c0a32fe13cd323ca9420500b16fd69589c9ba91e ]
The error exit path omits kfree'ing the allocated new_smi, causing a memory
leak. Fix this by kfree'ing new_smi.
Detected by CoverityScan, CID#14582571 ("Resource Leak")
Fixes: 7e030d6dff71 ("ipmi: Prefer ACPI system interfaces over SMBIOS ones")
Signed-off-by: Colin Ian King
Signed-off-by: Corey Minyard
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit f2d81d0f030afc7a873bb3454eaf59f384543baf
Author: Jia-Ju Bai
Date: Sun Oct 8 19:54:07 2017 +0800
rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd
[ Upstream commit 08880f8e08cbd814e870e9d3ab9530abc1bce226 ]
The driver may sleep under a spinlock, and the function call path is:
rtw_set_802_11_bssid(acquire the spinlock)
rtw_disassoc_cmd
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
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
Signed-off-by: Greg Kroah-Hartman
commit f898f36664a5d64a55c1257e55dfacaae6a86bb7
Author: Jia-Ju Bai
Date: Sun Oct 8 19:54:45 2017 +0800
rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd
[ Upstream commit 2bf9806d4228f7a6195f8e03eda0479d2a93b411 ]
The driver may sleep under a spinlock, and the function call path is:
rtw_surveydone_event_callback(acquire the spinlock)
rtw_createbss_cmd
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
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
Signed-off-by: Greg Kroah-Hartman
commit f18b2039d904f344dae779451592814e2c646686
Author: Don Hiatt
Date: Mon Oct 9 12:38:12 2017 -0700
IB/hfi1: Mask out A bit from psn trace
[ Upstream commit d0a2f454713a42447ee4007582c0e43c47bcf230 ]
The trace logic prior to the fixes below used to mask the
A bit from the psn. It now mistakenly displays the A bit,
which is already displayed separately.
Fix by adding the appropriate mask to the psn tracing.
Fixes: 228d2af1b723 ("IB/hfi1: Separate input/output header tracing")
Fixes: 863cf89d472f ("IB/hfi1: Add 16B trace support")
Reviewed-by: Mike Marciniszyn
Signed-off-by: Don Hiatt
Signed-off-by: Dennis Dalessandro
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 4e2836b43102633dc9bffbc170be43e1d147914c
Author: Jia-Ju Bai
Date: Mon Oct 9 16:45:55 2017 +0800
vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend
[ 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
Signed-off-by: Greg Kroah-Hartman
commit b57259ca055f7f2c7237dcc0e5aac446b2fa6da9
Author: Parav Pandit
Date: Mon Oct 16 08:45:16 2017 +0300
IB/core: Fix calculation of maximum RoCE MTU
[ Upstream commit 99260132fde7bddc6e0132ce53da94d1c9ccabcb ]
The original code only took into consideration the largest header
possible after the IB_BTH_BYTES. This was incorrect, as the largest
possible header size is the largest possible combination of headers we
might run into. The new code accounts for all possible headers in the
largest possible combination and subtracts that from the MTU to make
sure that all packets will fit on the wire.
Link: https://www.spinics.net/lists/linux-rdma/msg54558.html
Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices")
Signed-off-by: Parav Pandit
Reviewed-by: Daniel Jurgens
Reported-by: Roland Dreier
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 9cb27c88b080274e5f94ae7a7c4da7275925ab33
Author: Parav Pandit
Date: Mon Oct 16 08:45:15 2017 +0300
IB/core: Fix use workqueue without WQ_MEM_RECLAIM
[ Upstream commit 39baf10310e6669564a485b55267fae70a4e44ae ]
The IB/core provides address resolution service and invokes callback
handler when address resolve request completes of requester in worker
thread context.
Such caller might allocate or free memory in callback handler
depending on the completion status to make further progress or to
terminate a connection. Most ULPs resolve route which involves
allocating route entry and path record elements in callback event handler.
It has been noticed that WQ_MEM_RECLAIM flag should not be used for
workers that tend to allocate memory in this [1] thread discussion.
In order to mitigate this situation, WQ_MEM_RECLAIM flag was dropped for
other such WQs in this [2] patch.
Similar problem might arise with address resolution path, though its not
yet noticed. The ib_addr workqueue is not memory reclaim path due to its
nature of invoking callback that might allocate memory or don't free any
memory under memory pressure.
[1] https://www.spinics.net/lists/linux-rdma/msg53239.html
[2] https://www.spinics.net/lists/linux-rdma/msg53416.html
Fixes: f54816261c2b ("IB/addr: Remove deprecated create_singlethread_workqueue")
Fixes: 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
Signed-off-by: Parav Pandit
Reviewed-by: Daniel Jurgens
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 84607a2958762c94741fc96e947e6a134cd5f5c3
Author: Kurt Garloff
Date: Tue Oct 17 09:10:45 2017 +0200
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]
All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.
Signed-off-by: Kurt Garloff
Signed-off-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 8151940acc356ba61e0992f464fca38118860c31
Author: NeilBrown
Date: Tue Oct 17 16:18:36 2017 +1100
raid5: Set R5_Expanded on parity devices as well as data.
[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]
When reshaping a fully degraded raid5/raid6 to a larger
nubmer of devices, the new device(s) are not in-sync
and so that can make the newly grown stripe appear to be
"failed".
To avoid this, we set the R5_Expanded flag to say "Even though
this device is not fully in-sync, this block is safe so
don't treat the device as failed for this stripe".
This flag is set for data devices, not not for parity devices.
Consequently, if you have a RAID6 with two devices that are partly
recovered and a spare, and start a reshape to include the spare,
then when the reshape gets past the point where the recovery was
up to, it will think the stripes are failed and will get into
an infinite loop, failing to make progress.
So when contructing parity on an EXPAND_READY stripe,
set R5_Expanded.
Reported-by: Curt
Signed-off-by: NeilBrown
Signed-off-by: Shaohua Li
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 57db94d4b72479c6c1e31d18e83a581d5d6d0ee9
Author: Linus Walleij
Date: Wed Oct 11 11:57:15 2017 +0200
pinctrl: adi2: Fix Kconfig build problem
[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]
The build robot is complaining on Blackfin:
drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
pointer to incomplete type 'struct gpio_port_t'
writew(readw(®s->port_fer) & ~BIT(offset),
^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
if (readl(®s->invert_set) & pintbit)
^~
It seems the driver need to include and
to compile.
The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.
Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.
Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.
This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.
Cc: Steven Miao
Cc: Huanhuan Feng
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 4684da79d20edf232e33442775506e600fc4fe6f
Author: Ross Zwisler
Date: Wed Oct 18 12:21:55 2017 -0600
dev/dax: fix uninitialized variable build warning
[ Upstream commit 0a3ff78699d1817e711441715d22665475466036 ]
Fix this build warning:
warning: 'phys' may be used uninitialized in this function
[-Wuninitialized]
As reported here:
https://lkml.org/lkml/2017/10/16/152
http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/
Signed-off-by: Ross Zwisler
Signed-off-by: Dan Williams
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 93fc8284472124140a7946c4e5f555e06808f4a2
Author: nixiaoming
Date: Fri Sep 15 17:45:56 2017 +0800
tty fix oops when rmmod 8250
[ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ]
After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver
Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,
Use name in proc_dir_entry instead of driver->driver_name to fix oops
test on linux 4.1.12:
BUG: unable to handle kernel paging request at ffffffffa01979de
IP: [] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ... ... [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
Workqueue: events release_one_tty
task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
RIP: 0010:[] [] strchr+0x0/0x30
RSP: 0018:ffff880852887c90 EFLAGS: 00010282
RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
Stack:
ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
Call Trace:
[] ? __xlate_proc_name+0x71/0xd0
[] remove_proc_entry+0x40/0x180
[] ? _raw_spin_lock_irqsave+0x41/0x60
[] ? destruct_tty_driver+0x60/0xe0
[] proc_tty_unregister_driver+0x28/0x40
[] destruct_tty_driver+0x88/0xe0
[] tty_driver_kref_put+0x1d/0x20
[] release_one_tty+0x5a/0xd0
[] process_one_work+0x139/0x420
[] worker_thread+0x121/0x450
[] ? process_scheduled_works+0x40/0x40
[] kthread+0xec/0x110
[] ? tg_rt_schedulable+0x210/0x220
[] ? kthread_freezable_should_stop+0x80/0x80
[] ret_from_fork+0x42/0x70
[] ? kthread_freezable_should_stop+0x80/0x80
Signed-off-by: nixiaoming
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit b53af57679492180417d584be410b1134de15cd2
Author: Wanpeng Li
Date: Thu Oct 19 07:00:34 2017 +0800
KVM: nVMX: Fix EPT switching advertising
[ Upstream commit 575b3a2cb439b03fd603ea77c73c76f3ed237596 ]
I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not
exposed to L1.
EPT switching is advertised unconditionally since it is emulated, however,
it can be treated as an extended feature for EPT and it should not be
advertised if EPT itself is not exposed. This patch fixes it.
Reviewed-by: David Hildenbrand
Cc: Paolo Bonzini
Cc: Radim KrÄmář
Cc: Jim Mattson
Signed-off-by: Wanpeng Li
Signed-off-by: Radim KrÄmář
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit fdfcb06c5944afb78007cfc25e527ff689b2a344
Author: Eric Dumazet
Date: Wed Oct 18 17:02:03 2017 -0700
ipv4: ipv4_default_advmss() should use route mtu
[ Upstream commit 164a5e7ad531e181334a3d3f03d0d5ad20d6faea ]
ipv4_default_advmss() incorrectly uses the device MTU instead
of the route provided one. IPv6 has the proper behavior,
lets harmonize the two protocols.
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 48185ffb6dc3eb64846039117d76148d3e3d7022
Author: Matthias Brugger
Date: Sat Oct 21 10:17:47 2017 +0200
soc: mediatek: pwrap: fix compiler errors
[ Upstream commit fb2c1934f30577756e55e24e8870b45c78da3bc2 ]
When compiling using sparse, we got the following error:
drivers/soc/mediatek/mtk-pmic-wrap.c:686:25: error: dubious one-bit signed bitfield
Changing the data type to unsigned fixes this.
Signed-off-by: Matthias Brugger
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 9cd01922985ce5c00cf050f12daef304cc452761
Author: Breno Leitao
Date: Tue Oct 17 16:20:18 2017 -0200
powerpc/xmon: Check before calling xive functions
[ Upstream commit 402e172a2ce76210f2fe921cf419d12103851344 ]
Currently xmon could call XIVE functions from OPAL even if the XIVE is
disabled or does not exist in the system, as in POWER8 machines. This
causes the following exception:
1:mon> dx
cpu 0x1: Vector: 700 (Program Check) at [c000000423c93450]
pc: c00000000009cfa4: opal_xive_dump+0x50/0x68
lr: c0000000000997b8: opal_return+0x0/0x50
This patch simply checks if XIVE is enabled before calling XIVE
functions.
Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller")
Suggested-by: Guilherme G. Piccoli
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit 8ee1eada4f1a6671517dc51f6bc11174faebea02
Author: Michael Ellerman
Date: Mon Oct 9 21:52:44 2017 +1100
powerpc/perf/hv-24x7: Fix incorrect comparison in memord
[ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ]
In the hv-24x7 code there is a function memord() which tries to
implement a sort function return -1, 0, 1. However one of the
conditions is incorrect, such that it can never be true, because we
will have already returned.
I don't believe there is a bug in practice though, because the
comparisons are an optimisation prior to calling memcmp().
Fix it by swapping the second comparision, so it can be true.
Reported-by: David Binderman
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
commit b59dc14b0b102d42d6bd54ae77848ddc00a4596c
Author: Johan Hovold
Date: Mon Oct 16 15:06:19 2017 +0200
serdev: ttyport: enforce tty-driver open() requirement
[ Upstream commit dee7d0f3b200c67c6ee96bd37c6e8fa52690ab56 ]
The tty-driver open routine is mandatory, but the serdev
tty-port-controller implementation did not treat it as such and would
instead fall back to calling tty_port_open() directly.
Signed-off-by: Johan Hovold
Acked-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin