History log of /openbmc/linux/fs/ext4/xattr.c (Results 1 – 25 of 1663)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.6.71
# 9144f784 09-Jan-2025 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.70' into for/openbmc/dev-6.6

This is the 6.6.70 stable release

Conflicts:
include/linux/usb/chipidea.h

Conflict was a trivial addition.

Signed-off-by: Andrew Jeffery <andrew@c

Merge tag 'v6.6.70' into for/openbmc/dev-6.6

This is the 6.6.70 stable release

Conflicts:
include/linux/usb/chipidea.h

Conflict was a trivial addition.

Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...


Revision tags: v6.6.70, v6.6.69, v6.6.68, v6.6.67, v6.6.66, v6.6.65, v6.6.64, v6.6.63, v6.6.62, v6.6.61, v6.6.60, v6.6.59, v6.6.58, v6.6.57, v6.6.56, v6.6.55, v6.6.54, v6.6.53, v6.6.52, v6.6.51, v6.6.50, v6.6.49, v6.6.48, v6.6.47, v6.6.46, v6.6.45, v6.6.44, v6.6.43, v6.6.42, v6.6.41, v6.6.40, v6.6.39, v6.6.38, v6.6.37, v6.6.36, v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6
# fa42d5f1 04-Oct-2023 Jeff Layton <jlayton@kernel.org>

ext4: convert to new timestamp accessors

[ Upstream commit b898ab233611f7903d88c0b10f8145e1c15d3642 ]

Convert to using the new inode timestamp accessor functions.

Signed-off-by: Jeff Layton <jlayt

ext4: convert to new timestamp accessors

[ Upstream commit b898ab233611f7903d88c0b10f8145e1c15d3642 ]

Convert to using the new inode timestamp accessor functions.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20231004185347.80880-33-jlayton@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Stable-dep-of: c7fc0366c656 ("ext4: partial zero eof block on unaligned inode size extension")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# 7b7fd0ac 17-Oct-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.57' into for/openbmc/dev-6.6

This is the 6.6.57 stable release


# e789b7fd 01-Aug-2024 Wojciech Gładysz <wojciech.gladysz@infogain.com>

ext4: nested locking for xattr inode

[ Upstream commit d1bc560e9a9c78d0b2314692847fc8661e0aeb99 ]

Add nested locking with I_MUTEX_XATTR subclass to avoid lockdep warning
while handling xattr inode

ext4: nested locking for xattr inode

[ Upstream commit d1bc560e9a9c78d0b2314692847fc8661e0aeb99 ]

Add nested locking with I_MUTEX_XATTR subclass to avoid lockdep warning
while handling xattr inode on file open syscall at ext4_xattr_inode_iget.

Backtrace
EXT4-fs (loop0): Ignoring removed oldalloc option
======================================================
WARNING: possible circular locking dependency detected
5.10.0-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor543/2794 is trying to acquire lock:
ffff8880215e1a48 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:782 [inline]
ffff8880215e1a48 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}, at: ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425

but task is already holding lock:
ffff8880215e3278 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x136d/0x19c0 fs/ext4/inode.c:5559

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&ei->i_data_sem/3){++++}-{3:3}:
lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
down_write+0x93/0x180 kernel/locking/rwsem.c:1564
ext4_update_i_disksize fs/ext4/ext4.h:3267 [inline]
ext4_xattr_inode_write fs/ext4/xattr.c:1390 [inline]
ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1538 [inline]
ext4_xattr_set_entry+0x331a/0x3d80 fs/ext4/xattr.c:1662
ext4_xattr_ibody_set+0x124/0x390 fs/ext4/xattr.c:2228
ext4_xattr_set_handle+0xc27/0x14e0 fs/ext4/xattr.c:2385
ext4_xattr_set+0x219/0x390 fs/ext4/xattr.c:2498
ext4_xattr_user_set+0xc9/0xf0 fs/ext4/xattr_user.c:40
__vfs_setxattr+0x404/0x450 fs/xattr.c:177
__vfs_setxattr_noperm+0x11d/0x4f0 fs/xattr.c:208
__vfs_setxattr_locked+0x1f9/0x210 fs/xattr.c:266
vfs_setxattr+0x112/0x2c0 fs/xattr.c:283
setxattr+0x1db/0x3e0 fs/xattr.c:548
path_setxattr+0x15a/0x240 fs/xattr.c:567
__do_sys_setxattr fs/xattr.c:582 [inline]
__se_sys_setxattr fs/xattr.c:578 [inline]
__x64_sys_setxattr+0xc5/0xe0 fs/xattr.c:578
do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
entry_SYSCALL_64_after_hwframe+0x61/0xcb

-> #0 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:2988 [inline]
check_prevs_add kernel/locking/lockdep.c:3113 [inline]
validate_chain+0x1695/0x58f0 kernel/locking/lockdep.c:3729
__lock_acquire+0x12fd/0x20d0 kernel/locking/lockdep.c:4955
lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
down_write+0x93/0x180 kernel/locking/rwsem.c:1564
inode_lock include/linux/fs.h:782 [inline]
ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425
ext4_xattr_inode_get+0x138/0x410 fs/ext4/xattr.c:485
ext4_xattr_move_to_block fs/ext4/xattr.c:2580 [inline]
ext4_xattr_make_inode_space fs/ext4/xattr.c:2682 [inline]
ext4_expand_extra_isize_ea+0xe70/0x1bb0 fs/ext4/xattr.c:2774
__ext4_expand_extra_isize+0x304/0x3f0 fs/ext4/inode.c:5898
ext4_try_to_expand_extra_isize fs/ext4/inode.c:5941 [inline]
__ext4_mark_inode_dirty+0x591/0x810 fs/ext4/inode.c:6018
ext4_setattr+0x1400/0x19c0 fs/ext4/inode.c:5562
notify_change+0xbb6/0xe60 fs/attr.c:435
do_truncate+0x1de/0x2c0 fs/open.c:64
handle_truncate fs/namei.c:2970 [inline]
do_open fs/namei.c:3311 [inline]
path_openat+0x29f3/0x3290 fs/namei.c:3425
do_filp_open+0x20b/0x450 fs/namei.c:3452
do_sys_openat2+0x124/0x460 fs/open.c:1207
do_sys_open fs/open.c:1223 [inline]
__do_sys_open fs/open.c:1231 [inline]
__se_sys_open fs/open.c:1227 [inline]
__x64_sys_open+0x221/0x270 fs/open.c:1227
do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
entry_SYSCALL_64_after_hwframe+0x61/0xcb

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&ei->i_data_sem/3);
lock(&ea_inode->i_rwsem#7/1);
lock(&ei->i_data_sem/3);
lock(&ea_inode->i_rwsem#7/1);

*** DEADLOCK ***

5 locks held by syz-executor543/2794:
#0: ffff888026fbc448 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x4a/0x2a0 fs/namespace.c:365
#1: ffff8880215e3488 (&sb->s_type->i_mutex_key#7){++++}-{3:3}, at: inode_lock include/linux/fs.h:782 [inline]
#1: ffff8880215e3488 (&sb->s_type->i_mutex_key#7){++++}-{3:3}, at: do_truncate+0x1cf/0x2c0 fs/open.c:62
#2: ffff8880215e3310 (&ei->i_mmap_sem){++++}-{3:3}, at: ext4_setattr+0xec4/0x19c0 fs/ext4/inode.c:5519
#3: ffff8880215e3278 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x136d/0x19c0 fs/ext4/inode.c:5559
#4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_write_trylock_xattr fs/ext4/xattr.h:162 [inline]
#4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_try_to_expand_extra_isize fs/ext4/inode.c:5938 [inline]
#4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: __ext4_mark_inode_dirty+0x4fb/0x810 fs/ext4/inode.c:6018

stack backtrace:
CPU: 1 PID: 2794 Comm: syz-executor543 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x177/0x211 lib/dump_stack.c:118
print_circular_bug+0x146/0x1b0 kernel/locking/lockdep.c:2002
check_noncircular+0x2cc/0x390 kernel/locking/lockdep.c:2123
check_prev_add kernel/locking/lockdep.c:2988 [inline]
check_prevs_add kernel/locking/lockdep.c:3113 [inline]
validate_chain+0x1695/0x58f0 kernel/locking/lockdep.c:3729
__lock_acquire+0x12fd/0x20d0 kernel/locking/lockdep.c:4955
lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
down_write+0x93/0x180 kernel/locking/rwsem.c:1564
inode_lock include/linux/fs.h:782 [inline]
ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425
ext4_xattr_inode_get+0x138/0x410 fs/ext4/xattr.c:485
ext4_xattr_move_to_block fs/ext4/xattr.c:2580 [inline]
ext4_xattr_make_inode_space fs/ext4/xattr.c:2682 [inline]
ext4_expand_extra_isize_ea+0xe70/0x1bb0 fs/ext4/xattr.c:2774
__ext4_expand_extra_isize+0x304/0x3f0 fs/ext4/inode.c:5898
ext4_try_to_expand_extra_isize fs/ext4/inode.c:5941 [inline]
__ext4_mark_inode_dirty+0x591/0x810 fs/ext4/inode.c:6018
ext4_setattr+0x1400/0x19c0 fs/ext4/inode.c:5562
notify_change+0xbb6/0xe60 fs/attr.c:435
do_truncate+0x1de/0x2c0 fs/open.c:64
handle_truncate fs/namei.c:2970 [inline]
do_open fs/namei.c:3311 [inline]
path_openat+0x29f3/0x3290 fs/namei.c:3425
do_filp_open+0x20b/0x450 fs/namei.c:3452
do_sys_openat2+0x124/0x460 fs/open.c:1207
do_sys_open fs/open.c:1223 [inline]
__do_sys_open fs/open.c:1231 [inline]
__se_sys_open fs/open.c:1227 [inline]
__x64_sys_open+0x221/0x270 fs/open.c:1227
do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7f0cde4ea229
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd81d1c978 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0030656c69662f30 RCX: 00007f0cde4ea229
RDX: 0000000000000089 RSI: 00000000000a0a00 RDI: 00000000200001c0
RBP: 2f30656c69662f2e R08: 0000000000208000 R09: 0000000000208000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd81d1c9c0
R13: 00007ffd81d1ca00 R14: 0000000000080000 R15: 0000000000000003
EXT4-fs error (device loop0): ext4_expand_extra_isize_ea:2730: inode #13: comm syz-executor543: corrupted in-inode xattr

Signed-off-by: Wojciech Gładysz <wojciech.gladysz@infogain.com>
Link: https://patch.msgid.link/20240801143827.19135-1-wojciech.gladysz@infogain.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# fac59652 10-Oct-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.56' into for/openbmc/dev-6.6

This is the 6.6.56 stable release


# 89bbc55d 23-Sep-2024 Luis Henriques (SUSE) <luis.henriques@linux.dev>

ext4: mark fc as ineligible using an handle in ext4_xattr_set()

commit 04e6ce8f06d161399e5afde3df5dcfa9455b4952 upstream.

Calling ext4_fc_mark_ineligible() with a NULL handle is racy and may result

ext4: mark fc as ineligible using an handle in ext4_xattr_set()

commit 04e6ce8f06d161399e5afde3df5dcfa9455b4952 upstream.

Calling ext4_fc_mark_ineligible() with a NULL handle is racy and may result
in a fast-commit being done before the filesystem is effectively marked as
ineligible. This patch moves the call to this function so that an handle
can be used. If a transaction fails to start, then there's not point in
trying to mark the filesystem as ineligible, and an error will eventually be
returned to user-space.

Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20240923104909.18342-3-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 1760371b 19-Aug-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.47' into for/openbmc/dev-6.6

This is the 6.6.47 stable release


# 737fb785 21-Mar-2024 Jan Kara <jack@suse.cz>

ext4: do not create EA inode under buffer lock

[ Upstream commit 0a46ef234756dca04623b7591e8ebb3440622f0b ]

ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
on the external xa

ext4: do not create EA inode under buffer lock

[ Upstream commit 0a46ef234756dca04623b7591e8ebb3440622f0b ]

ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
on the external xattr block. This is problematic as it nests all the
allocation locking (which acquires locks on other buffers) under the
buffer lock. This can even deadlock when the filesystem is corrupted and
e.g. quota file is setup to contain xattr block as data block. Move the
allocation of EA inode out of ext4_xattr_set_entry() into the callers.

Reported-by: syzbot+a43d4f48b8397d0e41a9@syzkaller.appspotmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240321162657.27420-2-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# f2a77188 09-Feb-2024 Jan Kara <jack@suse.cz>

ext4: fold quota accounting into ext4_xattr_inode_lookup_create()

[ Upstream commit 8208c41c43ad5e9b63dce6c45a73e326109ca658 ]

When allocating EA inode, quota accounting is done just before
ext4_xa

ext4: fold quota accounting into ext4_xattr_inode_lookup_create()

[ Upstream commit 8208c41c43ad5e9b63dce6c45a73e326109ca658 ]

When allocating EA inode, quota accounting is done just before
ext4_xattr_inode_lookup_create(). Logically these two operations belong
together so just fold quota accounting into
ext4_xattr_inode_lookup_create(). We also make
ext4_xattr_inode_lookup_create() return the looked up / created inode to
convert the function to a more standard calling convention.

Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240209112107.10585-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Stable-dep-of: 0a46ef234756 ("ext4: do not create EA inode under buffer lock")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# 7e24a55b 04-Aug-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.44' into for/openbmc/dev-6.6

This is the 6.6.44 stable release


# 1e81d6c3 13-Jun-2024 Jan Kara <jack@suse.cz>

ext4: avoid writing unitialized memory to disk in EA inodes

[ Upstream commit 65121eff3e4c8c90f8126debf3c369228691c591 ]

If the extended attribute size is not a multiple of block size, the last
blo

ext4: avoid writing unitialized memory to disk in EA inodes

[ Upstream commit 65121eff3e4c8c90f8126debf3c369228691c591 ]

If the extended attribute size is not a multiple of block size, the last
block in the EA inode will have uninitialized tail which will get
written to disk. We will never expose the data to userspace but still
this is not a good practice so just zero out the tail of the block as it
isn't going to cause a noticeable performance overhead.

Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Reported-by: syzbot+9c1fe13fcb51574b249b@syzkaller.appspotmail.com
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20240613150234.25176-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# ba292915 16-Jun-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.34' into dev-6.6

This is the 6.6.34 stable release


# a95df6f0 04-May-2024 Baokun Li <libaokun1@huawei.com>

ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()

commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.

Syzbot reports a warning as follows:

===========================

ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()

commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.

Syzbot reports a warning as follows:

============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
<TASK>
ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
generic_shutdown_super+0x136/0x2d0 fs/super.c:641
kill_block_super+0x44/0x90 fs/super.c:1675
ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================

This is because when finding an entry in ext4_xattr_block_cache_find(), if
ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
in the __entry_find(), won't be put away, and eventually trigger the above
issue in mb_cache_destroy() due to reference count leakage.

So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

Reported-by: syzbot+dd43bd0f7474512edc47@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dd43bd0f7474512edc47
Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases")
Cc: stable@kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240504075526.2254349-2-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v6.5.5, v6.5.4, v6.5.3
# c900529f 12-Sep-2023 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-fixes into drm-misc-fixes

Forwarding to v6.6-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


Revision tags: v6.5.2, v6.1.51, v6.5.1
# 3ef96fcf 31-Aug-2023 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'ext4_for_linus-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

Pull ext4 updates from Ted Ts'o:
"Many ext4 and jbd2 cleanups and bug fixes:

- Cleanups in the ext

Merge tag 'ext4_for_linus-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

Pull ext4 updates from Ted Ts'o:
"Many ext4 and jbd2 cleanups and bug fixes:

- Cleanups in the ext4 remount code when going to and from read-only

- Cleanups in ext4's multiblock allocator

- Cleanups in the jbd2 setup/mounting code paths

- Performance improvements when appending to a delayed allocation file

- Miscellaneous syzbot and other bug fixes"

* tag 'ext4_for_linus-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (60 commits)
ext4: fix slab-use-after-free in ext4_es_insert_extent()
libfs: remove redundant checks of s_encoding
ext4: remove redundant checks of s_encoding
ext4: reject casefold inode flag without casefold feature
ext4: use LIST_HEAD() to initialize the list_head in mballoc.c
ext4: do not mark inode dirty every time when appending using delalloc
ext4: rename s_error_work to s_sb_upd_work
ext4: add periodic superblock update check
ext4: drop dio overwrite only flag and associated warning
ext4: add correct group descriptors and reserved GDT blocks to system zone
ext4: remove unused function declaration
ext4: mballoc: avoid garbage value from err
ext4: use sbi instead of EXT4_SB(sb) in ext4_mb_new_blocks_simple()
ext4: change the type of blocksize in ext4_mb_init_cache()
ext4: fix unttached inode after power cut with orphan file feature enabled
jbd2: correct the end of the journal recovery scan range
ext4: ext4_get_{dev}_journal return proper error value
ext4: cleanup ext4_get_dev_journal() and ext4_get_journal()
jbd2: jbd2_journal_init_{dev,inode} return proper error return value
jbd2: drop useless error tag in jbd2_journal_wipe()
...

show more ...


# 1ac731c5 30-Aug-2023 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 6.6 merge window.


Revision tags: v6.1.50
# 615e9583 28-Aug-2023 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'v6.6-vfs.ctime' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull vfs timestamp updates from Christian Brauner:
"This adds VFS support for multi-grain timestamps and converts

Merge tag 'v6.6-vfs.ctime' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull vfs timestamp updates from Christian Brauner:
"This adds VFS support for multi-grain timestamps and converts tmpfs,
xfs, ext4, and btrfs to use them. This carries acks from all relevant
filesystems.

The VFS always uses coarse-grained timestamps when updating the ctime
and mtime after a change. This has the benefit of allowing filesystems
to optimize away a lot of metadata updates, down to around 1 per
jiffy, even when a file is under heavy writes.

Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide to invalidate the cache.

Even with NFSv4, a lot of exported filesystems don't properly support
a change attribute and are subject to the same problems with timestamp
granularity. Other applications have similar issues with timestamps
(e.g., backup applications).

If we were to always use fine-grained timestamps, that would improve
the situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.

This introduces fine-grained timestamps that are used when they are
actively queried.

This uses the 31st bit of the ctime tv_nsec field to indicate that
something has queried the inode for the mtime or ctime. When this flag
is set, on the next mtime or ctime update, the kernel will fetch a
fine-grained timestamp instead of the usual coarse-grained one.

As POSIX generally mandates that when the mtime changes, the ctime
must also change the kernel always stores normalized ctime values, so
only the first 30 bits of the tv_nsec field are ever used.

Filesytems can opt into this behavior by setting the FS_MGTIME flag in
the fstype. Filesystems that don't set this flag will continue to use
coarse-grained timestamps.

Various preparatory changes, fixes and cleanups are included:

- Fixup all relevant places where POSIX requires updating ctime
together with mtime. This is a wide-range of places and all
maintainers provided necessary Acks.

- Add new accessors for inode->i_ctime directly and change all
callers to rely on them. Plain accesses to inode->i_ctime are now
gone and it is accordingly rename to inode->__i_ctime and commented
as requiring accessors.

- Extend generic_fillattr() to pass in a request mask mirroring in a
sense the statx() uapi. This allows callers to pass in a request
mask to only get a subset of attributes filled in.

- Rework timestamp updates so it's possible to drop the @now
parameter the update_time() inode operation and associated helpers.

- Add inode_update_timestamps() and convert all filesystems to it
removing a bunch of open-coding"

* tag 'v6.6-vfs.ctime' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (107 commits)
btrfs: convert to multigrain timestamps
ext4: switch to multigrain timestamps
xfs: switch to multigrain timestamps
tmpfs: add support for multigrain timestamps
fs: add infrastructure for multigrain timestamps
fs: drop the timespec64 argument from update_time
xfs: have xfs_vn_update_time gets its own timestamp
fat: make fat_update_time get its own timestamp
fat: remove i_version handling from fat_update_time
ubifs: have ubifs_update_time use inode_update_timestamps
btrfs: have it use inode_update_timestamps
fs: drop the timespec64 arg from generic_update_time
fs: pass the request_mask to generic_fillattr
fs: remove silly warning from current_time
gfs2: fix timestamp handling on quota inodes
fs: rename i_ctime field to __i_ctime
selinux: convert to ctime accessor functions
security: convert to ctime accessor functions
apparmor: convert to ctime accessor functions
sunrpc: convert to ctime accessor functions
...

show more ...


Revision tags: v6.5, v6.1.49, v6.1.48
# fdebffeb 23-Aug-2023 Dave Airlie <airlied@redhat.com>

BackMerge tag 'v6.5-rc7' into drm-next

Linux 6.5-rc7

This is needed for the CI stuff and the msm pull has fixes in it.

Signed-off-by: Dave Airlie <airlied@redhat.com>


# a3dd14c0 21-Aug-2023 Georgi Djakov <djakov@kernel.org>

Merge tag 'v6.5-rc6' into icc-next

The fixes that got merged into v6.5-rc6 are needed here.

Signed-off-by: Georgi Djakov <djakov@kernel.org>


Revision tags: v6.1.46, v6.1.45, v6.1.44
# 2612e3bb 07-Aug-2023 Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo V

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...


# 9f771739 07-Aug-2023 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/1

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/121735/

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

show more ...


# bf184299 04-Aug-2023 Arnaldo Carvalho de Melo <acme@redhat.com>

Merge remote-tracking branch 'torvalds/master' into perf-tools-next

To pick up the fixes that were just merged from perf-tools/perf-tools
for v6.5.

Signed-off-by: Arnaldo Carvalho de Melo <acme@red

Merge remote-tracking branch 'torvalds/master' into perf-tools-next

To pick up the fixes that were just merged from perf-tools/perf-tools
for v6.5.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

show more ...


Revision tags: v6.1.43
# 1346e933 31-Jul-2023 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 6.5-rc4 into char-misc-next

We need the char-misc fixes in here as well for testing.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35
# eb8ab444 16-Jun-2023 Jan Kara <jack@suse.cz>

ext4: make ext4_forced_shutdown() take struct super_block

Currently ext4_forced_shutdown() takes struct ext4_sb_info but most
callers need to get it from struct super_block anyway. So just pass in
s

ext4: make ext4_forced_shutdown() take struct super_block

Currently ext4_forced_shutdown() takes struct ext4_sb_info but most
callers need to get it from struct super_block anyway. So just pass in
struct super_block to save all callers from some boilerplate code. No
functional changes.

Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230616165109.21695-3-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>

show more ...


# 014acf26 27-Jul-2023 Jakub Kicinski <kuba@kernel.org>

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Cross-merge networking fixes after downstream PR.

No conflicts or adjacent changes.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>


12345678910>>...67