The check wasn't done with sufficient locking anyway. IMHO, when everything gets right in this area of the network stack, we will no longer need this flag.

Well, you cannot just declare timeout(1) is compliant with (or even is expected to conform to) the POSIX.1-2024 Standard without actually updating it.
Actually, the current version has several behaviors (e.g., signal catching, signal propagation) that don't comply with the Standard.

In D15865#1126562, @editor_callfortesting.org wrote:

From the Jails Production User call: This work is still of interest, particularly in the context of OCI jail progress.
DCH: "This needs serious rebasing." Do any developers have interest in this feature?

• Document descriptions are part of titles and should not have crossreferences, this breaks with a wontfix in many implementations, like apropos
• We almost always put "driver" at the end throughout the entire kernel interfaces manual, and consistent apropos results are a big fit and finish polish
• Gpio is already in there from GPIO_MUTE
• The date format is standard and errors on the linter
• The copyright line comes before the SPDX tag per style(9), it's really hard to fix this stuff later and I have to do it often because $dayjob says that I can work on foss but it has to have a standard, valid foss license. Which is also why I love spdx tags because I can't get in trouble over a typo.
• The Roff language asks one sentence per line

This revision is rebased on top of https://reviews.freebsd.org/D49411.

Added all reviewers of D37139

update from bz

updates from bz

update from bz

In D49393#1126517, @adrian wrote:

In D49393#1126451, @bz wrote:

Your description for the commit message is very misleading (*); I read it thrice in the hope to understand what you mean. Trying to paraphrase:

Reject a key for a cipher suite [forcefully (given it is not announced as supported)] set by user space (i.e., wpa_supplicant) although it is not set as supported in software crypto or device driver hardware crypto at all.

Which makes me wonder: I do not believe that we can do any hardware crypto without any software support so the code for setting ic_cryptocaps should enforce that the crypto suite is also set in ic_sw_cryptocaps (that implies an order of setting -- or given we have a default rely on that). Also the code for setting ic_sw_cryptocaps should check that we actually have an implementation ...

Ah! Ok, the software support is for software encryption/decryption, not /support/ per se.

Thanks a lot Joe!

In D46656#1126578, @emaste wrote:

It looks like <= PAGE_SIZE would indeed be correct

In D49163#1126058, @kib wrote:

In D49163#1125281, @jhb wrote:

Thanks a bunch of for doing this. This is one of the features I've wanted for a long time as a useful tool to understand what a process might be waiting on. The other thing I would love to have in this vein are a way to see the file descriptors that a thread blocked in select/poll is waiting on (and the specific poll flags for each fd). For that case you could use the existing open file descriptor sysctl/core dump note to get details about each fd, you would just need the list of <fd, poll flags> tuples.

Isn't this information easily available from the memory dump already? Both for poll and select, the syscalls take the set of fds explicitly, so all that is needed is to look up their arg array or bitmaps.

In D49402#1126581, @jrm wrote:

In D49402#1126472, @michaelo wrote:

@jrm, yes of course, it simply worked in poudriere. Did forget to bump the revision.

In D49402#1126478, @michaelo wrote:

I don't know who represents maintainer apache@FreeBSD.org, but I guess I have to give the potential maintainers two weeks of time for this.

It's a mailing list [0] so proceed as you see fit.

[0] https://lists.freebsd.org/subscription/freebsd-apache

In D49398#1126583, @emaste wrote:

I think this is fine. backticks and checkyesno moving are minor improvements (arguably not bugs).

I think the problem could also be fixed with [ "$(echo ${MODULE_DIR}/*.ko)" != "${MODULE_DIR}/*.ko" ] if we want to continue avoiding the extra process invocation. Is there a PR for it?

I think this is fine. backticks and checkyesno moving are minor improvements (arguably not bugs).

In D49402#1126472, @michaelo wrote:

@jrm, yes of course, it simply worked in poudriere. Did forget to bump the revision.