Re: git: cb7009867ae6 - main - socket: Restore handling of IPPROTO_DIVERT

On Tue, Aug 25, 2026 at 03:37:51PM -0400, Mark Johnston wrote:
M> > I'm not happy with this change.  I know that I'm slow on reacting on reviews,
M> > but for this one you didn't give me a week to say anything.
M> 
M> In December you wrote this email:
M> https://lists.freebsd.org/archives/dev-commits-src-main/2025-December/038370.html
M> 
M> Specifically:
M> 
M> 	I'm fine with prolonging existence of the shim until python 3.11
M> 	goes out of support, which is 2027-10.
M> 
M> I took this to mean that you were tacitly ok with restoring the shim, at
M> least for now, given that 2027-10 is more than a year away.

Right, if this is considered a temporary thing, then I'm fine.  The question is
when this code is going away from GENERIC? 2027 is fine by me. Even 2030 is fine
by me. I just don't want to see this forever.

M> > I did a lot of work to discover and upstream all applications in the ports that
M> > use divert(4) to properly use PF_DIVERT.
M> > 
M> > I worked with python to adopt PF_DIVERT and I also fixed the getaddrlen()
M> > there, too.  See https://github.com/python/cpython/pull/142993
M> > 
M> > I addressed all python scripts in the tests to properly use PF_DIVERT.
M> > 
M> > Unfortunately python is very slow with accepting changes and our ports are very
M> > slow with adopting newer python versions.  However, the bugfix can be easily
M> > added to python312 port as a patch.
M> > 
M> > Now with this change we will have extra check for every socket(2) syscall to
M> > satisfy a very small number of installations, who are ether willing to run
M> > FreeBSD 16 with outdated python either with proper version of python, but are
M> > unwilling to apply a trivial change to their script.  Can you estimate number
M> > of this installations?
M> 
M> Of course I cannot, nor can you estimate the number of applications
M> silently broken by the original change.  The ports tree does not contain
M> everything that runs on FreeBSD.
M> 
M> Python is just an example, I used it to justify this change because it
M> has bitten me multiple times since you removed this check.  It seems
M> quite plausible that there are other divert sockets applications out
M> that are simply broken now.

Since my opponents can't provide even 1 application, and I'm not able to
prove that there are 0 applications, this whole discussion becomes close
to discussion if the God exists or not.  Neither side is able to prove.
However, in our case both sides agree that number of users/systems that
may face the problem is extremely small.  So, on one hand we have a kernel
that is run by all FreeBSD users and all of them will execute extra useless
check on every socket(2) syscall.  On the other hand are potentially affected
users with old binaries.  In my opinion the number of the latter is so miniscule
that they can actually do something to fix their systems, rather than require
the rest of FreeBSD users to carry and run extra code.  With something I
mean recompilation of their programs, or in case if sources are indeed lost,
just LD_PRELOAD a tuny shim that would workaround the socket(2) syscall.
I can provide the sources for the shim.

M> In general I believe we try quite hard to make old binaries continue to
M> work on FreeBSD.  It's a very useful feature.  That is why e.g.,
M> sendfile() still has a COMPAT_FREEBSD4 shim.  Is it important to remove
M> that too?  If not, then what's different about socket()?

In my opinion we should remove COMPAT_FREEBSD4 from GENERIC at some point.
And in my opinion is that today is probably not too early, maybe even long
due to do that.

The other differencies with sendfile(2) are that the API is definitely much
more used than a divert socket, and what's more important is that the
sendfile(2) itself is a heavy syscall, so a single comparison won't have
a measureable effect.

-- 
Gleb Smirnoff