* [PATCH 11/32] gfs2: Don't zero i_private_data
From: Jan Kara @ 2026-03-03 10:34 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara, Andreas Gruenbacher, gfs2
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
The zeroing is the only use within gfs2 so it is pointless.
CC: Andreas Gruenbacher <agruenba@redhat.com>
CC: gfs2@lists.linux.dev
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/gfs2/glock.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 2acbabccc8ad..b8a144d3a73b 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1149,7 +1149,6 @@ int gfs2_glock_get(struct gfs2_sbd *sdp, u64 number,
mapping->flags = 0;
gfp_mask = mapping_gfp_mask(sdp->sd_inode->i_mapping);
mapping_set_gfp_mask(mapping, gfp_mask);
- mapping->i_private_data = NULL;
mapping->writeback_index = 0;
}
--
2.51.0
^ permalink raw reply related
* [PATCH 21/32] bdev: Drop pointless invalidate_mapping_buffers() call
From: Jan Kara @ 2026-03-03 10:34 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara, Jens Axboe, linux-block
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
Nobody is calling mark_buffer_dirty_inode() with internal bdev inode and
it doesn't make sense for internal bdev inode to have any metadata
buffer heads. Just drop the pointless invalidate_mapping_buffers() call.
CC: Jens Axboe <axboe@kernel.dk>
CC: linux-block@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
---
block/bdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..ad1660b6b324 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -420,7 +420,6 @@ static void init_once(void *data)
static void bdev_evict_inode(struct inode *inode)
{
truncate_inode_pages_final(&inode->i_data);
- invalidate_inode_buffers(inode); /* is it needed here? */
clear_inode(inode);
}
--
2.51.0
^ permalink raw reply related
* [PATCH 15/32] fs: Drop osync_buffers_list()
From: Jan Kara @ 2026-03-03 10:34 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
The function only waits for already locked buffers in the list of
metadata bhs. fsync_buffers_list() has just waited for all outstanding
IO on buffers so this isn't adding anything useful. Comment in front of
fsync_buffers_list() mentions concerns about buffers being moved out
from tmp list back to mappings i_private_list but these days
mark_buffer_dirty_inode() doesn't touch inodes with b_assoc_map set so
that cannot happen. Just delete the stale code.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/buffer.c | 43 ++-----------------------------------------
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index c85ccfb1a4ec..1c0e7c81a38b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -526,41 +526,6 @@ int inode_has_buffers(struct inode *inode)
}
EXPORT_SYMBOL_GPL(inode_has_buffers);
-/*
- * osync is designed to support O_SYNC io. It waits synchronously for
- * all already-submitted IO to complete, but does not queue any new
- * writes to the disk.
- *
- * To do O_SYNC writes, just queue the buffer writes with write_dirty_buffer
- * as you dirty the buffers, and then use osync_inode_buffers to wait for
- * completion. Any other dirty buffers which are not yet queued for
- * write will not be flushed to disk by the osync.
- */
-static int osync_buffers_list(spinlock_t *lock, struct list_head *list)
-{
- struct buffer_head *bh;
- struct list_head *p;
- int err = 0;
-
- spin_lock(lock);
-repeat:
- list_for_each_prev(p, list) {
- bh = BH_ENTRY(p);
- if (buffer_locked(bh)) {
- get_bh(bh);
- spin_unlock(lock);
- wait_on_buffer(bh);
- if (!buffer_uptodate(bh))
- err = -EIO;
- brelse(bh);
- spin_lock(lock);
- goto repeat;
- }
- }
- spin_unlock(lock);
- return err;
-}
-
/**
* sync_mapping_buffers - write out & wait upon a mapping's "associated" buffers
* @mapping: the mapping which wants those buffers written
@@ -777,7 +742,7 @@ static int fsync_buffers_list(spinlock_t *lock, struct list_head *list)
{
struct buffer_head *bh;
struct address_space *mapping;
- int err = 0, err2;
+ int err = 0;
struct blk_plug plug;
LIST_HEAD(tmp);
@@ -844,11 +809,7 @@ static int fsync_buffers_list(spinlock_t *lock, struct list_head *list)
}
spin_unlock(lock);
- err2 = osync_buffers_list(lock, list);
- if (err)
- return err;
- else
- return err2;
+ return err;
}
/*
--
2.51.0
^ permalink raw reply related
* [PATCH 09/32] fs: Ignore inode metadata buffers in inode_lru_isolate()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only a few filesystems that use generic tracking of inode
metadata buffer heads. As such it is mostly pointless to verify such
attached buffer heads during inode reclaim. Drop the handling from
inode_lru_isolate().
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/buffer.c | 29 -----------------------------
fs/inode.c | 21 +++++++++------------
include/linux/buffer_head.h | 3 ---
3 files changed, 9 insertions(+), 44 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 1bc0f22f3cc2..bd48644e1bf8 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -878,35 +878,6 @@ void invalidate_inode_buffers(struct inode *inode)
}
EXPORT_SYMBOL(invalidate_inode_buffers);
-/*
- * Remove any clean buffers from the inode's buffer list. This is called
- * when we're trying to free the inode itself. Those buffers can pin it.
- *
- * Returns true if all buffers were removed.
- */
-int remove_inode_buffers(struct inode *inode)
-{
- int ret = 1;
-
- if (inode_has_buffers(inode)) {
- struct address_space *mapping = &inode->i_data;
- struct list_head *list = &mapping->i_private_list;
- struct address_space *buffer_mapping = mapping->i_private_data;
-
- spin_lock(&buffer_mapping->i_private_lock);
- while (!list_empty(list)) {
- struct buffer_head *bh = BH_ENTRY(list->next);
- if (buffer_dirty(bh)) {
- ret = 0;
- break;
- }
- __remove_assoc_queue(bh);
- }
- spin_unlock(&buffer_mapping->i_private_lock);
- }
- return ret;
-}
-
/*
* Create the appropriate buffers when given a folio for data area and
* the size of each buffer.. Use the bh->b_this_page linked list to
diff --git a/fs/inode.c b/fs/inode.c
index cc12b68e021b..4f98a5f04bbd 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -17,7 +17,6 @@
#include <linux/fsverity.h>
#include <linux/mount.h>
#include <linux/posix_acl.h>
-#include <linux/buffer_head.h> /* for inode_has_buffers */
#include <linux/ratelimit.h>
#include <linux/list_lru.h>
#include <linux/iversion.h>
@@ -367,7 +366,6 @@ struct inode *alloc_inode(struct super_block *sb)
void __destroy_inode(struct inode *inode)
{
- BUG_ON(inode_has_buffers(inode));
inode_detach_wb(inode);
security_inode_free(inode);
fsnotify_inode_delete(inode);
@@ -994,19 +992,18 @@ static enum lru_status inode_lru_isolate(struct list_head *item,
* page cache in order to free up struct inodes: lowmem might
* be under pressure before the cache inside the highmem zone.
*/
- if (inode_has_buffers(inode) || !mapping_empty(&inode->i_data)) {
+ if (!mapping_empty(&inode->i_data)) {
+ unsigned long reap;
+
inode_pin_lru_isolating(inode);
spin_unlock(&inode->i_lock);
spin_unlock(&lru->lock);
- if (remove_inode_buffers(inode)) {
- unsigned long reap;
- reap = invalidate_mapping_pages(&inode->i_data, 0, -1);
- if (current_is_kswapd())
- __count_vm_events(KSWAPD_INODESTEAL, reap);
- else
- __count_vm_events(PGINODESTEAL, reap);
- mm_account_reclaimed_pages(reap);
- }
+ reap = invalidate_mapping_pages(&inode->i_data, 0, -1);
+ if (current_is_kswapd())
+ __count_vm_events(KSWAPD_INODESTEAL, reap);
+ else
+ __count_vm_events(PGINODESTEAL, reap);
+ mm_account_reclaimed_pages(reap);
inode_unpin_lru_isolating(inode);
return LRU_RETRY;
}
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index b16b88bfbc3e..631bf971efc0 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -517,7 +517,6 @@ void buffer_init(void);
bool try_to_free_buffers(struct folio *folio);
int inode_has_buffers(struct inode *inode);
void invalidate_inode_buffers(struct inode *inode);
-int remove_inode_buffers(struct inode *inode);
int sync_mapping_buffers(struct address_space *mapping);
void invalidate_bh_lrus(void);
void invalidate_bh_lrus_cpu(void);
@@ -528,9 +527,7 @@ extern int buffer_heads_over_limit;
static inline void buffer_init(void) {}
static inline bool try_to_free_buffers(struct folio *folio) { return true; }
-static inline int inode_has_buffers(struct inode *inode) { return 0; }
static inline void invalidate_inode_buffers(struct inode *inode) {}
-static inline int remove_inode_buffers(struct inode *inode) { return 1; }
static inline int sync_mapping_buffers(struct address_space *mapping) { return 0; }
static inline void invalidate_bh_lrus(void) {}
static inline void invalidate_bh_lrus_cpu(void) {}
--
2.51.0
^ permalink raw reply related
* [PATCH 12/32] hugetlbfs: Stop using i_private_data
From: Jan Kara @ 2026-03-03 10:34 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
Instead of using i_private_data for resv_map pointer add the pointer
into hugetlbfs private part of the inode.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/hugetlbfs/inode.c | 10 ++--------
include/linux/hugetlb.h | 1 +
mm/hugetlb.c | 10 +---------
3 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 3f70c47981de..0496f2e6d177 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -622,13 +622,7 @@ static void hugetlbfs_evict_inode(struct inode *inode)
trace_hugetlbfs_evict_inode(inode);
remove_inode_hugepages(inode, 0, LLONG_MAX);
- /*
- * Get the resv_map from the address space embedded in the inode.
- * This is the address space which points to any resv_map allocated
- * at inode creation time. If this is a device special inode,
- * i_mapping may not point to the original address space.
- */
- resv_map = (struct resv_map *)(&inode->i_data)->i_private_data;
+ resv_map = HUGETLBFS_I(inode)->resv_map;
/* Only regular and link inodes have associated reserve maps */
if (resv_map)
resv_map_release(&resv_map->refs);
@@ -950,7 +944,7 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
&hugetlbfs_i_mmap_rwsem_key);
inode->i_mapping->a_ops = &hugetlbfs_aops;
simple_inode_init_ts(inode);
- inode->i_mapping->i_private_data = resv_map;
+ info->resv_map = resv_map;
info->seals = F_SEAL_SEAL;
switch (mode & S_IFMT) {
default:
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 65910437be1c..fc5462fe943f 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -518,6 +518,7 @@ static inline struct hugetlbfs_sb_info *HUGETLBFS_SB(struct super_block *sb)
struct hugetlbfs_inode_info {
struct inode vfs_inode;
+ struct resv_map *resv_map;
unsigned int seals;
};
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 0beb6e22bc26..7ab5c724a711 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1157,15 +1157,7 @@ void resv_map_release(struct kref *ref)
static inline struct resv_map *inode_resv_map(struct inode *inode)
{
- /*
- * At inode evict time, i_mapping may not point to the original
- * address space within the inode. This original address space
- * contains the pointer to the resv_map. So, always use the
- * address space embedded within the inode.
- * The VERY common case is inode->mapping == &inode->i_data but,
- * this may not be true for device special inodes.
- */
- return (struct resv_map *)(&inode->i_data)->i_private_data;
+ return HUGETLBFS_I(inode)->resv_map;
}
static struct resv_map *vma_resv_map(struct vm_area_struct *vma)
--
2.51.0
^ permalink raw reply related
* [PATCH 14/32] fs: Remove i_private_data
From: Jan Kara @ 2026-03-03 10:34 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
Nobody is using it anymore.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/inode.c | 1 -
include/linux/fs.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 4f98a5f04bbd..d5774e627a9c 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -283,7 +283,6 @@ int inode_init_always_gfp(struct super_block *sb, struct inode *inode, gfp_t gfp
atomic_set(&mapping->nr_thps, 0);
#endif
mapping_set_gfp_mask(mapping, GFP_HIGHUSER_MOVABLE);
- mapping->i_private_data = NULL;
mapping->writeback_index = 0;
init_rwsem(&mapping->invalidate_lock);
lockdep_set_class_and_name(&mapping->invalidate_lock,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8b3dd145b25e..10b96eb5391d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -465,7 +465,6 @@ extern const struct address_space_operations empty_aops;
* @wb_err: The most recent error which has occurred.
* @i_private_lock: For use by the owner of the address_space.
* @i_private_list: For use by the owner of the address_space.
- * @i_private_data: For use by the owner of the address_space.
*/
struct address_space {
struct inode *host;
@@ -486,7 +485,6 @@ struct address_space {
spinlock_t i_private_lock;
struct list_head i_private_list;
struct rw_semaphore i_mmap_rwsem;
- void * i_private_data;
} __attribute__((aligned(sizeof(long)))) __randomize_layout;
/*
* On most architectures that alignment is already the case; but
--
2.51.0
^ permalink raw reply related
* [PATCH 10/32] fs: Stop using i_private_data for metadata bh tracking
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
All filesystem using generic metadata bh tracking are using bdev mapping
as a backing for these bhs. Stop using i_private_data for it and get to
bdev mapping directly.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/buffer.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index bd48644e1bf8..c85ccfb1a4ec 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -574,9 +574,10 @@ static int osync_buffers_list(spinlock_t *lock, struct list_head *list)
*/
int sync_mapping_buffers(struct address_space *mapping)
{
- struct address_space *buffer_mapping = mapping->i_private_data;
+ struct address_space *buffer_mapping =
+ mapping->host->i_sb->s_bdev->bd_mapping;
- if (buffer_mapping == NULL || list_empty(&mapping->i_private_list))
+ if (list_empty(&mapping->i_private_list))
return 0;
return fsync_buffers_list(&buffer_mapping->i_private_lock,
@@ -679,11 +680,6 @@ void mark_buffer_dirty_inode(struct buffer_head *bh, struct inode *inode)
struct address_space *buffer_mapping = bh->b_folio->mapping;
mark_buffer_dirty(bh);
- if (!mapping->i_private_data) {
- mapping->i_private_data = buffer_mapping;
- } else {
- BUG_ON(mapping->i_private_data != buffer_mapping);
- }
if (!bh->b_assoc_map) {
spin_lock(&buffer_mapping->i_private_lock);
list_move_tail(&bh->b_assoc_buffers,
@@ -868,7 +864,8 @@ void invalidate_inode_buffers(struct inode *inode)
if (inode_has_buffers(inode)) {
struct address_space *mapping = &inode->i_data;
struct list_head *list = &mapping->i_private_list;
- struct address_space *buffer_mapping = mapping->i_private_data;
+ struct address_space *buffer_mapping =
+ mapping->host->i_sb->s_bdev->bd_mapping;
spin_lock(&buffer_mapping->i_private_lock);
while (!list_empty(list))
--
2.51.0
^ permalink raw reply related
* [PATCH 05/32] ext4: Sync and invalidate metadata buffers from ext4_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/inode.c | 4 +++-
fs/ext4/super.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 396dc3a5d16b..c2692b9c7123 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -185,7 +185,9 @@ void ext4_evict_inode(struct inode *inode)
ext4_evict_ea_inode(inode);
if (inode->i_nlink) {
truncate_inode_pages_final(&inode->i_data);
-
+ /* Avoid mballoc special inode which has no proper iops */
+ if (!EXT4_SB(inode->i_sb)->s_journal)
+ sync_mapping_buffers(&inode->i_data);
goto no_delete;
}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 43f680c750ae..ea827b0ecc8d 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1524,7 +1524,8 @@ static void destroy_inodecache(void)
void ext4_clear_inode(struct inode *inode)
{
ext4_fc_del(inode);
- invalidate_inode_buffers(inode);
+ if (!EXT4_SB(inode->i_sb)->s_journal)
+ invalidate_inode_buffers(inode);
clear_inode(inode);
ext4_discard_preallocations(inode);
ext4_es_remove_extent(inode, 0, EXT_MAX_BLOCKS);
--
2.51.0
^ permalink raw reply related
* [PATCH 08/32] affs: Sync and invalidate metadata buffers from affs_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/affs/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/affs/inode.c b/fs/affs/inode.c
index 0bfc7d151dcd..84afa862f220 100644
--- a/fs/affs/inode.c
+++ b/fs/affs/inode.c
@@ -267,6 +267,8 @@ affs_evict_inode(struct inode *inode)
if (!inode->i_nlink) {
inode->i_size = 0;
affs_truncate(inode);
+ } else {
+ sync_mapping_buffers(&inode->i_data);
}
invalidate_inode_buffers(inode);
--
2.51.0
^ permalink raw reply related
* [PATCH 07/32] bfs: Sync and invalidate metadata buffers from bfs_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/bfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
index 9da02f5cb6cd..e0e50a9dbe9c 100644
--- a/fs/bfs/inode.c
+++ b/fs/bfs/inode.c
@@ -187,6 +187,8 @@ static void bfs_evict_inode(struct inode *inode)
dprintf("ino=%08lx\n", ino);
truncate_inode_pages_final(&inode->i_data);
+ if (inode->i_nlink)
+ sync_mapping_buffers(&inode->i_data);
invalidate_inode_buffers(inode);
clear_inode(inode);
--
2.51.0
^ permalink raw reply related
* [PATCH 06/32] ext4: Use inode_has_buffers()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
Instead of checking i_private_list directly use appropriate wrapper
inode_has_buffers(). Also delete stale comment.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/buffer.c | 1 +
fs/ext4/inode.c | 5 +----
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 22b43642ba57..1bc0f22f3cc2 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -524,6 +524,7 @@ int inode_has_buffers(struct inode *inode)
{
return !list_empty(&inode->i_data.i_private_list);
}
+EXPORT_SYMBOL_GPL(inode_has_buffers);
/*
* osync is designed to support O_SYNC io. It waits synchronously for
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index c2692b9c7123..6f892abef003 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1422,9 +1422,6 @@ static int write_end_fn(handle_t *handle, struct inode *inode,
/*
* We need to pick up the new inode size which generic_commit_write gave us
* `iocb` can be NULL - eg, when called from page_symlink().
- *
- * ext4 never places buffers on inode->i_mapping->i_private_list. metadata
- * buffers are managed internally.
*/
static int ext4_write_end(const struct kiocb *iocb,
struct address_space *mapping,
@@ -3439,7 +3436,7 @@ static bool ext4_inode_datasync_dirty(struct inode *inode)
}
/* Any metadata buffers to write? */
- if (!list_empty(&inode->i_mapping->i_private_list))
+ if (inode_has_buffers(inode))
return true;
return inode_state_read_once(inode) & I_DIRTY_DATASYNC;
}
--
2.51.0
^ permalink raw reply related
* [PATCH 04/32] ext2: Sync and invalidate metadata buffers from ext2_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext2/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index dbfe9098a124..fb91c61aa6d6 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -94,8 +94,9 @@ void ext2_evict_inode(struct inode * inode)
if (inode->i_blocks)
ext2_truncate_blocks(inode, 0);
ext2_xattr_delete_inode(inode);
+ } else {
+ sync_mapping_buffers(&inode->i_data);
}
-
invalidate_inode_buffers(inode);
clear_inode(inode);
--
2.51.0
^ permalink raw reply related
* [PATCH 02/32] udf: Sync and invalidate metadata buffers from udf_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/udf/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 7fae8002344a..739b190ca4e9 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -154,6 +154,8 @@ void udf_evict_inode(struct inode *inode)
}
}
truncate_inode_pages_final(&inode->i_data);
+ if (!want_delete)
+ sync_mapping_buffers(&inode->i_data);
invalidate_inode_buffers(inode);
clear_inode(inode);
kfree(iinfo->i_data);
--
2.51.0
^ permalink raw reply related
* [PATCH 03/32] minix: Sync and invalidate metadata buffers from minix_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/minix/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 99541c6a5bbf..ab7c06efb139 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -48,6 +48,8 @@ static void minix_evict_inode(struct inode *inode)
if (!inode->i_nlink) {
inode->i_size = 0;
minix_truncate(inode);
+ } else {
+ sync_mapping_buffers(&inode->i_data);
}
invalidate_inode_buffers(inode);
clear_inode(inode);
--
2.51.0
^ permalink raw reply related
* [PATCH 0/32] fs: Move metadata bh tracking from address_space
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
Hello,
this patch series cleans up the mess that has accumulated over the years in
metadata buffer_head tracking for inodes, moves the tracking into dedicated
structure in filesystem-private part of the inode (so that we don't use
private_list, private_data, and private_lock in struct address_space), and also
moves couple other users of private_data and private_list so these are removed
from struct address_space saving 3 longs in struct inode for 99% of inodes. I
would like to get rid of private_lock in struct address_space as well however
the locking changes for buffer_heads are non-trivial there and the patch series
is long enough as is. So let's leave that for another time.
The patches have survived some testing with fstests and ltp however I didn't
test AFFS, HUGETLBFS, and KVM guest_memfd changes so a help with testing
those would be very welcome. Thanks.
block/bdev.c | 1
fs/affs/affs.h | 2
fs/affs/dir.c | 1
fs/affs/file.c | 1
fs/affs/inode.c | 2
fs/affs/super.c | 6
fs/affs/symlink.c | 1
fs/aio.c | 78 +++++++-
fs/bfs/bfs.h | 2
fs/bfs/dir.c | 1
fs/bfs/file.c | 4
fs/bfs/inode.c | 9 +
fs/buffer.c | 387 +++++++++++++++++---------------------------
fs/ext2/ext2.h | 2
fs/ext2/file.c | 1
fs/ext2/inode.c | 3
fs/ext2/namei.c | 2
fs/ext2/super.c | 6
fs/ext2/symlink.c | 2
fs/ext4/ext4.h | 4
fs/ext4/file.c | 1
fs/ext4/inode.c | 9 -
fs/ext4/namei.c | 2
fs/ext4/super.c | 9 -
fs/ext4/symlink.c | 3
fs/fat/fat.h | 2
fs/fat/file.c | 1
fs/fat/inode.c | 16 +
fs/fat/namei_msdos.c | 1
fs/fat/namei_vfat.c | 1
fs/gfs2/glock.c | 1
fs/hugetlbfs/inode.c | 10 -
fs/inode.c | 24 +-
fs/minix/file.c | 1
fs/minix/inode.c | 10 +
fs/minix/minix.h | 2
fs/minix/namei.c | 1
fs/ntfs3/file.c | 3
fs/ocfs2/dlmglue.c | 1
fs/ocfs2/namei.c | 3
fs/udf/file.c | 1
fs/udf/inode.c | 2
fs/udf/namei.c | 1
fs/udf/super.c | 6
fs/udf/symlink.c | 1
fs/udf/udf_i.h | 1
fs/udf/udfdecl.h | 1
include/linux/buffer_head.h | 6
include/linux/fs.h | 11 -
include/linux/hugetlb.h | 1
mm/hugetlb.c | 10 -
virt/kvm/guest_memfd.c | 12 -
52 files changed, 360 insertions(+), 309 deletions(-)
Honza
^ permalink raw reply
* [PATCH 01/32] fat: Sync and invalidate metadata buffers from fat_evict_inode()
From: Jan Kara @ 2026-03-03 10:33 UTC (permalink / raw)
To: linux-fsdevel
Cc: Christian Brauner, Al Viro, linux-ext4, Ted Tso,
Tigran A. Aivazian, David Sterba, OGAWA Hirofumi, Muchun Song,
Oscar Salvador, David Hildenbrand, linux-mm, linux-aio,
Benjamin LaHaise, Jan Kara
In-Reply-To: <20260303101717.27224-1-jack@suse.cz>
There are only very few filesystems using generic metadata buffer head
tracking and everybody is paying the overhead. When we remove this
tracking for inode reclaim code .evict will start to see inodes with
metadata buffers attached so write them out and prune them.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/fat/inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3cc5fb01afa1..ce88602b0d57 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -657,8 +657,10 @@ static void fat_evict_inode(struct inode *inode)
if (!inode->i_nlink) {
inode->i_size = 0;
fat_truncate_blocks(inode, 0);
- } else
+ } else {
+ sync_mapping_buffers(inode->i_mapping);
fat_free_eofblocks(inode);
+ }
invalidate_inode_buffers(inode);
clear_inode(inode);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 004/110] net: change sock.sk_ino and sock_i_ino() to u64
From: Marc Kleine-Budde @ 2026-03-03 10:03 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260302-iino-u64-v2-4-e5388800dae0@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On 02.03.2026 15:23:48, Jeff Layton wrote:
> inode->i_ino is being converted to a u64. sock.sk_ino (which caches the
> inode number) must also be widened to avoid truncation on 32-bit
> architectures where unsigned long is only 32 bits.
>
> Change sk_ino from unsigned long to u64, and update the return type
> of sock_i_ino() to match. Fix all format strings that print the
> result of sock_i_ino() (%lu -> %llu), and widen the intermediate
> variables and function parameters in the diag modules that were
> using int to hold the inode number.
>
> Note that the UAPI socket diag structures (inet_diag_msg.idiag_inode,
> unix_diag_msg.udiag_ino, etc.) are all __u32 and cannot be changed
> without breaking the ABI. The assignments to those fields will
> silently truncate, which is the existing behavior.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> net/can/bcm.c | 2 +-
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for net/can
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/4] jbd2: store jinode dirty range in PAGE_SIZE units
From: Jan Kara @ 2026-03-03 9:01 UTC (permalink / raw)
To: Li Chen
Cc: Theodore Ts'o, Jan Kara, Mark Fasheh, linux-ext4, ocfs2-devel,
Jan Kara, linux-kernel
In-Reply-To: <6oexp6kpanvquzjn3nnqqg6wyyhh6og7jjb7fitlj7vzlj5vzp@cobcxovcgzg5>
On Mon 02-03-26 19:27:13, Jan Kara wrote:
> On Tue 24-02-26 17:24:33, Li Chen wrote:
> > jbd2_inode fields are updated under journal->j_list_lock, but some paths
> > read them without holding the lock (e.g. fast commit helpers and ordered
> > truncate helpers).
> >
> > READ_ONCE() alone is not sufficient for the dirty range fields when they
> > are stored as loff_t because 32-bit platforms can observe torn loads.
> > Store the dirty range in PAGE_SIZE units as pgoff_t instead.
> >
> > Use READ_ONCE() on the read side and WRITE_ONCE() on the write side for the
> > dirty range and i_flags to match the existing lockless access pattern.
> >
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Reviewed-by: Jan Kara <jack@suse.cz>
> > Signed-off-by: Li Chen <me@linux.beauty>
> ...
> > @@ -2654,15 +2655,20 @@ static int jbd2_journal_file_inode(handle_t *handle, struct jbd2_inode *jinode,
> > jbd2_debug(4, "Adding inode %lu, tid:%d\n", jinode->i_vfs_inode->i_ino,
> > transaction->t_tid);
> >
> > + start_page = (pgoff_t)(start_byte >> PAGE_SHIFT);
> > + end_page = (pgoff_t)(end_byte >> PAGE_SHIFT);
>
> MAX_LFS_SIZE on 32-bit is ULONG_MAX << PAGE_SHIFT and that's maximum file
> size. So we could do here end_page = DIV_ROUND_UP(end_byte, PAGE_SIZE) and
> just use end_page as exclusive end of a range to flush and get rid of
> special JBD2_INODE_DIRTY_RANGE_NONE value.
>
> The problem with the scheme you use is that files of MAX_LFS_SIZE would be
> treated as having empty flush range...
Or perhaps even easier might be to set start_page to ULONG_MAX and end_page
to 0 and use start_page > end_page as an indication of empty range.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
From: yebin (H) @ 2026-03-03 7:55 UTC (permalink / raw)
To: Baokun Li, Ye Bin; +Cc: jack, tytso, adilger.kernel, linux-ext4
In-Reply-To: <80be4b7a-976f-44cc-a50d-66a0e9ed05a0@linux.alibaba.com>
On 2026/3/3 10:36, Baokun Li wrote:
>
> On 3/2/26 9:46 PM, Ye Bin wrote:
>> From: Ye Bin <yebin10@huawei.com>
>>
>> There's issue as follows:
>> ...
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117
>> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>>
>> EXT4-fs (mmcblk0p1): error count since last fsck: 1
>> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760
>> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760
>> ...
>>
>> According to the log analysis, blocks are always requested from the
>> corrupted block group. This may happen as follows:
>> ext4_mb_find_by_goal
>> ext4_mb_load_buddy
>> ext4_mb_load_buddy_gfp
>> ext4_mb_init_cache
>> ext4_read_block_bitmap_nowait
>> ext4_wait_block_bitmap
>> ext4_validate_block_bitmap
>> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))
>> return -EFSCORRUPTED; // There's no logs.
>> if (err)
>> return err; // Will return error
>> ext4_lock_group(ac->ac_sb, group);
>> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable
>> goto out;
>>
>> After commit 9008a58e5dce ("ext4: make the bitmap read routines return
>> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group
>> as corrupt on block bitmap error") is no real solution for allocating
>> blocks from corrupted block groups. This is because if
>> 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then
>> 'ext4_mb_load_buddy()' may return an error. This means that the block
>> allocation will fail.
>> Therefore, check block group if corrupted when ext4_mb_load_buddy()
>> returns error.
>
> Good catch!
>
> Agreed, we should try other groups upon failure unless it's a goal-only
> allocation.
>
> But note that e4b->bd_info might be uninitialized if ext4_mb_load_buddy()
> fails.
>
The situation you mentioned probably doesn't exist.
ext4_mb_find_by_goal
struct ext4_group_info *grp = ext4_get_group_info(ac->ac_sb, group);
if (!grp) // The possibility that e4b->bd_info is not initialized
has been avoided.
return -EFSCORRUPTED;
err = ext4_mb_load_buddy(ac->ac_sb, group, e4b);
ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_NOFS);
grp = ext4_get_group_info(sb, group);
if (!grp) // This condition probably will not be met.
return -EFSCORRUPTED;
e4b->bd_info = grp;
> I think we can optimize this in ext4_mb_regular_allocator(): we can record
> the error from ext4_mb_find_by_goal() but avoid an early exit.
>
> Specifically, after checking that EXT4_MB_HINT_GOAL_ONLY is not set,
> we can assign the error to ac->ac_first_err. This way, if subsequent
> allocation attempts still fail, we can preserve the original.
>
>
> Cheers,
> Baokun
>
>> Fixes: 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error")
>> Fixes: 9008a58e5dce ("ext4: make the bitmap read routines return real error codes")
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> ---
>> fs/ext4/mballoc.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> index e2341489f4d0..ffa6886de8a3 100644
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -2443,8 +2443,12 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac,
>> return 0;
>>
>> err = ext4_mb_load_buddy(ac->ac_sb, group, e4b);
>> - if (err)
>> + if (err) {
>> + if (EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info) &&
>> + !(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY))
>> + return 0;
>> return err;
>> + }
>>
>> ext4_lock_group(ac->ac_sb, group);
>> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
>
>
> .
>
^ permalink raw reply
* [syzbot ci] Re: ext4: avoid infinite loops caused by data conflicts
From: syzbot ci @ 2026-03-03 7:47 UTC (permalink / raw)
To: brauner, eadavis, jack, linux-ext4, linux-fsdevel, linux-kernel,
syzbot, syzbot, syzkaller-bugs, viro
Cc: syzbot, syzkaller-bugs
In-Reply-To: <tencent_13E236704A527419766767443D6736EE9609@qq.com>
syzbot ci has tested the following series
[v2] ext4: avoid infinite loops caused by data conflicts
https://lore.kernel.org/all/tencent_13E236704A527419766767443D6736EE9609@qq.com
* [PATCH v2] ext4: avoid infinite loops caused by data conflicts
and found the following issues:
* KASAN: slab-out-of-bounds Read in ext4_xattr_block_csum_set
* KASAN: slab-use-after-free Read in ext4_xattr_block_csum_set
* KASAN: slab-use-after-free Read in ext4_xattr_set_entry
* KASAN: use-after-free Read in ext4_xattr_block_csum_set
* KASAN: use-after-free Read in ext4_xattr_set_entry
Full report is available here:
https://ci.syzbot.org/series/ccbb03e4-9312-48f0-808d-923f86d83f2f
***
KASAN: slab-out-of-bounds Read in ext4_xattr_block_csum_set
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 11439c4635edd669ae435eec308f4ab8a0804808
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
syz repro: https://ci.syzbot.org/findings/ddaf8105-c8d7-4a57-87ef-ee750875c5c7/syz_repro
fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
==================================================================
BUG: KASAN: slab-out-of-bounds in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: slab-out-of-bounds in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: slab-out-of-bounds in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88816a0ea0b0 by task syz.0.17/6006
CPU: 1 UID: 0 PID: 6006 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
crc32c_base lib/crc/crc32-main.c:54 [inline]
crc32c_arch lib/crc/x86/crc32.h:44 [inline]
crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
ext4_chksum fs/ext4/ext4.h:2553 [inline]
ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
__ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
ext4_mkdir+0x3da/0xbf0 fs/ext4/namei.c:3005
vfs_mkdir+0x413/0x630 fs/namei.c:5233
filename_mkdirat+0x285/0x510 fs/namei.c:5266
__do_sys_mkdirat fs/namei.c:5287 [inline]
__se_sys_mkdirat+0x35/0x150 fs/namei.c:5284
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb60ad9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb60bd17028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007fb60b015fa0 RCX: 00007fb60ad9c799
RDX: 00000000000001c0 RSI: 0000200000000180 RDI: ffffffffffffff9c
RBP: 00007fb60ae32bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb60b016038 R14: 00007fb60b015fa0 R15: 00007fff4bbf7228
</TASK>
Allocated by task 1:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4515 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4851
__kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
__kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
create_files fs/sysfs/group.c:82 [inline]
internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
internal_create_groups fs/sysfs/group.c:229 [inline]
sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
device_add_groups drivers/base/core.c:2836 [inline]
device_add_attrs+0xdd/0x5b0 drivers/base/core.c:2900
device_add+0x496/0xb70 drivers/base/core.c:3643
__video_register_device+0x3e40/0x4d20 drivers/media/v4l2-core/v4l2-dev.c:1076
video_register_device include/media/v4l2-dev.h:390 [inline]
vivid_create_devnodes+0xc5e/0x2bf0 drivers/media/test-drivers/vivid/vivid-core.c:1471
vivid_create_instance drivers/media/test-drivers/vivid/vivid-core.c:2042 [inline]
vivid_probe+0x510d/0x72b0 drivers/media/test-drivers/vivid/vivid-core.c:2095
platform_probe+0xf9/0x190 drivers/base/platform.c:1446
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x267/0xaf0 drivers/base/dd.c:661
__driver_probe_device+0x18c/0x320 drivers/base/dd.c:803
driver_probe_device+0x4f/0x240 drivers/base/dd.c:833
__driver_attach+0x3e7/0x710 drivers/base/dd.c:1227
bus_for_each_dev+0x23b/0x2c0 drivers/base/bus.c:383
bus_add_driver+0x345/0x670 drivers/base/bus.c:715
driver_register+0x23a/0x320 drivers/base/driver.c:249
vivid_init+0x561/0x5f0 drivers/media/test-drivers/vivid/vivid-core.c:2294
do_one_initcall+0x250/0x8d0 init/main.c:1382
do_initcall_level+0x104/0x190 init/main.c:1444
do_initcalls+0x59/0xa0 init/main.c:1460
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1692
kernel_init+0x1d/0x1d0 init/main.c:1582
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff88816a0ea000
which belongs to the cache kernfs_node_cache of size 176
The buggy address is located 0 bytes to the right of
allocated 176-byte region [ffff88816a0ea000, ffff88816a0ea0b0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x16a0ea
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000000 ffff8881012d3dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000800110011 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 19200276917, free_ts 4632825873
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3269 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3458
new_slab mm/slub.c:3516 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7153
refill_sheaf mm/slub.c:2818 [inline]
__pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
alloc_from_pcs mm/slub.c:4695 [inline]
slab_alloc_node mm/slub.c:4829 [inline]
kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4851
__kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
kernfs_create_link+0xa7/0x200 fs/kernfs/symlink.c:39
sysfs_do_create_link_sd+0x83/0x110 fs/sysfs/symlink.c:44
device_create_sys_dev_entry+0x122/0x190 drivers/base/core.c:3515
device_add+0x733/0xb70 drivers/base/core.c:3659
cdev_device_add+0x1d6/0x390 fs/char_dev.c:553
media_devnode_register+0x287/0x420 drivers/media/mc/mc-devnode.c:247
__media_device_register+0x15c/0x3c0 drivers/media/mc/mc-device.c:753
page last free pid 10 tgid 10 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
vfree+0x25a/0x400 mm/vmalloc.c:3479
delayed_vfree_work+0x55/0x80 mm/vmalloc.c:3398
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff88816a0e9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88816a0ea000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88816a0ea080: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc 00 00
^
ffff88816a0ea100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88816a0ea180: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
==================================================================
***
KASAN: slab-use-after-free Read in ext4_xattr_block_csum_set
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 11439c4635edd669ae435eec308f4ab8a0804808
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro: https://ci.syzbot.org/findings/bee8f041-a020-4e43-a068-e014486583d9/c_repro
syz repro: https://ci.syzbot.org/findings/bee8f041-a020-4e43-a068-e014486583d9/syz_repro
ext4 filesystem being mounted at /0/file0 supports timestamps until 2038-01-19 (0x7fffffff)
fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
==================================================================
BUG: KASAN: slab-use-after-free in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: slab-use-after-free in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: slab-use-after-free in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88816c2f9000 by task syz.0.17/5966
CPU: 0 UID: 0 PID: 5966 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
crc32c_base lib/crc/crc32-main.c:54 [inline]
crc32c_arch lib/crc/x86/crc32.h:44 [inline]
crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
ext4_chksum fs/ext4/ext4.h:2553 [inline]
ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
__ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
ext4_mkdir+0x3da/0xbf0 fs/ext4/namei.c:3005
vfs_mkdir+0x413/0x630 fs/namei.c:5233
filename_mkdirat+0x285/0x510 fs/namei.c:5266
__do_sys_mkdir fs/namei.c:5293 [inline]
__se_sys_mkdir+0x34/0x150 fs/namei.c:5290
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb91ff9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe3b8b33f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00007fb920215fa0 RCX: 00007fb91ff9c799
RDX: 0000000000000000 RSI: 0000000000000142 RDI: 0000200000000300
RBP: 00007fb920032bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb920215fac R14: 00007fb920215fa0 R15: 00007fb920215fa0
</TASK>
Allocated by task 5807:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5358
kmalloc_noprof include/linux/slab.h:950 [inline]
slab_free_hook mm/slub.c:2644 [inline]
slab_free mm/slub.c:6143 [inline]
kmem_cache_free+0x15b/0x630 mm/slub.c:6273
anon_vma_free mm/rmap.c:137 [inline]
__put_anon_vma+0x12b/0x2d0 mm/rmap.c:2889
put_anon_vma mm/internal.h:215 [inline]
unlink_anon_vmas+0x58b/0x730 mm/rmap.c:529
free_pgtables+0x663/0xb70 mm/memory.c:414
exit_mmap+0x490/0xa10 mm/mmap.c:1314
__mmput+0x118/0x430 kernel/fork.c:1174
exec_mmap+0x3b4/0x440 fs/exec.c:893
begin_new_exec+0x134a/0x24a0 fs/exec.c:1148
load_elf_binary+0xa47/0x2980 fs/binfmt_elf.c:1011
search_binary_handler fs/exec.c:1664 [inline]
exec_binprm fs/exec.c:1696 [inline]
bprm_execve+0x93d/0x1460 fs/exec.c:1748
do_execveat_common+0x50d/0x690 fs/exec.c:1846
__do_sys_execve fs/exec.c:1930 [inline]
__se_sys_execve fs/exec.c:1924 [inline]
__x64_sys_execve+0x97/0xc0 fs/exec.c:1924
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5807:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2692 [inline]
slab_free mm/slub.c:6143 [inline]
kfree+0x1c1/0x630 mm/slub.c:6461
slab_free_after_rcu_debug+0x5e/0x220 mm/slub.c:6195
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
handle_softirqs+0x22a/0x870 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x5f/0x150 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
__call_rcu_common kernel/rcu/tree.c:3131 [inline]
call_rcu+0xee/0x890 kernel/rcu/tree.c:3251
slab_free_hook mm/slub.c:2656 [inline]
slab_free mm/slub.c:6143 [inline]
kmem_cache_free+0x439/0x630 mm/slub.c:6273
anon_vma_free mm/rmap.c:137 [inline]
__put_anon_vma+0x12b/0x2d0 mm/rmap.c:2889
put_anon_vma mm/internal.h:215 [inline]
unlink_anon_vmas+0x58b/0x730 mm/rmap.c:529
free_pgtables+0x663/0xb70 mm/memory.c:414
exit_mmap+0x490/0xa10 mm/mmap.c:1314
__mmput+0x118/0x430 kernel/fork.c:1174
exec_mmap+0x3b4/0x440 fs/exec.c:893
begin_new_exec+0x134a/0x24a0 fs/exec.c:1148
load_elf_binary+0xa47/0x2980 fs/binfmt_elf.c:1011
search_binary_handler fs/exec.c:1664 [inline]
exec_binprm fs/exec.c:1696 [inline]
bprm_execve+0x93d/0x1460 fs/exec.c:1748
do_execveat_common+0x50d/0x690 fs/exec.c:1846
__do_sys_execve fs/exec.c:1930 [inline]
__se_sys_execve fs/exec.c:1924 [inline]
__x64_sys_execve+0x97/0xc0 fs/exec.c:1924
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff88816c2f9000
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
freed 32-byte region [ffff88816c2f9000, ffff88816c2f9020)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x16c2f9
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000000 ffff888100041780 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800400040 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5807, tgid 5807 (sshd), ts 57508476883, free_ts 57508008939
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3269 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3458
new_slab mm/slub.c:3516 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7153
refill_sheaf mm/slub.c:2818 [inline]
__pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
alloc_from_pcs mm/slub.c:4695 [inline]
slab_alloc_node mm/slub.c:4829 [inline]
__do_kmalloc_node mm/slub.c:5237 [inline]
__kvmalloc_node_noprof+0x657/0x8a0 mm/slub.c:6730
proc_sys_call_handler+0x3d1/0x830 fs/proc/proc_sysctl.c:583
new_sync_read fs/read_write.c:493 [inline]
vfs_read+0x582/0xa70 fs/read_write.c:574
ksys_read+0x150/0x270 fs/read_write.c:717
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5807 tgid 5807 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
tlb_batch_list_free mm/mmu_gather.c:161 [inline]
tlb_finish_mmu+0x144/0x230 mm/mmu_gather.c:533
unmap_region+0x2a5/0x330 mm/vma.c:488
vms_clear_ptes mm/vma.c:1284 [inline]
vms_complete_munmap_vmas+0x493/0xc60 mm/vma.c:1326
do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1585
do_vmi_munmap+0x252/0x2d0 mm/vma.c:1633
__vm_munmap+0x22c/0x3d0 mm/vma.c:3254
__do_sys_munmap mm/mmap.c:1078 [inline]
__se_sys_munmap mm/mmap.c:1075 [inline]
__x64_sys_munmap+0x60/0x70 mm/mmap.c:1075
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88816c2f8f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88816c2f8f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88816c2f9000: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
^
ffff88816c2f9080: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff88816c2f9100: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================
***
KASAN: slab-use-after-free Read in ext4_xattr_set_entry
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 11439c4635edd669ae435eec308f4ab8a0804808
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
syz repro: https://ci.syzbot.org/findings/703aaa0c-3de2-4301-b1d3-6310fbf18b70/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
Read of size 260 at addr ffff88811a37e000 by task syz.2.19/5991
CPU: 0 UID: 0 PID: 5991 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
__asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
ext4_xattr_block_set+0x636/0x2b00 fs/ext4/xattr.c:1961
ext4_xattr_set_handle+0xdc2/0x14d0 fs/ext4/xattr.c:2432
ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2560
__vfs_removexattr+0x431/0x470 fs/xattr.c:518
__vfs_removexattr_locked+0xe2/0x280 fs/xattr.c:553
vfs_removexattr+0x7f/0x230 fs/xattr.c:575
ovl_do_removexattr fs/overlayfs/overlayfs.h:335 [inline]
ovl_removexattr fs/overlayfs/overlayfs.h:343 [inline]
ovl_make_workdir fs/overlayfs/super.c:760 [inline]
ovl_get_workdir fs/overlayfs/super.c:840 [inline]
ovl_fill_super_creds fs/overlayfs/super.c:1453 [inline]
ovl_fill_super+0x4c09/0x5e00 fs/overlayfs/super.c:1564
vfs_get_super fs/super.c:1327 [inline]
get_tree_nodev+0xbb/0x150 fs/super.c:1346
vfs_get_tree+0x92/0x2a0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
do_new_mount_fc fs/namespace.c:3763 [inline]
do_new_mount+0x341/0xd30 fs/namespace.c:3839
do_mount fs/namespace.c:4172 [inline]
__do_sys_mount fs/namespace.c:4361 [inline]
__se_sys_mount+0x31d/0x420 fs/namespace.c:4338
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7facfdf9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007facfd5fe028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007facfe215fa0 RCX: 00007facfdf9c799
RDX: 0000200000000440 RSI: 0000200000000100 RDI: 0000000000000000
RBP: 00007facfe032bd9 R08: 0000200000000280 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007facfe216038 R14: 00007facfe215fa0 R15: 00007ffdb6825fe8
</TASK>
Allocated by task 5825:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4515 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4851
__kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
__kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
create_files fs/sysfs/group.c:82 [inline]
internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
internal_create_groups fs/sysfs/group.c:229 [inline]
sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
device_add_groups drivers/base/core.c:2836 [inline]
device_add_attrs+0xdd/0x5b0 drivers/base/core.c:2900
device_add+0x496/0xb70 drivers/base/core.c:3643
netdev_register_kobject+0x178/0x310 net/core/net-sysfs.c:2358
register_netdevice+0x12c0/0x1cf0 net/core/dev.c:11422
__ip_tunnel_create+0x3e8/0x560 net/ipv4/ip_tunnel.c:268
ip_tunnel_init_net+0x2e7/0x840 net/ipv4/ip_tunnel.c:1147
ops_init+0x35c/0x5c0 net/core/net_namespace.c:137
setup_net+0x118/0x340 net/core/net_namespace.c:446
copy_net_ns+0x50e/0x730 net/core/net_namespace.c:581
create_new_namespaces+0x3e7/0x6a0 kernel/nsproxy.c:130
unshare_nsproxy_namespaces+0x11a/0x160 kernel/nsproxy.c:226
ksys_unshare+0x51d/0x930 kernel/fork.c:3174
__do_sys_unshare kernel/fork.c:3245 [inline]
__se_sys_unshare kernel/fork.c:3243 [inline]
__x64_sys_unshare+0x38/0x50 kernel/fork.c:3243
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 15:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2692 [inline]
slab_free mm/slub.c:6143 [inline]
kmem_cache_free+0x187/0x630 mm/slub.c:6273
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
handle_softirqs+0x22a/0x870 kernel/softirq.c:622
run_ksoftirqd+0x36/0x60 kernel/softirq.c:1063
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
__call_rcu_common kernel/rcu/tree.c:3131 [inline]
call_rcu+0xee/0x890 kernel/rcu/tree.c:3251
kernfs_put+0x18e/0x470 fs/kernfs/dir.c:591
kernfs_remove_by_name_ns+0xb7/0x130 fs/kernfs/dir.c:1723
kernfs_remove_by_name include/linux/kernfs.h:633 [inline]
remove_files fs/sysfs/group.c:28 [inline]
sysfs_remove_group+0xfc/0x2e0 fs/sysfs/group.c:328
sysfs_remove_groups+0x54/0xb0 fs/sysfs/group.c:352
device_remove_groups drivers/base/core.c:2843 [inline]
device_remove_attrs+0x229/0x280 drivers/base/core.c:2979
device_del+0x51f/0x8f0 drivers/base/core.c:3877
unregister_netdevice_many_notify+0x1e0e/0x2370 net/core/dev.c:12447
ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]
ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248
cleanup_net+0x56b/0x800 net/core/net_namespace.c:704
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff88811a37e000
which belongs to the cache kernfs_node_cache of size 176
The buggy address is located 0 bytes inside of
freed 176-byte region [ffff88811a37e000, ffff88811a37e0b0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88811a37ee10 pfn:0x11a37e
flags: 0x17ff00000000200(workingset|node=0|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 017ff00000000200 ffff8881012d3dc0 ffffea000468fed0 ffffea000468df10
raw: ffff88811a37ee10 000000080011000a 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5822, tgid 5822 (syz-executor), ts 67128981798, free_ts 62919905097
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3269 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3458
new_slab mm/slub.c:3516 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7153
refill_sheaf mm/slub.c:2818 [inline]
__pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
alloc_from_pcs mm/slub.c:4695 [inline]
slab_alloc_node mm/slub.c:4829 [inline]
kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4851
__kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
__kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
create_files fs/sysfs/group.c:82 [inline]
internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
internal_create_groups fs/sysfs/group.c:229 [inline]
sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
device_add_groups drivers/base/core.c:2836 [inline]
device_add_attrs+0x1bf/0x5b0 drivers/base/core.c:2911
device_add+0x496/0xb70 drivers/base/core.c:3643
netdev_register_kobject+0x178/0x310 net/core/net-sysfs.c:2358
page last free pid 5809 tgid 5809 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
vfree+0x25a/0x400 mm/vmalloc.c:3479
kcov_put kernel/kcov.c:442 [inline]
kcov_close+0x28/0x50 kernel/kcov.c:543
__fput+0x44f/0xa70 fs/file_table.c:469
fput_close_sync+0x11f/0x240 fs/file_table.c:574
__do_sys_close fs/open.c:1509 [inline]
__se_sys_close fs/open.c:1494 [inline]
__x64_sys_close+0x7e/0x110 fs/open.c:1494
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88811a37df00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88811a37df80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811a37e000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88811a37e080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fa fb
ffff88811a37e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
***
KASAN: use-after-free Read in ext4_xattr_block_csum_set
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 11439c4635edd669ae435eec308f4ab8a0804808
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro: https://ci.syzbot.org/findings/e7360798-7b84-42ba-9afb-319d10454142/c_repro
syz repro: https://ci.syzbot.org/findings/e7360798-7b84-42ba-9afb-319d10454142/syz_repro
fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
fscrypt: AES-256-XTS using implementation "xts(ecb(aes-lib))"
==================================================================
BUG: KASAN: use-after-free in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: use-after-free in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: use-after-free in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88811f068000 by task syz.0.17/5956
CPU: 0 UID: 0 PID: 5956 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
crc32c_base lib/crc/crc32-main.c:54 [inline]
crc32c_arch lib/crc/x86/crc32.h:44 [inline]
crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
ext4_chksum fs/ext4/ext4.h:2553 [inline]
ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
__ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
ext4_create+0x233/0x470 fs/ext4/namei.c:2820
lookup_open fs/namei.c:4483 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x1395/0x3860 fs/namei.c:4827
do_file_open+0x23e/0x4a0 fs/namei.c:4859
do_sys_openat2+0x113/0x200 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb6f179c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb6f26cf028 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007fb6f1a15fa0 RCX: 00007fb6f179c799
RDX: 0000000000101042 RSI: 00002000000002c0 RDI: ffffffffffffff9c
RBP: 00007fb6f1832bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb6f1a16038 R14: 00007fb6f1a15fa0 R15: 00007ffe4cb28f88
</TASK>
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xc1 pfn:0x11f068
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff00000000000 ffffea00047c0f08 ffffea00047c1648 0000000000000000
raw: 00000000000000c1 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), pid 5966, tgid 5966 (modprobe), ts 74332946165, free_ts 74344928310
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
folio_alloc_mpol_noprof mm/mempolicy.c:2503 [inline]
vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2538
folio_prealloc mm/memory.c:-1 [inline]
do_cow_fault mm/memory.c:5822 [inline]
do_fault mm/memory.c:5934 [inline]
do_pte_missing+0x4ea/0x3750 mm/memory.c:4477
handle_pte_fault mm/memory.c:6316 [inline]
__handle_mm_fault mm/memory.c:6454 [inline]
handle_mm_fault+0x1bec/0x3310 mm/memory.c:6623
do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 5966 tgid 5966 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
folios_put_refs+0x789/0x8d0 mm/swap.c:1002
free_pages_and_swap_cache+0x2e7/0x5b0 mm/swap_state.c:423
__tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
exit_mmap+0x498/0xa10 mm/mmap.c:1315
__mmput+0x118/0x430 kernel/fork.c:1174
exit_mm+0x168/0x220 kernel/exit.c:581
do_exit+0x62e/0x2320 kernel/exit.c:959
do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
__do_sys_exit_group kernel/exit.c:1123 [inline]
__se_sys_exit_group kernel/exit.c:1121 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
x64_sys_call+0x221a/0x2240 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88811f067f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88811f067f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811f068000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88811f068080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811f068100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
***
KASAN: use-after-free Read in ext4_xattr_set_entry
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 11439c4635edd669ae435eec308f4ab8a0804808
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro: https://ci.syzbot.org/findings/f2e1c927-88dd-48df-af44-6348bc760ced/c_repro
syz repro: https://ci.syzbot.org/findings/f2e1c927-88dd-48df-af44-6348bc760ced/syz_repro
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
ext4 filesystem being mounted at /0/file0 supports timestamps until 2038-01-19 (0x7fffffff)
==================================================================
BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
Read of size 260 at addr ffff88811cde4000 by task syz.0.17/5956
CPU: 0 UID: 0 PID: 5956 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
__asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
ext4_xattr_block_set+0x636/0x2b00 fs/ext4/xattr.c:1961
ext4_xattr_set_handle+0xdc2/0x14d0 fs/ext4/xattr.c:2432
ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2560
__vfs_removexattr+0x431/0x470 fs/xattr.c:518
__vfs_removexattr_locked+0xe2/0x280 fs/xattr.c:553
vfs_removexattr+0x7f/0x230 fs/xattr.c:575
ovl_do_removexattr fs/overlayfs/overlayfs.h:335 [inline]
ovl_removexattr fs/overlayfs/overlayfs.h:343 [inline]
ovl_make_workdir fs/overlayfs/super.c:760 [inline]
ovl_get_workdir fs/overlayfs/super.c:840 [inline]
ovl_fill_super_creds fs/overlayfs/super.c:1453 [inline]
ovl_fill_super+0x4c09/0x5e00 fs/overlayfs/super.c:1564
vfs_get_super fs/super.c:1327 [inline]
get_tree_nodev+0xbb/0x150 fs/super.c:1346
vfs_get_tree+0x92/0x2a0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
do_new_mount_fc fs/namespace.c:3763 [inline]
do_new_mount+0x341/0xd30 fs/namespace.c:3839
do_mount fs/namespace.c:4172 [inline]
__do_sys_mount fs/namespace.c:4361 [inline]
__se_sys_mount+0x31d/0x420 fs/namespace.c:4338
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f60b0d9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcaa4270a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f60b1015fa0 RCX: 00007f60b0d9c799
RDX: 0000200000000b80 RSI: 0000200000000000 RDI: 0000000000000000
RBP: 00007f60b0e32bd9 R08: 0000200000000100 R09: 0000000000000000
R10: 0000000000000804 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f60b1015fac R14: 00007f60b1015fa0 R15: 00007f60b1015fa0
</TASK>
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x39c pfn:0x11cde4
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff00000000000 ffffea0004737948 ffff888121040d70 0000000000000000
raw: 000000000000039c 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), pid 5919, tgid 5919 (syz-executor), ts 71335198059, free_ts 71626869117
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
folio_alloc_mpol_noprof mm/mempolicy.c:2503 [inline]
vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2538
folio_prealloc mm/memory.c:-1 [inline]
do_cow_fault mm/memory.c:5822 [inline]
do_fault mm/memory.c:5934 [inline]
do_pte_missing+0x4ea/0x3750 mm/memory.c:4477
handle_pte_fault mm/memory.c:6316 [inline]
__handle_mm_fault mm/memory.c:6454 [inline]
handle_mm_fault+0x1bec/0x3310 mm/memory.c:6623
do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 5920 tgid 5920 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
folios_put_refs+0x789/0x8d0 mm/swap.c:1002
free_pages_and_swap_cache+0x537/0x5b0 mm/swap_state.c:426
__tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
exit_mmap+0x498/0xa10 mm/mmap.c:1315
__mmput+0x118/0x430 kernel/fork.c:1174
exit_mm+0x168/0x220 kernel/exit.c:581
do_exit+0x62e/0x2320 kernel/exit.c:959
do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
get_signal+0x1284/0x1330 kernel/signal.c:3034
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88811cde3f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88811cde3f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811cde4000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88811cde4080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811cde4100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply
* Re: [PATCH] block: remove bdev_nonrot()
From: Hannes Reinecke @ 2026-03-03 7:05 UTC (permalink / raw)
To: Damien Le Moal, Jens Axboe, linux-block, Song Liu, Yu Kuai,
linux-raid, Martin K . Petersen, linux-scsi, target-devel,
David Sterba, linux-btrfs, Theodore Ts'o, linux-ext4,
Andreas Dilger, Andrew Morton, Chris Li, Kairui Song, linux-mm
In-Reply-To: <20260226075448.2229655-1-dlemoal@kernel.org>
On 2/26/26 08:54, Damien Le Moal wrote:
> bdev_nonrot() is simply the negative return value of bdev_rot().
> So replace all call sites of bdev_nonrot() with calls to bdev_rot()
> and remove bdev_nonrot().
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> drivers/md/raid1.c | 2 +-
> drivers/md/raid10.c | 2 +-
> drivers/md/raid5.c | 2 +-
> drivers/target/target_core_file.c | 2 +-
> drivers/target/target_core_iblock.c | 2 +-
> fs/btrfs/volumes.c | 4 ++--
> fs/ext4/mballoc-test.c | 2 +-
> fs/ext4/mballoc.c | 2 +-
> include/linux/blkdev.h | 5 -----
> mm/swapfile.c | 2 +-
> 10 files changed, 10 insertions(+), 15 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH v3 2/2] jbd2: gracefully abort on transaction state corruptions
From: kernel test robot @ 2026-03-03 6:16 UTC (permalink / raw)
To: Milos Nikic, jack
Cc: llvm, oe-kbuild-all, tytso, linux-ext4, linux-kernel, Milos Nikic
In-Reply-To: <20260303005502.337108-3-nikic.milos@gmail.com>
Hi Milos,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on tytso-ext4/dev next-20260302]
[cannot apply to linus/master v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Milos-Nikic/jbd2-gracefully-abort-instead-of-panicking-on-unlocked-buffer/20260303-085946
base: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all
patch link: https://lore.kernel.org/r/20260303005502.337108-3-nikic.milos%40gmail.com
patch subject: [PATCH v3 2/2] jbd2: gracefully abort on transaction state corruptions
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260303/202603030706.NpyA7pqe-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260303/202603030706.NpyA7pqe-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603030706.NpyA7pqe-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> fs/jbd2/transaction.c:1547:11: warning: variable 'journal' is uninitialized when used here [-Wuninitialized]
1547 | journal->j_devname, jh->b_transaction,
| ^~~~~~~
include/linux/printk.h:554:33: note: expanded from macro 'pr_err'
554 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/printk.h:511:60: note: expanded from macro 'printk'
511 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/printk.h:483:19: note: expanded from macro 'printk_index_wrap'
483 | _p_func(_fmt, ##__VA_ARGS__); \
| ^~~~~~~~~~~
fs/jbd2/transaction.c:1520:20: note: initialize the variable 'journal' to silence this warning
1520 | journal_t *journal;
| ^
| = NULL
1 warning generated.
vim +/journal +1547 fs/jbd2/transaction.c
1493
1494 /**
1495 * jbd2_journal_dirty_metadata() - mark a buffer as containing dirty metadata
1496 * @handle: transaction to add buffer to.
1497 * @bh: buffer to mark
1498 *
1499 * mark dirty metadata which needs to be journaled as part of the current
1500 * transaction.
1501 *
1502 * The buffer must have previously had jbd2_journal_get_write_access()
1503 * called so that it has a valid journal_head attached to the buffer
1504 * head.
1505 *
1506 * The buffer is placed on the transaction's metadata list and is marked
1507 * as belonging to the transaction.
1508 *
1509 * Returns error number or 0 on success.
1510 *
1511 * Special care needs to be taken if the buffer already belongs to the
1512 * current committing transaction (in which case we should have frozen
1513 * data present for that commit). In that case, we don't relink the
1514 * buffer: that only gets done when the old transaction finally
1515 * completes its commit.
1516 */
1517 int jbd2_journal_dirty_metadata(handle_t *handle, struct buffer_head *bh)
1518 {
1519 transaction_t *transaction = handle->h_transaction;
1520 journal_t *journal;
1521 struct journal_head *jh;
1522 int ret = 0;
1523
1524 if (!buffer_jbd(bh))
1525 return -EUCLEAN;
1526
1527 /*
1528 * We don't grab jh reference here since the buffer must be part
1529 * of the running transaction.
1530 */
1531 jh = bh2jh(bh);
1532 jbd2_debug(5, "journal_head %p\n", jh);
1533 JBUFFER_TRACE(jh, "entry");
1534
1535 /*
1536 * This and the following assertions are unreliable since we may see jh
1537 * in inconsistent state unless we grab bh_state lock. But this is
1538 * crucial to catch bugs so let's do a reliable check until the
1539 * lockless handling is fully proven.
1540 */
1541 if (data_race(jh->b_transaction != transaction &&
1542 jh->b_next_transaction != transaction)) {
1543 spin_lock(&jh->b_state_lock);
1544 if (WARN_ON_ONCE(jh->b_transaction != transaction &&
1545 jh->b_next_transaction != transaction)) {
1546 pr_err("JBD2: %s: assertion failure: b_transaction=%p transaction=%p b_next_transaction=%p\n",
> 1547 journal->j_devname, jh->b_transaction,
1548 transaction, jh->b_next_transaction);
1549 ret = -EINVAL;
1550 goto out_unlock_bh;
1551 }
1552 spin_unlock(&jh->b_state_lock);
1553 }
1554 if (data_race(jh->b_modified == 1)) {
1555 /* If it's in our transaction it must be in BJ_Metadata list. */
1556 if (data_race(jh->b_transaction == transaction &&
1557 jh->b_jlist != BJ_Metadata)) {
1558 spin_lock(&jh->b_state_lock);
1559 if (jh->b_transaction == transaction &&
1560 jh->b_jlist != BJ_Metadata)
1561 pr_err("JBD2: assertion failure: h_type=%u h_line_no=%u block_no=%llu jlist=%u\n",
1562 handle->h_type, handle->h_line_no,
1563 (unsigned long long) bh->b_blocknr,
1564 jh->b_jlist);
1565 if (WARN_ON_ONCE(jh->b_transaction == transaction &&
1566 jh->b_jlist != BJ_Metadata)) {
1567 ret = -EINVAL;
1568 goto out_unlock_bh;
1569 }
1570 spin_unlock(&jh->b_state_lock);
1571 }
1572 goto out;
1573 }
1574
1575 spin_lock(&jh->b_state_lock);
1576
1577 if (is_handle_aborted(handle)) {
1578 /*
1579 * Check journal aborting with @jh->b_state_lock locked,
1580 * since 'jh->b_transaction' could be replaced with
1581 * 'jh->b_next_transaction' during old transaction
1582 * committing if journal aborted, which may fail
1583 * assertion on 'jh->b_frozen_data == NULL'.
1584 */
1585 ret = -EROFS;
1586 goto out_unlock_bh;
1587 }
1588
1589 journal = transaction->t_journal;
1590
1591 if (jh->b_modified == 0) {
1592 /*
1593 * This buffer's got modified and becoming part
1594 * of the transaction. This needs to be done
1595 * once a transaction -bzzz
1596 */
1597 if (WARN_ON_ONCE(jbd2_handle_buffer_credits(handle) <= 0)) {
1598 ret = -ENOSPC;
1599 goto out_unlock_bh;
1600 }
1601 jh->b_modified = 1;
1602 handle->h_total_credits--;
1603 }
1604
1605 /*
1606 * fastpath, to avoid expensive locking. If this buffer is already
1607 * on the running transaction's metadata list there is nothing to do.
1608 * Nobody can take it off again because there is a handle open.
1609 * I _think_ we're OK here with SMP barriers - a mistaken decision will
1610 * result in this test being false, so we go in and take the locks.
1611 */
1612 if (jh->b_transaction == transaction && jh->b_jlist == BJ_Metadata) {
1613 JBUFFER_TRACE(jh, "fastpath");
1614 if (unlikely(jh->b_transaction !=
1615 journal->j_running_transaction)) {
1616 printk(KERN_ERR "JBD2: %s: "
1617 "jh->b_transaction (%llu, %p, %u) != "
1618 "journal->j_running_transaction (%p, %u)\n",
1619 journal->j_devname,
1620 (unsigned long long) bh->b_blocknr,
1621 jh->b_transaction,
1622 jh->b_transaction ? jh->b_transaction->t_tid : 0,
1623 journal->j_running_transaction,
1624 journal->j_running_transaction ?
1625 journal->j_running_transaction->t_tid : 0);
1626 ret = -EINVAL;
1627 }
1628 goto out_unlock_bh;
1629 }
1630
1631 set_buffer_jbddirty(bh);
1632
1633 /*
1634 * Metadata already on the current transaction list doesn't
1635 * need to be filed. Metadata on another transaction's list must
1636 * be committing, and will be refiled once the commit completes:
1637 * leave it alone for now.
1638 */
1639 if (jh->b_transaction != transaction) {
1640 JBUFFER_TRACE(jh, "already on other transaction");
1641 if (unlikely(((jh->b_transaction !=
1642 journal->j_committing_transaction)) ||
1643 (jh->b_next_transaction != transaction))) {
1644 printk(KERN_ERR "jbd2_journal_dirty_metadata: %s: "
1645 "bad jh for block %llu: "
1646 "transaction (%p, %u), "
1647 "jh->b_transaction (%p, %u), "
1648 "jh->b_next_transaction (%p, %u), jlist %u\n",
1649 journal->j_devname,
1650 (unsigned long long) bh->b_blocknr,
1651 transaction, transaction->t_tid,
1652 jh->b_transaction,
1653 jh->b_transaction ?
1654 jh->b_transaction->t_tid : 0,
1655 jh->b_next_transaction,
1656 jh->b_next_transaction ?
1657 jh->b_next_transaction->t_tid : 0,
1658 jh->b_jlist);
1659 WARN_ON(1);
1660 ret = -EINVAL;
1661 }
1662 /* And this case is illegal: we can't reuse another
1663 * transaction's data buffer, ever. */
1664 goto out_unlock_bh;
1665 }
1666
1667 /* That test should have eliminated the following case: */
1668 if (WARN_ON_ONCE(jh->b_frozen_data)) {
1669 ret = -EINVAL;
1670 goto out_unlock_bh;
1671 }
1672
1673 JBUFFER_TRACE(jh, "file as BJ_Metadata");
1674 spin_lock(&journal->j_list_lock);
1675 __jbd2_journal_file_buffer(jh, transaction, BJ_Metadata);
1676 spin_unlock(&journal->j_list_lock);
1677 out_unlock_bh:
1678 spin_unlock(&jh->b_state_lock);
1679 out:
1680 JBUFFER_TRACE(jh, "exit");
1681 return ret;
1682 }
1683
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] fsverity: add dependency on 64K or smaller pages
From: Eric Biggers @ 2026-03-03 5:06 UTC (permalink / raw)
To: fsverity
Cc: linux-fsdevel, Christoph Hellwig, Arnd Bergmann, linux-ext4,
linux-f2fs-devel, linux-btrfs, linux-xfs
In-Reply-To: <20260221204525.30426-1-ebiggers@kernel.org>
On Sat, Feb 21, 2026 at 12:45:25PM -0800, Eric Biggers wrote:
> Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs)
> cache the Merkle tree in the pagecache at a 64K aligned offset after the
> end of the file data. This offset needs to be a multiple of the page
> size, which is guaranteed only when the page size is 64K or smaller.
>
> 64K was chosen to be the "largest reasonable page size". But it isn't
> the largest *possible* page size: the hexagon and powerpc ports of Linux
> support 256K pages, though that configuration is rarely used.
>
> For now, just disable support for FS_VERITY in these odd configurations
> to ensure it isn't used in cases where it would have incorrect behavior.
>
> Fixes: 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing")
> Reported-by: Christoph Hellwig <hch@lst.de>
> Closes: https://lore.kernel.org/r/20260119063349.GA643@lst.de
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> fs/verity/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
Applied to https://git.kernel.org/pub/scm/fs/fsverity/linux.git/log/?h=for-current
- Eric
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Darrick J. Wong @ 2026-03-03 4:25 UTC (permalink / raw)
To: Theodore Tso
Cc: Jeff Layton, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260303012556.GA6520@macsyma-wired.lan>
On Mon, Mar 02, 2026 at 08:25:56PM -0500, Theodore Tso wrote:
> On Mon, Mar 02, 2026 at 03:23:45PM -0500, Jeff Layton wrote:
> > The PRIino macro is a length modifier, not a complete format specifier.
> > It is used as: "%" PRIino "u" for decimal, "%" PRIino "x" for hex, etc.
> > This follows the pattern used by userspace PRIu64/PRIx64 macros.
>
> For the record, I really hate the inttypes.h format specifiers, but I
> agree that we should forward the example of the C99 spec, for better
> or for worse.
>
> That being said, the userspace PRIu64, et. al macros are complete
> format specifiers, not just a length modifier. And I think this
> results in less ugly format specifiers in our kernel code.
Yeah, I don't like "ino=%" PRIino "u, lolz\n" either. I'd rather have
the whole format in the PRIino definition -- it /is/ unsigned long
after all.
--D
> ---- cut here ---
> #!/bin/sh
> cat <<EOF > /tmp/blah.c
> #include <inttypes.h>
> #include <stdio.h>
>
> int main(int arg, char **argv)
> {
> printf("PRIu64 is %s\n", PRIu64);
> printf("PRId64 is %s\n", PRId64);
> printf("PRIx64 is %s\n", PRIx64);
> return 0;
> }
> EOF
>
> clang -m32 -o /tmp/blah /tmp/blah.c
> /tmp/blah
> ---- cut here ---
>
> % /tmp/blah.sh
> PRIu64 is llu
> PRId64 is lld
> PRIx64 is llx
>
> Thanks!
>
> - Ted
^ permalink raw reply
* Re: [PATCH] ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
From: Baokun Li @ 2026-03-03 2:36 UTC (permalink / raw)
To: Ye Bin; +Cc: jack, tytso, adilger.kernel, linux-ext4
In-Reply-To: <20260302134619.3145520-1-yebin@huaweicloud.com>
On 3/2/26 9:46 PM, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> There's issue as follows:
> ...
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117
> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
>
> EXT4-fs (mmcblk0p1): error count since last fsck: 1
> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760
> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760
> ...
>
> According to the log analysis, blocks are always requested from the
> corrupted block group. This may happen as follows:
> ext4_mb_find_by_goal
> ext4_mb_load_buddy
> ext4_mb_load_buddy_gfp
> ext4_mb_init_cache
> ext4_read_block_bitmap_nowait
> ext4_wait_block_bitmap
> ext4_validate_block_bitmap
> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))
> return -EFSCORRUPTED; // There's no logs.
> if (err)
> return err; // Will return error
> ext4_lock_group(ac->ac_sb, group);
> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable
> goto out;
>
> After commit 9008a58e5dce ("ext4: make the bitmap read routines return
> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group
> as corrupt on block bitmap error") is no real solution for allocating
> blocks from corrupted block groups. This is because if
> 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then
> 'ext4_mb_load_buddy()' may return an error. This means that the block
> allocation will fail.
> Therefore, check block group if corrupted when ext4_mb_load_buddy()
> returns error.
Good catch!
Agreed, we should try other groups upon failure unless it's a goal-only
allocation.
But note that e4b->bd_info might be uninitialized if ext4_mb_load_buddy()
fails.
I think we can optimize this in ext4_mb_regular_allocator(): we can record
the error from ext4_mb_find_by_goal() but avoid an early exit.
Specifically, after checking that EXT4_MB_HINT_GOAL_ONLY is not set,
we can assign the error to ac->ac_first_err. This way, if subsequent
allocation attempts still fail, we can preserve the original.
Cheers,
Baokun
> Fixes: 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error")
> Fixes: 9008a58e5dce ("ext4: make the bitmap read routines return real error codes")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/mballoc.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index e2341489f4d0..ffa6886de8a3 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -2443,8 +2443,12 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac,
> return 0;
>
> err = ext4_mb_load_buddy(ac->ac_sb, group, e4b);
> - if (err)
> + if (err) {
> + if (EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info) &&
> + !(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY))
> + return 0;
> return err;
> + }
>
> ext4_lock_group(ac->ac_sb, group);
> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox