1. 01 Dec, 2018 22 commits
  2. 27 Nov, 2018 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.141 · bb2d990b
      Greg Kroah-Hartman authored
      bb2d990b
    • Ilya Dryomov's avatar
      libceph: fall back to sendmsg for slab pages · c3ec4e5b
      Ilya Dryomov authored
      commit 7e241f64 upstream.
      
      skb_can_coalesce() allows coalescing neighboring slab objects into
      a single frag:
      
        return page == skb_frag_page(frag) &&
               off == frag->page_offset + skb_frag_size(frag);
      
      ceph_tcp_sendpage() can be handed slab pages.  One example of this is
      XFS: it passes down sector sized slab objects for its metadata I/O.  If
      the kernel client is co-located on the OSD node, the skb may go through
      loopback and pop on the receive side with the exact same set of frags.
      When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy
      complains because the size exceeds the object's allocated size:
      
        usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes)
      
      Although skb_can_coalesce() could be taught to return false if the
      resulting frag would cross a slab object boundary, we already have
      a fallback for non-refcounted pages.  Utilize it for slab pages too.
      
      Cc: stable@vger.kernel.org # 4.8+
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3ec4e5b
    • Eric Biggers's avatar
      HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges · ab26f7fd
      Eric Biggers authored
      commit 8c01db76 upstream.
      
      When a UHID_CREATE command is written to the uhid char device, a
      copy_from_user() is done from a user pointer embedded in the command.
      When the address limit is KERNEL_DS, e.g. as is the case during
      sys_sendfile(), this can read from kernel memory.  Alternatively,
      information can be leaked from a setuid binary that is tricked to write
      to the file descriptor.  Therefore, forbid UHID_CREATE in these cases.
      
      No other commands in uhid_char_write() are affected by this bug and
      UHID_CREATE is marked as "obsolete", so apply the restriction to
      UHID_CREATE only rather than to uhid_char_write() entirely.
      
      Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
      Jann Horn for commit 9da3f2b7 ("x86/fault: BUG() when uaccess
      helpers fault on kernel addresses"), allowing this bug to be found.
      
      Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com
      Fixes: d365c6cf ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
      Cc: <stable@vger.kernel.org> # v3.6+
      Cc: Jann Horn <jannh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab26f7fd
    • Al Viro's avatar
      new helper: uaccess_kernel() · 2cf6ba5b
      Al Viro authored
      commit db68ce10 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [only take the include/linux/uaccess.h portion - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cf6ba5b
    • Hans de Goede's avatar
      ACPI / platform: Add SMB0001 HID to forbidden_id_list · ea41e453
      Hans de Goede authored
      commit 2bbb5fa3 upstream.
      
      Many HP AMD based laptops contain an SMB0001 device like this:
      
      Device (SMBD)
      {
          Name (_HID, "SMB0001")  // _HID: Hardware ID
          Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
          {
              IO (Decode16,
                  0x0B20,             // Range Minimum
                  0x0B20,             // Range Maximum
                  0x20,               // Alignment
                  0x20,               // Length
                  )
              IRQ (Level, ActiveLow, Shared, )
                  {7}
          })
      }
      
      The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
      be called with legacy=true and this message to show in dmesg:
      ACPI: IRQ 7 override to edge, high
      
      This causes issues when later on the AMD0030 GPIO device gets enumerated:
      
      Device (GPIO)
      {
          Name (_HID, "AMDI0030")  // _HID: Hardware ID
          Name (_CID, "AMDI0030")  // _CID: Compatible ID
          Name (_UID, Zero)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
      	Name (RBUF, ResourceTemplate ()
      	{
      	    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
      	    {
      		0x00000007,
      	    }
      	    Memory32Fixed (ReadWrite,
      		0xFED81500,         // Address Base
      		0x00000400,         // Address Length
      		)
      	})
      	Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
          }
      }
      
      Now acpi_dev_get_irqresource() gets called with legacy=false, but because
      of the earlier override of the trigger-type acpi_register_gsi() returns
      -EBUSY (because we try to register the same interrupt with a different
      trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
      
      The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
      acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
      resulting in the following in dmesg:
      
      amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
      amd_gpio: probe of AMDI0030:00 failed with error -22
      
      The SMB0001 is a "virtual" device in the sense that the only way the OS
      interacts with it is through calling a couple of methods to do SMBus
      transfers. As such it is weird that it has IO and IRQ resources at all,
      because the driver for it is not expected to ever access the hardware
      directly.
      
      The Linux driver for the SMB0001 device directly binds to the acpi_device
      through the acpi_bus, so we do not need to instantiate a platform_device
      for this ACPI device. This commit adds the SMB0001 HID to the
      forbidden_id_list, avoiding the instantiating of a platform_device for it.
      Not instantiating a platform_device means we will no longer call
      acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
      the AMDI0030 device failing.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523Reported-by: default avatarLukas Kahnert <openproggerfreak@gmail.com>
      Tested-by: default avatarMarc <suaefar@googlemail.com>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea41e453
    • Gustavo A. R. Silva's avatar
      drivers/misc/sgi-gru: fix Spectre v1 vulnerability · 7810fe9f
      Gustavo A. R. Silva authored
      commit fee05f45 upstream.
      
      req.gid can be indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
      potential spectre issue 'gru_base' [w]
      
      Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
      uses it to index gru_base.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7810fe9f
    • Mattias Jacobsson's avatar
      USB: misc: appledisplay: add 20" Apple Cinema Display · fdddfd7f
      Mattias Jacobsson authored
      commit f6501f49 upstream.
      
      Add another Apple Cinema Display to the list of supported displays
      Signed-off-by: default avatarMattias Jacobsson <2pi@mok.nu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdddfd7f
    • Nathan Chancellor's avatar
      misc: atmel-ssc: Fix section annotation on atmel_ssc_get_driver_data · f1b4d95e
      Nathan Chancellor authored
      commit 7c973012 upstream.
      
      After building the kernel with Clang, the following section mismatch
      warning appears:
      
      WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from
      the function ssc_probe() to the function
      .init.text:atmel_ssc_get_driver_data()
      The function ssc_probe() references
      the function __init atmel_ssc_get_driver_data().
      This is often because ssc_probe lacks a __init
      annotation or the annotation of atmel_ssc_get_driver_data is wrong.
      
      Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1b4d95e
    • Emmanuel Pescosta's avatar
      usb: quirks: Add delay-init quirk for Corsair K70 LUX RGB · 305a97a9
      Emmanuel Pescosta authored
      commit a7711257 upstream.
      
      Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
      Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to
      start correctly at boot.
      
      Dmesg output:
      usb 1-6: string descriptor 0 read error: -110
      usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33
      usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 1-6: can't set config #1, error -110
      Signed-off-by: default avatarEmmanuel Pescosta <emmanuelpescosta099@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      305a97a9
    • Kai-Heng Feng's avatar
      USB: quirks: Add no-lpm quirk for Raydium touchscreens · 148b90c1
      Kai-Heng Feng authored
      commit deefd242 upstream.
      
      Raydium USB touchscreen fails to set config if LPM is enabled:
      [    2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119
      [    2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      [    2.030660] usb 1-8: Product: Raydium Touch System
      [    2.030661] usb 1-8: Manufacturer: Raydium Corporation
      [    7.132209] usb 1-8: can't set config #1, error -110
      
      Same behavior can be observed on 2386:3114.
      
      Raydium claims the touchscreen supports LPM under Windows, so I used
      Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows
      that the LPM doesn't work under Windows, either. So let's just disable LPM
      for Raydium touchscreens.
      
      [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-toolsSigned-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      148b90c1
    • Maarten Jacobs's avatar
      usb: cdc-acm: add entry for Hiro (Conexant) modem · 9f08cfeb
      Maarten Jacobs authored
      commit 63529eaa upstream.
      
      The cdc-acm kernel module currently does not support the Hiro (Conexant)
      H05228 USB modem. The patch below adds the device specific information:
      	idVendor	0x0572
      	idProduct	0x1349
      Signed-off-by: default avatarMaarten Jacobs <maarten256@outlook.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f08cfeb
    • Dan Carpenter's avatar
      uio: Fix an Oops on load · bb5f531d
      Dan Carpenter authored
      commit 43279819 upstream.
      
      I was trying to solve a double free but I introduced a more serious
      NULL dereference bug.  The problem is that if there is an IRQ which
      triggers immediately, then we need "info->uio_dev" but it's not set yet.
      
      This patch puts the original initialization back to how it was and just
      sets info->uio_dev to NULL on the error path so it should solve both
      the Oops and the double free.
      
      Fixes: f019f07e ("uio: potential double frees if __uio_register_device() fails")
      Reported-by: default avatarMathias Thore <Mathias.Thore@infinera.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarMathias Thore <Mathias.Thore@infinera.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb5f531d
    • Sakari Ailus's avatar
      media: v4l: event: Add subscription to list before calling "add" operation · 496f98c0
      Sakari Ailus authored
      commit 92539d3e upstream.
      
      Patch ad608fbc changed how events were subscribed to address an issue
      elsewhere. As a side effect of that change, the "add" callback was called
      before the event subscription was added to the list of subscribed events,
      causing the first event queued by the add callback (and possibly other
      events arriving soon afterwards) to be lost.
      
      Fix this by adding the subscription to the list before calling the "add"
      callback, and clean up afterwards if that fails.
      
      Fixes: ad608fbc ("media: v4l: event: Prevent freeing event subscriptions while accessed")
      Reported-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.org>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Tested-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.org>
      Reviewed-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Tested-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org (for 4.14 and up)
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      [Sakari Ailus: Backported to v4.9 stable]
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      496f98c0
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV" · 93848099
      Greg Kroah-Hartman authored
      This reverts commit b5c98d8c which is
      commit 6c3711ec upstream.
      
      You Ling writes that this config option isn't even in 4.9.y yet, so it
      causes a regression.  Revert the patch because of this.
      Reported-by: default avataryouling 257 <youling257@gmail.com>
      Cc: Johan Hedberg <johan.hedberg@intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Sasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93848099
    • Hans Verkuil's avatar
      Revert "media: videobuf2-core: don't call memop 'finish' when queueing" · a540483b
      Hans Verkuil authored
      This reverts commit 9ac47200.
      
      This commit fixes a bug in upstream commit a136f59c ("vb2: Move
      buffer cache synchronisation to prepare from queue") which isn't
      present in 4.9.
      
      So as a result you get an UNBALANCED message in the kernel log if
      this patch is applied:
      
      vb2:   counters for queue ffffffc0f3687478, buffer 3: UNBALANCED!
      vb2:     buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
      vb2:     buf_queue: 806 buf_done: 806
      vb2:     alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
      vb2:     get_userptr: 0 put_userptr: 0
      vb2:     attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
      vb2:     get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805
      
      Reverting this patch solves this regression.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a540483b
    • Lu Fengqi's avatar
      btrfs: fix pinned underflow after transaction aborted · 33f3f3bd
      Lu Fengqi authored
      commit fcd5e742 upstream.
      
      When running generic/475, we may get the following warning in dmesg:
      
      [ 6902.102154] WARNING: CPU: 3 PID: 18013 at fs/btrfs/extent-tree.c:9776 btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
      [ 6902.109160] CPU: 3 PID: 18013 Comm: umount Tainted: G        W  O      4.19.0-rc8+ #8
      [ 6902.110971] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      [ 6902.112857] RIP: 0010:btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
      [ 6902.118921] RSP: 0018:ffffc9000459bdb0 EFLAGS: 00010286
      [ 6902.120315] RAX: ffff880175050bb0 RBX: ffff8801124a8000 RCX: 0000000000170007
      [ 6902.121969] RDX: 0000000000000002 RSI: 0000000000170007 RDI: ffffffff8125fb74
      [ 6902.123716] RBP: ffff880175055d10 R08: 0000000000000000 R09: 0000000000000000
      [ 6902.125417] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880175055d88
      [ 6902.127129] R13: ffff880175050bb0 R14: 0000000000000000 R15: dead000000000100
      [ 6902.129060] FS:  00007f4507223780(0000) GS:ffff88017ba00000(0000) knlGS:0000000000000000
      [ 6902.130996] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 6902.132558] CR2: 00005623599cac78 CR3: 000000014b700001 CR4: 00000000003606e0
      [ 6902.134270] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 6902.135981] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 6902.137836] Call Trace:
      [ 6902.138939]  close_ctree+0x171/0x330 [btrfs]
      [ 6902.140181]  ? kthread_stop+0x146/0x1f0
      [ 6902.141277]  generic_shutdown_super+0x6c/0x100
      [ 6902.142517]  kill_anon_super+0x14/0x30
      [ 6902.143554]  btrfs_kill_super+0x13/0x100 [btrfs]
      [ 6902.144790]  deactivate_locked_super+0x2f/0x70
      [ 6902.146014]  cleanup_mnt+0x3b/0x70
      [ 6902.147020]  task_work_run+0x9e/0xd0
      [ 6902.148036]  do_syscall_64+0x470/0x600
      [ 6902.149142]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [ 6902.150375]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 6902.151640] RIP: 0033:0x7f45077a6a7b
      [ 6902.157324] RSP: 002b:00007ffd589f3e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
      [ 6902.159187] RAX: 0000000000000000 RBX: 000055e8eec732b0 RCX: 00007f45077a6a7b
      [ 6902.160834] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000055e8eec73490
      [ 6902.162526] RBP: 0000000000000000 R08: 000055e8eec734b0 R09: 00007ffd589f26c0
      [ 6902.164141] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e8eec73490
      [ 6902.165815] R13: 00007f4507ac61a4 R14: 0000000000000000 R15: 00007ffd589f40d8
      [ 6902.167553] irq event stamp: 0
      [ 6902.168998] hardirqs last  enabled at (0): [<0000000000000000>]           (null)
      [ 6902.170731] hardirqs last disabled at (0): [<ffffffff810cd810>] copy_process.part.55+0x3b0/0x1f00
      [ 6902.172773] softirqs last  enabled at (0): [<ffffffff810cd810>] copy_process.part.55+0x3b0/0x1f00
      [ 6902.174671] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [ 6902.176407] ---[ end trace 463138c2986b275c ]---
      [ 6902.177636] BTRFS info (device dm-3): space_info 4 has 273465344 free, is not full
      [ 6902.179453] BTRFS info (device dm-3): space_info total=276824064, used=4685824, pinned=18446744073708158976, reserved=0, may_use=0, readonly=65536
      
      In the above line there's "pinned=18446744073708158976" which is an
      unsigned u64 value of -1392640, an obvious underflow.
      
      When transaction_kthread is running cleanup_transaction(), another
      fsstress is running btrfs_commit_transaction(). The
      btrfs_finish_extent_commit() may get the same range as
      btrfs_destroy_pinned_extent() got, which causes the pinned underflow.
      
      Fixes: d4b450cd ("Btrfs: fix race between transaction commit and empty block group removal")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarLu Fengqi <lufq.fnst@cn.fujitsu.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      33f3f3bd
    • Qu Wenruo's avatar
      btrfs: Ensure btrfs_trim_fs can trim the whole filesystem · 4423e072
      Qu Wenruo authored
      Commit 6ba9fc8e upstream.
      
      [BUG]
      fstrim on some btrfs only trims the unallocated space, not trimming any
      space in existing block groups.
      
      [CAUSE]
      Before fstrim_range passed to btrfs_trim_fs(), it gets truncated to
      range [0, super->total_bytes).  So later btrfs_trim_fs() will only be
      able to trim block groups in range [0, super->total_bytes).
      
      While for btrfs, any bytenr aligned to sectorsize is valid, since btrfs
      uses its logical address space, there is nothing limiting the location
      where we put block groups.
      
      For filesystem with frequent balance, it's quite easy to relocate all
      block groups and bytenr of block groups will start beyond
      super->total_bytes.
      
      In that case, btrfs will not trim existing block groups.
      
      [FIX]
      Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs()
      can get the unmodified range, which is normally set to [0, U64_MAX].
      Reported-by: default avatarChris Murphy <lists@colorremedies.com>
      Fixes: f4c697e6 ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl")
      CC: <stable@vger.kernel.org> # v4.9
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [ change parameter from @fs_info to @fs_info->root for older kernel ]
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4423e072
    • Qu Wenruo's avatar
      btrfs: Enhance btrfs_trim_fs function to handle error better · fc43e4cd
      Qu Wenruo authored
      Commit 93bba24d upstream.
      
      Function btrfs_trim_fs() doesn't handle errors in a consistent way. If
      error happens when trimming existing block groups, it will skip the
      remaining blocks and continue to trim unallocated space for each device.
      
      The return value will only reflect the final error from device trimming.
      
      This patch will fix such behavior by:
      
      1) Recording the last error from block group or device trimming
         The return value will also reflect the last error during trimming.
         Make developer more aware of the problem.
      
      2) Continuing trimming if possible
         If we failed to trim one block group or device, we could still try
         the next block group or device.
      
      3) Report number of failures during block group and device trimming
         It would be less noisy, but still gives user a brief summary of
         what's going wrong.
      
      Such behavior can avoid confusion for cases like failure to trim the
      first block group and then only unallocated space is trimmed.
      Reported-by: default avatarChris Murphy <lists@colorremedies.com>
      CC: stable@vger.kernel.org # 4.9
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ add bg_ret and dev_ret to the messages ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [ change parameter from @fs_info to @fs_info->root for older kernel ]
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fc43e4cd