On Mon, Nov 20, 2017 at 12:47:10PM -1000, Linus Torvalds wrote: > Sorry, on mobile right now, thus nasty HTML email.. > > On Nov 20, 2017 09:50, "Matthew Garrett" <mj...@srcf.ucam.org> wrote: > > >> Can you clarify a little with regard to how you'd have liked this >> patchset to look? > > > So I think the actual status of the patches is fairly good with the default > warning. > > But what I'd really like to see is to not have to worry so much about these > hardening things. The last set of user access hardening really was more > painful than it might have been.
Sure, and Kees learned from that experience and added the default fallback in response to it. Let's reward people for learning from past problems rather than screaming at them :) >From a practical perspective this does feel like a completely reasonable request - when changing the semantics of kernel APIs in ways that aren't amenable to automated analysis, doing so in a way that generates warnings rather than triggering breakage is pretty clearly a preferable approach. But these features often start off seeming simple and then devolving into rounds of "ok just one more fix and we'll have everything" and by then it's easy to have lost track of the amount of complexity that's developed as a result. Formalising the Right Way of approaching these problems would possibly help avoid this kind of problem in future - I'll try to write something up for Documentation/process. > And largely due to that I was really dreading pulling this one - and then > with 20+ pulls a day because I really wanted to get everything big merged > before travel, I basically ran out of time. > > Part of that is probably also because the 4.15 merge window actually ended > up bigger than I expected. I was perhaps naive, but I expected that because > of 4.14 being LTS, this release would be smaller (like 4.9 vs 4.10) but > that never happened. > > So where I'd really like to be is simply that these pulls wouldn't be so > nerve wracking for me. And that's largely me worrying about the approach > people are taking, which is why I then reacted so strongly to the whole > "warnings came later". > > Sorry for the strong words. This one seems unfortunate in that a lot of people interpreted it as "Kees submits bad code", and I think that does have an impact on people's enthusiasm for submitting more complex or controversial work. The number of people willing to work on security stuff is limited enough for various reasons, let's try to keep hold of the ones we have! -- Matthew Garrett | mj...@srcf.ucam.org
