1. 07 Dec, 2018 2 commits
    • Linus Torvalds's avatar
      Merge branch 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm · b72f711a
      Linus Torvalds authored
      Pull ARM spectre fix from Russell King:
       "Exynos folk noticed that CPU hotplug wasn't working with their kernel
        configuration, and have tested this as fixing the problem"
      
      * 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: ensure that processor vtables is not lost after boot
      b72f711a
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm · 7e40b56c
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Some small fixes that have been accumulated:
      
         - Chris Cole noticed that in a SMP environment, the DMA cache
           coherence handling can produce undesirable results in a corner
           case
      
         - Propagate that fix for ARMv7M as well
      
         - Fix a false positive with source fortification
      
         - Fix an uninitialised return that Nathan Jones spotted"
      
      * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: 8816/1: dma-mapping: fix potential uninitialized return
        ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart
        ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling
        ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE
      7e40b56c
  2. 06 Dec, 2018 6 commits
  3. 05 Dec, 2018 12 commits
    • Linus Torvalds's avatar
      Merge tag 'arc-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc · 369af92c
      Linus Torvalds authored
      Pull ARC fixes/updates from Vineet Gupta
      
       - Missing reads{x}()/writes{x}() getting in the way of some drivers [Jose Abreu]
      
       - Builds defaulting to ARCv2 ISA based configsa [Kevin Hilman]
      
       - Misc fixes
      
      * tag 'arc-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
        ARC: io.h: Implement reads{x}()/writes{x}()
        ARC: change defconfig defaults to ARCv2
        arc: [devboards] Add support of NFSv3 ACL
        ARC: mm: fix uninitialised signal code in do_page_fault
        ARC: [plat-hsdk] Enable DW APB GPIO support
        ARCv2: boot log unaligned access in use
        ARC: IOC: panic if kernel was started with previously enabled IOC
        ARC: remove redundant 'default n' from Kconfig
      369af92c
    • David Rientjes's avatar
      mm, thp: restore node-local hugepage allocations · 2f0799a0
      David Rientjes authored
      This is a full revert of ac5b2c18 ("mm: thp: relax __GFP_THISNODE for
      MADV_HUGEPAGE mappings") and a partial revert of 89c83fb5 ("mm, thp:
      consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
      
      By not setting __GFP_THISNODE, applications can allocate remote hugepages
      when the local node is fragmented or low on memory when either the thp
      defrag setting is "always" or the vma has been madvised with
      MADV_HUGEPAGE.
      
      Remote access to hugepages often has much higher latency than local pages
      of the native page size.  On Haswell, ac5b2c18 was shown to have a
      13.9% access regression after this commit for binaries that remap their
      text segment to be backed by transparent hugepages.
      
      The intent of ac5b2c18 is to address an issue where a local node is
      low on memory or fragmented such that a hugepage cannot be allocated.  In
      every scenario where this was described as a fix, there is abundant and
      unfragmented remote memory available to allocate from, even with a greater
      access latency.
      
      If remote memory is also low or fragmented, not setting __GFP_THISNODE was
      also measured on Haswell to have a 40% regression in allocation latency.
      
      Restore __GFP_THISNODE for thp allocations.
      
      Fixes: ac5b2c18 ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings")
      Fixes: 89c83fb5 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask")
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f0799a0
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20181205' of git://git.kernel.dk/linux-block · 4eaaa2b9
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "A bit earlier in the week as usual, but there's a fix here that should
        go in sooner rather than later.
      
        Under a combination of circumstance, the direct issue path in blk-mq
        could corrupt data. This wasn't easy to hit, but the ones that are
        affected by it, seem to hit it pretty easily. Full explanation in the
        patch. None of the regular filesystem and storage testing has
        triggered it, even though it's been around since 4.19-rc1.
      
        Outside of that, whitelist trim tweak for certain Samsung devices for
        libata"
      
      * tag 'for-linus-20181205' of git://git.kernel.dk/linux-block:
        blk-mq: fix corruption with direct issue
        libata: whitelist all SAMSUNG MZ7KM* solid-state disks
      4eaaa2b9
    • Linus Torvalds's avatar
      Merge tag 'for-4.20-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · d0897090
      Linus Torvalds authored
      Pull btrfs fix from David Sterba:
       "A patch in 4.19 introduced a sanity check that was too strict and a
        filesystem cannot be mounted.
      
        This happens for filesystems with more than 10 devices and has been
        reported by a few users so we need the fix to propagate to stable"
      
      * tag 'for-4.20-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable
      d0897090
    • Linus Torvalds's avatar
      Merge tag 'pm-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 91dd51f6
      Linus Torvalds authored
      Pull power management fix from Rafael Wysocki:
       "Revert a problematic recent commit that attempted to fix a system-wide
        suspend issue related to the freezer"
      
      * tag 'pm-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        Revert "exec: make de_thread() freezable"
      91dd51f6
    • Linus Torvalds's avatar
      Merge tag 'mfd-fixes-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd · 5e0dc1a7
      Linus Torvalds authored
      Pull mfd bugfix from Lee Jones:
       "Replace release function in cros_ec_dev"
      
      * tag 'mfd-fixes-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
        Revert "mfd: cros_ec: Use devm_kzalloc for private data"
      5e0dc1a7
    • Chris Chiu's avatar
      ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G · b72f936f
      Chris Chiu authored
      Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
      with the input from external microphone. The issue can be fixed by
      the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b72f936f
    • Chris Chiu's avatar
      ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G · 9f8aefed
      Chris Chiu authored
      Acer AIO Veriton Z4660G with ALC286 codec has issue with the input
      from external microphones connecting via 'Front Mic' jack. The fixup
      ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of
      the headset and fix the audio input issue of external microphone.
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9f8aefed
    • Chris Chiu's avatar
      ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic · 705b65f1
      Chris Chiu authored
      The Acer AIO Aspire C24-860 with ALC286 can't detect the headset
      microphone. Just like another Acer AIO U27-880, it needs a different
      pin value for 0x18 and the headset fixup to make headset mic work.
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      705b65f1
    • Chris Chiu's avatar
      ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880 · 33aaebd4
      Chris Chiu authored
      Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic
      and internal mic not working either. It needs the similar quirk like
      Sony laptops to fix headphone jack sensing and enables use of the
      internal microphone.
      
      Unfortunately jack sensing for the headset mic is still not working.
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      33aaebd4
    • Enric Balletbo i Serra's avatar
      Revert "mfd: cros_ec: Use devm_kzalloc for private data" · 48a2ca0e
      Enric Balletbo i Serra authored
      This reverts commit 3aa2177e.
      
      That commit triggered a new WARN when unloading the module (see at the
      end of the commit message). When a class_dev is embedded in a structure
      then that class_dev is the thing that controls the lifetime of that
      structure, for that reason device managed allocations can't be used here.
      See Documentation/kobject.txt.
      
      Revert the above patch, so the struct is allocated using kzalloc and we
      have a release function for it that frees the allocated memory, otherwise
      it is broken.
      
       ------------[ cut here ]------------
       Device 'cros_ec' does not have a release() function, it is broken and must be fixed.
       WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90
       Modules linked in: btusb btrtl btintel btbcm bluetooth ...
       CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76
       Hardware name: Google Kevin (DT)
       pstate: 40000005 (nZcv daif -PAN -UAO)
       pc : device_release+0x80/0x90
       lr : device_release+0x80/0x90
       sp : ffff00000c47bc70
       x29: ffff00000c47bc70 x28: ffff8000e86b0d40
       x27: 0000000000000000 x26: 0000000000000000
       x25: 0000000056000000 x24: 0000000000000015
       x23: ffff8000f0bbf860 x22: ffff000000d320a0
       x21: ffff8000ee93e100 x20: ffff8000ed931428
       x19: ffff8000ed931418 x18: 0000000000000020
       x17: 0000000000000000 x16: 0000000000000000
       x15: 0000000000000400 x14: 0000000000000143
       x13: 0000000000000000 x12: 0000000000000400
       x11: 0000000000000157 x10: 0000000000000960
       x9 : ffff00000c47b9b0 x8 : ffff8000e86b1700
       x7 : 0000000000000000 x6 : ffff8000f7d520b8
       x5 : ffff8000f7d520b8 x4 : 0000000000000000
       x3 : ffff8000f7d58e68 x2 : ffff8000e86b0d40
       x1 : 37d859939c964800 x0 : 0000000000000000
       Call trace:
        device_release+0x80/0x90
        kobject_put+0x74/0xe8
        device_unregister+0x20/0x30
        ec_device_remove+0x34/0x48 [cros_ec_dev]
        platform_drv_remove+0x28/0x48
        device_release_driver_internal+0x1a8/0x240
        driver_detach+0x40/0x80
        bus_remove_driver+0x54/0xa8
        driver_unregister+0x2c/0x58
        platform_driver_unregister+0x10/0x18
        cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev]
        __arm64_sys_delete_module+0x16c/0x1f8
        el0_svc_common+0x84/0xd8
        el0_svc_handler+0x2c/0x80
        el0_svc+0x8/0xc
       ---[ end trace a57c4625f3c60ae8 ]---
      
      Cc: stable@vger.kernel.org
      Fixes: 3aa2177e ("mfd: cros_ec: Use devm_kzalloc for private data")
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
      Reviewed-by: default avatarDmitry Torokhov <dtor@chromium.org>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      48a2ca0e
    • Jens Axboe's avatar
      blk-mq: fix corruption with direct issue · ffe81d45
      Jens Axboe authored
      If we attempt a direct issue to a SCSI device, and it returns BUSY, then
      we queue the request up normally. However, the SCSI layer may have
      already setup SG tables etc for this particular command. If we later
      merge with this request, then the old tables are no longer valid. Once
      we issue the IO, we only read/write the original part of the request,
      not the new state of it.
      
      This causes data corruption, and is most often noticed with the file
      system complaining about the just read data being invalid:
      
      [  235.934465] EXT4-fs error (device sda1): ext4_iget:4831: inode #7142: comm dpkg-query: bad extra_isize 24937 (inode size 256)
      
      because most of it is garbage...
      
      This doesn't happen from the normal issue path, as we will simply defer
      the request to the hardware queue dispatch list if we fail. Once it's on
      the dispatch list, we never merge with it.
      
      Fix this from the direct issue path by flagging the request as
      REQ_NOMERGE so we don't change the size of it before issue.
      
      See also:
        https://bugzilla.kernel.org/show_bug.cgi?id=201685Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Fixes: 6ce3dd6e ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      ffe81d45
  4. 04 Dec, 2018 7 commits
    • Nathan Jones's avatar
      ARM: 8816/1: dma-mapping: fix potential uninitialized return · c2a3831d
      Nathan Jones authored
      While trying to use the dma_mmap_*() interface, it was noticed that this
      interface returns strange values when passed an incorrect length.
      
      If neither of the if() statements fire then the return value is
      uninitialized. In the worst case it returns 0 which means the caller
      will think the function succeeded.
      
      Fixes: 1655cf88 ("ARM: dma-mapping: Remove traces of NOMMU code")
      Signed-off-by: default avatarNathan Jones <nathanj439@gmail.com>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      c2a3831d
    • Vladimir Murzin's avatar
      ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart · 3d0358d0
      Vladimir Murzin authored
      Chris has discovered and reported that v7_dma_inv_range() may corrupt
      memory if address range is not aligned to cache line size.
      
      Since the whole cache-v7m.S was lifted form cache-v7.S the same
      observation applies to v7m_dma_inv_range(). So the fix just mirrors
      what has been done for v7 with a little specific of M-class.
      
      Cc: Chris Cole <chris@sageembedded.com>
      Signed-off-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      3d0358d0
    • Chris Cole's avatar
      ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling · a1208f6a
      Chris Cole authored
      This patch addresses possible memory corruption when
      v7_dma_inv_range(start_address, end_address) address parameters are not
      aligned to whole cache lines. This function issues "invalidate" cache
      management operations to all cache lines from start_address (inclusive)
      to end_address (exclusive). When start_address and/or end_address are
      not aligned, the start and/or end cache lines are first issued "clean &
      invalidate" operation. The assumption is this is done to ensure that any
      dirty data addresses outside the address range (but part of the first or
      last cache lines) are cleaned/flushed so that data is not lost, which
      could happen if just an invalidate is issued.
      
      The problem is that these first/last partial cache lines are issued
      "clean & invalidate" and then "invalidate". This second "invalidate" is
      not required and worse can cause "lost" writes to addresses outside the
      address range but part of the cache line. If another component writes to
      its part of the cache line between the "clean & invalidate" and
      "invalidate" operations, the write can get lost. This fix is to remove
      the extra "invalidate" operation when unaligned addressed are used.
      
      A kernel module is available that has a stress test to reproduce the
      issue and a unit test of the updated v7_dma_inv_range(). It can be
      downloaded from
      http://ftp.sageembedded.com/outgoing/linux/cache-test-20181107.tgz.
      
      v7_dma_inv_range() is call by dmac_[un]map_area(addr, len, direction)
      when the direction is DMA_FROM_DEVICE. One can (I believe) successfully
      argue that DMA from a device to main memory should use buffers aligned
      to cache line size, because the "clean & invalidate" might overwrite
      data that the device just wrote using DMA. But if a driver does use
      unaligned buffers, at least this fix will prevent memory corruption
      outside the buffer.
      Signed-off-by: default avatarChris Cole <chris@sageembedded.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      a1208f6a
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · a517af52
      Linus Torvalds authored
      Pull parisc fix from Helge Deller:
       "On parisc, use -ffunction-sections compiler option when building
        32-bit kernel modules to avoid sysfs-warnings when loading such
        modules.
      
        This got broken with kernel v4.18"
      
      * 'parisc-4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Enable -ffunction-sections for modules on 32-bit kernel
      a517af52
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · adac0753
      Linus Torvalds authored
      Pull input updates from Dmitry Torokhov:
       "Mostly new IDs for Elan/Synaptics touchpads, plus a few small fixups"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: omap-keypad - fix keyboard debounce configuration
        Input: xpad - quirk all PDP Xbox One gamepads
        Input: synaptics - enable SMBus for HP 15-ay000
        Input: synaptics - add PNP ID for ThinkPad P50 to SMBus
        Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR
        Input: elan_i2c - add support for ELAN0621 touchpad
        Input: hyper-v - fix wakeup from suspend-to-idle
        Input: atkbd - clean up indentation issue
        Input: st1232 - convert to SPDX identifiers
        Input: migor_ts - convert to SPDX identifiers
        Input: dt-bindings - fix a typo in file input-reset.txt
        Input: cros_ec_keyb - fix button/switch capability reports
        Input: elan_i2c - add ELAN0620 to the ACPI table
        Input: matrix_keypad - check for errors from of_get_named_gpio()
      adac0753
    • Rafael J. Wysocki's avatar
      Revert "exec: make de_thread() freezable" · a72173ec
      Rafael J. Wysocki authored
      Revert commit c2239788 "exec: make de_thread() freezable" as
      requested by Ingo Molnar:
      
      "So there's a new regression in v4.20-rc4, my desktop produces this
      lockdep splat:
      
      [ 1772.588771] WARNING: pkexec/4633 still has locks held!
      [ 1772.588773] 4.20.0-rc4-custom-00213-g93a49841322b #1 Not tainted
      [ 1772.588775] ------------------------------------
      [ 1772.588776] 1 lock held by pkexec/4633:
      [ 1772.588778]  #0: 00000000ed85fbf8 (&sig->cred_guard_mutex){+.+.}, at: prepare_bprm_creds+0x2a/0x70
      [ 1772.588786] stack backtrace:
      [ 1772.588789] CPU: 7 PID: 4633 Comm: pkexec Not tainted 4.20.0-rc4-custom-00213-g93a49841322b #1
      [ 1772.588792] Call Trace:
      [ 1772.588800]  dump_stack+0x85/0xcb
      [ 1772.588803]  flush_old_exec+0x116/0x890
      [ 1772.588807]  ? load_elf_phdrs+0x72/0xb0
      [ 1772.588809]  load_elf_binary+0x291/0x1620
      [ 1772.588815]  ? sched_clock+0x5/0x10
      [ 1772.588817]  ? search_binary_handler+0x6d/0x240
      [ 1772.588820]  search_binary_handler+0x80/0x240
      [ 1772.588823]  load_script+0x201/0x220
      [ 1772.588825]  search_binary_handler+0x80/0x240
      [ 1772.588828]  __do_execve_file.isra.32+0x7d2/0xa60
      [ 1772.588832]  ? strncpy_from_user+0x40/0x180
      [ 1772.588835]  __x64_sys_execve+0x34/0x40
      [ 1772.588838]  do_syscall_64+0x60/0x1c0
      
      The warning gets triggered by an ancient lockdep check in the freezer:
      
      (gdb) list *0xffffffff812ece06
      0xffffffff812ece06 is in flush_old_exec (./include/linux/freezer.h:57).
      52	 * DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION
      53	 * If try_to_freeze causes a lockdep warning it means the caller may deadlock
      54	 */
      55	static inline bool try_to_freeze_unsafe(void)
      56	{
      57		might_sleep();
      58		if (likely(!freezing(current)))
      59			return false;
      60		return __refrigerator(false);
      61	}
      
      I reviewed the ->cred_guard_mutex code, and the mutex is held across all
      of exec() - and we always did this.
      
      But there's this recent -rc4 commit:
      
      > Chanho Min (1):
      >       exec: make de_thread() freezable
      
        c2239788: exec: make de_thread() freezable
      
      I believe this commit is bogus, you cannot call try_to_freeze() from
      de_thread(), because it's holding the ->cred_guard_mutex."
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Tested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a72173ec
    • Qu Wenruo's avatar
      btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable · 10950929
      Qu Wenruo authored
      [BUG]
      A completely valid btrfs will refuse to mount, with error message like:
        BTRFS critical (device sdb2): corrupt leaf: root=2 block=239681536 slot=172 \
          bg_start=12018974720 bg_len=10888413184, invalid block group size, \
          have 10888413184 expect (0, 10737418240]
      
      This has been reported several times as the 4.19 kernel is now being
      used. The filesystem refuses to mount, but is otherwise ok and booting
      4.18 is a workaround.
      
      Btrfs check returns no error, and all kernels used on this fs is later
      than 2011, which should all have the 10G size limit commit.
      
      [CAUSE]
      For a 12 devices btrfs, we could allocate a chunk larger than 10G due to
      stripe stripe bump up.
      
      __btrfs_alloc_chunk()
      |- max_stripe_size = 1G
      |- max_chunk_size = 10G
      |- data_stripe = 11
      |- if (1G * 11 > 10G) {
             stripe_size = 976128930;
             stripe_size = round_up(976128930, SZ_16M) = 989855744
      
      However the final stripe_size (989855744) * 11 = 10888413184, which is
      still larger than 10G.
      
      [FIX]
      For the comprehensive check, we need to do the full check at chunk read
      time, and rely on bg <-> chunk mapping to do the check.
      
      We could just skip the length check for now.
      
      Fixes: fce466ea ("btrfs: tree-checker: Verify block_group_item")
      Cc: stable@vger.kernel.org # v4.19+
      Reported-by: default avatarWang Yugui <wangyugui@e16-tech.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      10950929
  5. 03 Dec, 2018 13 commits