Ben Skeggs [Tue, 25 Jul 2017 01:06:47 +0000 (11:06 +1000)]
drm/nouveau/bar/gf100: fix access to upper half of BAR2
commit
38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.
Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.
We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.
This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
Shout-out to NVIDIA for the quick response with the potential cause!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Mirkin [Wed, 28 Jun 2017 12:24:45 +0000 (08:24 -0400)]
drm/nouveau/disp/nv50-: bump max chans to 21
commit
a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.
GP102's cursors go from chan 17..20. Increase the array size to hold
their data properly.
Fixes:
e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sinclair Yeh [Tue, 18 Jul 2017 06:28:36 +0000 (23:28 -0700)]
drm/vmwgfx: Fix gcc-7.1.1 warning
commit
fcfffdd8f98ac305285dca568b5065ef86be6458 upstream.
The current code does not look correct, and the reason for it is
probably lost. Since this now generates a compiler warning,
fix it to what makes sense.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ofer Heifetz [Mon, 24 Jul 2017 06:17:40 +0000 (09:17 +0300)]
md/raid5: add thread_group worker async_tx_issue_pending_all
commit
7e96d559634b73a8158ee99a7abece2eacec2668 upstream.
Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.
Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.
Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.
Signed-off-by: Ofer Heifetz <oferh@marvell.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Fri, 21 Jul 2017 03:57:14 +0000 (13:57 +1000)]
KVM: PPC: Book3S HV: Enable TM before accessing TM registers
commit
e47057151422a67ce08747176fa21cb3b526a2c9 upstream.
Commit
46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state
properly", 2017-06-15) added code to read transactional memory (TM)
registers but forgot to enable TM before doing so. The result is
that if userspace does have live values in the TM registers, a KVM_RUN
ioctl will cause a host kernel crash like this:
[ 181.328511] Unrecoverable TM Unavailable Exception f60 at
d00000001e7d9980
[ 181.328605] Oops: Unrecoverable TM Unavailable Exception, sig: 6 [#1]
[ 181.328613] SMP NR_CPUS=2048
[ 181.328613] NUMA
[ 181.328618] PowerNV
[ 181.328646] Modules linked in: vhost_net vhost tap nfs_layout_nfsv41_files rpcsec_gss_krb5 nfsv4 dns_resolver nfs
+fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
+nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun ebtable_filter ebtables
+ip6table_filter ip6_tables iptable_filter bridge stp llc kvm_hv kvm nfsd ses enclosure scsi_transport_sas ghash_generic
+auth_rpcgss gf128mul xts sg ctr nfs_acl lockd vmx_crypto shpchp ipmi_powernv i2c_opal grace ipmi_devintf i2c_core
+powernv_rng sunrpc ipmi_msghandler ibmpowernv uio_pdrv_genirq uio leds_powernv powernv_op_panel ip_tables xfs sd_mod
+lpfc ipr bnx2x libata mdio ptp pps_core scsi_transport_fc libcrc32c dm_mirror dm_region_hash dm_log dm_mod
[ 181.329278] CPU: 40 PID: 9926 Comm: CPU 0/KVM Not tainted 4.12.0+ #1
[ 181.329337] task:
c000003fc6980000 task.stack:
c000003fe4d80000
[ 181.329396] NIP:
d00000001e7d9980 LR:
d00000001e77381c CTR:
d00000001e7d98f0
[ 181.329465] REGS:
c000003fe4d837e0 TRAP: 0f60 Not tainted (4.12.0+)
[ 181.329523] MSR:
9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
[ 181.329527] CR:
24022448 XER:
00000000
[ 181.329608] CFAR:
d00000001e773818 SOFTE: 1
[ 181.329608] GPR00:
d00000001e77381c c000003fe4d83a60 d00000001e7ef410 c000003fdcfe0000
[ 181.329608] GPR04:
c000003fe4f00000 0000000000000000 0000000000000000 c000003fd7954800
[ 181.329608] GPR08:
0000000000000001 c000003fc6980000 0000000000000000 d00000001e7e2880
[ 181.329608] GPR12:
d00000001e7d98f0 c000000007b19000 00000001295220e0 00007fffc0ce2090
[ 181.329608] GPR16:
0000010011886608 00007fff8c89f260 0000000000000001 00007fff8c080028
[ 181.329608] GPR20:
0000000000000000 00000100118500a6 0000010011850000 0000010011850000
[ 181.329608] GPR24:
00007fffc0ce1b48 0000010011850000 00000000d673b901 0000000000000000
[ 181.329608] GPR28:
0000000000000000 c000003fdcfe0000 c000003fdcfe0000 c000003fe4f00000
[ 181.330199] NIP [
d00000001e7d9980] kvmppc_vcpu_run_hv+0x90/0x6b0 [kvm_hv]
[ 181.330264] LR [
d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
[ 181.330322] Call Trace:
[ 181.330351] [
c000003fe4d83a60] [
d00000001e773478] kvmppc_set_one_reg+0x48/0x340 [kvm] (unreliable)
[ 181.330437] [
c000003fe4d83b30] [
d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
[ 181.330513] [
c000003fe4d83b50] [
d00000001e7700b4] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
[ 181.330586] [
c000003fe4d83bd0] [
d00000001e7642f8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
[ 181.330658] [
c000003fe4d83d40] [
c0000000003451b8] do_vfs_ioctl+0xc8/0x8b0
[ 181.330717] [
c000003fe4d83de0] [
c000000000345a64] SyS_ioctl+0xc4/0x120
[ 181.330776] [
c000003fe4d83e30] [
c00000000000b004] system_call+0x58/0x6c
[ 181.330833] Instruction dump:
[ 181.330869]
e92d0260 e9290b50 e9290108 792807e3 41820058 e92d0260 e9290b50 e9290108
[ 181.330941]
792ae8a4 794a1f87 408204f4 e92d0260 <
7d4022a6>
f9490ff0 e92d0260 7d4122a6
[ 181.331013] ---[ end trace
6f6ddeb4bfe92a92 ]---
The fix is just to turn on the TM bit in the MSR before accessing the
registers.
Fixes:
46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu [Mon, 17 Jul 2017 07:32:30 +0000 (15:32 +0800)]
crypto: authencesn - Fix digest_null crash
commit
41cdf7a45389e01991ee31e3301ed83cb3e3f7dc upstream.
When authencesn is used together with digest_null a crash will
occur on the decrypt path. This is because normally we perform
a special setup to preserve the ESN, but this is skipped if there
is no authentication. However, on the post-authentication path
it always expects the preservation to be in place, thus causing
a crash when digest_null is used.
This patch fixes this by also skipping the post-processing when
there is no authentication.
Fixes:
104880a6b470 ("crypto: authencesn - Convert to new AEAD...")
Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Coddington [Fri, 28 Jul 2017 16:33:54 +0000 (12:33 -0400)]
NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter
commit
b7dbcc0e433f0f61acb89ed9861ec996be4f2b38 upstream.
nfs4_retry_setlk() sets the task's state to TASK_INTERRUPTIBLE within the
same region protected by the wait_queue's lock after checking for a
notification from CB_NOTIFY_LOCK callback. However, after releasing that
lock, a wakeup for that task may race in before the call to
freezable_schedule_timeout_interruptible() and set TASK_WAKING, then
freezable_schedule_timeout_interruptible() will set the state back to
TASK_INTERRUPTIBLE before the task will sleep. The result is that the task
will sleep for the entire duration of the timeout.
Since we've already set TASK_INTERRUPTIBLE in the locked section, just use
freezable_schedule_timout() instead.
Fixes:
a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Mon, 24 Jul 2017 03:18:50 +0000 (13:18 +1000)]
NFS: invalidate file size when taking a lock.
commit
442ce0499c0535f8972b68fa1fda357357a5c953 upstream.
Prior to commit
ca0daa277aca ("NFS: Cache aggressively when file is open
for writing"), NFS would revalidate, or invalidate, the file size when
taking a lock. Since that commit it only invalidates the file content.
If the file size is changed on the server while wait for the lock, the
client will have an incorrect understanding of the file size and could
corrupt data. This particularly happens when writing beyond the
(supposed) end of file and can be easily be demonstrated with
posix_fallocate().
If an application opens an empty file, waits for a write lock, and then
calls posix_fallocate(), glibc will determine that the underlying
filesystem doesn't support fallocate (assuming version 4.1 or earlier)
and will write out a '0' byte at the end of each 4K page in the region
being fallocated that is after the end of the file.
NFS will (usually) detect that these writes are beyond EOF and will
expand them to cover the whole page, and then will merge the pages.
Consequently, NFS will write out large blocks of zeroes beyond where it
thought EOF was. If EOF had moved, the pre-existing part of the file
will be over-written. Locking should have protected against this,
but it doesn't.
This patch restores the use of nfs_zap_caches() which invalidated the
cached attributes. When posix_fallocate() asks for the file size, the
request will go to the server and get a correct answer.
Fixes:
ca0daa277aca ("NFS: Cache aggressively when file is open for writing")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Vivier [Fri, 21 Jul 2017 14:51:39 +0000 (16:51 +0200)]
powerpc/pseries: Fix of_node_put() underflow during reconfig remove
commit
4fd1bd443e80b12f0a01a45fb9a793206b41cb72 upstream.
As for commit
68baf692c435 ("powerpc/pseries: Fix of_node_put()
underflow during DLPAR remove"), the call to of_node_put() must be
removed from pSeries_reconfig_remove_node().
dlpar_detach_node() and pSeries_reconfig_remove_node() both call
of_detach_node(), and thus the node should not be released in both
cases.
Fixes:
0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Tue, 25 Jul 2017 19:41:41 +0000 (21:41 +0200)]
parisc: Suspend lockup detectors before system halt
commit
56188832a50f09998cb570ba3771a1d25c193c0e upstream.
Some machines can't power off the machine, so disable the lockup detectors to
avoid this watchdog BUG to show up every few seconds:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1]
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John David Anglin [Tue, 25 Jul 2017 21:23:35 +0000 (17:23 -0400)]
parisc: Extend disabled preemption in copy_user_page
commit
56008c04ebc099940021b714da2d7779117cf6a7 upstream.
It's always bothered me that we only disable preemption in
copy_user_page around the call to flush_dcache_page_asm.
This patch extends this to after the copy.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John David Anglin [Tue, 25 Jul 2017 21:11:26 +0000 (17:11 -0400)]
parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases
commit
ae7a609c34b6fb12328c553b5f9aab26ae74a28e upstream.
Helge noticed that we flush the TLB page in flush_cache_page but not in
flush_cache_range or flush_cache_mm.
For a long time, we have had random segmentation faults building
packages on machines with PA8800/8900 processors. These machines only
support equivalent aliases. We don't see these faults on machines that
don't require strict coherency. So, it appears TLB speculation
sometimes leads to cache corruption on machines that require coherency.
This patch adds TLB flushes to flush_cache_range and flush_cache_mm when
coherency is required. We only flush the TLB in flush_cache_page when
coherency is required.
The patch also optimizes flush_cache_range. It turns out we always have
the right context to use flush_user_dcache_range_asm and
flush_user_icache_range_asm.
The patch has been tested for some time on rp3440, rp3410 and A500-44.
It's been boot tested on c8000. No random segmentation faults were
observed during testing.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Dadap [Fri, 14 Jul 2017 00:27:39 +0000 (19:27 -0500)]
ALSA: hda - Add missing NVIDIA GPU codec IDs to patch table
commit
74ec118152ea494a25ebb677cbc83a75c982ac5f upstream.
Add codec IDs for several recently released, pending, and historical
NVIDIA GPU audio controllers to the patch table, to allow the correct
patch functions to be selected for them.
Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Shevchenko [Sun, 16 Jul 2017 18:40:03 +0000 (21:40 +0300)]
ALSA: fm801: Initialize chip after IRQ handler is registered
commit
610e1ae9b533be82b3aa118b907e0a703256913d upstream.
The commit
b56fa687e02b ("ALSA: fm801: detect FM-only card earlier")
rearranged initialization calls, i.e. it makes snd_fm801_chip_init() to
be called before we register interrupt handler and set PCI bus
mastering.
Somehow it prevents FM801-AU to work properly. Thus, partially revert
initialization order changed by commit mentioned above.
Fixes:
b56fa687e02b ("ALSA: fm801: detect FM-only card earlier")
Reported-by: Émeric MASCHINO <emeric.maschino@gmail.com>
Tested-by: Émeric MASCHINO <emeric.maschino@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 22 Jun 2017 13:31:10 +0000 (15:31 +0200)]
jfs: Don't clear SGID when inheriting ACLs
commit
9bcf66c72d726322441ec82962994e69157613e4 upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by moving posix_acl_update_mode() out of
__jfs_set_acl() into jfs_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
CC: jfs-discussion@lists.sourceforge.net
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 31 Jan 2017 18:20:32 +0000 (10:20 -0800)]
net: reduce skb_warn_bad_offload() noise
commit
b2504a5dbef3305ef41988ad270b0e8ec289331c upstream.
Dmitry reported warnings occurring in __skb_gso_segment() [1]
All SKB_GSO_DODGY producers can allow user space to feed
packets that trigger the current check.
We could prevent them from doing so, rejecting packets, but
this might add regressions to existing programs.
It turns out our SKB_GSO_DODGY handlers properly set up checksum
information that is needed anyway when packets needs to be segmented.
By checking again skb_needs_check() after skb_mac_gso_segment(),
we should remove these pesky warnings, at a very minor cost.
With help from Willem de Bruijn
[1]
WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
Call Trace:
[<
ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
[<
ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
[<
ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
[<
ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
[<
ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
[<
ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
[<
ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
[<
ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
[<
ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
[<
ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
[<
ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
[<
ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
[<
ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
[<
ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
[<
ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
[<
ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
[<
ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
[<
ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
[<
ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
[<
ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joel Fernandes [Thu, 20 Oct 2016 07:34:00 +0000 (00:34 -0700)]
pstore: Make spinlock per zone instead of global
commit
109704492ef637956265ec2eb72ae7b3b39eb6f4 upstream.
Currently pstore has a global spinlock for all zones. Since the zones
are independent and modify different areas of memory, there's no need
to have a global lock, so we should use a per-zone lock as introduced
here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
introduced later, which splits the ftrace memory area into a single zone
per CPU, it will eliminate the need for locking. In preparation for this,
make the locking optional.
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: updated commit message]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuejie Shi [Fri, 31 Mar 2017 07:10:20 +0000 (15:10 +0800)]
af_key: Add lock to key dump
commit
89e357d83c06b6fac581c3ca7f0ee3ae7e67109e upstream.
A dump may come in the middle of another dump, modifying its dump
structure members. This race condition will result in NULL pointer
dereference in kernel. So add a lock to prevent that race.
Fixes:
83321d6b9872 ("[AF_KEY]: Dump SA/SP entries non-atomically")
Signed-off-by: Yuejie Shi <syjcnss@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 27 Jul 2017 22:08:24 +0000 (15:08 -0700)]
Linux 4.9.40
Greg Hackmann [Mon, 24 Jul 2017 17:19:24 +0000 (10:19 -0700)]
alarmtimer: don't rate limit one-shot timers
Commit
ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a
minimum bound on the alarm timer interval. This minimum bound shouldn't
be applied if the interval is 0. Otherwise, one-shot timers will be
converted into periodic ones.
Fixes:
ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals")
Reported-by: Ben Fennema <fennema@google.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Cc: stable@vger.kernel.org
Cc: John Stultz <john.stultz@linaro.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunyu Hu [Thu, 20 Jul 2017 10:36:09 +0000 (18:36 +0800)]
tracing: Fix kmemleak in instance_rmdir
commit
db9108e054700c96322b0f0028546aa4e643cf0b upstream.
Hit the kmemleak when executing instance_rmdir, it forgot releasing
mem of tracing_cpumask. With this fix, the warn does not appear any
more.
unreferenced object 0xffff93a8dfaa7c18 (size 8):
comm "mkdir", pid 1436, jiffies
4294763622 (age 9134.308s)
hex dump (first 8 bytes):
ff ff ff ff ff ff ff ff ........
backtrace:
[<
ffffffff88b6567a>] kmemleak_alloc+0x4a/0xa0
[<
ffffffff8861ea41>] __kmalloc_node+0xf1/0x280
[<
ffffffff88b505d3>] alloc_cpumask_var_node+0x23/0x30
[<
ffffffff88b5060e>] alloc_cpumask_var+0xe/0x10
[<
ffffffff88571ab0>] instance_mkdir+0x90/0x240
[<
ffffffff886e5100>] tracefs_syscall_mkdir+0x40/0x70
[<
ffffffff886565c9>] vfs_mkdir+0x109/0x1b0
[<
ffffffff8865b1d0>] SyS_mkdir+0xd0/0x100
[<
ffffffff88403857>] do_syscall_64+0x67/0x150
[<
ffffffff88b710e7>] return_from_SYSCALL_64+0x0/0x6a
[<
ffffffffffffffff>] 0xffffffffffffffff
Link: http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-chuhu@redhat.com
Fixes:
ccfe9e42e451 ("tracing: Make tracing_cpumask available for all instances")
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Fri, 14 Jul 2017 10:51:48 +0000 (11:51 +0100)]
PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present
commit
975e83cfb8dc16e7a2fdc58188c77c0c605876c2 upstream.
If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach
may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets
the PM domain for the device unconditionally.
When subsequent attempts are made to call genpd_dev_pm_attach, it may
return -EEXISTS checking dev->pm_domain without re-attempting to call
attach_dev or power_on.
platform_drv_probe then attempts to call drv->probe as the return value
-EEXIST != -EPROBE_DEFER, which may end up in a situation where the
device is accessed without it's power domain switched on.
Fixes:
f104e1e5ef57 (PM / Domains: Re-order initialization of generic_pm_domain_data)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 22 Jun 2017 07:32:49 +0000 (09:32 +0200)]
reiserfs: Don't clear SGID when inheriting ACLs
commit
6883cd7f68245e43e91e5ee583b7550abf14523f upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by moving posix_acl_update_mode() out of
__reiserfs_set_acl() into reiserfs_set_acl(). That way the function will
not be called when inheriting ACLs which is what we want as it prevents
SGID bit clearing and the mode has been properly set by
posix_acl_create() anyway.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
CC: reiserfs-devel@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Andersson [Thu, 29 Jun 2017 21:46:44 +0000 (14:46 -0700)]
spmi: Include OF based modalias in device uevent
commit
d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream.
Include the OF-based modalias in the uevent sent when registering SPMI
devices, so that user space has a chance to autoload the kernel module
for the device.
Tested-by: Rob Clark <robdclark@gmail.com>
Reported-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Wed, 28 Dec 2016 22:56:48 +0000 (14:56 -0800)]
of: device: Export of_device_{get_modalias, uvent_modalias} to modules
commit
7a3b7cd332db08546f3cdd984f11773e0d1999e7 upstream.
The ULPI bus can be built as a module, and it will soon be
calling these functions when it supports probing devices from DT.
Export them so they can be used by the ULPI module.
Acked-by: Rob Herring <robh@kernel.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prarit Bhargava [Wed, 31 May 2017 17:32:00 +0000 (13:32 -0400)]
acpi/nfit: Fix memory corruption/Unregister mce decoder on failure
commit
7e700d2c59e5853c9126642976b4f5768f64c9b3 upstream.
nfit_init() calls nfit_mce_register() on module load. When the module
load fails the nfit mce decoder is not unregistered. The module's
memory is freed leaving the decoder chain referencing junk. This will
cause panics as future registrations will reference the free'd memory.
Unregister the nfit mce decoder on module init failure.
[v2]: register and then unregister mce handler to avoid losing mce events
[v3]: also cleanup nfit workqueue
Fixes:
6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
Cc: Linda Knippers <linda.knippers@hpe.com>
Cc: lszubowi@redhat.com
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amir Goldstein [Tue, 11 Jul 2017 12:58:35 +0000 (15:58 +0300)]
ovl: fix random return value on mount
commit
8fc646b44385ff0a9853f6590497e43049eeb311 upstream.
On failure to prepare_creds(), mount fails with a random
return value, as err was last set to an integer cast of
a valid lower mnt pointer or set to 0 if inodes index feature
is enabled.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes:
3fe6e52f0626 ("ovl: override creds with the ones from ...")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 21 Jun 2017 13:02:47 +0000 (15:02 +0200)]
hfsplus: Don't clear SGID when inheriting ACLs
commit
84969465ddc4f8aeb3b993123b571aa01c5f2683 upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by creating __hfsplus_set_posix_acl() function that does
not call posix_acl_update_mode() and use it when inheriting ACLs. That
prevents SGID bit clearing and the mode has been properly set by
posix_acl_create() anyway.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Mon, 24 Apr 2017 22:15:28 +0000 (15:15 -0700)]
mlx5: Avoid that mlx5_ib_sg_to_klms() overflows the klms[] array
commit
99975cd4fda52974a767aa44fe0b1a8f74950d9d upstream.
ib_map_mr_sg() can pass an SG-list to .map_mr_sg() that is larger
than what fits into a single MR. .map_mr_sg() must not attempt to
map more SG-list elements than what fits into a single MR.
Hence make sure that mlx5_ib_sg_to_klms() does not write outside
the MR klms[] array.
Fixes:
b005d3164713 ("mlx5: Add arbitrary sg list support")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Leon Romanovsky <leonro@mellanox.com>
Cc: Israel Rukshin <israelr@mellanox.com>
Acked-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Wed, 19 Jul 2017 13:46:32 +0000 (16:46 +0300)]
drm/mst: Avoid processing partially received up/down message transactions
commit
636c4c3e762b62aa93632c645ca65879285b16e3 upstream.
Currently we may process up/down message transactions containing
uninitialized data. This can happen if there was an error during the
reception of any message in the transaction, but we happened to receive
the last message correctly with the end-of-message flag set.
To avoid this abort the reception of the transaction when the first
error is detected, rejecting any messages until a message with the
start-of-message flag is received (which will start a new transaction).
This is also what the DP 1.4 spec 2.11.8.2 calls for in this case.
In addtion this also prevents receiving bogus transactions without the
first message with the the start-of-message flag set.
v2:
- unchanged
v3:
- git add the part that actually skips messages after an error in
drm_dp_sideband_msg_build()
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719134632.13366-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Wed, 19 Jul 2017 11:43:29 +0000 (14:43 +0300)]
drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()
commit
7f8b3987da54cb4d41ad2545cd4d7958b9a36bdf upstream.
In case of an unknown broadcast message is sent mstb will remain unset,
so check for this.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-3-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Wed, 19 Jul 2017 11:43:28 +0000 (14:43 +0300)]
drm/mst: Fix error handling during MST sideband message reception
commit
448421b5e93b9177c5698f0cf6f5e72d2995eeca upstream.
Handle any error due to partial reads, timeouts etc. to avoid parsing
uninitialized data subsequently. Also bail out if the parsing itself
fails.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-2-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ismail, Mustafa [Fri, 14 Jul 2017 14:41:31 +0000 (09:41 -0500)]
RDMA/core: Initialize port_num in qp_attr
commit
a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream.
Initialize the port_num for iWARP in rdma_init_qp_attr.
Fixes:
5ecce4c9b17b("Check port number supplied by user verbs cmds")
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Thu, 6 Jul 2017 03:12:21 +0000 (11:12 +0800)]
ceph: fix race in concurrent readdir
commit
84583cfb973c4313955c6231cc9cb3772d280b15 upstream.
For a large directory, program needs to issue multiple readdir
syscalls to get all dentries. When there are multiple programs
read the directory concurrently. Following sequence of events
can happen.
- program calls readdir with pos = 2. ceph sends readdir request
to mds. The reply contains N1 entries. ceph adds these N1 entries
to readdir cache.
- program calls readdir with pos = N1+2. The readdir is satisfied
by the readdir cache, N2 entries are returned. (Other program
calls readdir in the middle, which fills the cache)
- program calls readdir with pos = N1+N2+2. ceph sends readdir
request to mds. The reply contains N3 entries and it reaches
directory end. ceph adds these N3 entries to the readdir cache
and marks directory complete.
The second readdir call does not update fi->readdir_cache_idx.
ceph add the last N3 entries to wrong places.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Sat, 15 Jul 2017 15:32:08 +0000 (11:32 -0400)]
staging: lustre: ko2iblnd: check copy_from_iter/copy_to_iter return code
commit
566e1ce22e04426fa52328b2adcdf1df49acd98e upstream.
We now get a helpful warning for code that calls copy_{from,to}_iter
without checking the return value, introduced by commit
aa28de275a24
("iov_iter/hardening: move object size checks to inlined part").
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function 'kiblnd_send':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1643:2: error: ignoring return value of 'copy_from_iter', declared with attribute warn_unused_result [-Werror=unused-result]
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function 'kiblnd_recv':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1744:3: error: ignoring return value of 'copy_to_iter', declared with attribute warn_unused_result [-Werror=unused-result]
In case we get short copies here, we may get incorrect behavior.
I've added failure handling for both rx and tx now, returning
-EFAULT as expected.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Teddy Wang [Fri, 30 Jun 2017 20:57:43 +0000 (21:57 +0100)]
staging: sm750fb: avoid conflicting vesafb
commit
740c433ec35187b45abe08bb6c45a321a791be8e upstream.
If vesafb is enabled in the config then /dev/fb0 is created by vesa
and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
effectively work with xorg.
So if it has been alloted fb1, then try to remove the other fb0.
In the previous send, why #ifdef is used was asked.
https://lkml.org/lkml/2017/6/25/57
Answered at: https://lkml.org/lkml/2017/6/25/69
Also pasting here for reference.
'Did a quick research into "why".
The patch
d8801e4df91e ("x86/PCI: Set IORESOURCE_ROM_SHADOW only for the
default VGA device") has started setting IORESOURCE_ROM_SHADOW in flags
for a default VGA device and that is being done only for x86.
And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that
needs to be checked only for a x86 and not for other arch.'
Signed-off-by: Teddy Wang <teddy.wang@siliconmotion.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 30 Jun 2017 11:02:18 +0000 (12:02 +0100)]
staging: comedi: ni_mio_common: fix AO timer off-by-one regression
commit
15d5193104a457d5151840247e3bce561c42e3e9 upstream.
As reported by Éric Piel on the Comedi mailing list (see
<https://groups.google.com/forum/#!topic/comedi_list/ueZiR7vTLOU/discussion>),
the analog output asynchronous commands are running too fast with a
period 50 ns shorter than it should be. This affects all boards with AO
command support that are supported by the "ni_pcimio", "ni_atmio", and
"ni_mio_cs" drivers.
This is a regression bug introduced by commit
080e6795cba3 ("staging:
comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd"), specifically,
this line in `ni_ao_cmd_set_update()`:
/* following line: N-1 per STC */
ni_stc_writel(dev, trigvar - 1, NISTC_AO_UI_LOADA_REG);
The `trigvar` variable value comes from a call to `ni_ns_to_timer()`
which converts a timer period in nanoseconds to a hardware divisor
value. The function already reduces the divisor by 1 as required by the
hardware, so the above line should not reduce it further by 1. Fix it
by replacing `trigvar` by `trigvar - 1` in the above line, and remove
the misleading comment.
Reported-by: Éric Piel <piel@delmic.com>
Fixes:
080e6795cba3 ("staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd")
Cc: Éric Piel <piel@delmic.com>
Cc: Spencer E. Olson <olsonse@umich.edu>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Gugino [Mon, 17 Jul 2017 17:29:09 +0000 (13:29 -0400)]
staging: rtl8188eu: add TL-WN722N v2 support
commit
5a1d4c5dd4eb2f1f8a9b30e61762f3b3b564df70 upstream.
Add support for USB Device TP-Link TL-WN722N v2.
VendorID: 0x2357, ProductID: 0x010c
Signed-off-by: Michael Gugino <michael.gugino.2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ingo Molnar [Tue, 11 Jul 2017 08:56:54 +0000 (10:56 +0200)]
Revert "perf/core: Drop kernel samples even though :u is specified"
commit
6a8a75f3235724c5941a33e287b2f98966ad14c5 upstream.
This reverts commit
cc1582c231ea041fbc68861dfaf957eaf902b829.
This commit introduced a regression that broke rr-project, which uses sampling
events to receive a signal on overflow (but does not care about the contents
of the sample). These signals are critical to the correct operation of rr.
There's been some back and forth about how to fix it - but to not keep
applications in limbo queue up a revert.
Reported-by: Kyle Huey <me@kylehuey.com>
Acked-by: Kyle Huey <me@kylehuey.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/20170628105600.GC5981@leverpostej
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jin Yao [Thu, 8 Jun 2017 06:01:44 +0000 (14:01 +0800)]
perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target
commit
80f62589fa52f530cffc50e78c0b5a2ae572d61e upstream.
When the jump instruction is displayed at the row 0 in annotate view,
the arrow is broken. An example:
16.86 │ ┌──je 82
0.01 │ movsd (%rsp),%xmm0
│ movsd 0x8(%rsp),%xmm4
│ movsd 0x8(%rsp),%xmm1
│ movsd (%rsp),%xmm3
│ divsd %xmm4,%xmm0
│ divsd %xmm3,%xmm1
│ movsd (%rsp),%xmm2
│ addsd %xmm1,%xmm0
│ addsd %xmm2,%xmm0
│ movsd %xmm0,(%rsp)
│82: sub $0x1,%ebx
83.03 │ ↑ jne 38
│ add $0x10,%rsp
│ xor %eax,%eax
│ pop %rbx
│ ← retq
The patch increments the row number before checking with 0.
Signed-off-by: Yao Jin <yao.jin@linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes:
944e1abed9e1 ("perf ui browser: Add method to draw up/down arrow line")
Link: http://lkml.kernel.org/r/1496901704-30275-1-git-send-email-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Fri, 30 Jun 2017 05:21:31 +0000 (22:21 -0700)]
iser-target: Avoid isert_conn->cm_id dereference in isert_login_recv_done
commit
fce50a2fa4e9c6e103915c351b6d4a98661341d6 upstream.
This patch fixes a NULL pointer dereference in isert_login_recv_done()
of isert_conn->cm_id due to isert_cma_handler() -> isert_connect_error()
resetting isert_conn->cm_id = NULL during a failed login attempt.
As per Sagi, we will always see the completion of all recv wrs posted
on the qp (given that we assigned a ->done handler), this is a FLUSH
error completion, we just don't get to verify that because we deref
NULL before.
The issue here, was the assumption that dereferencing the connection
cm_id is always safe, which is not true since:
commit
4a579da2586bd3b79b025947ea24ede2bbfede62
Author: Sagi Grimberg <sagig@mellanox.com>
Date: Sun Mar 29 15:52:04 2015 +0300
iser-target: Fix possible deadlock in RDMA_CM connection error
As I see it, we have a direct reference to the isert_device from
isert_conn which is the one-liner fix that we actually need like
we do in isert_rdma_read_done() and isert_rdma_write_done().
Reported-by: Andrea Righi <righi.andrea@gmail.com>
Tested-by: Andrea Righi <righi.andrea@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiang Yi [Sun, 25 Jun 2017 19:28:50 +0000 (12:28 -0700)]
target: Fix COMPARE_AND_WRITE caw_sem leak during se_cmd quiesce
commit
1d6ef276594a781686058802996e09c8550fd767 upstream.
This patch addresses a COMPARE_AND_WRITE se_device->caw_sem leak,
that would be triggered during normal se_cmd shutdown or abort
via __transport_wait_for_tasks().
This would occur because target_complete_cmd() would catch this
early and do complete_all(&cmd->t_transport_stop_comp), but since
target_complete_ok_work() or target_complete_failure_work() are
never called to invoke se_cmd->transport_complete_callback(),
the COMPARE_AND_WRITE specific callbacks never release caw_sem.
To address this special case, go ahead and release caw_sem
directly from target_complete_cmd().
(Remove '&& success' from check, to release caw_sem regardless
of scsi_status - nab)
Signed-off-by: Jiang Yi <jiangyilism@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Tue, 13 Jun 2017 14:20:25 +0000 (16:20 +0200)]
udf: Fix deadlock between writeback and udf_setsize()
commit
f2e95355891153f66d4156bf3a142c6489cd78c6 upstream.
udf_setsize() called truncate_setsize() with i_data_sem held. Thus
truncate_pagecache() called from truncate_setsize() could lock a page
under i_data_sem which can deadlock as page lock ranks below
i_data_sem - e. g. writeback can hold page lock and try to acquire
i_data_sem to map a block.
Fix the problem by moving truncate_setsize() calls from under
i_data_sem. It is safe for us to change i_size without holding
i_data_sem as all the places that depend on i_size being stable already
hold inode_lock.
Fixes:
7e49b6f2480cb9a9e7322a91592e56a5c85361f5
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Wed, 5 Jul 2017 02:22:20 +0000 (12:22 +1000)]
NFS: only invalidate dentrys that are clearly invalid.
commit
cc89684c9a265828ce061037f1f79f4a68ccd3f7 upstream.
Since commit
bafc9b754f75 ("vfs: More precise tests in d_invalidate")
in v3.18, a return of '0' from ->d_revalidate() will cause the dentry
to be invalidated even if it has filesystems mounted on or it or on a
descendant. The mounted filesystem is unmounted.
This means we need to be careful not to return 0 unless the directory
referred to truly is invalid. So -ESTALE or -ENOENT should invalidate
the directory. Other errors such a -EPERM or -ERESTARTSYS should be
returned from ->d_revalidate() so they are propagated to the caller.
A particular problem can be demonstrated by:
1/ mount an NFS filesystem using NFSv3 on /mnt
2/ mount any other filesystem on /mnt/foo
3/ ls /mnt/foo
4/ turn off network, or otherwise make the server unable to respond
5/ ls /mnt/foo &
6/ cat /proc/$!/stack # note that nfs_lookup_revalidate is in the call stack
7/ kill -9 $! # this results in -ERESTARTSYS being returned
8/ observe that /mnt/foo has been unmounted.
This patch changes nfs_lookup_revalidate() to only treat
-ESTALE from nfs_lookup_verify_inode() and
-ESTALE or -ENOENT from ->lookup()
as indicating an invalid inode. Other errors are returned.
Also nfs_check_inode_attributes() is changed to return -ESTALE rather
than -EIO. This is consistent with the error returned in similar
circumstances from nfs_update_inode().
As this bug allows any user to unmount a filesystem mounted on an NFS
filesystem, this fix is suitable for stable kernels.
Fixes:
bafc9b754f75 ("vfs: More precise tests in d_invalidate")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Sat, 10 Jun 2017 02:59:07 +0000 (04:59 +0200)]
sunrpc: use constant time memory comparison for mac
commit
15a8b93fd5690de017ce665382ea45e5d61811a4 upstream.
Otherwise, we enable a MAC forgery via timing attack.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@poochiereds.net>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moni Shoua [Tue, 23 May 2017 07:48:44 +0000 (10:48 +0300)]
IB/core: Namespace is mandatory input for address resolution
commit
bebb2a473a43c8f84a8210687d1cbdde503046d7 upstream.
In function addr_resolve() the namespace is a required input parameter
and not an output. It is passed later for searching the routing table
and device addresses. Also, it shouldn't be copied back to the caller.
Fixes:
565edd1d5555 ('IB/addr: Pass network namespace as a parameter')
Signed-off-by: Moni Shoua <monis@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>
Vladimir Neyelov [Sun, 21 May 2017 16:17:31 +0000 (19:17 +0300)]
IB/iser: Fix connection teardown race condition
commit
c8c16d3bae967f1c7af541e8d016e5c51e4f010a upstream.
Under heavy iser target(scst) start/stop stress during login/logout
on iser intitiator side happened trace call provided below.
The function iscsi_iser_slave_alloc iser_conn pointer could be NULL,
due to the fact that function iscsi_iser_conn_stop can be called before
and free iser connection. Let's protect that flow by introducing global mutex.
BUG: unable to handle kernel paging request at
0000000000001018
IP: [<
ffffffffc0426f7e>] iscsi_iser_slave_alloc+0x1e/0x50 [ib_iser]
Call Trace:
? scsi_alloc_sdev+0x242/0x300
scsi_probe_and_add_lun+0x9e1/0xea0
? kfree_const+0x21/0x30
? kobject_set_name_vargs+0x76/0x90
? __pm_runtime_resume+0x5b/0x70
__scsi_scan_target+0xf6/0x250
scsi_scan_target+0xea/0x100
iscsi_user_scan_session.part.13+0x101/0x130 [scsi_transport_iscsi]
? iscsi_user_scan_session.part.13+0x130/0x130 [scsi_transport_iscsi]
iscsi_user_scan_session+0x1e/0x30 [scsi_transport_iscsi]
device_for_each_child+0x50/0x90
iscsi_user_scan+0x44/0x60 [scsi_transport_iscsi]
store_scan+0xa8/0x100
? common_file_perm+0x5d/0x1c0
dev_attr_store+0x18/0x30
sysfs_kf_write+0x37/0x40
kernfs_fop_write+0x12c/0x1c0
__vfs_write+0x18/0x40
vfs_write+0xb5/0x1a0
SyS_write+0x55/0xc0
Fixes:
318d311e8f01 ("iser: Accept arbitrary sg lists mapping if the device supports it")
Signed-off-by: Vladimir Neyelov <vladimirn@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Sagi Grimberg <sagi@grimbeg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen Hong [Sun, 2 Jul 2017 22:11:10 +0000 (15:11 -0700)]
Input: i8042 - fix crash at boot time
commit
340d394a789518018f834ff70f7534fc463d3226 upstream.
The driver checks port->exists twice in i8042_interrupt(), first when
trying to assign temporary "serio" variable, and second time when deciding
whether it should call serio_interrupt(). The value of port->exists may
change between the 2 checks, and we may end up calling serio_interrupt()
with a NULL pointer:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000050
IP: [<
ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40
PGD 0
Oops: 0002 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:[<
ffffffff8150feaf>] [<
ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40
RSP: 0018:
ffff880028203cc0 EFLAGS:
00010082
RAX:
0000000000010000 RBX:
0000000000000000 RCX:
0000000000000000
RDX:
0000000000000282 RSI:
0000000000000098 RDI:
0000000000000050
RBP:
ffff880028203cc0 R08:
ffff88013e79c000 R09:
ffff880028203ee0
R10:
0000000000000298 R11:
0000000000000282 R12:
0000000000000050
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000098
FS:
0000000000000000(0000) GS:
ffff880028200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
CR2:
0000000000000050 CR3:
0000000001a85000 CR4:
00000000001407f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process swapper (pid: 1, threadinfo
ffff88013e79c000, task
ffff88013e79b500)
Stack:
ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000
<d>
0000000000000000 0000000000000000 0000000000000000 0000000000000098
<d>
ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac
Call Trace:
<IRQ>
[<
ffffffff813de186>] serio_interrupt+0x36/0xa0
[<
ffffffff813e0162>] i8042_interrupt+0x132/0x3a0
[<
ffffffff8103b8ac>] ? kvm_clock_read+0x1c/0x20
[<
ffffffff8103b8b9>] ? kvm_clock_get_cycles+0x9/0x10
[<
ffffffff810e1640>] handle_IRQ_event+0x60/0x170
[<
ffffffff8103b154>] ? kvm_guest_apic_eoi_write+0x44/0x50
[<
ffffffff810e3d8e>] handle_edge_irq+0xde/0x180
[<
ffffffff8100de89>] handle_irq+0x49/0xa0
[<
ffffffff81516c8c>] do_IRQ+0x6c/0xf0
[<
ffffffff8100b9d3>] ret_from_intr+0x0/0x11
[<
ffffffff81076f63>] ? __do_softirq+0x73/0x1e0
[<
ffffffff8109b75b>] ? hrtimer_interrupt+0x14b/0x260
[<
ffffffff8100c1cc>] ? call_softirq+0x1c/0x30
[<
ffffffff8100de05>] ? do_softirq+0x65/0xa0
[<
ffffffff81076d95>] ? irq_exit+0x85/0x90
[<
ffffffff81516d80>] ? smp_apic_timer_interrupt+0x70/0x9b
[<
ffffffff8100bb93>] ? apic_timer_interrupt+0x13/0x20
To avoid the issue let's change the second check to test whether serio is
NULL or not.
Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of
trying to be overly smart and using memory barriers.
Signed-off-by: Chen Hong <chenhong3@huawei.com>
[dtor: take lock in i8042_start()/i8042_stop()]
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:15:22 +0000 (00:15 +0100)]
MIPS: Fix a typo: s/preset/present/ in r2-to-r6 emulation error message
commit
27fe2200dad2de8207a694024a7b9037dff1b280 upstream.
This is a user-visible message, so we want it to be spelled correctly.
Fixes:
5f9f41c474be ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16400/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:14:12 +0000 (00:14 +0100)]
MIPS: Send SIGILL for R6 branches in `__compute_return_epc_for_insn'
commit
a60b1a5bf88a250f1a77977c0224e502c901c77b upstream.
Fix:
* commit
8467ca0122e2 ("MIPS: Emulate the new MIPS R6 branch compact
(BC) instruction"),
* commit
84fef630127a ("MIPS: Emulate the new MIPS R6 BALC
instruction"),
* commit
69b9a2fd05a3 ("MIPS: Emulate the new MIPS R6 BEQZC and JIC
instructions"),
* commit
28d6f93d201d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC
instructions"),
* commit
c893ce38b265 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and
BEQZALC instructions")
and send SIGILL rather than returning -SIGILL for R6 branch and jump
instructions. Returning -SIGILL is never correct as the API defines
this function's result upon error to be -EFAULT and a signal actually
issued.
Fixes:
8467ca0122e2 ("MIPS: Emulate the new MIPS R6 branch compact (BC) instruction")
Fixes:
84fef630127a ("MIPS: Emulate the new MIPS R6 BALC instruction")
Fixes:
69b9a2fd05a3 ("MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions")
Fixes:
28d6f93d201d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions")
Fixes:
c893ce38b265 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16399/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:12:53 +0000 (00:12 +0100)]
MIPS: Send SIGILL for linked branches in `__compute_return_epc_for_insn'
commit
fef40be6da856afead4177aaa9d869a66fb3381f upstream.
Fix commit
319824eabc3f ("MIPS: kernel: branch: Do not emulate the
branch likelies on MIPS R6") and also send SIGILL rather than returning
-SIGILL for BLTZAL, BLTZALL, BGEZAL and BGEZALL instruction encodings no
longer supported in R6, except where emulated. Returning -SIGILL is
never correct as the API defines this function's result upon error to be
-EFAULT and a signal actually issued.
Fixes:
319824eabc3f ("MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16398/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:09:23 +0000 (00:09 +0100)]
MIPS: Rename `sigill_r6' to `sigill_r2r6' in `__compute_return_epc_for_insn'
commit
1f4edde422961397cf4470b347958c13c6a740bb upstream.
Use the more accurate `sigill_r2r6' name for the label used in the case
of sending SIGILL in the absence of the instruction emulator for an
earlier ISA level instruction that has been removed as from the R6 ISA,
so that the `sigill_r6' name is freed for the situation where an R6
instruction is not supposed to be interpreted, because the executing
processor does not support the R6 ISA.
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16397/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:08:29 +0000 (00:08 +0100)]
MIPS: Send SIGILL for BPOSGE32 in `__compute_return_epc_for_insn'
commit
7b82c1058ac1f8f8b9f2b8786b1f710a57a870a8 upstream.
Fix commit
e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") and
send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP
ASE instruction has been encountered in `__compute_return_epc_for_insn'
as our Reserved Instruction exception handler would in response to an
attempt to actually execute the instruction. Sending SIGBUS only makes
sense for the unaligned PC case, since moved to `__compute_return_epc'.
Adjust function documentation accordingly, correct formatting and use
`pr_info' rather than `printk' as the other exit path already does.
Fixes:
e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16396/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:05:08 +0000 (00:05 +0100)]
MIPS: math-emu: Prevent wrong ISA mode instruction emulation
commit
13769ebad0c42738831787e27c7c7f982e7da579 upstream.
Terminate FPU emulation immediately whenever an ISA mode switch has been
observed. This is so that we do not interpret machine code in the wrong
mode, for example when a regular MIPS FPU instruction has been placed in
a delay slot of a jump that switches into the MIPS16 mode, as with the
following code (taken from a GCC test suite case):
00400650 <set_fast_math>:
400650:
3c020100 lui v0,0x100
400654:
03e00008 jr ra
400658:
44c2f800 ctc1 v0,c1_fcsr
40065c:
00000000 nop
[...]
004012d0 <__libc_csu_init>:
4012d0: f000 6a02 li v0,2
4012d4: f150 0b1c la v1,3f9430 <_DYNAMIC-0x6df0>
4012d8: f400 3240 sll v0,16
4012dc: e269 addu v0,v1
4012de: 659a move gp,v0
4012e0: f00c 64f6 save a0-a2,48,ra,s0-s1
4012e4: 673c move s1,gp
4012e6: f010 9978 lw v1,-32744(s1)
4012ea: d204 sw v0,16(sp)
4012ec: eb40 jalr v1
4012ee: 653b move t9,v1
4012f0: f010 997c lw v1,-32740(s1)
4012f4: f030 9920 lw s1,-32736(s1)
4012f8: e32f subu v1,s1
4012fa: 326b sra v0,v1,2
4012fc: d206 sw v0,24(sp)
4012fe: 220c beqz v0,401318 <__libc_csu_init+0x48>
401300: 6800 li s0,0
401302: 99e0 lw a3,0(s1)
401304: 4801 addiu s0,1
401306: 960e lw a2,56(sp)
401308: 4904 addiu s1,4
40130a: 950d lw a1,52(sp)
40130c: 940c lw a0,48(sp)
40130e: ef40 jalr a3
401310: 653f move t9,a3
401312: 9206 lw v0,24(sp)
401314: ea0a cmp v0,s0
401316: 61f5 btnez 401302 <__libc_csu_init+0x32>
401318: 6476 restore 48,ra,s0-s1
40131a: e8a0 jrc ra
Here `set_fast_math' is called from `40130e' (`40130f' with the ISA bit)
and emulation triggers for the CTC1 instruction. As it is in a jump
delay slot emulation continues from `401312' (`401313' with the ISA
bit). However we have no path to handle MIPS16 FPU code emulation,
because there are no MIPS16 FPU instructions. So the default emulation
path is taken, interpreting a 32-bit word fetched by `get_user' from
`401313' as a regular MIPS instruction, which is:
401313:
f5ea0a92 sdc1 $f10,2706(t7)
This makes the FPU emulator proceed with the supposed SDC1 instruction
and consequently makes the program considered here terminate with
SIGSEGV.
A similar although less severe issue exists with pure-microMIPS
processors in the case where similarly an FPU instruction is emulated in
a delay slot of a register jump that (incorrectly) switches into the
regular MIPS mode. A subsequent instruction fetch from the jump's
target is supposed to cause an Address Error exception, however instead
we proceed with regular MIPS FPU emulation.
For simplicity then, always terminate the emulation loop whenever a mode
change is detected, denoted by an ISA mode bit flip. As from commit
377cb1b6c16a ("MIPS: Disable MIPS16/microMIPS crap for platforms not
supporting these ASEs.") the result of `get_isa16_mode' can be hardcoded
to 0, so we need to examine the ISA mode bit by hand.
This complements commit
102cedc32a6e ("MIPS: microMIPS: Floating point
support.") which added JALX decoding to FPU emulation.
Fixes:
102cedc32a6e ("MIPS: microMIPS: Floating point support.")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16393/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:07:34 +0000 (00:07 +0100)]
MIPS: Fix unaligned PC interpretation in `compute_return_epc'
commit
11a3799dbeb620bf0400b1fda5cc2c6bea55f20a upstream.
Fix a regression introduced with commit
fb6883e5809c ("MIPS: microMIPS:
Support handling of delay slots.") and defer to `__compute_return_epc'
if the ISA bit is set in EPC with non-MIPS16, non-microMIPS hardware,
which will then arrange for a SIGBUS due to an unaligned instruction
reference. Returning EPC here is never correct as the API defines this
function's result to be either a negative error code on failure or one
of 0 and BRANCH_LIKELY_TAKEN on success.
Fixes:
fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16395/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Thu, 15 Jun 2017 23:06:19 +0000 (00:06 +0100)]
MIPS: Actually decode JALX in `__compute_return_epc_for_insn'
commit
a9db101b735a9d49295326ae41f610f6da62b08c upstream.
Complement commit
fb6883e5809c ("MIPS: microMIPS: Support handling of
delay slots.") and actually decode the regular MIPS JALX major
instruction opcode, the handling of which has been added with the said
commit for EPC calculation in `__compute_return_epc_for_insn'.
Fixes:
fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.")
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16394/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Wed, 31 May 2017 15:19:48 +0000 (16:19 +0100)]
MIPS: Save static registers before sysmips
commit
49955d84cd9ccdca5a16a495e448e1a06fad9e49 upstream.
The MIPS sysmips system call handler may return directly from the
MIPS_ATOMIC_SET case (mips_atomic_set()) to syscall_exit. This path
restores the static (callee saved) registers, however they won't have
been saved on entry to the system call.
Use the save_static_function() macro to create a __sys_sysmips wrapper
function which saves the static registers before calling sys_sysmips, so
that the correct static register state is restored by syscall_exit.
Fixes:
f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16149/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Sat, 8 Jul 2017 22:24:44 +0000 (23:24 +0100)]
MIPS: Fix MIPS I ISA /proc/cpuinfo reporting
commit
e5f5a5b06e51a36f6ddf31a4a485358263953a3d upstream.
Correct a commit
515a6393dbac ("MIPS: kernel: proc: Add MIPS R6 support
to /proc/cpuinfo") regression that caused MIPS I systems to show no ISA
levels supported in /proc/cpuinfo, e.g.:
system type : Digital DECstation 2100/3100
machine : Unknown
processor : 0
cpu model : R3000 V2.0 FPU V2.0
BogoMIPS : 10.69
wait instruction : no
microsecond timers : no
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : no
isa :
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
and similarly exclude `mips1' from the ISA list for any processors below
MIPSr1. This is because the condition to show `mips1' on has been made
`cpu_has_mips_r1' rather than newly-introduced `cpu_has_mips_1'. Use
the correct condition then.
Fixes:
515a6393dbac ("MIPS: kernel: proc: Add MIPS R6 support to /proc/cpuinfo")
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16758/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seunghun Han [Tue, 18 Jul 2017 09:20:44 +0000 (18:20 +0900)]
x86/ioapic: Pass the correct data to unmask_ioapic_irq()
commit
e708e35ba6d89ff785b225cd07dcccab04fa954a upstream.
One of the rarely executed code pathes in check_timer() calls
unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
interrupt 0. irq_get_chip_data(0) returns NULL, so the following
dereference in unmask_ioapic_irq() causes a kernel panic.
The issue went unnoticed in the first place because irq_get_chip_data()
returns a void pointer so the compiler cannot do a type check on the
argument. The code path was added for machines with broken configuration,
but it seems that those machines are either not running current kernels or
simply do not longer exist.
Hand in irq_get_irq_data(0) as argument which provides the correct data.
[ tglx: Rewrote changelog ]
Fixes:
4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkamagui@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seunghun Han [Tue, 18 Jul 2017 11:03:51 +0000 (20:03 +0900)]
x86/acpi: Prevent out of bound access caused by broken ACPI tables
commit
dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream.
The bus_irq argument of mp_override_legacy_irq() is used as the index into
the isa_irq_to_gsi[] array. The bus_irq argument originates from
ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI
tables, but is nowhere sanity checked.
That allows broken or malicious ACPI tables to overwrite memory, which
might cause malfunction, panic or arbitrary code execution.
Add a sanity check and emit a warning when that triggers.
[ tglx: Added warning and rewrote changelog ]
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Wed, 12 Jul 2017 03:09:17 +0000 (11:09 +0800)]
Revert "ACPI / EC: Enable event freeze mode..." to fix a regression
commit
9c40f956ce9b331493347d1b3cb7e384f7dc0581 upstream.
On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier
EC event freezing timing causes acpitz-virtual-0 to report a stuck
48C temparature. And with EC firmware revisioned as 1.14, without
reverting back to old EC event freezing timing, the fan still blows
up after a system resume.
This reverts the culprit change so that the regression can be fixed
without upgrading the EC firmware.
Fixes:
d30283057ecd (ACPI / EC: Enable event freeze mode to improve event handling)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168
Tested-by: Damjan Georgievski <gdamjan@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Wed, 12 Jul 2017 03:09:09 +0000 (11:09 +0800)]
ACPI / EC: Drop EC noirq hooks to fix a regression
commit
662591461c4b9a1e3b9b159dbf37648a585ebaae upstream.
According to bug reports, although the busy polling mode can make
noirq stages execute faster, it causes abnormal fan blowing up after
system resume (see the first link below for a video demonstration)
on Lenovo ThinkPad X1 Carbon - the 5th Generation. The problem can
be fixed by upgrading the EC firmware on that machine.
However, many reporters confirm that the problem can be fixed by
stopping busy polling during suspend/resume and for some of them
upgrading the EC firmware is not an option.
For this reason, drop the noirq stage hooks from the EC driver
to fix the regression.
Fixes:
c3a696b6e8f8 (ACPI / EC: Use busy polling mode when GPE is not enabled)
Link: https://youtu.be/9NQ9x-Jm99Q
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129
Reported-by: Andreas Lindhe <andreas@lindhe.io>
Tested-by: Gjorgji Jankovski <j.gjorgji@gmail.com>
Tested-by: Damjan Georgievski <gdamjan@gmail.com>
Tested-by: Fernando Chaves <nanochaves@gmail.com>
Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com>
Tested-by: Denis P. <theoriginal.skullburner@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Weinberger [Fri, 16 Jun 2017 14:21:44 +0000 (16:21 +0200)]
ubifs: Don't leak kernel memory to the MTD
commit
4acadda74ff8b949c448c0282765ae747e088c87 upstream.
When UBIFS prepares data structures which will be written to the MTD it
ensues that their lengths are multiple of 8. Since it uses kmalloc() the
padded bytes are left uninitialized and we leak a few bytes of kernel
memory to the MTD.
To make sure that all bytes are initialized, let's switch to kzalloc().
Kzalloc() is fine in this case because the buffers are not huge and in
the IO path the performance bottleneck is anyway the MTD.
Fixes:
1e51764a3c2a ("UBIFS: add new flash file system")
Signed-off-by: Richard Weinberger <richard@nod.at>
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>
James Hogan [Thu, 29 Jun 2017 09:12:34 +0000 (10:12 +0100)]
MIPS: Negate error syscall return in trace
commit
4f32a39d49b25eaa66d2420f1f03d371ea4cd906 upstream.
The sys_exit trace event takes a single return value for the system
call, which MIPS passes the value of the $v0 (result) register, however
MIPS returns positive error codes in $v0 with $a3 specifying that $v0
contains an error code. As a result erroring system calls are traced
returning positive error numbers that can't always be distinguished from
success.
Use regs_return_value() to negate the error code if $a3 is set.
Fixes:
1d7bf993e073 ("MIPS: ftrace: Add support for syscall tracepoints.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16651/
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Wed, 31 May 2017 15:19:49 +0000 (16:19 +0100)]
MIPS: Fix mips_atomic_set() with EVA
commit
4915e1b043d6286928207b1f6968197b50407294 upstream.
EVA linked loads (LLE) and conditional stores (SCE) should be used on
EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system
call, or else the atomic set will apply to the kernel view of the
virtual address space (potentially unmapped on EVA kernels) rather than
the user view (TLB mapped).
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16151/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Wed, 31 May 2017 15:19:47 +0000 (16:19 +0100)]
MIPS: Fix mips_atomic_set() retry condition
commit
2ec420b26f7b6ff332393f0bb5a7d245f7ad87f0 upstream.
The inline asm retry check in the MIPS_ATOMIC_SET operation of the
sysmips system call has been backwards since commit
f1e39a4a616c ("MIPS:
Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying
until the operation was inatomic, before returning the new value that
was probably just written multiple times instead of the old value.
Invert the branch condition to fix that particular issue.
Fixes:
f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16148/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 12 Jul 2017 07:35:57 +0000 (10:35 +0300)]
ftrace: Fix uninitialized variable in match_records()
commit
2e028c4fe12907f226b8221815f16c2486ad3aa7 upstream.
My static checker complains that if "func" is NULL then "clear_filter"
is uninitialized. This seems like it could be true, although it's
possible something subtle is happening that I haven't seen.
kernel/trace/ftrace.c:3844 match_records()
error: uninitialized symbol 'clear_filter'.
Link: http://lkml.kernel.org/r/20170712073556.h6tkpjcdzjaozozs@mwanda
Fixes:
f0a3b154bd7 ("ftrace: Clarify code for mod command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marta Rybczynska [Tue, 6 Jun 2017 11:27:21 +0000 (13:27 +0200)]
nvme-rdma: remove race conditions from IB signalling
commit
5e599d73c1c1816af07f94ddba879499aa39b43c upstream.
This patch improves the way the RDMA IB signalling is done by using atomic
operations for the signalling variable. This avoids race conditions on
sig_count.
The signalling interval changes slightly and is now the largest power of
two not larger than queue depth / 2.
ilog() usage idea by Bart Van Assche.
Signed-off-by: Marta Rybczynska <marta.rybczynska@kalray.eu>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Williamson [Wed, 28 Jun 2017 19:50:05 +0000 (13:50 -0600)]
vfio: New external user group/file match
commit
5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream.
At the point where the kvm-vfio pseudo device wants to release its
vfio group reference, we can't always acquire a new reference to make
that happen. The group can be in a state where we wouldn't allow a
new reference to be added. This new helper function allows a caller
to match a file to a group to facilitate this. Given a file and
group, report if they match. Thus the caller needs to already have a
group reference to match to the file. This allows the deletion of a
group without acquiring a new reference.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Williamson [Mon, 19 Jun 2017 15:10:32 +0000 (09:10 -0600)]
vfio: Fix group release deadlock
commit
811642d8d8a82c0cce8dc2debfdaf23c5a144839 upstream.
If vfio_iommu_group_notifier() acquires a group reference and that
reference becomes the last reference to the group, then vfio_group_put
introduces a deadlock code path where we're trying to unregister from
the iommu notifier chain from within a callout of that chain. Use a
work_struct to release this reference asynchronously.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konstantin Khlebnikov [Tue, 10 Jan 2017 18:30:21 +0000 (21:30 +0300)]
ovl: drop CAP_SYS_RESOURCE from saved mounter's credentials
commit
51f8f3c4e22535933ef9aecc00e9a6069e051b57 upstream.
If overlay was mounted by root then quota set for upper layer does not work
because overlay now always use mounter's credentials for operations.
Also overlay might deplete reserved space and inodes in ext4.
This patch drops capability SYS_RESOURCE from saved credentials.
This affects creation new files, whiteouts, and copy-up operations.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes:
1175b6b8d963 ("ovl: do operations on underlying file system in mounter's context")
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Brooks [Mon, 3 Jul 2017 18:05:34 +0000 (14:05 -0400)]
drm/ttm: Fix use-after-free in ttm_bo_clean_mm
commit
8046e1955465e3f24e9154d0f2a2e0a8e3f8dccf upstream.
We unref the man->move fence in ttm_bo_clean_mm() and then call
ttm_bo_force_list_clean() which waits on it, except the refcount is now
zero so a warning is generated (or worse):
[149492.279301] refcount_t: increment on 0; use-after-free.
[149492.279309] ------------[ cut here ]------------
[149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30
[149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(
-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
[149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1
[149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
[149492.279327] task:
ffff8804ddfedcc0 task.stack:
ffffc90008d20000
[149492.279329] RIP: 0010:refcount_inc+0x2b/0x30
[149492.279330] RSP: 0018:
ffffc90008d23c30 EFLAGS:
00010286
[149492.279331] RAX:
000000000000002b RBX:
0000000000000170 RCX:
0000000000000000
[149492.279331] RDX:
0000000000000000 RSI:
ffff88051ecccbe8 RDI:
ffff88051ecccbe8
[149492.279332] RBP:
ffffc90008d23c30 R08:
0000000000000001 R09:
00000000000003ee
[149492.279333] R10:
ffffc90008d23bb0 R11:
00000000000003ee R12:
ffff88043aaac960
[149492.279333] R13:
ffff8805005e28a8 R14:
0000000000000002 R15:
ffff88050115e178
[149492.279334] FS:
00007fc540168700(0000) GS:
ffff88051ecc0000(0000) knlGS:
0000000000000000
[149492.279335] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[149492.279336] CR2:
00007fc3e8654140 CR3:
000000027ba77000 CR4:
00000000001426e0
[149492.279337] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[149492.279337] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[149492.279338] Call Trace:
[149492.279345] ttm_bo_force_list_clean+0xb9/0x110 [ttm]
[149492.279348] ttm_bo_clean_mm+0x7a/0xe0 [ttm]
[149492.279375] amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu]
[149492.279392] amdgpu_bo_fini+0x12/0x40 [amdgpu]
[149492.279415] gmc_v7_0_sw_fini+0x32/0x40 [amdgpu]
[149492.279430] amdgpu_fini+0x2c9/0x490 [amdgpu]
[149492.279445] amdgpu_device_fini+0x58/0x1b0 [amdgpu]
[149492.279461] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu]
[149492.279470] drm_dev_unregister+0x3c/0xe0 [drm]
[149492.279485] amdgpu_pci_remove+0x19/0x30 [amdgpu]
[149492.279487] pci_device_remove+0x39/0xc0
[149492.279490] device_release_driver_internal+0x155/0x210
[149492.279491] driver_detach+0x38/0x70
[149492.279493] bus_remove_driver+0x4c/0xa0
[149492.279494] driver_unregister+0x2c/0x40
[149492.279496] pci_unregister_driver+0x21/0x90
[149492.279520] amdgpu_exit+0x15/0x406 [amdgpu]
[149492.279523] SyS_delete_module+0x1a8/0x270
[149492.279525] ? exit_to_usermode_loop+0x92/0xa0
[149492.279528] entry_SYSCALL_64_fastpath+0x13/0x94
[149492.279529] RIP: 0033:0x7fc53fcb68e7
[149492.279529] RSP: 002b:
00007ffcfbfaabb8 EFLAGS:
00000206 ORIG_RAX:
00000000000000b0
[149492.279531] RAX:
ffffffffffffffda RBX:
0000563117adb200 RCX:
00007fc53fcb68e7
[149492.279531] RDX:
000000000000000a RSI:
0000000000000800 RDI:
0000563117adb268
[149492.279532] RBP:
0000000000000003 R08:
0000000000000000 R09:
1999999999999999
[149492.279533] R10:
0000000000000883 R11:
0000000000000206 R12:
00007ffcfbfa9ba0
[149492.279533] R13:
0000000000000000 R14:
0000000000000000 R15:
0000563117adb200
[149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff
[149492.279557] ---[ end trace
2d4e0ffcb66a1016 ]---
Unref the fence *after* waiting for it.
v2: Set man->move to NULL after dropping the last ref (Christian König)
Fixes:
aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean)
Signed-off-by: John Brooks <john@fastquake.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jaegeuk Kim [Tue, 11 Jul 2017 21:56:49 +0000 (14:56 -0700)]
f2fs: Don't clear SGID when inheriting ACLs
commit
c925dc162f770578ff4a65ec9b08270382dba9e6 upstream.
This patch copies commit
b7f8a09f80:
"btrfs: Don't clear SGID when inheriting ACLs" written by Jan.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jin Qian [Thu, 1 Jun 2017 18:18:30 +0000 (11:18 -0700)]
f2fs: sanity check size of nat and sit cache
commit
21d3f8e1c3b7996ce239ab6fa82e9f7a8c47d84d upstream.
Make sure number of entires doesn't exceed max journal size.
Signed-off-by: Jin Qian <jinqian@android.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Mon, 26 Jun 2017 15:48:18 +0000 (08:48 -0700)]
xfs: Don't clear SGID when inheriting ACLs
commit
8ba358756aa08414fa9e65a1a41d28304ed6fd7f upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when
setting up inode in xfs_generic_create(). That prevents SGID bit
clearing and mode is properly set by posix_acl_create() anyway. We also
reorder arguments of __xfs_set_acl() to match the ordering of
xfs_set_acl() to make things consistent.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
CC: Darrick J. Wong <darrick.wong@oracle.com>
CC: linux-xfs@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Corey Minyard [Fri, 30 Jun 2017 12:18:08 +0000 (07:18 -0500)]
ipmi:ssif: Add missing unlock in error branch
commit
4495ec6d770e1bca7a04e93ac453ab6720c56c5d upstream.
When getting flags, a response to a different message would
result in a deadlock because of a missing unlock. Add that
unlock and a comment. Found by static analysis.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Camuso [Mon, 19 Jun 2017 17:17:33 +0000 (13:17 -0400)]
ipmi: use rcu lock around call to intf->handlers->sender()
commit
cdea46566bb21ce309725a024208322a409055cc upstream.
A vendor with a system having more than 128 CPUs occasionally encounters
the following crash during shutdown. This is not an easily reproduceable
event, but the vendor was able to provide the following analysis of the
crash, which exhibits the same footprint each time.
crash> bt
PID: 0 TASK:
ffff88017c70ce70 CPU: 5 COMMAND: "swapper/5"
#0 [
ffff88085c143ac8] machine_kexec at
ffffffff81059c8b
#1 [
ffff88085c143b28] __crash_kexec at
ffffffff811052e2
#2 [
ffff88085c143bf8] crash_kexec at
ffffffff811053d0
#3 [
ffff88085c143c10] oops_end at
ffffffff8168ef88
#4 [
ffff88085c143c38] no_context at
ffffffff8167ebb3
#5 [
ffff88085c143c88] __bad_area_nosemaphore at
ffffffff8167ec49
#6 [
ffff88085c143cd0] bad_area_nosemaphore at
ffffffff8167edb3
#7 [
ffff88085c143ce0] __do_page_fault at
ffffffff81691d1e
#8 [
ffff88085c143d40] do_page_fault at
ffffffff81691ec5
#9 [
ffff88085c143d70] page_fault at
ffffffff8168e188
[exception RIP: unknown or invalid address]
RIP:
ffffffffa053c800 RSP:
ffff88085c143e28 RFLAGS:
00010206
RAX:
ffff88017c72bfd8 RBX:
ffff88017a8dc000 RCX:
ffff8810588b5ac8
RDX:
ffff8810588b5a00 RSI:
ffffffffa053c800 RDI:
ffff8810588b5a00
RBP:
ffff88085c143e58 R8:
ffff88017c70d408 R9:
ffff88017a8dc000
R10:
0000000000000002 R11:
ffff88085c143da0 R12:
ffff8810588b5ac8
R13:
0000000000000100 R14:
ffffffffa053c800 R15:
ffff8810588b5a00
ORIG_RAX:
ffffffffffffffff CS: 0010 SS: 0018
<IRQ stack>
[exception RIP: cpuidle_enter_state+82]
RIP:
ffffffff81514192 RSP:
ffff88017c72be50 RFLAGS:
00000202
RAX:
0000001e4c3c6f16 RBX:
000000000000f8a0 RCX:
0000000000000018
RDX:
0000000225c17d03 RSI:
ffff88017c72bfd8 RDI:
0000001e4c3c6f16
RBP:
ffff88017c72be78 R8:
000000000000237e R9:
0000000000000018
R10:
0000000000002494 R11:
0000000000000001 R12:
ffff88017c72be20
R13:
ffff88085c14f8e0 R14:
0000000000000082 R15:
0000001e4c3bb400
ORIG_RAX:
ffffffffffffff10 CS: 0010 SS: 0018
This is the corresponding stack trace
It has crashed because the area pointed with RIP extracted from timer
element is already removed during a shutdown process.
The function is smi_timeout().
And we think
ffff8810588b5a00 in RDX is a parameter struct smi_info
crash> rd
ffff8810588b5a00 20
ffff8810588b5a00:
ffff8810588b6000 0000000000000000 .`.X............
ffff8810588b5a10:
ffff880853264400 ffffffffa05417e0 .D&S......T.....
ffff8810588b5a20:
24a024a000000000 0000000000000000 .....$.$........
ffff8810588b5a30:
0000000000000000 0000000000000000 ................
ffff8810588b5a30:
0000000000000000 0000000000000000 ................
ffff8810588b5a40:
ffffffffa053a040 ffffffffa053a060 @.S.....`.S.....
ffff8810588b5a50:
0000000000000000 0000000100000001 ................
ffff8810588b5a60:
0000000000000000 0000000000000e00 ................
ffff8810588b5a70:
ffffffffa053a580 ffffffffa053a6e0 ..S.......S.....
ffff8810588b5a80:
ffffffffa053a4a0 ffffffffa053a250 ..S.....P.S.....
ffff8810588b5a90:
0000000500000002 0000000000000000 ................
Unfortunately the top of this area is already detroyed by someone.
But because of two reasonns we think this is struct smi_info
1) The address included in between
ffff8810588b5a70 and
ffff8810588b5a80:
are inside of ipmi_si_intf.c see crash> module
ffff88085779d2c0
2) We've found the area which point this.
It is offset 0x68 of
ffff880859df4000
crash> rd
ffff880859df4000 100
ffff880859df4000:
0000000000000000 0000000000000001 ................
ffff880859df4010:
ffffffffa0535290 dead000000000200 .RS.............
ffff880859df4020:
ffff880859df4020 ffff880859df4020 @.Y.... @.Y....
ffff880859df4030:
0000000000000002 0000000000100010 ................
ffff880859df4040:
ffff880859df4040 ffff880859df4040 @@.Y....@@.Y....
ffff880859df4050:
0000000000000000 0000000000000000 ................
ffff880859df4060:
0000000000000000 ffff8810588b5a00 .........Z.X....
ffff880859df4070:
0000000000000001 ffff880859df4078 ........x@.Y....
If we regards it as struct ipmi_smi in shutdown process
it looks consistent.
The remedy for this apparent race is affixed below.
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This was first introduced in
7ea0ed2b5be817 ipmi: Make the
message handler easier to use for SMI interfaces
where some code was moved outside of the rcu_read_lock()
and the lock was not added.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Mario Kleiner [Fri, 7 Jul 2017 02:57:04 +0000 (04:57 +0200)]
drm/radeon: Fix eDP for single-display iMac10,1 (v2)
commit
564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream.
The late 2009, 27 inch Apple iMac10,1 has an
internal eDP display and an external Mini-
Displayport output, driven by a DCE-3.2, RV730
Radeon Mobility HD-4670.
The machine worked fine in a dual-display setup
with eDP panel + externally connected HDMI
or DVI-D digital display sink, connected via
MiniDP to DVI or HDMI adapter.
However, booting the machine single-display with
only eDP panel results in a completely black
display - even backlight powering off, as soon as
the radeon modesetting driver loads.
This patch fixes the single dispay eDP case by
assigning encoders based on dig->linkb, similar
to DCE-4+. While this should not be generally
necessary (Alex: "...atom on normal boards
should be able to handle any mapping."), Apple
seems to use some special routing here.
One remaining problem not solved by this patch
is that an external Minidisplayport->DP sink
does still not work on iMac10,1, whereas external
DVI and HDMI sinks continue to work.
The problem affects at least all tested kernels
since Linux 3.13 - didn't test earlier kernels, so
backporting to stable probably makes sense.
v2: With the original patch from 2016, Alex was worried it
will break other DCE3.2 systems. Use dmi_match() to
apply this special encoder assignment only for the
Apple iMac 10,1 from late 2009.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 11 May 2017 17:14:14 +0000 (13:14 -0400)]
drm/radeon/ci: disable mclk switching for high refresh rates (v2)
commit
ab03d9fe508f4e2914a8f4a9eef1b21051cacd0f upstream.
Even if the vblank period would allow it, it still seems to
be problematic on some cards.
v2: fix logic inversion (Nils)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
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>
Tom St Denis [Tue, 23 May 2017 15:35:22 +0000 (11:35 -0400)]
drm/amd/amdgpu: Return error if initiating read out of range on vram
commit
9156e723301c0a7a7def4cde820e018ce791b842 upstream.
If you initiate a read that is out of the VRAM address space return
ENXIO instead of 0.
Reads that begin below that point will read upto the VRAM limit as
before.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-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>
Jiri Olsa [Thu, 29 Jun 2017 09:38:11 +0000 (11:38 +0200)]
s390/syscalls: Fix out of bounds arguments access
commit
c46fc0424ced3fb71208e72bd597d91b9169a781 upstream.
Zorro reported following crash while having enabled
syscall tracing (CONFIG_FTRACE_SYSCALLS):
Unable to handle kernel pointer dereference at virtual ...
Oops: 0011 [#1] SMP DEBUG_PAGEALLOC
SNIP
Call Trace:
([<
000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8)
[<
00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8
[<
0000000000730f1c>] sysc_tracesys+0x1a/0x32
[<
000003fffcf946a2>] 0x3fffcf946a2
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<
000000000022dd44>] rb_event_data+0x34/0x40
---[ end trace
8c795f86b1b3f7b9 ]---
The crash happens in syscall_get_arguments function for
syscalls with zero arguments, that will try to access
first argument (args[0]) in event entry, but it's not
allocated.
Bail out of there are no arguments.
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiao Ni [Wed, 5 Jul 2017 09:34:04 +0000 (17:34 +0800)]
Raid5 should update rdev->sectors after reshape
commit
b5d27718f38843a74552e9a93d32e2391fd3999f upstream.
The raid5 md device is created by the disks which we don't use the total size. For example,
the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
and assemble it again. It fails.
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
mdadm /dev/md0 --grow --chunk=64
wait reshape to finish
mdadm -S /dev/md0
mdadm -As
The error messages:
[197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
[197519.821686] md: md_import_device returned -22
After reshape the data offset is changed. It selects backwards direction in this condition.
In function super_1_load it compares the available space of the underlying device with
sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based
on rdev->sectors. So add md_finish_reshape in end_reshape.
Signed-off-by: Xiao Ni <xni@redhat.com>
Acked-by: Guoqing Jiang <gqjiang@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 21 Jun 2017 12:34:15 +0000 (14:34 +0200)]
ext2: Don't clear SGID when inheriting ACLs
commit
a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by creating __ext2_set_acl() function that does not call
posix_acl_update_mode() and use it when inheriting ACLs. That prevents
SGID bit clearing and the mode has been properly set by
posix_acl_create() anyway.
Fixes:
073931017b49d9458aa351605b43a7e34598caef
CC: linux-ext4@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Toshi Kani [Fri, 7 Jul 2017 23:44:26 +0000 (17:44 -0600)]
libnvdimm: fix badblock range handling of ARS range
commit
4e3f0701f25ab194c5362576b1146a1e6cc6c2e7 upstream.
__add_badblock_range() does not account sector alignment when
it sets 'num_sectors'. Therefore, an ARS error record range
spanning across two sectors is set to a single sector length,
which leaves the 2nd sector unprotected.
Change __add_badblock_range() to set 'num_sectors' properly.
Fixes:
0caeef63e6d2 ("libnvdimm: Add a poison list and export badblocks")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vishal Verma [Thu, 29 Jun 2017 22:59:11 +0000 (16:59 -0600)]
libnvdimm, btt: fix btt_rw_page not returning errors
commit
c13c43d54f2c6a3be1c675766778ac1ad8dfbfcc upstream.
btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any
IO errors via the rw_page path going unnoticed. the pmem driver recently
fixed this in e10624f pmem: fail io-requests to known bad blocks
but same problem in BTT went neglected.
Fixes:
5212e11fde4d ("nd_btt: atomic sector updates")
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Devin Heitmueller [Sat, 20 Sep 2014 12:23:44 +0000 (09:23 -0300)]
cx88: Fix regression in initial video standard setting
commit
4e0973a918b9a42e217093f078e04a61e5dd95a5 upstream.
Setting initial standard at the top of cx8800_initdev would cause the
first call to cx88_set_tvnorm() to return without programming any
registers (leaving the driver saying it's set to NTSC but the hardware
isn't programmed). Even worse, any subsequent attempt to explicitly
set it to NTSC-M will return success but actually fail to program the
underlying registers unless first changing the standard to something
other than NTSC-M.
Set the initial standard later in the process, and make sure the field
is zero at the beginning to ensure that the call always goes through.
This regression was introduced in the following commit:
commit
ccd6f1d488e7 ("[media] cx88: move width, height and field to core
struct")
Author: Hans Verkuil <hans.verkuil@cisco.com>
[media] cx88: move width, height and field to core struct
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Marczykowski-Górecki [Mon, 26 Jun 2017 12:49:46 +0000 (14:49 +0200)]
x86/xen: allow userspace access during hypercalls
commit
c54590cac51db8ab5fd30156bdaba34af915e629 upstream.
Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.
The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
carefully verify buffer addresses.
Cc: stable@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
[HYPERVISOR_dm_op dropped - not present until 4.11]
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Wed, 7 Jun 2017 23:05:31 +0000 (19:05 -0400)]
md: don't use flush_signals in userspace processes
commit
f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream.
The function flush_signals clears all pending signals for the process. It
may be used by kernel threads when we need to prepare a kernel thread for
responding to signals. However using this function for an userspaces
processes is incorrect - clearing signals without the program expecting it
can cause misbehavior.
The raid1 and raid5 code uses flush_signals in its request routine because
it wants to prepare for an interruptible wait. This patch drops
flush_signals and uses sigprocmask instead to block all signals (including
SIGKILL) around the schedule() call. The signals are not lost, but the
schedule() call won't respond to them.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Wed, 19 Jul 2017 07:16:55 +0000 (16:16 +0900)]
usb: renesas_usbhs: gadget: disable all eps when the driver stops
commit
b8b9c974afee685789fcbb191b52d1790be3608c upstream.
A gadget driver will not disable eps immediately when ->disconnect()
is called. But, since this driver assumes all eps stop after
the ->disconnect(), unexpected behavior happens (especially in system
suspend).
So, this patch disables all eps in usbhsg_try_stop(). After disabling
eps by renesas_usbhs driver, since some functions will be called by
both a gadget and renesas_usbhs driver, renesas_usbhs driver should
protect uep->pipe. To protect uep->pipe easily, this patch adds a new
lock in struct usbhsg_uep.
Fixes:
2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
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>
Yoshihiro Shimoda [Wed, 19 Jul 2017 07:16:54 +0000 (16:16 +0900)]
usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRL
commit
59a0879a0e17b2e43ecdc5e3299da85b8410d7ce upstream.
This patch fixes an issue that some registers may be not initialized
after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
if a cable is not connected, the driver will not enable INTENB0.VBSE
after resume. And then, the driver cannot detect the VBUS.
Fixes:
ca8a282a5373 ("usb: gadget: renesas_usbhs: add suspend/resume support")
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>
Johan Hovold [Wed, 12 Jul 2017 13:08:39 +0000 (15:08 +0200)]
USB: cdc-acm: add device-id for quirky printer
commit
fe855789d605590e57f9cd968d85ecce46f5c3fd upstream.
Add device-id entry for DATECS FP-2000 fiscal printer needing the
NO_UNION_NORMAL quirk.
Reported-by: Anton Avramov <lukav@lukav.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 6 Jul 2017 15:06:32 +0000 (16:06 +0100)]
usb: storage: return on error to avoid a null pointer dereference
commit
446230f52a5bef593554510302465eabab45a372 upstream.
When us->extra is null the driver is not initialized, however, a
later call to osd200_scsi_to_ata is made that dereferences
us->extra, causing a null pointer dereference. The code
currently detects and reports that the driver is not initialized;
add a return to avoid the subsequent dereference issue in this
check.
Thanks to Alan Stern for pointing out that srb->result needs setting
to DID_ERROR << 16
Detected by CoverityScan, CID#100308 ("Dereference after null check")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Devin Heitmueller [Fri, 21 Apr 2017 16:28:37 +0000 (13:28 -0300)]
mxl111sf: Fix driver to use heap allocate buffers for USB messages
commit
d90b336f3f652ff0441e631a06236f785581c8f7 upstream.
The recent changes in 4.9 to mandate USB buffers be heap allocated
broke this driver, which was allocating the buffers on the stack.
This resulted in the device failing at initialization.
Introduce dedicated send/receive buffers as part of the state
structure, and add a mutex to protect access to them.
Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass
the pointer to the state struct rather than the device, since
we need it inside the function to access the buffers and the
mutex. This patch adjusts the callers to match the API change.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Reported-by: Doug Lung <dlung0@gmail.com>
Cc: Michael Ira Krufky <mkrufky@linuxtv.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiahau Chang [Thu, 20 Jul 2017 11:48:27 +0000 (14:48 +0300)]
xhci: Bad Ethernet performance plugged in ASM1042A host
commit
9da5a1092b13468839b1a864b126cacfb72ad016 upstream.
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
The register we modify is changes the behavior
[use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
Signed-off-by: Jiahau Chang <Lars_chang@asmedia.com.tw>
Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Thu, 20 Jul 2017 11:48:26 +0000 (14:48 +0300)]
xhci: Fix NULL pointer dereference when cleaning up streams for removed host
commit
4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream.
This off by one in stream_id indexing caused NULL pointer dereference and
soft lockup on machines with USB attached SCSI devices connected to a
hotpluggable xhci controller.
The code that cleans up pending URBs for dead hosts tried to dereference
a stream ring at the invalid stream_id 0.
ep->stream_info->stream_rings[0] doesn't point to a ring.
Start looping stream_id from 1 like in all the other places in the driver,
and check that the ring exists before trying to kill URBs on it.
Reported-by: rocko r <rockorequin@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Thu, 20 Jul 2017 11:48:29 +0000 (14:48 +0300)]
xhci: fix 20000ms port resume timeout
commit
a54408d0a004757789863d74e29c2297edae0b4d upstream.
A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 20000ms while waiting to get the final port event
interrupt for resume -> U0 state change.
This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.
The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julian Anastasov [Sat, 29 Apr 2017 17:33:09 +0000 (20:33 +0300)]
ipvs: SNAT packet replies only for NATed connections
commit
3c5ab3f395d66a9e4e937fcfdf6ebc63894f028b upstream.
We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:
- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.
- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.
The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.
So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.
Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Tested-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen Yu [Thu, 25 May 2017 08:49:07 +0000 (16:49 +0800)]
PCI/PM: Restore the status of PCI devices across hibernation
commit
e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream.
Currently we saw a lot of "No irq handler" errors during hibernation, which
caused the system hang finally:
ata4.00: qc timeout (cmd 0xec)
ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata4.00: revalidation failed (errno=-5)
ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
do_IRQ: 31.151 No irq handler for vector
According to above logs, there is an interrupt triggered and it is
dispatched to CPU31 with a vector number 151, but there is no handler for
it, thus this IRQ will not get acked and will cause an IRQ flood which
kills the system. To be more specific, the 31.151 is an interrupt from the
AHCI host controller.
After some investigation, the reason why this issue is triggered is because
the thaw_noirq() function does not restore the MSI/MSI-X settings across
hibernation.
The scenario is illustrated below:
1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
is bound to CPU31.
2. Hibernation starts, the AHCI device is put into low power state.
3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
the last alive one - CPU0.
4. After the snapshot has been created, all the nonboot CPUs are brought
up again; IRQ 34 remains bound to CPU0.
5. AHCI devices are put into D0.
6. The snapshot is written to the disk.
The issue is triggered in step 6. The AHCI interrupt should be delivered
to CPU0, however it is delivered to the original CPU31 instead, which
causes the "No irq handler" issue.
Ying Huang has provided a clue that, in step 3 it is possible that writing
to the register might not take effect as the PCI devices have been
suspended.
In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
in fact it is not. In __pci_write_msi_msg(), if the device is already in
low power state, the low level MSI message entry will not be updated but
cached. During the device restore process after a normal suspend/resume,
pci_restore_msi_state() writes the cached MSI back to the hardware.
But this is not the case for hibernation. pci_restore_msi_state() is not
currently called in pci_pm_thaw_noirq(), although pci_save_state() has
saved the necessary PCI cached information in pci_pm_freeze_noirq().
Restore the PCI status for the device during hibernation. Otherwise the
status might be lost across hibernation (for example, settings for MSI,
MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.
Suggested-by: Ying Huang <ying.huang@intel.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Rui Zhang <rui.zhang@intel.com>
Cc: Ying Huang <ying.huang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Mon, 3 Jul 2017 09:21:02 +0000 (17:21 +0800)]
PCI: rockchip: Use normal register bank for config accessors
commit
dc8cca5ef25ac4cb0dfc37467521a759767ff361 upstream.
Rockchip's RC has two banks of registers for the root port: a normal bank
that is strictly compatible with the PCIe spec, and a privileged bank that
can be used to change RO bits of root port registers.
When probing the RC driver, we use the privileged bank to do some basic
setup work as some RO bits are hw-inited to wrong value. But we didn't
change to the normal bank after probing the driver.
This leads to a serious problem when the PME code tries to clear the PME
status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA. Per
PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C. So the PME code
is doing the right thing to clear the PME status but we find the RC doesn't
clear it but actually setting it to one. So finally the system trap in
pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever. This issue
can be reproduced by booting kernel with pci=nomsi.
Use the normal register bank for the PCI config accessors. The privileged
bank is used only internally by this driver.
Fixes:
e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Fri, 19 Aug 2016 08:30:25 +0000 (16:30 +0800)]
PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11
commit
13cfc732160f7bc7e596128ce34cda361c556966 upstream.
Neither soft poweroff (transition to ACPI power state S5) nor
suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and
11,5.
The problem is related to the [mem 0x7fa00000-0x7fbfffff] space. When we
use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI
Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work
anymore.
Linux does a soft poweroff (transition to S5) by writing to PM1_CNT. The
theory about why this doesn't work is:
- The write to PM1_CNT causes an SMI
- The BIOS SMI handler depends on something in
[mem 0x7fa00000-0x7fbfffff]
- When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it
covers up whatever the SMI handler uses, so the SMI handler no longer
works correctly
Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to
anything.
This is voodoo programming, since we don't know what the real conflict is,
but we've failed to find the root cause.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
Tested-by: thejoe@gmail.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>