LWN: Comments on "The 5.6 merge window opens"

The 5.6 merge window opens

cortana — Thu, 27 Feb 2020 09:36:58 +0000

The audit log?

The 5.6 merge window opens

glm — Wed, 12 Feb 2020 12:32:11 +0000

About the "new boot-time parameter (managed_irq)": I don't understand the concept of "managed interrupts". Could you give a short explanation and some examples?

RFC 8229 (TCP Encapsulation for IPsec) support merged

shef — Tue, 11 Feb 2020 02:21:48 +0000

As far as I know some user equipment manufacturers support TLS encapsulation for WiFi calling which is relying on IPsec/IKE by default. Some time back 3GPP defined TLS profiles as a firewall bypass mechanism. Curious if 3GPP will switch back to IPsec/IKE over TCP if it is going to be supported by Android.

The 5.6 merge window opens

mchapman — Fri, 07 Feb 2020 22:51:42 +0000

Uh, setenforce obviously.

The 5.6 merge window opens

mchapman — Fri, 07 Feb 2020 22:41:11 +0000

If I understand the changes correctly, they do not alter the ability to use getenforce to toggle whether SELinux is in enforcing or permissive mode.

The 5.6 merge window opens

ScottMinster — Fri, 07 Feb 2020 12:44:54 +0000

Indeed, just last night I was setting up a new server and things were not working. I suspected that it might be a bad SELinux context on some files. Since temporarily disabling SELinux caused things to start working, that confirmed my suspicions, and I was able to quickly resolve the issue (and then re-enable SELinux).

I can see how being able to disable it on a production server could be a bad thing, as a debugging tool it is nice.

If there was an easier way to determine why a process (like a web server) cannot read a file other than "permission denied" maybe it wouldn't be as big a deal.

The 5.6 merge window opens

Cyberax — Thu, 06 Feb 2020 20:00:46 +0000

> The ability to disable the SELinux security module at run time has been deprecated with an eye toward removing it in a future release. This feature is still used by Fedora and RHEL, but has been left behind by most other distributions. The preferred way to disable SELinux is with the selinux=0 command-line parameter.
Do we need MORE evidence that SELinux was designed by plants from the NSA to subvert Linux security?

The 5.6 merge window opens

NRArnot — Thu, 06 Feb 2020 09:50:55 +0000

Losing runtime disable of selinux will make life far harder for sysadmins.

At present, if something won't work and the reason is not obvious, a simple test is to disable selinux, test again, and re-enable selinux seconds later having established whether or not it's the source of the problem. (On a test machine, not a public-facing server).

Having to reboot to test will be a complete PITA. Especially if the fix is still not obvious and several iterations are required.

RFC 8229 (TCP Encapsulation for IPsec) support merged

josh — Fri, 31 Jan 2020 16:49:46 +0000

I'm hoping that HTTP/3 helps convince the operators of such networks that blocking UDP is a problem.

RFC 8229 (TCP Encapsulation for IPsec) support merged

hailfinger — Fri, 31 Jan 2020 14:30:38 +0000

Support for RFC 8229 (TCP Encapsulation of IKE and IPsec Packets) was also merged in this series of commits:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Cover letter: https://marc.info/?l=linux-netdev&m=157468978806473&...

For some networks, all non-TCP communication to the outside is blocked, so you can neither use UDP encapsulation nor raw ESP to establish an IPsec tunnel. With these patches, you can finally use port 443/TCP to establish an IPsec tunnel. Obviously, tunneling e.g. TCP over TCP has some drawbacks, but at least the option does exist now.

@corbet: Would it be possible to mention this in the article (or a followup) in the network section? Thanks!

Can we stop this?

pbonzini — Fri, 31 Jan 2020 06:57:29 +0000

Not exactly an answer to your question, but you may be interested in this recent article from LWN: https://lwn.net/Articles/810404/

Can we stop this?

sub2LWN — Fri, 31 Jan 2020 00:03:37 +0000

BPF := Banter Prudently, Fellow :-) Glancing at the git log:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

I noticed a recent merge from an LWN repo:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Including "A new document on how to help with documentation" which I assume is Documentation/doc-guide/contributing.rst

I had no idea you are the Documentation maintainer. Which subsystems do you think are improving the most in regards to their documentation? Other than:

https://www.kernel.org/doc/html/latest/process/maintainer...

Hunting around for descriptions of the "merge window" process itself, as a kernel noob, I found this section of "A guide to the Kernel Development Process" comprehensive:

https://www.kernel.org/doc/html/latest/process/2.Process....

Can we stop this?

corbet — Thu, 30 Jan 2020 21:48:12 +0000

This kind of comment is really not helpful to anybody. LWN comments are far better when we're not just tossing random childish insults around; could I ask you (and others!) to please stop doing that?

The 5.6 merge window opens

grober — Thu, 30 Jan 2020 21:20:26 +0000

BPF == Biggest Possible Fuckup.