netdev - RE: [EXTERNAL] Re: [PATCH] netpoll: support sending over raw IP interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <MWHPR1801MB1918F15413BA4766F29A8581D3292@MWHPR1801MB1918.namprd18.prod.outlook.com>
Date: Thu, 14 Mar 2024 02:46:06 +0000
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Mark <mark@...suba.nl>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Hans de Goede
	<hdegoede@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Breno Leitao <leitao@...ian.org>, Ingo Molnar
	<mingo@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni
	<pabeni@...hat.com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [PATCH] netpoll: support sending over raw IP
 interfaces

> From: Mark <mark@...suba.nl>
> Sent: Wednesday, March 13, 2024 7:23 PM
> To: Ratheesh Kannoth <rkannoth@...vell.com>
> > On 2024-03-13 at 18:16:13, Mark Cilissen (mark@...suba.nl) wrote:
> >> […]
> > Taking an assumption based on dev’s lower layer does not look to be good.
> > why not transmit packet from skb_network_header() in your driver (by
> > making changes in your driver)
> 
> There’s two assumptions at play here:
> - The lower layer is ethernet: this has always been present in netpoll, and is
> even
>   documented in netconsole.rst. This comment just mentions it because we
> add a way
>   to bypass the assumption; it is not an assumption this patch adds to the
> code.
> - hard_header_len==0 means that there is no exposed link layer: this is a rather
>   conservative assumption in my opinion, and is also mentioned in the
> definition

Hmm.  That is not my question.   Let me explain it in detail. Netconsole is using netpoll_send_udp() to encapsulate the msg over 
UDP/IP/ MAC headers. Job well done. Now it calls netdev->ops->ndo_start_xmit(skb, dev).  If your driver is well aware that you can
Transmit only from network header, why don’t you dma map from network header ?  

>   of LL_RESERVED_SPACE:
> 
> > * Alternative is:
> > *   dev->hard_header_len ? (dev->hard_header_len +
> > *                            (HH_DATA_MOD - 1)) & ~(HH_DATA_MOD - 1) : 0
> 
>   The same assumption is also made in more places in the core network code,
> like af_packet:
> 
> >   - If the device has no dev->header_ops->create, 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.
> 
ACK.