From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 44BE5899 for ; Thu, 29 Jun 2017 17:52:54 +0000 (UTC) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4CA1DA4 for ; Thu, 29 Jun 2017 17:52:53 +0000 (UTC) Received: by mail-io0-f175.google.com with SMTP id h64so11438655iod.0 for ; Thu, 29 Jun 2017 10:52:53 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <1498758126.2834.70.camel@HansenPartnership.com> References: <1498754169.2834.61.camel@HansenPartnership.com> <1498758126.2834.70.camel@HansenPartnership.com> From: Kees Cook Date: Thu, 29 Jun 2017 10:52:51 -0700 Message-ID: To: James Bottomley Content-Type: text/plain; charset="UTF-8" Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Developing across multiple areas of the kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jun 29, 2017 at 10:42 AM, James Bottomley wrote: > On Thu, 2017-06-29 at 09:51 -0700, Kees Cook wrote: >> On Thu, Jun 29, 2017 at 9:36 AM, James Bottomley >> wrote: >> > >> > On Wed, 2017-06-28 at 16:01 -0700, Kees Cook wrote: >> > > >> > > For refcount_t, the conversions have been going per-maintainer, >> > > and while this is likely the right way to do things, there are >> > > dependencies that are crossing releases, which seems inefficient. >> > > For example, obviously doing a refcount_t conversion requires the >> > > refcount_t implementation first (which landed in v4.11), but then >> > > later conversions wanted an option for a light implementation >> > > (expected for v4.13), but in both cases most maintainers wanted >> > > the implementations entirely landed, not just in -next (vast >> > > majority of refcount_t conversions currently in the kernel landed >> > > in v4.12, so the next wave will have to wait until v4.14 it >> > > seems). This appears mostly to be about avoiding tree >> > > dependencies, IIUC, but is an awfully slow way to do things. >> > >> > Given the performance concerns of the first implementation, this >> > timetable and the interactions that went with it seem to be pretty >> > much textbook correct, especially as none of the hot paths seemed >> > susceptible to overflow attacks. >> > >> > Any other way would have produced a lot more friction: imagine if >> > it had been done tree at once for 4.12 and then performance had >> > tanked and we'd got reversions all over the place ... you'd be >> > spending a lot more than a couple of kernel releases trying to >> > persuade maintainers to take the new improved stuff. >> >> Right, I've got no objection to the performance concerns and how that >> played out, but it's API-to-conversion steps that seem inefficient. >> E.g., instead of API 1 in v4.11, conversion wave 1 in v4.12, API 2 in >> v4.13, conversion wave 2 in v4.14, it looks like tree dependencies >> was the only reason we couldn't have had: API 1 and conversion wave 1 >> in v4.11, API 2 and conversion wave 2 in v4.12 (e.g. btrfs couldn't >> compile their tree with the API living in tip, so they had to wait >> until the API was in a release). > > Well don't discount tree merge problems, having seen a few caused by > API plus conversion all at once. However, by putting them through the > maintainer trees you got the review that would otherwise have been > missing which highlighted the performance concerns. Even this time > around the affected trees have a whole merge window to run performance > regressions to verify everything is OK. Based on this I think the rule > should be API in release R - 1 and conversion in release R through the > affected trees with the only exception being changes that are trivial > enough (for some value of trivial). I'd argue that's what -next is for, but we lack a way to have people base their trees on -next sanely. Regardless, I will commence beer-crying. :) -Kees -- Kees Cook Pixel Security