linux-kernel - Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

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: <200609200056.57858.rjw@sisk.pl>
Date:	Wed, 20 Sep 2006 00:56:57 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Greg KH <greg@...ah.com>
Cc:	David Miller <davem@...emloft.net>, akpm@...l.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

On Wednesday, 20 September 2006 00:30, Greg KH wrote:
> On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > From: "Rafael J. Wysocki" <rjw@...k.pl>
> > Date: Wed, 20 Sep 2006 00:06:52 +0200
> > 
> > > I _guess_ the problem is caused by
> > > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > > because the kernel (obviously) doesn't compile if I revert it.
> > 
> > Indeed.
> > 
> > I thought we threw this patch out because we knew it would cause
> > problems for existing systems?  I do remember Greg making an argument
> > as to why we needed the change, but that doesn't make breaking people's
> > systems legitimate in any way.
> 
> It's now thrown out, and I think Andrew already had a patch in his tree
> that reverted this.
> 
> I'll be bringing it back eventually, but first we are going to work out
> all the kinks by probably putting these changes in the next few SuSE
> alpha releases to see what shakes out in userspace that we need to go
> fix.
> 
> It's not 2.6.19 material at all, so don't worry :)

Please note, however, that by including such changes in -mm we make _other_
things be not tested.

For example, if I can't install a new kernel and use it on my system without
replacing some other pieces of software, I just won't be using it, because I
have no time for playing with udev, hal, powersaved, acpid, ...
Then, if there are any bugs in it that would have shown up on my system,
we won't know about them unless they show up on someone else's system,
which may not happen.

The more changes that break existing setups are there in -mm, the less
people will acutally try to use -mm kernels and that will result in buggier
-rc kernels and more bugs propagating to the "stable" ones.  Do we really
want that to happen?

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller
-
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/