Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework

2006-07-31 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-07-31 20:01 Thomas Graf wrote: * Ville Nuorvala [EMAIL PROTECTED] 2006-07-31 17:46 Shouldn't all these (struct fib_rule_hdr included) actually be defined in include/linux/rtnetlink.h? We used to stuff everything into rtnetlink.h for no good

Re: [PATCH 2/5] [IPV6]: Multiple Routing Tables

2006-07-29 Thread Thomas Graf
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2006-07-29 13:13 Well, one design consideration that I have had for several months is performance impact. Previously, we directly use address, ifindex etc., not flowi, in IPv6 routing code except for ip6_route_output(). This patch changes

Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework

2006-07-28 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-07-28 01:30 +int fib_rules_lookup(struct fib_rules_ops *ops, struct flowi *fl, +int flags, struct fib_lookup_arg *arg) +{ + struct fib_rule *rule; + int err; + + rcu_read_lock(); + + list_for_each_entry(rule,

Re: [RFC] Multiple IPV6 Routing Tables Policy Routing

2006-07-28 Thread Thomas Graf
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2006-07-28 15:10 Well, as you stated, the code is based on the work of MIPL, which is being jointly developed by Helsinki University of Technology (HUT) and USAGI/WIDE Project. Please describe this on your commit logs. Please retain

Re: [PATCH 2/7] NetLabel: core network changes

2006-07-28 Thread Thomas Graf
* [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-07-17 11:52 + * NetLabel makes use of the Generic NETLINK mechanism as a transport layer to + * send messages between kernel and user space. The general format of a + * NetLabel message is shown below: + * + *

Re: [PATCH 2/7] NetLabel: core network changes

2006-07-28 Thread Thomas Graf
* Paul Moore [EMAIL PROTECTED] 2006-07-28 13:58 I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :) I

Re: [PATCH 2/7] NetLabel: core network changes

2006-07-28 Thread Thomas Graf
* Paul Moore [EMAIL PROTECTED] 2006-07-28 14:39 It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons: 1. They are listed as optional in the documents I read 2.

[RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework

2006-07-27 Thread Thomas Graf
Derived from net/ipv6/fib_rules.c Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/linux/fib_rules.h === --- /dev/null +++ net-2.6.git/include/linux/fib_rules.h @@ -0,0 +1,60 @@ +#ifndef __LINUX_FIB_RULES_H

[RESEND 4/5] [IPV6]: Policy Routing Rules

2006-07-27 Thread Thomas Graf
Adds support for policy routing rules including a new local table for routes with a local destination. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/ipv6/fib6_rules.c === --- /dev/null +++ net-2.6.git/net/ipv6

[RESEND 5/5] [IPV4]: Use Protocol Independant Policy Routing Rules Framework

2006-07-27 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/net/ip_fib.h === --- net-2.6.git.orig/include/net/ip_fib.h +++ net-2.6.git/include/net/ip_fib.h @@ -18,6 +18,7 @@ #include net/flow.h #include linux

[PATCH 2/5] [IPV6]: Multiple Routing Tables

2006-07-26 Thread Thomas Graf
. Since policy rules will not be reversible it is unclear whether it makes sense to change this. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/net/ip6_fib.h === --- net-2.6.git.orig/include/net/ip6_fib.h

[PATCH 3/5] [NET]: Protocol Independant Policy Routing Rules Framework

2006-07-26 Thread Thomas Graf
Derived from net/ipv6/fib_rules.c Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/linux/fib_rules.h === --- /dev/null +++ net-2.6.git/include/linux/fib_rules.h @@ -0,0 +1,60 @@ +#ifndef __LINUX_FIB_RULES_H

[RFC] Multiple IPV6 Routing Tables Policy Routing

2006-07-26 Thread Thomas Graf
Hello, Thought it might be time to go through a round of comments on this work. Even though I've almost rewritten all the code the patches are based on the work found on www.mobile-ipv6.org. I have no idea which code was written by whom so just email me to get the credits right. Main differences

[PATCH 1/5] [IPV6]: Remove ndiscs rt6_lock dependency

2006-07-26 Thread Thomas Graf
(Ab)using rt6_lock wouldn't work anymore if rt6_lock is converted into a per table lock. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/ipv6/route.c === --- net-2.6.git.orig/net/ipv6/route.c +++ net-2.6.git/net

[PATCH 4/5] [IPV6]: Policy Routing Rules

2006-07-26 Thread Thomas Graf
Adds support for policy routing rules including a new local table for routes with a local destination. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/ipv6/fib6_rules.c === --- /dev/null +++ net-2.6.git/net/ipv6

[PATCH 5/5] [IPV4]: Use Protocol Independant Policy Routing Rules Framework

2006-07-26 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/net/ip_fib.h === --- net-2.6.git.orig/include/net/ip_fib.h +++ net-2.6.git/include/net/ip_fib.h @@ -18,6 +18,7 @@ #include net/flow.h #include linux

Re: [PATCH 2/5] [IPV6]: Multiple Routing Tables

2006-07-26 Thread Thomas Graf
* David Miller [EMAIL PROTECTED] 2006-07-26 15:39 Wow, were we corrupting the IP6CB() of input packets on every route lookup that hit this path? I found that via compile error as passing on skb to this context didn't make sense when I rewrote the code around it :-) Fortunately it's only used

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-09 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-09 08:52 On Sun, 2006-09-07 at 01:46 +0200, Thomas Graf wrote: * Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-08 10:14 [..] There is no easy way to detect such a deadlock. I think it reduces to the same case as eth0-eth0, i.e: It's very

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-09 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-09 10:03 On Sun, 2006-09-07 at 15:33 +0200, Thomas Graf wrote: That's not gonna work, dev-queue_lock may be held legimitately by someone else than an underlying dev_queue_xmit() call. If there is a legitimate reason then it wont work. I cant

[PKT_SCHED]: act_api: Fix module leak while flushing actions

2006-07-09 Thread Thomas Graf
Module reference needs to be given back if message header construction fails. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/sched/act_api.c === --- net-2.6.git.orig/net/sched/act_api.c +++ net-2.6.git/net/sched

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-09 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-09 11:00 If you mean that the device will also try to grab the qlock there, then that is fine still for the serialization. It all starts at dev_queue_xmit. Look at where dev-queue_lock is taken, whenever a qdisc or filter is added, modified or

Re: [PKT_SCHED]: act_api: Fix module leak while flushing actions

2006-07-09 Thread Thomas Graf
* David Miller [EMAIL PROTECTED] 2006-07-09 11:38 From: Thomas Graf [EMAIL PROTECTED] Date: Sun, 9 Jul 2006 16:20:43 +0200 Module reference needs to be given back if message header construction fails. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Applied, thanks Thomas

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-08 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-07-01 09:35 On Sat, 2006-01-07 at 13:28 +0200, Thomas Graf wrote: Please enlighten me, I may be making a wrong assumption again. 1) tc_verd is reset to 0 after dq in ri_tasklet() 2) TC_AT is set to AT_EGRESS in dev_queue_xmit() 3) TC_FROM being derived

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-08 Thread Thomas Graf
* Thomas Graf [EMAIL PROTECTED] 2006-07-09 01:46 __LINK_STATE_QDISC_RUNNING will prevent an eventual tx deadlock, it will not prevent the mirred deadlock. BTW, it will also not protect you from deadlocking on dev-queue_lock while enqueueing. - To unsubscribe from this list: send the line

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-07 Thread Thomas Graf
* Andrew Morton [EMAIL PROTECTED] 2006-07-06 16:05 hm, nla_strlcpy() looks more complex than it needs to be. We really need nla_kstrndup() ;) Oh well. This? Looks good. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-07 Thread Thomas Graf
* Andrew Morton [EMAIL PROTECTED] 2006-07-06 15:56 Yup. Thomas, what's the testing status of the netlink patch you sent? Should I queue it up and start plagueing people with it? It survived feeding it with oversized strings etc. Feel free to queue it up. - To unsubscribe from this list:

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Thomas Graf
. Aims at easing the pain with using nla_strlcpy() on temporary buffers. The old `minlen' field is renamed to `len' for cosmetic purposes which is ok since nobody was using it at this point. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/net/netlink.h

Re: [PATCH 0/3] Action API fixes

2006-07-06 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-07-06 08:27 The proper patch is attached as a replacement for [PATCH 3/3] [PKT_SCHED]: Fix error handling while dumping action from Thomas. If you have already submitted it, then i will send a patch against it. I don't understand why you're picky about this

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Thomas Graf
* Andrew Morton [EMAIL PROTECTED] 2006-07-06 14:48 In the interests of keeping this work decoupled from netlink enhancements I'd propose the below. Is it bad to modify the data at nla_data()? Yes, it points into a skb data buffer which may be shared by sitting on other queues if the message is

Re: [PATCH 1/3] [PKT_SCHED]: Fix illegal memory dereferences when dumping actions

2006-07-05 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-07-05 01:42 Thomas Graf wrote: @@ -834,7 +833,7 @@ tc_dump_action(struct sk_buff *skb, stru a.ops = a_o; if (a_o-walk == NULL) { - printk(tc_dump_action: %s !capable of dumping table\n, kind); + printk

Re: [PATCH 3/3] [PKT_SCHED]: Fix error handling while dumping actions

2006-07-05 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-07-05 09:35 Please resubmit this patch with changing -err to -1 (i.e a one liner) I went back to about 2.6.10 and this is in there. I looked at my notes and i cant see any reasoning to explain this. So it is a bug. Fine, if you think that's better. Is there a

[PATCH 0/3] Action API fixes

2006-07-04 Thread Thomas Graf
Dave, Fixes for some rather serious action API bugs. Please apply. net/sched/act_api.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info

[PATCH 1/3] [PKT_SCHED]: Fix illegal memory dereferences when dumping actions

2006-07-04 Thread Thomas Graf
be triggered with malformed netlink message and don't require any privileges. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/sched/act_api.c === --- net-2.6.git.orig/net/sched/act_api.c +++ net-2.6.git/net/sched

[PATCH 2/3] [PKT_SCHED]: Return ENOENT if action module is unavailable

2006-07-04 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/sched/act_api.c === --- net-2.6.git.orig/net/sched/act_api.c +++ net-2.6.git/net/sched/act_api.c @@ -305,6 +305,7 @@ struct tc_action *tcf_action_init_1(stru

Re: [RFC NET 00/04]: Increase number of possible routing tables

2006-07-03 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-07-03 11:38 That wasn't entirely true either, its not inet_check_attr but rtnetlink_rcv_message that aborts, and it does this on all kernels. Somehow I thought unknown attributes were usually ignored .. This only applies to the first level of rtnetlink

Re: [RFC NET 00/04]: Increase number of possible routing tables

2006-07-03 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-07-03 13:36 They will as long as this feature isn't used, the RTA_TABLE attribute is only added to the message when the table id is 255. Worked fine during my tests, or are you refering to something else? Perfect, I said nothing :) - To unsubscribe

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-01 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 22:59 On Sat, 2006-01-07 at 01:45 +0200, Thomas Graf wrote: Fact is that the from verdict is set to a meaningful value again at dev_queue_xmit() or ing_filter() so ifb_xmit() only sees valid values. Ok, Thomas this is one of those places where we end

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-07-01 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 22:23 I am not certain i understood then: Are we in the mode where the refcount is not needed because chances are small that a device will disappear? It seems to me after all this trouble that it may not be so bad to refcount (I guess i meant refcount the

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
-dev in a manner that the device can't disappear before calling netif_rx() and the semantics are fixed so a packet reentering the stack looks like it would have been received on the ifb device. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/linux/skbuff.h

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 10:35 On Fri, 2006-30-06 at 16:15 +0200, Thomas Graf wrote: eth0::tcf_mirred() skb-dev = ifb0, input_dev = eth0 ifb0::tcf_mirred() skb-dev = ifb1, input_dev = ifb0 ifb1::ifb_xmit() skb-dev = ifb0, input_dev = ifb1, set ncls bit ifb0

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 13:19 On Fri, 2006-30-06 at 18:32 +0200, Thomas Graf wrote: * jamal [EMAIL PROTECTED] 2006-06-30 10:35 Did you actually try to run this before you reached this conclusion? I did, fortunately some other bug prevents this from happening, packets

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 15:34 I thought we went past that point already - and i made it clear that the reference is _not_ taken in netif_receive_skb(). So assuming it is taken in mirred (i havent thought of where it is decremented), why would using the ifindex be better? The

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 15:59 One thing is clear in my mind at least (and i have said it several times): I am not as good at the semantics as either yourself or Thomas or Dave or Acme etc but i have tons of other things that compensate for. Probably not as good is not the best

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 16:54 I agree - and i try hard to document but at times there's too much and a line needs to be drawn. As an example: the eth-ifb-ifb case though is a very corner case. All the IMQ types need to only redirect to one ifb; while i test it ive always seen the

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 17:09 On Fri, 2006-30-06 at 19:13 +0200, Thomas Graf wrote: Index: net-2.6.git/drivers/net/ifb.c === --- net-2.6.git.orig/drivers/net/ifb.c +++ net-2.6.git/drivers/net/ifb.c @@ -158,19

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
This is boring, I reversed everything to not change any semantics and you still complain. * jamal [EMAIL PROTECTED] 2006-06-30 17:35 On Fri, 2006-30-06 at 23:20 +0200, Thomas Graf wrote: * jamal [EMAIL PROTECTED] 2006-06-30 17:09 the ref inside the else below after changing input_dev

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-30 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-30 17:31 Better to explain the reason for ifb first: ifb exists initially as a replacement for IMQ. 1) qdiscs/policies that are per device as opposed to system wide. This now allows for sharing. 2) Allows for queueing incoming traffic for shaping instead

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-29 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-28 09:46 Why not use iflink? It exists, by definition, specifically as the ifindex of the down muxed netdevice (should probably add that definition in the .h). This is semantically different from a message to the stack which says this came to you from input

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-29 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-29 19:23 What's currently done in ifb: skb-dev = skb-input_dev; skb-input_dev = dev; Confusing, isn't it? not at all. Let me explain the design intent further below. Then let me show you what your code does: [mirred attached to

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-29 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-29 20:03 On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote: * jamal [EMAIL PROTECTED] 2006-06-29 19:23 not at all. Let me explain the design intent further below. Then let me show you what your code does: [mirred attached to filter on eth0

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-29 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-29 20:48 the ifb references it; only mirred redirects to the ifb at the moment. You would need to increment in mirred, no? Why do i feel i am missing something? ;- The point is to avoid having an atomic operation for every packet when setting iif in

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-28 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-27 09:07 I am reading the thread backwards, so i may miss some of the obvious. I also dont remember the exact discussion we had - but the consensus was to leave the field setting as is. Note the meta-setter (been sitting on it for too long) also set the

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-28 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-28 08:22 Let me see if i understood correctly: you have a device from both vlan1 and vlan2 both being redirected to ifb1? and vlan 3, 4= ifb2? And i take it to make it interesting vlan1,2 on eth0 and vlan3,4 ontop of eth1? note the iflink would/should reflect

[PATCHSET] Towards accurate incoming interface information

2006-06-26 Thread Thomas Graf
This patchset transforms skb-input_dev based on a device reference to skb-iif based on an interface index moving towards accurate iif information for routing and classification through the following changesets: [NET]: Use interface index to keep input

[PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-26 Thread Thomas Graf
Updating iif to the VLAN device helps keeping routing namespaces defined in case packets from multiple VLANs collapse on a single device again. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/net/8021q/vlan_dev.c

[PATCH 1/3] [NET]: Use interface index to keep input device information

2006-06-26 Thread Thomas Graf
Using the interface index instead of a direct reference allows a safe usage beyond the scope where an interface could disappear. The old input_dev field was incorrectly made dependant on CONFIG_NET_CLS_ACT in skb_copy(). Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include

[PATCH 3/3] [PKT_SCHED]: Add iif meta match

2006-06-26 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.git/include/linux/tc_ematch/tc_em_meta.h === --- net-2.6.git.orig/include/linux/tc_ematch/tc_em_meta.h +++ net-2.6.git/include/linux/tc_ematch/tc_em_meta.h @@ -81,6 +81,7

Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

2006-06-26 Thread Thomas Graf
* David Miller [EMAIL PROTECTED] 2006-06-26 10:46 From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 26 Jun 2006 19:04:15 +0200 I know this was discussed before, but I can't remember the exact outcome. Why don't we just unconditionally update iif in netif_receive_skb()? Software

Re: [DOC]: generic netlink

2006-06-20 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-06-19 09:41 // the attributes you want to own enum { FOOBAR_ATTR_UNSPEC, FOOBAR_ATTR_TYPE, FOOBAR_ATTR_TYPEID, FOOBAR_ATTR_TYPENAME, FOOBAR_ATTR_OPER, /* add future attributes here */ __FOOBAR_ATTR_MAX,

Re: [DOC]: generic netlink

2006-06-20 Thread Thomas Graf
Hello TODO: a) Add a more complete compiling kernel module with events. Have Thomas put his Mashimaro example and point to it. I guess we have a legal issue here ;) change the name ;- Ask Mr. Mashimaro has become my replacement for 8ball. Renaming it would lead to a serious

Re: Refactor Netlink connector?

2006-06-01 Thread Thomas Graf
* James Morris [EMAIL PROTECTED] 2006-05-31 11:42 On Wed, 31 May 2006, jamal wrote: To also answer your other email: Look at security/selinux/nlmsgtab.c for example for NETLINK_ROUTE and compare with NETLINK_GENERIC to see the hole. I was suggesting if we started by just adding checks

Re: Refactor Netlink connector?

2006-05-31 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2006-05-31 08:00 We could start by just adding a check for NETLINK_GENERIC in your table (as is done generally for other netlink families/protocols with SELinux) and then do the fine-grained stuff. I think that checking for attributes instead of types will need to be

Re: Refactor Netlink connector?

2006-05-30 Thread Thomas Graf
* James Morris [EMAIL PROTECTED] 2006-05-27 13:21 Actually, a possible solution here is to completely remove all internal knowledge of netlink messages from SELinux and have the netfilter framework and protocols provide methods to determine message types and permissions. Right, regarding

[PATCH] [NETFILTER] ip_queue: Fix wrong skb-len == nlmsg_len assumption

2006-03-07 Thread Thomas Graf
may not be mangled depening on their original size. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/ipv4/netfilter/ip_queue.c === --- net-2.6.orig/net/ipv4/netfilter/ip_queue.c +++ net-2.6/net/ipv4/netfilter/ip_queue.c

[BONDING]: Remove CAP_NET_ADMIN requirement for INFOQUERY ioctl

2006-01-23 Thread Thomas Graf
This information is already available via /proc/net/bonding/* therefore it doesn't make sense to require CAP_NET_ADMIN privileges. Original patch by Laurent Deniel [EMAIL PROTECTED] Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/core/dev.c

Re: WCONF, netlink based WE replacement.

2006-01-13 Thread Thomas Graf
* Michael Buesch [EMAIL PROTECTED] 2006-01-12 18:24 This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. I'll only

Re: [PATCH] net: fix PRIO qdisc bands init

2006-01-13 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2006-01-12 06:25 David S. Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 10 Jan 2006 23:02:45 -0500 So it is an optimization - not a bug then, correct? It is only an optimization in as much as it avoids duplicate work during initialization.

Re: [PATCH] genetlink: don't touch module ref count

2006-01-13 Thread Thomas Graf
* Per Liden [EMAIL PROTECTED] 2006-01-13 09:27 Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Why shouldn't

Re: ipv4 duplicate rules

2005-12-27 Thread Thomas Graf
I realized that in fib_rules.c the inet_rtm_new_rule() function adds rules without checking if they already exist. This may result in duplicate rules being added. It makes it difficult to remove a rule when it is added multiple times (with the intention that it would be added only once

[PATCH] [NETLINK]: Fix processing of fib_lookup netlink messages

2005-12-01 Thread Thomas Graf
The receive path for fib_lookup netlink messages is lacking sanity checks for header and payload and is thus vulnerable to malformed netlink messages causing illegal memory references. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: linux-2.6/net/ipv4/fib_frontend.c

Re: [stable] [PATCH] [NETLINK]: Fix processing of fib_lookup netlink messages

2005-12-01 Thread Thomas Graf
* Greg KH [EMAIL PROTECTED] 2005-12-01 14:21 On Thu, Dec 01, 2005 at 11:05:12PM +0100, Thomas Graf wrote: The receive path for fib_lookup netlink messages is lacking sanity checks for header and payload and is thus vulnerable to malformed netlink messages causing illegal memory references

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

2005-11-28 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-28 14:15 Hi, ok, at least some progress has happened: Looks good, it would be nice if you could separate the vlan part as a separate patch for later on though. -Replaced device-specific oper_state method with NETIF_F_STACKED flag to select between

Re: [2.6 patch] do not select NET_CLS

2005-11-23 Thread Thomas Graf
* David S. Miller [EMAIL PROTECTED] 2005-11-22 14:37 From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 21 Nov 2005 17:16:18 +0100 Adrian Bunk wrote: This patch therefore changes NET_CLS back to the 2.6.14 status quo of being an user-visible option. I disagree with this patch.

Re: [DEBUG INFO]IPv6: sleeping function called from invalid context.

2005-11-19 Thread Thomas Graf
* Herbert Xu [EMAIL PROTECTED] 2005-11-19 22:48 Thomas Graf [EMAIL PROTECTED] wrote: I did. I think it was right, why would an allocation be necessary on the second call to inet6_dump_fib()? The walker allocated in process context on the first call should be reused from cb-args[0

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

2005-11-16 Thread Thomas Graf
* jamal [EMAIL PROTECTED] 2005-11-15 21:16 3) There is a kernel dev-operstate_kernel which is accessible via user space in the same manner IFF_UP flags are set etc. Just be careful about synchronization, that's one issue with the currently proposed implementation. The callers cannot be made

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

2005-11-14 Thread Thomas Graf
My suggestion is at this point to ignore any L3 issues and have people post their patches. RFC 2863 states MUST be taken into consideration. Proper naming must be taken into account. Split up in 3 patches, not implementing the bits allowing userspace to trigger leaving dormant state. [NET]:

Re: [PATCH 6/6] [NETLINK]: Generic netlink family

2005-11-10 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-11-10 11:00 Dave - ACK on all 6. Both Thomas and I have tested these and the TIPC folks have been playing with them for sometime now; if we get them in for 2.6.15 it would help to encourage them to change their API on their stable release to use this

Re: [PATCH 6/6] [NETLINK]: Generic netlink family

2005-11-10 Thread Thomas Graf
* James Morris [EMAIL PROTECTED] 2005-11-10 10:15 For SELinux, we'll need to track genl ID assignment and deletion, so we can determine what the Netlink family number means when we see a Netlink message. We'll have to assume that the sysadmin has not changed the module name. Forgot to

Re: Consensus? WAS(RFC 2863)

2005-11-10 Thread Thomas Graf
* Paul Jakma [EMAIL PROTECTED] 2005-11-10 23:10 Why would an on-demand dialup device go ~IFF_RUNNING? The whole point of such a device is to /hide/ whether the physical layer is up or not. The state of an on-demand interface must be visible, typically an on-demand interface is in dormant

Re: Patch: RFC2863 #1 (incomplete)

2005-11-09 Thread Thomas Graf
We're talking about the auto routes in the main table, right? There is no reason for the addresses to be configured as a prefix, they can, and in my opinion should, be added as /~0 if the net is not guaranteed to be reachable at exactly this interface at all times. e.g. a user adding the

Re: Patch: RFC2863 #1 (incomplete)

2005-11-09 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-09 17:13 Am Mittwoch 09 November 2005 15:25 schrieb Thomas Graf: It's still behind eth3 but not reachable at the moment. If you know that the network can be reached via other interfaces then just don't statically assign a route for it and have

Re: Consensus? WAS(RFC 2863)

2005-11-09 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-11-09 15:13 The link change notification should be handled by the fib code as if it was an admin notification. Something like this should do the job, although it doesn't take care of taking things up again for now. Now all supporters of this should tell

Re: Consensus? WAS(RFC 2863)

2005-11-09 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-10 00:09 + OPER_UNKNOWN = 0, + OPER_NOTPRESENT, /* unused, placeholder */ + OPER_DOWN = 16, + OPER_LOWERLAYERDOWN, + OPER_TESTING = 32, + OPER_DORMANTL3DOWN = 48, /* OS queue start from here */ +

Re: Consensus? WAS(RFC 2863)

2005-11-09 Thread Thomas Graf
Index: linux-2.6/net/ipv4/fib_frontend.c === --- linux-2.6.orig/net/ipv4/fib_frontend.c +++ linux-2.6/net/ipv4/fib_frontend.c @@ -630,8 +630,13 @@ static int fib_netdev_event(struct notif case NETDEV_DOWN:

Re: Consensus? WAS(RFC 2863)

2005-11-09 Thread Thomas Graf
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-11-09 18:49 Historically we point such routes to the dummy device. Remember diald and good ole SLIP dial on demand? I would suspect it should still work the same way. Actually, probably use a blackhole route which will swallow such packets alive

[PATCH 4/6] [XFRM]: Use generic netlink receive queue processor

2005-11-09 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/xfrm/xfrm_user.c === --- net-2.6.orig/net/xfrm/xfrm_user.c +++ net-2.6/net/xfrm/xfrm_user.c @@ -18,7 +18,6 @@ #include linux/string.h #include linux/net.h #include

[PATCH 2/6] [NETLINK]: Make netlink_callback-done() optional

2005-11-09 Thread Thomas Graf
Most netlink families make no use of the done() callback, making it optional gets rid of all unnecessary dummy implementations. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/netlink/af_netlink.c === --- net-2.6

[PATCH 5/6] [RTNETLINK]: Use generic netlink receive queue processor

2005-11-09 Thread Thomas Graf
Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/core/rtnetlink.c === --- net-2.6.orig/net/core/rtnetlink.c +++ net-2.6/net/core/rtnetlink.c @@ -49,6 +49,7 @@ #include net/udp.h #include net/sock.h #include net

[PATCHSET] Type-safe netlink interface, generic netlink family

2005-11-09 Thread Thomas Graf
Dave, This patchset adds a type-safe netlink interface and the generic netlink family for simplified netlink usage. I did not include any transformations patch as some of them showed issues. The code posted here is tested and already in use by external users (TIPC). - To unsubscribe from this

[PATCH 6/6] [NETLINK]: Generic netlink family

2005-11-09 Thread Thomas Graf
to the current multicast implementation of netlink, the number of generic netlink modules is restricted to 1024 to avoid wasting memory for the per socket multiacst subscription bitmask. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/netlink/Makefile

Re: Patch: RFC2863 #1 (incomplete)

2005-11-08 Thread Thomas Graf
* Hasso Tepper [EMAIL PROTECTED] 2005-11-08 17:14 OSPF doesn't care if there is connected route or not if !IFF_RUNNING. And it doesn't matter if it's demand circuit or usual one. If kernel reports link down (!IFF_RUNNING), no any packets are sent over this link - hellos, LS updates etc. Hellos

Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion

2005-11-08 Thread Thomas Graf
+++ b/ChangeLog 2005-03-19 00:49:52 +01:00 @@ -1,3 +1,8 @@ +2005-03-19 Thomas Graf [EMAIL PROTECTED] + + * Warn about wildcard deletions and provide IFA_ADDRESS upon + deletions to enforce prefix length validation for IPv4. + 2005-03-18 Stephen Hemminger [EMAIL PROTECTED

Re: Patch: RFC2863 #1 (incomplete)

2005-11-07 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-07 00:42 -userspace interaction, including userspace supplicant + locking of operstate_useroverride -migrate VLAN + BONDING to use OPER_LOWERLAYERDOWN I think that bonding should check on the administrative status of its slaves as well. Why not check

Re: Patch: RFC2863 #1 (incomplete)

2005-11-07 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-07 17:41 Can't we put the driver, stacked interface, etc. in charge for dropping packets which shouldn't be let through yet? I would favour this and have the dormant state limited to link layer responsibilities. Imagine this situation: +---+

Re: Patch: RFC2863 #1 (incomplete)

2005-11-07 Thread Thomas Graf
* Krzysztof Halasa [EMAIL PROTECTED] 2005-11-07 18:04 Thomas Graf [EMAIL PROTECTED] writes: void netif_carrier_on(struct net_device *dev) { + if ((dev-flags IFF_WAIT) + test_bit(__LINK_STATE_NOCARRIER, dev-state)) + netif_dormant_on(dev

Re: Patch: RFC2863 #1 (incomplete)

2005-11-07 Thread Thomas Graf
* Stefan Rompf [EMAIL PROTECTED] 2005-11-07 20:25 dose:~ # ip addr add 192.168.200.1/24 dev eth1 dose:~ # ip link set eth1 up dose:~ # ifconfig eth1 | fgrep UP UP BROADCAST MULTICAST MTU:1500 Metric:1 dose:~ # ip route show 192.168.200.0/24 192.168.200.0/24 dev eth1 proto kernel

Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion

2005-11-05 Thread Thomas Graf
* Patrick McHardy [EMAIL PROTECTED] 2005-11-05 05:28 The reason why all routes are deleted is because their prefered source addresses is the primary address. fn_flush_list should probably send the missing notifications for the deleted routes. Changing address promotion to not delete the other

Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion

2005-11-05 Thread Thomas Graf
Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_ any notification. Flushes do not generate notifications. The reason is technical: they are usually massive, do overflow buffer, get lost and listeners have to do painful resynchronization. The justification: they are

Re: LRO Patent vs. patent free TOE

2005-08-23 Thread Thomas Graf
* David S. Miller [EMAIL PROTECTED] 2005-08-23 09:15 There are actually some non-trivial issues wrt. this. We would need to loop inside of the packet scheduler, and netfilter, to do correct traffic classification and firewalling. But I guess we could deal with that by supporting chaining in

Re: LRO Patent vs. patent free TOE

2005-08-23 Thread Thomas Graf
* David S. Miller [EMAIL PROTECTED] 2005-08-23 10:35 Currently NETIF_F_SG drivers do not wake up the TX queue until MAX_SKB_FRAGS descriptors are ready, now they'll have to defer until (N * MAX_SKB_FRAGS) are available. And even for a low value of N like 3 this is a whopping _54_ TX

<    4   5   6   7   8   9   10   >