In D26334#598980, @np wrote:

okay, I'll take care of this.

It seems by now there is also needs_inner_tcp_csum() ?
Can you possibly incorporate this in your next driver update and do it yourself @np ?

Anyone interested in reviewing this? I'd love to get it in no later than Monday.

I have a couple of comments for this:
(a) ICMP access is not just echo requests; this will alllow jails to send other things out which might not be a great idea, so if you do, default off.
(b) I'd love to have an ICMPv6 equivalent; ICMPv6 is even worse as to what people can do; see (a)
(c) I don't think this is a good idea.
(d) Even with this there'll be other issues (as are with raw sockets), such as source address selection, which was once was discussed in 2011 [ https://people.freebsd.org/~bz/20120407-01-ping-source-addr.diff ]; probably on freebsd-net or -jails back then.
(e) lastly we do have full network stacks these days, and even if they are not always needed the tradeoff to adding more hacks on top of classic IP-jails is questionable.

I haven't tried it but scrolling through it looks ok to me.

In D26727#595888, @manu wrote:

In D26727#595874, @bz wrote:

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

See D23085 (Or https://github.com/evadot/freebsd/tree/drm_base_v5.6-20201007 for a more up to date version).

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

• Update comment about ieee80211_add_channel_cbw() now supporting HT40/VHT80/..

• Remove debug printfs from here as well.
• Remove the whitespace from regdomain.

manu, if you are okay with it, either commit it yourself or let me know when so that you can deal with the drm-kmod bits as well

• Rename f_mul to ___lsb as suggested by hselasky.

In D26681#594681, @manu wrote:

Apart from the line break it's fine. No need for a new version; can commit with the change if you want.

Can I ask you to drop this one?

Looks okay to me as well. The two minor things may be ignored.

Use DEVMETHOD_END.
Include subvendor/subdevice as V32 to deal with the -1 wildcard.
Add the bus name to the name filed in the driver_t.

I'd still love to update this so that we can have the full set but I need to find the bug first that prevents this (with the comments) from working. You can still see how this turns out (just with less columns):

Address comments from kib mostly.

I'll wait to see what @manu or others in case of kobject_uevent_env() say and then upload the final diff. Interim version coming in a minute.

Abandon in favour of D26598

While I agree on the counter I am not yet sure I entirely want to lose all these messages.
Some are helpful in that they tell us things. If you are on multiple network as most of my devices are it can become a pain otherwise to retroactively debug.
Given none of them are logged by default (nd6_debug = 0 unless -DND6_DEBUG is used at compile time and nd6.h:#define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) ) can we not just do both?

Rework as suggested by adrian.

In D26554#591413, @adrian wrote:

I'm not a huge fan of this cause honestly we should be doing the epoch enter/exit around a batch.

What I was hoping to do was to create a list of frames from calls to rtwn_rx_frame and then push them up to the stack in a second pass under (a) no lock, avoiding the relock, and (b) being done in NET_EPOCH.

Wanna do that or should I?

We'll probably want to add more of these in the future for vnets, so happy we start to lay the grounds.
Will you work on jail/jail.conf to also pick the right set for devfs depending on whether the vnet option is given? If not you should given @jamie a ping6.

In D26537#591051, @kp wrote:

In D26537#590825, @bz wrote:

Did we ever fix this one?

https://www.openbsd.org/errata48.html
005: SECURITY FIX: December 17, 2010 All architectures
Insufficent initialization of the pf rule structure in the ioctl handler may allow userland to modify kernel memory. By default root privileges are needed to add or modify pf rules.

https://ftp.openbsd.org/pub/OpenBSD/patches/4.8/common/005_pf.patch

I believe you did: https://svnweb.freebsd.org/base?view=revision&revision=302117

This landed by accident in head as https://svnweb.freebsd.org/changeset/base/366112 (not sure why the review wasn't automatically closed either).

Arg. Sorry, used the wrong alias and pushed the change into head instead of here. Please do a post-commit review in head then.

I am mostly interested if the names are okay. I did not want to use _IEEE80211_MS() as that might be confused with some time operation MS_TO_xxx. If the names are okay, I'll wrap the lines and upload a new version for actual review.

Did we ever fix this one?