Looks ok to me. I'll leave min vs MIN up to you.

Looks ok to me. You can decide whether or not to add the
KASSERT for x_op != XDR_FREE?

Looks fine to me. Feel free to ignore the minor comments.

In D52970#1210155, @cy wrote:

In D52970#1210136, @rmacklem wrote:

Looks fine to me. Is there somewhere that we can stick
examples for krb5.conf, kdc.conf and kadm5.acl?

In share/examples/krb5 maybe?

Looks fine to me. Is there somewhere that we can stick
examples for krb5.conf, kdc.conf and kadm5.acl?

Just fyi. Unless I hear otherwise I am going to commit
this patch Monday, so that it can be MFC'd to stable/15.
It stops rpcbind from crashing. If others don't like the
choice of address string for netlink, that can be changed
later.

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

In D52263#1194959, @olce wrote:

In D52263#1194857, @olce wrote:

So, while I'm here, I'd also like to know what you think about discarding groups exceeding the NGROUPS limit.
(snip)

According to RFC 5531, the authsys_parms structure for AUTH_SYS contains in fact the effective group ID (spelled out exactly like this in the RFC) and then an array of 16 groups "that contain the caller as a member". But we only have XU_NGROUPS (16) in total in struct xucred.

So, what do you think of:

1. To support the protocol, we accept up to 17 groups (1 + 16), but no more (extensions are not supported).
2. But we discard the 17th one, as we don't have room to store it.

This is in fact what the inline decode version is already doing.

I made a few comments, but stopped there.
You seem to be confusing the 16 which is
a hardwired RPC constant with what happens
to be defined elsewhere.
(Even if XU_NGROUPS == 16 there is nothing
stopping someone from changing that someday.)

I'll admit I do not understand what your recent gid
changes are, so I will resign as a reviewer.

Looks fine to me.

In D51845#1184637, @rmacklem wrote:

In D51845#1184634, @markj wrote:

The not so good news is that this bug made it out into 14.3.

I'll submit an EN since this is my bug (unless you'd really like to).

You are more than welcome to do so.
I'll give it a 2week MFC and you'll see it go into stable/14 in two weeks.

Made changes suggested by kib@.

Thanks for the feedback. I'm off doing other things for
a few days, but will update this next weekend.

Reworded to mention copy_file_range.

Looks good to me. Thanks for doing this, rick

In D51808#1184330, @rmacklem wrote:

In D51808#1184315, @rmacklem wrote:

In D51808#1183889, @mav wrote:

In D51808#1183592, @rmacklem wrote:

So, unless you think there is a better answer than
vp->v_mount->mnt_stat.f_iosize,

If it is per-file-system, then this is probably the best you can get.

I think that will work.

I think it may matter only if client decide to clone file in several parts/requests. It may fail if the file appear having its block size bigger than f_iosize. It may be not very often, but possible.

(I will take a look at the block cloning code called from
zfs_copy_file_range() to see what it uses?)

Take a look at the beginning of zfs_clone_range(). It has a number of different constraints.

I did and from what I can see, they are exactly the constraints
that RFC7862 specifies for the NFSv4.2 CLONE operation.
(I suspect this all came from the way Linux does it?)

The one thing I have found is that zfs_clone_range() uses
z_blksz, which varies depending on the file's size.
(It is 512 for small files and 128K for bigger ones, for my
setup. mnt_stat.f_iosize is 128K.)

I am trying to find out if the NFSv4.2 clone_blksize
attribute is considered per-file or per-file-system.

Oh, and I might have found a bug in zfs_copy_file_range().
(It doesn't appear to advance the offsets when presented
as pointers and is not using f_offsets. I'll investigate further.)

The bug is in vn_copy_file_range() and not in the ZFS function.
For the case where the offset arguments are being passed in,
it doesn't update them properly.
I'll work on it, but it is not a bug in the ZFS code.

rick

This is getting interesting, rick

In D51845#1184634, @markj wrote:

The not so good news is that this bug made it out into 14.3.

I'll submit an EN since this is my bug (unless you'd really like to).

In D51808#1184315, @rmacklem wrote:

In D51808#1183889, @mav wrote:

In D51808#1183592, @rmacklem wrote:

So, unless you think there is a better answer than
vp->v_mount->mnt_stat.f_iosize,

If it is per-file-system, then this is probably the best you can get.

I think that will work.

I think it may matter only if client decide to clone file in several parts/requests. It may fail if the file appear having its block size bigger than f_iosize. It may be not very often, but possible.

(I will take a look at the block cloning code called from
zfs_copy_file_range() to see what it uses?)

Take a look at the beginning of zfs_clone_range(). It has a number of different constraints.

I did and from what I can see, they are exactly the constraints
that RFC7862 specifies for the NFSv4.2 CLONE operation.
(I suspect this all came from the way Linux does it?)

The one thing I have found is that zfs_clone_range() uses
z_blksz, which varies depending on the file's size.
(It is 512 for small files and 128K for bigger ones, for my
setup. mnt_stat.f_iosize is 128K.)

I am trying to find out if the NFSv4.2 clone_blksize
attribute is considered per-file or per-file-system.

Oh, and I might have found a bug in zfs_copy_file_range().
(It doesn't appear to advance the offsets when presented
as pointers and is not using f_offsets. I'll investigate further.)

The bug is in vn_copy_file_range() and not in the ZFS function.
For the case where the offset arguments are being passed in,
it doesn't update them properly.
I'll work on it, but it is not a bug in the ZFS code.

In D51808#1183889, @mav wrote:

In D51808#1183592, @rmacklem wrote:

So, unless you think there is a better answer than
vp->v_mount->mnt_stat.f_iosize,

If it is per-file-system, then this is probably the best you can get.

I think that will work.

I think it may matter only if client decide to clone file in several parts/requests. It may fail if the file appear having its block size bigger than f_iosize. It may be not very often, but possible.

(I will take a look at the block cloning code called from
zfs_copy_file_range() to see what it uses?)

Take a look at the beginning of zfs_clone_range(). It has a number of different constraints.

Thanks for doing this. I was going to start looking at this
to-day, but I'm glad to see you've done it.

In D51808#1183580, @mav wrote:

The kernel had a ZFS patch that set _PC_CLONE_BLKSIZE correctly.

I am not sure what you mean with "correctly", but for a note, in ZFS different files might have different block sizes if created (grown beyond one block) during recordsize property was set to different values, or if the file is smaller than recordsize. Also the last block is predictably more flexible, but also with some limitations.

In D51808#1183472, @asomers wrote:

In D51808#1183471, @rmacklem wrote:

In D51808#1183460, @asomers wrote:

Here's a stupid question. Is it possible for nfsd to reexport an NFS mountpoint? If so, then nfs_copy_file_range will need to check the flag, too.

Not a stupid question. Linux allows this and they have endless bugs to deal
with because of it. FreeBSD does not and I hope to keep it that way.

Should we add the check anyway, just in case we ever add the FIONBCLONE (or whatever it's called) ioctl for userspace processes to use?

In D51808#1183460, @asomers wrote:

Here's a stupid question. Is it possible for nfsd to reexport an NFS mountpoint? If so, then nfs_copy_file_range will need to check the flag, too.

Added check to fuse_copy_file_range() as pointed
out by asomers@.

In D51808#1183453, @asomers wrote:

Shouldn't there also be some ZFS code that returns ENOSYS if the cloning requirement cannot be satisfied? And fuse_vnop_copy_file_range cannot ever satisfy that requirement, so it should return ENOSYS just like in vn_generic_copy_file_range