Re: [2.6.32 ubuntu] I/O hang at start_this_handle

[Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>]

Jan Kara wrote:
>   Ext3 looks innocent here. That is a standard call path for open(..,
> O_TRUNC). But apparently something broke in SLUB allocator. Adding proper
> list to CC...

Thanks.

Both fs/jbd/transaction.c and fs/jbd2/transaction.c provide start_this_handle()
and I don't know which one was called.

But

	if (!journal->j_running_transaction) {
		new_transaction = kzalloc(sizeof(*new_transaction),
					  GFP_NOFS|__GFP_NOFAIL);
		if (!new_transaction) {
			ret = -ENOMEM;
			goto out;
		}
	}

does kzalloc(GFP_NOFS|__GFP_NOFAIL) causes /proc/$PID/status to show

  State:  D (disk sleep)

line? I thought this is either

	if (transaction->t_state == T_LOCKED) {
		DEFINE_WAIT(wait);

		prepare_to_wait(&journal->j_wait_transaction_locked,
				&wait, TASK_UNINTERRUPTIBLE);
		spin_unlock(&journal->j_state_lock);
		schedule();
		finish_wait(&journal->j_wait_transaction_locked, &wait);
		goto repeat;
	}

or

	if (needed > journal->j_max_transaction_buffers) {
		/*
		 * If the current transaction is already too large, then start
		 * to commit it: we can then go back and attach this handle to
		 * a new transaction.
		 */
		DEFINE_WAIT(wait);

		jbd_debug(2, "Handle %p starting new commit...\n", handle);
		spin_unlock(&transaction->t_handle_lock);
		prepare_to_wait(&journal->j_wait_transaction_locked, &wait,
				TASK_UNINTERRUPTIBLE);
		__jbd2_log_start_commit(journal, transaction->t_tid);
		spin_unlock(&journal->j_state_lock);
		schedule();
		finish_wait(&journal->j_wait_transaction_locked, &wait);
		goto repeat;
	}

within start_this_handle().
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html