* Re: GIT: net-*2.6 rebased...
From: Stephen Rothwell @ 2010-08-05 4:11 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100804.162141.15218463.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
Hi Dave,
On Wed, 04 Aug 2010 16:21:41 -0700 (PDT) David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>
> Please adhere to these rules, it helps keep the tree stable and
> preserve the limited sanity still remaining in folks like Stephen
> Rothwell. :-)
Now I am not sure if I should be insulted :-)
/me locks up all his sharp objects
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] igb.txt: Add igb documentation
From: Jeff Kirsher @ 2010-08-05 4:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, linux-kernel, gospo, bphilips
In-Reply-To: <1280889274.13192.565.camel@localhost>
0On Tue, Aug 3, 2010 at 19:34, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2010-08-03 at 17:15 -0700, Jeff Kirsher wrote:
> [...]
>> + Jumbo Frames
>> + ------------
>> + Jumbo Frames support is enabled by changing the MTU to a value larger than
>> + the default of 1500. Use the ifconfig command to increase the MTU size.
>> + For example:
>> +
>> + ifconfig eth<x> mtu 9000 up
>> +
>> + This setting is not saved across reboots.
>
> Not igb-specific.
>
> [...]
>> + Ethtool
>> + -------
>> + The driver utilizes the ethtool interface for driver configuration and
>> + diagnostics, as well as displaying statistical information. Ethtool
>> + version 3.0 or later is required for this functionality, although we
>> + strongly recommend downloading the latest version at:
>> +
>> + http://sourceforge.net/projects/gkernel.
>
> Not igb-specific, and seriously - 3.0?
>
>> + Enabling Wake on LAN* (WoL)
>> + ---------------------------
>> + WoL is configured through the Ethtool* utility.
>
> Not igb-specific.
>
> [...]
>> + LRO
>> + ---
>> + Large Receive Offload (LRO) is a technique for increasing inbound throughput
>> + of high-bandwidth network connections by reducing CPU overhead. It works by
>> + aggregating multiple incoming packets from a single stream into a larger
>> + buffer before they are passed higher up the networking stack, thus reducing
>> + the number of packets that have to be processed. LRO combines multiple
>> + Ethernet frames into a single receive in the stack, thereby potentially
>> + decreasing CPU utilization for receives.
>
> Not igb-specific.
>
>> + NOTE: LRO requires 2.6.24 or later kernel version.
> [...]
>
> Which is irrelevant to an in-tree driver.
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
Thanks for the review Ben.
I am fine and agree with removing the reference to Ethtool version 3.0
and reference to LRO requiring 2.6.24 kernel. Sorry we did not catch
the earlier...
As far as the 4 sections you noted as not being igb-specific, while
these sections are not specific to the driver, I see them as useful to
users trying to find more information on the driver and how to
configure it. IMHO more documentation is more useful that too little,
as long as you are not adding bloat to the documentation which makes
it difficult to find what you are looking for.
If I am in minority here, I fine with removing the non-igb specific
sections as well.
--
Cheers,
Jeff
^ permalink raw reply
* SCTP Bundling Timeout value in linux
From: Kiran P @ 2010-08-05 4:23 UTC (permalink / raw)
To: netdev
Hi,
Is there any SCTP bundling timeout value in linux?
When I checked the code and sysctl, I could find only sack timeout but
no bundling timeout..
--
Kiran
^ permalink raw reply
* Re: [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: David Miller @ 2010-08-05 4:54 UTC (permalink / raw)
To: bhutchings; +Cc: rusty, netdev, mst, izumi.taku
In-Reply-To: <1280980041.13192.628.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 05 Aug 2010 04:47:21 +0100
> On Thu, 2010-08-05 at 13:02 +0930, Rusty Russell wrote:
>> I often use "ethtool -i" command to check what driver controls the
>> ehternet device. But because current virtio_net driver doesn't
>> support "ethtool -i", it becomes the following:
>>
>> # ethtool -i eth3
>> Cannot get driver information: Operation not supported
>>
>> This patch simply adds the "ethtool -i" support. The following is the
>> result when using the virtio_net driver with my patch applied to.
>>
>> # ethtool -i eth3
>> driver: virtio_net
>> version: N/A
>> firmware-version: N/A
>> bus-info: virtio0
>>
>> Personally, "-i" is one of the most frequently-used option, and most
>> network drivers support "ethtool -i", so I think virtio_net also
>> should do.
> [...]
>
> This information is already available generically through sysfs:
> basename $(readlink /sys/class/net/eth3/device)
> basename $(readlink /sys/class/net/eth3/device/driver)
>
> Given that, we should either recommend that people use that method
> instead, or we should add an equivalent default implementation of the
> get_drvinfo operation.
We've had ethtool for nearly a decade, it's a standard facility and
it's only wise to have all drivers implement as much of the API as
possible.
As such I've applied Rusty's patch and I will apply any patch which
makes a driver more fully provide support for all ethtool facilities.
^ permalink raw reply
* Re: [PATCH] act_nat: fix on the TX path
From: David Miller @ 2010-08-05 4:54 UTC (permalink / raw)
To: herbert; +Cc: xiaosuo, hadi, netdev
In-Reply-To: <20100804070621.GB370@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 4 Aug 2010 15:06:21 +0800
> On Wed, Aug 04, 2010 at 11:39:18AM +0800, Changli Gao wrote:
>> On the TX path, skb->data points to the ethernet header, not the network
>> header. So when validating the packet length for accessing we should
>> take the ethernet header into account.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] RxRPC: Fix a potential deadlock between the call resend_timer and state_lock
From: David Miller @ 2010-08-05 4:55 UTC (permalink / raw)
To: dhowells; +Cc: netdev
In-Reply-To: <20100804123417.29580.95095.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 04 Aug 2010 13:34:17 +0100
> RxRPC can potentially deadlock as rxrpc_resend_time_expired() wants to get
> call->state_lock so that it can alter the state of an RxRPC call. However, its
> caller (call_timer_fn()) has an apparent lock on the timer struct.
>
> The problem is that rxrpc_resend_time_expired() isn't permitted to lock
> call->state_lock as this could cause a deadlock against rxrpc_send_abort() as
> that takes state_lock and then attempts to delete the resend timer by calling
> del_timer_sync().
>
> The deadlock can occur because del_timer_sync() will sit there forever waiting
> for rxrpc_resend_time_expired() to return, but the latter may then wait for
> call->state_lock, which rxrpc_send_abort() holds around del_timer_sync()...
>
> This leads to a warning appearing in the kernel log that looks something like
> the attached.
>
> It should be sufficient to simply dispense with the locks. It doesn't matter
> if we set the resend timer expired event bit and queue the event processor
> whilst we're changing state to one where the resend timer is irrelevant as the
> event can just be ignored by the processor thereafter.
...
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 1/4] sk_buff: introduce pskb_network_may_pull()
From: David Miller @ 2010-08-05 4:55 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, kaber, netdev
In-Reply-To: <1280933024-12132-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 4 Aug 2010 22:43:44 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/4] cls_flow: add sanity check for the packet length
From: David Miller @ 2010-08-05 4:55 UTC (permalink / raw)
To: kaber; +Cc: xiaosuo, hadi, netdev
In-Reply-To: <4C59915D.1020902@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 04 Aug 2010 18:12:13 +0200
> Am 04.08.2010 16:48, schrieb Changli Gao:
>> The packet length should be checked before the packet data is dereferenced.
>>
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH v2 3/4] cls_rsvp: add sanity check for the packet length
From: David Miller @ 2010-08-05 4:55 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, netdev
In-Reply-To: <1280933740-17480-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 4 Aug 2010 22:55:40 +0800
> The packet length should be checked before the packet data is dereferenced.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 4/4] sch_sfq: add sanity check for the packet length
From: David Miller @ 2010-08-05 4:55 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, netdev
In-Reply-To: <1280933939-17548-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 4 Aug 2010 22:58:59 +0800
> The packet length should be checked before the packet data is dereferenced.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ppp: make channel_ops const
From: David Miller @ 2010-08-05 4:56 UTC (permalink / raw)
To: shemminger; +Cc: paulus, linux-ppp, netdev
In-Reply-To: <20100804103436.72e234d6@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 4 Aug 2010 10:34:36 -0700
> The PPP channel ops structure should be const.
> Cleanup the declarations to use standard C99 format.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* [linux-next] build failure
From: divya @ 2010-08-05 5:32 UTC (permalink / raw)
To: LKML, linux-next, linuxppc-dev, netdev, jeffrey.t.kirsher
Yestersday's linux-next(2.6.35_next_20100802) build fails with the following error on both system p and x.
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_select_queue':
drivers/net/ixgbe/ixgbe_main.c:6159: error: 'struct ixgbe_fcoe' has no member named 'up'
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_xmit_frame':
drivers/net/ixgbe/ixgbe_main.c:6221: error: 'struct ixgbe_fcoe' has no member named 'up'
make[3]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1
make[2]: *** [drivers/net/ixgbe] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Thanks
Divya
^ permalink raw reply
* [PATCH 1/3 update] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: xeb @ 2010-08-05 5:48 UTC (permalink / raw)
To: netdev
This is patch 1/3 which contains gre demultiplexer driver source
for demultiplexing gre packets with different gre version.
Update: included forgotten net/ipv4/ip_gre.c
include/net/gre.h | 18 ++++++
net/ipv4/Kconfig | 7 +++
net/ipv4/Makefile | 1 +
net/ipv4/gre.c | 151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/ip_gre.c | 10 ++--
5 files changed, 182 insertions(+), 5 deletions(-)
diff --git a/include/net/gre.h b/include/net/gre.h
new file mode 100644
index 0000000..31a0f76
--- /dev/null
+++ b/include/net/gre.h
@@ -0,0 +1,18 @@
+#ifndef __LINUX_GRE_H
+#define __LINUX_GRE_H
+
+#include <linux/skbuff.h>
+
+#define GREPROTO_CISCO 0
+#define GREPROTO_PPTP 1
+#define GREPROTO_MAX 2
+
+struct gre_protocol {
+ int (*handler)(struct sk_buff *skb);
+ void (*err_handler)(struct sk_buff *skb, u32 info);
+};
+
+int gre_add_protocol(const struct gre_protocol *proto, u8 version);
+int gre_del_protocol(const struct gre_protocol *proto, u8 version);
+
+#endif
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 7c3a7d1..7458bda 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -215,8 +215,15 @@ config NET_IPIP
be inserted in and removed from the running kernel whenever you
want). Most people won't need this and can say N.
+config NET_IPGRE_DEMUX
+ tristate "IP: GRE demultiplexer"
+ help
+ This is helper module to demultiplex GRE packets on GRE version field criteria.
+ Required by ip_gre and pptp modules.
+
config NET_IPGRE
tristate "IP: GRE tunnels over IP"
+ depends on NET_IPGRE_DEMUX
help
Tunneling means encapsulating data of one protocol type within
another protocol and sending it over a channel that understands the
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index 80ff87c..4978d22 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
obj-$(CONFIG_IP_MROUTE) += ipmr.o
obj-$(CONFIG_NET_IPIP) += ipip.o
+obj-$(CONFIG_NET_IPGRE_DEMUX) += gre.o
obj-$(CONFIG_NET_IPGRE) += ip_gre.o
obj-$(CONFIG_SYN_COOKIES) += syncookies.o
obj-$(CONFIG_INET_AH) += ah4.o
diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
new file mode 100644
index 0000000..993f3cf
--- /dev/null
+++ b/net/ipv4/gre.c
@@ -0,0 +1,151 @@
+/*
+ * GRE over IPv4 demultiplexer driver
+ *
+ * Authors: Dmitry Kozlov (xeb@mail.ru)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kmod.h>
+#include <linux/skbuff.h>
+#include <linux/in.h>
+#include <linux/netdevice.h>
+#include <linux/version.h>
+#include <linux/spinlock.h>
+#include <net/protocol.h>
+#include <net/gre.h>
+
+
+const struct gre_protocol *gre_proto[GREPROTO_MAX] ____cacheline_aligned_in_smp;
+static DEFINE_RWLOCK(gre_proto_lock);
+
+int gre_add_protocol(const struct gre_protocol *proto, u8 version)
+{
+ int ret;
+
+ if (version >= GREPROTO_MAX)
+ return -1;
+
+ write_lock_bh(&gre_proto_lock);
+ if (gre_proto[version]) {
+ ret = -1;
+ } else {
+ gre_proto[version]=proto;
+ ret = 0;
+ }
+ write_unlock_bh(&gre_proto_lock);
+
+ return ret;
+}
+int gre_del_protocol(const struct gre_protocol *proto, u8 version)
+{
+ int ret;
+
+ if (version >= GREPROTO_MAX)
+ return -1;
+
+ write_lock_bh(&gre_proto_lock);
+ if (gre_proto[version] == proto) {
+ gre_proto[version] = NULL;
+ ret = 0;
+ } else {
+ ret = -1;
+ }
+ write_unlock_bh(&gre_proto_lock);
+
+ return ret;
+}
+static int gre_rcv(struct sk_buff *skb)
+{
+ u8 ver;
+ int ret;
+
+ if (!pskb_may_pull(skb, 12))
+ goto drop_nolock;
+
+ ver = skb->data[1]&0x7f;
+ if (ver >= GREPROTO_MAX)
+ goto drop_nolock;
+
+ read_lock(&gre_proto_lock);
+ if (!gre_proto[ver] || !gre_proto[ver]->handler)
+ goto drop;
+
+ ret = gre_proto[ver]->handler(skb);
+ read_unlock(&gre_proto_lock);
+
+ return ret;
+
+drop:
+ read_unlock(&gre_proto_lock);
+drop_nolock:
+ kfree_skb(skb);
+ return NET_RX_DROP;
+}
+static void gre_err(struct sk_buff *skb, u32 info)
+{
+ u8 ver;
+
+ printk("err\n");
+
+ if (!pskb_may_pull(skb, 12))
+ goto drop_nolock;
+
+ ver=skb->data[1];
+ if (ver>=GREPROTO_MAX)
+ goto drop_nolock;
+
+ read_lock(&gre_proto_lock);
+ if (!gre_proto[ver] || !gre_proto[ver]->err_handler)
+ goto drop;
+
+ gre_proto[ver]->err_handler(skb,info);
+ read_unlock(&gre_proto_lock);
+
+ return;
+
+drop:
+ read_unlock(&gre_proto_lock);
+drop_nolock:
+ kfree_skb(skb);
+}
+
+
+static struct net_protocol net_gre_protocol = {
+ .handler = gre_rcv,
+ .err_handler = gre_err,
+// .netns_ok=1,
+};
+
+static int __init gre_init(void)
+{
+ printk(KERN_INFO "GRE over IPv4 demultiplexor driver");
+
+ if (inet_add_protocol(&net_gre_protocol, IPPROTO_GRE) < 0) {
+ printk(KERN_INFO "gre: can't add protocol\n");
+ return -EAGAIN;
+ }
+
+ return 0;
+}
+
+static void __exit gre_exit(void)
+{
+ inet_del_protocol(&net_gre_protocol, IPPROTO_GRE);
+}
+
+module_init(gre_init);
+module_exit(gre_exit);
+
+MODULE_DESCRIPTION("GRE over IPv4 demultiplexer driver");
+MODULE_AUTHOR("D. Kozlov (xeb@mail.ru)");
+MODULE_LICENSE("GPL");
+EXPORT_SYMBOL_GPL(gre_add_protocol);
+EXPORT_SYMBOL_GPL(gre_del_protocol);
+
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 32618e1..f0391b3 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -44,6 +44,7 @@
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
+#include <net/gre.h>
#ifdef CONFIG_IPV6
#include <net/ipv6.h>
@@ -1276,10 +1277,9 @@ static void ipgre_fb_tunnel_init(struct net_device *dev)
}
-static const struct net_protocol ipgre_protocol = {
+static const struct gre_protocol ipgre_protocol = {
.handler = ipgre_rcv,
.err_handler = ipgre_err,
- .netns_ok = 1,
};
static void ipgre_destroy_tunnels(struct ipgre_net *ign, struct list_head *head)
@@ -1661,7 +1661,7 @@ static int __init ipgre_init(void)
if (err < 0)
return err;
- err = inet_add_protocol(&ipgre_protocol, IPPROTO_GRE);
+ err = gre_add_protocol(&ipgre_protocol, GREPROTO_CISCO);
if (err < 0) {
printk(KERN_INFO "ipgre init: can't add protocol\n");
goto add_proto_failed;
@@ -1681,7 +1681,7 @@ out:
tap_ops_failed:
rtnl_link_unregister(&ipgre_link_ops);
rtnl_link_failed:
- inet_del_protocol(&ipgre_protocol, IPPROTO_GRE);
+ gre_del_protocol(&ipgre_protocol, GREPROTO_CISCO);
add_proto_failed:
unregister_pernet_device(&ipgre_net_ops);
goto out;
@@ -1691,7 +1691,7 @@ static void __exit ipgre_fini(void)
{
rtnl_link_unregister(&ipgre_tap_ops);
rtnl_link_unregister(&ipgre_link_ops);
- if (inet_del_protocol(&ipgre_protocol, IPPROTO_GRE) < 0)
+ if (gre_del_protocol(&ipgre_protocol, GREPROTO_CISCO) < 0)
printk(KERN_INFO "ipgre close: can't remove protocol\n");
unregister_pernet_device(&ipgre_net_ops);
}
^ permalink raw reply related
* Re: [PATCH 3/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Dmitry Kozlov @ 2010-08-05 5:55 UTC (permalink / raw)
To: Bill Fink; +Cc: netdev
In-Reply-To: <20100804212251.59c08e58.billfink@mindspring.com>
On Wed, 4 Aug 2010 21:22:51 -0400 Bill Fink <billfink@mindspring.com> wrote:
> On Wed, 04 Aug 2010, xeb@mail.ru wrote:
>
> > This is patch 3/3 which contains MAINTAINERS file modification.
> >
> > ---
> > MAINTAINERS | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 02f75fc..313d829 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6450,6 +6450,20 @@ M: "Maciej W. Rozycki" <macro@linux-mips.org>
> > S: Maintained
> > F: drivers/serial/zs.*
> >
> > +GRE DEMULTIPLEXER DRIVER
> > +M: Dmitry Kozlov <xeb@mail.ru>
> > +L: linux-net@vger.kernel.org
>
> Shouldn't this also be:
>
> +L: netdev@vger.kernel.org
>
> just like the PPTP DRIVER entry below?
>
> -Bill
Seems like it should ... will be fixed.
^ permalink raw reply
* RE: can TCP send buffer be over used?
From: Leslie Rhorer @ 2010-08-05 7:20 UTC (permalink / raw)
To: 'Jack Zhang', linux-net, netdev
In-Reply-To: <AANLkTikWH8NQZ5CYN7ytPYg-tK=eXF=OgJn=cuAoVexO@mail.gmail.com>
> There is one part of your suggestion I'm not sure if I fully
> understand though... "the transmitter cannot be allowed to send more
> data without acknowledgement of receipt of all the sent data than the
> receiver can assemble in one chunk. " I take it as the transmitter
> cannot send data of more than the receive window size without ack of
> the sent data. Is that what you meant?
For TCP, yes. In general it is true of any protocol which
guarantees intact delivery of data. The far (Rx) end must be able to
assemble all the data in good order if no data is to be lost. If the far
end can only buffer N blocks of data and the transmitter sends N + 1 blocks
of data before the far end can properly assemble the chunk, then the far end
has to discard one of the blocks of data.
TCP employs a sliding window, so once N blocks of data have been
assembled by the Rx system, it sends and ACK for the Nth block back to the
Tx host, whereupon the Tx host moves up its pointer for the window's
starting position to N + 1, and continues transmitting until the end of the
window is reached. If the latency is very small and the link error free, it
may never reach the end of the window, and the transfer will proceed at wire
speed. Otherwise, the near host transmits until it reaches the end of the
buffer whose size has been negotiated between the near and far system, and
then waits for an acknowledgement from the far end. When it comes, it may
not be an acknowledgement for the 1st block of data in the window, but
rather for some number of blocks, or perhaps even the entire window.
However many blocks are acknowledged, the Tx system moves its window pointer
up by that many blocks, and transmission begins again.
> > 3. Your measurement is based upon transfers that are too small in
> extent.
>
> I was transferring 1 GB data over the 100 Mbps link. Do you think if I
> should increase the size of the transfer?
No. As long as the file size is large compared to the maximum
window size, the measurement should be valid. A file size of 1G is very
large compared to 128K.
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Arnd Hannemann @ 2010-08-05 7:57 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, sfr-3FnU+UHB4dNDw9hX6IcOSA
In-Reply-To: <20100804.162141.15218463.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi,
Am 05.08.2010 01:21, schrieb David Miller:
>
> Both net-2.6 and net-next-2.6 have been rebased.
>
> To be honest, if you've been pulling from my tree you can just keep
> doing so if you want, it will look just as if I had merged Linus's
> tree into net-2.6 et al.
I there something broken with the trees on git.kernel.org?
if I try to fetch from net-next-2.6, I get:
fatal: The remote end hung up unexpectedly
if I try to clone net-2.6:
(e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
I get lots of errors reading the tags "does not point to a valid object!" and then:
remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
I'm using git version 1.7.1.
Best regards,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Changli Gao @ 2010-08-05 8:02 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, sfr-3FnU+UHB4dNDw9hX6IcOSA
In-Reply-To: <4C5A6EFE.7040703-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
On Thu, Aug 5, 2010 at 3:57 PM, Arnd Hannemann <arnd-BCMAnToX5e2ELgA04lAiVw@public.gmane.org> wrote:
> Hi,
>
> Am 05.08.2010 01:21, schrieb David Miller:
>>
>> Both net-2.6 and net-next-2.6 have been rebased.
>>
>> To be honest, if you've been pulling from my tree you can just keep
>> doing so if you want, it will look just as if I had merged Linus's
>> tree into net-2.6 et al.
>
> I there something broken with the trees on git.kernel.org?
>
> if I try to fetch from net-next-2.6, I get:
> fatal: The remote end hung up unexpectedly
>
> if I try to clone net-2.6:
> (e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> I get lots of errors reading the tags "does not point to a valid object!" and then:
> remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
> remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
>
> I'm using git version 1.7.1.
>
me 2 for net-next-2.6
localhost linux # git pull
fatal: The remote end hung up unexpectedly
localhost linux # git version
git version 1.7.1
--
Regards,
Changli Gao(xiaosuo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] usbnet: remove noisy and hardly useful printk
From: Christian Samsel @ 2010-08-05 8:14 UTC (permalink / raw)
To: netdev; +Cc: dhollis, Christian Samsel
With turned on hspa modem (Dell 5530 internal card) and activated usb auto
suspend, my system gets up 100 "usbnet_resume has delayed data" per
minute. I didnt noticed any pathological behaviour, so just drop
this message. if any objections, please at least change it to _DEBUG.
Signed-off-by: Christian Samsel <christian.samsel@rwth-aachen.de>
---
drivers/net/usb/usbnet.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 3b03794..7f62e2d 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1457,7 +1457,6 @@ int usbnet_resume (struct usb_interface *intf)
spin_lock_irq(&dev->txq.lock);
while ((res = usb_get_from_anchor(&dev->deferred))) {
- printk(KERN_INFO"%s has delayed data\n", __func__);
skb = (struct sk_buff *)res->context;
retval = usb_submit_urb(res, GFP_ATOMIC);
if (retval < 0) {
--
1.7.2
^ permalink raw reply related
* Re: GIT: net-*2.6 rebased...
From: David Miller @ 2010-08-05 8:46 UTC (permalink / raw)
To: arnd-BCMAnToX5e2ELgA04lAiVw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, sfr-3FnU+UHB4dNDw9hX6IcOSA
In-Reply-To: <4C5A6EFE.7040703-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
From: Arnd Hannemann <arnd-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
Date: Thu, 05 Aug 2010 09:57:50 +0200
> if I try to fetch from net-next-2.6, I get:
> fatal: The remote end hung up unexpectedly
>
> if I try to clone net-2.6:
> (e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> I get lots of errors reading the tags "does not point to a valid object!" and then:
> remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
> remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
Hmmm, since I can I tried an ssh based clone and it works.
But indeed if I try to use the git:// URL it fails.
Oh I see, the alternates files in those repos are completely broken.
They have:
/home/davem/git/../torvalds/linux-2.6.git/objects
/home/davem/git is a symlink to /pub/scm/linux/kernel/git/davem
so if I login and "cd git" then:
git clone --shared --bare ../torvalds/linux-2.6.git net-next-2.6.git
which is how I always create my trees, we get that unusable 'alternates'
path above.
The ".." works when my GIT directory is the working directory, but
not as part of the symlink include path to get there.
I fixed the alternates file but it will take some time for the fix
to propagate from master.kernel.org
Let me know if it doesn't work even after an hour or so.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
From: Xin, Xiaohui @ 2010-08-05 8:52 UTC (permalink / raw)
To: Xin, Xiaohui, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1280402088-5849-1-git-send-email-xiaohui.xin@intel.com>
Herbert,
The v8 patches are modified mostly based on your comments about
napi_gro_frags interface. How do you think about the patches about
net core system part?
We know currently there are some comments about the mp device,
such as to support zero-copy for tun/tap and macvtap. Since there
isn't a decision yet about it. May you give comments about the
net core system first, since this part is all the same for zero-copy.
Thanks
Xiaohui
>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On
>Behalf Of xiaohui.xin@intel.com
>Sent: Thursday, July 29, 2010 7:15 PM
>To: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mst@redhat.com; mingo@elte.hu; davem@davemloft.net; herbert@gondor.apana.org.au;
>jdike@linux.intel.com
>Subject: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
>
>We provide an zero-copy method which driver side may get external
>buffers to DMA. Here external means driver don't use kernel space
>to allocate skb buffers. Currently the external buffer can be from
>guest virtio-net driver.
>
>The idea is simple, just to pin the guest VM user space and then
>let host NIC driver has the chance to directly DMA to it.
>The patches are based on vhost-net backend driver. We add a device
>which provides proto_ops as sendmsg/recvmsg to vhost-net to
>send/recv directly to/from the NIC driver. KVM guest who use the
>vhost-net backend may bind any ethX interface in the host side to
>get copyless data transfer thru guest virtio-net frontend.
>
>patch 01-10: net core and kernel changes.
>patch 11-13: new device as interface to mantpulate external buffers.
>patch 14: for vhost-net.
>patch 15: An example on modifying NIC driver to using napi_gro_frags().
>patch 16: An example how to get guest buffers based on driver
> who using napi_gro_frags().
>
>The guest virtio-net driver submits multiple requests thru vhost-net
>backend driver to the kernel. And the requests are queued and then
>completed after corresponding actions in h/w are done.
>
>For read, user space buffers are dispensed to NIC driver for rx when
>a page constructor API is invoked. Means NICs can allocate user buffers
>from a page constructor. We add a hook in netif_receive_skb() function
>to intercept the incoming packets, and notify the zero-copy device.
>
>For write, the zero-copy deivce may allocates a new host skb and puts
>payload on the skb_shinfo(skb)->frags, and copied the header to skb->data.
>The request remains pending until the skb is transmitted by h/w.
>
>We provide multiple submits and asynchronous notifiicaton to
>vhost-net too.
>
>Our goal is to improve the bandwidth and reduce the CPU usage.
>Exact performance data will be provided later.
>
>What we have not done yet:
> Performance tuning
>
>what we have done in v1:
> polish the RCU usage
> deal with write logging in asynchroush mode in vhost
> add notifier block for mp device
> rename page_ctor to mp_port in netdevice.h to make it looks generic
> add mp_dev_change_flags() for mp device to change NIC state
> add CONIFG_VHOST_MPASSTHRU to limit the usage when module is not load
> a small fix for missing dev_put when fail
> using dynamic minor instead of static minor number
> a __KERNEL__ protect to mp_get_sock()
>
>what we have done in v2:
>
> remove most of the RCU usage, since the ctor pointer is only
> changed by BIND/UNBIND ioctl, and during that time, NIC will be
> stopped to get good cleanup(all outstanding requests are finished),
> so the ctor pointer cannot be raced into wrong situation.
>
> Remove the struct vhost_notifier with struct kiocb.
> Let vhost-net backend to alloc/free the kiocb and transfer them
> via sendmsg/recvmsg.
>
> use get_user_pages_fast() and set_page_dirty_lock() when read.
>
> Add some comments for netdev_mp_port_prep() and handle_mpassthru().
>
>what we have done in v3:
> the async write logging is rewritten
> a drafted synchronous write function for qemu live migration
> a limit for locked pages from get_user_pages_fast() to prevent Dos
> by using RLIMIT_MEMLOCK
>
>
>what we have done in v4:
> add iocb completion callback from vhost-net to queue iocb in mp device
> replace vq->receiver by mp_sock_data_ready()
> remove stuff in mp device which access structures from vhost-net
> modify skb_reserve() to ignore host NIC driver reserved space
> rebase to the latest vhost tree
> split large patches into small pieces, especially for net core part.
>
>
>what we have done in v5:
> address Arnd Bergmann's comments
> -remove IFF_MPASSTHRU_EXCL flag in mp device
> -Add CONFIG_COMPAT macro
> -remove mp_release ops
> move dev_is_mpassthru() as inline func
> fix a bug in memory relinquish
> Apply to current git (2.6.34-rc6) tree.
>
>what we have done in v6:
> move create_iocb() out of page_dtor which may happen in interrupt context
> -This remove the potential issues which lock called in interrupt context
> make the cache used by mp, vhost as static, and created/destoryed during
> modules init/exit functions.
> -This makes multiple mp guest created at the same time.
>
>what we have done in v7:
> some cleanup prepared to suppprt PS mode
>
>what we have done in v8
> discarding the modifications to point skb->data to guest buffer directly.
> Add code to modify driver to support napi_gro_frags() with Herbert's comments.
> To support PS mode.
> Add mergeable buffer support in mp device.
> Add GSO/GRO support in mp deice.
> Address comments from Eric Dumazet about cache line and rcu usage.
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Jens Axboe @ 2010-08-05 9:02 UTC (permalink / raw)
To: Tejun Heo
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Linus Torvalds, stable@kernel.org
In-Reply-To: <4C598E6B.7050405@gmail.com>
On 2010-08-04 17:59, Tejun Heo wrote:
> bd_prepare_to_claim() incorrectly allowed multiple attempts for
> exclusive open to progress in parallel if the attempting holders are
> identical. This triggered BUG_ON() as reported in the following bug.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16393
>
> __bd_abort_claiming() is used to finish claiming blocks and doesn't
> work if multiple openers are inside a claiming block. Allowing
> multiple parallel open attempts to continue doesn't gain anything as
> those are serialized down in the call chain anyway. Fix it by always
> allowing only single open attempt in a claiming block.
>
> This problem can easily be reproduced by adding a delay after
> bd_prepare_to_claim() and attempting to mount two partitions of a
> disk.
>
> stable: only applicable to v2.6.35
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
> Cc: stable@kernel.org
Thanks Tejun, applied.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Markus Trippelsdorf @ 2010-08-05 9:17 UTC (permalink / raw)
To: Jens Axboe
Cc: Tejun Heo, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Linus Torvalds,
stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <4C5A7E33.3060101-5c4llco8/ftWk0Htik3J/w@public.gmane.org>
On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
> On 2010-08-04 17:59, Tejun Heo wrote:
> > bd_prepare_to_claim() incorrectly allowed multiple attempts for
> > exclusive open to progress in parallel if the attempting holders are
> > identical. This triggered BUG_ON() as reported in the following bug.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=16393
> >
> > __bd_abort_claiming() is used to finish claiming blocks and doesn't
> > work if multiple openers are inside a claiming block. Allowing
> > multiple parallel open attempts to continue doesn't gain anything as
> > those are serialized down in the call chain anyway. Fix it by always
> > allowing only single open attempt in a claiming block.
> >
> > This problem can easily be reproduced by adding a delay after
> > bd_prepare_to_claim() and attempting to mount two partitions of a
> > disk.
> >
> > stable: only applicable to v2.6.35
> >
> > Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Reported-by: Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> > Cc: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
>
> Thanks Tejun, applied.
It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb
--
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Jens Axboe @ 2010-08-05 9:20 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Tejun Heo, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Linus Torvalds,
stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <20100805091704.GA1772-joY5NpejW+Hx3b7vapvTcQ@public.gmane.org>
On 2010-08-05 11:17, Markus Trippelsdorf wrote:
> On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
>> On 2010-08-04 17:59, Tejun Heo wrote:
>>> bd_prepare_to_claim() incorrectly allowed multiple attempts for
>>> exclusive open to progress in parallel if the attempting holders are
>>> identical. This triggered BUG_ON() as reported in the following bug.
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16393
>>>
>>> __bd_abort_claiming() is used to finish claiming blocks and doesn't
>>> work if multiple openers are inside a claiming block. Allowing
>>> multiple parallel open attempts to continue doesn't gain anything as
>>> those are serialized down in the call chain anyway. Fix it by always
>>> allowing only single open attempt in a claiming block.
>>>
>>> This problem can easily be reproduced by adding a delay after
>>> bd_prepare_to_claim() and attempting to mount two partitions of a
>>> disk.
>>>
>>> stable: only applicable to v2.6.35
>>>
>>> Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Reported-by: Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
>>> Cc: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
>>
>> Thanks Tejun, applied.
>
> It's already in mainline:
> e75aa85892b2ee78c79edac720868cbef16e62eb
Irk, had not noticed yet, my for-2.6.36 branch isn't fully merged
up yet. Thanks for the heads-up.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Michael Leun @ 2010-08-05 9:25 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev, davem, linux-kernel
In-Reply-To: <m1lj8l29zm.fsf@fess.ebiederm.org>
Hi,
On Wed, 04 Aug 2010 17:12:29 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
First, thank you very much for picking that up (and, of course, for
your work at linux in general).
> > # > unshare -n /bin/bash
> > # > # how to setup veth device pair to get connectivity into
> > namespace not shown here # > openvpn --config some.config
> > [ running some traffic over vpn device not shown here ]
> > ^c # stopping openvpn
> > # > lsof -i
> > # > netstat -an
> > Active Internet connections (servers and established)
> > Proto Recv-Q Send-Q Local Address Foreign Address
> > State Active UNIX domain sockets (servers and established)
> > Proto RefCnt Flags Type State I-Node Path
> > # > ps ax|grep openvpn|grep -v grep
> > # > # cannot find anything that suggests there is anything left
> > from that openvpn session # > exit # logging out from shell in
> > network namespace
> >
> > Now I get
> >
> > Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo
> > to become free. Usage count = 3 [repeated]
>
> How many times?
Unfortunately looks like indefinitely. Never watched longer so far
(rebooted soon), but I'm seeing this message now repeated every 10 secs
for ~10 minutes on a idle system.
Additionally when testing this I found another one (by accident started
my firewall script in that namespace...) - using netfilter RECENT
makes it barf. Stripped down to the essentials it looks like this:
> # unshare -n /bin/bash
> # iptables -I INPUT -d 1.2.3.4 -m recent --name BLA --set
> # exit
Aug 5 11:19:47 doris kernel: [ 218.420238] ------------[ cut here ]------------
Aug 5 11:19:47 doris kernel: [ 218.420256] kernel BUG at net/netfilter/xt_recent.c:609!
Aug 5 11:19:47 doris kernel: [ 218.420268] invalid opcode: 0000 [#1] PREEMPT SMP
Aug 5 11:19:47 doris kernel: [ 218.420284] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/charge_full
Aug 5 11:19:47 doris kernel: [ 218.420295] Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ipt_REJECT ipt_LOG xt_limit xt_recent iptable_mangle iptable_nat iptable_filter nf_conntrack_ipv6 xt_state xt_tcpudp ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack ip_tables x_tables fuse nls_utf8 loop arc4 ecb iwlagn iwlcore mac80211 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm cfg80211 snd_timer snd usb_storage iTCO_wdt soundcore tg3 sg iTCO_vendor_support snd_page_alloc rfkill i2c_i801 pcspkr battery ac ext4 jbd2 crc16 sha256_generic aes_generic cbc dm_crypt linear i915 drm_kms_helper drm i2c_algo_bit sd_mod video
intel_agp button dm_snapshot dm_mod fan processor ata_piix ahci libahci libata scsi_mod thermal thermal_sys
Aug 5 11:19:47 doris kernel: [ 218.420529]
Aug 5 11:19:47 doris kernel: [ 218.420542] Pid: 13, comm: netns Not tainted 2.6.35 #2 Kuril /40684JG
Aug 5 11:19:47 doris kernel: [ 218.420557] EIP: 0060:[<fc886a15>] EFLAGS: 00010206 CPU: 0
Aug 5 11:19:47 doris kernel: [ 218.420578] EIP is at recent_net_exit+0x55/0x70 [xt_recent]
Aug 5 11:19:47 doris kernel: [ 218.420589] EAX: f2218000 EBX: f5b79290 ECX: f2f27b40 EDX: f5cd4000
Aug 5 11:19:47 doris kernel: [ 218.420601] ESI: f2218000 EDI: f5cd5f44 EBP: f5cd5f28 ESP: f5cd5f20
Aug 5 11:19:47 doris kernel: [ 218.420612] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Aug 5 11:19:47 doris kernel: [ 218.420626] Process netns (pid: 13, ti=f5cd4000 task=f5cc9920 task.ti=f5cd4000)
Aug 5 11:19:47 doris kernel: [ 218.420635] Stack:
Aug 5 11:19:47 doris kernel: [ 218.420641] f5cd5f30 fc887618 f5cd5f3c c130867d fc887618 f5cd5f44 c1308850 f5cd5f60
Aug 5 11:19:47 doris kernel: [ 218.420667] <0> c1308919 f2218014 f2218014 f221800c f221800c c15915a0 c3bb4f40 c1308850
Aug 5 11:19:47 doris kernel: [ 218.420695] <0> f5cd5fbc c105a230 c13d1658 00000001 00000000 f7048000 c160f500 f5cc9c00
Aug 5 11:19:47 doris kernel: [ 218.420724] Call Trace:
Aug 5 11:19:47 doris kernel: [ 218.420749] [<c130867d>] ? ops_exit_list+0x1d/0x50
Aug 5 11:19:47 doris kernel: [ 218.420766] [<c1308850>] ? cleanup_net+0x0/0x160
Aug 5 11:19:47 doris kernel: [ 218.420782] [<c1308919>] ? cleanup_net+0xc9/0x160
Aug 5 11:19:47 doris kernel: [ 218.420797] [<c1308850>] ? cleanup_net+0x0/0x160
Aug 5 11:19:47 doris kernel: [ 218.420815] [<c105a230>] ? worker_thread+0x110/0x250
Aug 5 11:19:47 doris kernel: [ 218.420832] [<c13d1658>] ? schedule+0x748/0x7a0
Aug 5 11:19:47 doris kernel: [ 218.420849] [<c105d5f0>] ? autoremove_wake_function+0x0/0x40
Aug 5 11:19:47 doris kernel: [ 218.420864] [<c105a120>] ? worker_thread+0x0/0x250
Aug 5 11:19:47 doris kernel: [ 218.420879] [<c105d1bc>] ? kthread+0x6c/0x80
Aug 5 11:19:47 doris kernel: [ 218.420895] [<c105d150>] ? kthread+0x0/0x80
Aug 5 11:19:47 doris kernel: [ 218.420910] [<c1003336>] ? kernel_thread_helper+0x6/0x10
Aug 5 11:19:47 doris kernel: [ 218.420919] Code: 91 08 89 e2 81 e2 00 e0 ff ff 83 6a 14 01 f6 42 08 08 75 19 3b 1b 75 13 ba fa 72 88 fc e8 94 3e 8c c4 8d 64 24 04 5b 5d c3 0f 0b <0f> 0b 89 45 f8 e8 a1 ad b4 c4 8b 45 f8 eb da 8d b6 00 00 00 00
Aug 5 11:19:47 doris kernel: [ 218.421063] EIP: [<fc886a15>] recent_net_exit+0x55/0x70 [xt_recent] SS:ESP 0068:f5cd5f20
Aug 5 11:19:47 doris kernel: [ 218.421136] ---[ end trace f57524f15f4df616 ]---
--
MfG,
Michael Leun
^ permalink raw reply
* [PATCH v2 1/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Dmitry Kozlov @ 2010-08-05 9:36 UTC (permalink / raw)
To: netdev
This is patch 1/3 which contains gre demultiplexer driver source
for demultiplexing gre packets with different gre version.
---
include/net/gre.h | 18 +++++++
net/ipv4/Kconfig | 7 +++
net/ipv4/Makefile | 1 +
net/ipv4/gre.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/ip_gre.c | 10 ++--
5 files changed, 178 insertions(+), 5 deletions(-)
diff --git a/include/net/gre.h b/include/net/gre.h
new file mode 100644
index 0000000..31a0f76
--- /dev/null
+++ b/include/net/gre.h
@@ -0,0 +1,18 @@
+#ifndef __LINUX_GRE_H
+#define __LINUX_GRE_H
+
+#include <linux/skbuff.h>
+
+#define GREPROTO_CISCO 0
+#define GREPROTO_PPTP 1
+#define GREPROTO_MAX 2
+
+struct gre_protocol {
+ int (*handler)(struct sk_buff *skb);
+ void (*err_handler)(struct sk_buff *skb, u32 info);
+};
+
+int gre_add_protocol(const struct gre_protocol *proto, u8 version);
+int gre_del_protocol(const struct gre_protocol *proto, u8 version);
+
+#endif
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 7c3a7d1..7458bda 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -215,8 +215,15 @@ config NET_IPIP
be inserted in and removed from the running kernel whenever you
want). Most people won't need this and can say N.
+config NET_IPGRE_DEMUX
+ tristate "IP: GRE demultiplexer"
+ help
+ This is helper module to demultiplex GRE packets on GRE version field criteria.
+ Required by ip_gre and pptp modules.
+
config NET_IPGRE
tristate "IP: GRE tunnels over IP"
+ depends on NET_IPGRE_DEMUX
help
Tunneling means encapsulating data of one protocol type within
another protocol and sending it over a channel that understands the
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index 80ff87c..4978d22 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
obj-$(CONFIG_IP_MROUTE) += ipmr.o
obj-$(CONFIG_NET_IPIP) += ipip.o
+obj-$(CONFIG_NET_IPGRE_DEMUX) += gre.o
obj-$(CONFIG_NET_IPGRE) += ip_gre.o
obj-$(CONFIG_SYN_COOKIES) += syncookies.o
obj-$(CONFIG_INET_AH) += ah4.o
diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
new file mode 100644
index 0000000..f54a0fc
--- /dev/null
+++ b/net/ipv4/gre.c
@@ -0,0 +1,147 @@
+/*
+ * GRE over IPv4 demultiplexer driver
+ *
+ * Authors: Dmitry Kozlov (xeb@mail.ru)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kmod.h>
+#include <linux/skbuff.h>
+#include <linux/in.h>
+#include <linux/netdevice.h>
+#include <linux/version.h>
+#include <linux/spinlock.h>
+#include <net/protocol.h>
+#include <net/gre.h>
+
+
+const struct gre_protocol *gre_proto[GREPROTO_MAX] ____cacheline_aligned_in_smp;
+static DEFINE_RWLOCK(gre_proto_lock);
+
+int gre_add_protocol(const struct gre_protocol *proto, u8 version)
+{
+ int ret;
+
+ if (version >= GREPROTO_MAX)
+ return -1;
+
+ write_lock_bh(&gre_proto_lock);
+ if (gre_proto[version]) {
+ ret = -1;
+ } else {
+ gre_proto[version]=proto;
+ ret = 0;
+ }
+ write_unlock_bh(&gre_proto_lock);
+
+ return ret;
+}
+int gre_del_protocol(const struct gre_protocol *proto, u8 version)
+{
+ int ret;
+
+ if (version >= GREPROTO_MAX)
+ return -1;
+
+ write_lock_bh(&gre_proto_lock);
+ if (gre_proto[version] == proto) {
+ gre_proto[version] = NULL;
+ ret = 0;
+ } else {
+ ret = -1;
+ }
+ write_unlock_bh(&gre_proto_lock);
+
+ return ret;
+}
+static int gre_rcv(struct sk_buff *skb)
+{
+ u8 ver;
+ int ret;
+
+ if (!pskb_may_pull(skb, 12))
+ goto drop_nolock;
+
+ ver = skb->data[1]&0x7f;
+ if (ver >= GREPROTO_MAX)
+ goto drop_nolock;
+
+ read_lock(&gre_proto_lock);
+ if (!gre_proto[ver] || !gre_proto[ver]->handler)
+ goto drop;
+ ret = gre_proto[ver]->handler(skb);
+ read_unlock(&gre_proto_lock);
+ return ret;
+
+drop:
+ read_unlock(&gre_proto_lock);
+drop_nolock:
+ kfree_skb(skb);
+ return NET_RX_DROP;
+}
+static void gre_err(struct sk_buff *skb, u32 info)
+{
+ u8 ver;
+
+ printk("err\n");
+
+ if (!pskb_may_pull(skb, 12))
+ goto drop_nolock;
+
+ ver=skb->data[1];
+ if (ver>=GREPROTO_MAX)
+ goto drop_nolock;
+
+ read_lock(&gre_proto_lock);
+ if (!gre_proto[ver] || !gre_proto[ver]->err_handler)
+ goto drop;
+ gre_proto[ver]->err_handler(skb,info);
+ read_unlock(&gre_proto_lock);
+ return;
+
+drop:
+ read_unlock(&gre_proto_lock);
+drop_nolock:
+ kfree_skb(skb);
+}
+
+
+static struct net_protocol net_gre_protocol = {
+ .handler = gre_rcv,
+ .err_handler = gre_err,
+ .netns_ok=1,
+};
+
+static int __init gre_init(void)
+{
+ printk(KERN_INFO "GRE over IPv4 demultiplexor driver");
+
+ if (inet_add_protocol(&net_gre_protocol, IPPROTO_GRE) < 0) {
+ printk(KERN_INFO "gre: can't add protocol\n");
+ return -EAGAIN;
+ }
+
+ return 0;
+}
+
+static void __exit gre_exit(void)
+{
+ inet_del_protocol(&net_gre_protocol, IPPROTO_GRE);
+}
+
+module_init(gre_init);
+module_exit(gre_exit);
+
+MODULE_DESCRIPTION("GRE over IPv4 demultiplexer driver");
+MODULE_AUTHOR("D. Kozlov (xeb@mail.ru)");
+MODULE_LICENSE("GPL");
+EXPORT_SYMBOL_GPL(gre_add_protocol);
+EXPORT_SYMBOL_GPL(gre_del_protocol);
+
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 32618e1..f0391b3 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -44,6 +44,7 @@
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
+#include <net/gre.h>
#ifdef CONFIG_IPV6
#include <net/ipv6.h>
@@ -1276,10 +1277,9 @@ static void ipgre_fb_tunnel_init(struct net_device *dev)
}
-static const struct net_protocol ipgre_protocol = {
+static const struct gre_protocol ipgre_protocol = {
.handler = ipgre_rcv,
.err_handler = ipgre_err,
- .netns_ok = 1,
};
static void ipgre_destroy_tunnels(struct ipgre_net *ign, struct list_head *head)
@@ -1661,7 +1661,7 @@ static int __init ipgre_init(void)
if (err < 0)
return err;
- err = inet_add_protocol(&ipgre_protocol, IPPROTO_GRE);
+ err = gre_add_protocol(&ipgre_protocol, GREPROTO_CISCO);
if (err < 0) {
printk(KERN_INFO "ipgre init: can't add protocol\n");
goto add_proto_failed;
@@ -1681,7 +1681,7 @@ out:
tap_ops_failed:
rtnl_link_unregister(&ipgre_link_ops);
rtnl_link_failed:
- inet_del_protocol(&ipgre_protocol, IPPROTO_GRE);
+ gre_del_protocol(&ipgre_protocol, GREPROTO_CISCO);
add_proto_failed:
unregister_pernet_device(&ipgre_net_ops);
goto out;
@@ -1691,7 +1691,7 @@ static void __exit ipgre_fini(void)
{
rtnl_link_unregister(&ipgre_tap_ops);
rtnl_link_unregister(&ipgre_link_ops);
- if (inet_del_protocol(&ipgre_protocol, IPPROTO_GRE) < 0)
+ if (gre_del_protocol(&ipgre_protocol, GREPROTO_CISCO) < 0)
printk(KERN_INFO "ipgre close: can't remove protocol\n");
unregister_pernet_device(&ipgre_net_ops);
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox