zio_add_child: collapse into a single function

[robn]

Motivation and Context

In my work I'm often hooking up different things to zios, and changing in both places is easy to miss. The only difference is the locking, and that's easy enough to handle with a boolean.

Description

Make zio_add_child_impl(), with a boolean_t first arg, and make the existing functions wrap it.

This inverts the lock order just to make the code more readable: the "lock/unlock unless first" conditional becomes a simple two-liner wrapping the guts.

How Has This Been Tested?

Very lightly sanity checked.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

The unification is fine. I was just thinking whether it could make sent to mark zio_add_child_impl() with inline. But I am not so sure you can change lock order that easily. It might need a deeper look to avoid LORs.

[robn]

Yeah, I was thinking about the locks a bit more this morning, and everywhere else takes parent first, so there does seem like a chance.

I did it that way to try and keep the parent lock scoped as narrowly as possible, since I guessed you did it for a reason. If not, then it's less of an issue I think. Last push is the "easy" version, lmk.

[amotin]

In zio_remove_child() we take parent lock first too. So if invert, then both. Even if they likely never conflict in practice, different order made me nervous. But I worry whether we may somewhere recurse with lock held or doing something else like it. I'd be happy to reduce the scope, since those function quite actively appear in profiles for some reason, but it just needs some care and possibly taking some risk.

[robn]

@amotin I agree, makes me nervous too, and I hadn't thought very hard (just a little). I would prefer not change function in what's supposed to be a readability patch. So I'm happy to drop it if you think it will slow us down, or revisit it if it comes up again in profiling. A BIG REMINDER COMMENT to update both places might be good enough.