Hi everybody,
ftp, ping, IP forwarding, IP masquerading etc., in short: everything having to
do with networking is broken using kernel 2.6.29.
My thousand thanks for that again go to Mr. David S. Miller, kernel
contributor of the netdev section, who again and again is adding his SOB under
untested crap code that itself breaks networking hardware by reaching the
kernel mainline via git patches.
In the past exactly that happened again and again, and it is particularly Mr.
David S. Miller himself who, proven by facts, is not willing to learn to stay
away from sending in malicious code via the git path.
I am really wondering why Linus Torvalds is still trusting him, as it is a
fact that not everybody can send in code just like that, i. e. without
restrictions.
It cost me almost 1 complete day (and again I do state that this is not the
first time that some unqualified hacker operating with the responsibility of Mr.
David S. Miller deeply sucks and steals my nerves and wastes my time) to find
out that the following patch needs to be reverted to make networking services
in 2.6.29 final available again for everybody.
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2588,9 +2588,9 @@ static int process_backlog(struct napi_struct *napi, int
quota)
local_irq_disable();
skb = __skb_dequeue(&queue->input_pkt_queue);
if (!skb) {
- __napi_complete(napi);
local_irq_enable();
- break;
+ napi_complete(napi);
+ goto out;
}
local_irq_enable();
@@ -2599,6 +2599,7 @@ static int process_backlog(struct napi_struct *napi, int
quota)
napi_gro_flush(napi);
+out:
return work;
}
@@ -2671,7 +2672,7 @@ void netif_napi_del(struct napi_struct *napi)
struct sk_buff *skb, *next;
list_del_init(&napi->dev_list);
- kfree(napi->skb);
+ kfree_skb(napi->skb);
for (skb = napi->gro_list; skb; skb = next) {
next = skb->next;
Best wishes
Uwe
> 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 ?
Alan Cox a ?crit :
>> 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 ?
This guy had his life depending on linux-2.6.29 apparently, and failed
to read netdev or lkml. Go figure...
It sounds like a troll, dont you think ?
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?
On 03/24/2009 07:50 PM, Eric Dumazet wrote:
> Alan Cox a écrit :
>> 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 ?
>
> This guy had his life depending on linux-2.6.29 apparently, and failed
> to read netdev or lkml. Go figure...
>
> It sounds like a troll, dont you think ?
Sounds like Uwe Bugla to me.
Niel
From: sinter <[email protected]>
Date: Tue, 24 Mar 2009 19:18:29 +0100
> Who needs a maintainer adding his SOB with closed eyes under untested crap
> code? Who needs someone like that for kernel development?
Hey Uwe, nothing interesting going on in your life so you have to make
other people miserable?
This patch was tested, and it made a bug reporter's kernel crash go
away.
We'll fix the problems we're seeing now, just like we always do.
* sinter <[email protected]> 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
* sinter <[email protected]> wrote:
> > 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.
>
> And what top-class advice would you give me if I would have found
> that serious bug in .29.8 or in .29.9? Due to your answer every
> shit is possible and nothing is impossible, or did I get something
> wrong?
You got it exactly right.
This world is ruled by probabilities, and generally everything is
possible - even a bug slipping into a .0 release that you could
trigger personally, even though -rc1 through -rc8 worked just fine
for you.
Such things happened before, and they can happen again. Yes, it can
hit you - and it did hit me too and i'm not complaining.
We still try our best to reduce the probabilities. We cannot,
however, unfortunately, bring them down to zero. The fix looked
reasonable and the justification of it fixing a live crash looked
reasonable too.
What we can do, and what we did do, was to provide people (you
included) with a fix within 12 hours after the code having been
released.
That's the deal really.
Ingo
* Niel Lambrechts <[email protected]> wrote:
> > It sounds like a troll, dont you think ?
>
> Sounds like Uwe Bugla to me.
It's him for sure, his gmx authentication gave him away.
--
left blank, right bald