From: Daniel Borkmann <daniel@iogearbox.net>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
tklauser@distanz.ch, Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net v2 3/3] packet: fix tpacket_snd max frame and vlan handling
Date: Wed, 11 Nov 2015 00:12:31 +0100 [thread overview]
Message-ID: <564279DF.4080400@iogearbox.net> (raw)
In-Reply-To: <CA+FuTSfkD4aMciGeqon0cLp=EJ7fWis56nGQsbku82ZC+=nNWg@mail.gmail.com>
On 11/10/2015 11:52 PM, Willem de Bruijn wrote:
>> if (sock->type == SOCK_DGRAM) {
>> - err = dev_hard_header(skb, dev, ntohs(proto), addr,
>> - NULL, tp_len);
>> + /* In DGRAM sockets, we expect struct sockaddr_ll was filled
>> + * via struct msghdr, so we have dest mac and skb->protocol.
>> + * Otherwise there's not too much useful things we can do in
>> + * this flush run.
>> + */
>> + err = dev_hard_header(skb, dev, ntohs(skb->protocol), addr,
>> + NULL, tp_len);
>
> This change is not really necessary.
Sure agreed, I found it helpful though. Don't mind removing it.
>> if (unlikely(err < 0))
>> return -EINVAL;
>> - } else if (dev->hard_header_len) {
>
> Why remove the check on hard_header_len?
Hmm, the patch doesn't remove the check (it's moved further below).
>> - if (ll_header_truncated(dev, tp_len))
>> - return -EINVAL;
>> + } else {
>> + /* If skb->protocol is still 0, try to infer/guess it. Might
>> + * not be fully reliable in the sense that a user could still
>> + * change/race data afterwards, but on the other hand the proto
>
> The race goes away when probing it after the copy in skb_store_bits.
> Then it is also certain that tp_len is long enough to hold the entire
> link layer header.
The skb_store_bits() is only done in case we do have a dev->hard_header_len
or in case where we run into a possible situation where we have the additional
4 bytes on a full frame. In that case we need to check them properly, which
requires copying, otherwise we don't copy any header.
>> + * can be set arbitrarily anyways. We only need to take care
>> + * in case of extra large VLAN frames.
>> + */
>> + if (!skb->protocol && tp_len >= ETH_HLEN)
>> + skb->protocol = ((struct ethhdr *)data)->h_proto;
>
> Packet sockets are not restricted to link layer of type Ethernet.
>
> There are a few other points in this file that also cast mac header
> to eth_hdr(skb).
Ok, the set doesn't address this assumption which we have elsewhere, too.
Do you suggest to also check on dev->type for these cases?
Thanks,
Daniel
next prev parent reply other threads:[~2015-11-10 23:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 22:03 [PATCH net v2 0/3] packet fixes Daniel Borkmann
2015-11-10 22:03 ` [PATCH net v2 1/3] packet: do skb_probe_transport_header when we actually have data Daniel Borkmann
2015-11-11 5:07 ` Jason Wang
2015-11-10 22:03 ` [PATCH net v2 2/3] packet: always probe for transport header Daniel Borkmann
2015-11-11 5:08 ` Jason Wang
2015-11-10 22:03 ` [PATCH net v2 3/3] packet: fix tpacket_snd max frame and vlan handling Daniel Borkmann
2015-11-10 22:52 ` Willem de Bruijn
2015-11-10 23:12 ` Daniel Borkmann [this message]
2015-11-10 23:24 ` Willem de Bruijn
2015-11-10 23:51 ` Daniel Borkmann
2015-11-11 14:56 ` Willem de Bruijn
2015-11-11 22:39 ` Daniel Borkmann
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=564279DF.4080400@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=tklauser@distanz.ch \
--cc=willemdebruijn.kernel@gmail.com \
/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.