linux-kernel - Re: [GIT]: Networking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0809031703480.3515@nehalem.linux-foundation.org>
Date:	Wed, 3 Sep 2008 17:18:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
cc:	David Miller <davem@...emloft.net>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"tomasw@...il.com" <tomasw@...il.com>,
	"yi.zhu@...el.com" <yi.zhu@...el.com>,
	"linville@...driver.com" <linville@...driver.com>
Subject: Re: [GIT]: Networking

On Wed, 3 Sep 2008, Luis R. Rodriguez wrote:
> 
> What I think really happens here IMHO is communication needs to be
> enhanced. I only recently noticed that "regression only" policy for
> 2.6.27 for example. I think some of us were rather surprised by it too.

It's really not a "2.6.27" policy, it's always been a "merge window" vs 
"-rc" policy. It's just that I've started making more noise about it, 
since many people don't seem to see what the point of the merge window is.

And no, the problem isn't new either. But it does seem to have been 
getting somewhat worse lately. Possibly simply because we have more code 
(ie releases have grown, which has made the problem more visible, even if 
it hasn't necessarily changed in any other way).

> Before snapping at people for not following "orders" we need a clear
> guideline for what should or not be sent.

The basic rule really should be:

 - *any* new development should target the merge window. 

   I think some of the driver people in particular have been mislead by 
   the fact that we have actually accepted new drivers even after the 
   merge window ("they can't regress"), and that in turn has probably 
   de-sensitized people a bit to the whole merge window.

   Similarly, drivers (and other wholly self-contained modules like 
   filesystems etc) that didn't exist before - even if they were then
   merged _during_ the merge window - have also been getting leeway in the 
   -rc code, since again they cannot regress.

And it really does appear like a lot of driver people just get very comfy 
and used to that _first_ release, when we allow almost anything. And then 
they just continue with it.

> To avoid it I do think another exception needs to be made for patches:
> 
> * Small fixes which make something that was not working, which was
>   supposed to work work

Not really.

The thing is, if it's a driver that has been around for more than a single 
release, then those "small fixes" really can't be worth all that much. And 
yes, they may be small, and yes, they may be "obvious", but the fact is, 
they definitely can regress.

Sure, if some driver really haven't been around for very long, I can see 
your point. Not very many people have used it, and I can well imagine that 
there are lots of those "small fixes" that really do matter.

but if the driver has been in active use for a few kernel versions, there 
really is almost no excuse to say "this fix is so important that it needs 
to go in even though it's not a regression/security/oops fix".

So I would agree that the very first release a new driver (or filesystem) 
is in is special. Almost anything goes during the -rc releases leading up 
to that. And yes, I can well imagine that during the -rc for the second 
release it perhaps makes sense to be a _bit_ more relaxed, simply because 
it's young and as more people use it, silly (but serious) issues can just 
become more obvious.

But in the long run? No. Drivers are not different from any other code, 
and the -rc rules should be "regressions only".

In fact, in many ways we should be even _more_ careful with drivers than 
with most other things, because driver changes are seldom "obvious". Even 
really trivial stuff can interact with hardware in odd ways, in ways that 
is seldom true of normal code that you can think about and analyze (since 
we assume that the CPU itself doesn't have subtle timing etc bugs, of 
course).

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/