Incorporated feedback.

No longer necessary.

The ZFS bits look good, just one question about the change in zfs_freebsd_bmap.

Thanks for the upstream PR @rlibby

Sorry I didn't get a chance to review this in time. Thank you for updating to 436ab35a5. I share the concern about our diff against upstream.

The asserts are working fine when building OpenZFS out of tree, so how is it that this is needed in tree?

Thank you for catching this. The version strings look reasonable to me.

Address feedback

I'm not familiar with how the symbol map works, but you've got the generated functions in there so that's good.

@jhb Thanks for the heads up. It's working as intended in other cases but clearly not in this case. I'm looking into it.

Thanks!

Upload the correct diff

Use cap_netdb

I'll second Scott's three suggested changes.

VFS_QUOTACTL(9) shows it as caddr_t, so I suppose that needs to be fixed as well.

I like that deciding what action to take at the current node is able to be split out into its own function. I don't find sysctl_sysctl_next_node to be a properly descriptive name. It kept confusing me that the "next node" function doesn't do what it sounds like. Changing that to something like sysctl_sysctl_next_action and using an enum for the different actions would avoid the confusion. The variable its return value is stored in could be called action instead of ret. Consider for example enum { ITER_STOP, ITER_SIBLINGS, ITER_CHILDREN };.

Something like this?

diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index afe9afb50471..91e411fb023d 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2406,6 +2406,7 @@ do_jail_attach(struct thread *td, struct prison *pr)
 		goto e_unlock;
 #endif
 	VOP_UNLOCK(pr->pr_root);
+	pwd_chdir(td, pr->pr_root);
 	if ((error = pwd_chroot(td, pr->pr_root)))
 		goto e_revert_osd;

When you have the chance, please update these diffs so I can apply them locally for closer inspection.

In D26932#601290, @kevans wrote:

In D26932#601288, @freqlabs wrote:

Curious, why are libifconfig bindings in the stack?

I don't know, that's a bit unusual... it doesn't look like I accidentally slapped any dependency on there (transitively or otherwise), so I'm not really sure since the only connection is that that's also dependent upon the (now-committed) libjail bits.

Curious, why are libifconfig bindings in the stack?