2020-05-13 07:54:17 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2016-08-03 09:12:25 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Oracle. All Rights Reserved.
|
|
|
|
* Author: Darrick J. Wong <darrick.wong@oracle.com>
|
|
|
|
*/
|
|
|
|
#ifndef __XFS_DEFER_H__
|
|
|
|
#define __XFS_DEFER_H__
|
|
|
|
|
2020-05-01 03:52:22 +08:00
|
|
|
struct xfs_btree_cur;
|
2016-08-03 09:12:25 +08:00
|
|
|
struct xfs_defer_op_type;
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
struct xfs_defer_capture;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Header for deferred operation list.
|
|
|
|
*/
|
|
|
|
enum xfs_defer_ops_type {
|
2016-10-04 00:11:28 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_BMAP,
|
2016-10-04 00:11:22 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_REFCOUNT,
|
2016-08-03 10:11:01 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_RMAP,
|
2016-08-03 09:14:35 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_FREE,
|
2018-05-08 08:38:47 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_AGFL_FREE,
|
2016-08-03 09:12:25 +08:00
|
|
|
XFS_DEFER_OPS_TYPE_MAX,
|
|
|
|
};
|
|
|
|
|
2018-12-13 00:46:22 +08:00
|
|
|
/*
|
|
|
|
* Save a log intent item and a list of extents, so that we can replay
|
|
|
|
* whatever action had to happen to the extent list and file the log done
|
|
|
|
* item.
|
|
|
|
*/
|
|
|
|
struct xfs_defer_pending {
|
|
|
|
struct list_head dfp_list; /* pending items */
|
|
|
|
struct list_head dfp_work; /* work items */
|
2020-05-01 03:52:21 +08:00
|
|
|
struct xfs_log_item *dfp_intent; /* log intent item */
|
2020-05-01 03:52:22 +08:00
|
|
|
struct xfs_log_item *dfp_done; /* log done item */
|
2018-12-13 00:46:22 +08:00
|
|
|
unsigned int dfp_count; /* # extent items */
|
|
|
|
enum xfs_defer_ops_type dfp_type;
|
|
|
|
};
|
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
void xfs_defer_add(struct xfs_trans *tp, enum xfs_defer_ops_type type,
|
2016-08-03 09:12:25 +08:00
|
|
|
struct list_head *h);
|
2018-07-25 04:43:15 +08:00
|
|
|
int xfs_defer_finish_noroll(struct xfs_trans **tp);
|
2018-07-25 04:43:15 +08:00
|
|
|
int xfs_defer_finish(struct xfs_trans **tp);
|
2018-08-01 22:20:30 +08:00
|
|
|
void xfs_defer_cancel(struct xfs_trans *);
|
2018-08-01 22:20:30 +08:00
|
|
|
void xfs_defer_move(struct xfs_trans *dtp, struct xfs_trans *stp);
|
2016-08-03 09:12:25 +08:00
|
|
|
|
|
|
|
/* Description of a deferred type. */
|
|
|
|
struct xfs_defer_op_type {
|
2020-05-01 03:52:21 +08:00
|
|
|
struct xfs_log_item *(*create_intent)(struct xfs_trans *tp,
|
|
|
|
struct list_head *items, unsigned int count, bool sort);
|
|
|
|
void (*abort_intent)(struct xfs_log_item *intent);
|
2020-05-01 03:52:22 +08:00
|
|
|
struct xfs_log_item *(*create_done)(struct xfs_trans *tp,
|
|
|
|
struct xfs_log_item *intent, unsigned int count);
|
|
|
|
int (*finish_item)(struct xfs_trans *tp, struct xfs_log_item *done,
|
2020-05-01 03:52:22 +08:00
|
|
|
struct list_head *item, struct xfs_btree_cur **state);
|
|
|
|
void (*finish_cleanup)(struct xfs_trans *tp,
|
|
|
|
struct xfs_btree_cur *state, int error);
|
2020-05-01 03:52:23 +08:00
|
|
|
void (*cancel_item)(struct list_head *item);
|
2018-12-13 00:46:22 +08:00
|
|
|
unsigned int max_items;
|
2016-08-03 09:12:25 +08:00
|
|
|
};
|
|
|
|
|
2018-12-13 00:46:22 +08:00
|
|
|
extern const struct xfs_defer_op_type xfs_bmap_update_defer_type;
|
|
|
|
extern const struct xfs_defer_op_type xfs_refcount_update_defer_type;
|
|
|
|
extern const struct xfs_defer_op_type xfs_rmap_update_defer_type;
|
|
|
|
extern const struct xfs_defer_op_type xfs_extent_free_defer_type;
|
|
|
|
extern const struct xfs_defer_op_type xfs_agfl_free_defer_type;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
/*
|
|
|
|
* This structure enables a dfops user to detach the chain of deferred
|
|
|
|
* operations from a transaction so that they can be continued later.
|
|
|
|
*/
|
|
|
|
struct xfs_defer_capture {
|
|
|
|
/* List of other capture structures. */
|
|
|
|
struct list_head dfc_list;
|
|
|
|
|
|
|
|
/* Deferred ops state saved from the transaction. */
|
|
|
|
struct list_head dfc_dfops;
|
|
|
|
unsigned int dfc_tpflags;
|
2020-09-26 08:39:49 +08:00
|
|
|
|
|
|
|
/* Block reservations for the data and rt devices. */
|
|
|
|
unsigned int dfc_blkres;
|
|
|
|
unsigned int dfc_rtxres;
|
2020-09-26 08:39:50 +08:00
|
|
|
|
|
|
|
/* Log reservation saved from the transaction. */
|
|
|
|
unsigned int dfc_logres;
|
2020-09-26 08:39:51 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* An inode reference that must be maintained to complete the deferred
|
|
|
|
* work.
|
|
|
|
*/
|
|
|
|
struct xfs_inode *dfc_capture_ip;
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
};
|
|
|
|
|
2020-09-22 00:15:09 +08:00
|
|
|
/*
|
|
|
|
* Functions to capture a chain of deferred operations and continue them later.
|
|
|
|
* This doesn't normally happen except log recovery.
|
|
|
|
*/
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
int xfs_defer_ops_capture_and_commit(struct xfs_trans *tp,
|
2020-09-26 08:39:51 +08:00
|
|
|
struct xfs_inode *capture_ip, struct list_head *capture_list);
|
|
|
|
void xfs_defer_ops_continue(struct xfs_defer_capture *d, struct xfs_trans *tp,
|
|
|
|
struct xfs_inode **captured_ipp);
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
void xfs_defer_ops_release(struct xfs_mount *mp, struct xfs_defer_capture *d);
|
2020-09-22 00:15:09 +08:00
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
#endif /* __XFS_DEFER_H__ */
|