linux-ext4 - Re: [PATCH 5/6] jbd2: Refactor wait logic for transaction updates into a common function

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: <20220113121721.nyn7kdmr6boaazvp@riteshh-domain>
Date:   Thu, 13 Jan 2022 17:47:21 +0530
From:   Ritesh Harjani <riteshh@...ux.ibm.com>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jan Kara <jack@...e.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>, tytso@....edu,
        Eric Whitney <enwlinux@...il.com>
Subject: Re: [PATCH 5/6] jbd2: Refactor wait logic for transaction updates
 into a common function

On 22/01/13 12:30PM, Jan Kara wrote:
> On Thu 13-01-22 08:56:28, Ritesh Harjani wrote:
> > No functionality change as such in this patch. This only refactors the
> > common piece of code which waits for t_updates to finish into a common
> > function named as jbd2_journal_wait_updates(journal_t *)
> >
> > Signed-off-by: Ritesh Harjani <riteshh@...ux.ibm.com>
>
> Just one nit, otherwise. Feel free to add:
>
> Reviewed-by: Jan Kara <jack@...e.cz>
>
> > @@ -1757,6 +1757,35 @@ static inline unsigned long jbd2_log_space_left(journal_t *journal)
> >  	return max_t(long, free, 0);
> >  }
> >
> > +/*
> > + * Waits for any outstanding t_updates to finish.
> > + * This is called with write j_state_lock held.
> > + */
> > +static inline void jbd2_journal_wait_updates(journal_t *journal)
> > +{
> > +	transaction_t *commit_transaction = journal->j_running_transaction;
> > +
> > +	if (!commit_transaction)
> > +		return;
> > +
> > +	spin_lock(&commit_transaction->t_handle_lock);
> > +	while (atomic_read(&commit_transaction->t_updates)) {
> > +		DEFINE_WAIT(wait);
> > +
> > +		prepare_to_wait(&journal->j_wait_updates, &wait,
> > +					TASK_UNINTERRUPTIBLE);
> > +		if (atomic_read(&commit_transaction->t_updates)) {
> > +			spin_unlock(&commit_transaction->t_handle_lock);
> > +			write_unlock(&journal->j_state_lock);
> > +			schedule();
> > +			write_lock(&journal->j_state_lock);
> > +			spin_lock(&commit_transaction->t_handle_lock);
> > +		}
> > +		finish_wait(&journal->j_wait_updates, &wait);
> > +	}
> > +	spin_unlock(&commit_transaction->t_handle_lock);
> > +}
> > +
>
> I don't think making this inline makes sence. Neither the commit code nor
> jbd2_journal_lock_updates() are so hot that it would warrant this large
> inline function...

Yes, make sense. Thanks for the review.
Will do the needful in v2.

-ritesh

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