linux-kernel - Re: [PATCH 0/2] Postpone memcg reclaim to return-to-user path

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: <bkql5n7vg7zoxxf3rwfceioenwkifw7iw4tev4jkljzkvpbrci@6uofefhkdzrx>
Date: Thu, 19 Jun 2025 10:04:56 +0200
From: Jan Kara <jack@...e.cz>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Zhongkun He <hezhongkun.hzk@...edance.com>, akpm@...ux-foundation.org, 
	tytso@....edu, jack@...e.com, hannes@...xchg.org, mhocko@...nel.org, 
	muchun.song@...ux.dev, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, cgroups@...r.kernel.org
Subject: Re: [PATCH 0/2] Postpone memcg reclaim to return-to-user path

On Wed 18-06-25 15:37:20, Shakeel Butt wrote:
> > This is
> > beneficial for users who perform over-max reclaim while holding multiple
> > locks or other resources (especially resources related to file system
> > writeback). If a task needs any of these resources, it would otherwise
> > have to wait until the other task completes reclaim and releases the
> > resources. Postponing reclaim to the return-to-user path helps avoid this issue.
> > 
> > # Background
> > 
> > We have been encountering an hungtask issue for a long time. Specifically,
> > when a task holds the jbd2 handler 
> 
> Can you explain a bit more about jbd2 handler? Is it some global shared
> lock or a workqueue which can only run single thread at a time.
> Basically is there a way to get the current holder/owner of jbd2 handler
> programmatically?

There's a typo in the original email :). It should be "jbd2 handle". And
that is just a reference to the currently running transaction in ext4
filesystem. There can be always at most one running transaction in ext4
filesystem and until the last reference is dropped it cannot commit. This
eventually (once the transaction reaches its maximum size) blocks all the
other modifications to the filesystem. So it is shared global resource
that's held by the process doing reclaim.

Since there can be many holders of references to the currently running
transaction there's no easy way to iterate processes that are holding the
references... That being said ext4 sets current->journal_info when
acquiring a journal handle but other filesystems use this field for other
purposes so current->journal_info being non-NULL does not mean jbd2 handle
is held.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR