LWN: Comments on "Maintainers Summit topics: pull depth, hardware vulnerabilities, etc."

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

ajdlinux — Mon, 23 Sep 2019 14:46:57 +0000

Stephen is paid to do the linux-next work.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

nevets — Fri, 20 Sep 2019 03:19:35 +0000

> As the discussion is set up, however, it looks like the only thing that's going to cause a change of MO here is reality catching up with the presently broken MO.

Exactly. As the topic is now blacklisted from further Maintainer Summits, the only way it will come back is when a real problem happens. Linus's entire point is "We haven't had an issue yet, so stop worrying about it". We need an issue to happen so that we can then rightfully complain to Linus.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

karim — Fri, 20 Sep 2019 03:13:13 +0000

Yes, I gathered that part as well regarding the kprobes part of the discussion. And that's not just "inconvenient", as is the case for in-kernel tracepoints, but rather downright scary. In fact I'm willing to bet good money this approach is going to come to bite at some point in the future TBD. What happens when such internal code that needed changing contained a bug and there's no way to revert without reintroducing the bug? What if the code had to be obsoleted? etc.

As the discussion is set up, however, it looks like the only thing that's going to cause a change of MO here is reality catching up with the presently broken MO.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

nevets — Fri, 20 Sep 2019 03:04:24 +0000

I guess the best way to describe what Linus said is that they are not an ABI, until they are.

It's even worse now that if a tool can be built on a kprobe (dynamic tracepoint defined by a user, not a kernel developer), and the internal code changes, that, according to Linus, is now an ABI breakage, and the code that changed will be reverted!

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

olof — Thu, 19 Sep 2019 03:28:19 +0000

Hm, maybe I said that Linus needs to roar at other subsystems, but it's not what I intended to say and I'd definitely like to take any such request back.

What I was trying to express was that the ARM cleanups wouldn't have happened unless things ended up reaching a breaking point with dire consequences on the horizon, and that some of the changes that might be beneficial w.r.t. people working closer together across company/subsystem boundaries in other areas might need some external motivation.

I certainly didn't mean to encourage any kind of angry outbursts or yelling at people.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

karim — Thu, 19 Sep 2019 01:19:01 +0000

Tracepoints should not be ABI. Advertising them as such ensures they aren't added to the kernel and gives a false sense of security to user space. Unless, or course, the goal is to minimize in-kernel tracepoints to begin with.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

ndesaulniers — Wed, 18 Sep 2019 03:04:10 +0000

Brounie is helping out this cycle.

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

geofft — Tue, 17 Sep 2019 20:51:21 +0000

Is he working these 16-hour days as a volunteer? Why is nobody else doing it / could other people help out? (I looked for the automation recently but didn't see anything obvious, is it done by hand?)

Should LF be paying him (and others) to do it?

Maintainers Summit topics: pull depth, hardware vulnerabilities, etc.

jgg — Tue, 17 Sep 2019 16:20:19 +0000

It is very worrying that Stephen Rothwell is overloaded, linux-next is incredibly valuable.