Skip zvol snapshot extents in iscsi.extent.pool_import
## Problem
iSCSI extents can be backed by a read-only zvol snapshot. `pool_import` passed those paths to `zfs.resource.list_impl`, which rejects any path containing `@`, so the `pool.post_import` hook failed and volthreading was never turned off for any zvol extent on the imported pool (including at boot).
## Solution
Leave snapshot paths out of the query, the same way extent create/update/delete already do. Snapshots don't have a volthreading property, so there is nothing to set on them anyway.
(cherry picked from commit 90d53b596bff4564e30ae07d8dc8df14b256eb9a)
NAS-144411 / 28.0.0-BETA.1 / Skip zvol snapshot extents in iscsi.extent.pool_import (#19986)
## Problem
iSCSI extents can be backed by a read-only zvol snapshot. `pool_import`
passed those paths to `zfs.resource.list_impl`, which rejects any path
containing `@`, so the `pool.post_import` hook failed and volthreading
was never turned off for any zvol extent on the imported pool (including
at boot).
## Solution
Leave snapshot paths out of the query, the same way extent
create/update/delete already do. Snapshots don't have a volthreading
property, so there is nothing to set on them anyway.
[llubi] Don't ignore address taken by assume-like intrinsics (#230938)
The function pointer used by `llvm.assume` is still evaluated.
The test is generated by DeepSeek-V4.1-Flash.
if_gre: Use OID_AUTO for the net.link.gre sysctl node
if_gre(4) registers net.link.gre with the static OID number IFT_TUNNEL.
That number is an interface type that several tunnel drivers share, not
one that belongs to gre(4). if_me(4) used it too, which made loading
both modules panic until 21f2245de219. Nothing addresses the node by
number, so use OID_AUTO as if_me(4) now does.
Suggested by: markj
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
if_gre: Use OID_AUTO for the net.link.gre sysctl node
if_gre(4) registers net.link.gre with the static OID number IFT_TUNNEL.
That number is an interface type that several tunnel drivers share, not
one that belongs to gre(4). if_me(4) used it too, which made loading
both modules panic until 21f2245de219. Nothing addresses the node by
number, so use OID_AUTO as if_me(4) now does.
Suggested by: markj
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
mail/tarpitd: Add new port
tarpitd answers SMTP connections and holds them open for as long as the peer
can be persuaded to wait. It is meant to sit behind a packet filter rule that
redirects known spam sources to it, in the manner of spamd(8) on OpenBSD, and
it never accepts or delivers anything.
Every reply is a syntactically valid SMTP response, so the sender has no reason
to give up, but it is written out one byte at a time and commands are read back
at the same rate. Every terminal answer is a temporary failure, so the message
stays in the sender's queue and it comes back later to be tarpitted again. The
intent is to occupy a slot in the sending botnet's delivery queue for hours
rather than to reject mail quickly.
Among its tactics are a delayed and optionally endless multiline greeting,
detection of clients that transmit before the greeting has finished, padding of
the EHLO response, a STARTTLS handshake that never completes, an AUTH honeypot
that decodes and logs the credentials bots offer, and clamped socket buffers so
the peer's window stays tiny.
[7 lines not shown]
mail/tarpitd: Add new port
tarpitd answers SMTP connections and holds them open for as long as the peer
can be persuaded to wait. It is meant to sit behind a packet filter rule that
redirects known spam sources to it, in the manner of spamd(8) on OpenBSD, and
it never accepts or delivers anything.
Every reply is a syntactically valid SMTP response, so the sender has no reason
to give up, but it is written out one byte at a time and commands are read back
at the same rate. Every terminal answer is a temporary failure, so the message
stays in the sender's queue and it comes back later to be tarpitted again. The
intent is to occupy a slot in the sending botnet's delivery queue for hours
rather than to reject mail quickly.
Among its tactics are a delayed and optionally endless multiline greeting,
detection of clients that transmit before the greeting has finished, padding of
the EHLO response, a STARTTLS handshake that never completes, an AUTH honeypot
that decodes and logs the credentials bots offer, and clamped socket buffers so
the peer's window stays tiny.
[7 lines not shown]
15.2: release documents checked
The initial content from 15.1 release docs included:
installation.adoc moved to upgrading.adoc
relnotes.adoc header refers to upgrading.adoc
i386 arch removed from readme.adoc
Approved by: re (implicit)
Differential Revision: https://reviews.freebsd.org/D60612
devel/srell: Update 2026.05 => 2026.07
* Add hint to portscout(1) to help it discover new upstream versions
by pointing it to exact site:URL [1] with download directory listing,
as just generic one [0] strangely returns HTTP 403 error.
* Limit PORTSCOUT versions by following strict upstream YYYY.MM scheme.
[0] https://www.akenotsuki.com/misc/srell/releases/
[1] https://www.akenotsuki.com/misc/srell/releases/?C=M;O=D
net/norm: Bump PORTEPOCH to fix package version ordering
The previous version format (1.5r6) was incorrectly evaluated
by 'pkg version' as greater than the newer version (1.5.9).
Bump PORTEPOCH to force a proper upgrade path for existing installations.
net/norm: Bump PORTEPOCH to fix package version ordering
The previous version format (1.5r6) was incorrectly evaluated
by 'pkg version' as greater than the newer version (1.5.9).
Bump PORTEPOCH to force a proper upgrade path for existing installations.
[LAA] Compute MaxBTC * MaxStride in a wide enough type. (#230860)
isSafeDependenceDistance proves independence if |Dist| > MaxBTC *
MaxStride. The original code did not account for MaxBTC * MaxStride
wrapping, e.g. if either has a narrow type.
Fix by computing the product in the wider of the types of the distance
and MaxBTC, zero-extending MaxBTC. The distance is sign-extended as
before.
The product can still wrap if MaxBTC is as wide as the distance, e.g. an
unbounded i64 MaxBTC. Requiring it not to wrap regresses existing proofs
for symbolic distances (e.g. PR31098), so that case is left as is for
now.
Add Przemysław Frasunek for his longterm contributions to FreeBSD
This includes work on:
* kqueue related bugs
* multiple advisories
* mail/tarpitd port
PR: 297312
