An error occurred fetching the project authors.
  1. 09 Mar, 2016 22 commits
    • Mike Christie's avatar
      target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors · 3028963a
      Mike Christie authored
      commit 8a9ebe71 upstream.
      
      In a couple places we are not converting to/from the Linux
      block layer 512 bytes sectors.
      
      1.
      
      The request queue values and what we do are a mismatch of
      things:
      
      max_discard_sectors - This is in linux block layer 512 byte
      sectors. We are just copying this to max_unmap_lba_count.
      
      discard_granularity - This is in bytes. We are converting it
      to Linux block layer 512 byte sectors.
      
      discard_alignment - This is in bytes. We are just copying
      this over.
      
      The problem is that the core LIO code exports these values in
      spc_emulate_evpd_b0 and we use them to test request arguments
      in sbc_execute_unmap, but we never convert to the block size
      we export to the initiator. If we are not using 512 byte sectors
      then we are exporting the wrong values or are checks are off.
      And, for the discard_alignment/bytes case we are just plain messed
      up.
      
      2.
      
      blkdev_issue_discard's start and number of sector arguments
      are supposed to be in linux block layer 512 byte sectors. We are
      currently passing in the values we get from the initiator which
      might be based on some other sector size.
      
      There is a similar problem in iblock_execute_write_same where
      the bio functions want values in 512 byte sectors but we are
      passing in what we got from the initiator.
      Signed-off-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ kamal: backport to 4.4-stable: no unmap_zeroes_data ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3028963a
    • Joerg Roedel's avatar
      iommu/vt-d: Use BUS_NOTIFY_REMOVED_DEVICE in hotplug path · 00548ecf
      Joerg Roedel authored
      commit e6a8c9b3 upstream.
      
      In the PCI hotplug path of the Intel IOMMU driver, replace
      the usage of the BUS_NOTIFY_DEL_DEVICE notifier, which is
      executed before the driver is unbound from the device, with
      BUS_NOTIFY_REMOVED_DEVICE, which runs after that.
      
      This fixes a kernel BUG being triggered in the VT-d code
      when the device driver tries to unmap DMA buffers and the
      VT-d driver already destroyed all mappings.
      Reported-by: default avatarStefani Seibold <stefani@seibold.net>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00548ecf
    • Suravee Suthikulpanit's avatar
      iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered · 44792d5c
      Suravee Suthikulpanit authored
      commit 38e45d02 upstream.
      
      The setup code for the performance counters in the AMD IOMMU driver
      tests whether the counters can be written. It tests to setup a counter
      for device 00:00.0, which fails on systems where this particular device
      is not covered by the IOMMU.
      
      Fix this by not relying on device 00:00.0 but only on the IOMMU being
      present.
      Signed-off-by: default avatarSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44792d5c
    • Jay Cornwall's avatar
      iommu/amd: Apply workaround for ATS write permission check · ad0f9dad
      Jay Cornwall authored
      commit 358875fd upstream.
      
      The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's
      Guide omitted part of the BIOS IOMMU L2 register setup specification.
      Without this setup the IOMMU L2 does not fully respect write permissions
      when handling an ATS translation request.
      
      The IOMMU L2 will set PTE dirty bit when handling an ATS translation with
      write permission request, even when PTE RW bit is clear. This may occur by
      direct translation (which would cause a PPR) or by prefetch request from
      the ATC.
      
      This is observed in practice when the IOMMU L2 modifies a PTE which maps a
      pagecache page. The ext4 filesystem driver BUGs when asked to writeback
      these (non-modified) pages.
      
      Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.
      Signed-off-by: default avatarJay Cornwall <jay@jcornwall.me>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad0f9dad
    • Michael S. Tsirkin's avatar
      arm/arm64: KVM: Fix ioctl error handling · d1c623c9
      Michael S. Tsirkin authored
      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: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1c623c9
    • Paolo Bonzini's avatar
      KVM: x86: fix root cause for missed hardware breakpoints · 25e86186
      Paolo Bonzini authored
      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: default avatarXiao Guangrong <guangrong.xiao@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25e86186
    • Michael S. Tsirkin's avatar
      vfio: fix ioctl error handling · 7931825d
      Michael S. Tsirkin authored
      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: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7931825d
    • Yadan Fan's avatar
      Fix cifs_uniqueid_to_ino_t() function for s390x · bbb3c507
      Yadan Fan authored
      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: default avatarYadan Fan <ydfan@suse.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbb3c507
    • Pavel Shilovsky's avatar
      CIFS: Fix SMB2+ interim response processing for read requests · b52a3958
      Pavel Shilovsky authored
      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: default avatarPavel Shilovsky <pshilovsky@samba.org>
      Tested-by: default avatarShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b52a3958
    • Justin Maggard's avatar
      cifs: fix out-of-bounds access in lease parsing · 77f0cc0e
      Justin Maggard authored
      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: default avatarJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77f0cc0e
    • Jean-Philippe Brucker's avatar
      fbcon: set a default value to blink interval · 2f553b9b
      Jean-Philippe Brucker authored
      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: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Tested-by: default avatarScot Doyle <lkml14@scotdoyle.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f553b9b
    • Owen Hofmann's avatar
      kvm: x86: Update tsc multiplier on change. · 8cedd1c0
      Owen Hofmann authored
      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: default avatarOwen Hofmann <osh@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cedd1c0
    • Michael S. Tsirkin's avatar
      mips/kvm: fix ioctl error handling · ce16d9cf
      Michael S. Tsirkin authored
      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: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce16d9cf
    • Helge Deller's avatar
      parisc: Fix ptrace syscall number and return value modification · 59dc7ab2
      Helge Deller authored
      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: default avatarHelge Deller <deller@gmx.de>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Tested-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59dc7ab2
    • Murali Karicheri's avatar
      PCI: keystone: Fix MSI code that retrieves struct pcie_port pointer · 5bbc2b41
      Murali Karicheri authored
      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: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Zhou Wang <wangzhou1@hisilicon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bbc2b41
    • Keith Busch's avatar
      block: Initialize max_dev_sectors to 0 · 9ec19090
      Keith Busch authored
      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: default avatarKeith Busch <keith.busch@intel.com>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ec19090
    • Oded Gabbay's avatar
    • Qu Wenruo's avatar
      btrfs: async-thread: Fix a use-after-free error for trace · d60a3749
      Qu Wenruo authored
      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: default avatarDave Jones <davej@codemonkey.org.uk>
      Signed-off-by: default avatarQu Wenruo <quwenruo@cn.fujitsu.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d60a3749
    • Zhao Lei's avatar
      btrfs: Fix no_space in write and rm loop · 08acfd9d
      Zhao Lei authored
      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: default avatarZhao Lei <zhaolei@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08acfd9d
    • Filipe Manana's avatar
      Btrfs: fix deadlock running delayed iputs at transaction commit time · 2232d6dc
      Filipe Manana authored
      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: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2232d6dc
    • Geert Uytterhoeven's avatar
      drivers: sh: Restore legacy clock domain on SuperH platforms · ad1d8666
      Geert Uytterhoeven authored
      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: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad1d8666
    • Al Viro's avatar
      use ->d_seq to get coherency between ->d_inode and ->d_flags · 53729dbb
      Al Viro authored
      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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53729dbb
  2. 03 Mar, 2016 18 commits