From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org, Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 09/14] xfs: move log shut down handling out of xlog_state_iodone_process_iclog
Date: Wed, 18 Mar 2020 10:48:25 -0400 [thread overview]
Message-ID: <20200318144825.GB32848@bfoster> (raw)
In-Reply-To: <20200316144233.900390-10-hch@lst.de>
On Mon, Mar 16, 2020 at 03:42:28PM +0100, Christoph Hellwig wrote:
> Move handling of a shut down log out of xlog_state_iodone_process_iclog
> and into xlog_state_do_callback so that it can be moved into an entirely
> separate branch. While doing so switch to using XLOG_FORCED_SHUTDOWN to
> check the shutdown condition global to the log instead of the per-iclog
> flag, and make sure the comments match reality.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_log.c | 64 ++++++++++++++++++++----------------------------
> 1 file changed, 26 insertions(+), 38 deletions(-)
>
> diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
> index c534d7007aa3..4efaa248a03d 100644
> --- a/fs/xfs/xfs_log.c
> +++ b/fs/xfs/xfs_log.c
...
> @@ -2795,39 +2785,41 @@ STATIC void
> xlog_state_do_callback(
> struct xlog *log)
> {
> - struct xlog_in_core *iclog;
> - struct xlog_in_core *first_iclog;
> bool cycled_icloglock;
> - bool ioerror;
> int flushcnt = 0;
> int repeats = 0;
>
> + /*
> + * Scan all iclogs starting with the one pointed to by the log. Reset
> + * this starting point each time the log is unlocked (during callbacks).
> + *
> + * Keep looping through iclogs until one full pass is made without
> + * running any callbacks.
> + *
> + * If the log has been shut down, still perform the callbacks once per
> + * iclog to abort all log items, but don't bother to restart the loop
> + * after dropping the log as no new callbacks can show up.
> + */
"after dropping the lock ..."
> spin_lock(&log->l_icloglock);
> do {
> - /*
> - * Scan all iclogs starting with the one pointed to by the
> - * log. Reset this starting point each time the log is
> - * unlocked (during callbacks).
> - *
> - * Keep looping through iclogs until one full pass is made
> - * without running any callbacks.
> - */
> - first_iclog = log->l_iclog;
> - iclog = log->l_iclog;
> + struct xlog_in_core *first_iclog = log->l_iclog;
> + struct xlog_in_core *iclog = first_iclog;
> +
> cycled_icloglock = false;
> - ioerror = false;
> repeats++;
>
> do {
> - if (xlog_state_iodone_process_iclog(log, iclog,
> - &ioerror))
> + if (XLOG_FORCED_SHUTDOWN(log)) {
> + xlog_state_do_iclog_callbacks(log, iclog);
> + wake_up_all(&iclog->ic_force_wait);
> + continue;
> + }
> +
Why do we need to change the flow here? The current code looks like it
proceeds with the _do_iclog_callbacks() call below..
As it is, I also don't think this reflects the comment above because if
we catch the shutdown partway through a loop, the outer loop will
execute one more time through. That doesn't look like a problem at a
glance, but I think we should try to retain closer to existing behavior
by folding the shutdown check into the ic_state check below as well as
the outer loop conditional.
This (and the next patch) also raises the issue of whether to maintain
state validity once the iclog ioerror state goes away. Currently we see
the IOERROR state and kind of have free reign on busting through the
normal runtime logic to clear out callbacks, etc. on the iclog
regardless of what the pre-error state was. It certainly makes sense to
continue to do that based on XLOG_FORCED_SHUTDOWN(), but the iclog state
sort of provides a platform that allows us to do that because any
particular context can see it and handle an iclog with care. With
IOERROR replaced with the (potentially racy) log flag check, I think we
should try to maintain the coherence of other states wherever possible.
IOW, XLOG_FORCED_SHUTDOWN() means we can run callbacks and abort and
whatnot, but we should probably still consider and update the iclog
state as we progress (as opposed to leaving it in the DONE_SYNC state,
for example) because there's no guarantee some other context will
(always) behave just as it did with IOERROR.
Brian
> + if (xlog_state_iodone_process_iclog(log, iclog))
> break;
>
> - if (iclog->ic_state != XLOG_STATE_CALLBACK &&
> - iclog->ic_state != XLOG_STATE_IOERROR) {
> - iclog = iclog->ic_next;
> + if (iclog->ic_state != XLOG_STATE_CALLBACK)
> continue;
> - }
>
> /*
> * Running callbacks will drop the icloglock which means
> @@ -2835,12 +2827,8 @@ xlog_state_do_callback(
> */
> cycled_icloglock = true;
> xlog_state_do_iclog_callbacks(log, iclog);
> - if (XLOG_FORCED_SHUTDOWN(log))
> - wake_up_all(&iclog->ic_force_wait);
> - else
> - xlog_state_clean_iclog(log, iclog);
> - iclog = iclog->ic_next;
> - } while (first_iclog != iclog);
> + xlog_state_clean_iclog(log, iclog);
> + } while ((iclog = iclog->ic_next) != first_iclog);
>
> if (repeats > 5000) {
> flushcnt += repeats;
> @@ -2849,7 +2837,7 @@ xlog_state_do_callback(
> "%s: possible infinite loop (%d iterations)",
> __func__, flushcnt);
> }
> - } while (!ioerror && cycled_icloglock);
> + } while (cycled_icloglock);
>
> if (log->l_iclog->ic_state == XLOG_STATE_ACTIVE ||
> log->l_iclog->ic_state == XLOG_STATE_IOERROR)
> --
> 2.24.1
>
next prev parent reply other threads:[~2020-03-18 14:48 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 14:42 cleanup log I/O error handling v2 Christoph Hellwig
2020-03-16 14:42 ` [PATCH 01/14] xfs: merge xlog_cil_push into xlog_cil_push_work Christoph Hellwig
2020-03-16 19:40 ` Darrick J. Wong
2020-03-17 0:15 ` Dave Chinner
2020-03-17 13:23 ` Brian Foster
2020-03-16 14:42 ` [PATCH 02/14] xfs: factor out a xlog_wait_on_iclog helper Christoph Hellwig
2020-03-16 20:20 ` Darrick J. Wong
2020-03-17 13:23 ` Brian Foster
2020-03-16 14:42 ` [PATCH 03/14] xfs: simplify the xfs_log_release_iclog calling convention Christoph Hellwig
2020-03-16 20:21 ` Darrick J. Wong
2020-03-17 13:23 ` Brian Foster
2020-03-16 14:42 ` [PATCH 04/14] xfs: simplify log shutdown checking in xfs_log_release_iclog Christoph Hellwig
2020-03-16 20:33 ` Darrick J. Wong
2020-03-17 13:24 ` Brian Foster
2020-03-16 14:42 ` [PATCH 05/14] xfs: remove the aborted parameter to xlog_state_done_syncing Christoph Hellwig
2020-03-16 20:50 ` Darrick J. Wong
2020-03-18 9:38 ` Christoph Hellwig
2020-03-17 13:24 ` Brian Foster
2020-03-16 14:42 ` [PATCH 06/14] xfs: refactor xlog_state_clean_iclog Christoph Hellwig
2020-03-16 20:59 ` Darrick J. Wong
2020-03-17 13:25 ` Brian Foster
2020-03-18 9:40 ` Christoph Hellwig
2020-03-16 14:42 ` [PATCH 07/14] xfs: move the ioerror check out of xlog_state_clean_iclog Christoph Hellwig
2020-03-16 21:00 ` Darrick J. Wong
2020-03-17 13:25 ` Brian Foster
2020-03-16 14:42 ` [PATCH 08/14] xfs: move xlog_state_do_iclog_callbacks up Christoph Hellwig
2020-03-16 21:00 ` Darrick J. Wong
2020-03-18 14:44 ` Brian Foster
2020-03-16 14:42 ` [PATCH 09/14] xfs: move log shut down handling out of xlog_state_iodone_process_iclog Christoph Hellwig
2020-03-16 21:02 ` Darrick J. Wong
2020-03-18 14:48 ` Brian Foster [this message]
2020-03-18 16:34 ` Christoph Hellwig
2020-03-19 11:36 ` Brian Foster
2020-03-19 13:05 ` Christoph Hellwig
2020-03-19 13:37 ` Brian Foster
2020-03-16 14:42 ` [PATCH 10/14] xfs: refactor xlog_state_iodone_process_iclog Christoph Hellwig
2020-03-16 21:07 ` Darrick J. Wong
2020-03-16 14:42 ` [PATCH 11/14] xfs: merge xlog_state_clean_iclog into xlog_state_iodone_process_iclog Christoph Hellwig
2020-03-16 21:09 ` Darrick J. Wong
2020-03-18 14:48 ` Brian Foster
2020-03-16 14:42 ` [PATCH 12/14] xfs: merge xlog_state_set_callback " Christoph Hellwig
2020-03-16 21:10 ` Darrick J. Wong
2020-03-18 14:48 ` Brian Foster
2020-03-16 14:42 ` [PATCH 13/14] xfs: remove xlog_state_want_sync Christoph Hellwig
2020-03-16 21:23 ` Darrick J. Wong
2020-03-18 14:48 ` Brian Foster
2020-03-16 14:42 ` [PATCH 14/14] xfs: remove XLOG_STATE_IOERROR Christoph Hellwig
2020-03-16 21:25 ` Darrick J. Wong
2020-03-18 9:43 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200318144825.GB32848@bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).