On Tue, 10 Dec 2019 12:46:29 +0100, Maciej Żenczykowski wrote:

quoted

Okay, that's what I was suspecting.  It'd be great if the real
motivation for a patch was spelled out in the commit message :/  

It is, but the commit message is already extremely long.

Long, yet it doesn't mention the _real_ reason for the patch.

At some point essays and discussions belong in email and not in the
commit message.

Ugh just admit you didn't mention the primary use case in the commit
log, and we can move on.

Here's another use case:

A network where firewall policy or network behaviour blocks all
traffic using specific ports.

I've seen generic firewalls that unconditionally drop all BGP or SMTP
port traffic, or all traffic on ports 5060/5061 (regardless of
direction) or on 25/53/80/123/443/853/3128/8000/8080/8088/8888
(usually due to some ill guided security policies against sip or open
proxies or xxx). If you happen to use port XXXX as your source port
your connection just hangs (packets are blackholed).

Sure you can argue the network is broken, but in the real world you
often can't fix it... Go try and convince your ISP that they should
only drop inbound connections to port 8000, but not outgoing
connections from port 8000 - you'll go crazy before you find someone
who even understands what you're talking about - and even if you find
such a person, they'll probably be too busy to change things - and
even though it might be a 1 letter change (port -> dport) - it still
might take months of testing and rollout before it's fully deployed.

I've seen networks where specific ports are automatically classified
as super high priority (network control) so you don't want anything
using these ports without very good reason (common for BGP for
example, or for encap schemes).

Or a specific port number being reserved by GUE or other udp encap
schemes and thus unsafe to use for generic traffic (because the
network or even the kernel itself might for example auto decapsulate
it [via tc ebpf for example], or parse the interior of the packet for
flowhashing purposes...).

[I'll take this opportunity to point out that due to poor flow hashing
behaviour GRE is basically unusable at scale (not to mention poorly
extensible), and thus GUE and other UDP encap schemes are taking over]

Or you might want to forward udp port 4500 from your external IP to a
dedicated ipsec box or some hardware offload engine... etc.

It's networking you can concoct a scenario to justify anything.

quoted

So some SoCs which run non-vanilla kernels require hacks to steal
ports from the networking stack for use by proprietary firmware.
I don't see how merging this patch benefits the community.  

I think you're failing to account for the fact that the majority of
Linux users are Android users - there's around 2.5 billion Android
phones in the wild... - but perhaps you don't consider your users (or
Android?) to be part of your community?

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? Some companies care about upstream, and those should be rewarded
by us taking some of the maintenance off their hands. Some don't:
https://www.youtube.com/watch?v=_36yNWw_07g (link to Linus+nVidia video) 
even tho they sell majority of SoCs for 2.5 billion devices.

btw. Chrome OS is also Linux based (and if a quick google search is to
be believed, about 1/7th of the linux desktop/laptop share), but since
it supports running Android apps, it needs to have all Android
specific generic kernel changes...

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
(I can think of a few other networking patches off the top of my head
where we've been unable to upstream them for no particularly good
reason).

The way to get those patches upstream is to have a honest discussion
about the use case so people can validate the design. Not by sending
a patch with a 5 page commit message which fails to clearly state the
motivation for the feature :/