- 06 Apr, 2016 40 commits
-
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 4cad67fc upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up kvm to do return copy_to_user(...)) ? -EFAULT : 0; everywhere. Acked-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 70e4da7a upstream. Commit 172b2386 ("KVM: x86: fix missed hardware breakpoints", 2016-02-10) worked around a case where the debug registers are not loaded correctly on preemption and on the first entry to KVM_RUN. However, Xiao Guangrong pointed out that the root cause must be that KVM_DEBUGREG_BP_ENABLED is not being set correctly. This can indeed happen due to the lazy debug exit mechanism, which does not call kvm_update_dr7. Fix it by replacing the existing loop (more or less equivalent to kvm_update_dr0123) with calls to all the kvm_update_dr* functions. Fixes: 172b2386Reviewed-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 8160c4e4 upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up vfio to do return copy_to_user(...)) ? -EFAULT : 0; everywhere. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Yadan Fan authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 1ee9f4bd upstream. This issue is caused by commit 02323db1 ("cifs: fix cifs_uniqueid_to_ino_t not to ever return 0"), when BITS_PER_LONG is 64 on s390x, the corresponding cifs_uniqueid_to_ino_t() function will cast 64-bit fileid to 32-bit by using (ino_t)fileid, because ino_t (typdefed __kernel_ino_t) is int type. It's defined in arch/s390/include/uapi/asm/posix_types.h #ifndef __s390x__ typedef unsigned long __kernel_ino_t; ... #else /* __s390x__ */ typedef unsigned int __kernel_ino_t; So the #ifdef condition is wrong for s390x, we can just still use one cifs_uniqueid_to_ino_t() function with comparing sizeof(ino_t) and sizeof(u64) to choose the correct execution accordingly. Signed-off-by:
Yadan Fan <ydfan@suse.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 6cc3b242 upstream. For interim responses we only need to parse a header and update a number credits. Now it is done for all SMB2+ command except SMB2_READ which is wrong. Fix this by adding such processing. Signed-off-by:
Pavel Shilovsky <pshilovsky@samba.org> Tested-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
-
Justin Maggard authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit deb7deff upstream. When opening a file, SMB2_open() attempts to parse the lease state from the SMB2 CREATE Response. However, the parsing code was not careful to ensure that the create contexts are not empty or invalid, which can lead to out- of-bounds memory access. This can be seen easily by trying to read a file from a OSX 10.11 SMB3 server. Here is sample crash output: BUG: unable to handle kernel paging request at ffff8800a1a77cc6 IP: [<ffffffff8828a734>] SMB2_open+0x804/0x960 PGD 8f77067 PUD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14 Hardware name: NETGEAR ReadyNAS 314 /ReadyNAS 314 , BIOS 4.6.5 10/11/2012 task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000 RIP: 0010:[<ffffffff8828a734>] [<ffffffff8828a734>] SMB2_open+0x804/0x960 RSP: 0018:ffff88005b31fa08 EFLAGS: 00010282 RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0 RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866 R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800 R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0 FS: 00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0 Stack: ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80 ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000 ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0 Call Trace: [<ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0 [<ffffffff8828cf68>] smb2_open_file+0x98/0x210 [<ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0 [<ffffffff882685f4>] cifs_open+0x2a4/0x720 [<ffffffff88122cef>] do_dentry_open+0x1ff/0x310 [<ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30 [<ffffffff88123d92>] vfs_open+0x52/0x60 [<ffffffff88131dd0>] path_openat+0x170/0xf70 [<ffffffff88097d48>] ? remove_wait_queue+0x48/0x50 [<ffffffff88133a29>] do_filp_open+0x79/0xd0 [<ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170 [<ffffffff881240c4>] do_sys_open+0x114/0x1e0 [<ffffffff881241a9>] SyS_open+0x19/0x20 [<ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8 RIP [<ffffffff8828a734>] SMB2_open+0x804/0x960 RSP <ffff88005b31fa08> CR2: ffff8800a1a77cc6 ---[ end trace d9f69ba64feee469 ]--- Signed-off-by:
Justin Maggard <jmaggard@netgear.com> Signed-off-by:
-
Jean-Philippe Brucker authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit a1e533ec upstream. Since commit 27a4c827 fbcon: use the cursor blink interval provided by vt two attempts have been made at fixing a possible hang caused by cursor_timer_handler. That function registers a timer to be triggered at "jiffies + fbcon_ops.cur_blink_jiffies". A new case had been encountered during initialisation of clcd-pl11x: fbcon_fb_registered do_fbcon_takeover -> do_register_con_driver fbcon_startup (A) add_cursor_timer (with cur_blink_jiffies = 0) -> do_bind_con_driver visual_init fbcon_init (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); If we take an softirq anywhere between A and B (and we do), cursor_timer_handler executes indefinitely. Instead of patching all possible paths that lead to this case one at a time, fix the issue at the source and initialise cur_blink_jiffies to 200ms when allocating fbcon_ops. This was its default value before aforesaid commit. fbcon_cursor or fbcon_init will refine this value downstream. Signed-off-by:
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Tested-by:
Scot Doyle <lkml14@scotdoyle.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Owen Hofmann authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 2680d6da upstream. vmx.c writes the TSC_MULTIPLIER field in vmx_vcpu_load, but only when a vcpu has migrated physical cpus. Record the last value written and update in vmx_vcpu_load on any change, otherwise a cpu migration must occur for TSC frequency scaling to take effect. Fixes: ff2c3a18Signed-off-by:
Owen Hofmann <osh@google.com> Signed-off-by:
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 0178fd7d upstream. Returning directly whatever copy_to_user(...) or copy_from_user(...) returns may not do the right thing if there's a pagefault: copy_to_user/copy_from_user return the number of bytes not copied in this case, but ioctls need to return -EFAULT instead. Fix up kvm on mips to do return copy_to_user(...)) ? -EFAULT : 0; and return copy_from_user(...)) ? -EFAULT : 0; everywhere. Signed-off-by:
-
Helge Deller authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 98e8b6c9 upstream. Mike Frysinger reported that his ptrace testcase showed strange behaviour on parisc: It was not possible to avoid a syscall and the return value of a syscall couldn't be changed. To modify a syscall number, we were missing to save the new syscall number to gr20 which is then picked up later in assembly again. The effect that the return value couldn't be changed is a side-effect of another bug in the assembly code. When a process is ptraced, userspace expects each syscall to report entrance and exit of a syscall. If a syscall number was given which doesn't exist, we jumped to the normal syscall exit code instead of informing userspace that the (non-existant) syscall exits. This unexpected behaviour confuses userspace and thus the bug was misinterpreted as if we can't change the return value. This patch fixes both problems and was tested on 64bit kernel with 32bit userspace. Signed-off-by:
Helge Deller <deller@gmx.de> Cc: Mike Frysinger <vapier@gentoo.org> Tested-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Murali Karicheri authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 79e3f4a8 upstream. Commit cbce7900 ("PCI: designware: Make driver arch-agnostic") changed the host bridge sysdata pointer from the ARM pci_sys_data to the DesignWare pcie_port structure, and changed pcie-designware.c to reflect that. But it did not change the corresponding code in pci-keystone-dw.c, so it caused crashes on Keystone: Unable to handle kernel NULL pointer dereference at virtual address 00000030 pgd = c0003000 [00000030] *pgd=80000800004003, *pmd=00000000 Internal error: Oops: 206 [#1] PREEMPT SMP ARM CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.2-00139-gb74f926 #2 Hardware name: Keystone PC is at ks_dw_pcie_msi_irq_unmask+0x24/0x58 Change pci-keystone-dw.c to expect sysdata to be the struct pcie_port pointer. [bhelgaas: changelog] Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic") Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 5f009d3f upstream. The new queue limit is not used by the majority of block drivers, and should be initialized to 0 for the driver's requested settings to be used. Signed-off-by:
Keith Busch <keith.busch@intel.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Qu Wenruo authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 0a95b851 upstream. Parameter of trace_btrfs_work_queued() can be freed in its workqueue. So no one use use that pointer after queue_work(). Fix the user-after-free bug by move the trace line before queue_work(). Reported-by:
Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Zhao Lei authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit e1746e83 upstream. I see no_space in v4.4-rc1 again in xfstests generic/102. It happened randomly in some node only. (one of 4 phy-node, and a kvm with non-virtio block driver) By bisect, we can found the first-bad is: commit bdced438 ("block: setup bi_phys_segments after splitting")' But above patch only triggered the bug by making bio operation faster(or slower). Main reason is in our space_allocating code, we need to commit page writeback before wait it complish, this patch fixed above bug. BTW, there is another reason for generic/102 fail, caused by disable default mixed-blockgroup, I'll fix it in xfstests. Signed-off-by:
Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by:
-
Filipe Manana authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit c2d6cb16 upstream. While running a stress test I ran into a deadlock when running the delayed iputs at transaction time, which produced the following report and trace: [ 886.399989] ============================================= [ 886.400871] [ INFO: possible recursive locking detected ] [ 886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted [ 886.402384] --------------------------------------------- [ 886.403182] fio/8277 is trying to acquire lock: [ 886.403568] (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] but task is already holding lock: [ 886.403568] (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] other info that might help us debug this: [ 886.403568] Possible unsafe locking scenario: [ 886.403568] [ 886.403568] CPU0 [ 886.403568] ---- [ 886.403568] lock(&fs_info->delayed_iput_sem); [ 886.403568] lock(&fs_info->delayed_iput_sem); [ 886.403568] [ 886.403568] *** DEADLOCK *** [ 886.403568] [ 886.403568] May be due to missing lock nesting notation [ 886.403568] [ 886.403568] 3 locks held by fio/8277: [ 886.403568] #0: (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0 [ 886.403568] #1: (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs] [ 886.403568] #2: (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] stack backtrace: [ 886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [ 886.403568] 0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0 [ 886.403568] ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290 [ 886.403568] 0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804 [ 886.403568] Call Trace: [ 886.403568] [<ffffffff8125d4fd>] dump_stack+0x4e/0x79 [ 886.403568] [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b [ 886.403568] [<ffffffff810c22db>] ? __module_address+0xdf/0x108 [ 886.403568] [<ffffffff8108eb77>] lock_acquire+0x10d/0x194 [ 886.403568] [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194 [ 886.403568] [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [<ffffffff8148556b>] down_read+0x3e/0x4d [ 886.489542] [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs] [ 886.489542] [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs] [ 886.489542] [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs] [ 886.489542] [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs] [ 886.489542] [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs] [ 886.489542] [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs] [ 886.489542] [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs] [ 886.489542] [<ffffffff81188e31>] evict+0xa7/0x15c [ 886.489542] [<ffffffff81189878>] iput+0x1d3/0x266 [ 886.489542] [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs] [ 886.489542] [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs] [ 886.489542] [<ffffffff81085096>] ? signal_pending_state+0x31/0x31 [ 886.489542] [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs] [ 886.489542] [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs] [ 886.489542] [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs] [ 886.489542] [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs] [ 886.489542] [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128 [ 886.489542] [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs] [ 886.489542] [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50 [ 886.489542] [<ffffffff8117279e>] __vfs_write+0x7c/0xa5 [ 886.489542] [<ffffffff81172cda>] vfs_write+0xa0/0xe4 [ 886.489542] [<ffffffff811734cc>] SyS_write+0x50/0x7e [ 886.489542] [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds. [ 1081.854348] Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.863227] fio D ffff880213f9bb28 0 8244 8240 0x00000000 [ 1081.868719] ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240 [ 1081.872499] ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400 [ 1081.876834] ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4 [ 1081.880782] Call Trace: [ 1081.881793] [<ffffffff81482ba4>] schedule+0x7f/0x97 [ 1081.883340] [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325 [ 1081.895525] [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab [ 1081.897419] [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20 [ 1081.899251] [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20 [ 1081.901063] [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21 [ 1081.902365] [<ffffffff814855bd>] down_write+0x43/0x57 [ 1081.903846] [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1081.906078] [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1081.908846] [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c [ 1081.910409] [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs] [ 1081.912482] [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs] [ 1081.914597] [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs] [ 1081.919037] [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128 [ 1081.920754] [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs] [ 1081.922496] [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50 [ 1081.923922] [<ffffffff8117279e>] __vfs_write+0x7c/0xa5 [ 1081.925275] [<ffffffff81172cda>] vfs_write+0xa0/0xe4 [ 1081.926584] [<ffffffff811734cc>] SyS_write+0x50/0x7e [ 1081.927968] [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1081.985293] INFO: lockdep is turned off. [ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds. [ 1081.987434] Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.990147] fio D ffff880218febbb8 0 8249 8240 0x00000000 [ 1081.991626] ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240 [ 1081.993258] ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00 [ 1081.994850] ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4 [ 1081.996485] Call Trace: [ 1081.997037] [<ffffffff81482ba4>] schedule+0x7f/0x97 [ 1081.998017] [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325 [ 1081.999241] [<ffffffff810852a5>] ? finish_wait+0x6d/0x76 [ 1082.000306] [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20 [ 1082.001533] [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20 [ 1082.002776] [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21 [ 1082.003995] [<ffffffff814855bd>] down_write+0x43/0x57 [ 1082.005000] [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1082.007403] [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1082.008988] [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs] [ 1082.010193] [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77 [ 1082.011280] [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0 [ 1082.012265] [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0 [ 1082.013021] [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff [ 1082.013738] [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b [ 1082.014778] [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea [ 1082.015778] [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e [ 1082.016806] [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71 [ 1082.017789] [<ffffffff8118240e>] SyS_ioctl+0x57/0x79 [ 1082.018706] [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f This happens because we can recursively acquire the semaphore fs_info->delayed_iput_sem when attempting to allocate space to satisfy a file write request as shown in the first trace above - when committing a transaction we acquire (down_read) the semaphore before running the delayed iputs, and when running a delayed iput() we can end up calling an inode's eviction handler, which in turn commits another transaction and attempts to acquire (down_read) again the semaphore to run more delayed iput operations. This results in a deadlock because if a task acquires multiple times a semaphore it should invoke down_read_nested() with a different lockdep class for each level of recursion. Fix this by simplifying the implementation and use a mutex instead that is acquired by the cleaner kthread before it runs the delayed iputs instead of always acquiring a semaphore before delayed references are run from anywhere. Fixes: d7c15171 (btrfs: Fix NO_SPACE bug caused by delayed-iput) Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 0378ba48 upstream. CONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms (which are DT based and multi-platform), but also on a select set of Renesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence since commit 0ba58de2 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"), the legacy clock domain is no longer installed on these SuperH platforms, and module clocks may not be enabled when needed, leading to driver failures. To fix this, add an additional check for CONFIG_OF. Fixes: 0ba58de2 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Al Viro authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit a528aca7 upstream. Games with ordering and barriers are way too brittle. Just bump ->d_seq before and after updating ->d_inode and ->d_flags type bits, so that verifying ->d_seq would guarantee they are coherent. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1494350 "d1cd1210: x86, pageattr: Prevent overflow in slow_virt_to_phys() for X86_PAE" was unintentionally removed by the recent "34437e67: x86/mm: Fix slow_virt_to_phys() to handle large PAT bit". And, the variable 'phys_addr' was defined as "unsigned long" by mistake -- it should be "phys_addr_t". As a result, Hyper-V network driver in 32-PAE Linux guest can't work again. Fixes: commit 34437e67: "x86/mm: Fix slow_virt_to_phys() to handle large PAT bit" Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Toshi Kani <toshi.kani@hpe.com> Cc: olaf@aepfle.de Cc: gregkh@linuxfoundation.org Cc: jasowang@redhat.com Cc: driverdev-devel@linuxdriverproject.org Cc: linux-mm@kvack.org Cc: apw@canonical.com Cc: Andrew Morton <akpm@linux-foundation.org> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Link: http://lkml.kernel.org/r/1456394292-9030-1-git-send-email-decui@microsoft.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit bf70e551) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Stefan Berger authored
BugLink: http://bugs.launchpad.net/bugs/1398274 When the TPM response reception is interrupted in the wait_event_interruptable call, the TPM is still busy processing the command and will only deliver the response later. So we have to wait for an outstanding response before sending a new request to avoid trying to put a 2nd request into the CRQ. Also reset the res_len before sending a command so we will end up in that wait_event_interruptable() waiting for the response rather than reading the command packet as a response. The easiest way to trigger the problem is to run the following cd /sys/device/vio/71000004 while :; cat pcrs >/dev/null; done And press Ctrl-C. This will then display an error tpm_ibmvtpm 71000004: tpm_transmit: tpm_recv: error -4 followed by several other errors once interaction with the TPM resumes. tpm_ibmvtpm 71000004: A TPM error (101) occurred attempting to determine the number of PCRS. Signed-off-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Tested-by:
Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Ashley Lai <ashley@ashleylai.com> Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> (cherry picked from commit 6674ff14) Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 auto-probing doesn't work with shared interrupts, and the auto detection interrupt range is for x86 only. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by:
Martin Wilck <Martin.Wilck@ts.fujitsu.com> Tested-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Now that the probe and run cases are merged together we can use a much simpler setup flow where probe and normal setup are done with exactly the same code. Since the new flow always calls tpm_gen_interrupt to confirm the IRQ there is also no longer any need to call tpm_get_timeouts twice. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The new code that works directly in tpm_tis_send is able to handle IRQ probing duties as well, so just use it for everything. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 IRQ probing needs to know that the TPM is working before trying to probe, so move tpm_get_timeouts() to the top of the tpm_tis_init(). This has the advantage of also getting the correct timeouts loaded before doing IRQ probing. All the timeout handling code is moved to tpm_get_timeouts() in order to remove duplicate code in tpm_tis and tpm_crb. [jarkko.sakkinen@linux.intel.com: squashed two patches together and improved the commit message.] Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 This should be done very early, before anything could possibly cause the TPM to generate an interrupt. If the IRQ line is shared with another driver causing an interrupt before setting up our handler will be very bad. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The interrupt is always allocated with devm_request_irq so it must always be freed with devm_free_irq. Fixes: 448e9c55 ("tpm_tis: verify interrupt during init") Signed-off-by:
-
Martin Wilck authored
BugLink: http://bugs.launchpad.net/bugs/1398274 commit 07b133e6 ("char/tpm: simplify duration calculation and eliminate smatch warning.") includes a misleading test that is always false. The tpm_ordinal_duration table is only valid for TPM_PROTECTED ordinals where the higher 16 bits are all 0, anyway. Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555033Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555033Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555033Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555033Signed-off-by:
-
Tim Gardner authored
Signed-off-by: -
Tim Gardner authored
The diff cannot represent when files are moved. Signed-off-by: -
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1543683 Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nick Bowler <nbowler@draconx.ca> References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.htmlReported-by:
Nick Bowler <nbowler@draconx.ca> Cc: stable@vger.kernel.org Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 0780cd36) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> (back ported from commit 8d409cb3) Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1543165Signed-off-by:
-
Parthasarathy Bhuvaragan authored
commit 4d5cfcba ('tipc: fix connection abort during subscription cancel'), removes the check for a valid subscription before calling tipc_nametbl_subscribe(). This will lead to a nullptr exception when we process a subscription cancel request. For a cancel request, a null subscription is passed to tipc_nametbl_subscribe() resulting in exception. In this commit, we call tipc_nametbl_subscribe() only for a valid subscription. Fixes: 4d5cfcba ('tipc: fix connection abort during subscription cancel') Reported-by:
Anders Widell <anders.widell@ericsson.com> Signed-off-by:
Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 4de13d7e) Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1554608 This reverts commit dbb17a21. It turns out that commit can cause problems for systems with multiple GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid graphics. This got noticed originally in 4.4.4, where this patch had already gotten back-ported, but 4.5-rc7 was verified to have the same problem. Alexander Deucher says: "It looks like you have a muxed system so I suspect what's happening is that one of the display is being reported as connected for both the IGP and the dGPU and then the desktop environment gets confused or there some sort problem in the detect functions since the mux is not switched to the dGPU. I don't see an easy fix unless Dave has any ideas. I'd say just revert for now" Reported-by:
Jörg-Volker Peetz <jvpeetz@web.de> Acked-by:
Alexander Deucher <Alexander.Deucher@amd.com> Cc: Dave Airlie <airlied@gmail.com> Cc: stable@kernel.org # wherever dbb17a21 got back-ported Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 256faedc) Signed-off-by:
-
Andrew Pinski authored
On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI instructions may cause the icache to become corrupted if it contains data for a non-current ASID. This patch implements the workaround (which invalidates the local icache when switching the mm) by using code patching. Signed-off-by:
Andrew Pinski <apinski@cavium.com> Signed-off-by:
David Daney <david.daney@cavium.com> Reviewed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (cherry picked from linux-next commit 104a0c02) [ dannf: dropped Documentation/ change to file that didn't exist in v4.4; Adjusted cpu errata numbers for v4.4 ] Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
