commit bb28cae901ddf2a4c708dbd03e9e304536c966dc
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat Aug 20 11:53:43 2016 +0200
Linux 3.14.77
commit b792e7f015c8030d54f3a0833d1193f81c2b393b
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Apr 28 09:24:05 2016 +0930
Documentation/module-signing.txt: Note need for version info if reusing a key
commit b8612e517c3c9809e1200b72c474dbfd969e5a83 upstream.
Signing a module should only make it trusted by the specific kernel it
was built for, not anything else. If a module signing key is used for
multiple ABI-incompatible kernels, the modules need to include enough
version information to distinguish them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc77c4ad276a03ac9217e7db44339003ba1de6bd
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Apr 28 09:24:01 2016 +0930
module: Invalidate signatures on force-loaded modules
commit bca014caaa6130e57f69b5bf527967aa8ee70fdd upstream.
Signing a module should only make it trusted by the specific kernel it
was built for, not anything else. Loading a signed module meant for a
kernel with a different ABI could have interesting effects.
Therefore, treat all signatures as invalid when a module is
force-loaded.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7aca820d3b93fa028ecb2077b482587a26beeb6
Author: Mike Snitzer <snitzer@redhat.com>
Date: Fri Jul 29 13:19:55 2016 -0400
dm flakey: error READ bios during the down_interval
commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.
When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval. This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.
Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte
feature.
Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa <ruby.wktk@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc72d914c05f530dec9c7f5f4e301700e6e4c4ba
Author: Chris Blake <chrisrblake93@gmail.com>
Date: Mon May 30 07:26:37 2016 -0500
PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.
Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.
Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 034668ac914f360ac300d56d4cb80f2b919852fa
Author: Mike Christie <mchristi@redhat.com>
Date: Thu Jun 2 20:12:37 2016 -0500
target: Fix max_unmap_lba_count calc overflow
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.
max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.
This fixes a regression caused by my patch:
commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie <mchristi@redhat.com>
Date: Mon Jan 18 14:09:27 2016 -0600
target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors
which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.
Signed-off-by: Mike Christie <mchristi@redhat.com>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4a233770354929cd5c0178c0f09aa12d2227715
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Thu Jun 2 14:56:45 2016 -0700
target: Fix race between iscsi-target connection shutdown + ABORT_TASK
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.
This patch fixes a race in iscsit_release_commands_from_conn() ->
iscsit_free_cmd() -> transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.
This results in transport_generic_free_cmd() blocking indefinately
on se_cmd->cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.
To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn->cmd_lock. Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.
Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.
Cc: Mike Christie <mchristi@redhat.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Tested-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6117840dec60344167038f9511c3770d4c096eaa
Author: Iosif Harutyunov <iharutyunov@SonicWALL.com>
Date: Fri Jul 22 23:22:42 2016 +0000
ubi: Fix race condition between ubi device creation and udev
commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.
Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.
Signed-off-by: Iosif Harutyunov <iharutyunov@sonicwall.com>
[rw: massaged commit message]
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 83770c0e1822e505bb71d8c1e118feb92eacf8a0
Author: Richard Weinberger <richard@nod.at>
Date: Thu Jun 23 19:30:38 2016 +0200
ubi: Make volume resize power cut aware
commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.
When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.
Fix this issue by waiting for erase to complete and write the new
volume table afterward.
Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b873cc9edceee10f05ee789ae633d87322edc1f4
Author: Yishai Hadas <yishaih@mellanox.com>
Date: Wed Jun 22 17:27:28 2016 +0300
IB/mlx4: Fix the SQ size of an RC QP
commit f2940e2c76bb554a7fbdd28ca5b90904117a9e96 upstream.
When calculating the required size of an RC QP send queue, leave
enough space for masked atomic operations, which require more space than
"regular" atomic operation.
Fixes: 6fa8f719844b ("IB/mlx4: Add support for masked atomic operations")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Jack Morgenstein <jackm@mellanox.co.il>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ade849b0a93748ac10e148ad23ac76af362c3f9
Author: Erez Shitrit <erezsh@mellanox.com>
Date: Sat Jun 4 15:15:19 2016 +0300
IB/IPoIB: Don't update neigh validity for unresolved entries
commit 61c78eea9516a921799c17b4c20558e2aa780fd3 upstream.
ipoib_neigh_get unconditionally updates the "alive" variable member on
any packet send. This prevents the neighbor garbage collection from
cleaning out a dead neighbor entry if we are still queueing packets
for it. If the queue for this neighbor is full, then don't update the
alive timestamp. That way the neighbor can time out even if packets
are still being queued as long as none of them are being sent.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path")
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0874b369269ef2d4db0d52c865d4b294c11db6e
Author: Eli Cohen <eli@mellanox.com>
Date: Wed Jun 22 17:27:26 2016 +0300
IB/mlx5: Fix post send fence logic
commit c9b254955b9f8814966f5dabd34c39d0e0a2b437 upstream.
If the caller specified IB_SEND_FENCE in the send flags of the work
request and no previous work request stated that the successive one
should be fenced, the work request would be executed without a fence.
This could result in RDMA read or atomic operations failure due to a MR
being invalidated. Fix this by adding the mlx5 enumeration for fencing
RDMA/atomic operations and fix the logic to apply this.
Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2cff2b867310e4d7404a4272535661d6b6ea9df8
Author: Noa Osherovich <noaos@mellanox.com>
Date: Sat Jun 4 15:15:32 2016 +0300
IB/mlx5: Fix returned values of query QP
commit 0540d8148d419bf769e5aa99c77027febd8922f0 upstream.
Some variables were not initialized properly: max_recv_wr,
max_recv_sge, max_send_wr, qp_context and max_inline_data.
Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB...')
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 738ed2dcdd73482974c9528e1a5edba906c796bd
Author: Artemy Kovalyov <artemyko@mellanox.com>
Date: Fri Jun 17 15:33:31 2016 +0300
IB/mlx5: Fix MODIFY_QP command input structure
commit e3353c268b06236d6c40fa1714c114f21f44451c upstream.
Make MODIFY_QP command input structure compliant to specification
Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e47661ff86d8729aaf9df53cb4924292f7993a20
Author: James Hogan <james.hogan@imgtec.com>
Date: Thu Aug 4 17:36:08 2016 +0100
metag: Fix __cmpxchg_u32 asm constraint for CMP
commit 6154c187b97ee7513046bb4eb317a89f738f13ef upstream.
The LNKGET based atomic sequence in __cmpxchg_u32 has slightly incorrect
constraints for the return value which under certain circumstances can
allow an address unit register to be used as the first operand of a CMP
instruction. This isn't a valid instruction however as the encodings
only allow a data unit to be specified. This would result in an
assembler error like the following:
Error: failed to assemble instruction: "CMP A0.2,D0Ar6"
Fix by changing the constraint from "=&da" (assigned, early clobbered,
data or address unit register) to "=&d" (data unit register only).
The constraint for the second operand, "bd" (an op2 register where op1
is a data unit register and the instruction supports O2R) is already
correct assuming the first operand is a data unit register.
Other cases of CMP in inline asm have had their constraints checked, and
appear to all be fine.
Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b5b3ce548fcbe00036a1f722531efd25049f46b
Author: Laura Abbott <labbott@redhat.com>
Date: Fri Jul 8 12:18:50 2016 -0700
ftrace/recordmcount: Work around for addition of metag magic but not relocations
commit b2e1c26f0b62531636509fbcb6dab65617ed8331 upstream.
glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi
webpage") that added a #define for EM_METAG but did not add relocations
This triggers build errors:
scripts/recordmcount.c: In function 'do_file':
scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function)
case EM_METAG: reltype = R_METAG_ADDR32;
^~~~~~~~~~~~~~
scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in
scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function)
rel_type_nop = R_METAG_NONE;
^~~~~~~~~~~~
Work around this change with some more #ifdefery for the relocations.
Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034
Link: http://lkml.kernel.org/r/1468005530-14757-1-git-send-email-labbott@redhat.com
Cc: James Hogan <james.hogan@imgtec.com>
Fixes: 00512bdd4573 ("metag: ftrace support")
Reported-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 778116cc268a41e19d487c93fac9bb6d41513a5a
Author: Konstantin Neumoin <kneumoin@virtuozzo.com>
Date: Mon Jul 11 15:28:59 2016 +0300
balloon: check the number of available pages in leak balloon
commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 upstream.
The balloon has a special mechanism that is subscribed to the oom
notification which leads to deflation for a fixed number of pages.
The number is always fixed even when the balloon is fully deflated.
But leak_balloon did not expect that the pages to deflate will be more
than taken, and raise a "BUG" in balloon_page_dequeue when page list
will be empty.
So, the simplest solution would be to check that the number of releases
pages is less or equal to the number taken pages.
Signed-off-by: Konstantin Neumoin <kneumoin@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d6e414eaf05825514a84c5275b49c9c4c280d3b
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Wed Jul 6 12:05:45 2016 +0200
drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
commit 196f954e250943df414efd3d632254c29be38e59 upstream.
This reverts commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.
Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.
The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.
DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.
Please backport to stable.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0999578ef8ae07c842fe0ee5e95ef1e74b9d402e
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Jul 8 17:27:04 2016 -0400
drm/radeon: support backlight control for UNIPHY3
commit d3200be6c423afa1c34f7e39e9f6d04dd5b0af9d upstream.
Same interface as other UNIPHY blocks
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit abe209e601041aa9751a7c3e33b4792d375be060
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Wed Jul 27 15:28:56 2016 -0400
drm/radeon: fix firmware info version checks
commit 3edc38a0facef45ee22af8afdce3737f421f36ab upstream.
Some of the checks didn't handle frev 2 tables properly.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4b2f6ef0b65eb4f0fb9dd2bf44989c30e7d44cf
Author: Lyude <cpaul@redhat.com>
Date: Fri Jun 24 17:54:31 2016 -0400
drm/radeon: Poll for both connect/disconnect on analog connectors
commit 14ff8d48f2235295dfb3117693008e367b49cdb5 upstream.
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with a radeon GPU and a VGA port
- Plug a monitor into the VGA port, wait for it to update the connector
from disconnected to connected
- Disconnect the monitor on VGA, a hotplug event is never sent for the
removal of the connector.
Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.
Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dee66d2c89b5dede8c14033fa53e5639e7f5e446
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Wed Jun 1 12:58:36 2016 -0400
drm/radeon: add a delay after ATPX dGPU power off
commit d814b24fb74cb9797d70cb8053961447c5879a5c upstream.
ATPX dGPU power control requires a 200ms delay between
power off and on. This should fix dGPU failures on
resume from power off.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f067bc41a7fdbead47a3042040ee887d9dbdf44
Author: Paul Moore <paul@paul-moore.com>
Date: Mon Jun 6 15:17:20 2016 -0400
netlabel: add address family checks to netlbl_{sock,req}_delattr()
commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 upstream.
It seems risky to always rely on the caller to ensure the socket's
address family is correct before passing it to the NetLabel kAPI,
especially since we see at least one LSM which didn't. Add address
family checks to the *_delattr() functions to help prevent future
problems.
Reported-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6ca565341e43c8e2a643df10c9595ef5cbee1e1
Author: Steve Capper <steve.capper@arm.com>
Date: Tue Jun 7 17:58:06 2016 +0100
ARM: 8579/1: mm: Fix definition of pmd_mknotpresent
commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 upstream.
Currently pmd_mknotpresent will use a zero entry to respresent an
invalidated pmd.
Unfortunately this definition clashes with pmd_none, thus it is
possible for a race condition to occur if zap_pmd_range sees pmd_none
whilst __split_huge_pmd_locked is running too with pmdp_invalidate
just called.
This patch fixes the race condition by modifying pmd_mknotpresent to
create non-zero faulting entries (as is done in other architectures),
removing the ambiguity with pmd_none.
[catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]
Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc: <stable@vger.kernel.org> # 3.11+
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3acd7bf39cdb109aaaef2ec4819cca7088218a4b
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Dec 30 08:51:12 2015 -0500
udp: properly support MSG_PEEK with truncated buffers
commit 197c949e7798fbf28cfadc69d9ca0c2abbf93191 upstream.
Backport of this upstream commit into stable kernels :
89c22d8c3b27 ("net: Fix skb csum races when peeking")
exposed a bug in udp stack vs MSG_PEEK support, when user provides
a buffer smaller than skb payload.
In this case,
skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr),
msg->msg_iov);
returns -EFAULT.
This bug does not happen in upstream kernels since Al Viro did a great
job to replace this into :
skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg);
This variant is safe vs short buffers.
For the time being, instead reverting Herbert Xu patch and add back
skb->ip_summed invalid changes, simply store the result of
udp_lib_checksum_complete() so that we avoid computing the checksum a
second time, and avoid the problematic
skb_copy_and_csum_datagram_iovec() call.
This patch can be applied on recent kernels as it avoids a double
checksumming, then backported to stable kernels as a bug fix.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Charles (Chas) Williams <ciwillia@brocade.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fd13a6831e1c770e20619efb48be360c24574717
Author: Kangjie Lu <kangjielu@gmail.com>
Date: Tue May 3 16:32:16 2016 -0400
USB: usbfs: fix potential infoleak in devio
commit 681fef8380eb818c0b845fca5d2ab1dcbab114ee upstream.
The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Charles (Chas) Williams <ciwillia@brocade.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c6f91e395929b77e5e3893c331eb5a88d45b55c
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Mon Jul 18 10:41:57 2016 -0400
nfs: don't create zero-length requests
commit 149a4fddd0a72d526abbeac0c8deaab03559836a upstream.
NFS doesn't expect requests with wb_bytes set to zero and may make
unexpected decisions about how to handle that request at the page IO layer.
Skip request creation if we won't have any wb_bytes in the request.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Reviewed-by: Weston Andros Adamson <dros@primarydata.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 72280d77f19106e5acb36e3211469d72e6cc8a12
Author: James Hogan <james.hogan@imgtec.com>
Date: Thu Aug 18 10:22:55 2016 +0100
MIPS: KVM: Propagate kseg0/mapped tlb fault errors
commit 9b731bcfdec4c159ad2e4312e25d69221709b96a upstream.
Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and
kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal
error since they normally indicate the guest accessed bad physical
memory or the commpage in an unexpected way.
Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[james.hogan@imgtec.com: Backport to v3.10.y - v3.15.y]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c94ccfa80eafc0e26a1a1712600c19b128487cf8
Author: James Hogan <james.hogan@imgtec.com>
Date: Thu Aug 18 10:22:54 2016 +0100
MIPS: KVM: Fix gfn range check in kseg0 tlb faults
commit 0741f52d1b980dbeb290afe67d88fc2928edd8ab upstream.
Two consecutive gfns are loaded into host TLB, so ensure the range check
isn't off by one if guest_pmap_npages is odd.
Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[james.hogan@imgtec.com: Backport to v3.10.y - v3.15.y]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 187e049062bcb3dbdaff9e9414f47cd960f8fce4
Author: James Hogan <james.hogan@imgtec.com>
Date: Thu Aug 18 10:22:53 2016 +0100
MIPS: KVM: Add missing gfn range check
commit 8985d50382359e5bf118fdbefc859d0dbf6cebc7 upstream.
kvm_mips_handle_mapped_seg_tlb_fault() calculates the guest frame number
based on the guest TLB EntryLo values, however it is not range checked
to ensure it lies within the guest_pmap. If the physical memory the
guest refers to is out of range then dump the guest TLB and emit an
internal error.
Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[james.hogan@imgtec.com: Backport to v3.10.y - v3.15.y]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1c9a61089774770466fb9921a82c5f44b6428cb
Author: James Hogan <james.hogan@imgtec.com>
Date: Thu Aug 18 10:22:52 2016 +0100
MIPS: KVM: Fix mapped fault broken commpage handling
commit c604cffa93478f8888bec62b23d6073dad03d43a upstream.
kvm_mips_handle_mapped_seg_tlb_fault() appears to map the guest page at
virtual address 0 to PFN 0 if the guest has created its own mapping
there. The intention is unclear, but it may have been an attempt to
protect the zero page from being mapped to anything but the comm page in
code paths you wouldn't expect from genuine commpage accesses (guest
kernel mode cache instructions on that address, hitting trapping
instructions when executing from that address with a coincidental TLB
eviction during the KVM handling, and guest user mode accesses to that
address).
Fix this to check for mappings exactly at KVM_GUEST_COMMPAGE_ADDR (it
may not be at address 0 since commit 42aa12e74e91 ("MIPS: KVM: Move
commpage so 0x0 is unmapped")), and set the corresponding EntryLo to be
interpreted as 0 (invalid).
Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[james.hogan@imgtec.com: Backport to v3.10.y - v3.15.y]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e38c381e0cc02c7d12d1659dcba5d31a96fee41
Author: Theodore Ts'o <tytso@mit.edu>
Date: Mon Jun 13 10:10:51 2016 -0400
random: print a warning for the first ten uninitialized random users
commit 9b4d008787f864f17d008c9c15bbe8a0f7e2fc24 upstream.
Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot. So print the first ten such
complaints instead.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b62a2dd877df2d7372d8762cd151661a591c3002
Author: Pavel Shilovsky <pshilovsky@samba.org>
Date: Sun Jul 24 10:37:38 2016 +0300
CIFS: Fix a possible invalid memory access in smb2_query_symlink()
commit 7893242e2465aea6f2cbc2639da8fa5ce96e8cc2 upstream.
During following a symbolic link we received err_buf from SMB2_open().
While the validity of SMB2 error response is checked previously
in smb2_check_message() a symbolic link payload is not checked at all.
Fix it by adding such checks.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c05dc3703bf9ab3c34fd3fb4ea88e2723d20a8d4
Author: Rabin Vincent <rabinv@axis.com>
Date: Tue Jul 19 09:26:21 2016 +0200
cifs: fix crash due to race in hmac(md5) handling
commit bd975d1eead2558b76e1079e861eacf1f678b73b upstream.
The secmech hmac(md5) structures are present in the TCP_Server_Info
struct and can be shared among multiple CIFS sessions. However, the
server mutex is not currently held when these structures are allocated
and used, which can lead to a kernel crashes, as in the scenario below:
mount.cifs(8) #1 mount.cifs(8) #2
Is secmech.sdeschmaccmd5 allocated?
// false
Is secmech.sdeschmaccmd5 allocated?
// false
secmech.hmacmd = crypto_alloc_shash..
secmech.sdeschmaccmd5 = kzalloc..
sdeschmaccmd5->shash.tfm = &secmec.hmacmd;
secmech.sdeschmaccmd5 = kzalloc
// sdeschmaccmd5->shash.tfm
// not yet assigned
crypto_shash_update()
deref NULL sdeschmaccmd5->shash.tfm
Unable to handle kernel paging request at virtual address 00000030
epc : 8027ba34 crypto_shash_update+0x38/0x158
ra : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84
Call Trace:
crypto_shash_update+0x38/0x158
setup_ntlmv2_rsp+0x4bc/0xa84
build_ntlmssp_auth_blob+0xbc/0x34c
sess_auth_rawntlmssp_authenticate+0xac/0x248
CIFS_SessSetup+0xf0/0x178
cifs_setup_session+0x4c/0x84
cifs_get_smb_ses+0x2c8/0x314
cifs_mount+0x38c/0x76c
cifs_do_mount+0x98/0x440
mount_fs+0x20/0xc0
vfs_kern_mount+0x58/0x138
do_mount+0x1e8/0xccc
SyS_mount+0x88/0xd4
syscall_common+0x30/0x54
Fix this by locking the srv_mutex around the code which uses these
hmac(md5) structures. All the other secmech algos already have similar
locking.
Fixes: 95dc8dd14e2e84cc ("Limit allocation of crypto mechanisms to dialect which requires")
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Acked-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 30d6d4f221b089022a33e274b31c68840a5f4310
Author: Sachin Prabhu <sprabhu@redhat.com>
Date: Thu Jul 7 21:28:27 2016 +0100
cifs: Check for existing directory when opening file with O_CREAT
commit 8d9535b6efd86e6c07da59f97e68f44efb7fe080 upstream.
When opening a file with O_CREAT flag, check to see if the file opened
is an existing directory.
This prevents the directory from being opened which subsequently causes
a crash when the close function for directories cifs_closedir() is called
which frees up the file->private_data memory while the file is still
listed on the open file list for the tcon.
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Reported-by: Xiaoli Feng <xifeng@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aed5492f1739b5e57046ef80afc812b7a907f1e3
Author: Amadeusz Sławiński <amadeusz.slawinski@tieto.com>
Date: Thu Jul 14 10:50:23 2016 +0200
Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU
commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.
When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.
Signed-off-by: Amadeusz Sławiński <amadeusz.slawinski@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8b536a40302d6db1001b43780d16cffde322a86
Author: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Tue May 3 16:27:17 2016 -0400
s5p-mfc: Add release callback for memory region devs
commit 6311f1261f59ce5e51fbe5cc3b5e7737197316ac upstream.
When s5p_mfc_remove() calls put_device() for the reserved memory region
devs, the driver core warns that the dev doesn't have a release callback:
WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
Also, the declared DMA memory using dma_declare_coherent_memory() isn't
relased so add a dev .release that calls dma_release_declared_memory().
Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 822a46606ec7573f4d0fd375f5ce1e7f94084fe1
Author: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Tue May 3 16:27:16 2016 -0400
s5p-mfc: Set device name for reserved memory region devs
commit 29debab0a94035a390801d1f177d171d014b7765 upstream.
The devices don't have a name set, so makes dev_name() returns NULL which
makes harder to identify the devices that are causing issues, for example:
WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90
Device '(null)' does not have a release() function, it is broken and must be fixed.
And after setting the device name:
WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fdde7535944f96fbb15f5c7256b311e5ea91af71
Author: Alex Hung <alex.hung@canonical.com>
Date: Mon Jun 13 19:44:00 2016 +0800
hp-wmi: Fix wifi cannot be hard-unblocked
commit fc8a601e1175ae351f662506030f9939cb7fdbfe upstream.
Several users reported wifi cannot be unblocked as discussed in [1].
This patch removes the use of the 2009 flag by BIOS but uses the actual
WMI function calls - it will be skipped if WMI reports unsupported.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=69131
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Tested-by: Evgenii Shatokhin <eugene.shatokhin@yandex.ru>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f8a872a7a2d16ad3193f3925620c27b0c7d0e03
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Jul 6 12:50:12 2016 +0300
gpio: intel-mid: Remove potentially harmful code
commit 3dbd3212f81b2b410a34a922055e2da792864829 upstream.
The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
doesn't look at all as a proper support for Intel Merrifield and I dare to say
that it distorts the behaviour of the hardware.
The register map is different on Intel Merrifield, i.e. only 6 out of 8
register have the same purpose but none of them has same location in the
address space. The current case potentially harmful to existing hardware since
it's poking registers on wrong offsets and may set some pin to be GPIO output
when connected hardware doesn't expect such.
Besides the above GPIO and pinctrl on Intel Merrifield have been located in
different IP blocks. The functionality has been extended as well, i.e. added
support of level interrupts, special registers for wake capable sources and
thus, in my opinion, requires a completele separate driver.
If someone wondering the existing gpio-intel-mid.c would be converted to actual
pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
that.
Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4b2ccfc2fc3460c62977681e06a67424dafdcf5c
Author: Vignesh R <vigneshr@ti.com>
Date: Thu Jun 9 11:02:04 2016 +0530
gpio: pca953x: Fix NBANK calculation for PCA9536
commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 upstream.
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f12e6c0fc0db556f84e6a926a7ab413c5d5552b
Author: Daniele Palmas <dnlplm@gmail.com>
Date: Mon Jun 6 12:38:17 2016 +0200
USB: serial: option: add support for Telit LE910 PID 0x1206
commit 3c0415fa08548e3bc63ef741762664497ab187ed upstream.
This patch adds support for 0x1206 PID of Telit LE910.
Since the interfaces positions are the same than the ones for
0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 018ec30216fdff75d2909f32abfc47a05eec5aa8
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed Jun 8 16:32:50 2016 +0900
usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()
commit 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 upstream.
This patch fixes an issue that the CFIFOSEL register value is possible
to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer
using CFIFO may not work correctly.
For example:
# modprobe g_multi file=usb-storage.bin
# ifconfig usb0 192.168.1.1 up
(During the USB host is sending file to the mass storage)
# ifconfig usb0 down
In this case, since the u_ether.c may call usb_ep_enable() in
eth_stop(), if the renesas_usbhs driver is also using CFIFO for
mass storage, the mass storage may not work correctly.
So, this patch adds usbhs_lock() and usbhs_unlock() calling in
usbhsg_ep_enable() to protect CFIFOSEL register. This is because:
- CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration
- The CFIFOSEL (fifo->sel) is already protected by usbhs_lock()
Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 90c1d870edc3fde05fdeb7b856b1dab2de86009c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed Aug 17 10:00:14 2016 +0200
tcp: make challenge acks faster
When backporting upstream commit 75ff39ccc1bd ("tcp: make challenge acks
less predictable") I negelected to use the correct ACCESS* type macros.
This fixes that up to hopefully speed things up a bit more.
Thanks to Chas Wiliams for the 3.10 backport which reminded me of this.
Cc: Yue Cao <ycao009@ucr.edu>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Chas Williams <ciwillia@brocade.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>