1. 11 Mar, 2023 6 commits
    • Zhihao Cheng's avatar
      ext4: zero i_disksize when initializing the bootloader inode · f5361da1
      Zhihao Cheng authored
      If the boot loader inode has never been used before, the
      EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
      i_size to 0.  However, if the "never before used" boot loader has a
      non-zero i_size, then i_disksize will be non-zero, and the
      inconsistency between i_size and i_disksize can trigger a kernel
      warning:
      
       WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
       CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
       RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
       Call Trace:
        vfs_write+0x3b1/0x5c0
        ksys_write+0x77/0x160
        __x64_sys_write+0x22/0x30
        do_syscall_64+0x39/0x80
      
      Reproducer:
       1. create corrupted image and mount it:
             mke2fs -t ext4 /tmp/foo.img 200
             debugfs -wR "sif <5> size 25700" /tmp/foo.img
             mount -t ext4 /tmp/foo.img /mnt
             cd /mnt
             echo 123 > file
       2. Run the reproducer program:
             posix_memalign(&buf, 1024, 1024)
             fd = open("file", O_RDWR | O_DIRECT);
             ioctl(fd, EXT4_IOC_SWAP_BOOT);
             write(fd, buf, 1024);
      
      Fix this by setting i_disksize as well as i_size to zero when
      initiaizing the boot loader inode.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
      Cc: stable@kernel.org
      Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      f5361da1
    • Ye Bin's avatar
      ext4: make sure fs error flag setted before clear journal error · f57886ca
      Ye Bin authored
      Now, jounral error number maybe cleared even though ext4_commit_super()
      failed. This may lead to error flag miss, then fsck will miss to check
      file system deeply.
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307061703.245965-3-yebin@huaweicloud.com
      f57886ca
    • Ye Bin's avatar
      ext4: commit super block if fs record error when journal record without error · eee00237
      Ye Bin authored
      Now, 'es->s_state' maybe covered by recover journal. And journal errno
      maybe not recorded in journal sb as IO error. ext4_update_super() only
      update error information when 'sbi->s_add_error_count' large than zero.
      Then 'EXT4_ERROR_FS' flag maybe lost.
      To solve above issue just recover 'es->s_state' error flag after journal
      replay like error info.
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarBaokun Li <libaokun1@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307061703.245965-2-yebin@huaweicloud.com
      eee00237
    • Theodore Ts'o's avatar
      ext4, jbd2: add an optimized bmap for the journal inode · 62913ae9
      Theodore Ts'o authored
      The generic bmap() function exported by the VFS takes locks and does
      checks that are not necessary for the journal inode.  So allow the
      file system to set a journal-optimized bmap function in
      journal->j_bmap.
      
      Reported-by: syzbot+9543479984ae9e576000@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?id=e4aaa78795e490421c79f76ec3679006c8ff4cf0Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      62913ae9
    • Ye Bin's avatar
      ext4: fix WARNING in ext4_update_inline_data · 2b96b4a5
      Ye Bin authored
      Syzbot found the following issue:
      EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
      fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
      fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
      Modules linked in:
      CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
      RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
      RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
      RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
      RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
      RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
      R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
      R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
      FS:  0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       __alloc_pages_node include/linux/gfp.h:237 [inline]
       alloc_pages_node include/linux/gfp.h:260 [inline]
       __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
       __do_kmalloc_node mm/slab_common.c:956 [inline]
       __kmalloc+0xfe/0x190 mm/slab_common.c:981
       kmalloc include/linux/slab.h:584 [inline]
       kzalloc include/linux/slab.h:720 [inline]
       ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
       ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
       ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
       ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
       ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
       ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
       lookup_open fs/namei.c:3413 [inline]
       open_last_lookups fs/namei.c:3481 [inline]
       path_openat+0x12ac/0x2dd0 fs/namei.c:3711
       do_filp_open+0x264/0x4f0 fs/namei.c:3741
       do_sys_openat2+0x124/0x4e0 fs/open.c:1310
       do_sys_open fs/open.c:1326 [inline]
       __do_sys_openat fs/open.c:1342 [inline]
       __se_sys_openat fs/open.c:1337 [inline]
       __x64_sys_openat+0x243/0x290 fs/open.c:1337
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Above issue happens as follows:
      ext4_iget
         ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
      ext4_try_add_inline_entry
         __ext4_mark_inode_dirty
            ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
               ext4_xattr_shift_entries
      	 ->after shift i_inline_off is incorrect, actually is change to 176
      ext4_try_add_inline_entry
        ext4_update_inline_dir
          get_max_inline_xattr_value_size
            if (EXT4_I(inode)->i_inline_off)
      	entry = (struct ext4_xattr_entry *)((void *)raw_inode +
      			EXT4_I(inode)->i_inline_off);
              free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
      	->As entry is incorrect, then 'free' may be negative
         ext4_update_inline_data
            value = kzalloc(len, GFP_NOFS);
            -> len is unsigned int, maybe very large, then trigger warning when
               'kzalloc()'
      
      To resolve the above issue we need to update 'i_inline_off' after
      'ext4_xattr_shift_entries()'.  We do not need to set
      EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
      already sets this flag if needed.  Setting EXT4_STATE_MAY_INLINE_DATA
      when it is needed may trigger a BUG_ON in ext4_writepages().
      
      Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com
      Cc: stable@kernel.org
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      2b96b4a5
    • Ye Bin's avatar
      ext4: move where set the MAY_INLINE_DATA flag is set · 1dcdce59
      Ye Bin authored
      The only caller of ext4_find_inline_data_nolock() that needs setting of
      EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode().  In
      ext4_write_inline_data_end() we just need to update inode->i_inline_off.
      Since we are going to add one more caller that does not need to set
      EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA
      out to ext4_iget_extra_inode().
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Cc: stable@kernel.org
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      1dcdce59
  2. 08 Mar, 2023 7 commits
    • Jan Kara's avatar
      ext4: Fix deadlock during directory rename · 3c92792d
      Jan Kara authored
      As lockdep properly warns, we should not be locking i_rwsem while having
      transactions started as the proper lock ordering used by all directory
      handling operations is i_rwsem -> transaction start. Fix the lock
      ordering by moving the locking of the directory earlier in
      ext4_rename().
      
      Reported-by: syzbot+9d16c39efb5fade84574@syzkaller.appspotmail.com
      Fixes: 0813299c ("ext4: Fix possible corruption when moving a directory")
      Link: https://syzkaller.appspot.com/bug?extid=9d16c39efb5fade84574Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230301141004.15087-1-jack@suse.czSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      3c92792d
    • Tudor Ambarus's avatar
      ext4: Fix comment about the 64BIT feature · 7fc1f5c2
      Tudor Ambarus authored
      64BIT is part of the incompatible feature set, update the comment
      accordingly.
      Signed-off-by: default avatarTudor Ambarus <tudor.ambarus@linaro.org>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Link: https://lore.kernel.org/r/20230301133842.671821-1-tudor.ambarus@linaro.orgSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      7fc1f5c2
    • Wu Bo's avatar
      docs: ext4: modify the group desc size to 64 · b7eef407
      Wu Bo authored
      Since the default ext4 group desc size is 64 now (assuming that the
      64-bit feature is enbled). And the size mentioned in this doc is 64 too.
      Change it to 64.
      Signed-off-by: default avatarWu Bo <bo.wu@vivo.com>
      Acked-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Link: https://lore.kernel.org/r/20230222013525.14748-1-bo.wu@vivo.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      b7eef407
    • Darrick J. Wong's avatar
      ext4: fix another off-by-one fsmap error on 1k block filesystems · c993799b
      Darrick J. Wong authored
      Apparently syzbot figured out that issuing this FSMAP call:
      
      struct fsmap_head cmd = {
      	.fmh_count	= ...;
      	.fmh_keys	= {
      		{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
      		{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
      	},
      ...
      };
      ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
      
      Produces this crash if the underlying filesystem is a 1k-block ext4
      filesystem:
      
      kernel BUG at fs/ext4/ext4.h:3331!
      invalid opcode: 0000 [#1] PREEMPT SMP
      CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G        W  O       6.2.0-rc8-achx
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
      RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
      RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
      RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
      RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
      RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
      R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
      R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
      FS:  00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
      Call Trace:
       <TASK>
       ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
       ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
       ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
       ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
       __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
       __x64_sys_ioctl+0x82/0xa0
       do_syscall_64+0x2b/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      RIP: 0033:0x7fdf20558aff
      RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff
      RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003
      RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010
      R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000
      
      For GETFSMAP calls, the caller selects a physical block device by
      writing its block number into fsmap_head.fmh_keys[01].fmr_device.
      To query mappings for a subrange of the device, the starting byte of the
      range is written to fsmap_head.fmh_keys[0].fmr_physical and the last
      byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.
      
      IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd
      set the inputs as follows:
      
      	fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},
      	fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},
      
      Which would return you whatever is mapped in the 12 bytes starting at
      physical offset 3.
      
      The crash is due to insufficient range validation of keys[1] in
      ext4_getfsmap_datadev.  On 1k-block filesystems, block 0 is not part of
      the filesystem, which means that s_first_data_block is nonzero.
      ext4_get_group_no_and_offset subtracts this quantity from the blocknr
      argument before cracking it into a group number and a block number
      within a group.  IOWs, block group 0 spans blocks 1-8192 (1-based)
      instead of 0-8191 (0-based) like what happens with larger blocksizes.
      
      The net result of this encoding is that blocknr < s_first_data_block is
      not a valid input to this function.  The end_fsb variable is set from
      the keys that are copied from userspace, which means that in the above
      example, its value is zero.  That leads to an underflow here:
      
      	blocknr = blocknr - le32_to_cpu(es->s_first_data_block);
      
      The division then operates on -1:
      
      	offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >>
      		EXT4_SB(sb)->s_cluster_bits;
      
      Leaving an impossibly large group number (2^32-1) in blocknr.
      ext4_getfsmap_check_keys checked that keys[0].fmr_physical and
      keys[1].fmr_physical are in increasing order, but
      ext4_getfsmap_datadev adjusts keys[0].fmr_physical to be at least
      s_first_data_block.  This implies that we have to check it again after
      the adjustment, which is the piece that I forgot.
      
      Reported-by: syzbot+6be2b977c89f79b6b153@syzkaller.appspotmail.com
      Fixes: 4a495624 ("ext4: fix off-by-one fsmap error on 1k block filesystems")
      Link: https://syzkaller.appspot.com/bug?id=79d5768e9bfe362911ac1a5057a36fc6b5c30002
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnoliaSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      c993799b
    • Eric Whitney's avatar
      ext4: fix RENAME_WHITEOUT handling for inline directories · c9f62c8b
      Eric Whitney authored
      A significant number of xfstests can cause ext4 to log one or more
      warning messages when they are run on a test file system where the
      inline_data feature has been enabled.  An example:
      
      "EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode
       #16385: comm fsstress: No space for directory leaf checksum. Please
      run e2fsck -D."
      
      The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068,
      070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585,
      589, 626, 631, and 650.
      
      In this situation, the warning message indicates a bug in the code that
      performs the RENAME_WHITEOUT operation on a directory entry that has
      been stored inline.  It doesn't detect that the directory is stored
      inline, and incorrectly attempts to compute a dirent block checksum on
      the whiteout inode when creating it.  This attempt fails as a result
      of the integrity checking in get_dirent_tail (usually due to a failure
      to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message
      is then emitted.
      
      Fix this by simply collecting the inlined data state at the time the
      search for the source directory entry is performed.  Existing code
      handles the rest, and this is sufficient to eliminate all spurious
      warning messages produced by the tests above.  Go one step further
      and do the same in the code that resets the source directory entry in
      the event of failure.  The inlined state should be present in the
      "old" struct, but given the possibility of a race there's no harm
      in taking a conservative approach and getting that information again
      since the directory entry is being reread anyway.
      
      Fixes: b7ff91fd ("ext4: find old entry again if failed to rename whiteout")
      Cc: stable@kernel.org
      Signed-off-by: default avatarEric Whitney <enwlinux@gmail.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      c9f62c8b
    • Thomas Weißschuh's avatar
      ext4: make kobj_type structures constant · 60db00e0
      Thomas Weißschuh authored
      Since commit ee6d3dd4 ("driver core: make kobj_type constant.")
      the driver core allows the usage of const struct kobj_type.
      
      Take advantage of this to constify the structure definitions to prevent
      modification at runtime.
      Signed-off-by: default avatarThomas Weißschuh <linux@weissschuh.net>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230209-kobj_type-ext4-v1-1-6865fb05c1f8@weissschuh.netSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      60db00e0
    • Eric Biggers's avatar
      ext4: fix cgroup writeback accounting with fs-layer encryption · ffec85d5
      Eric Biggers authored
      When writing a page from an encrypted file that is using
      filesystem-layer encryption (not inline encryption), ext4 encrypts the
      pagecache page into a bounce page, then writes the bounce page.
      
      It also passes the bounce page to wbc_account_cgroup_owner().  That's
      incorrect, because the bounce page is a newly allocated temporary page
      that doesn't have the memory cgroup of the original pagecache page.
      This makes wbc_account_cgroup_owner() not account the I/O to the owner
      of the pagecache page as it should.
      
      Fix this by always passing the pagecache page to
      wbc_account_cgroup_owner().
      
      Fixes: 001e4a87 ("ext4: implement cgroup writeback support")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Link: https://lore.kernel.org/r/20230203005503.141557-1-ebiggers@kernel.orgSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      ffec85d5
  3. 25 Feb, 2023 3 commits
  4. 19 Feb, 2023 10 commits
  5. 15 Feb, 2023 1 commit
  6. 09 Feb, 2023 3 commits
  7. 22 Jan, 2023 2 commits
    • Linus Torvalds's avatar
      Linux 6.2-rc5 · 2241ab53
      Linus Torvalds authored
      2241ab53
    • Linus Torvalds's avatar
      Merge tag 'io_uring-6.2-2023-01-21' of git://git.kernel.dk/linux · 95f184d0
      Linus Torvalds authored
      Pull another io_uring fix from Jens Axboe:
       "Just a single fix for a regression that happened in this release due
        to a poll change. Normally I would've just deferred it to next week,
        but since the original fix got picked up by stable, I think it's
        better to just send this one off separately.
      
        The issue is around the poll race fix, and how it mistakenly also got
        applied to multishot polling. Those don't need the race fix, and we
        should not be doing any reissues for that case. Exhaustive test cases
        were written and committed to the liburing regression suite for the
        reported issue, and additions for similar issues"
      
      * tag 'io_uring-6.2-2023-01-21' of git://git.kernel.dk/linux:
        io_uring/poll: don't reissue in case of poll race on multishot request
      95f184d0
  8. 21 Jan, 2023 8 commits
    • Linus Torvalds's avatar
      Merge tag 'char-misc-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · f6714402
      Linus Torvalds authored
      Pull char/misc driver fixes from Greg KH:
       "Here are some small char/misc and other subsystem driver fixes for
        6.2-rc5 to resolve a few reported issues. They include:
      
         - long time pending fastrpc fixes (should have gone into 6.1, my
           fault)
      
         - mei driver/bus fixes and new device ids
      
         - interconnect driver fixes for reported problems
      
         - vmci bugfix
      
         - w1 driver bugfixes for reported problems
      
        Almost all of these have been in linux-next with no reported problems,
        the rest have all passed 0-day bot testing in my tree and on the
        mailing lists where they have sat too long due to me taking a long
        time to catch up on my pending patch queue"
      
      * tag 'char-misc-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        VMCI: Use threaded irqs instead of tasklets
        misc: fastrpc: Pass bitfield into qcom_scm_assign_mem
        gsmi: fix null-deref in gsmi_get_variable
        misc: fastrpc: Fix use-after-free race condition for maps
        misc: fastrpc: Don't remove map on creater_process and device_release
        misc: fastrpc: Fix use-after-free and race in fastrpc_map_find
        misc: fastrpc: fix error code in fastrpc_req_mmap()
        mei: me: add meteor lake point M DID
        mei: bus: fix unlink on bus in error path
        w1: fix WARNING after calling w1_process()
        w1: fix deadloop in __w1_remove_master_device()
        comedi: adv_pci1760: Fix PWM instruction handling
        interconnect: qcom: rpm: Use _optional func for provider clocks
        interconnect: qcom: msm8996: Fix regmap max_register values
        interconnect: qcom: msm8996: Provide UFS clocks to A2NoC
        dt-bindings: interconnect: Add UFS clocks to MSM8996 A2NoC
      f6714402
    • Linus Torvalds's avatar
      Merge tag 'driver-core-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core · c88a3114
      Linus Torvalds authored
      Pull driver core fixes from Greg KH:
       "Here are three small driver and kernel core fixes for 6.2-rc5. They
        include:
      
         - potential gadget fixup in do_prlimit
      
         - device property refcount leak fix
      
         - test_async_probe bugfix for reported problem"
      
      * tag 'driver-core-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
        prlimit: do_prlimit needs to have a speculation check
        driver core: Fix test_async_probe_init saves device in wrong array
        device property: fix of node refcount leak in fwnode_graph_get_next_endpoint()
      c88a3114
    • Linus Torvalds's avatar
      Merge tag 'staging-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · bb86d657
      Linus Torvalds authored
      Pull staging driver fix from Greg KH:
       "Here is a single staging driver fix for 6.2-rc5. It resolves a build
        issue reported and Fixed by Arnd in the vc04_services driver. It's
        been in linux-next this week with no reported problems"
      
      * tag 'staging-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        staging: vchiq_arm: fix enum vchiq_status return types
      bb86d657
    • Linus Torvalds's avatar
      Merge tag 'tty-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · bd5cc6ee
      Linus Torvalds authored
      Pull tty/serial driver fixes from Greg KH:
       "Here are some small tty and serial driver fixes for 6.2-rc5 that
        resolve a number of tiny reported issues and some new device ids. They
        include:
      
         - new device id for the exar serial driver
      
         - speakup tty driver bugfix
      
         - atmel serial driver baudrate fixup
      
         - stm32 serial driver bugfix and then revert as the bugfix broke the
           build. That will come back in a later pull request once it is all
           worked out properly.
      
         - amba-pl011 serial driver rs486 mode bugfix
      
         - qcom_geni serial driver bugfix
      
        Most of these have been in linux-next with no reported problems (well,
        other than the build breakage which generated the revert), the new
        device id passed 0-day testing"
      
      * tag 'tty-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        serial: exar: Add support for Sealevel 7xxxC serial cards
        Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler"
        tty: serial: qcom_geni: avoid duplicate struct member init
        serial: atmel: fix incorrect baudrate setup
        tty: fix possible null-ptr-defer in spk_ttyio_release
        serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
        serial: amba-pl011: fix high priority character transmission in rs486 mode
        serial: pch_uart: Pass correct sg to dma_unmap_sg()
        tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
      bd5cc6ee
    • Linus Torvalds's avatar
      Merge tag 'usb-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · e67da288
      Linus Torvalds authored
      Pull USB / Thunderbolt fixes from Greg KH:
       "Here are a number of small USB and Thunderbolt driver fixes and new
        device id changes for 6.2-rc5. Included in here are:
      
         - thunderbolt bugfixes for reported problems
      
         - new usb-serial driver ids added
      
         - onboard_hub usb driver fixes for much-reported problems
      
         - xhci bugfixes
      
         - typec bugfixes
      
         - ehci-fsl driver module alias fix
      
         - iowarrior header size fix
      
         - usb gadget driver fixes
      
        All of these, except for the iowarrior fix, have been in linux-next
        with no reported issues. The iowarrior fix passed the 0-day testing
        and is a one digit change based on a reported problem in the driver
        (which was written to a spec, not the real device that is now
        available)"
      
      * tag 'usb-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (40 commits)
        USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
        usb: host: ehci-fsl: Fix module alias
        usb: dwc3: fix extcon dependency
        usb: core: hub: disable autosuspend for TI TUSB8041
        USB: fix misleading usb_set_intfdata() kernel doc
        usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
        USB: gadget: Add ID numbers to configfs-gadget driver names
        usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail
        usb: gadget: g_webcam: Send color matching descriptor per frame
        usb: typec: altmodes/displayport: Use proper macro for pin assignment check
        usb: typec: altmodes/displayport: Fix pin assignment calculation
        usb: typec: altmodes/displayport: Add pin assignment helper
        usb: gadget: f_fs: Ensure ep0req is dequeued before free_request
        usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
        usb: misc: onboard_hub: Move 'attach' work to the driver
        usb: misc: onboard_hub: Invert driver registration order
        usb: ucsi: Ensure connector delayed work items are flushed
        usb: musb: fix error return code in omap2430_probe()
        usb: chipidea: core: fix possible constant 0 if use IS_ERR(ci->role_switch)
        xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
        ...
      e67da288
    • Linus Torvalds's avatar
      Merge tag 'kbuild-fixes-v6.2-3' of... · 83cd5fd0
      Linus Torvalds authored
      Merge tag 'kbuild-fixes-v6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
      
      Pull Kbuild fixes from Masahiro Yamada:
      
       - Hide LDFLAGS_vmlinux from decompressor Makefiles to fix error
         messages when GNU Make 4.4 is used.
      
       - Fix 'make modules' build error when CONFIG_DEBUG_INFO_BTF_MODULES=y.
      
       - Fix warnings emitted by GNU Make 4.4 in scripts/kconfig/Makefile.
      
       - Support GNU Make 4.4 for scripts/jobserver-exec.
      
       - Show clearer error message when kernel/gen_kheaders.sh fails due to
         missing cpio.
      
      * tag 'kbuild-fixes-v6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
        kheaders: explicitly validate existence of cpio command
        scripts: support GNU make 4.4 in jobserver-exec
        kconfig: Update all declared targets
        scripts: rpm: make clear that mkspec script contains 4.13 feature
        init/Kconfig: fix LOCALVERSION_AUTO help text
        kbuild: fix 'make modules' error when CONFIG_DEBUG_INFO_BTF_MODULES=y
        kbuild: export top-level LDFLAGS_vmlinux only to scripts/Makefile.vmlinux
        init/version-timestamp.c: remove unneeded #include <linux/version.h>
        docs: kbuild: remove mention to dropped $(objtree) feature
      83cd5fd0
    • Linus Torvalds's avatar
      ext4: deal with legacy signed xattr name hash values · f3bbac32
      Linus Torvalds authored
      We potentially have old hashes of the xattr names generated on systems
      with signed 'char' types.  Now that everybody uses '-funsigned-char',
      those hashes will no longer match.
      
      This only happens if you use xattrs names that have the high bit set,
      which probably doesn't happen in practice, but the xfstest generic/454
      shows it.
      
      Instead of adding a new "signed xattr hash filesystem" bit and having to
      deal with all the possible combinations, just calculate the hash both
      ways if the first one fails, and always generate new hashes with the
      proper unsigned char version.
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Link: https://lore.kernel.org/oe-lkp/202212291509.704a11c9-oliver.sang@intel.com
      Link: https://lore.kernel.org/all/CAHk-=whUNjwqZXa-MH9KMmc_CpQpoFKFjAB9ZKHuu=TbsouT4A@mail.gmail.com/
      Exposed-by: 3bc753c0 ("kbuild: treat char as always unsigned")
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: Andreas Dilger <adilger@dilger.ca>
      Cc: Theodore Ts'o <tytso@mit.edu>,
      Cc: Jason Donenfeld <Jason@zx2c4.com>
      Cc: Masahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f3bbac32
    • Greg Kroah-Hartman's avatar
      prlimit: do_prlimit needs to have a speculation check · 73979060
      Greg Kroah-Hartman authored
      do_prlimit() adds the user-controlled resource value to a pointer that
      will subsequently be dereferenced.  In order to help prevent this
      codepath from being used as a spectre "gadget" a barrier needs to be
      added after checking the range.
      Reported-by: default avatarJordy Zomer <jordyzomer@google.com>
      Tested-by: default avatarJordy Zomer <jordyzomer@google.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73979060