From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Roland Dreier <roland@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit@lists.linux.dev
Subject: Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
Date: Tue, 20 Jul 2021 18:26:02 +0200 [thread overview]
Message-ID: <CAKMK7uHQyJTHA9V=MwZ4XjQOidsE6KKhJsijoQBKZ9hFUcCQtA@mail.gmail.com> (raw)
In-Reply-To: <YIH+Tu7I1pctKSXj@pendragon.ideasonboard.com>
Since I've just made myself popular again with the drivers/gpu merge
criteria I figured good time to dig this out from the big thread as a
separate topic. I entirely missed this interesting topic which was
unfortunately deeply burried in something I don't care a whole lot about
:-)
On Fri, Apr 23, 2021 at 12:53 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> On Fri, Apr 23, 2021 at 12:35:02AM +0200, Thomas Gleixner wrote:
> > On Thu, Apr 22 2021 at 18:03, Al Viro wrote:
> > > On Thu, Apr 22, 2021 at 06:59:48AM +0100, Christoph Hellwig wrote:
> > >> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > >> > I also think there does need to be a strong sanction against this UMN
> > >> > research group, since we need to make sure there are strong incentives
> > >> > against wasting everyone's time with stunts like this. Hopefully on
> > >> > the academic side it can be made clear that this is not ethical
> > >> > research - for example, why did IEEE think this was an acceptable
> > >> > paper?
> > >>
> > >> I wholeheartedly disagree. Demonstrating this kind of "attack" has
> > >> been long overdue, and kicked off a very important discussion. Even
> > >> more so as in this area malice is almost indistinguishable from normal
> > >> incompetence. I think they deserve a medel of honor.
> > >
> > > Demonstrating this kind of attack would be very useful, if they bothered to
> > > provide the raw data and their protocol.
> > >
> > > They'd done neither, AFAICS. There's no way to actually look at how the
> > > submissions went, timings, etc. We are offered what could (very generously)
> > > be called aggregate stats illustrating the problems, along with bloody
> > > worthless suggestions of improvements. Use of the technics in question
> > > is not limited to introducing UAF bugs; it's certainly possible to use
> > > a (real or not) UAF bug as an excuse to get in something designed _not_
> > > to be caught by any of their suggested scler^Whardening patches, etc.
> > >
> > > There certainly are very real problems with review process, and examining
> > > their data might provide useful insights - had any of that data been
> > > given.
> >
> > I agree.
> >
> > Though the most important takeaway for me is that this demonstrated the
> > problems which the kernel development has - once more.
> >
> > What's worse is that it's known for quite some time that the kernel
> > development is understaffed and cannot keep up with the influx of
> > patches. Of course this has been willfully ignored - similar to other
> > completely avoidable horrors like the ssl disaster.
> >
> > There is a long list of issues which lead to that situation, but let me
> > pick a few really important ones:
> >
> > - The 'features and performance first, correctness maybe' mentality in
> > this industry.
> >
> > - The ignorance which takes the availability and sustainability of
> > FOSS components especially "low-level plumbing" ones for granted,
> > even if their business is built on and depends on these.
> >
> > - The unwillingness to put money on basic "low-level" technology just
> > because it does not come with the 'hype-of-the-day' tag and is
> > therefore useless for marketing and headlines.
> >
> > None of these things can be solved at the technical level. There is no
> > technical solution which solves problems at the human stupidity and
> > even less so at the greed level.
> >
> > While in theory the approach of sharing the workload for base technology
> > is obviously the right thing to do, the reality tells that sharing is
> > interpreted as make sure that someone else pays for it and I can push my
> > feature agenda.
>
> I'd like to point out explicitly that this issue isn't limited to
> "low-level" or "core" technology. On the driver side, it feels more
> often than not that the community is used as a dumping ground for BSP
> core of dubious quality, when that code isn't just kept out-of-tree
> altogether. I wouldn't necessarily blame greed in all cases, as I've
> seen vendors who are willing to do the right thing but don't know what
> it would be (what we take for granted as being obvious seems not to be
> so for a large number of people who are not all stupid :-)).
>
> While I may not be fully convinced by all the details of the experiment,
> I think there's something to be learnt from how DRM/KMS handles
> contributors, and how they've managed to get many contributors from the
> industry to get and stay involved at the subsystem level in the longer
> term. I'm sure there can be other initiatives I'm not aware of.
I'm not sure our commit rights stuff helps a lot with getting vendors in.
It helps maybe with load-balancing the maintainer/review roles better
among volunteers and anyone who can cut away a bit of time here and there
to help out with subsystem stuff.
> > As long as that does not change, nothing will change.
> >
> > We can put technical countermeasures (as discussed elsewhere in this
> > thread) in place as much as we want, they are just futile attempts which
> > try to cure the symptoms.
> >
> > As technical people we all know how useful the approach of curing the
> > symptoms instead of the root cause is. But still we try to do that
> > because we think it's our only option.
> >
> > It's about time to rethink that approach.
>
> Amen. Incentives to contribute in the right way need to be higher, and
> depending on the vendors, this can be carrot, stick, or both.
So much.
Now as much as it's unpopular, the drivers/gpu merge criteria of
"userspace must be open source and ready for merging into relevant
upstream userspace project" is a really big stick here. It keeps all the
dump&run vendor contributions out, and any company that seriously
considers this path will spend a few years building up a team (which means
hiring existing people and consulting companies for training and ramp-up)
or just pay for the work to get done. Because tossing your entire
userspace space and creating a new one based on our upstream stack is not
a light undertaking at all for a gpu driver.
The downside is that there's a continual stream of "if you'd just merge
more gpu drivers it would be so much better for you and help get vendors
on board" style complaints, but I don't buy that. We'd definitely get more
code (some 10x for the same functionality), and it would be a lot more
crap. Plus, there'd be a lot less money floating around to pay for
maintainance and improvement of the shared code and infrastructure.
It is more or less flat out extortion, but then nothing else seems to
avoid the tragedy of the commons.
I guess the plus side is that it's not extortion by a single entity that
holds the keys to the castle, but it's collective. If a vendor shows up
with a dump&run proposal they can talk to all the various maintainers we
have and try to enlist all the various consulting shops active in this
area, and the answer tends to be the same across the board.
Overall I think to make sure a subsystem is somewhat sustainable you need
a really big stick to force vendors to contribute in the right
(sustainable) way. The important part is to make sure the stick isn't just
bureaucracy to make it painful for everyone, so that you still have a
carrot left for the people who do get it and want to contribute properly.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-07-20 16:26 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
2021-04-21 18:46 ` Christian Borntraeger
2021-04-21 18:51 ` Alexey Dobriyan
2021-04-21 18:53 ` Christian Borntraeger
2021-04-21 19:06 ` Al Viro
2021-04-21 19:14 ` James Bottomley
2021-04-21 19:22 ` Steven Rostedt
2021-04-21 19:26 ` Kees Cook
2021-04-21 19:32 ` Roland Dreier
2021-04-21 19:55 ` Julia Lawall
2021-04-21 20:28 ` Stephen Hemminger
2021-04-21 20:37 ` Julia Lawall
2021-04-21 20:45 ` Steven Rostedt
2021-04-21 20:50 ` Julia Lawall
2021-04-21 21:03 ` Jiri Kosina
2021-04-21 21:37 ` James Morris
2021-04-22 7:34 ` Geert Uytterhoeven
2021-04-22 7:51 ` Mike Rapoport
2021-04-22 8:45 ` Christian Brauner
2021-04-22 15:27 ` Steven Rostedt
2021-04-22 9:39 ` Mauro Carvalho Chehab
2021-04-22 9:55 ` Mauro Carvalho Chehab
2021-04-22 12:01 ` Leon Romanovsky
2021-04-22 12:26 ` Mark Brown
2021-04-22 12:35 ` Leon Romanovsky
2021-04-22 12:52 ` Hans Verkuil
2021-04-22 13:33 ` Mauro Carvalho Chehab
2021-04-22 13:42 ` Leon Romanovsky
2021-04-22 12:18 ` Leon Romanovsky
2021-04-22 15:38 ` Shuah Khan
2021-04-23 9:06 ` Mauro Carvalho Chehab
2021-04-23 17:17 ` Leon Romanovsky
2021-04-23 22:41 ` Shuah Khan
2021-04-22 5:59 ` Christoph Hellwig
2021-04-22 6:28 ` Tomasz Figa
2021-04-22 7:05 ` Al Viro
2021-04-22 7:46 ` Al Viro
2021-04-22 7:06 ` H. Peter Anvin
2021-04-22 7:05 ` Jiri Kosina
2021-04-22 16:05 ` Roland Dreier
2021-04-22 16:24 ` Krzysztof Kozlowski
2021-04-22 18:03 ` Al Viro
2021-04-22 22:35 ` Thomas Gleixner
2021-04-22 22:53 ` Laurent Pinchart
2021-07-20 16:26 ` Daniel Vetter [this message]
2021-04-21 19:30 ` Jiri Kosina
2021-04-21 20:28 ` Jiri Kosina
2021-04-21 22:18 ` Shuah Khan
2021-04-21 23:17 ` Guenter Roeck
2021-04-21 23:21 ` Shuah Khan
2021-04-21 19:47 ` Dan Carpenter
2021-04-22 9:34 ` Mauro Carvalho Chehab
2021-04-22 9:59 ` Johannes Berg
2021-04-22 10:52 ` Mauro Carvalho Chehab
2021-04-22 12:16 ` Mike Rapoport
2021-04-22 13:41 ` Mauro Carvalho Chehab
2021-04-22 20:15 ` Alexandre Belloni
2021-04-23 0:09 ` Randy Dunlap
2021-04-21 19:49 ` Alexandre Belloni
2021-04-22 2:05 ` Martin K. Petersen
2021-04-22 3:04 ` Joe Perches
2021-04-22 10:13 ` Mauro Carvalho Chehab
2021-04-22 12:07 ` Mark Brown
2021-04-22 16:42 ` Bart Van Assche
2021-04-22 17:58 ` Jiri Kosina
2021-04-22 4:21 ` Leon Romanovsky
2021-04-22 4:56 ` Al Viro
2021-04-22 5:52 ` Leon Romanovsky
2021-04-22 6:05 ` Christoph Hellwig
2021-04-22 6:03 ` Christoph Hellwig
2021-04-22 6:18 ` Leon Romanovsky
2021-04-22 9:20 ` Mauro Carvalho Chehab
2021-04-22 11:34 ` Leon Romanovsky
2021-04-22 13:22 ` Mark Brown
2021-04-22 13:47 ` Leon Romanovsky
2021-04-22 13:51 ` Mark Brown
2021-04-22 14:12 ` Mauro Carvalho Chehab
2021-04-22 14:51 ` Leon Romanovsky
2021-04-22 13:29 ` Steven Rostedt
2021-04-22 13:58 ` Leon Romanovsky
2021-04-22 14:20 ` Rob Herring
2021-04-23 6:04 ` Mauro Carvalho Chehab
2021-04-23 6:46 ` Joe Perches
2021-04-23 7:13 ` Mauro Carvalho Chehab
2021-04-23 7:20 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
2021-04-23 7:20 ` Mauro Carvalho Chehab
2021-04-23 14:52 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
2021-04-23 16:03 ` Mark Brown
2021-04-23 17:12 ` Leon Romanovsky
2021-04-26 23:50 ` Simon Glass
2021-04-22 12:53 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
2021-04-22 13:08 ` Leon Romanovsky
2021-04-22 13:27 ` Konstantin Ryabitsev
2021-04-22 13:41 ` Leon Romanovsky
2021-04-22 16:28 ` Serge E. Hallyn
2021-04-22 17:56 ` Leon Romanovsky
2021-04-22 18:05 ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
2021-04-22 18:51 ` Leon Romanovsky
2021-04-25 10:58 ` Leon Romanovsky
2021-04-23 7:19 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
2021-04-23 7:31 ` Christian Brauner
2021-04-23 18:50 ` Konstantin Ryabitsev
2021-04-22 12:40 ` Mark Brown
2021-04-22 12:54 ` Mike Rapoport
2021-04-22 13:23 ` Mark Brown
2021-04-22 15:19 ` Steven Rostedt
2021-04-22 21:19 ` Thomas Gleixner
2021-04-22 21:36 ` Steven Rostedt
2021-04-22 22:39 ` Thomas Gleixner
2021-04-23 0:26 ` Joe Perches
2021-04-23 6:15 ` Greg KH
2021-04-23 6:50 ` Dan Williams
2021-04-23 7:13 ` Geert Uytterhoeven
2021-04-23 14:41 ` Shuah Khan
2021-04-23 9:12 ` Michal Hocko
2021-04-22 14:51 ` Laurent Pinchart
2021-04-22 15:14 ` Mike Rapoport
2021-04-22 15:17 ` Laurent Pinchart
2021-04-22 15:35 ` Al Viro
2021-04-22 15:32 ` Shuah Khan
2021-04-22 10:35 ` Mauro Carvalho Chehab
2021-04-22 11:03 ` Sudip Mukherjee
2021-04-22 14:00 ` Steven Rostedt
2021-04-22 14:07 ` Jiri Kosina
2021-04-22 15:31 ` Sudip Mukherjee
2021-04-22 21:33 ` Thomas Gleixner
2021-04-22 20:28 ` Andrew Morton
2021-04-22 20:46 ` Steven Rostedt
2021-04-22 12:32 ` Martin K. Petersen
2021-04-22 15:11 ` Laurent Pinchart
2021-04-22 15:28 ` James Bottomley
2021-04-22 15:35 ` Johannes Berg
2021-04-22 15:36 ` Mark Brown
2021-04-22 15:40 ` James Bottomley
2021-04-23 9:27 ` Dan Carpenter
2021-04-22 13:24 ` Konstantin Ryabitsev
2021-04-22 14:31 ` Mauro Carvalho Chehab
2021-04-22 15:34 ` Shuah Khan
2021-04-22 15:42 ` James Bottomley
2021-04-22 15:48 ` James Bottomley
2021-04-22 15:52 ` Steven Rostedt
2021-04-22 16:08 ` Shuah Khan
2021-04-22 16:13 ` Jan Kara
2021-04-22 17:04 ` Steven Rostedt
2021-04-22 17:08 ` Martin K. Petersen
2021-04-23 11:16 ` Jan Kara
2021-04-23 12:57 ` Mauro Carvalho Chehab
2021-04-23 7:58 ` Mauro Carvalho Chehab
2021-04-23 10:54 ` Greg KH
2021-04-23 17:09 ` Leon Romanovsky
2021-04-22 16:23 ` Konstantin Ryabitsev
2021-04-22 16:38 ` Bart Van Assche
2021-04-22 16:57 ` Leon Romanovsky
2021-04-22 18:03 ` Jiri Kosina
2021-04-22 21:26 ` Thomas Gleixner
2021-04-22 21:36 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKMK7uHQyJTHA9V=MwZ4XjQOidsE6KKhJsijoQBKZ9hFUcCQtA@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=James.Bottomley@hansenpartnership.com \
--cc=hch@infradead.org \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=roland@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.