1. 30 Jul, 2021 17 commits
  2. 29 Jul, 2021 12 commits
  3. 28 Jul, 2021 11 commits
    • Linus Torvalds's avatar
      Merge tag 'fixes_for_v5.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs · 4010a528
      Linus Torvalds authored
      Pull ext2 and reiserfs fixes from Jan Kara:
       "A fix for the ext2 conversion to kmap_local() and two reiserfs
        hardening fixes"
      
      * tag 'fixes_for_v5.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
        reiserfs: check directory items on read from disk
        fs/ext2: Avoid page_address on pages returned by ext2_get_page
        reiserfs: add check for root_inode in reiserfs_fill_super
      4010a528
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v5.14-2' of... · dfe49536
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v5.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
      
      Pull x86 platform driver fixes from Hans de Goede:
       "A set of bug-fixes and new hardware ids.
      
        Highlights:
      
         - amd-pmc fixes
      
         - think-lmi fixes
      
         - various new hardware-ids"
      
      * tag 'platform-drivers-x86-v5.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
        platform/x86: gigabyte-wmi: add support for B550 Aorus Elite V2
        platform/x86: intel-hid: add Alder Lake ACPI device ID
        platform/x86: think-lmi: Fix possible mem-leaks on tlmi_analyze() error-exit
        platform/x86: think-lmi: Split kobject_init() and kobject_add() calls
        platform/x86: think-lmi: Move pending_reboot_attr to the attributes sysfs dir
        platform/x86: amd-pmc: Fix undefined reference to __udivdi3
        platform/x86: amd-pmc: Fix missing unlock on error in amd_pmc_send_cmd()
        platform/x86: wireless-hotkey: remove hardcoded "hp" from the error message
        platform/x86: amd-pmc: Use return code on suspend
        platform/x86: amd-pmc: Add new acpi id for future PMC controllers
        platform/x86: amd-pmc: Add support for ACPI ID AMDI0006
        platform/x86: amd-pmc: Add support for logging s0ix counters
        platform/x86: amd-pmc: Add support for logging SMU metrics
        platform/x86: amd-pmc: call dump registers only once
        platform/x86: amd-pmc: Fix SMU firmware reporting mechanism
        platform/x86: amd-pmc: Fix command completion code
        platform/x86: think-lmi: Add pending_reboot support
      dfe49536
    • Tony Luck's avatar
      dmaengine: idxd: Change license on idxd.h to LGPL · 25905f60
      Tony Luck authored
      This file was given GPL-2.0 license. But LGPL-2.1 makes more sense
      as it needs to be used by libraries outside of the kernel source tree.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      25905f60
    • Miklos Szeredi's avatar
      af_unix: fix garbage collect vs MSG_PEEK · cbcf0112
      Miklos Szeredi authored
      unix_gc() assumes that candidate sockets can never gain an external
      reference (i.e.  be installed into an fd) while the unix_gc_lock is
      held.  Except for MSG_PEEK this is guaranteed by modifying inflight
      count under the unix_gc_lock.
      
      MSG_PEEK does not touch any variable protected by unix_gc_lock (file
      count is not), yet it needs to be serialized with garbage collection.
      Do this by locking/unlocking unix_gc_lock:
      
       1) increment file count
      
       2) lock/unlock barrier to make sure incremented file count is visible
          to garbage collection
      
       3) install file into fd
      
      This is a lock barrier (unlike smp_mb()) that ensures that garbage
      collection is run completely before or completely after the barrier.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cbcf0112
    • Desmond Cheong Zhi Xi's avatar
      btrfs: fix rw device counting in __btrfs_free_extra_devids · b2a61667
      Desmond Cheong Zhi Xi authored
      When removing a writeable device in __btrfs_free_extra_devids, the rw
      device count should be decremented.
      
      This error was caught by Syzbot which reported a warning in
      close_fs_devices:
      
        WARNING: CPU: 1 PID: 9355 at fs/btrfs/volumes.c:1168 close_fs_devices+0x763/0x880 fs/btrfs/volumes.c:1168
        Modules linked in:
        CPU: 0 PID: 9355 Comm: syz-executor552 Not tainted 5.13.0-rc1-syzkaller #0
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        RIP: 0010:close_fs_devices+0x763/0x880 fs/btrfs/volumes.c:1168
        RSP: 0018:ffffc9000333f2f0 EFLAGS: 00010293
        RAX: ffffffff8365f5c3 RBX: 0000000000000001 RCX: ffff888029afd4c0
        RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
        RBP: ffff88802846f508 R08: ffffffff8365f525 R09: ffffed100337d128
        R10: ffffed100337d128 R11: 0000000000000000 R12: dffffc0000000000
        R13: ffff888019be8868 R14: 1ffff1100337d10d R15: 1ffff1100337d10a
        FS:  00007f6f53828700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000000000047c410 CR3: 00000000302a6000 CR4: 00000000001506f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         btrfs_close_devices+0xc9/0x450 fs/btrfs/volumes.c:1180
         open_ctree+0x8e1/0x3968 fs/btrfs/disk-io.c:3693
         btrfs_fill_super fs/btrfs/super.c:1382 [inline]
         btrfs_mount_root+0xac5/0xc60 fs/btrfs/super.c:1749
         legacy_get_tree+0xea/0x180 fs/fs_context.c:592
         vfs_get_tree+0x86/0x270 fs/super.c:1498
         fc_mount fs/namespace.c:993 [inline]
         vfs_kern_mount+0xc9/0x160 fs/namespace.c:1023
         btrfs_mount+0x3d3/0xb50 fs/btrfs/super.c:1809
         legacy_get_tree+0xea/0x180 fs/fs_context.c:592
         vfs_get_tree+0x86/0x270 fs/super.c:1498
         do_new_mount fs/namespace.c:2905 [inline]
         path_mount+0x196f/0x2be0 fs/namespace.c:3235
         do_mount fs/namespace.c:3248 [inline]
         __do_sys_mount fs/namespace.c:3456 [inline]
         __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433
         do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Because fs_devices->rw_devices was not 0 after
      closing all devices. Here is the call trace that was observed:
      
        btrfs_mount_root():
          btrfs_scan_one_device():
            device_list_add();   <---------------- device added
          btrfs_open_devices():
            open_fs_devices():
              btrfs_open_one_device();   <-------- writable device opened,
      	                                     rw device count ++
          btrfs_fill_super():
            open_ctree():
              btrfs_free_extra_devids():
      	  __btrfs_free_extra_devids();  <--- writable device removed,
      	                              rw device count not decremented
      	  fail_tree_roots:
      	    btrfs_close_devices():
      	      close_fs_devices();   <------- rw device count off by 1
      
      As a note, prior to commit cf89af14 ("btrfs: dev-replace: fail
      mount if we don't have replace item with target device"), rw_devices
      was decremented on removing a writable device in
      __btrfs_free_extra_devids only if the BTRFS_DEV_STATE_REPLACE_TGT bit
      was not set for the device. However, this check does not need to be
      reinstated as it is now redundant and incorrect.
      
      In __btrfs_free_extra_devids, we skip removing the device if it is the
      target for replacement. This is done by checking whether device->devid
      == BTRFS_DEV_REPLACE_DEVID. Since BTRFS_DEV_STATE_REPLACE_TGT is set
      only on the device with devid BTRFS_DEV_REPLACE_DEVID, no devices
      should have the BTRFS_DEV_STATE_REPLACE_TGT bit set after the check,
      and so it's redundant to test for that bit.
      
      Additionally, following commit 82372bc8 ("Btrfs: make
      the logic of source device removing more clear"), rw_devices is
      incremented whenever a writeable device is added to the alloc
      list (including the target device in btrfs_dev_replace_finishing), so
      all removals of writable devices from the alloc list should also be
      accompanied by a decrement to rw_devices.
      
      Reported-by: syzbot+a70e2ad0879f160b9217@syzkaller.appspotmail.com
      Fixes: cf89af14 ("btrfs: dev-replace: fail mount if we don't have replace item with target device")
      CC: stable@vger.kernel.org # 5.10+
      Tested-by: syzbot+a70e2ad0879f160b9217@syzkaller.appspotmail.com
      Reviewed-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarDesmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      b2a61667
    • Filipe Manana's avatar
      btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction · ecc64fab
      Filipe Manana authored
      When checking if we need to log the new name of a renamed inode, we are
      checking if the inode and its parent inode have been logged before, and if
      not we don't log the new name. The check however is buggy, as it directly
      compares the logged_trans field of the inodes versus the ID of the current
      transaction. The problem is that logged_trans is a transient field, only
      stored in memory and never persisted in the inode item, so if an inode
      was logged before, evicted and reloaded, its logged_trans field is set to
      a value of 0, meaning the check will return false and the new name of the
      renamed inode is not logged. If the old parent directory was previously
      fsynced and we deleted the logged directory entries corresponding to the
      old name, we end up with a log that when replayed will delete the renamed
      inode.
      
      The following example triggers the problem:
      
        $ mkfs.btrfs -f /dev/sdc
        $ mount /dev/sdc /mnt
      
        $ mkdir /mnt/A
        $ mkdir /mnt/B
        $ echo -n "hello world" > /mnt/A/foo
      
        $ sync
      
        # Add some new file to A and fsync directory A.
        $ touch /mnt/A/bar
        $ xfs_io -c "fsync" /mnt/A
      
        # Now trigger inode eviction. We are only interested in triggering
        # eviction for the inode of directory A.
        $ echo 2 > /proc/sys/vm/drop_caches
      
        # Move foo from directory A to directory B.
        # This deletes the directory entries for foo in A from the log, and
        # does not add the new name for foo in directory B to the log, because
        # logged_trans of A is 0, which is less than the current transaction ID.
        $ mv /mnt/A/foo /mnt/B/foo
      
        # Now make an fsync to anything except A, B or any file inside them,
        # like for example create a file at the root directory and fsync this
        # new file. This syncs the log that contains all the changes done by
        # previous rename operation.
        $ touch /mnt/baz
        $ xfs_io -c "fsync" /mnt/baz
      
        <power fail>
      
        # Mount the filesystem and replay the log.
        $ mount /dev/sdc /mnt
      
        # Check the filesystem content.
        $ ls -1R /mnt
        /mnt/:
        A
        B
        baz
      
        /mnt/A:
        bar
      
        /mnt/B:
        $
      
        # File foo is gone, it's neither in A/ nor in B/.
      
      Fix this by using the inode_logged() helper at btrfs_log_new_name(), which
      safely checks if an inode was logged before in the current transaction.
      
      A test case for fstests will follow soon.
      
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      ecc64fab
    • Goldwyn Rodrigues's avatar
      btrfs: mark compressed range uptodate only if all bio succeed · 240246f6
      Goldwyn Rodrigues authored
      In compression write endio sequence, the range which the compressed_bio
      writes is marked as uptodate if the last bio of the compressed (sub)bios
      is completed successfully. There could be previous bio which may
      have failed which is recorded in cb->errors.
      
      Set the writeback range as uptodate only if cb->errors is zero, as opposed
      to checking only the last bio's status.
      
      Backporting notes: in all versions up to 4.4 the last argument is always
      replaced by "!cb->errors".
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarGoldwyn Rodrigues <rgoldwyn@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      240246f6
    • Hao Xu's avatar
      io_uring: fix poll requests leaking second poll entries · a890d01e
      Hao Xu authored
      For pure poll requests, it doesn't remove the second poll wait entry
      when it's done, neither after vfs_poll() or in the poll completion
      handler. We should remove the second poll wait entry.
      And we use io_poll_remove_double() rather than io_poll_remove_waitqs()
      since the latter has some redundant logic.
      
      Fixes: 88e41cf9 ("io_uring: add multishot mode for IORING_OP_POLL_ADD")
      Cc: stable@vger.kernel.org # 5.13+
      Signed-off-by: default avatarHao Xu <haoxu@linux.alibaba.com>
      Link: https://lore.kernel.org/r/20210728030322.12307-1-haoxu@linux.alibaba.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      a890d01e
    • Jens Axboe's avatar
      io_uring: don't block level reissue off completion path · ef046888
      Jens Axboe authored
      Some setups, like SCSI, can throw spurious -EAGAIN off the softirq
      completion path. Normally we expect this to happen inline as part
      of submission, but apparently SCSI has a weird corner case where it
      can happen as part of normal completions.
      
      This should be solved by having the -EAGAIN bubble back up the stack
      as part of submission, but previous attempts at this failed and we're
      not just quite there yet. Instead we currently use REQ_F_REISSUE to
      handle this case.
      
      For now, catch it in io_rw_should_reissue() and prevent a reissue
      from a bogus path.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarFabian Ebner <f.ebner@proxmox.com>
      Tested-by: default avatarFabian Ebner <f.ebner@proxmox.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      ef046888
    • Thomas Weißschuh's avatar
    • Ping Bao's avatar
      platform/x86: intel-hid: add Alder Lake ACPI device ID · a59c7b6c
      Ping Bao authored
      Alder Lake has a new ACPI ID for Intel HID event filter device.
      Signed-off-by: default avatarPing Bao <ping.a.bao@intel.com>
      Link: https://lore.kernel.org/r/20210721225615.20575-1-ping.a.bao@intel.comSigned-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      a59c7b6c