1. 01 Dec, 2018 23 commits
  2. 27 Nov, 2018 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.165 · 2757e11b
      Greg Kroah-Hartman authored
    • Mathias Nyman's avatar
      xhci: Fix USB3 NULL pointer dereference at logical disconnect. · d57a6bb2
      Mathias Nyman authored
      commit 2278446e2b7cd33ad894b32e7eb63afc7db6c86e upstream.
      Hub driver will try to disable a USB3 device twice at logical disconnect,
      racing with xhci_free_dev() callback from the first port disable.
      This can be triggered with "udisksctl power-off --block-device <disk>"
      or by writing "1" to the "remove" sysfs file for a USB3 device
      in 4.17-rc4.
      USB3 devices don't have a similar disabled link state as USB2 devices,
      and use a U3 suspended link state instead. In this state the port
      is still enabled and connected.
      hub_port_connect() first disconnects the device, then later it notices
      that device is still enabled (due to U3 states) it will try to disable
      the port again (set to U3).
      The xhci_free_dev() called during device disable is async, so checking
      for existing xhci->devs[i] when setting link state to U3 the second time
      was successful, even if device was being freed.
      The regression was caused by, and whole thing revealed by,
      Commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
      which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned.
      and causes a NULL pointer dereference the second time we try to set U3.
      Fix this by checking xhci->devs[i]->udev exists before setting link state.
      The original patch went to stable so this fix needs to be applied there as
      Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Tested-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Biggers's avatar
      HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges · 645cb396
      Eric Biggers authored
      commit 8c01db7619f07c85c5cd81ec5eb83608b56c88f5 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 9da3f2b740544 ("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>
    • Al Viro's avatar
      new helper: uaccess_kernel() · 342bd595
      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>
    • Hans de Goede's avatar
      ACPI / platform: Add SMB0001 HID to forbidden_id_list · 7f0052a8
      Hans de Goede authored
      commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa 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, )
      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, ,, )
      	    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
      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>
    • Gustavo A. R. Silva's avatar
      drivers/misc/sgi-gru: fix Spectre v1 vulnerability · b61865ef
      Gustavo A. R. Silva authored
      commit fee05f455ceb5c670cbe48e2f9454ebc4a388554 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>
    • Mattias Jacobsson's avatar
      USB: misc: appledisplay: add 20" Apple Cinema Display · 1b44cb3b
      Mattias Jacobsson authored
      commit f6501f49199097b99e4e263644d88c90d1ec1060 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>
    • Nathan Chancellor's avatar
      misc: atmel-ssc: Fix section annotation on atmel_ssc_get_driver_data · 285745ac
      Nathan Chancellor authored
      commit 7c97301285b62a41d6bceded7d964085fc8cc50f 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
      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>
    • Emmanuel Pescosta's avatar
      usb: quirks: Add delay-init quirk for Corsair K70 LUX RGB · 095ead16
      Emmanuel Pescosta authored
      commit a77112577667cbda7c6292c52d909636aef31fd9 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>
    • Kai-Heng Feng's avatar
      USB: quirks: Add no-lpm quirk for Raydium touchscreens · f88d08ec
      Kai-Heng Feng authored
      commit deefd24228a172d1b27d4a9adbfd2cdacd60ae64 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>
    • Maarten Jacobs's avatar
      usb: cdc-acm: add entry for Hiro (Conexant) modem · 7b3bf88e
      Maarten Jacobs authored
      commit 63529eaa6164ef7ab4b907b25ac3648177e5e78f 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>
    • Dan Carpenter's avatar
      uio: Fix an Oops on load · 1582f07e
      Dan Carpenter authored
      commit 432798195bbce1f8cd33d1c0284d0538835e25fb 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: f019f07ecf6a ("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>
    • Sakari Ailus's avatar
      media: v4l: event: Add subscription to list before calling "add" operation · 4bda4fd0
      Sakari Ailus authored
      commit 92539d3eda2c090b382699bbb896d4b54e9bdece upstream.
      Patch ad608fbcf166 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: ad608fbcf166 ("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>
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV" · 549a22b8
      Greg Kroah-Hartman authored
      This reverts commit 5824d86b which is
      commit 6c3711ec64fd23a9abc8aaf59a9429569a6282df upstream.
      You Ling writes that this config option isn't even in 4.4.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>
    • Hans Verkuil's avatar
      Revert "media: videobuf2-core: don't call memop 'finish' when queueing" · 411a5050
      Hans Verkuil authored
      This reverts commit 46431d9c.
      This commit fixes a bug in upstream commit a136f59c ("vb2: Move
      buffer cache synchronisation to prepare from queue") which isn't
      present in 4.4.
      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>
    • Lu Fengqi's avatar
      btrfs: fix pinned underflow after transaction aborted · 37944cba
      Lu Fengqi authored
      commit fcd5e74288f7d36991b1f0fb96b8c57079645e38 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>
    • Andreas Gruenbacher's avatar
      gfs2: Put bitmap buffers in put_super · 00112fda
      Andreas Gruenbacher authored
      commit 10283ea525d30f2e99828978fd04d8427876a7ad upstream.
      gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
      attached to the resource group glocks.  That function should release the
      buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
      gfs2_rgrp_brelse for doing that is missing.
      When gfs2_releasepage later runs across these buffers which are still
      referenced, it refuses to free them.  This causes the pages the buffers
      are attached to to remain referenced as well.  With enough mount/unmount
      cycles, the system will eventually run out of memory.
      Fix this by adding the missing call to gfs2_rgrp_brelse in
      (Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
      Fixes: 39b0f1e9 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
      Cc: stable@vger.kernel.org # v4.4
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>