linux-ext4 - [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bug-217965-13602-nOWQuR3ZDX@https.bugzilla.kernel.org/>
Date: Tue, 02 Dec 2025 09:05:46 +0000
From: bugzilla-daemon@...nel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd

https://bugzilla.kernel.org/show_bug.cgi?id=217965

--- Comment #74 from mingyu.he (mingyu.he@...pee.com) ---
(In reply to Ojaswin Mujoo from comment #73)

> I tried the replicator however I was unable to get to the high CPU util, but
> since you already have the setup, can you check if you are able to hit this
> issue in v6.4 vs v6.5.

Using C program, it won't result in high CPU util. Also, its running time is
very short, as it only allocate a single block.

If you try C program, you should also start a BPF program to trace 

'ext4_mb_scan_aligned' or 'mb_find_extent' or 'find_extent' and print key data
like this

 group_id=175542, block(i)=9744, needed(stripe)=30000, ret(max)=23024

Here is my BPF program:

#!/usr/bin/env bpftrace

struct ext4_buddy {
struct page *bd_buddy_page;
void *bd_buddy;
struct page *bd_bitmap_page;
void *bd_bitmap;
struct ext4_group_info *bd_info;
struct super_block *bd_sb;
__u16 bd_blkbits;
ext4_group_t bd_group;
};

BEGIN
{
    printf("Tracing ext4_mb_regular_allocator... Hit Ctrl-C to stop.\n");
}

kprobe:mb_find_extent
{
    @no_group[tid] = ((struct ext4_buddy *)arg0)->bd_group;
    @arg1[tid] = arg1; 
    @arg2[tid] = arg2;
}

kretprobe:mb_find_extent
/@...1[tid]/
{
    print(kstack(3));
    printf("find_ex, tid=%d, group_id=%d, block(i)=%d, needed(stripe)=%d,
ret(max)=%d\n",
           tid, @no_group[tid], @arg1[tid], @arg2[tid], retval);
    delete(@no_group[tid]);
    delete(@arg1[tid]);
    delete(@arg2[tid]);
}

At last, if you still can't reproduce, I can help you test it in 6.4 VS 6.5

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.