[Ksummit-discuss] [MAINTAINERS SUMMIT] Developing across multiple areas of the kernel

[Kees Cook]

On Thu, Jun 29, 2017 at 9:36 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> 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).

-Kees

-- 
Kees Cook
Pixel Security