On 2/24/21 8:04 AM, Brian Foster wrote:
On Thu, Feb 18, 2021 at 09:53:33AM -0700, Allison Henderson wrote:
This patch separates the first half of xfs_attr_node_addname into a
helper function xfs_attr_node_addname_find_attr. It also replaces the
restart goto with with an EAGAIN return code driven by a loop in the
calling function. This looks odd now, but will clean up nicly once we
introduce the state machine. It will also enable hoisting the last
state out of xfs_attr_node_addname with out having to plumb in a "done"
parameter to know if we need to move to the next state or not.
Signed-off-by: Allison Henderson <allison.henderson@xxxxxxxxxx>
---
fs/xfs/libxfs/xfs_attr.c | 80 ++++++++++++++++++++++++++++++------------------
1 file changed, 51 insertions(+), 29 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
index bee8d3fb..4333b61 100644
--- a/fs/xfs/libxfs/xfs_attr.c
+++ b/fs/xfs/libxfs/xfs_attr.c
...
@@ -941,6 +931,38 @@ xfs_attr_node_addname(
args->rmtvaluelen = 0;
}
+ return 0;
+out:
Nit: can we call this label 'error' since it appears to be used when we
want to return the current retval as an operational error?
Sure, will change out
+ if (*state)
+ xfs_da_state_free(*state);
+ return retval;
+}
+
+/*
+ * Add a name to a Btree-format attribute list.
+ *
+ * This will involve walking down the Btree, and may involve splitting
+ * leaf nodes and even splitting intermediate nodes up to and including
+ * the root node (a special case of an intermediate node).
+ *
+ * "Remote" attribute values confuse the issue and atomic rename operations
+ * add a whole extra layer of confusion on top of that.
+ */
+STATIC int
+xfs_attr_node_addname(
+ struct xfs_da_args *args,
+ struct xfs_da_state *state)
+{
+ struct xfs_da_state_blk *blk;
+ struct xfs_inode *dp;
+ int retval, error;
+
+ trace_xfs_attr_node_addname(args);
This moves the tracepoint into the looping sequence whereas previously
it would only execute once. I don't see a clean way to fix that with the
breakdown as of this patch, and it's not a huge deal, but it would be
nice to fix that before the end of the series if we haven't already.
Otherwise LGTM:
I see, I could hoist it out, but it is short lived really. Once we get
into the state machine it wont much matter if it's hoisted or not. In
the greater scheme of things, I think it makes more sense for it to stay
where it is. A lot of these patches are not particularly elegant during
this refactoring phase, and then things sort of come together once the
state machine gets here.
Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
Thank you!
Allison
+
+ dp = args->dp;
+ blk = &state->path.blk[state->path.active-1];
+ ASSERT(blk->magic == XFS_ATTR_LEAF_MAGIC);
+
retval = xfs_attr3_leaf_add(blk->bp, state->args);
if (retval == -ENOSPC) {
if (state->path.active == 1) {
@@ -966,7 +988,7 @@ xfs_attr_node_addname(
if (error)
goto out;
- goto restart;
+ return -EAGAIN;
}
/*
--
2.7.4
