* 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 add
* 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 t
* jamal <[EMAIL PROTECTED]> 2006-05-31 08:20
> The challenge is how to inform SELinux of these permissions.
> The access limit could be done by putting a SELinux hook at the time the
> skb gets to the generic netlink code?
> Note: There's actually two things that can be classified for access
> con
* 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, regard
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/net
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
* 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 shou
* 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
* 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'l
> > 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 adde
* jamal <[EMAIL PROTECTED]> 2005-12-07 07:56
> How is this different, conceptually, from any other flag setting being
> lost - for example a promisc or admin up/down?
> In other words if you want to reliably transmit state, shouldnt the
> "responsible system" have to worry about the reliability?
>
Stefan,
This looks better with every iteration, I'm still lacking a few minor
things though:
The implementation of the rule "if admin status down operational status
should be down" only exists in the sysfs code. I would absolutely favour
one clear interface representing the operational status of
* 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 mess
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_fron
* 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 be
* 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 w
* 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
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2005-11-18 09:47
> In article <[EMAIL PROTECTED]> (at Fri, 18 Nov 2005 08:44:27 +0800), Yan
> Zheng <[EMAIL PROTECTED]> says:
>
> > I get follow message when switch to single user mode and the kernel version
> > is 2.6.15-rc1-git5.
> :
> > No
* 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 mad
* Pekka Savola <[EMAIL PROTECTED]> 2005-11-16 12:46
> On Mon, 14 Nov 2005, John W. Linville wrote:
> > http://people.redhat.com/linville/kernels/fedora-netdev/
>
> I guess the test can be termed a 'success' because after updating from
> 2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 1
> 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]
* jamal <[EMAIL PROTECTED]> 2005-11-13 10:09
> Issue-1)
> We have agreed to implement based on 2863.
> Stefan has gone one step further and suggested extra states for L3
> status. The idea for the extra states being to resolve in this fix old
> standing issue (since 2.2 days) of higher metric rout
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/ipv6/route.c
===
--- net-2.6.orig/net/ipv6/route.c
+++ net-2.6/net/ipv6/route.c
@@ -1732,7 +1732,7 @@ int inet6_dump_fib(struct sk_buf
* Herbert Xu <[EMAIL PROTECTED]> 2005-11-12 15:15
> The recent change to netlink dump "done" callback handling broke IPv6
> which played dirty tricks with the "done" callback. This causes an
> infinite loop during a dump.
Absolutely right, thanks.
-
To unsubscribe from this list: send the line "u
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 19:46
> fib_disable_ip() evicts all routes pointing to that interface, including
> userspace generated ones, doesn't it? If so, we don't get away that easy.
Right, the patch represents Jamal's interpretation. Once in a while
I please him by providing
* 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
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-10 10:45
> from inspection: Whats wrong with what netif_carrier_ok() tells you?
> i.e to extrapolate what you have (it seems to be out
> fib_netdev_event())- something along:
>
> case NETDEV_CHANGE:
> rt_cache_flush(0);
>
* 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.
>
> Forgo
* 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 t
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/Ma
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 li
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
===
--- n
.
The resulting netlink code should be smaller, less error prone
and easier to understand.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/attr.c
===
--- /dev/null
+++ net-2.6/net/netlink/attr.c
@@ -0,0
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
#include
#include
+#i
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
#include
#include
-#include
#i
setting
the error pointer to 0 in which case netlink_run_queue() will
return with a qlen != 0.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/af_netlink.c
===
--- net-2.6.orig/net/netlink/af_net
* 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
> > 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_DOW
* 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 */
> + OPER
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-09 22:02
> My main concern here are dial on demand interfaces. Routes pointing to them
> must be considered even if the interface is !OPER_UP. Routes pointing to
> "permanent" interfaces in !OPER_UP should not.
Right, we do need a dormant state with all
* 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
t
* 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
> &
> > 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 a
g
--- a/ChangeLog 2005-03-19 00:49:52 +01:00
+++ 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-
* 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. H
* Hasso Tepper <[EMAIL PROTECTED]> 2005-11-08 15:39
> The same is true for any OSPF link. Only periodical hellos are used for
> that in standard case. Demand circuits are there to suppress periodical
> hellos and link state update refreshes - ie. if there is no real
> application traffic going over
* Hasso Tepper <[EMAIL PROTECTED]> 2005-11-08 14:55
> Thomas Graf wrote:
> > Then how are you going to implement OSPF which has its own link state
> > detection?
>
> OSPF doesn't have any link state detection. If carrier is up, hello
> packets are sent out to th
* Thomas Graf <[EMAIL PROTECTED]> 2005-11-05 14:46
> Assuming this is a separate bug, I'm not sure if this is the right
> way to fix it. I think it would be better to rewrite the preferred
> source address of all related local routes and only perform a
> remove-and-add o
* 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
* 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_NOCARRI
* 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:
>
* 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 che
> > 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
* 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 o
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 10:48
> @@ -1508,7 +1508,7 @@ fn_trie_lookup(struct fib_table *tb, con
> continue;
> }
> if (IS_LEAF(n)) {
> - if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
> res, &ret))
>
* 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
* 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 chain
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-22 23:38
> @@ -1364,7 +1365,7 @@ fn_trie_lookup(struct fib_table *tb, con
> }
>
> if (IS_LEAF(n)) {
> - if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
> res, &ret))
> + if ((re
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -588,33 +588,35 @@ struct lookup_args {
struct in6_addr
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -617,11 +617,10 @@ static inline struct fib6_node *fib6_des
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -198,6 +198,10 @@ static __inline__ void rt6_release
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -623,18 +623,12 @@ static struct fib6_node * fib6_lo
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/include/net/ip6_fib.h
===
--- net-2.6.14.orig/include/net/ip6_fib.h
+++ net-2.6.14/include/net/ip6_fib.h
@@ -124,6 +124,11 @@ struct rt6_statistics {
#define RT
Collection of cleanups for fib6_lookup() that used to live in my tree
for a while now.
Yoshfuji-san, what's the plan for CONFIG_IPV6_SUBTREES? Is MIPL
going to use it or can we remove it? For now I manually compiled
with CONFIG_IPV6_SUBTREES=1 but I have no idea how to actually
test it.
-
To unsu
cking
requirements of qdisc_destroy() but since the qdisc could
never be seen by the outside world this doesn't matter
and it can stay as-is until the locking of pkt_sched
is cleaned up.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/sch
* David S. Miller <[EMAIL PROTECTED]> 2005-08-22 10:07
> I don't want to create too much conflicts with your MIPV6
> work. Would you prefer to integrate Thomas's cleanups into
> your tree? Please let me know.
We can also wait and I'll merge those patches once you're
both in sync again, no proble
Pablo,
* Pablo Neira <[EMAIL PROTECTED]> 2005-08-20 16:35
> Attached the implementation of the Boyer-Moore[1] string search
> algorithm for brand new textsearch infrastructure.
Are you aware that this implementation is only correct under
the assumption that a pattern is never spread over mutlipl
* Thomas Graf <[EMAIL PROTECTED]> 2005-08-20 15:44
> I can't see how a <= b <= c can be enforced in less than two
> branches.
Without using a flag risking to have 4 branches when there is
no such thing as cmov that is.
-
To unsubscribe from this list: send the line &quo
* Andi Kleen <[EMAIL PROTECTED]> 2005-08-20 03:33
> On Sat, Aug 20, 2005 at 03:14:15AM +0200, Thomas Graf wrote:
> > + len = ntohs(iph->tot_len);
> > + if (skb->len < len || len < (iph->ihl*4))
> > + goto inhdr_error;
>
> If you re
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -333,16 +333,16 @@ drop:
static inline int ip_rcv_finish(
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -361,6 +361,7 @@ drop:
int ip_rcv(struct sk_buff *skb,
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/include/asm-i386/checksum.h
===
--- net-2.6.14.orig/include/asm-i386/checksum.h
+++ net-2.6.14/include/asm-i386/checksum.h
@@ -83,7 +83,7 @@ static inline un
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -400,7 +400,7 @@ int ip_rcv(struct sk_buff *skb, st
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -279,6 +279,58 @@ int ip_local_deliver(struct sk_buf
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_output.c
===
--- net-2.6.14.orig/net/ipv4/ip_output.c
+++ net-2.6.14/net/ipv4/ip_output.c
@@ -200,7 +200,7 @@ static inline int ip_finish_output
* David S. Miller <[EMAIL PROTECTED]> 2005-08-14 17:56
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 15 Aug 2005 10:42:44 +1000
>
> > Well I don't think I understand the new skb->user solution yet :)
> >
> > For a start, skb->users will prevent the skb->data area from being
> > freed as wel
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-14 15:30
> Thomas Graf wrote:
> > * Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:36
> >
> >>[NETLINK]: Support dynamic number of multicast groups per netlink family
> >>
> >>Signed-off-by: Pat
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:35
> besides a small bugfix, this patchset adds support for dynamic number
> of groups to netlink. To support an arbitary number of groups a couple
> of changes had to me made, I'll explain them below. The patches are
> only sent to netdev to avoi
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:36
> [NETLINK]: Support dynamic number of multicast groups per netlink family
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
> - if ((err = __netlink_create(sock, protocol) < 0))
> + nlk->groups = kmalloc(NLGRPSZ(groups), GFP_
* David S. Miller <[EMAIL PROTECTED]> 2005-08-13 14:10
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Sat, 13 Aug 2005 11:32:39 +1000
>
> > I actually had a play with the fast clone stuff. However, eventually
> > I gave up because of this dilemma: I needed to either introduce an extra
> > atomic
* David S. Miller <[EMAIL PROTECTED]> 2005-08-13 15:20
> From: Tommy Christensen <[EMAIL PROTECTED]>
> > First thing I'd try is to remove the ! from these two tests.
>
> Duh, thanks for catching that obvious error :-)
I guess my mind was or still is lost in the woods of Alaska.
-
To unsubscribe f
* Ralf Baechle <[EMAIL PROTECTED]> 2005-08-12 14:39
> On Fri, Aug 12, 2005 at 02:27:59PM +0100, Ralf Baechle wrote:
>
> > > Something I noticed doing the tty work. the 6pack driver calls
> > > netif_start_queue() before it calls register_netdev. I'm curious if this
> > > is allowed ?
> >
> > As p
* Herbert Xu <[EMAIL PROTECTED]> 2005-08-08 21:49
> On Mon, Aug 08, 2005 at 12:46:30PM +0200, Patrick McHardy wrote:
> >
> > part on top of netlink). Right now there are none, so this won't cause
> > any trouble, the question is if we want to retain the possibility or
> > just don't care about this
* Anand SVR <[EMAIL PROTECTED]> 2005-08-08 15:07
> I am happy to know that there is a way of achieving http level packet
> classification once the connection tracking is also in place. We can
> even think of other string combinations for url based classification,
> not just what I mentioned in my
* Harald Welte <[EMAIL PROTECTED]> 2005-08-07 17:03
> On Sun, Aug 07, 2005 at 01:20:39PM +0200, Thomas Graf wrote:
> > Same very minor issues as nfnetlink regarding some of the
> > new netlink message construction policies. I'll "fix" them
> > du
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-08-07 15:19
> On Sun, Aug 07, 2005 at 01:12:19PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > I don't get this, you introduce a new option which basically
> > changes the subscription schema from a bitmask to a singl
* Harald Welte <[EMAIL PROTECTED]> 2005-07-30 12:30
> This (long-awaited) patch adds the generic nfnetlink-based userspace
> logging. nfnetlink_log can be used for any protocol family, and
> supports upt to 65535 logging groups (that could go to separate logging
> daemons, e.g.).
Same very minor
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-07-29 14:45
> Subscription is a netlink socket option, which, if enabled, ends up
> in direct message delivering, but not multicast one.
I don't get this, you introduce a new option which basically
changes the subscription schema from a bitmask to a sing
* Anand SVR <[EMAIL PROTECTED]> 2005-07-27 23:17
> As a starting point, I would like to define classification rules such
> that web access to
> *.edu OR *.net OR *.org can be put under one bandwidth chunk. Public
> mail sites such as *.yahoo.com OR gmail.com OR *hotmail.com under a
> different ch
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-07-26 08:45
> On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
> > Usually netlink is easily extendable by using nested TLVs. By hiding
> > this you basically remove this extensibility.
>
> Current netlink is not ex
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 02:16
> Thomas Graf wrote:
> >* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
> >
> >>You still have to take care of mixed 64/32 bit environments, u64 fields
> >>for example are differently alli
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
> Netlink users don't have to care about shared or cloned skbs. I don't
> think its a big issue to use alloc_skb and then the usual netlink
> macros. Thomas added a number of macros that simplfiy use a lot.
Once I've finished the generic netli
* David S. Miller <[EMAIL PROTECTED]> 2005-07-25 16:18
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 01:11:13 +0200
>
> > Not sure but as I see it:
> ...
> > The __dev_get_by_index() can be expensive with
> > more than a 1k interfaces
* David S. Miller <[EMAIL PROTECTED]> 2005-07-25 15:56
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 00:35:05 +0200
>
> > We can also use ifindex and hold a reference. We won't access input_dev
> > too often so a __dev_get_by_ifin
* jamal <[EMAIL PROTECTED]> 2005-07-25 18:40
> On Tue, 2005-26-07 at 00:32 +0200, Thomas Graf wrote:
> > I was referring to the tc_verd & TC_NCLS check in tcf_action_exec()
> > which uses input_dev in a printk. I assume dave was referring to the
> > same code
* jamal <[EMAIL PROTECTED]> 2005-07-25 18:28
> So ifindex maybe the simplest way to go. If someone unloads a module
> for the netdevice then loads it back or pops out a hotplug net card
> and then pops it in - could we safely assume they are talking about
> another device? ;->
We can also use ifin
* jamal <[EMAIL PROTECTED]> 2005-07-25 18:22
> > The code block which uses input_dev is dead, TC_NCLS is never
> > set as of now. Jamal might have use for it though? Generally,
> > tcf_action_exec() may be called on both ingress and egress.
>
> I mentioned the meta action already; the dummy device
* David S. Miller <[EMAIL PROTECTED]> 2005-07-25 13:14
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Mon, 25 Jul 2005 22:05:21 +0200
>
> > The meta ematch which will the primary user of input_dev
> > provides both, filtering by ifindex and by name so I'm fi
* David S. Miller <[EMAIL PROTECTED]> 2005-07-25 11:46
> There is, of course, still the issue of refcounting. If we go
> the ifindex route for skb->input_dev, it might make sense to
> translate device specifications in action rules into ifindex.
> But things could break if you down then up a devic
* David S. Miller <[EMAIL PROTECTED]> 2005-07-25 12:09
> Ok, so can we agree on the following patch? ing_filter() should
> never see a NULL ->input_dev, and we could add a BUG() check
> there for that invariant if you want.
This looks good to me, a input_dev==NULL means the packets
origin is loca
901 - 1000 of 1030 matches
Mail list logo