netdev - [PATCH 1/1] [QPOLICY]: Ignore packets with specific priority

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-next>] [day] [month] [year] [list]

Message-Id: <200810262233.54649.tomasz@grobelny.oswiecenia.net>
Date:	Sun, 26 Oct 2008 22:33:54 +0100
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	netdev@...r.kernel.org
Subject: [PATCH 1/1] [QPOLICY]: Ignore packets with specific priority

This patch allows certain packets to be discarded based on its priority. This
allows for creation of userspace queuing policies.

This patch is not meant for inclusion in test tree, it is only to provide base 
for discussion. Last time (quite a few months ago) when we discussed how 
qpolicies should be implemented we couldn't reach a conclusion how parameters 
should be detected, not even if they should be detected at runtime at all. 
This trivial patch allows qpolicies to be moved to userspace as demonstrated 
by attached C# code (requires mono). This way userspace-kernelspace interface 
is dead simple allowing for quite a lot flexibility in designing the way 
packet buffer is organized.

The basic idea is that we set send buffer size so that only one packet fits in 
it. Sending second packet while first is inside buffer (has not been sent 
yet) causes send() to block until ccid allows the first packet to be 'send'. 
For each real packet we call send() twice: one 'fake' (will be discarded just 
before sending) and one 'real' (contains user data). This makes all the 
waiting to be done on the 'fake' packet making sending the real one really 
fast. This allows for late data choice without difficult to implement ring 
buffers shared by user and kernel space or complicated qpolicies code on 
kernel side.

Results on CCID2 are very promising (near ideal), but CCID3 is somewhat 
disappointing to the extent I'm starting to think that I'm doing something 
seriously wrong while testing it.

Therefore I have two questions:
1. What do you think about the idea in general?
2. Could anybody test the attached code on both CCID2 and CCID3 and send 
results/observations to the list?

(Don't ask why packets with priority 65 are discarded. It's just a random 
number.)
---
 net/dccp/qpolicy.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/dccp/qpolicy.c b/net/dccp/qpolicy.c
index 27383f8..e639523 100644
--- a/net/dccp/qpolicy.c
+++ b/net/dccp/qpolicy.c
@@ -43,6 +43,8 @@ static struct sk_buff *qpolicy_prio_best_skb(struct sock 
*sk)
 	skb_queue_walk(&sk->sk_write_queue, skb)
 		if (best == NULL || skb->priority > best->priority)
 			best = skb;
+	if (best == NULL || best->priority == 65)
+		return NULL;
 	return best;
 }

@@ -120,11 +122,11 @@ struct sk_buff *dccp_qpolicy_pop(struct sock *sk)
 {
 	struct sk_buff *skb = dccp_qpolicy_top(sk);

-	/* Clear any skb fields that we used internally */
-	skb->priority = 0;
-
-	if (skb)
+	if (skb) {
+		/* Clear any skb fields that we used internally */
+		skb->priority = 0;
 		skb_unlink(skb, &sk->sk_write_queue);
+	}
 	return skb;
 }

-- 
1.5.4.5

View attachment "DccpClient.cs" of type "text/x-c++src" (989 bytes)

View attachment "libdccp.c" of type "text/x-csrc" (1118 bytes)

View attachment "DccpLib.cs" of type "text/x-c++src" (4057 bytes)

View attachment "Makefile" of type "text/x-makefile" (501 bytes)

View attachment "server.c" of type "text/x-csrc" (1291 bytes)