From: "Svenning Sørensen" <sss@secomea.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: guard against coalescing packets from buggy network drivers
Date: Fri, 25 Apr 2014 21:32:27 +0200 [thread overview]
Message-ID: <535AB84B.20207@secomea.com> (raw)
In-Reply-To: <1398444575.29914.93.camel@edumazet-glaptop2.roam.corp.google.com>
On 25-04-2014 18:49, Eric Dumazet wrote:
> On Fri, 2014-04-25 at 18:01 +0200, Svenning Sørensen wrote:
>
>> You are right, of course, there are more effective ways to catch buggy
>> drivers.
>> But they will probably also be much more expensive.
>> This one is very cheap, being in a relatively cold path, especially
>> compared to the memcpy in the same path.
> It seems you missed the recent tipc thread then.
Yes, I'm not subscribed to the mailing list at the moment - too much
traffic and too little time..
>
> They are many ways this code path can be abused, your patch only takes
> care of one case.
>
> In tipc case, they added skb to shinfo->frag_list without changing
> skb->data_len.
>
> So skb_tailroom(to) was not returning 0 as it should.
>
> The invariant should be more strict.
>
> BUG_ON(to->data + to->len != skb_tail_pointer(to));
>
> I still think a BUG() to catch this is better.
>
> There is no guarantee the developer/user will catch a WARN(),
> the bug could sit there a long time.
>
> I have no pity for serious bugs like that.
Neither do I.
Either BUG or WARN would have worked for me and would have saved me a
lot of time in chasing this bug in a monster size (almost 800 files!)
third party driver for this unfamiliar chip on newly developed embedded
hardware (so I couldn't be sure it wasn't a hardware bug) with nothing
else than a serial port and a few MB flash to store log files on.
>
> Since you spot buggy drivers, please provide their fixes or at least
> name them so that we can take care of them.
>
> Thanks
>
>
Strange, I was almost certain that I saw at least one with the same bug,
but I can't seem to find it any longer.
Maybe I looked too quick, or maybe it's been fixed by the git pull I've
made in the meantime.
I'll take a closer look if I get some spare time some day..
prev parent reply other threads:[~2014-04-25 19:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 15:02 [PATCH] net: guard against coalescing packets from buggy network drivers Svenning Sørensen
2014-04-25 15:43 ` Eric Dumazet
2014-04-25 16:01 ` Svenning Sørensen
2014-04-25 16:49 ` Eric Dumazet
2014-04-25 19:32 ` Svenning Sørensen [this message]
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=535AB84B.20207@secomea.com \
--to=sss@secomea.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.