linux-kernel - Re: [External] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACSyD1PJ8tGbWpqyCx=dXSgZbhfCuXcKKX6_kmN17F6g+E9m2w@mail.gmail.com>
Date: Tue, 24 Jun 2025 15:45:37 +0800
From: Zhongkun He <hezhongkun.hzk@...edance.com>
To: Jan Kara <jack@...e.cz>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, 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: [External] Re: [PATCH 0/2] Postpone memcg reclaim to
 return-to-user path

On Thu, Jun 19, 2025 at 4:05 PM Jan Kara <jack@...e.cz> wrote:
>
> 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.

Hi Jan,
Thanks for your feedback and explanations.

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