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:	Tue, 11 Nov 2008 11:10:21 -0800
From:	"Lovich, Vitali" <vlovich@...lcomm.com>
To:	Johann Baudy <johaahn@...il.com>
CC:	Evgeniy Polyakov <zbr@...emap.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING



> -----Original Message-----
> From: Johann Baudy [mailto:johaahn@...il.com]
> Sent: November-11-08 10:59 AM
> To: Lovich, Vitali
> Cc: Evgeniy Polyakov; netdev@...r.kernel.org
> Subject: Re: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING
> 
> Hi Vitali,
> 
> > I'm saying that that frame's status should just be set to
> TP_STATUS_KERNEL, not user.  The kernel wants nothing to do with this
> frame any more and the user needs to know that.  I was going to add
> statistics tracking to keep track of how many packets were sent vs
> rejected.  This was more of an issue with my approach where I had a
> dedicated kernel thread doing all of this.
> 
> In all cases of error, Kernel is blocking on the same frame until
> update, indeed packet_increment_head() is only called on success.
> I've done this in order to not skip a packet in case of
> skb_alloc_send_skb error().
> 
> I believe, we have 3 options on all failure, if we set packet to:
> - TP_STATUS_KERNEL: User can consider that buffer is free and it will
> fill it again.
> If we choose TP_STATUS_KERNEL by default, that's means content is lost
> even for sock_alloc_send_skb() error. Such behavior is not acceptable,
> User is not able to show the difference between packet success and
> packet failure on a specific frame (same status).
> - TP_STATUS_USER: Kernel will try to send it again and again,
> especially if send() is called in a loop (even it is impossible).
> This is current way of working, It looks like a manner to block on
> issue.
> - TP_STATUS_LOOSING(or other): as TP_STATUS_USER with more info for
> user.
> Whereas TP_STATUS_USER, this one provides user with the buffer where
> error has occurred.
> 
> Thanks,
> Johann
> --
> Johann Baudy
> johaahn@...il.com

So the way I had done it is that non-recoverable errors are those caused by malformed data coming from the user (i.e. packet size is invalid).  In this case, we free the frame and return.  In all other cases, it assumed that the cause was some kind of bad kernel state (i.e. no memory, device busy, etc) that will eventually be recovered from, so we keep retrying or return to the user without changing the status code.
--
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