1. 31 May, 2019 4 commits
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · adc3f554
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "The fixes are still trickling in for arm64, but the only really
        significant one here is actually fixing a regression in the botched
        module relocation range checking merged for -rc2.
      
        Hopefully we've nailed it this time.
      
         - Fix implementation of our set_personality() system call, which
           wasn't being wrapped properly
      
         - Fix system call function types to keep CFI happy
      
         - Fix siginfo layout when delivering SIGKILL after a kernel fault
      
         - Really fix module relocation range checking"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: use the correct function type for __arm64_sys_ni_syscall
        arm64: use the correct function type in SYSCALL_DEFINE0
        arm64: fix syscall_fn_t type
        signal/arm64: Use force_sig not force_sig_fault for SIGKILL
        arm64/module: revert to unsigned interpretation of ABS16/32 relocations
        arm64: Fix the arm64_personality() syscall wrapper redirection
      adc3f554
    • Linus Torvalds's avatar
      Merge tag 'for-5.2-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 318adf8e
      Linus Torvalds authored
      Pull btrfs fixes from David Sterba:
       "A few more fixes for bugs reported by users, fuzzing tools and
        regressions:
      
         - fix crashes in relocation:
             + resuming interrupted balance operation does not properly clean
               up orphan trees
             + with enabled qgroups, resuming needs to be more careful about
               block groups due to limited context when updating qgroups
      
         - fsync and logging fixes found by fuzzing
      
         - incremental send fixes for no-holes and clone
      
         - fix spin lock type used in timer function for zstd"
      
      * tag 'for-5.2-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        Btrfs: fix race updating log root item during fsync
        Btrfs: fix wrong ctime and mtime of a directory after log replay
        Btrfs: fix fsync not persisting changed attributes of a directory
        btrfs: qgroup: Check bg while resuming relocation to avoid NULL pointer dereference
        btrfs: reloc: Also queue orphan reloc tree for cleanup to avoid BUG_ON()
        Btrfs: incremental send, fix emission of invalid clone operations
        Btrfs: incremental send, fix file corruption when no-holes feature is enabled
        btrfs: correct zstd workspace manager lock to use spin_lock_bh()
        btrfs: Ensure replaced device doesn't have pending chunk allocation
      318adf8e
    • Linus Torvalds's avatar
      Merge tag 'configfs-for-5.2-2' of git://git.infradead.org/users/hch/configfs · 8cb7104d
      Linus Torvalds authored
      Pull configs fix from Christoph Hellwig:
      
       - fix a use after free in configfs_d_iput (Sahitya Tummala)
      
      * tag 'configfs-for-5.2-2' of git://git.infradead.org/users/hch/configfs:
        configfs: Fix use-after-free when accessing sd->s_dentry
      8cb7104d
    • Linus Torvalds's avatar
      Merge tag 'sound-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · c5ba1712
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "No big surprises here, just a few device-specific fixes.
      
        HD-audio received several fixes for Acer, Dell, Huawei and other
        laptops as well as the workaround for the new Intel chipset. One
        significant one-liner fix is the disablement of the node-power saving
        on Realtek codecs, which may potentially cover annoying bugs like the
        background noises or click noises on many devices.
      
        Other than that, a fix for FireWire bit definitions, and another fix
        for LINE6 USB audio bug that was discovered by syzkaller"
      
      * tag 'sound-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: fireface: Use ULL suffixes for 64-bit constants
        ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops
        ALSA: line6: Assure canceling delayed work at disconnection
        ALSA: hda - Force polling mode on CNL for fixing codec communication
        ALSA: hda/realtek - Enable micmute LED for Huawei laptops
        ALSA: hda/realtek - Set default power save node to 0
        ALSA: hda/realtek - Check headset type by unplug and resume
      c5ba1712
  2. 30 May, 2019 1 commit
  3. 29 May, 2019 9 commits
    • Linus Torvalds's avatar
      Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/linux · bec7550c
      Linus Torvalds authored
      Pull documentation fixes from Jonathan Corbet:
       "The Sphinx 2.0 release contained a few incompatible API changes that
        broke our extensions and, thus, the documentation build in general.
        Who knew that those deprecation warnings it was outputting actually
        meant we should change something? This set of fixes makes the build
        work again with Sphinx 2.0 and eliminates the warnings for 1.8. As
        part of that, we also need a few fixes to the docs for places where
        the new Sphinx is more strict.
      
        It is a bit late in the cycle for this kind of change, but it does fix
        problems that people are experiencing now.
      
        There has been some talk of raising the minimum version of Sphinx we
        support. I don't want to do that abruptly, though, so these changes
        add some glue to continue to support versions back to 1.3. We will be
        adding some infrastructure soon to nudge users of old versions
        forward, with the idea of maybe increasing our minimum version (and
        removing this glue) sometime in the future"
      
      * tag 'docs-5.2-fixes2' of git://git.lwn.net/linux:
        drm/i915: Maintain consistent documentation subsection ordering
        scripts/sphinx-pre-install: make it handle Sphinx versions
        docs: Fix conf.py for Sphinx 2.0
        docs: fix multiple doc build warnings in enumeration.rst
        lib/list_sort: fix kerneldoc build error
        docs: fix numaperf.rst and add it to the doc tree
        doc: Cope with the deprecation of AutoReporter
        doc: Cope with Sphinx logging deprecations
      bec7550c
    • Linus Torvalds's avatar
      Merge tag 'linux-kselftest-5.2-rc3' of... · 2b28601d
      Linus Torvalds authored
      Merge tag 'linux-kselftest-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
      
      Pull Kselftest fixes from Shuah Khan:
      
       - Alexandre Belloni's fixes to rtc regressions introduced in kselftest
         Makefile test run output refactoring work from Kees Cook.
      
       - ftrace test checkbashisms fixes from Masami Hiramatsu
      
      * tag 'linux-kselftest-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
        selftests: rtc: rtctest: specify timeouts
        selftests/harness: Allow test to configure timeout
        selftests/ftrace: Add checkbashisms meta-testcase
        selftests/ftrace: Make a script checkbashisms clean
      2b28601d
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 9e82b4a9
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "This fixes a memory leak from the error path in the event filter
        logic"
      
      * tag 'trace-v5.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Avoid memory leak in predicate_parse()
      9e82b4a9
    • Sami Tolvanen's avatar
      arm64: use the correct function type for __arm64_sys_ni_syscall · 1e29ab31
      Sami Tolvanen authored
      Calling sys_ni_syscall through a syscall_fn_t pointer trips indirect
      call Control-Flow Integrity checking due to a function type
      mismatch. Use SYSCALL_DEFINE0 for __arm64_sys_ni_syscall instead and
      remove the now unnecessary casts.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1e29ab31
    • Sami Tolvanen's avatar
      arm64: use the correct function type in SYSCALL_DEFINE0 · 0e358bd7
      Sami Tolvanen authored
      Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
      parameters, use the correct function type to avoid indirect call
      type mismatches with Control-Flow Integrity checking.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      0e358bd7
    • Sami Tolvanen's avatar
      arm64: fix syscall_fn_t type · 8ef8f368
      Sami Tolvanen authored
      Syscall wrappers in <asm/syscall_wrapper.h> use const struct pt_regs *
      as the argument type. Use const in syscall_fn_t as well to fix indirect
      call type mismatches with Control-Flow Integrity checking.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8ef8f368
    • Geert Uytterhoeven's avatar
      ALSA: fireface: Use ULL suffixes for 64-bit constants · 6954158a
      Geert Uytterhoeven authored
      With gcc 4.1:
      
          sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_switch_fetching_mode’:
          sound/firewire/fireface/ff-protocol-latter.c:97: warning: integer constant is too large for ‘long’ type
          sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_begin_session’:
          sound/firewire/fireface/ff-protocol-latter.c:170: warning: integer constant is too large for ‘long’ type
          sound/firewire/fireface/ff-protocol-latter.c:197: warning: integer constant is too large for ‘long’ type
          sound/firewire/fireface/ff-protocol-latter.c:205: warning: integer constant is too large for ‘long’ type
          sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_finish_session’:
          sound/firewire/fireface/ff-protocol-latter.c:214: warning: integer constant is too large for ‘long’ type
      
      Fix this by adding the missing "ULL" suffixes.
      Add the same suffix to the last constant, to maintain consistency.
      
      Fixes: fd1cc9de ("ALSA: fireface: add support for Fireface UCX")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6954158a
    • Eric W. Biederman's avatar
      signal/arm64: Use force_sig not force_sig_fault for SIGKILL · d76cac67
      Eric W. Biederman authored
      I don't think this is userspace visible but SIGKILL does not have
      any si_codes that use the fault member of the siginfo union.  Correct
      this the simple way and call force_sig instead of force_sig_fault when
      the signal is SIGKILL.
      
      The two know places where synchronous SIGKILL are generated are
      do_bad_area and fpsimd_save.  The call paths to force_sig_fault are:
      do_bad_area
        arm64_force_sig_fault
          force_sig_fault
      force_signal_inject
        arm64_notify_die
          arm64_force_sig_fault
             force_sig_fault
      
      Which means correcting this in arm64_force_sig_fault is enough
      to ensure the arm64 code is not misusing the generic code, which
      could lead to maintenance problems later.
      
      Cc: stable@vger.kernel.org
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Fixes: af40ff68 ("arm64: signal: Ensure si_code is valid for all fault signals")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d76cac67
    • Hui Wang's avatar
      ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops · 9cb40eb1
      Hui Wang authored
      We met another Acer Aspire laptop which has the problem on the
      headset-mic, the Pin 0x19 is not set the corret configuration for a
      mic and the pin presence can't be detected too after plugging a
      headset. Kailang suggested that we should set the coeff to enable the
      mic and apply the ALC269_FIXUP_LIFEBOOK_EXTMIC. After doing that,
      both headset-mic presence and headset-mic work well.
      
      The existing ALC255_FIXUP_ACER_MIC_NO_PRESENCE set the headset-mic
      jack to be a phantom jack. Now since the jack can support presence
      unsol event, let us imporve it to set the jack to be a normal jack.
      
      https://bugs.launchpad.net/bugs/1821269
      Fixes: 5824ce8d ("ALSA: hda/realtek - Add support for Acer Aspire E5-475 headset mic")
      Cc: Chris Chiu <chiu@endlessm.com>
      CC: Daniel Drake <drake@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9cb40eb1
  4. 28 May, 2019 18 commits
    • Tomas Bortoli's avatar
      tracing: Avoid memory leak in predicate_parse() · dfb4a6f2
      Tomas Bortoli authored
      In case of errors, predicate_parse() goes to the out_free label
      to free memory and to return an error code.
      
      However, predicate_parse() does not free the predicates of the
      temporary prog_stack array, thence leaking them.
      
      Link: http://lkml.kernel.org/r/20190528154338.29976-1-tomasbortoli@gmail.com
      
      Cc: stable@vger.kernel.org
      Fixes: 80765597 ("tracing: Rewrite filter logic to be simpler and faster")
      Reported-by: syzbot+6b8e0fb820e570c59e19@syzkaller.appspotmail.com
      Signed-off-by: default avatarTomas Bortoli <tomasbortoli@gmail.com>
      [ Added protection around freeing prog_stack[i].pred ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      dfb4a6f2
    • Filipe Manana's avatar
      Btrfs: fix race updating log root item during fsync · 06989c79
      Filipe Manana authored
      When syncing the log, the final phase of a fsync operation, we need to
      either create a log root's item or update the existing item in the log
      tree of log roots, and that depends on the current value of the log
      root's log_transid - if it's 1 we need to create the log root item,
      otherwise it must exist already and we update it. Since there is no
      synchronization between updating the log_transid and checking it for
      deciding whether the log root's item needs to be created or updated, we
      end up with a tiny race window that results in attempts to update the
      item to fail because the item was not yet created:
      
                    CPU 1                                    CPU 2
      
        btrfs_sync_log()
      
          lock root->log_mutex
      
          set log root's log_transid to 1
      
          unlock root->log_mutex
      
                                                     btrfs_sync_log()
      
                                                       lock root->log_mutex
      
                                                       sets log root's
                                                       log_transid to 2
      
                                                       unlock root->log_mutex
      
          update_log_root()
      
            sees log root's log_transid
            with a value of 2
      
              calls btrfs_update_root(),
              which fails with -EUCLEAN
              and causes transaction abort
      
      Until recently the race lead to a BUG_ON at btrfs_update_root(), but after
      the recent commit 7ac1e464 ("btrfs: Don't panic when we can't find a
      root key") we just abort the current transaction.
      
      A sample trace of the BUG_ON() on a SLE12 kernel:
      
        ------------[ cut here ]------------
        kernel BUG at ../fs/btrfs/root-tree.c:157!
        Oops: Exception in kernel mode, sig: 5 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        (...)
        Supported: Yes, External
        CPU: 78 PID: 76303 Comm: rtas_errd Tainted: G                 X 4.4.156-94.57-default #1
        task: c00000ffa906d010 ti: c00000ff42b08000 task.ti: c00000ff42b08000
        NIP: d000000036ae5cdc LR: d000000036ae5cd8 CTR: 0000000000000000
        REGS: c00000ff42b0b860 TRAP: 0700   Tainted: G                 X  (4.4.156-94.57-default)
        MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 22444484  XER: 20000000
        CFAR: d000000036aba66c SOFTE: 1
        GPR00: d000000036ae5cd8 c00000ff42b0bae0 d000000036bda220 0000000000000054
        GPR04: 0000000000000001 0000000000000000 c00007ffff8d37c8 0000000000000000
        GPR08: c000000000e19c00 0000000000000000 0000000000000000 3736343438312079
        GPR12: 3930373337303434 c000000007a3a800 00000000007fffff 0000000000000023
        GPR16: c00000ffa9d26028 c00000ffa9d261f8 0000000000000010 c00000ffa9d2ab28
        GPR20: c00000ff42b0bc48 0000000000000001 c00000ff9f0d9888 0000000000000001
        GPR24: c00000ffa9d26000 c00000ffa9d261e8 c00000ffa9d2a800 c00000ff9f0d9888
        GPR28: c00000ffa9d26028 c00000ffa9d2aa98 0000000000000001 c00000ffa98f5b20
        NIP [d000000036ae5cdc] btrfs_update_root+0x25c/0x4e0 [btrfs]
        LR [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs]
        Call Trace:
        [c00000ff42b0bae0] [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] (unreliable)
        [c00000ff42b0bba0] [d000000036b53610] btrfs_sync_log+0x2d0/0xc60 [btrfs]
        [c00000ff42b0bce0] [d000000036b1785c] btrfs_sync_file+0x44c/0x4e0 [btrfs]
        [c00000ff42b0bd80] [c00000000032e300] vfs_fsync_range+0x70/0x120
        [c00000ff42b0bdd0] [c00000000032e44c] do_fsync+0x5c/0xb0
        [c00000ff42b0be10] [c00000000032e8dc] SyS_fdatasync+0x2c/0x40
        [c00000ff42b0be30] [c000000000009488] system_call+0x3c/0x100
        Instruction dump:
        7f43d378 4bffebb9 60000000 88d90008 3d220000 e8b90000 3b390009 e87a01f0
        e8898e08 e8f90000 4bfd48e5 60000000 <0fe00000> e95b0060 39200004 394a0ea0
        ---[ end trace 8f2dc8f919cabab8 ]---
      
      So fix this by doing the check of log_transid and updating or creating the
      log root's item while holding the root's log_mutex.
      
      Fixes: 7237f183 ("Btrfs: fix tree logs parallel sync")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      06989c79
    • Filipe Manana's avatar
      Btrfs: fix wrong ctime and mtime of a directory after log replay · 5338e43a
      Filipe Manana authored
      When replaying a log that contains a new file or directory name that needs
      to be added to its parent directory, we end up updating the mtime and the
      ctime of the parent directory to the current time after we have set their
      values to the correct ones (set at fsync time), efectivelly losing them.
      
      Sample reproducer:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /mnt
      
        $ mkdir /mnt/dir
        $ touch /mnt/dir/file
      
        # fsync of the directory is optional, not needed
        $ xfs_io -c fsync /mnt/dir
        $ xfs_io -c fsync /mnt/dir/file
      
        $ stat -c %Y /mnt/dir
        1557856079
      
        <power failure>
      
        $ sleep 3
        $ mount /dev/sdb /mnt
        $ stat -c %Y /mnt/dir
        1557856082
      
          --> should have been 1557856079, the mtime is updated to the current
              time when replaying the log
      
      Fix this by not updating the mtime and ctime to the current time at
      btrfs_add_link() when we are replaying a log tree.
      
      This could be triggered by my recent fsync fuzz tester for fstests, for
      which an fstests patch exists titled "fstests: generic, fsync fuzz tester
      with fsstress".
      
      Fixes: e02119d5 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      5338e43a
    • Filipe Manana's avatar
      Btrfs: fix fsync not persisting changed attributes of a directory · 60d9f503
      Filipe Manana authored
      While logging an inode we follow its ancestors and for each one we mark
      it as logged in the current transaction, even if we have not logged it.
      As a consequence if we change an attribute of an ancestor, such as the
      UID or GID for example, and then explicitly fsync it, we end up not
      logging the inode at all despite returning success to user space, which
      results in the attribute being lost if a power failure happens after
      the fsync.
      
      Sample reproducer:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /mnt
      
        $ mkdir /mnt/dir
        $ chown 6007:6007 /mnt/dir
      
        $ sync
      
        $ chown 9003:9003 /mnt/dir
        $ touch /mnt/dir/file
        $ xfs_io -c fsync /mnt/dir/file
      
        # fsync our directory after fsync'ing the new file, should persist the
        # new values for the uid and gid.
        $ xfs_io -c fsync /mnt/dir
      
        <power failure>
      
        $ mount /dev/sdb /mnt
        $ stat -c %u:%g /mnt/dir
        6007:6007
      
          --> should be 9003:9003, the uid and gid were not persisted, despite
              the explicit fsync on the directory prior to the power failure
      
      Fix this by not updating the logged_trans field of ancestor inodes when
      logging an inode, since we have not logged them. Let only future calls to
      btrfs_log_inode() to mark inodes as logged.
      
      This could be triggered by my recent fsync fuzz tester for fstests, for
      which an fstests patch exists titled "fstests: generic, fsync fuzz tester
      with fsstress".
      
      Fixes: 12fcfd22 ("Btrfs: tree logging unlink/rename fixes")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      60d9f503
    • Qu Wenruo's avatar
      btrfs: qgroup: Check bg while resuming relocation to avoid NULL pointer dereference · 57949d03
      Qu Wenruo authored
      [BUG]
      When mounting a fs with reloc tree and has qgroup enabled, it can cause
      NULL pointer dereference at mount time:
      
        BUG: kernel NULL pointer dereference, address: 00000000000000a8
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 0 P4D 0
        Oops: 0000 [#1] PREEMPT SMP NOPTI
        RIP: 0010:btrfs_qgroup_add_swapped_blocks+0x186/0x300 [btrfs]
        Call Trace:
         replace_path.isra.23+0x685/0x900 [btrfs]
         merge_reloc_root+0x26e/0x5f0 [btrfs]
         merge_reloc_roots+0x10a/0x1a0 [btrfs]
         btrfs_recover_relocation+0x3cd/0x420 [btrfs]
         open_ctree+0x1bc8/0x1ed0 [btrfs]
         btrfs_mount_root+0x544/0x680 [btrfs]
         legacy_get_tree+0x34/0x60
         vfs_get_tree+0x2d/0xf0
         fc_mount+0x12/0x40
         vfs_kern_mount.part.12+0x61/0xa0
         vfs_kern_mount+0x13/0x20
         btrfs_mount+0x16f/0x860 [btrfs]
         legacy_get_tree+0x34/0x60
         vfs_get_tree+0x2d/0xf0
         do_mount+0x81f/0xac0
         ksys_mount+0xbf/0xe0
         __x64_sys_mount+0x25/0x30
         do_syscall_64+0x65/0x240
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      [CAUSE]
      In btrfs_recover_relocation(), we don't have enough info to determine
      which block group we're relocating, but only to merge existing reloc
      trees.
      
      Thus in btrfs_recover_relocation(), rc->block_group is NULL.
      btrfs_qgroup_add_swapped_blocks() hasn't taken this into consideration,
      and causes a NULL pointer dereference.
      
      The bug is introduced by commit 3d0174f7 ("btrfs: qgroup: Only trace
      data extents in leaves if we're relocating data block group"), and
      later qgroup refactoring still keeps this optimization.
      
      [FIX]
      Thankfully in the context of btrfs_recover_relocation(), there is no
      other progress can modify tree blocks, thus those swapped tree blocks
      pair will never affect qgroup numbers, no matter whatever we set for
      block->trace_leaf.
      
      So we only need to check if @bg is NULL before accessing @bg->flags.
      Reported-by: default avatarJuan Erbes <jerbes@gmail.com>
      Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1134806
      Fixes: 3d0174f7 ("btrfs: qgroup: Only trace data extents in leaves if we're relocating data block group")
      CC: stable@vger.kernel.org # 4.20+
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      57949d03
    • Qu Wenruo's avatar
      btrfs: reloc: Also queue orphan reloc tree for cleanup to avoid BUG_ON() · 30d40577
      Qu Wenruo authored
      [BUG]
      When a fs has orphan reloc tree along with unfinished balance:
        ...
              item 16 key (TREE_RELOC ROOT_ITEM FS_TREE) itemoff 12090 itemsize 439
                      generation 12 root_dirid 256 bytenr 300400640 level 1 refs 0 <<<
                      lastsnap 8 byte_limit 0 bytes_used 1359872 flags 0x0(none)
                      uuid 7c48d938-33a3-4aae-ab19-6e5c9d406e46
              item 17 key (BALANCE TEMPORARY_ITEM 0) itemoff 11642 itemsize 448
                      temporary item objectid BALANCE offset 0
                      balance status flags 14
      
      Then at mount time, we can hit the following kernel BUG_ON():
        BTRFS info (device dm-3): relocating block group 298844160 flags metadata|dup
        ------------[ cut here ]------------
        kernel BUG at fs/btrfs/relocation.c:1413!
        invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
        CPU: 1 PID: 897 Comm: btrfs-balance Tainted: G           O      5.2.0-rc1-custom #15
        RIP: 0010:create_reloc_root+0x1eb/0x200 [btrfs]
        Call Trace:
         btrfs_init_reloc_root+0x96/0xb0 [btrfs]
         record_root_in_trans+0xb2/0xe0 [btrfs]
         btrfs_record_root_in_trans+0x55/0x70 [btrfs]
         select_reloc_root+0x7e/0x230 [btrfs]
         do_relocation+0xc4/0x620 [btrfs]
         relocate_tree_blocks+0x592/0x6a0 [btrfs]
         relocate_block_group+0x47b/0x5d0 [btrfs]
         btrfs_relocate_block_group+0x183/0x2f0 [btrfs]
         btrfs_relocate_chunk+0x4e/0xe0 [btrfs]
         btrfs_balance+0x864/0xfa0 [btrfs]
         balance_kthread+0x3b/0x50 [btrfs]
         kthread+0x123/0x140
         ret_from_fork+0x27/0x50
      
      [CAUSE]
      In btrfs, reloc trees are used to record swapped tree blocks during
      balance.
      Reloc tree either get merged (replace old tree blocks of its parent
      subvolume) in next transaction if its ref is 1 (fresh).
      Or is already merged and will be cleaned up if its ref is 0 (orphan).
      
      After commit d2311e69 ("btrfs: relocation: Delay reloc tree deletion
      after merge_reloc_roots"), reloc tree cleanup is delayed until one block
      group is balanced.
      
      Since fresh reloc roots are recorded during merge, as long as there
      is no power loss, those orphan reloc roots converted from fresh ones are
      handled without problem.
      
      However when power loss happens, orphan reloc roots can be recorded
      on-disk, thus at next mount time, we will have orphan reloc roots from
      on-disk data directly, and ignored by clean_dirty_subvols() routine.
      
      Then when background balance starts to balance another block group, and
      needs to create new reloc root for the same root, btrfs_insert_item()
      returns -EEXIST, and trigger that BUG_ON().
      
      [FIX]
      For orphan reloc roots, also queue them to rc->dirty_subvol_roots, so
      all reloc roots no matter orphan or not, can be cleaned up properly and
      avoid above BUG_ON().
      
      And to cooperate with above change, clean_dirty_subvols() will check if
      the queued root is a reloc root or a subvol root.
      For a subvol root, do the old work, and for a orphan reloc root, clean it
      up.
      
      Fixes: d2311e69 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots")
      CC: stable@vger.kernel.org # 5.1
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      30d40577
    • Filipe Manana's avatar
      Btrfs: incremental send, fix emission of invalid clone operations · 3c850b45
      Filipe Manana authored
      When doing an incremental send we can now issue clone operations with a
      source range that ends at the source's file eof and with a destination
      range that ends at an offset smaller then the destination's file eof.
      If the eof of the source file is not aligned to the sector size of the
      filesystem, the receiver will get a -EINVAL error when trying to do the
      operation or, on older kernels, silently corrupt the destination file.
      The corruption happens on kernels without commit ac765f83
      ("Btrfs: fix data corruption due to cloning of eof block"), while the
      failure to clone happens on kernels with that commit.
      
      Example reproducer:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /mnt/sdb
      
        $ xfs_io -f -c "pwrite -S 0xb1 0 2M" /mnt/sdb/foo
        $ xfs_io -f -c "pwrite -S 0xc7 0 2M" /mnt/sdb/bar
        $ xfs_io -f -c "pwrite -S 0x4d 0 2M" /mnt/sdb/baz
        $ xfs_io -f -c "pwrite -S 0xe2 0 2M" /mnt/sdb/zoo
      
        $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base
      
        $ btrfs send -f /tmp/base.send /mnt/sdb/base
      
        $ xfs_io -c "reflink /mnt/sdb/bar 1560K 500K 100K" /mnt/sdb/bar
        $ xfs_io -c "reflink /mnt/sdb/bar 1560K 0 100K" /mnt/sdb/zoo
        $ xfs_io -c "truncate 550K" /mnt/sdb/bar
      
        $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr
      
        $ btrfs send -f /tmp/incr.send -p /mnt/sdb/base /mnt/sdb/incr
      
        $ mkfs.btrfs -f /dev/sdc
        $ mount /dev/sdc /mnt/sdc
      
        $ btrfs receive -f /tmp/base.send /mnt/sdc
        $ btrfs receive -vv -f /tmp/incr.send /mnt/sdc
        (...)
        truncate bar size=563200
        utimes bar
        clone zoo - source=bar source offset=512000 offset=0 length=51200
        ERROR: failed to clone extents to zoo
        Invalid argument
      
      The failure happens because the clone source range ends at the eof of file
      bar, 563200, which is not aligned to the filesystems sector size (4Kb in
      this case), and the destination range ends at offset 0 + 51200, which is
      less then the size of the file zoo (2Mb).
      
      So fix this by detecting such case and instead of issuing a clone
      operation for the whole range, do a clone operation for smaller range
      that is sector size aligned followed by a write operation for the block
      containing the eof. Here we will always be pessimistic and assume the
      destination filesystem of the send stream has the largest possible sector
      size (64Kb), since we have no way of determining it.
      
      This fixes a recent regression introduced in kernel 5.2-rc1.
      
      Fixes: 040ee612 ("Btrfs: send, improve clone range")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      3c850b45
    • Filipe Manana's avatar
      Btrfs: incremental send, fix file corruption when no-holes feature is enabled · 6b1f72e5
      Filipe Manana authored
      When using the no-holes feature, if we have a file with prealloc extents
      with a start offset beyond the file's eof, doing an incremental send can
      cause corruption of the file due to incorrect hole detection. Such case
      requires that the prealloc extent(s) exist in both the parent and send
      snapshots, and that a hole is punched into the file that covers all its
      extents that do not cross the eof boundary.
      
      Example reproducer:
      
        $ mkfs.btrfs -f -O no-holes /dev/sdb
        $ mount /dev/sdb /mnt/sdb
      
        $ xfs_io -f -c "pwrite -S 0xab 0 500K" /mnt/sdb/foobar
        $ xfs_io -c "falloc -k 1200K 800K" /mnt/sdb/foobar
      
        $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base
      
        $ btrfs send -f /tmp/base.snap /mnt/sdb/base
      
        $ xfs_io -c "fpunch 0 500K" /mnt/sdb/foobar
      
        $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr
      
        $ btrfs send -p /mnt/sdb/base -f /tmp/incr.snap /mnt/sdb/incr
      
        $ md5sum /mnt/sdb/incr/foobar
        816df6f64deba63b029ca19d880ee10a   /mnt/sdb/incr/foobar
      
        $ mkfs.btrfs -f /dev/sdc
        $ mount /dev/sdc /mnt/sdc
      
        $ btrfs receive -f /tmp/base.snap /mnt/sdc
        $ btrfs receive -f /tmp/incr.snap /mnt/sdc
      
        $ md5sum /mnt/sdc/incr/foobar
        cf2ef71f4a9e90c2f6013ba3b2257ed2   /mnt/sdc/incr/foobar
      
          --> Different checksum, because the prealloc extent beyond the
              file's eof confused the hole detection code and it assumed
              a hole starting at offset 0 and ending at the offset of the
              prealloc extent (1200Kb) instead of ending at the offset
              500Kb (the file's size).
      
      Fix this by ensuring we never cross the file's size when issuing the
      write operations for a hole.
      
      Fixes: 16e7549f ("Btrfs: incompatible format change to remove hole extents")
      CC: stable@vger.kernel.org # 3.14+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      6b1f72e5
    • Dennis Zhou's avatar
      btrfs: correct zstd workspace manager lock to use spin_lock_bh() · fee13fe9
      Dennis Zhou authored
      The btrfs zstd workspace manager uses a background timer to reclaim not
      recently used workspaces. I used spin_lock() from this context which
      should have been caught with lockdep, but was not. This deadlock was
      reported in bugzilla. The fix is to switch the zstd wsm lock to use
      spin_lock_bh() from the softirq context.
      
      This happened quite relibably on ppc64, unlike on other architectures.
      
        [  313.402874] ================================
        [  313.402875] WARNING: inconsistent lock state
        [  313.402879] 5.1.0-rc7 #1 Not tainted
        [  313.402880] --------------------------------
        [  313.402882] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
        [  313.402885] swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
        [  313.402888] 0000000080d1120c (&(&wsm.lock)->rlock){+.?.}, at: .zstd_reclaim_timer_fn+0x40/0x230
        [  313.402895] {SOFTIRQ-ON-W} state was registered at:
        [  313.402899]   .lock_acquire+0xd0/0x240
        [  313.402903]   ._raw_spin_lock+0x34/0x60
        [  313.402906]   .zstd_get_workspace+0xd0/0x360
        [  313.402908]   .end_compressed_bio_read+0x3b8/0x540
        [  313.402911]   .bio_endio+0x174/0x2c0
        [  313.402914]   .end_workqueue_fn+0x4c/0x70
        [  313.402917]   .normal_work_helper+0x138/0x7e0
        [  313.402920]   .process_one_work+0x324/0x790
        [  313.402922]   .worker_thread+0x68/0x570
        [  313.402925]   .kthread+0x19c/0x1b0
        [  313.402928]   .ret_from_kernel_thread+0x58/0x78
        [  313.402930] irq event stamp: 2629216
        [  313.402933] hardirqs last  enabled at (2629216): [<c0000000009da738>] ._raw_spin_unlock_irq+0x38/0x60
        [  313.402936] hardirqs last disabled at (2629215): [<c0000000009da4c4>] ._raw_spin_lock_irq+0x24/0x70
        [  313.402939] softirqs last  enabled at (2629212): [<c0000000000af9fc>] .irq_enter+0x8c/0xd0
        [  313.402942] softirqs last disabled at (2629213): [<c0000000000afb58>] .irq_exit+0x118/0x170
        [  313.402944]
      		 other info that might help us debug this:
        [  313.402945]  Possible unsafe locking scenario:
      
        [  313.402947]        CPU0
        [  313.402948]        ----
        [  313.402949]   lock(&(&wsm.lock)->rlock);
        [  313.402951]   <Interrupt>
        [  313.402952]     lock(&(&wsm.lock)->rlock);
        [  313.402954]
      		  *** DEADLOCK ***
      
        [  313.402957] 1 lock held by swapper/5/0:
        [  313.402958]  #0: 000000004b612042 ((&wsm.timer)){+.-.}, at: .call_timer_fn+0x0/0x3c0
        [  313.402963]
      		 stack backtrace:
        [  313.402967] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.1.0-rc7 #1
        [  313.402968] Call Trace:
        [  313.402972] [c0000007fa262e70] [c0000000009b3294] .dump_stack+0xe0/0x15c (unreliable)
        [  313.402975] [c0000007fa262f10] [c000000000125548] .print_usage_bug+0x348/0x390
        [  313.402978] [c0000007fa262fd0] [c000000000125cb4] .mark_lock+0x724/0x930
        [  313.402981] [c0000007fa263080] [c000000000126c20] .__lock_acquire+0xc90/0x16a0
        [  313.402984] [c0000007fa2631b0] [c000000000128040] .lock_acquire+0xd0/0x240
        [  313.402987] [c0000007fa263280] [c0000000009da2b4] ._raw_spin_lock+0x34/0x60
        [  313.402990] [c0000007fa263300] [c00000000054b0b0] .zstd_reclaim_timer_fn+0x40/0x230
        [  313.402993] [c0000007fa2633d0] [c000000000158b38] .call_timer_fn+0xc8/0x3c0
        [  313.402996] [c0000007fa2634a0] [c000000000158f74] .expire_timers+0x144/0x260
        [  313.402999] [c0000007fa263550] [c000000000159178] .run_timer_softirq+0xe8/0x230
        [  313.403002] [c0000007fa263680] [c0000000009db288] .__do_softirq+0x188/0x5d4
        [  313.403004] [c0000007fa263790] [c0000000000afb58] .irq_exit+0x118/0x170
        [  313.403008] [c0000007fa263800] [c000000000028d88] .timer_interrupt+0x158/0x430
        [  313.403012] [c0000007fa2638b0] [c0000000000091d4] decrementer_common+0x134/0x140
        [  313.403017] --- interrupt: 901 at replay_interrupt_return+0x0/0x4
      		     LR = .arch_local_irq_restore.part.0+0x68/0x80
        [  313.403020] [c0000007fa263bb0] [c00000000001a3ac] .arch_local_irq_restore.part.0+0x2c/0x80 (unreliable)
        [  313.403024] [c0000007fa263c30] [c0000000007bbbcc] .cpuidle_enter_state+0xec/0x670
        [  313.403027] [c0000007fa263d00] [c0000000000f5130] .call_cpuidle+0x40/0x90
        [  313.403031] [c0000007fa263d70] [c0000000000f554c] .do_idle+0x2dc/0x3a0
        [  313.403034] [c0000007fa263e30] [c0000000000f59ac] .cpu_startup_entry+0x2c/0x30
        [  313.403037] [c0000007fa263ea0] [c000000000045674] .start_secondary+0x644/0x650
        [  313.403041] [c0000007fa263f90] [c00000000000ad5c] start_secondary_prolog+0x10/0x14
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203517
      Fixes: 3f93aef5 ("btrfs: add zstd compression level support")
      CC: stable@vger.kernel.org # 5.1+
      Signed-off-by: default avatarDennis Zhou <dennis@kernel.org>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      fee13fe9
    • Nikolay Borisov's avatar
      btrfs: Ensure replaced device doesn't have pending chunk allocation · debd1c06
      Nikolay Borisov authored
      Recent FITRIM work, namely bbbf7243 ("btrfs: combine device update
      operations during transaction commit") combined the way certain
      operations are recoded in a transaction. As a result an ASSERT was added
      in dev_replace_finish to ensure the new code works correctly.
      Unfortunately I got reports that it's possible to trigger the assert,
      meaning that during a device replace it's possible to have an unfinished
      chunk allocation on the source device.
      
      This is supposed to be prevented by the fact that a transaction is
      committed before finishing the replace oepration and alter acquiring the
      chunk mutex. This is not sufficient since by the time the transaction is
      committed and the chunk mutex acquired it's possible to allocate a chunk
      depending on the workload being executed on the replaced device. This
      bug has been present ever since device replace was introduced but there
      was never code which checks for it.
      
      The correct way to fix is to ensure that there is no pending device
      modification operation when the chunk mutex is acquire and if there is
      repeat transaction commit. Unfortunately it's not possible to just
      exclude the source device from btrfs_fs_devices::dev_alloc_list since
      this causes ENOSPC to be hit in transaction commit.
      
      Fixing that in another way would need to add special cases to handle the
      last writes and forbid new ones. The looped transaction fix is more
      obvious, and can be easily backported. The runtime of dev-replace is
      long so there's no noticeable delay caused by that.
      Reported-by: default avatarDavid Sterba <dsterba@suse.com>
      Fixes: 391cd9df ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      debd1c06
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 9fb67d64
      Linus Torvalds authored
      Pull pin control fixes from Linus Walleij:
       "The commits that stand out are the Intel fixes that arrived during the
        merge window and I got relayed by pull request from Andy.
      
        Apart from that a minor Kconfig noise.
      
         - Interrupt clearing fix for the Intel pin controllers affecting
           touchpads on some laptops.
      
         - Compile Kconfig fix for the STMFX expander pin controller"
      
      * tag 'pinctrl-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: stmfx: Fix compile issue when CONFIG_OF_GPIO is not defined
        pinctrl: intel: Clear interrupt status in mask/unmask callback
        pinctrl: intel: Use GENMASK() consistently
      9fb67d64
    • Linus Torvalds's avatar
      Merge tag 'gpio-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · ca6584a3
      Linus Torvalds authored
      Pull GPIO fix from Linus Walleij:
       "Fix a build error in gpio-adp5588"
      
      * tag 'gpio-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: fix gpio-adp5588 build errors
      ca6584a3
    • Randy Dunlap's avatar
      ia64: fix build errors by exporting paddr_to_nid() · 9a626c4a
      Randy Dunlap authored
      Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
      exporting paddr_to_nid().
      
      Fixes these build errors:
      
      ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
      ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
      ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
      ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a626c4a
    • Ard Biesheuvel's avatar
      arm64/module: revert to unsigned interpretation of ABS16/32 relocations · 3fd00beb
      Ard Biesheuvel authored
      Commit 1cf24a2c
      
        ("arm64/module: deal with ambiguity in PRELxx relocation ranges")
      
      updated the overflow checking logic in the relocation handling code to
      ensure that PREL16/32 relocations don't overflow signed quantities.
      
      However, the same code path is used for absolute relocations, where the
      interpretation is the opposite: the only current use case for absolute
      relocations operating on non-native word size quantities is the CRC32
      handling in the CONFIG_MODVERSIONS code, and these CRCs are unsigned
      32-bit quantities, which are now being rejected by the module loader
      if bit 31 happens to be set.
      
      So let's use different ranges for quanties subject to absolute vs.
      relative relocations:
      - ABS16/32 relocations should be in the range [0, Uxx_MAX)
      - PREL16/32 relocations should be in the range [Sxx_MIN, Sxx_MAX)
      - otherwise, print an error since no other 16 or 32 bit wide data
        relocations are currently supported.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      3fd00beb
    • Catalin Marinas's avatar
      arm64: Fix the arm64_personality() syscall wrapper redirection · 00377277
      Catalin Marinas authored
      Following commit 4378a7d4 ("arm64: implement syscall wrappers"), the
      syscall function names gained the '__arm64_' prefix. Ensure that we
      have the correct #define for redirecting a default syscall through a
      wrapper.
      
      Fixes: 4378a7d4 ("arm64: implement syscall wrappers")
      Cc: <stable@vger.kernel.org> # 4.19.x-
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      00377277
    • Takashi Iwai's avatar
      ALSA: line6: Assure canceling delayed work at disconnection · 0b074ab7
      Takashi Iwai authored
      The current code performs the cancel of a delayed work at the late
      stage of disconnection procedure, which may lead to the access to the
      already cleared state.
      
      This patch assures to call cancel_delayed_work_sync() at the beginning
      of the disconnection procedure for avoiding that race.  The delayed
      work object is now assigned in the common line6 object instead of its
      derivative, so that we can call cancel_delayed_work_sync().
      
      Along with the change, the startup function is called via the new
      callback instead.  This will make it easier to port other LINE6
      drivers to use the delayed work for startup in later patches.
      
      Reported-by: syzbot+5255458d5e0a2b10bbb9@syzkaller.appspotmail.com
      Fixes: 7f84ff68 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0b074ab7
    • Sahitya Tummala's avatar
      configfs: Fix use-after-free when accessing sd->s_dentry · f6122ed2
      Sahitya Tummala authored
      In the vfs_statx() context, during path lookup, the dentry gets
      added to sd->s_dentry via configfs_attach_attr(). In the end,
      vfs_statx() kills the dentry by calling path_put(), which invokes
      configfs_d_iput(). Ideally, this dentry must be removed from
      sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
      sd->s_dentry is holding reference to a stale dentry pointer whose
      memory is already freed up. This results in use-after-free issue,
      when this stale sd->s_dentry is accessed later in
      configfs_readdir() path.
      
      This issue can be easily reproduced, by running the LTP test case -
      sh fs_racer_file_list.sh /config
      (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
      
      Fixes: 76ae281f ('configfs: fix race between dentry put and lookup')
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      f6122ed2
    • Bard Liao's avatar
      ALSA: hda - Force polling mode on CNL for fixing codec communication · fa763f1b
      Bard Liao authored
      We observed the same issue as reported by commit a8d7bde2
      ("ALSA: hda - Force polling mode on CFL for fixing codec communication")
      We don't have a better solution. So apply the same workaround to CNL.
      Signed-off-by: default avatarBard Liao <yung-chuan.liao@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fa763f1b
  5. 27 May, 2019 1 commit
  6. 26 May, 2019 6 commits
    • Linus Torvalds's avatar
      Linux 5.2-rc2 · cd6c84d8
      Linus Torvalds authored
      cd6c84d8
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · c5b44095
      Linus Torvalds authored
      Pull tracing warning fix from Steven Rostedt:
       "Make the GCC 9 warning for sub struct memset go away.
      
        GCC 9 now warns about calling memset() on partial structures when it
        goes across multiple fields. This adds a helper for the place in
        tracing that does this type of clearing of a structure"
      
      * tag 'trace-v5.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Silence GCC 9 array bounds warning
      c5b44095
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 862f0a32
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "The usual smattering of fixes and tunings that came in too late for
        the merge window, but should not wait four months before they appear
        in a release.
      
        I also travelled a bit more than usual in the first part of May, which
        didn't help with picking up patches and reports promptly"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (33 commits)
        KVM: x86: fix return value for reserved EFER
        tools/kvm_stat: fix fields filter for child events
        KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86 guard
        kvm: selftests: aarch64: compile with warnings on
        kvm: selftests: aarch64: fix default vm mode
        kvm: selftests: aarch64: dirty_log_test: fix unaligned memslot size
        KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
        KVM: x86/pmu: do not mask the value that is written to fixed PMUs
        KVM: x86/pmu: mask the result of rdpmc according to the width of the counters
        x86/kvm/pmu: Set AMD's virt PMU version to 1
        KVM: x86: do not spam dmesg with VMCS/VMCB dumps
        kvm: Check irqchip mode before assign irqfd
        kvm: svm/avic: fix off-by-one in checking host APIC ID
        KVM: selftests: do not blindly clobber registers in guest asm
        KVM: selftests: Remove duplicated TEST_ASSERT in hyperv_cpuid.c
        KVM: LAPIC: Expose per-vCPU timer_advance_ns to userspace
        KVM: LAPIC: Fix lapic_timer_advance_ns parameter overflow
        kvm: vmx: Fix -Wmissing-prototypes warnings
        KVM: nVMX: Fix using __this_cpu_read() in preemptible context
        kvm: fix compilation on s390
        ...
      862f0a32
    • Linus Torvalds's avatar
      Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random · 128f2bfa
      Linus Torvalds authored
      Pull /dev/random fix from Ted Ts'o:
       "Fix a soft lockup regression when reading from /dev/random in early
        boot"
      
      * tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
        random: fix soft lockup when trying to read from an uninitialized blocking pool
      128f2bfa
    • Theodore Ts'o's avatar
      random: fix soft lockup when trying to read from an uninitialized blocking pool · 58be0106
      Theodore Ts'o authored
      Fixes: eb9d1bf0: "random: only read from /dev/random after its pool has received 128 bits"
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      58be0106
    • Miguel Ojeda's avatar
      tracing: Silence GCC 9 array bounds warning · 0c97bf86
      Miguel Ojeda authored
      Starting with GCC 9, -Warray-bounds detects cases when memset is called
      starting on a member of a struct but the size to be cleared ends up
      writing over further members.
      
      Such a call happens in the trace code to clear, at once, all members
      after and including `seq` on struct trace_iterator:
      
          In function 'memset',
              inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3:
          ./include/linux/string.h:344:9: warning: '__builtin_memset' offset
          [8505, 8560] from the object at 'iter' is out of the bounds of
          referenced subobject 'seq' with type 'struct trace_seq' at offset
          4368 [-Warray-bounds]
            344 |  return __builtin_memset(p, c, size);
                |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      In order to avoid GCC complaining about it, we compute the address
      ourselves by adding the offsetof distance instead of referring
      directly to the member.
      
      Since there are two places doing this clear (trace.c and trace_kdb.c),
      take the chance to move the workaround into a single place in
      the internal header.
      
      Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.comSigned-off-by: default avatarMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      [ Removed unnecessary parenthesis around "iter" ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      0c97bf86
  7. 25 May, 2019 1 commit