commit 8433e5c9c8304b750c519ce3e0940dab675f6573
Author: Sasha Levin <alexander.levin@verizon.com>
Date: Wed Jan 18 13:51:20 2017 -0500
Linux 3.18.47
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit f087000a12ced3ee1c320b71cd38de75c56a7e7a
Author: Alexander Duyck <aduyck@mirantis.com>
Date: Tue Mar 29 14:55:22 2016 -0700
gro: Allow tunnel stacking in the case of FOU/GUE
[ Upstream commit c3483384ee511ee2af40b4076366cd82a6a47b86 ]
This patch should fix the issues seen with a recent fix to prevent
tunnel-in-tunnel frames from being generated with GRO. The fix itself is
correct for now as long as we do not add any devices that support
NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the
potential to mess things up due to the fact that the outer transport header
points to the outer UDP header and not the GRE header as would be expected.
Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit dd4fff23f0f4c7c5414f50c091c78a7e423f85da
Author: Jesse Gross <jesse@kernel.org>
Date: Sat Mar 19 09:32:01 2016 -0700
tunnels: Don't apply GRO to multiple layers of encapsulation.
[ Upstream commit fac8e0f579695a3ecbc4d3cac369139d7f819971 ]
When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.
No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.
UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.
Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 218e207ff7797e93d3331a2b1e7ad7ea9dc981d8
Author: Tom Herbert <therbert@google.com>
Date: Tue Feb 10 16:30:30 2015 -0800
net: Use more bit fields in napi_gro_cb
[ Upstream commit baa32ff42871f2d4aca9c08c9403d0e497325564 ]
This patch moves the free and same_flow fields to be bit fields
(2 and 1 bit sized respectively). This frees up some space for u16's.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 59aabf34e937d389561f5a782350cab8acd074dc
Author: Deepa Dinamani <deepa.kernel@gmail.com>
Date: Sat Feb 27 00:32:15 2016 -0800
net: ipv4: Convert IP network timestamps to be y2038 safe
[ Upstream commit 822c868532cae2cc1c51f4f18ab61c194d98aaf6 ]
ICMP timestamp messages and IP source route options require
timestamps to be in milliseconds modulo 24 hours from
midnight UT format.
Add inet_current_timestamp() function to support this. The function
returns the required timestamp in network byte order.
Timestamp calculation is also changed to call ktime_get_real_ts64()
which uses struct timespec64. struct timespec64 is y2038 safe.
Previously it called getnstimeofday() which uses struct timespec.
struct timespec is not y2038 safe.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: James Morris <jmorris@namei.org>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit bd73bf40df53c9dc493a889c3fed89924da071ac
Author: Jesse Gross <jesse@kernel.org>
Date: Sat Mar 19 09:32:00 2016 -0700
ipip: Properly mark ipip GRO packets as encapsulated.
[ Upstream commit b8cba75bdf6a48ea4811bbefb11a94a5c7281b68 ]
ipip encapsulated packets can be merged together by GRO but the result
does not have the proper GSO type set or even marked as being
encapsulated at all. Later retransmission of these packets will likely
fail if the device does not support ipip offloads. This is similar to
the issue resolved in IPv6 sit in feec0cb3
("ipv6: gro: support sit protocol").
Reported-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
Tested-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit a861b9212ab44dc9483259b1f9376e74bae2ad37
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri Dec 16 13:42:06 2016 -0500
sg_write()/bsg_write() is not fit to be called under KERNEL_DS
[ Upstream commit 128394eff343fc6d2f32172f03e24829539c5835 ]
Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those. Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 77e36d730030760bf2aebc4e911b2471fca770eb
Author: Aleksa Sarai <asarai@suse.de>
Date: Wed Dec 21 16:26:24 2016 +1100
fs: exec: apply CLOEXEC before changing dumpable task flags
[ Upstream commit 613cc2b6f272c1a8ad33aefa21cad77af23139f7 ]
If you have a process that has set itself to be non-dumpable, and it
then undergoes exec(2), any CLOEXEC file descriptors it has open are
"exposed" during a race window between the dumpable flags of the process
being reset for exec(2) and CLOEXEC being applied to the file
descriptors. This can be exploited by a process by attempting to access
/proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE.
The race in question is after set_dumpable has been (for get_link,
though the trace is basically the same for readlink):
[vfs]
-> proc_pid_link_inode_operations.get_link
-> proc_pid_get_link
-> proc_fd_access_allowed
-> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
Which will return 0, during the race window and CLOEXEC file descriptors
will still be open during this window because do_close_on_exec has not
been called yet. As a result, the ordering of these calls should be
reversed to avoid this race window.
This is of particular concern to container runtimes, where joining a
PID namespace with file descriptors referring to the host filesystem
can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect
against access of CLOEXEC file descriptors -- file descriptors which may
reference filesystem objects the container shouldn't have access to).
Cc: dev@opencontainers.org
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: Michael Crosby <crosbymichael@gmail.com>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 59e6ec3db8530af00d37344114f2f80b5e9a1914
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Mon Dec 19 18:00:05 2016 +0100
IB/cma: Fix a race condition in iboe_addr_get_sgid()
[ Upstream commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 ]
Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.
Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit c318c81453939e9632535432848013c243fede2e
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Dec 21 11:28:28 2016 +0100
Revert "ALSA: usb-audio: Fix race at stopping the stream"
[ Upstream commit f8114f8583bb18a467c04ddc1e8978330e445801 ]
This reverts commit 16200948d8353fe29a473a394d7d26790deae0e7.
The commit was intended to cover the race condition, but it introduced
yet another regression for devices with the implicit feedback, leading
to a kernel panic due to NULL-dereference in an irq context.
As the race condition that was addressed by the commit is very rare
and the regression is much worse, let's revert the commit for rc1, and
fix the issue properly in a later patch.
Fixes: 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream")
Reported-by: Ioan-Adrian Ratiu <adi@adirat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1eb7f3ea461455c2c019ee8bdd4a72042681aef7
Author: Russell Currey <ruscur@russell.cc>
Date: Thu Dec 15 16:12:41 2016 +1100
drivers/gpu/drm/ast: Fix infinite loop if read fails
[ Upstream commit 298360af3dab45659810fdc51aba0c9f4097e4f6 ]
ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.
Fix this by erroring out if an error is detected. On powerpc systems with
EEH, this leads to the device being fenced and the system continuing to
operate.
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit fcc5da2cf67993e96c9a9b3132775af11c0104ce
Author: Andy Grover <agrover@redhat.com>
Date: Mon Nov 21 16:35:30 2016 -0800
target/user: Fix use-after-free of tcmu_cmds if they are expired
[ Upstream commit d0905ca757bc40bd1ebc261a448a521b064777d7 ]
Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.
Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.
Cc: stable@vger.kernel.org
Reported-by: Bryant G Ly <bgly@us.ibm.com>
Tested-by: Bryant G Ly <bgly@us.ibm.com>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 3386c47bc80bf56dd8b6cdf5a85f5436da54e1aa
Author: Wei Fang <fangwei1@huawei.com>
Date: Tue Dec 13 09:25:21 2016 +0800
scsi: avoid a permanent stop of the scsi device's request queue
[ Upstream commit d2a145252c52792bc59e4767b486b26c430af4bb ]
A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
and unblocked after. The reason is that blocking a device sets both the
SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However,
scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
device to be ignored by scsi_target_unblock() and thus never have its
QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
running but has a stopped queue.
We actually have two places where SDEV_RUNNING is set: once in
scsi_add_lun() which respects the blocked flag and once in
scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely
spurious, simply remove it to fix the problem.
Cc: <stable@vger.kernel.org>
Reported-by: Zengxi Chen <chenzengxi@huawei.com>
Signed-off-by: Wei Fang <fangwei1@huawei.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 8dcd21b372737c2e75d9f60807573067d01c895f
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Mon Nov 21 10:21:41 2016 -0800
IPoIB: Avoid reading an uninitialized member variable
[ Upstream commit 11b642b84e8c43e8597de031678d15c08dd057bc ]
This patch avoids that Coverity reports the following:
Using uninitialized value port_attr.state when calling printk
Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 9cdff4fe5279dc07351ecdd77a89db5ed6bba9af
Author: NeilBrown <neilb@suse.com>
Date: Mon Dec 12 08:21:51 2016 -0700
block_dev: don't test bdev->bd_contains when it is not stable
[ Upstream commit bcc7f5b4bee8e327689a4d994022765855c807ff ]
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_openers == 0
it sets
bdev->bd_contains = bdev;
which is not correct for a partition.
After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
and then ->bd_contains is stable.
When FMODE_EXCL is used, blkdev_get() calls
bd_start_claiming() -> bd_prepare_to_claim() -> bd_may_claim()
This call happens before __blkdev_get() is called, so ->bd_contains
is not stable. So bd_may_claim() cannot safely use ->bd_contains.
It currently tries to use it, and this can lead to a BUG_ON().
This happens when a whole device is already open with a bd_holder (in
use by dm in my particular example) and two threads race to open a
partition of that device for the first time, one opening with O_EXCL and
one without.
The thread that doesn't use O_EXCL gets through blkdev_get() to
__blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev;
Immediately thereafter the other thread, using FMODE_EXCL, calls
bd_start_claiming() from blkdev_get(). This should fail because the
whole device has a holder, but because bdev->bd_contains == bdev
bd_may_claim() incorrectly reports success.
This thread continues and blocks on bd_mutex.
The first thread then sets bdev->bd_contains correctly and drops the mutex.
The thread using FMODE_EXCL then continues and when it calls bd_may_claim()
again in:
BUG_ON(!bd_may_claim(bdev, whole, holder));
The BUG_ON fires.
Fix this by removing the dependency on ->bd_contains in
bd_may_claim(). As bd_may_claim() has direct access to the whole
device, it can simply test if the target bdev is the whole device.
Fixes: 6b4517a7913a ("block: implement bd_claiming and claiming block")
Cc: stable@vger.kernel.org (v2.6.35+)
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit ad6be98aa49eb7fc66c4718a34d3e32daa3063ab
Author: Jingkui Wang <jkwang@google.com>
Date: Mon Dec 12 13:51:46 2016 -0800
Input: drv260x - fix input device's parent assignment
[ Upstream commit 5a8a6b89c15766446d845671d574a9243b6d8786 ]
We were assigning I2C bus controller instead of client as parent device.
Besides being logically wrong, it messed up with devm handling of input
device. As a result we were leaving input device and event node behind
after rmmod-ing the driver, which lead to a kernel oops if one were to
access the event node later.
Let's remove the assignment and rely on devm_input_allocate_device() to
set it up properly for us.
Signed-off-by: Jingkui Wang <jkwang@google.com>
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 2eb056b54b6a3dd0345c50c7f0d93dab031c13a3
Author: Ilya Dryomov <idryomov@gmail.com>
Date: Fri Dec 2 16:35:09 2016 +0100
libceph: verify authorize reply on connect
[ Upstream commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 ]
After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
the client gets back a ceph_x_authorize_reply, which it is supposed to
verify to ensure the authenticity and protect against replay attacks.
The code for doing this is there (ceph_x_verify_authorizer_reply(),
ceph_auth_verify_authorizer_reply() + plumbing), but it is never
invoked by the the messenger.
AFAICT this goes back to 2009, when ceph authentication protocols
support was added to the kernel client in 4e7a5dcd1bba ("ceph:
negotiate authentication protocol; implement AUTH_NONE protocol").
The second param of ceph_connection_operations::verify_authorizer_reply
is unused all the way down. Pass 0 to facilitate backporting, and kill
it in the next commit.
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 91a34ab02f7d7b838cee3dcbb4aa4f00e5bab60b
Author: Jussi Laako <jussi@sonarnerd.net>
Date: Mon Nov 28 11:27:45 2016 +0200
ALSA: hiface: Fix M2Tech hiFace driver sampling rate change
[ Upstream commit 995c6a7fd9b9212abdf01160f6ce3193176be503 ]
Sampling rate changes after first set one are not reflected to the
hardware, while driver and ALSA think the rate has been changed.
Fix the problem by properly stopping the interface at the beginning of
prepare call, allowing new rate to be set to the hardware. This keeps
the hardware in sync with the driver.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 81aaf3cb08f3c6560aeeef9f1bf85ea074f3f5ac
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date: Mon Nov 21 12:13:58 2016 +0100
s390/vmlogrdr: fix IUCV buffer allocation
[ Upstream commit 5457e03de918f7a3e294eb9d26a608ab8a579976 ]
The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses >= 2 GB.
Fix this by using GFP_DMA for the buffer allocation.
Cc: stable@vger.kernel.org
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 023a7e0604d71d9ed7c09fc544c3788995edf262
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date: Thu Nov 24 22:10:23 2016 +0000
kconfig/nconf: Fix hang when editing symbol with a long prompt
[ Upstream commit 79e51b5c2deea542b3bb8c66e0d502230b017dde ]
Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters. dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid. It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.
The additions in the offset calculations also don't match the intended
size of the window.
Limit the window size and calculate the offset similarly to
show_scroll_win().
Cc: stable <stable@vger.kernel.org>
Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6fc6cae43a0ef8266f9eccee46c74646969b867d
Author: NeilBrown <neilb@suse.com>
Date: Mon Dec 5 15:10:11 2016 +1100
SUNRPC: fix refcounting problems with auth_gss messages.
[ Upstream commit 1cded9d2974fe4fe339fc0ccd6638b80d465ab2c ]
There are two problems with refcounting of auth_gss messages.
First, the reference on the pipe->pipe list (taken by a call
to rpc_queue_upcall()) is not counted. It seems to be
assumed that a message in pipe->pipe will always also be in
pipe->in_downcall, where it is correctly reference counted.
However there is no guaranty of this. I have a report of a
NULL dereferences in rpc_pipe_read() which suggests a msg
that has been freed is still on the pipe->pipe list.
One way I imagine this might happen is:
- message is queued for uid=U and auth->service=S1
- rpc.gssd reads this message and starts processing.
This removes the message from pipe->pipe
- message is queued for uid=U and auth->service=S2
- rpc.gssd replies to the first message. gss_pipe_downcall()
calls __gss_find_upcall(pipe, U, NULL) and it finds the
*second* message, as new messages are placed at the head
of ->in_downcall, and the service type is not checked.
- This second message is removed from ->in_downcall and freed
by gss_release_msg() (even though it is still on pipe->pipe)
- rpc.gssd tries to read another message, and dereferences a pointer
to this message that has just been freed.
I fix this by incrementing the reference count before calling
rpc_queue_upcall(), and decrementing it if that fails, or normally in
gss_pipe_destroy_msg().
It seems strange that the reply doesn't target the message more
precisely, but I don't know all the details. In any case, I think the
reference counting irregularity became a measureable bug when the
extra arg was added to __gss_find_upcall(), hence the Fixes: line
below.
The second problem is that if rpc_queue_upcall() fails, the new
message is not freed. gss_alloc_msg() set the ->count to 1,
gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1,
then the pointer is discarded so the memory never gets freed.
Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service")
Cc: stable@vger.kernel.org
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 0d39ae1e9eddfdc54204151d3a9aa4654a0cf532
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat Dec 10 09:56:01 2016 -0500
ext4: return -ENOMEM instead of success
[ Upstream commit 578620f451f836389424833f1454eeeb2ffc9e9f ]
We should set the error code if kzalloc() fails.
Fixes: 67cf5b09a46f ("ext4: add the basic function for inline data support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 79762247b6a0ec1b6f45e3ae7213e7e9b400e05c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Sep 5 21:42:32 2016 -0400
nfs_write_end(): fix handling of short copies
[ Upstream commit c0cf3ef5e0f47e385920450b245d22bead93e7ad ]
What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied. As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1a1f89b31f5e3542655171172e853e3dd920d3f9
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date: Thu Dec 8 20:54:49 2016 -0500
fgraph: Handle a case where a tracer ignores set_graph_notrace
[ Upstream commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 ]
Both the wakeup and irqsoff tracers can use the function graph tracer when
the display-graph option is set. The problem is that they ignore the notrace
file, and record the entry of functions that would be ignored by the
function_graph tracer. This causes the trace->depth to be recorded into the
ring buffer. The set_graph_notrace uses a trick by adding a large negative
number to the trace->depth when a graph function is to be ignored.
On trace output, the graph function uses the depth to record a stack of
functions. But since the depth is negative, it accesses the array with a
negative number and causes an out of bounds access that can cause a kernel
oops or corrupt data.
Have the print functions handle cases where a tracer still records functions
even when they are in set_graph_notrace.
Also add warnings if the depth is below zero before accessing the array.
Note, the function graph logic will still prevent the return of these
functions from being recorded, which means that they will be left hanging
without a return. For example:
# echo '*spin*' > set_graph_notrace
# echo 1 > options/display-graph
# echo wakeup > current_tracer
# cat trace
[...]
_raw_spin_lock() {
preempt_count_add() {
do_raw_spin_lock() {
update_rq_clock();
Where it should look like:
_raw_spin_lock() {
preempt_count_add();
do_raw_spin_lock();
}
update_rq_clock();
Cc: stable@vger.kernel.org
Cc: Namhyung Kim <namhyung.kim@lge.com>
Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 3e6eb9d1d89d5ed746c0e95a1c90a5134274f323
Author: Giuseppe Lippolis <giu.lippolis@gmail.com>
Date: Tue Dec 6 21:24:19 2016 +0100
USB: serial: option: add dlink dwm-158
[ Upstream commit d8a12b7117b42fd708f1e908498350232bdbd5ff ]
Adding registration for 3G modem DWM-158 in usb-serial-option
Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 53453ed7d5057f773ef9d107ebc637b5486ff003
Author: Daniele Palmas <dnlplm@gmail.com>
Date: Thu Dec 1 16:38:39 2016 +0100
USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041
[ Upstream commit 5b09eff0c379002527ad72ea5ea38f25da8a8650 ]
This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A.
Since the interface positions are the same than the ones used
for other Telit compositions, previous defined blacklists are used.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 9eb0316c4d37da93d2199a48165e9c2d8277e68b
Author: Con Kolivas <con@kolivas.org>
Date: Fri Dec 9 15:15:57 2016 +1100
ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks
[ Upstream commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 ]
The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
following warning.
[ 6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
cval->res is probably wrong.
[ 6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
4608/7680/1
Adding it to the list of devices in volume_control_quirks makes it work
properly, fixing related typo.
Signed-off-by: Con Kolivas <kernel@kolivas.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 4aedc0b0c6462f7facd60e4ef70150234aae643a
Author: Benjamin Marzinski <bmarzins@redhat.com>
Date: Wed Nov 30 17:56:14 2016 -0600
dm space map metadata: fix 'struct sm_metadata' leak on failed create
[ Upstream commit 314c25c56c1ee5026cf99c570bdfe01847927acb ]
In dm_sm_metadata_create() we temporarily change the dm_space_map
operations from 'ops' (whose .destroy function deallocates the
sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't).
If dm_sm_metadata_create() fails in sm_ll_new_metadata() or
sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls
dm_sm_destroy() with the intention of freeing the sm_metadata, but it
doesn't (because the dm_space_map operations is still set to
'bootstrap_ops').
Fix this by setting the dm_space_map operations back to 'ops' if
dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 16691059c77a6a444b84843683d3e8190058b3f6
Author: Julien Grall <julien.grall@arm.com>
Date: Wed Dec 7 12:24:40 2016 +0000
arm/xen: Use alloc_percpu rather than __alloc_percpu
[ Upstream commit 24d5373dda7c00a438d26016bce140299fae675e ]
The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.
However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.
Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.
This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.
[1]
[ 0.023921] illegal size (48) or align (48) for percpu allocation
[ 0.024167] ------------[ cut here ]------------
[ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[ 0.024584] Modules linked in:
[ 0.024708]
[ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[ 0.025012] Hardware name: Foundation-v8A (DT)
[ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[ 0.025351] PC is at pcpu_alloc+0x88/0x6c0
[ 0.025490] LR is at pcpu_alloc+0x88/0x6c0
[ 0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
pstate: 60000045
[ 0.025830] sp : ffff80003d847cd0
[ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[ 0.026147] x27: 0000000000000000 x26: 0000000000000000
[ 0.026348] x25: 0000000000000000 x24: 0000000000000000
[ 0.026549] x23: 0000000000000000 x22: 00000000024000c0
[ 0.026752] x21: ffff000008e97000 x20: 0000000000000000
[ 0.026953] x19: 0000000000000030 x18: 0000000000000010
[ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[ 0.027782] x11: 0000000000000006 x10: 0000000000000042
[ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[ 0.029056]
[ 0.029152] ---[ end trace 0000000000000000 ]---
[ 0.029297] Call trace:
[ 0.029403] Exception stack(0xffff80003d847b00 to
0xffff80003d847c30)
[ 0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[ 0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[ 0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[ 0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[ 0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[ 0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[ 0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
[ 0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
[ 0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
[ 0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
[ 0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
[ 0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
[ 0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
Reported-by: Wei Chen <wei.chen@arm.com>
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 580d23f5ffe9e343979bc20d2b3c51da67d73649
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Dec 2 00:21:48 2016 -0500
drm/radeon: add additional pci revision to dpm workaround
[ Upstream commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 ]
New variant.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit d0d2a4c82942e2f51e4984beea1f7e5a994bd06c
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Fri Nov 4 11:50:31 2016 -0700
CIFS: Fix a possible memory corruption during reconnect
[ Upstream commit 53e0e11efe9289535b060a51d4cf37c25e0d0f2b ]
We can not unlock/lock cifs_tcp_ses_lock while walking through ses
and tcon lists because it can corrupt list iterator pointers and
a tcon structure can be released if we don't hold an extra reference.
Fix it by moving a reconnect process to a separate delayed work
and acquiring a reference to every tcon that needs to be reconnected.
Also do not send an echo request on newly established connections.
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit be79af5f784536bb160e10715a2d198a6a112f44
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Tue Nov 29 16:14:43 2016 -0800
CIFS: Fix a possible memory corruption in push locks
[ Upstream commit e3d240e9d505fc67f8f8735836df97a794bbd946 ]
If maxBuf is not 0 but less than a size of SMB2 lock structure
we can end up with a memory corruption.
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6ec5ca625b5459506bcdcafd3594b559c90a9f1a
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Tue Nov 29 11:30:58 2016 -0800
CIFS: Fix missing nls unload in smb2_reconnect()
[ Upstream commit 4772c79599564bd08ee6682715a7d3516f67433f ]
Cc: Stable <stable@vger.kernel.org>
Acked-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 707d28d3fd998530cc13017ce0ef493e780ffe82
Author: Nathaniel Quillin <ndq@google.com>
Date: Mon Dec 5 06:53:00 2016 -0800
USB: cdc-acm: add device id for GW Instek AFG-125
[ Upstream commit 301216044e4c27d5a7323c1fa766266fad00db5e ]
Add device-id entry for GW Instek AFG-125, which has a byte swapped
bInterfaceSubClass (0x20).
Signed-off-by: Nathaniel Quillin <ndq@google.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6fe5845642c77a39519e177569791c8e05658e8c
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Fri Dec 2 15:14:20 2016 +0200
mmc: sdhci: Fix recovery from tuning timeout
[ Upstream commit 61e53bd0047d58caee0c7170613045bf96de4458 ]
Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.
Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.
Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Dan O'Donovan <dan@emutex.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 74a1a07c88add3824f8be8654a77e245c1851a82
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Dec 5 11:19:38 2016 +0100
ALSA: usb-audio: Fix race at stopping the stream
[ Upstream commit 16200948d8353fe29a473a394d7d26790deae0e7 ]
We've got a kernel crash report showing like:
Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = a1d7c000
[00000008] *pgd=31c93831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1
task: a3ae61c0 ti: a08c8000 task.ti: a08c8000
PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio]
LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio]
pc : [<7f0eb22c>] lr : [<7f0e57fc>] psr: 200e0193
sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4
r10: 0000000a r9 : 00000102 r8 : 94cb3000
r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000
r3 : 7f0eb21c r2 : 00000000 r1 : 94cb3000 r0 : 00000000
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 31d7c04a DAC: 00000015
Process dbus-daemon (pid: 250, stack limit = 0xa08c8238)
Stack: (0xa08c9c98 to 0xa08ca000)
...
Backtrace:
[<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>] (snd_complete_urb+0x140/0x1f0 [snd_usb_audio])
[<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>] (__usb_hcd_giveback_urb+0x78/0xf4)
[<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>] (usb_giveback_urb_bh+0x8c/0xc0)
[<80371488>] (usb_giveback_urb_bh) from [<80028e3c>] (tasklet_hi_action+0xc4/0x148)
[<80028d78>] (tasklet_hi_action) from [<80028358>] (__do_softirq+0x190/0x380)
[<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc)
[<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8)
[<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8)
[<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78)
[<80508820>] (_raw_spin_unlock_irq) from [<8004b880>] (finish_task_switch+0x5c/0x100)
[<8004b824>] (finish_task_switch) from [<805052f0>] (__schedule+0x48c/0x6d8)
[<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c)
[<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0)
[<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20)
Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008)
Kernel panic - not syncing: Fatal exception in interrupt
There is a race between retire_capture_urb() and stop_endpoints().
The latter is called at stopping the stream and it sets some endpoint
fields to NULL. But its call is asynchronous, thus the pending
complete callback might get called after these NULL clears, and it
leads the NULL dereference like the above.
The fix is to move the NULL clearance after the synchronization,
i.e. wait_clear_urbs(). This is called at prepare and hw_free
callbacks, so it's assured to be called before the restart of the
stream or the release of the stream.
Also, while we're at it, put the EP_FLAG_RUNNING flag check at the
beginning of snd_complete_urb() to skip the pending complete after the
stream is stopped.
Fixes: b2eb950de2f0 ("ALSA: usb-audio: stop both data and sync...")
Reported-by: Jiada Wang <jiada_wang@mentor.com>
Reported-by: Mark Craske <Mark_Craske@mentor.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b5820655d484d913001f104400e8f0ce05738bc0
Author: Eric Sandeen <sandeen@sandeen.net>
Date: Mon Dec 5 12:31:06 2016 +1100
xfs: set AGI buffer type in xlog_recover_clear_agi_bucket
[ Upstream commit 6b10b23ca94451fae153a5cc8d62fd721bec2019 ]
xlog_recover_clear_agi_bucket didn't set the
type to XFS_BLFT_AGI_BUF, so we got a warning during log
replay (or an ASSERT on a debug build).
XFS (md0): Unknown buffer type 0!
XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
Fix this, as was done in f19b872b for 2 other locations
with the same problem.
cc: <stable@vger.kernel.org> # 3.10 to current
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit d0cfefba45916e4033fa54782f8965e51f355d55
Author: Rabin Vincent <rabinv@axis.com>
Date: Thu Dec 1 09:18:28 2016 +0100
block: protect iterate_bdevs() against concurrent close
[ Upstream commit af309226db916e2c6e08d3eba3fa5c34225200c4 ]
If a block device is closed while iterate_bdevs() is handling it, the
following NULL pointer dereference occurs because bdev->b_disk is NULL
in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
turn called by the mapping_cap_writeback_dirty() call in
__filemap_fdatawrite_range()):
BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
PGD 9e62067 PUD 9ee8067 PMD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
RIP: 0010:[<ffffffff81314790>] [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
Stack:
ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
Call Trace:
[<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
[<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
[<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
[<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
[<ffffffff811b2763>] sys_sync+0x63/0x90
[<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
RIP [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
RSP <ffff880009f5fe68>
CR2: 0000000000000508
---[ end trace 2487336ceb3de62d ]---
The crash is easily reproducible by running the following command, if an
msleep(100) is inserted before the call to func() in iterate_devs():
while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
Fix it by holding the bd_mutex across the func() call and only calling
func() if the bdev is opened.
Cc: stable@vger.kernel.org
Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
Reported-and-tested-by: Wei Fang <fangwei1@huawei.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 5ccc9afa6d0e133ac4d96a57de0629728528d4cc
Author: Robbie Ko <robbieko@synology.com>
Date: Fri Oct 7 17:30:47 2016 +0800
Btrfs: fix tree search logic when replaying directory entry deletes
[ Upstream commit 2a7bf53f577e49c43de4ffa7776056de26db65d9 ]
If a log tree has a layout like the following:
leaf N:
...
item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8
dir log end 1275809046
leaf N + 1:
item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8
dir log end 18446744073709551615
...
When we pass the value 1275809046 + 1 as the parameter start_ret to the
function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we
end up with path->slots[0] having the value 239 (points to the last item
of leaf N, item 240). Because the dir log item in that position has an
offset value smaller than *start_ret (1275809046 + 1) we need to move on
to the next leaf, however the logic for that is wrong since it compares
the current slot to the number of items in the leaf, which is smaller
and therefore we don't lookup for the next leaf but instead we set the
slot to point to an item that does not exist, at slot 240, and we later
operate on that slot which has unexpected content or in the worst case
can result in an invalid memory access (accessing beyond the last page
of leaf N's extent buffer).
So fix the logic that checks when we need to lookup at the next leaf
by first incrementing the slot and only after to check if that slot
is beyond the last item of the current leaf.
Signed-off-by: Robbie Ko <robbieko@synology.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Fixes: e02119d5a7b4 (Btrfs: Add a write ahead tree log to optimize synchronous operations)
Cc: stable@vger.kernel.org # 2.6.29+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
[Modified changelog for clarity and correctness]
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 28d39c27cc10c273a0b81d9d6409faecb9eaf9c8
Author: Geoff Levand <geoff@infradead.org>
Date: Tue Nov 29 10:47:32 2016 -0800
powerpc/ps3: Fix system hang with GCC 5 builds
[ Upstream commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 ]
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This check is of
limited value, so just get rid of it.
Cc: stable@vger.kernel.org
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit f7face12f6e6bab695d7e1c01309db04965dcc03
Author: Johan Hovold <johan@kernel.org>
Date: Tue Nov 29 16:55:01 2016 +0100
USB: serial: kl5kusb105: fix open error path
[ Upstream commit 6774d5f53271d5f60464f824748995b71da401ab ]
Kill urbs and disable read before returning from open on failure to
retrieve the line state.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit cc49a97516efdae4c867c4f5576caf5758e39650
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date: Tue Nov 22 19:22:44 2016 +0200
thermal: hwmon: Properly report critical temperature in sysfs
[ Upstream commit f37fabb8643eaf8e3b613333a72f683770c85eca ]
In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space. It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.
For example:
/sys/class/hwmon/hwmon0/temp1_crit:50000
/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
/sys/class/thermal/thermal_zone0/trip_point_0_type:active
/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
/sys/class/thermal/thermal_zone0/trip_point_3_type:critical
Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided. However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().
Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit e8b963dd533d52658b1213e2115b0bf22b98e491
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Sun Nov 27 19:32:32 2016 +0300
md/raid5: limit request size according to implementation limits
[ Upstream commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 ]
Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.
Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.
Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.
This patch limits requests size with 256Mb - 8Kb to prevent overflows.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Shaohua Li <shli@kernel.org>
Cc: Neil Brown <neilb@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b24ae852ddfe3de29604ec64acf59c822b7e7712
Author: Nicolai Stange <nicstange@gmail.com>
Date: Sun Nov 20 19:57:23 2016 +0100
f2fs: set ->owner for debugfs status file's file_operations
[ Upstream commit 05e6ea2685c964db1e675a24a4f4e2adc22d2388 ]
The struct file_operations instance serving the f2fs/status debugfs file
lacks an initialization of its ->owner.
This means that although that file might have been opened, the f2fs module
can still get removed. Any further operation on that opened file, releasing
included, will cause accesses to unmapped memory.
Indeed, Mike Marshall reported the following:
BUG: unable to handle kernel paging request at ffffffffa0307430
IP: [<ffffffff8132a224>] full_proxy_release+0x24/0x90
<...>
Call Trace:
[] __fput+0xdf/0x1d0
[] ____fput+0xe/0x10
[] task_work_run+0x8e/0xc0
[] do_exit+0x2ae/0xae0
[] ? __audit_syscall_entry+0xae/0x100
[] ? syscall_trace_enter+0x1ca/0x310
[] do_group_exit+0x44/0xc0
[] SyS_exit_group+0x14/0x20
[] do_syscall_64+0x61/0x150
[] entry_SYSCALL64_slow_path+0x25/0x25
<...>
---[ end trace f22ae883fa3ea6b8 ]---
Fixing recursive fault but reboot is needed!
Fix this by initializing the f2fs/status file_operations' ->owner with
THIS_MODULE.
This will allow debugfs to grab a reference to the f2fs module upon any
open on that file, thus preventing it from getting removed.
Fixes: 902829aa0b72 ("f2fs: move proc files to debugfs")
Reported-by: Mike Marshall <hubcap@omnibond.com>
Reported-by: Martin Brandenburg <martin@omnibond.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 0aa4606439f796354ef30fb10aca3fba2bc97e0b
Author: Hui Wang <hui.wang@canonical.com>
Date: Wed Nov 23 16:05:38 2016 +0800
ALSA: hda - fix headset-mic problem on a Dell laptop
[ Upstream commit 989dbe4a30728c047316ab87e5fa8b609951ce7c ]
This group of new pins is not in the pin quirk table yet, adding
them to the pin quirk table to fix the headset-mic problem.
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 2269a1fb8ea0c460548abcb0fe09c2e58c5113d4
Author: Ondrej Kozina <okozina@redhat.com>
Date: Wed Nov 2 15:02:08 2016 +0100
dm crypt: mark key as invalid until properly loaded
[ Upstream commit 265e9098bac02bc5e36cda21fdbad34cb5b2f48d ]
In crypt_set_key(), if a failure occurs while replacing the old key
(e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag
set. Otherwise, the crypto layer would have an invalid key that still
has DM_CRYPT_KEY_VALID flag set.
Cc: stable@vger.kernel.org
Signed-off-by: Ondrej Kozina <okozina@redhat.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 7b0668db2acb4c6e136235e4734e6d6c22406edb
Author: Paul Mackerras <paulus@ozlabs.org>
Date: Mon Nov 7 15:09:58 2016 +1100
KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state
[ Upstream commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 ]
When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state. Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.
This fixes it by saving and restoring the XER. To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.
The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.
Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit cefafbaa4a6ae8141182a7eb1d24e611483dfcb4
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Nov 18 13:37:47 2016 -0500
ext4: add sanity checking to count_overhead()
[ Upstream commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814 ]
The commit "ext4: sanity check the block and cluster size at mount
time" should prevent any problems, but in case the superblock is
modified while the file system is mounted, add an extra safety check
to make sure we won't overrun the allocated buffer.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit f358bbb9f1922f34e9056bb6a3ba60abc825a10e
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Nov 18 13:28:30 2016 -0500
ext4: use more strict checks for inodes_per_block on mount
[ Upstream commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96 ]
Centralize the checks for inodes_per_block and be more strict to make
sure the inodes_per_block_group can't end up being zero.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b703a4013adddf275fb167d646d892946916a53f
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Nov 18 13:00:24 2016 -0500
ext4: sanity check the block and cluster size at mount time
[ Upstream commit 9e47a4c9fc58032ee135bf76516809c7624b1551 ]
If the block size or cluster size is insane, reject the mount. This
is important for security reasons (although we shouldn't be just
depending on this check).
Ref: http://www.securityfocus.com/archive/1/539661
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506
Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit fdc4d918bc16f160680ed826bae0b6f36fbd5768
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Thu Nov 17 11:14:14 2016 +0200
usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices
[ Upstream commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 ]
USB-3 does not have any link state that will avoid negotiating a connection
with a plugged-in cable but will signal the host when the cable is
unplugged.
For USB-3 we used to first set the link to Disabled, then to RxDdetect to
be able to detect cable connects or disconnects. But in RxDetect the
connected device is detected again and eventually enabled.
Instead set the link into U3 and disable remote wakeups for the device.
This is what Windows does, and what Alan Stern suggested.
Cc: stable@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 76fa34bf3e9c30b3e838b87ab2530728774f0e0d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sat Nov 5 14:08:57 2016 -0500
ssb: Fix error routine when fallback SPROM fails
[ Upstream commit 8052d7245b6089992343c80b38b14dbbd8354651 ]
When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 14cd1eeed8c056e0821994b4ab67cb38db492255
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Mon Nov 14 20:16:21 2016 +0000
staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask
[ Upstream commit 655c4d442d1213b617926cc6d54e2a9a793fb46b ]
For NI M Series cards, the Comedi `insn_read` handler for the AI
subdevice is broken due to ANDing the value read from the AI FIFO data
register with an incorrect mask. The incorrect mask clears all but the
most significant bit of the sample data. It should preserve all the
sample data bits. Correct it.
Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 9a01b9e42b2f6d1ba31a3a1664d289972d9878b0
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date: Mon Nov 14 21:26:26 2016 -0500
ext4: fix stack memory corruption with 64k block size
[ Upstream commit 30a9d7afe70ed6bd9191d3000e2ef1a34fb58493 ]
The number of 'counters' elements needed in 'struct sg' is
super_block->s_blocksize_bits + 2. Presently we have 16 'counters'
elements in the array. This is insufficient for block sizes >= 32k. In
such cases the memcpy operation performed in ext4_mb_seq_groups_show()
would cause stack memory corruption.
Fixes: c9de560ded61f
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6437599ef8bf9b6bfae97afb7b3b5eb3371a3bd2
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date: Mon Nov 14 21:04:37 2016 -0500
ext4: fix mballoc breakage with 64k block size
[ Upstream commit 69e43e8cc971a79dd1ee5d4343d8e63f82725123 ]
'border' variable is set to a value of 2 times the block size of the
underlying filesystem. With 64k block size, the resulting value won't
fit into a 16-bit variable. Hence this commit changes the data type of
'border' to 'unsigned int'.
Fixes: c9de560ded61f
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit e92d3649f8f8037b16d7fce3751fa15513e4352d
Author: Alex Porosanu <alexandru.porosanu@nxp.com>
Date: Wed Nov 9 10:46:11 2016 +0200
crypto: caam - fix AEAD givenc descriptors
[ Upstream commit d128af17876d79b87edf048303f98b35f6a53dbc ]
The AEAD givenc descriptor relies on moving the IV through the
output FIFO and then back to the CTX2 for authentication. The
SEQ FIFO STORE could be scheduled before the data can be
read from OFIFO, especially since the SEQ FIFO LOAD needs
to wait for the SEQ FIFO LOAD SKIP to finish first. The
SKIP takes more time when the input is SG than when it's
a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
before the STORE, the DECO will hang waiting for data
to be available in the OFIFO so it can be transferred to C2.
In order to overcome this, first force transfer of IV to C2
by starting the "cryptlen" transfer first and then starting to
store data from OFIFO to the output buffer.
Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
Cc: <stable@vger.kernel.org> # 3.2+
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 8fee50f9de839a19e634ff2e7d07b4be93a68d41
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Sat Nov 12 15:22:38 2016 +0100
regulator: stw481x-vmmc: fix ages old enable error
[ Upstream commit 295070e9aa015abb9b92cccfbb1e43954e938133 ]
The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.
Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 577c0b8779c23da136c1c931e3b52e55e8478e7c
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Fri Oct 21 16:49:07 2016 -0400
USB: UHCI: report non-PME wakeup signalling for Intel hardware
[ Upstream commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 ]
The UHCI controllers in Intel chipsets rely on a platform-specific non-PME
mechanism for wakeup signalling. They can generate wakeup signals even
though they don't support PME.
We need to let the USB core know this so that it will enable runtime
suspend for UHCI controllers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 8537ab5ad79f6d528df8ef6a7ea4a3f44087ae90
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Fri Oct 21 16:45:38 2016 -0400
PCI: Check for PME in targeted sleep state
[ Upstream commit 6496ebd7edf446fccf8266a1a70ffcb64252593e ]
One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states. This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state. For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals. As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly. USB devices plugged into the controller are never detected.
If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend. This patch modifies the
pci_dev_run_wake() routine to add this check.
Reported-by: Pierre de Villemereuil <flyos@mailoo.org>
Tested-by: Pierre de Villemereuil <flyos@mailoo.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org
CC: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 066820f3484ea8f01a27f640d54b17907073e791
Author: Kashyap Desai <kashyap.desai@broadcom.com>
Date: Fri Oct 21 06:33:29 2016 -0700
scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset
[ Upstream commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c ]
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds. As driver does
not set convert flag to 1 and still making the OCR to run, VF(Virtual
function) driver is directly writing on to the register instead of
waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
will wait for 30 secs before going for reset.
CC: stable@vger.kernel.org
Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 305e545c05931aacc1a8de6db3eeb66c3f2f5d3e
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Tue Nov 1 15:43:15 2016 +0100
drm/gma500: Add compat ioctl
[ Upstream commit 0a97c81a9717431e6c57ea845b59c3c345edce67 ]
Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
It turns out that N2600 and N2800 comes with 64-bit enabled. We
previously assumed there where no such systems out there.
Cc: stable@vger.kernel.org
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit ee5c93577da48a31ef15a5922f97cfa67878fc55
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Wed Sep 28 10:38:11 2016 +0300
usb: gadget: composite: correctly initialize ep->maxpacket
[ Upstream commit e8f29bb719b47a234f33b0af62974d7a9521a52c ]
usb_endpoint_maxp() returns wMaxPacketSize in its
raw form. Without taking into consideration that it
also contains other bits reserved for isochronous
endpoints.
This patch fixes one occasion where this is a
problem by making sure that we initialize
ep->maxpacket only with lower 10 bits of the value
returned by usb_endpoint_maxp(). Note that seperate
patches will be necessary to audit all call sites of
usb_endpoint_maxp() and make sure that
usb_endpoint_maxp() only returns lower 10 bits of
wMaxPacketSize.
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>