To reproduce, just kldunload iscsi while iscsid is running. The kldunload will hang in "devdrn" inside of destroy_dev().

My first thought was much closer to Gleb's comment. That is, I think the mistake is probably to be lumping callouts in with other soft interrupts. I think probably what we want is something about like this:

• Add octets stat and move to per queue.

Note that the notes only document changes from the most recent release (in this case 12.2) to 13.0, not 12.0 to 13.0, so some of these aren't relevant. I wonder if the OpenSBI support made it into 12.2? If not, it warrants a mention I think. Hmm, 12.2 did include support for booting via OpenSBI v0.7.

Previously Ed was consistent in suggesting "obsolete" to refer to old GPLv2 toolchain bits.

Looks like GCC 6 supports -Wdate-time so I think you can just add this to CWARNFLAGS.

BTW, confirmed this fixed the error Chelsio's QA was seeing internally.

Altered step in second block to 8.

I'm just waiting to see if the folks who reported this to me can confirm this fixes the issue they were seeing. I've been unable to reproduce it myself locally on my own test boxes. :-/

I would probably instead have changed sbuf_drain() to just return instead of asserting. Asserting made sense when it was a private implementation function, as a public API I think just returning instead of asserting is better behavior.

Is there some more glue in sys/conf we can axe as well? Specifically, all the places that check PROFLEVEL?

Drew had a panic in production where the relevant mbuf had a cipher text payload of 0x1b7 bytes in length. I was able to reproduce with a size of 112 (one full block plus enough of a partial block that the poly1305 hash equaled a second full block). I've tested this fix with both sizes. The following review for cryptocheck expands the sizes covered to handle this case, but it in a slightly more general way.

For GELI I took the strategy of spamming a message each time a new volume was created with a deprecated algorithm via geli init, and a message each time an existing volume created a new provider (so if you booted with 5 GELI volumes and each used a deprecated algorithm, you got 5 warnings IIRC). The geli changes for this were in R10:5c420aae3b18027809507dc9142182d4290897bf. Unlike some other warnings I added for IPsec, I didn't bother with rate limiting.

Have you tried testing it? Maybe try to 'gvinum create' across two memory disks or ZVOLs to see if the warning works? You could maybe then do 'gvinum detach' and 'gvinum attach' to replicate boot-time probing. That is what I did when testing deprecation warnings for GELI algorithms I deprecated for 13. I don't have a good opinion on where the warning should go, and if it works in testing I'm fine with whatever works.

FYI, the best way to indicate dependencies is to setup needed commits as "parent revisions" via "Edit Related Revisions" at the top-right (or use 'git arc' to upload changes together).

Agreed, but that can be a separate review :)

• Fix with RATELIMIT and malloc size.

Should we add a 'gone_in()' call somewhere in the kernel as well, e.g. when creating a new gvinum GEOM provider?

I think this is probably fine. I would probably let the MD hook actually output whatever it wanted instead of requiring it to only do a single name and returning a value. That is I would just use gdb_tx_* directly in the new MD routine and not have the MI gdb_stop_reason intermediary, but I'm fine with it either way.

I should really add a TLS section to cxgbe(4) as well the talks about TOE TLS vs NIC TLS. It's on my todo list, just haven't done it yet :(

I would use "NIC TLS" in a few more messages to be consistent.

• Add alloc/free_ofld_txq() routines.

• Update for alloc/free_txq_ofld().

Generally looks good to me. Nice to have this runtime togglelable now. I assume the minimum FW version we require now supports the new feature?

Hmm, we don't list the leaked resources for any other types so that's a bit inconsistent (e.g. we don't list the address or rid's of BARs).

It's fine with me modulo the nits.