[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUInJQ0wJ4Cd07dT@mit.edu>
Date: Wed, 15 Sep 2021 13:02:29 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: NeilBrown <neilb@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Andreas Dilger <adilger.kernel@...ger.ca>,
"Darrick J. Wong" <djwong@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Mel Gorman <mgorman@...e.com>, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] EXT4: Remove ENOMEM/congestion_wait() loops.
On Wed, Sep 15, 2021 at 03:25:40PM +1000, NeilBrown wrote:
> Adding gfp_mask to __ext4_journal_start_sb() make perfect sense.
> There doesn't seem much point adding one to __ext4_journal_start(),
> we can have ext4_journal_start_with_revoke() call
> __ext4_journal_start_sb() directly.
> But I cannot see what it doesn't already do that.
> i.e. why have the inline __ext4_journal_start() at all?
> Is it OK if I don't use that for ext4_journal_start_with_revoke()?
Sure. I think the only reason why we have __ext4_journal_start() as
an inline function at all was for historical reasons. That is, we
modified __ext4_journal_start() so that it took a struct super, and
instead of changing all of the macros which called
__ext4_journal_start(), we named it to be __ext4_journal_start_sb()
and added the inline definition of __ext4_journal_start() to avoid
changing all of the existing users of __ext4_journal_start().
So sure, it's fine not to use that for
ext4_journal_start_with_revoke(), and we probably should clean up the
use of __ext4_journal_start() at some point. That's unrelated to your
work, though.
Cheers,
- Ted
Powered by blists - more mailing lists