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>

diff --git a/fs/bcachefs/journal.c b/fs/bcachefs/journal.c
index 801f09593e6b77a0f2201e4f6464c1342b98550f..43bb1d4002bddd50960d0595a5b03c4cd405897c 100644 (file)
--- a/fs/bcachefs/journal.c
+++ b/fs/bcachefs/journal.c
@@ -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()