Message ID | 20200914074154.1255716-1-xie.he.0141@gmail.com |
---|---|
State | Accepted |
Delegated to: | David Miller |
Headers | show |
Series | [net-next,v2] net/packet: Fix a comment about hard_header_len and headroom allocation | expand |
On Mon, Sep 14, 2020 at 9:42 AM Xie He <xie.he.0141@gmail.com> wrote: > > This comment is outdated and no longer reflects the actual implementation > of af_packet.c. > > Reasons for the new comment: > > 1. > > In af_packet.c, the function packet_snd first reserves a headroom of > length (dev->hard_header_len + dev->needed_headroom). > Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, > which calls dev->header_ops->create, to create the link layer header. > If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of > length (dev->hard_header_len), and checks if the user has provided a > header sized between (dev->min_header_len) and (dev->hard_header_len) > (in dev_validate_header). > This shows the developers of af_packet.c expect hard_header_len to > be consistent with header_ops. > > 2. > > In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment. > That comment states that prepending an LL header internally in a driver > is considered a bug. I believe this bug can be fixed by setting > hard_header_len to 0, making the internal header completely invisible > to af_packet.c (and requesting the headroom in needed_headroom instead). > > 3. > > There is a commit for a WiFi driver: > commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len") > According to the discussion about it at: > https://patchwork.kernel.org/patch/11407493/ > The author tried to set the WiFi driver's hard_header_len to the Ethernet > header length, and request additional header space internally needed by > setting needed_headroom. > This means this usage is already adopted by driver developers. > > Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > Cc: Eric Dumazet <eric.dumazet@gmail.com> > Cc: Brian Norris <briannorris@chromium.org> > Cc: Cong Wang <xiyou.wangcong@gmail.com> > Signed-off-by: Xie He <xie.he.0141@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com>
From: Xie He <xie.he.0141@gmail.com> Date: Mon, 14 Sep 2020 00:41:54 -0700 > This comment is outdated and no longer reflects the actual implementation > of af_packet.c. > > Reasons for the new comment: > > 1. > > In af_packet.c, the function packet_snd first reserves a headroom of > length (dev->hard_header_len + dev->needed_headroom). > Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, > which calls dev->header_ops->create, to create the link layer header. > If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of > length (dev->hard_header_len), and checks if the user has provided a > header sized between (dev->min_header_len) and (dev->hard_header_len) > (in dev_validate_header). > This shows the developers of af_packet.c expect hard_header_len to > be consistent with header_ops. > > 2. > > In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment. > That comment states that prepending an LL header internally in a driver > is considered a bug. I believe this bug can be fixed by setting > hard_header_len to 0, making the internal header completely invisible > to af_packet.c (and requesting the headroom in needed_headroom instead). > > 3. > > There is a commit for a WiFi driver: > commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len") > According to the discussion about it at: > https://patchwork.kernel.org/patch/11407493/ > The author tried to set the WiFi driver's hard_header_len to the Ethernet > header length, and request additional header space internally needed by > setting needed_headroom. > This means this usage is already adopted by driver developers. > > Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > Cc: Eric Dumazet <eric.dumazet@gmail.com> > Cc: Brian Norris <briannorris@chromium.org> > Cc: Cong Wang <xiyou.wangcong@gmail.com> > Signed-off-by: Xie He <xie.he.0141@gmail.com> Applied, thank you.
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index af6c93ed9fa0..2d5d5fbb435c 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -93,12 +93,15 @@ /* Assumptions: - - if device has no dev->hard_header routine, it adds and removes ll header - inside itself. In this case ll header is invisible outside of device, - but higher levels still should reserve dev->hard_header_len. - Some devices are enough clever to reallocate skb, when header - will not fit to reserved space (tunnel), another ones are silly - (PPP). + - If the device has no dev->header_ops, there is no LL header visible + above the device. In this case, its hard_header_len should be 0. + The device may prepend its own header internally. In this case, its + needed_headroom should be set to the space needed for it to add its + internal header. + For example, a WiFi driver pretending to be an Ethernet driver should + set its hard_header_len to be the Ethernet header length, and set its + needed_headroom to be (the real WiFi header length - the fake Ethernet + header length). - packet socket receives packets with pulled ll header, so that SOCK_RAW should push it back.
This comment is outdated and no longer reflects the actual implementation of af_packet.c. Reasons for the new comment: 1. In af_packet.c, the function packet_snd first reserves a headroom of length (dev->hard_header_len + dev->needed_headroom). Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, which calls dev->header_ops->create, to create the link layer header. If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of length (dev->hard_header_len), and checks if the user has provided a header sized between (dev->min_header_len) and (dev->hard_header_len) (in dev_validate_header). This shows the developers of af_packet.c expect hard_header_len to be consistent with header_ops. 2. In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment. That comment states that prepending an LL header internally in a driver is considered a bug. I believe this bug can be fixed by setting hard_header_len to 0, making the internal header completely invisible to af_packet.c (and requesting the headroom in needed_headroom instead). 3. There is a commit for a WiFi driver: commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len") According to the discussion about it at: https://patchwork.kernel.org/patch/11407493/ The author tried to set the WiFi driver's hard_header_len to the Ethernet header length, and request additional header space internally needed by setting needed_headroom. This means this usage is already adopted by driver developers. Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Brian Norris <briannorris@chromium.org> Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Xie He <xie.he.0141@gmail.com> --- net/packet/af_packet.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)