linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jim Zhao <jimzhao.ai@gmail.com>,
	akpm@linux-foundation.org,  jack@suse.cz, willy@infradead.org,
	linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm/page-writeback: Consolidate wb_thresh bumping logic into __wb_calc_thresh
Date: Tue, 14 Jan 2025 14:19:01 +0100	[thread overview]
Message-ID: <b4m3w6wuw3h6ke7qlvimly7nok4ymjvnej2vx3lnds3vysyopr@6b5bnifyst24> (raw)
In-Reply-To: <a0d751f8-e50b-4fa5-a4bc-bccfc574f3bb@roeck-us.net>

On Mon 13-01-25 15:05:25, Guenter Roeck wrote:
> Hi,
> 
> 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@suse.cz>
> > Signed-off-by: Jim Zhao <jimzhao.ai@gmail.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?

								Honza

> udhcpc: no lease, failing
> FAIL
> /etc/init.d/S55runtest: line 29: awk: Permission denied
> Found console ttySC1
> /etc/init.d/S55runtest: line 45: awk: Permission denied
> can't run '/sbin/getty': No such device or address
> 
> and boot stalls from there. There is no obvious kernel log message
> associated with the problem. Reverting this patch fixes the problem.
> 
> Bisect log is attached for reference.
> 
> Guenter
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR


  reply	other threads:[~2025-01-14 13:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-21 10:05 Jim Zhao
2025-01-13 23:05 ` Guenter Roeck
2025-01-14 13:19   ` Jan Kara [this message]
2025-01-14 15:01     ` Guenter Roeck
2025-01-15 16:07       ` Jan Kara
2025-01-15 16:28         ` Jan Kara
2025-01-15 16:52           ` Guenter Roeck
2025-01-15 16:41         ` Guenter Roeck
2025-01-16 14:56           ` Jan Kara
2025-01-16 16:05             ` Guenter Roeck
2025-10-07 16:17 ` Joshua Watt
2025-10-08 11:14   ` Jan Kara
2025-10-08 14:49     ` Joshua Watt
2025-10-08 23:14       ` Joshua Watt
2025-10-09  8:38         ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4m3w6wuw3h6ke7qlvimly7nok4ymjvnej2vx3lnds3vysyopr@6b5bnifyst24 \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=jimzhao.ai@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox