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 11:05:03 -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 10:12 AM
> To: Lovich, Vitali
> Cc: Johann Baudy; netdev@...r.kernel.org
> Subject: Re: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING
> 
> On Wed, Nov 12, 2008 at 09:59:20AM -0800, Lovich, Vitali
> (vlovich@...lcomm.com) wrote:
> > They aren't racy - not in the sense that your suggestion would make
> > it.  With current splice & sendfile, when it returns from the syscall,
> > the user knows that it has been transmitted and thus can continue using
> > the file descriptors & memory (in the case of vmsplice).  However, with
> > your suggestion, the user could actually never know when it's safe to
> > write into memory (even in a single-threaded situation).  Thus it is
> > racy in a single-threaded situation (even on a UP it's potentially
> > racy) which is a pretty amazing feat.  Consider:
> 
> Problem is, that when sendfile() returns nothing has been transferred.
> And in some NICs it will take a while to actually make a transfer.
> And what you wrote below is exactly the same problem as exists with
> splice/sendfile in particular and ->sendpage() in general.
I still don't see it.  This can only be a problem for vmsplice, since I believe
sendpage & splice copy the data from the source pipe if necessary.
vmsplice solves this through the SPLICE_F_GIFT flag (if not specified, 
I'm assuming it copies the data into a temporary buffer).  So I don't 
believe that these are actually racy functions if used properly.

However, your suggestion makes non-racy usage of the tx ring impossible
unless you know ahead of time how many frames you will need (in which case, resetting
the status flag is pointless).  But for proper ring buffer behaviour, it needs to
clear the flag in the skb destructor, once we know the data will no longer be used by
the driver.

> Please also update your mailer to wrap strings into 80-or-so lines, it
> is hard to answer into the middle of the paragraph.
Sorry - I hate using Outlook because it doesn't seem to honour my settings.
I'll split up the lines manually instead of trusting Outlook.

Vitali

--
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