leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

net/packet: Fix a comment about mac_header

Browse Source 
1. Change all "dev->hard_header" to "dev->header_ops"

2. On receiving incoming frames when header_ops == NULL:

The comment only says what is wrong, but doesn't say what is right.
This patch changes the comment to make it clear what is right.

3. On transmitting and receiving outgoing frames when header_ops == NULL:

The comment explains that the LL header will be later added by the driver.

However, I think it's better to simply say that the LL header is invisible
to us. This phrasing is better from a software engineering perspective,
because this makes it clear that what happens in the driver should be
hidden from us and we should not care about what happens internally in the
driver.

4. On resuming the LL header (for RAW frames) when header_ops == NULL:

The comment says we are "unlikely" to restore the LL header.

However, we should say that we are "unable" to restore it.
It's not possible (rather than not likely) to restore it, because:

1) There is no way for us to restore because the LL header internally
processed by the driver should be invisible to us.

2) In function packet_rcv and tpacket_rcv, the code only tries to restore
the LL header when header_ops != NULL.

Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Xie He 2020-09-16 05:23:08 -07:00 committed by David S. Miller
parent 31660a9766
commit b79a80bd6d
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
net/packet/af_packet.c
View File

@ -108,36 +108,37 @@
On receive:
-----------
Incoming, dev->hard_header!=NULL
Incoming, dev->header_ops != NULL
mac_header -> ll header
data -> data
Outgoing, dev->hard_header!=NULL
Outgoing, dev->header_ops != NULL
mac_header -> ll header
data -> ll header
Incoming, dev->hard_header==NULL
mac_header -> UNKNOWN position. It is very likely, that it points to ll
header. PPP makes it, that is wrong, because introduce
assymetry between rx and tx paths.
Incoming, dev->header_ops == NULL
mac_header -> data
However drivers often make it point to the ll header.
This is incorrect because the ll header should be invisible to us.
data -> data
Outgoing, dev->hard_header==NULL
mac_header -> data. ll header is still not built!
Outgoing, dev->header_ops == NULL
mac_header -> data. ll header is invisible to us.
data -> data
Resume
If dev->hard_header==NULL we are unlikely to restore sensible ll header.
If dev->header_ops == NULL we are unable to restore the ll header,
because it is invisible to us.
On transmit:
------------
dev->hard_header != NULL
dev->header_ops != NULL
mac_header -> ll header
data -> ll header
dev->hard_header == NULL (ll header is added by device, we cannot control it)
dev->header_ops == NULL (ll header is invisible to us)
mac_header -> data
data -> data