netdev - RE: [PATCH] Packet socket: mmapped IO: PACKET_TX

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]

Date:	Wed, 12 Nov 2008 13:23:33 -0800
From:	"Lovich, Vitali" <vlovich@...lcomm.com>
To:	Evgeniy Polyakov <zbr@...emap.net>
CC:	Johann Baudy <johaahn@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING



> -----Original Message-----
> From: Evgeniy Polyakov [mailto:zbr@...emap.net]
> Sent: November-12-08 11:14 AM
> To: Lovich, Vitali
> Cc: Johann Baudy; netdev@...r.kernel.org
> Subject: Re: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING
> 
> Here is the main point: why do you ever care about data that was or was
> not transmitted and want to update something at destruction time and
> not
> when dev_qeueue_xmit() returns. As pointed above, destruction time does
> not guarantee that skb was sent as long as return from
> dev_qeueue_xmit().
I don't care whether or not the data was sent - I care whether or not the driver
might still use the data in the frame the skb is referring to.  In the destructor, clearly the
driver can't since it gave up its reference.  After dev_queue_xmit, we don't know because
the driver (or the skb queue layer) may have decided to delay packet transmission.

Potentially the user might even have written half the payload of a packet when the device decides to
send out the skb for that frame and thus send out half the payload from one 
packet and half the payload from another.

> 
> So you can update whatever flags you have to after return of the
> dev_qeueue_xmit() and will get the same behaviour as sendfile:
> immediate write into the same memory area results in sending new
> content
> (on some NICs).
But using your approach, how can a user ever know whether or not he actually sent
a packet?

Am I missing something fundamental in my understanding?  I don't see any way, outside
of using the skb destructor, to notify the user when he can safely write to a frame
without interfering with any pending skbs.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html