Re: [PATCH v2] net: introduce ip_local_unbindable_ports sysctl

On Fri, 13 Dec 2019 09:16:03 +0900, Lorenzo Colitti wrote:

On Wed, Dec 11, 2019 at 2:31 AM Jakub Kicinski wrote:

quoted

I don't consider users of non-vanilla kernels to necessarily be a
reason to merge patches upstream, no. They carry literally millions
of lines of patches out of tree, let them carry this patch, too.
If I can't boot a vanilla kernel on those devices, and clearly there is
no intent by the device manufacturers for me to ever will, why would I
care?  

That's *not* the intent.
https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/

quoted

quoted

The reason Android runs non-vanilla kernels is *because* patches like
this - that make Linux work in the real world - are missing from
vanilla Linux  

That's exactly the point here. Saying, "Android will never use
mainline, so why should mainline take their patches" is a
self-fulfilling prophecy. Obviously, if mainline never takes Android
patches, then yes, Android will never be able to use mainline. We do
have an Android tree we can take this patch into. But we don't want to
take it without at least attempting to get it into mainline first.

The use case here is pretty simple. There are many CPUs in a mobile
phone. The baseband processor ("modem") implements much of the
functionality required by cellular networks, so if you want cellular
voice or data, it needs to be able to talk to the network. For many
reasons (architectural, power conservation, security), the modem needs
to be able to talk directly to the cellular network. This includes,
for example, SIP/RTP media streams that go directly to the audio
hardware, IKE traffic that is sent directly by the modem because only
the modem has the keys, etc. Normally this happens directly on the
cellular interface and Linux/Android is unaware of it. But, when using
wifi calling (which is an IPsec tunnel over wifi to an endpoint inside
the cellular network), the device only has one IPv4 address, and the
baseband processor and the application processor (the CPU that runs
Linux/Android) have to share it. This means that some ports have to be
reserved so that the baseband processor can depend on using them. NAT
cannot be used because the 3GPP standards require protocols that are
not very NAT-friendly, and because the modem needs to be able to
accept unsolicited inbound traffic.

Other than "commit message doesn't have a use case", are there
technical concerns with this patch?

Maybe a minor question or two, but the main complaint is the commit
message.

How are the ports which get reserved communicated between the baseband
and the AP? Is this part of the standard? Is the driver that talks to
the base band in the user space and it knows which ports to reserve
statically? Or does the modem dynamically request ports to
reserve/inform the host of ports in use?

Should the sysfs interface make sure there are not existing sockets
using requested ports which would stop working? If we may need it one
day better add it now..