Seems ok, thank you. I included a couple of suggestions.

Is it a use-after-free? Looks like a plain NULL pointer dereference. (I guess KASAN will flag those as KASAN violations, but it looks like a non-KASAN kernel would hit this too.)

Initialize the sysctl to 1 as well.

In D44906#1023898, @rmacklem wrote:

In D44906#1023894, @olce wrote:

In D44906#1023893, @markj wrote:

Oh hmm, not unrelated, but at a glance I think it is superseded by the privport check. That is, all code paths which lead there first have to go through the privport check. But I could be wrong about this.

It feels like NFS_REQRSVPORT is older but apparently it was introduced by the same (initial) commit as the if (nfs_privport ... check (9ec7b004d0edb). Maybe replacing NFS_REQRSVPORT by a runtime check for nfs_privport would make sense, but I don't really know this code. It may be instead that the code under NFS_REQRSVPORT is redundant, I'm not sure either. In any case, this would be a separate change.

Wow, this one is embarrassing... 25+ years ago I was using OpenBSD for various things and
put this code in (OpenBSD didn't have a port# check). Then, 25 years ago, I did the first
rendition of NFSv4 starting from that OpenBSD code. The comment comes from the fact
that the NFSv4 working group was anti-reserved port# in those days.

It's cruft that has never been built for FreeBSD. I can get rid of it (or Mark can).

Looks good to me overall.

In D44906#1023891, @olce wrote:

There's also NFS_REQRSVPORT, but it is unrelated I guess?

In D44906#1023888, @bz wrote:

In D44906#1023886, @emaste wrote:

Should we change the in-kernel default as well? It will normally be overridden by the rc.conf setting so it doesn't have a practical impact but probably good for consistency.

Would NFS Root be affected by that? Hmm it's a tunable so less of a problem in case people do have trouble.

In D44904#1023722, @asomers wrote:

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

I was planning to follow up with a new tip in fortune(6) and at https://wiki.freebsd.org/ZFSTuningGuide . Do you think that would be sufficient or would you like geli(8) too?

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

Nice, looks good.

I would point out in the commit message that, before your commits, CAPFAIL was basically never used, so users are very unlikely to notice the change in defaults.

Any feedback from DTrace? I would like to commit this soon.

Looks reasonable to me.

BTW, you could add

In D44740#1019798, @andrew wrote:

It looks like the icache handling is missing after writing the brk instruction. I think this could be done from userspace as VPIPT i-cache has been removed from the architecture [1].

[1] https://lore.kernel.org/linux-arm-kernel/b9198f61-c3d1-462b-9cff-0342e26d9ba9@arm.com/T/

Some folks are also opening bugzilla reports that just link to a github PR.

However, snd_unit_init() is called unconditionally upon sound(4) load in dsp_sysinit(), so the KASSERTs will never fail.

In D44825#1022248, @bapt wrote:

<grumpy>I am personnally not sure of the usefulness of this file (why not the same for ht.st, codeberg, gitlab etc?</grumpy>

Fix Andrew's ID