Remove mention of the SSTC extension

Fix error return

Fetch the IP header using m_copydata() instead of using mtod() to select policy/SA.

This looks like it does what it's supposed to do.

In D48265#1100756, @kib wrote:

In D48265#1100743, @markj wrote:

I wonder why exactly software ipsec cannot process unmapped mbufs. In an unmapped ktls packet, the protocol headers are still mapped. netipsec needs to access the payload in order to encrypt, but it uses opencrypto's cursor abstraction, and crypto_cursor_* handles unmapped mbufs. What is missing?

Basically, I wonder if we can side-step the problem by making netipsec compatible with unmapped mbufs.

Well, it started with PR 272616. There m_unshare uses memcpy() not being adopted for the unmapped buffers.

I think my patch moves the code in the right direction, and is the useful first step. For now, it avoids the cost of re-mapping incurred for all packets just if ipsec.ko is loaded. Also, it:

• handles incompatibility/panic/UB between ipsec and ktls
• should improve offloaded ipsec because packets are kept unmapped there.

I wonder why exactly software ipsec cannot process unmapped mbufs. In an unmapped ktls packet, the protocol headers are still mapped. netipsec needs to access the payload in order to encrypt, but it uses opencrypto's cursor abstraction, and crypto_cursor_* handles unmapped mbufs. What is missing?

In D48241#1100375, @aokblast wrote:

Another consumer of rendezvous will be the raw socket over serial console that I have implemented a couple months ago. I haven't implement the wait operation on raw socket serial console. I would like to confirm the interface of rendezvous before I implement it.

In D48254#1100415, @glebius wrote:

Don't have expertise to review, but thanks a lot for working on that. Was following your discussion with Dmitry. I hit this problem many many times, when running a different mix of modules on FreeBSD CURRENT and never bothered to understand it. Always resorted to recompile a static kernel.

Only compare names if we have them.

In D48251#1100319, @emaste wrote:

Any chance you could turn this into a regression test case?

I've been looking at makefs regression tests, in particular as a prerequisite for a more holistic rewrite of makefs's cd9660 pathname logic. The approach taken by the existing tests isn't great for these sorts of tests (it mounts the created image and relies on the kernel's iso9660 support). We could add tests that require cdrtools to be present, but my (longer-term) preference is to add a (probably lua-based) iso9660 dumper.

In D48251#1100313, @emaste wrote:

Example from PR283238:

$ mkdir -p test9660/this-is-a-directory-with-a-long-common-prefix-1 test9660/this-is-a-directory-with-a-long-common-prefix-2
$ makefs -t cd9660 -o rockridge test.iso test9660/
$ isoinfo -p -i test.iso
Setting input-charset to 'UTF-8' from locale.
Path table starts at block 18, size 86
   1:    1 14 
   2:    1 15 THIS_IS_A_DIRECTORY_WITH_A_LON
   3:    1 16 THIS_IS_A_DIRECTORY_WITH_A_LON

With this:

$ isoinfo -p -i test.iso
Setting input-charset to 'UTF-8' from locale.
Path table starts at block 18, size 90
   1:    1 14 
   2:    1 15 THIS_IS_A_DIRECTORY_WITH_A_LON0
   3:    1 16 THIS_IS_A_DIRECTORY_WITH_A_LONG

Are there any other potential consumers of this interface, besides rfb? I see the comment that mentions why gdb can't participate, which is a bit unsatisfying but okay.

Handle the possibility of duplicate forwarding addresses.

In D48032#1096297, @dev_submerge.ch wrote:

In D48032#1096268, @christos wrote:

In D48032#1095744, @dev_submerge.ch wrote:

If you want to make your function equal to the macro in terms of performance, you have to call it with literal format parameters somehow. E.g. through a switch on the format parameters.

I do not have a benchmark right now to prove the opposite, but do you think such a performance hit is noticeable, if at all existent? Currently we use a function pointer to a specialized function (i.e one for each format), and the patch uses a generic function which fetches the format directly from the struct. I am not really well-versed with compiler optimizations, but I would suppose that the generic one is more likely to be inlined, and thus give us a performance boost (I did see the comment about CPU-branch prediction in D47932).

The function pointer prevents inlining, alright. But inlining your generic function doesn't help to optimize the inner loops in feed_eq_biquad() that dominate here. The macro did that.

The main rationale behind this patch, as well as the other similar ones, is to make the code cleaner and easier to work with. There had been a few times already where I tried to make some changes to these files (especially with AFMT_FLOAT support) and the macros make it quite tedious. Even though D47932 fixes most of what I wanted, I still think it's good to have clean code everywhere.

I'm not telling you to go back to macros. All you need is a switch on the format parameter, in a dispatch function between the caller and feed_eq_biquad(). Something like:

switch(info->fmt) {
/* Cases you want to optimize for. */
case AFMT_S16_NE:
        feed_eq_biquad(..., ..., ..., AFMT_S16_NE);
        break;
case AFMT_S32_NE:
        feed_eq_biquad(..., ..., ..., AFMT_S32_NE);
        break;
/* Generic fallback, less optimized. */
default:
        feed_eq_biquad(..., ..., ..., info->fmt);
        break;
}

In D48163#1098579, @zlei wrote:

I thinks that is a general question, that is, does a firewall want to see all known invalid packets? For example, the above logic to check IN_LOOPBACK on the wire.

In D47842#1090897, @jhb wrote:

The thing that makes this a bit odd in terms of the memory limit is that userspace isn't the one requesting to wire the memory. The kernel does by calling sysctl_wire_old_buffer in an individual handler. It would be nice to be smarter about this, e.g. don't acquire the lock until sysctl_wire_old_buffer is actually called? OTOH, one might ask why we really need the lock at all? I guess the worry is that userspace can DOS the kernel by making lots of requests with large buffers for nodes that are known to use sysctl_wire_old_buffer?

In D48163#1098248, @glebius wrote:

On second thought this probably needs to be mentioned in Relnotes and not MFC-ed. Cause it might be that somebody was relying on the stack to drop those packets before firewall.

I'm sorry for the delayed follow-up. I'm trying to understand the purpose of the roundup. It appears to have been introduced by commit daf6545e6158f; the implication seems to be that some drivers depend on the property that "the relative alignment of two consecutive bytes in the I/O stream have a difference of 1 even if they are not physically contiguous."

In D47953#1094057, @vegeta_tuxpowered.net wrote:

Improve the situation a bit: force logging if state creation fails.
This isn't totally right as we'll end up logging the packet twice in
this case, but it's better than not logging the drop at all.

This seems more like a workaround than a fix of underlying design issues. Since I'm responsible for the mess of pf_rule_actions and match rules, I might be able to propose an alternative solution. Can you wait a few days?

In D48150#1098165, @kib wrote:

In D48150#1098161, @markj wrote:

Suppose a filesystem has MNT_NOSUID set, and contains a setuid root executable. If I create a nullfs mount of that filesystem and run the executable though nullfs, should the suid bit be honoured? I would expect not, but it is. In particular, MNT_NOSUID is not copied to the upper mount, and the code which checks MNT_NOSUID does not use a VOP, it just checks vp->v_mount->mnt_flags.

This is the current behavior, before or after the change, and in fact it is not that weird. Imagine that instead of nullfs, the lower fs is exported and mounted by nfs. The result is same.

In D48150#1098159, @kib wrote:

In D48150#1098146, @markj wrote:

When lower fs acts according to its mount configuration, it is reported up as VOP errors.

I do not quite understand what you mean here.

I mean that mnt_flags from lower fs do not need to be propagated to upper fs to make the mount operate correctly. Lower fs flags are checked when bypass calls lower VOP. So there is no need to 'fake' mnt_flags for upper fs, and esp. to fake it for only reporting to user in statfs(2).

When lower fs acts according to its mount configuration, it is reported up as VOP errors.

The current verbiage does need improvement.

If you mail me git format-patch output or submit it on github, I'll apply it.

Set PR_VNET earlier, so that prison_deref() won't leak the VNET if an
error occurs during jail initialization.

My comments are just suggestions/quibbling.

In D47992#1097201, @jamie wrote:

In D47992#1097186, @markj wrote:

The new PR_VNET_ROOT flag is unneeded: it's equivalent to PR_VNET, just check
that instead.

Not quite, I'm afraid. This is true once a prison has been created, but errors during the creation process can break that. pr_vnet is set when a new jail is created, but the flags are not actually set until after some parameter checking and other error opportunities. Chances are, this just requires setting the prison's PR_VNET flag at the same time the vnet is created (still saving other flags for later).

Revert unintended style change.

The new PR_VNET_ROOT flag is unneeded: it's equivalent to PR_VNET, just check
that instead.

In D48058#1096826, @mhorne wrote:

I have no objection to the current revision, although we can say a few things about how the code may look/change in the future.

Obviously, the feature-to-ISA-string code will continue to expand/balloon, as we will want to advertise the availability of the many unprivileged ISA extensions to the guest as well.

The problem is that we have no mechanism for reporting extension presence from the kernel to userspace, therefore you are using vm_cap_type here. I am working on something "official" for this, most likely it will be a sysarch exporting a bitmap, with bit definitions compatible to what can be found in Linux. Therefore one call can obtain the full set of supported extensions (sanitized), and we will be able to use this in bhyve to construct the ISA string for the guest.

So I don't think we will need to rely on vm_cap_type in the long run. We also don't need to be precious about the ABI, given the experimental state of RISC-V vmm and hypervisor hardware, and since I intend for this extension reporting stuff to be resolved before the release of 15.0. So this VM_CAP_SSTC can easily be removed later.