mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-17 18:56:24 +00:00
bcachefs: gracefully unwind journal res slowpath on shutdown
bcachefs detects journal stuck conditions in a couple different places. If the logic in the journal reservation slow path happens to detect the problem, I've seen instances where the filesystem remains deadlocked even though it has been shut down. This is occasionally reproduced by generic/333, and usually manifests as one or more tasks stuck in the journal reservation slow path. To help avoid this problem, repeat the journal error check in __journal_res_get() once under spinlock to cover the case where the previous lock holder might have triggered shutdown. This also helps avoid spurious/duplicate stuck reports. Also, wake the journal from the halt code to make sure blocked callers of the journal res slowpath have a chance to wake up and observe the pending error. This survives an overnight looping run of generic/333 without the aforementioned lockups. Signed-off-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This commit is contained in:
parent
873555f04d
commit
23fd4f4dc6
@ -162,6 +162,7 @@ void bch2_journal_halt(struct journal *j)
|
||||
__journal_entry_close(j, JOURNAL_ENTRY_ERROR_VAL);
|
||||
if (!j->err_seq)
|
||||
j->err_seq = journal_cur_seq(j);
|
||||
journal_wake(j);
|
||||
spin_unlock(&j->lock);
|
||||
}
|
||||
|
||||
@ -362,6 +363,12 @@ retry:
|
||||
|
||||
spin_lock(&j->lock);
|
||||
|
||||
/* check once more in case somebody else shut things down... */
|
||||
if (bch2_journal_error(j)) {
|
||||
spin_unlock(&j->lock);
|
||||
return -BCH_ERR_erofs_journal_err;
|
||||
}
|
||||
|
||||
/*
|
||||
* Recheck after taking the lock, so we don't race with another thread
|
||||
* that just did journal_entry_open() and call journal_entry_close()
|
||||
|
Loading…
x
Reference in New Issue
Block a user