From: Ingo Molnar <mingo@elte.hu>
To: sinter <sinter.salt@gmx.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org
Subject: Re: BUG in 2.6.29 final: broken network connection
Date: Tue, 24 Mar 2009 20:42:54 +0100 [thread overview]
Message-ID: <20090324194254.GB26930@elte.hu> (raw)
In-Reply-To: <200903241918.29929.sinter.salt@gmx.de>
* sinter <sinter.salt@gmx.de> wrote:
> Am Dienstag 24 März 2009 18:25:03 schrieben Sie:
> > > It cost me almost 1 complete day
> >
> > Wouldn't it have been simpler to wait when you found a problem and read
> > Ingo's email on the subject from a few hours ago ?
>
> Wouldn't it be simpler to restrictively avoid crap code in final
> kernel versions? And if that does not work by appeal shouldn't the
> netdev maintainer simply be substituted?
>
> Who needs a maintainer adding his SOB with closed eyes under
> untested crap code? Who needs someone like that for kernel
> development?
Nonsense. 303c6a0 "gro: Fix legacy path napi_complete crash" was an
obvious looking bug fix for a real crash that was reported, against
a commit that went upstream in 2.6.29-rc1.
It was a fix for a serious regression and i'd have applied it too,
and would have pushed it to Linus.
Furthermore, even on affected systems it took certain configs and
certain conditions for the bug to trigger under high load. So there
was no real good way to find this bug quickly.
Such kind of bugs can happen anytime, to any maintainer. Unless we
100% freeze the kernel for a full month before release, this risk
simply cannot be avoided. It is far more problematic if maintainers
dont push known fixes or ignore fixes. The networking tree is
exemplary in picking up fixes addressing bug reports quickly. A
proposed fix was posted 33 minutes after i sent my bugreport.
Things breaking is simply the nature of software changes - get used
to it. When new software with 1 million lines of changes over the
previous version comes out, dont jump on it immediately, if your
peace of mind depends on a 100% working system. Only try it if you
want to help out developing it.
And there's an easy solution for you in any case: you can wait for
.29.1 which i'm sure will be out quickly.
Thanks,
Ingo
next parent reply other threads:[~2009-03-24 19:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200903241812.14577.sinter.salt@gmx.de>
[not found] ` <20090324172503.1627a3ef@lxorguk.ukuu.org.uk>
[not found] ` <200903241918.29929.sinter.salt@gmx.de>
2009-03-24 19:42 ` Ingo Molnar [this message]
[not found] ` <200903242149.59640.sinter.salt@gmx.de>
2009-03-24 21:45 ` BUG in 2.6.29 final: broken network connection Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090324194254.GB26930@elte.hu \
--to=mingo@elte.hu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sinter.salt@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).