In D43658#996657, @bz wrote:

In D43658#996222, @cc wrote:

This patch also fixes the wrong/old values used in sys/compat/linuxkpi/common/include/linux/ieee80211.h. thanks

No, this patch ONLY fixes the wrong values there. The fact that they are defined to a native version is cosmetics.

I meant this patch fixes the wrong/old values here, in the LinuxKPI. For example, IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED should have a value 3, not the old 0x02.

Good catch!

This patch also fixes the wrong/old values used in sys/compat/linuxkpi/common/include/linux/ieee80211.h. thanks

I see two "MFC after" in the summary section, and the summary section seems to contain two parts that it looks you are going to split this patch into two when you MFC it. Am I understanding correctly? Are you going to manually MFC the two parts?

By the way, I forgot to ask, is it also helpful to add IEEE80211_LOCK_ASSERT in lkpi_iv_update_bss()?

I think this patch as a fix is targeting 271979#c28. If I am right, I will use the reproduce method to test this patch. thanks

Good catch!

Thanks for reminding me this so that I can make the right change of 93b7818226cf in MFC.

Thanks for the reminder.

Looks good to me now. Thanks for the update.

This is committed in https://cgit.freebsd.org/src/commit/?id=93b7818226cf5270646725805b4a8c17a1ad3761

Sorry, not sure how this is missing in my radar. Please allow one day or two to finish my review.

Tested in Emulab.net. Looks good to me.

code update with successful test

In D42765#979657, @imp wrote:

/rescue/tar is a requirement. What's wrong with that? the whole bug is because someone tried to grab the wrong image to start with and there's going to be way more than just this one detail wrong with the running system.

I think I have tested this method of separating packet processing and free before. But I want to make sure it is performing as expected. I will give my comment after testing.

remove debug echo

code update based on review comment

Add Reviewed by: carlavilla

add reviewer fernape

Assuming the channel input will be supported later, I accept this change.

My understanding too here is that CTLFLAG_NOFETCH is not used, and so is CTLFLAG_NEEDGIANT not needed.

Click the the section of "5. Community Questions" from the "Table of Contents" (in your web page link below) does not jump to that section. Other links from the "Table of Contents" work. Please consider if this requires update.

Please consider resolving the problems in my comments.

In D41894#955747, @asomers wrote:

If the caller provides insufficient space for the entire structure, will the kernel fail the ioctl or copy as much as it can? It looks to me like it will do the latter. That also provides backwards compatibility, as long as we don't move or delete fields. @tuexen do you accept @glebius's suggestion to directly commit to stable/14? I would like to do that because it improves the Rust story. The Rust community still has not accepted that some APIs change between versions, like 64-bit inodes. Pushing the tcp_info compatibility break to FreeBSD 15 instead of 14 will give Rust some more time to come to terms.

Correct a rare case when log_buf is NULL, which is returned by alq_getn().

In D41715#952053, @rscheff wrote:

In D41715#950701, @cc wrote:

Thanks for having a plan to sync-up with rfc9438, which is released recently in Aug 2023 and obsoletes rfc8312.

The jump is from pre-8312 to rfc9438. I will roll at least one update with all the comments changing from 8312bis-draft-15 to rfc9438, but really some regression / performance testing of this patch would be needed. Maybe some servers can run this as patches cc_cubic and statistical data collected (Lawrence may be delighted too ... )

Kindly remind of this change review. No need to rebase.

Thanks for having a plan to sync-up with rfc9438, which is released recently in Aug 2023 and obsoletes rfc8312.

Renew my approval after the re-base.

adds back snprintf() with buffer length check

Also please add an additional test for out of window seq number test:
your existing "with a lower (not acceptable) sequence number is silently ignored", and + "with a higher than window (not acceptable) sequence number is silently ignored"

Also please add an additional test for out of window seq number test:
your existing "with a lower (not acceptable) sequence number is silently ignored", and + "with a higher than window (not acceptable) sequence number is silently ignored"

Would you please elaborate the corresponding specification in RFC5961 and RFC9293?

Thanks for the explanation.

I see. :)

Mentioning r343646 make this review easier. Thanks!