linux-kernel - Re: 3.3.x: e1000 and ixgbe hang

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: <20120509.154558.1469429813580317150.davem@davemloft.net>
Date:	Wed, 09 May 2012 15:45:58 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	wolfgang.walter@...m.de
Cc:	gregkh@...uxfoundation.org, stable@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: 3.3.x: e1000 and ixgbe hang

From: Wolfgang Walter <wolfgang.walter@...m.de>
Date: Wed, 9 May 2012 18:57:13 +0200

> But when we are at it: I think that when a bug in a stable kernel is
> found and the final fix is known it is bad practice to hord that
> patch till submission without letting stable@ know about it.

I think you have no idea what goes into vetting patches for -stable.

It can take me days to put together a series, and also I time my
-stable submissions with when Linus pulls my 'net' bug fixes into his
tree since a part of the -stable requirements is presence in Linus's
tree.

I therefore batch, because bleeding out individual fixes one by one to
-stable rarely, if ever, makes sense.

And another part of what goes into vetting a patch is time.  The
longer a patch sits in a non-stable tree getting tested, the more
likely any unwanted bugs and side effects will be caught before the
patch goes into -stable.

And finally I am under no obligation whatsoever to post some kind of
status report to -stable every few days saying when I'll do this or
that.
--
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/