* Re: bne2 rx packet drop?
From: Rusty Russell @ 2010-08-05 0:08 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
In-Reply-To: <201008050859.57659.rusty@rustcorp.com.au>
On Thu, 5 Aug 2010 08:59:57 am Rusty Russell wrote:
> Hi Michael (and netdev!)
Subject should read bnx2 of course...
More coffee...
Rusty.
^ 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: Eric W. Biederman @ 2010-08-05 0:12 UTC (permalink / raw)
To: Michael Leun; +Cc: Greg KH, netdev, davem, linux-kernel
In-Reply-To: <20100805001105.5a3453ed@xenia.leun.net>
Michael Leun <lkml20100708@newton.leun.net> writes:
> Hi,
>
> On Wed, 4 Aug 2010 14:46:18 -0700
> Greg KH <greg@kroah.com> wrote:
>
>> Eric, here's a bug with the network namespace stuff, care to work on
>> resolving it?
>
> Just in case I provide the complete scenario again below.
>
> If I can help somehow (provide further information, test something...)
> of course I'll happily do so.
>
> In an network namespace I can use an tun/tap tunnel through ssh and
> when closing that namespace then eveything is fine.
>
> But when using openvpn (also tunnel trough tun/tap) in an network
> namespace and then closing that namespace I get:
>
> unregister_netdevice: waiting for lo to become free
> [repeated]
>
> Please see the following two examples showing that difference:
>
> # > unshare -n /bin/bash
> # > # how to setup veth device pair to get connectivity into namespace not shown here
> # > tunctl -u ml -t tap1
> # > ssh -o Tunnel=Ethernet -w 1:1 somewhere
> [ running some traffic over tap1 not shown here ]
> ^d # logging out from somewhere
> # > tunctl -d tap1
> # > exit # logging out from shell in network namespace
>
> Now the veth device pair used automagically vanishes and nothing
> from that different network namespace remains - very well.
>
> but
>
> # > 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?
> Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
> i586-suse-linux - the one in openSuSE 11.2 package - EDIT: meanwhile it
> is 2.1.1, openSuSE 11.3 ), openvpn didn't close some ressource and ssh
> does fine.
>
> But: should'nt kernel clean up after process when it exits?
> And/or: Should'nt kernel clean up if last process in network namespace
> exits - there is nothing left which might use that interface?!
We do, and the only place you will see:
unregister_netdevice: waiting for lo to become free. Usage count = 3 [repeated]
is when the a network namespace is being cleaned up.
However it looks like something is either taking a long time to get
cleaned up, or there is a bug and something is failing to get cleaned
up altogether thus resulting in an infinite stream of messages about waiting
for lo to become free.
I know of cases where a recent kernel can be slow to cleanup everything
attached to lo. I don't know of any cases where it will actually fail
to clean up lo. So I suspect all you are seeing is clean up process that
is slow and annoying not wrong.
Eric
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Kevin Hilman @ 2010-08-05 0:16 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt,
grant.likely, magnus.damm
In-Reply-To: <4C59E654.1090403@codeaurora.org>
Patrick Pannuto <ppannuto@codeaurora.org> writes:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
Also, later in that thread I also wrote[1] what seems to be the core of
what you've done here: namely, allow platform_devices and
platform_drivers to to be used on custom busses. Patch is at the end of
this mail with a more focused changelog. As Greg suggested in his reply
to your first version, this part could be merged today, and the
platform_bus_init stuff could be added later, after some more review.
Some comments below...
> INTRO
>
> As SOCs become more popular, the desire to quickly define a simple,
> but functional, bus type with only a few unique properties becomes
> desirable. As they become more complicated, the ability to nest these
> simple busses and otherwise orchestrate them to match the actual
> topology also becomes desirable.
>
> EXAMPLE USAGE
>
> /arch/ARCH/MY_ARCH/my_bus.c:
>
> #include <linux/device.h>
> #include <linux/platform_device.h>
>
> struct bus_type my_bus_type = {
> .name = "mybus",
> };
> EXPORT_SYMBOL_GPL(my_bus_type);
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
>
> struct platform_device sub_bus2 = {
> .name = "sub_bus2",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus2);
>
> static int __init my_bus_init(void)
> {
> int error;
> platform_bus_type_init(&my_bus_type);
> error = bus_register(&my_bus_type);
> if (error)
> return error;
>
> error = platform_device_register(&sub_bus1);
> if (error)
> goto fail_sub_bus1;
>
> error = platform_device_register(&sub_bus2);
> if (error)
> goto fail_sub_bus2;
>
> return error;
>
> fail_sub_bus2:
> platform_device_unregister(&sub_bus1);
> fail_sub_bus2:
> bus_unregister(&my_bus_type);
>
> return error;
> }
> postcore_initcall(my_bus_init);
> EXPORT_SYMBOL_GPL(my_bus_init);
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
>
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
>
> Notice that for a device / driver, only 3 lines were added to
> switch from the platform bus to the new my_bus. This is
> especially valuable if we consider supporting a legacy SOCs
> and new SOCs where the same driver is used, but may need to
> be on either the platform bus or the new my_bus. The above
> code then becomes:
>
> (possibly in a header)
> #ifdef CONFIG_MY_BUS
> #define MY_BUS_TYPE &my_bus_type
> #else
> #define MY_BUS_TYPE NULL
> #endif
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = MY_BUS_TYPE,
> },
> };
>
> Which will allow the same driver to easily to used on either
> the platform bus or the newly defined bus type.
Except it requires a re-compile.
Rather than doing this at compile time, it would be better to support
legacy devices at runtime. You could handle this by simply registering
the driver on the custom bus and the platform_bus and let the bus
matching code handle it. Then, the same binary would work on both
legacy and updated SoCs.
>
> This will build a device tree that mirrors the actual configuration:
> /sys/bus
> |-- my_bus
> | |-- devices
> | | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
> | | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
> | | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
> | |-- drivers
> | | |-- my-driver
>
>
> Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
> ---
> drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
> include/linux/platform_device.h | 2 ++
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4d99c8b..c86be03 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
> if (!pdev->dev.parent)
> pdev->dev.parent = &platform_bus;
>
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> if (pdev->id != -1)
> dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> @@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
> */
> int platform_driver_register(struct platform_driver *drv)
> {
> - drv->driver.bus = &platform_bus_type;
> + if (!drv->driver.bus)
> + drv->driver.bus = &platform_bus_type;
> if (drv->probe)
> drv->driver.probe = platform_drv_probe;
> if (drv->remove)
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
Up to here, this looks exactly what I wrote in thread referenced above.
>
> if (code != retval)
> platform_driver_unregister(drv);
> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
> +/** platform_bus_type_init - fill in a pseudo-platform-bus
> + * @bus: foriegn bus type
> + *
> + * This init is basically a selective memcpy that
> + * won't overwrite any user-defined attributes and
> + * only copies things that platform bus defines anyway
> + */
minor nit: kernel doc style has wrong indentation
> +void platform_bus_type_init(struct bus_type *bus)
> +{
> + if (!bus->dev_attrs)
> + bus->dev_attrs = platform_bus_type.dev_attrs;
> + if (!bus->match)
> + bus->match = platform_bus_type.match;
> + if (!bus->uevent)
> + bus->uevent = platform_bus_type.uevent;
> + if (!bus->pm)
> + bus->pm = platform_bus_type.pm;
> +}
> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
With this approach, you should note in the comments/changelog that
any selective customization of the bus PM methods must be done after
calling platform_bus_type_init().
Also, You've left out the legacy PM methods here. That implies that
moving a driver from the platform_bus to the custom bus is not entirely
transparent. If the driver still has legacy PM methods, it would stop
working on the custom bus.
While this is good motivation for converting a driver to dev_pm_ops, at
a minimum it should be clear in the changelog that the derivative busses
do not support legacy PM methods. However, since it's quite easy to do,
and you want the derivative busses to be *exactly* like the platform bus
except where explicitly changed, I'd suggest you also check/copy the
legacy PM methods.
In addition, you've missed several fields in 'struct bus_type'
(bus_attr, drv_attr, p, etc.) Without digging deeper into the driver
core, I'm not sure if they are all needed at init time, but it should be
clear in the comments why they can be excluded.
Kevin
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31289.html
>From b784009af1d0a7065dc5e58a13ce29afa3432d3e Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@deeprootsystems.com>
Date: Mon, 28 Jun 2010 16:08:14 -0700
Subject: [PATCH] driver core: allow platform_devices and platform_drivers on custom busses
This allows platform_devices and platform_drivers to be registered onto
custom busses that are compatible with the platform_bus.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
drivers/base/platform.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..2cf55e2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
--
1.7.2.1
^ permalink raw reply related
* Re: [patch] netfilter: default to NF_DROP in sip_help_tcp()
From: Simon Horman @ 2010-08-05 0:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <4C599102.9050500@trash.net>
On Wed, Aug 04, 2010 at 06:10:42PM +0200, Patrick McHardy wrote:
> Am 04.08.2010 10:07, schrieb Simon Horman:
> > On Wed, Jul 14, 2010 at 02:23:01PM +0200, Patrick McHardy wrote:
> >> On 10.07.2010 05:16, Simon Horman wrote:
> >>> I initially noticed this because of the compiler warning below, but it does
> >>> seem to be a valid concern in the case where ct_sip_get_header() returns 0
> >>> in the first iteration of the while loop.
> >>>
> >>> net/netfilter/nf_conntrack_sip.c: In function 'sip_help_tcp':
> >>> net/netfilter/nf_conntrack_sip.c:1379: warning: 'ret' may be used uninitialized in this function
> >>
> >> Thanks Simon. I've applied the patch, but changed NF_DROP to
> >> NF_ACCEPT since we should avoid dropping packets with unknown
> >> contents (not SIP) if possible.
> >
> > Hi Patrick,
> >
> > I'm not seeing this patch in nf-next-2.6.
> > Am I looking in the wrong place?
>
> I was struggling with some file system corruption and didn't manage
> to send it out in time, sorry. I'll include it in the next batch of
> patches for .36 and will also push it to -stable.
Thanks, I'm happy so long as it makes it eventually.
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-05 0:57 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt,
grant.likely, magnus.damm
In-Reply-To: <877hk56hiy.fsf@deeprootsystems.com>
On 08/04/2010 05:16 PM, Kevin Hilman wrote:
> Patrick Pannuto <ppannuto@codeaurora.org> writes:
>
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> Also, later in that thread I also wrote[1] what seems to be the core of
> what you've done here: namely, allow platform_devices and
> platform_drivers to to be used on custom busses. Patch is at the end of
> this mail with a more focused changelog. As Greg suggested in his reply
> to your first version, this part could be merged today, and the
> platform_bus_init stuff could be added later, after some more review.
> Some comments below...
>
I can split this into 2 patches.
Was your patch sent to linux-kernel or just linux-omap? I'm not on linux-omap...
>> [snip]
>>
>> Which will allow the same driver to easily to used on either
>> the platform bus or the newly defined bus type.
>
> Except it requires a re-compile.
>
> Rather than doing this at compile time, it would be better to support
> legacy devices at runtime. You could handle this by simply registering
> the driver on the custom bus and the platform_bus and let the bus
> matching code handle it. Then, the same binary would work on both
> legacy and updated SoCs.
>
Can you safely register a driver on more than one bus? I didn't think
that was safe -- normally it's impossible since you're calling
struct BUS_TYPE_driver mydriver;
BUS_TYPE_driver_register(&mydriver)
but now we have multiple "bus types" that are all actually platform type; still,
at a minimum you would need:
struct platform_driver mydrvier1 = {
.driver.bus = &sub_bus1,
};
struct platform_driver mydrvier2 = {
.driver.bus = &sub_bus2,
};
which would all point to the same driver functions, yet the respective devices
attached for the "same" driver would be on different buses. I fear this might
confuse some drivers. I don't think dynamic bus assignment is this easy
In short: I do not believe the same driver can be registered on multiple
different buses -- if this is wrong, please correct me.
>
> Up to here, this looks exactly what I wrote in thread referenced above.
>
It is, you just went on vacation :)
>>
>> if (code != retval)
>> platform_driver_unregister(drv);
>> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
>> };
>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>
>> +/** platform_bus_type_init - fill in a pseudo-platform-bus
>> + * @bus: foriegn bus type
>> + *
>> + * This init is basically a selective memcpy that
>> + * won't overwrite any user-defined attributes and
>> + * only copies things that platform bus defines anyway
>> + */
>
> minor nit: kernel doc style has wrong indentation
>
will fix
>> +void platform_bus_type_init(struct bus_type *bus)
>> +{
>> + if (!bus->dev_attrs)
>> + bus->dev_attrs = platform_bus_type.dev_attrs;
>> + if (!bus->match)
>> + bus->match = platform_bus_type.match;
>> + if (!bus->uevent)
>> + bus->uevent = platform_bus_type.uevent;
>> + if (!bus->pm)
>> + bus->pm = platform_bus_type.pm;
>> +}
>> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
>
> With this approach, you should note in the comments/changelog that
> any selective customization of the bus PM methods must be done after
> calling platform_bus_type_init().
No they don't. If you call platform_bus_type_init first then you'll
just overwrite them with new values; if you call it second then they
will all already be well-defined and thus not overwritten.
>
> Also, You've left out the legacy PM methods here. That implies that
> moving a driver from the platform_bus to the custom bus is not entirely
> transparent. If the driver still has legacy PM methods, it would stop
> working on the custom bus.
>
> While this is good motivation for converting a driver to dev_pm_ops, at
> a minimum it should be clear in the changelog that the derivative busses
> do not support legacy PM methods. However, since it's quite easy to do,
> and you want the derivative busses to be *exactly* like the platform bus
> except where explicitly changed, I'd suggest you also check/copy the
> legacy PM methods.
>
> In addition, you've missed several fields in 'struct bus_type'
> (bus_attr, drv_attr, p, etc.) Without digging deeper into the driver
> core, I'm not sure if they are all needed at init time, but it should be
> clear in the comments why they can be excluded.
>
I copied everything that was defined for platform_bus_type:
struct bus_type platform_bus_type = {
.name = "platform",
.dev_attrs = platform_dev_attrs,
.match = platform_match,
.uevent = platform_uevent,
.pm = &platform_dev_pm_ops,
};
EXPORT_SYMBOL_GPL(platform_bus_type);
struct bus_type {
const char *name;
struct bus_attribute *bus_attrs;
struct device_attribute *dev_attrs;
struct driver_attribute *drv_attrs;
int (*match)(struct device *dev, struct device_driver *drv);
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
int (*probe)(struct device *dev);
int (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
const struct dev_pm_ops *pm;
struct bus_type_private *p;
};
It is my understanding that everything that I did not copy *should* remain
unique to each bus; remaining fields will be filled in by bus_register and
should not be copied.
> Kevin
>
> [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31289.html
>
>
> From b784009af1d0a7065dc5e58a13ce29afa3432d3e Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@deeprootsystems.com>
> Date: Mon, 28 Jun 2010 16:08:14 -0700
> Subject: [PATCH] driver core: allow platform_devices and platform_drivers on custom busses
>
> This allows platform_devices and platform_drivers to be registered onto
> custom busses that are compatible with the platform_bus.
>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> drivers/base/platform.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4d99c8b..2cf55e2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
> if (!pdev->dev.parent)
> pdev->dev.parent = &platform_bus;
>
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> if (pdev->id != -1)
> dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> @@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
> */
> int platform_driver_register(struct platform_driver *drv)
> {
> - drv->driver.bus = &platform_bus_type;
> + if (!drv->driver.bus)
> + drv->driver.bus = &platform_bus_type;
> if (drv->probe)
> drv->driver.probe = platform_drv_probe;
> if (drv->remove)
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>
> if (code != retval)
> platform_driver_unregister(drv);
If you would like to lead this effort, please do so; I did not mean to step
on your toes, it's just that this is an issue for me as well. You had
indicated that you were going on vacation for a month and I had not seen any
more follow-up on this issue, so I forged ahead. If you'd like me to drop it,
please let me know and I will - but also please send stuff like this to wider
distribution than just linux-omap; it has much greater reach (and interest).
Thanks,
-Pat
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 3/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Bill Fink @ 2010-08-05 1:22 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <E1OgbWT-0004Ij-00.xeb-mail-ru@f134.mail.ru>
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
> +S: Maintained
> +F: net/ipv4/gre.c
> +F: include/net/gre.h
> +
> +PPTP DRIVER
> +M: Dmitry Kozlov <xeb@mail.ru>
> +L: netdev@vger.kernel.org
> +S: Maintained
> +F: drivers/net/pptp.c
> +W: http://accel-pptp.sourceforge.net/
> +
> THE REST
> M: Linus Torvalds <torvalds@linux-foundation.org>
> L: linux-kernel@vger.kernel.org
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Magnus Damm @ 2010-08-05 2:32 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt
In-Reply-To: <4C59E654.1090403@codeaurora.org>
On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto <ppannuto@codeaurora.org> wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> RFC: http://lkml.org/lkml/2010/8/3/496
> Patch is unchanged from the RFC. Reviews seemed generally positive
> and it seemed this was desired functionality.
Thanks for your patch, it's really nice to see work done in this area!
I'd like to see something like this merged in the not so distant
future. At this point I'm not so concerned about the details, so I'll
restrict myself to this:
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
I would really prefer not to have the bus type in the here. I
understand it's needed at this point, but I wonder if it's possible to
adjust the device<->driver matching for platform devices to allow any
type of pseudo-platform bus_type.
The reason why I'd like to avoid having the bus type in the driver is
that I'd like to reuse the platform driver across multiple
architectures and buses. For instance, on the SH architecture and
SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the
sh-sci.c serial driver. The sh-sci.c platform driver supports a wide
range of different SCI(F)(A)(B) hardware blocks, and on any given SoC
there is a mix of SCIF blocks spread out on different buses.
At this point our SH platform drivers are unaware where their driver
instanced are located on the SoC. The I/O address and IRQs are
assigned via struct resource and clocks are managed through clkdev. I
believe that adding the bus type in the driver will violate this
abstraction and make it more difficult to just instantiate a driver
somewhere on the SoC.
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
This I don't mind at all. Actually, this is the place where the
topology should be defined IMO.
Cheers,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: Rusty Russell @ 2010-08-05 3:32 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin, Taku Izumi
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.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE)
---
drivers/net/virtio_net.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Index: net-next.35/drivers/net/virtio_net.c
===================================================================
--- net-next.35.orig/drivers/net/virtio_net.c
+++ net-next.35/drivers/net/virtio_net.c
@@ -701,6 +701,19 @@ static int virtnet_close(struct net_devi
return 0;
}
+static void virtnet_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct virtio_device *vdev = vi->vdev;
+
+ strncpy(drvinfo->driver, KBUILD_MODNAME, ARRAY_SIZE(drvinfo->driver));
+ strncpy(drvinfo->version, "N/A", ARRAY_SIZE(drvinfo->version));
+ strncpy(drvinfo->fw_version, "N/A", ARRAY_SIZE(drvinfo->fw_version));
+ strncpy(drvinfo->bus_info, dev_name(&vdev->dev),
+ ARRAY_SIZE(drvinfo->bus_info));
+}
+
static int virtnet_set_tx_csum(struct net_device *dev, u32 data)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -813,6 +825,7 @@ static void virtnet_vlan_rx_kill_vid(str
}
static const struct ethtool_ops virtnet_ethtool_ops = {
+ .get_drvinfo = virtnet_get_drvinfo,
.set_tx_csum = virtnet_set_tx_csum,
.set_sg = ethtool_op_set_sg,
.set_tso = ethtool_op_set_tso,
^ permalink raw reply
* Re: [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: Ben Hutchings @ 2010-08-05 3:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev, Michael S. Tsirkin, Taku Izumi
In-Reply-To: <201008051302.06045.rusty@rustcorp.com.au>
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.
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.
^ permalink raw reply
* 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
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