linux-kernel - Re: [PATCH] mm/page-writeback: Consolidate wb_thresh bumping logic into __wb_calc

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: <885e0ae3-1d2e-43c7-a32b-f29871fc6b4b@roeck-us.net>
Date: Wed, 15 Jan 2025 08:52:43 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Jan Kara <jack@...e.cz>
Cc: Jim Zhao <jimzhao.ai@...il.com>, akpm@...ux-foundation.org,
 willy@...radead.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/page-writeback: Consolidate wb_thresh bumping logic
 into __wb_calc_thresh

On 1/15/25 08:28, Jan Kara wrote:
> On Wed 15-01-25 17:07:36, Jan Kara wrote:
>> On Tue 14-01-25 07:01:08, Guenter Roeck wrote:
>>> On 1/14/25 05:19, Jan Kara wrote:
>>>> On Mon 13-01-25 15:05:25, Guenter Roeck wrote:
>>>>> On Thu, Nov 21, 2024 at 06:05:39PM +0800, Jim Zhao wrote:
>>>>>> Address the feedback from "mm/page-writeback: raise wb_thresh to prevent
>>>>>> write blocking with strictlimit"(39ac99852fca98ca44d52716d792dfaf24981f53).
>>>>>> The wb_thresh bumping logic is scattered across wb_position_ratio,
>>>>>> __wb_calc_thresh, and wb_update_dirty_ratelimit. For consistency,
>>>>>> consolidate all wb_thresh bumping logic into __wb_calc_thresh.
>>>>>>
>>>>>> Reviewed-by: Jan Kara <jack@...e.cz>
>>>>>> Signed-off-by: Jim Zhao <jimzhao.ai@...il.com>
>>>>>
>>>>> This patch triggers a boot failure with one of my 'sheb' boot tests.
>>>>> It is seen when trying to boot from flash (mtd). The log says
>>>>>
>>>>> ...
>>>>> Starting network: 8139cp 0000:00:02.0 eth0: link down
>>>>> udhcpc: started, v1.33.0
>>>>> EXT2-fs (mtdblock3): error: ext2_check_folio: bad entry in directory #363: : directory entry across blocks - offset=0, inode=27393, rec_len=3072, name_len=2
>>>>> udhcpc: sending discover
>>>>> udhcpc: sending discover
>>>>> udhcpc: sending discover
>>>>> EXT2-fs (mtdblock3): error: ext2_check_folio: bad entry in directory #363: : directory entry across blocks - offset=0, inode=27393, rec_len=3072, name_len=2
>>>>
>>>> Thanks for report! Uh, I have to say I'm very confused by this. It is clear
>>>> than when ext2 detects the directory corruption (we fail checking directory
>>>> inode 363 which is likely /etc/init.d/), the boot fails in interesting
>>>> ways. What is unclear is how the commit can possibly cause ext2 directory
>>>> corruption.  If you didn't verify reverting the commit fixes the issue, I'd
>>>> be suspecting bad bisection but that obviously isn't the case :-)
>>>>
>>>> Ext2 is storing directory data in the page cache so at least it uses the
>>>> subsystem which the patch impacts but how writeback throttling can cause
>>>> ext2 directory corruption is beyond me. BTW, do you recreate the root
>>>> filesystem before each boot? How exactly?
>>>
>>> I use pre-built root file systems. For sheb, they are at
>>> https://github.com/groeck/linux-build-test/tree/master/rootfs/sheb
>>
>> Thanks. So the problematic directory is /usr/share/udhcpc/ where we
>> read apparently bogus metadata at the beginning of that directory.
> 
> Ah, the metadata isn't bogus. But the entries in the directory are
> apparently byte-swapped (little vs big endian). Is the machine actually
> little or big endian?
> 

sheb is big endian. I only see the problem there, not with the little endian
emulation. But that uses a different root file system. As I just mentioned
in the other reply, it might well be an emulation bug, but it is odd that your
patch would be required to expose that.

Guenter