On Mon, 2007-10-15 at 12:38 -0700, David Miller wrote:
> From: "Eliezer Tamir" <[EMAIL PROTECTED]>
> Date: Mon, 15 Oct 2007 17:27:29 +0200
>
> > Unfortunately, the firmware code is different for LE and BE machines.
> > We had issues with the BE firmware that appear to be resolved.
> > Hopefully, t
[IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi
Not every transform needs to zap ip_summed. For example, a pure tunnel
mode encapsulation does not affect the hardware checksum at all. In fact,
every algorithm (that needs this) other than AH6 already does its own
ip_summed zapping.
This pat
On Tue, Oct 16, 2007 at 09:33:15AM -0500, Eric Sandeen wrote:
>
> Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without
> a problem. Before, I'd oops every 5 or so times I booted...
>
> I now have another NIC in the box, disabled; I don't think that should
> be affecting anythi
[IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi
Currently xfrm6_rcv_spi gets the nexthdr value itself from the packet.
This means that we need to fix up the value in case we have a 4-on-6
tunnel. Moving this logic into the caller simplifies things and allows
us to merge the code with IPv4.
Sig
[IPSEC]: Move tunnel parsing for IPv4 out of xfrm4_input
This patch moves the tunnel parsing for IPv4 out of xfrm4_input and into
xfrm4_tunnel. This change is in line with what IPv6 does and will allow
us to merge the two input functions.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
inclu
[IPSEC]: Move type and mode map into xfrm_state.c
The type and mode maps are only used by SAs, not policies. So it makes
sense to move them from xfrm_policy.c into xfrm_state.c. This alos allows
us to mark xfrm_get_type/xfrm_put_type/xfrm_get_mode/xfrm_put_mode as
static.
The only other change
[IPSEC]: Store afinfo pointer in xfrm_mode
It is convenient to have a pointer from xfrm_state to address-specific
functions such as the output function for a family. Currently the
address-specific policy code calls out to the xfrm state code to get
those pointers when we could get it in an easier
[IPSEC]: Fix length check in xfrm_parse_spi
Currently xfrm_parse_spi requires there to be 16 bytes for AH and ESP.
In contrived cases there may not actually be 16 bytes there since the
respective header sizes are less than that (8 and 12 currently).
This patch changes the test to use the actual h
[IPSEC]: Use the top IPv4 route's peer instead of the bottom
For IPv4 we were using the bottom route's peer instead of the top one.
This is wrong because the peer is only used by TCP to keep track of
information about the TCP destination address which certainly does not
live in the bottom route.
[IPSEC]: Remove xfrmX_tunnel_check_size
These functions have always been causing trouble by sending ICMP errors
back to the local host which was totally confused about how to deal with
it and most often ended up causing a downward spiral which only finishes
when the MTU is so small that you can't
[IPSEC]: Disallow combinations of RO and AH/ESP/IPCOMP
Combining RO and AH/ESP/IPCOMP does not make sense. So this patch adds a
check in the state initialisation function to prevent this.
This allows us to safely remove the mode input function of RO since it
can never be called anymore. Indeed,
[IPSEC]: Reinject packet instead of calling netfilter directly on input
Currently we call netfilter directly on input after a series of transport
mode transforms (and BEET but that's a separate bug). This is inconsistent
because other parts of the stack such AF_PACKET cannot see the decapsulated
[NET]: Add netif_rerx_secpath
This patch follows on the netif_rerx addition. A number of tunnels reinject
packets back into the stack in the way of netif_rerx. They also need to
reset the security path since they're not part of the IPsec stack.
This patch creates the netif_rerx_secpath function
[IPSEC]: Fix pure tunnel modes involving IPv6
I noticed that my recent patch broke 6-on-4 pure IPsec tunnels (the ones
that are only used for incompressible IPsec packets). Subsequent reviews
show that I broke 6-on-6 pure tunnels more than three years ago and nobody
ever noticed. I suppose every
On Tue, Oct 16, 2007 at 04:39:56PM +0200, Patrick McHardy wrote:
>
> I think your patches didn't make it to netdev because the last
> address missed a closing '>'.
I think so too. I've just resent them to netdev only but
currently my mail server is being spammed so it's not sending
anything out.
On Oct 16 2007 10:30, Patrick McHardy wrote:
>> +static int match(const struct sk_buff *skb,
Potential symbol clash, name it ifgroup_match() for example.
>> + const struct net_device *in,
>> + const struct net_device *out,
>> + const struct xt_match *match,
>> + const void *
Herbert Xu wrote:
Hi Dave:
I was well on my way to merging the xfrm input path before I got
side-tracked by inter-family transforms :)
Anyway, here's a dump of what I've got. The one note-worthy bit
is the patch to reinject transport mode packets through netif_rx
rather than calling netfilter
Herbert Xu wrote:
[IPSEC]: Remove xfrmX_tunnel_check_size
These functions have always been causing trouble by sending ICMP errors
back to the local host which was totally confused about how to deal with
it and most often ended up causing a downward spiral which only finishes
when the MTU is so s
Herbert Xu wrote:
> David Mack <[EMAIL PROTECTED]> wrote:
>> If I understand the message Dave Jones sent yesterday, the patch you
>> mention *was* applied to the e100 driver in 2.6.23-6.fc8?
>
> Nope, he applied a different one which doesn't have the crucial
> part to disable NAPI polls before reg
On Tue, 2007-16-10 at 16:10 +0200, Patrick McHardy wrote:
> Herbert Xu wrote:
> > On Tue, Oct 16, 2007 at 09:22:31AM -0400, jamal wrote:
> >> Does the copying of tc_verd in __copy_skb_header() not cover that?
> >
> > Yep, I'm pretty sure it does.
> >
> > In fact this patch completely resolves my
On Tuesday 09 October 2007 10:21, Jan-Bernd Themann wrote:
> Roland Dreier <[EMAIL PROTECTED]> wrote on 03.10.2007 20:05:44:
> > > > Replace struct ibmebus_dev and struct ibmebus_driver with struct
of_device
> > > > and struct of_platform_driver, respectively. Match the external
ibmebus
> > >
Hi Dave:
I was well on my way to merging the xfrm input path before I got
side-tracked by inter-family transforms :)
Anyway, here's a dump of what I've got. The one note-worthy bit
is the patch to reinject transport mode packets through netif_rx
rather than calling netfilter directly.
Everythin
Herbert Xu wrote:
On Tue, Oct 16, 2007 at 09:22:31AM -0400, jamal wrote:
Does the copying of tc_verd in __copy_skb_header() not cover that?
Yep, I'm pretty sure it does.
In fact this patch completely resolves my concerns about tc_verd.
Indeed, I was looking at the wrong tree :)
-
To unsubs
Since we now allocate the queues in inet_fragment.c, we
can safely free it in the same place. The ->destructor
callback thus becomes optional for inet_frags.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 470b056..a75
Since this callback is used to check for conflicts in
hashtable when inserting a newly created frag queue, we can
do the same by checking for matching the queue with the
argument, used to create one.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/net/inet_frag.h b/i
On Tue, Oct 16, 2007 at 09:22:31AM -0400, jamal wrote:
>
> Does the copying of tc_verd in __copy_skb_header() not cover that?
Yep, I'm pretty sure it does.
In fact this patch completely resolves my concerns about tc_verd.
Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~
Here we need another callback ->match to check whether the
entry found in hash matches the key passed. The key used
is the same as the creation argument for inet_frag_create.
Yet again, this ->match is the same for netfilter and ipv6.
Running a frew steps forward - this callback will later
replac
This one uses the xxx_frag_intern() and xxx_frag_alloc()
routines, which are already consolidated, so remove them
from protocol code (as promised).
The ->constructor callback is used to init the rest of
the frag queue and it is the same for netfilter and ipv6.
Signed-off-by: Pavel Emelyanov <[EMA
Just perform the kzalloc() allocation and setup common
fields in the inet_frag_queue(). Then return the result
to the caller to initialize the rest.
The inet_frag_alloc() may return NULL, so check the
return value before doing the container_of(). This looks
ugly, but the xxx_frag_alloc() will be
This routine checks for the existence of a given entry
in the hash table and inserts the new one if needed.
The ->equal callback is used to compare two frag_queue-s
together, but this one is temporary and will be removed
later. The netfilter code and the ipv6 one use the same
routine to compare fr
Since the hash value is already calculated in xxx_find, we can
simply use it later. This is already done in netfilter code,
so make the same in ipv4 and ipv6.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
>From 5bcb464538cf504a9f6cf3be33dbd1a5ff18b693 Mon Sep 17 00:00:00 2001
From: Pa
This set concerns the xxx_find() routine only. This one
is used to obtain the fragment queue depending on some
criteria, and this can be consolidated.
The consolidation goes step-by-step, consolidating one
sub-routine at a time, so some functions, exports and
callbacks that are introduced in patc
On Tue, 2007-16-10 at 14:53 +0200, Patrick McHardy wrote:
> jamal wrote:
>
> [Can't quote for some reason ..]
Sorry, trying to be clever with git-format-patch but chickened out
sending using git-am - so patch was just attached (Dave seems to be
friendly to such an approach when he applies)
> I
On Tue, 2007-16-10 at 20:51 +0800, Herbert Xu wrote:
> But I still think the distinction between skb_clone and
> skb_copy_header is wrong.
>
> When you munge a packet, it's still going to go back up
> the stack and be processed along the same path. Therefore
> you should be calling pskb_expand_h
jamal wrote:
[Can't quote for some reason ..]
I don't think this change is safe since we might loose the
redirect counter and have endless redirect loops. ipip for
example calls skb_realloc_headroom, which clones the skb
when delta > 0, so it seems we really need to copy tc_verd
in skb_clone().
On Tue, Oct 16, 2007 at 08:33:31AM -0400, jamal wrote:
>
> +2) If you munge any packet thou shalt call skb_expand in the case
> +someone else is referencing the skb. After that you "own" the skb.
> +You must also tell us if it is ok to munge the packet (TC_OK2MUNGE),
> +this way any action downst
cheers,
jamal
[NET_DOC] Document some simple rules for actions
This patch adds documentation on what is expected of an
action which branches away from the action-graph or when it
needs to trample on actins. It also describes what is expected of
users of such actions.
Signed-off-by: Jamal Hadi Sa
cheers,
jamal
[NET_CLS_ACT] Use skb_act_clone
clean skb_clone of any signs of CONFIG_NET_CLS_ACT and
have mirred us skb_act_clone()
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
---
net/core/skbuff.c |7 ---
net/sched/act_mirred.c |2 +-
2 files changed, 1 insertions(+), 8
cheers,
jamal
[NET_CLS_ACT] Introduce skb_act_clone
Reworked skb_clone looks uglier with the single ifdef CONFIG_NET_CLS_ACT
This patch introduces skb_act_clone which will replace skb_clone
in tc actions
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
---
include/net/sch_generic.h | 15 +++
I am going to send three patches:
1) Introduces skb_act_clone
2) Uses skb_act_clone
3) documents expect behavior of actions in case of cloning or copying
skbs.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majo
On Tue, 2007-16-10 at 13:47 +0200, Laszlo Attila Toth wrote:
> Hm, the main problem (for me) is that it requires more then one value
> per net device and it should be limited. But if I say it is 5 for
> instance, anyone can say it is not enough for him.
Yes, those pesky humans, you give them an
In the NF_IP_POST_ROUTING hook function, how can I
tell that packet originated locally vs was forwarded ?
I need to hook NF_IP_POST_ROUTING not NF_IP_FORWARD.
I'd expect that 'net_device *in' argument to be not NULL for
forwarded packets.
But what I see is NULL for both forwarded and locally se
jamal írta:
On Tue, 2007-16-10 at 13:05 +0200, Laszlo Attila Toth wrote:
That sounds great but for what whould you like to use? It may help me
for the implementation.
For example i may want to add a tc rule to a group of interfaces.
tc BNF roughly looks like:
tc
Where targe is :=
It may
On Tue, 2007-16-10 at 13:05 +0200, Laszlo Attila Toth wrote:
> That sounds great but for what whould you like to use? It may help me
> for the implementation.
For example i may want to add a tc rule to a group of interfaces.
tc BNF roughly looks like:
tc
Where targe is :=
It may be useful t
jamal írta:
On Tue, 2007-16-10 at 11:03 +0200, Laszlo Attila Toth wrote:
Interfaces can be grouped and each group has an unique positive integer ID.
It can be set via ip link.
Feature request: Can you also implement a get operation. Perhaps
something that returns from the kernel a list of ifin
On Tue, 2007-16-10 at 11:03 +0200, Laszlo Attila Toth wrote:
> Interfaces can be grouped and each group has an unique positive integer ID.
> It can be set via ip link.
Feature request: Can you also implement a get operation. Perhaps
something that returns from the kernel a list of ifindices when o
On Tue, Oct 16, 2007 at 10:46:36AM +0200, Jean Delvare wrote:
>
> Thanks for the information. Now I'm worried that most people use
> netstat and not ss, while it seems that netstat doesn't have tcp_diag
> support. Would it make sense to add tcp_diag support to netstat? Or
> should we simply invite
On Mon, 2007-15-10 at 18:55 +0400, Alexey Kuznetsov wrote:
> Hello!
Didnt mean to wake you up Alexey ;->
> I see not so many places inside net/sched/act* where skb_clone is used.
> Exactly one in act_mirred.c, to be more exact. Did I miss something?
No you are right, thats the only spot at the m
On Mon, Oct 15, 2007 at 06:15:11PM -0700, Yanping Du wrote:
> Hi,
>
> We found the standard 16-bit tcp checksum is not
> strong enough in some cases. Is there any roadmap on
> implementing RFC1146 (tcp alternative checksum
> options) in Linux tcp stack ? If yes, how soon will
> that be in ?
If
Philip Craig írta:
Laszlo Attila Toth wrote:
Hello,
Different network interfaces can be grouped using the same group ID. With this
patch fewer netfilter rules are necessary but it may also be used by routing.
This allows an interface to belong to only one group. I expect there are
situations
Patrick McHardy írta:
Laszlo Attila Toth wrote:
+static int match(const struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ const struct xt_match *match,
+ const void *matchinfo,
+ int offset,
+ unsigned int protoff,
+ int *hot
Patrick McHardy írta:
Laszlo Attila Toth wrote:
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index c74440a..8e6a9a3 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -511,6 +511,11 @@ already configured.
@@ -1835,3 +1840,6 @@ was written by Alexey N. Kuznetsov and added in
Linux 2.2.
.SH AUTHO
Laszlo Attila Toth wrote:
+static int set_group(const char *dev, int ifgroup)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsgifi;
+ charbuf[256];
+ } req;
+ struct rtnl_handle rth;
+
+
Interfaces can be grouped and each group has an unique positive integer ID.
It can be set via ip link.
Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]>
---
include/linux/if_link.h |2 +
include/rt_names.h |2 +
ip/ipaddress.c |4 +++
ip/iplink.c | 49 +
On Tue, 2007-10-16 at 01:31 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 18:28:56 +1000
>
> > Allright, so that's an out of tree userland thingy... (which may well
> > work on ppc too I suppose). Definitely not installed by default by my
>
Hi Herbert,
On Sun, 14 Oct 2007 18:09:12 +0800, Herbert Xu wrote:
> Jean Delvare <[EMAIL PROTECTED]> wrote:
> >
> >> inet_diag is the preferred interface.
> >
> > How does it work? Is there some documentation available? I see
> > net/ipv4/inet_diag.c but I have no idea how to use it.
>
> Have a
Laszlo Attila Toth wrote:
> Hello,
>
> Different network interfaces can be grouped using the same group ID. With this
> patch fewer netfilter rules are necessary but it may also be used by routing.
This allows an interface to belong to only one group. I expect there are
situations where you want
Laszlo Attila Toth wrote:
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index c74440a..8e6a9a3 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -511,6 +511,11 @@ already configured.
@@ -1835,3 +1840,6 @@ was written by Alexey N. Kuznetsov and added in Linux 2.2.
.SH AUTHOR
Original Manpage by
Laszlo Attila Toth wrote:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 4756d58..18ff3c5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -646,6 +646,9 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct
net_device *dev,
if (dev->master)
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 18:28:56 +1000
> Allright, so that's an out of tree userland thingy... (which may well
> work on ppc too I suppose). Definitely not installed by default by my
> distro so IRQs from the network cards on all x86's using ubuntu g
Laszlo Attila Toth wrote:
+static int match(const struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ const struct xt_match *match,
+ const void *matchinfo,
+ int offset,
+ unsigned int protoff,
+ int *hotdrop)
+{
+ const
On Tue, 2007-10-16 at 00:44 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 17:29:47 +1000
>
> > Do you have any pointer to how that is done on x86 or sparc64 ?
>
> Sparc64 does it statically in the kernel.
>
> For x86, see http://irqbalanc
Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]>
---
include/linux/netfilter/xt_ifgroup.h | 11 +
net/netfilter/Kconfig| 16 +++
net/netfilter/Makefile |1 +
net/netfilter/xt_ifgroup.c | 78 ++
4 files c
Interfaces can be grouped and each group has an unique positive integer ID.
It can be set via ip link.
Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED](none)>
---
include/linux/if_link.h |2 +
include/rt_names.h |2 +
ip/ipaddress.c |4 +++
ip/iplink.c |
Hello,
Different network interfaces can be grouped using the same group ID. With this
patch fewer netfilter rules are necessary but it may also be used by routing.
The interface group (ifgroup) member of the net_device can be modified via
netlink (with iproute2) and it is used in the new 'ifgroup
Interface groups let handle different interfaces with one (netfilter) rule.
Modified net device structure and netlink interface.
Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]>
---
include/linux/if_link.h |2 ++
include/linux/netdevice.h |2 ++
net/core/rtnetlink.c |8 +
Jay Vosburgh wrote:
> Two small fixes to IPoIB support for bonding:
>
> 1- copy header_ops from slave to bonding for IPoIB slaves
> 2- move release and destroy logic to UNREGISTER from GOING_DOWN
> notifier to avoid double release
>
> Set bonding to version 3.2.1.
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 17:29:47 +1000
> Do you have any pointer to how that is done on x86 or sparc64 ?
Sparc64 does it statically in the kernel.
For x86, see http://irqbalance.org/
-
To unsubscribe from this list: send the line "unsubscribe netde
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 17:37:03 +1000
>
> On Tue, 2007-10-16 at 14:06 +0800, Herbert Xu wrote:
> > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > >
> > > Note: I use msleep_interruptible(1); just like napi_disable(). However
> > > I'm not to
> So the powerpc platform just honors the affinity mask, and depending on
> the PIC does things that range from nothing to spreading interrupts to
> CPUs in the affinity mask.
>
> All interrupts by defaults are spread to all CPUs (full balancing).
>
> At this stage, it's afaik userland business t
On Tue, 2007-10-16 at 14:06 +0800, Herbert Xu wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > Note: I use msleep_interruptible(1); just like napi_disable(). However
> > I'm not too happy that the "hot" loop that results of a pending signal
> > here will spin without even a cpu_r
Jumping on an old train ...
On Wed, 2007-09-12 at 05:50 -0700, David Miller wrote:
>
> > This would mean we have a problem on all SMP machines right now.
>
> This is not a correct statement.
>
> Only on your platform do network device interrupts get moved
> around, no other platform does this.
101 - 172 of 172 matches
Mail list logo
