On Thu, Dec 22, 2011 at 03:07:45PM +0100, Jan Kara wrote:
> j_barrier mutex is used for serializing different journal lock operations. The
> problem with it is that e.g. FIFREEZE ioctl results in process leaving kernel
> with j_barrier mutex held which makes lockdep freak out. Also hibernation code
> wants to freeze filesystem but it cannot do so because it then cannot hibernate
> the system because of mutex being locked.
>
> So we remove j_barrier mutex and use direct wait on j_barrier_count instead.
> Since locking journal is a rare operation we don't have to care about fairness
> or such things.
>
> CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Jan Kara <jack@xxxxxxx>
Strikes me as pretty reasonable.
> void journal_lock_updates(journal_t *journal)
> {
> DEFINE_WAIT(wait);
>
> +wait:
> + /* Wait for previous locked operation to finish */
> + wait_event(journal->j_wait_transaction_locked,
> + journal->j_barrier_count == 0);
> +
> spin_lock(&journal->j_state_lock);
> + /*
> + * Check reliably under the lock whether we are the ones winning the race
> + * and locking the journal
> + */
> + if (journal->j_barrier_count > 0) {
> + spin_unlock(&journal->j_state_lock);
> + goto wait;
> + }
I suppose I'd prefer:
do {
wait_event(journal->j_wait_transaction_locked,
journal->j_barrier_count == 0);
spin_lock(&journal->j_state_lock);
if (journal->j_barrier_count == 0)
break;
spin_unlock(&journal->j_state_lock);
} while (1);
++journal->j_barrier_count;
because I hate using goto for trivial loops, but that's a nitpick.
ACK.
Joel
--
You can use a screwdriver to screw in screws or to clean your ears,
however, the latter needs real skill, determination and a lack of fear
of injuring yourself. It is much the same with JavaScript.
- Chris Heilmann
http://www.jlbec.org/
jlbec@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
