* Re: [PATCH 02/86] dccp: revert buggy auto-loading of dccp module
From: Neil Horman @ 2010-02-02 15:39 UTC (permalink / raw)
To: gerrit; +Cc: davem, dccp, netdev
In-Reply-To: <53767.148.187.160.35.1265123175.squirrel@148.187.160.35>
On Tue, Feb 02, 2010 at 03:06:15PM -0000, gerrit@erg.abdn.ac.uk wrote:
> > --- a/net/dccp/probe.c
> > +++ b/net/dccp/probe.c
> > @@ -161,7 +161,8 @@ static __init int dccpprobe_init(void)
> > if (!proc_net_fops_create(&init_net, procname, S_IRUSR,
> > &dccpprobe_fops))
> > goto err0;
> >
> > - ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
> > + try_then_request_module(
> > + ((ret = register_jprobe(&dccp_send_probe)) == 0),
> > "dccp");
> > if (ret)
> > goto err1;
>
> Apologies for the late response -- delays are sometimes possible due to
> day job. The only problem that I had with this patch was that it was
> apparently not tested, causing the described problems.
>
>
> > I've not tested it, but this should do it,
> > without re-breaking the silent dependency.
>
> I will test it and get back to you until tomorrow morning (GMT),
> if it works I'll also push it out in the test tree.
>
> Thanks a lot for getting back and devising a different route.
>
Thanks, and apologies for being brusque. I just didn't want to fix what is
clearly a problem in what you describe by rebreaking a previously seen problem.
I expect this should work just fine. Let me know if it doesn't and I'll
resurrect my test bed here and take a look
Neil
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH] igmp: fix ip_mc_sf_allow race [v5]
From: David Miller @ 2010-02-02 15:32 UTC (permalink / raw)
To: fbl; +Cc: netdev, dlstevens, eric.dumazet
In-Reply-To: <20100128161338.GB3544@sysclose.org>
From: Flavio Leitner <fbl@sysclose.org>
Date: Thu, 28 Jan 2010 14:13:38 -0200
> Hello,
>
> This is another version considering the suggestions. Thanks!
> I didn't convert to list_head yet because a lot more code needs
> to be changed so I'd rather leave that to another patch.
> 8<---------
>
> Almost all igmp functions accessing inet->mc_list are protected by
> rtnl_lock(), but there is one exception which is ip_mc_sf_allow(),
> so there is a chance of either ip_mc_drop_socket or ip_mc_leave_group
> remove an entry while ip_mc_sf_allow is running causing a crash.
>
> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 V5] net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver
From: David Miller @ 2010-02-02 15:31 UTC (permalink / raw)
To: kristoffer; +Cc: netdev, shemminger
In-Reply-To: <1264664629-25128-2-git-send-email-kristoffer@gaisler.com>
From: Kristoffer Glembo <kristoffer@gaisler.com>
Date: Thu, 28 Jan 2010 08:43:49 +0100
> + struct amba_prom_registers *prom_regs;
> + unsigned int addr;
...
> + irqs = (int *) of_get_property(ofdev->node, "interrupts", NULL);
> + prom_regs = (struct amba_prom_registers *) of_get_property(ofdev->node, "reg", NULL);
...
> + addr = prom_regs->phys_addr;
...
> +struct amba_prom_registers {
> + unsigned int phys_addr;
> + unsigned int reg_size;
> +};
These kinds of constructs should never be necessary in an OF driver.
The device probing layer calculates OF device resources that you can
use to obtain the register (op->resource[]) and IRQ (op->irq[])
mappings portably.
And you use of_ioremap() on the resource object to map the register
I/O space properly, and of_iounmap() it on unload.
See drivers/net/niu.c:niu_of_probe() for an example.
Please fix this up, thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: use helpers to access mc list
From: David Miller @ 2010-02-02 15:25 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100126145738.GA2537@psychotron.lab.eng.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Tue, 26 Jan 2010 15:57:39 +0100
> Temporary macro "netdev_for_each_mc_addr" works in the ugly way, I'm aware, but
> it will be replaced. It uses iterator stored in "struct net_device". In every
> iteration, it copies addr from the list to "struct netdev_hw_addr" instance
> (also stored in "struct net_device"). Driver reads address stored in this
> structure. All is protected by addr_list_lock held by a caller.
This kind of ugly hack is rarely necessary, so I'm not applying
this, sorry.
In the macros, use the iterator type the driver instances already use,
which is the mcaddr entry pointer.
Then by using list_for_each_entry() things should "just work".
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
From: David Miller @ 2010-02-02 15:21 UTC (permalink / raw)
To: socketcan; +Cc: netdev
In-Reply-To: <4B5EF37F.7070906@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Tue, 26 Jan 2010 14:51:59 +0100
> In commit 20dd3850bcf860561496827b711fa10fecf6e787 "can: Speed up CAN frame
> receiption by using ml_priv" the formerly used hlist of receiver lists for
> each CAN netdevice has been replaced.
>
> The hlist content ensured only CAN netdevices to be accessed by the
> can_rx_(un)register() functions which accidently dropped away together with
> the hlist receiver implementation.
>
> This patch re-introduces the check for CAN netdevices in can_rx_(un)register().
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Applied, thanks Oliver.
^ permalink raw reply
* Re: [PATCH 02/86] dccp: revert buggy auto-loading of dccp module
From: gerrit @ 2010-02-02 15:06 UTC (permalink / raw)
To: Neil Horman; +Cc: Gerrit Renker, davem, dccp, netdev
In-Reply-To: <20100201122119.GC25094@hmsreliant.think-freely.org>
> --- a/net/dccp/probe.c
> +++ b/net/dccp/probe.c
> @@ -161,7 +161,8 @@ static __init int dccpprobe_init(void)
> if (!proc_net_fops_create(&init_net, procname, S_IRUSR,
> &dccpprobe_fops))
> goto err0;
>
> - ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
> + try_then_request_module(
> + ((ret = register_jprobe(&dccp_send_probe)) == 0),
> "dccp");
> if (ret)
> goto err1;
Apologies for the late response -- delays are sometimes possible due to
day job. The only problem that I had with this patch was that it was
apparently not tested, causing the described problems.
> I've not tested it, but this should do it,
> without re-breaking the silent dependency.
I will test it and get back to you until tomorrow morning (GMT),
if it works I'll also push it out in the test tree.
Thanks a lot for getting back and devising a different route.
^ permalink raw reply
* Re: [PATCH] netlink: fix for too early rmmod
From: Patrick McHardy @ 2010-02-02 14:55 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev, kuznet
In-Reply-To: <20100130200505.GA5318@x200>
Alexey Dobriyan wrote:
> Netlink code does module autoload if protocol userspace is asking for is
> not ready. However, module can dissapear right after it was autoloaded.
> Example: modprobe/rmmod stress-testing and xfrm_user.ko providing NETLINK_XFRM.
>
> netlink_create() in such situation _will_ create userspace socket and
> _will_not_ pin module. Now if module was removed and we're going to call
> ->netlink_rcv into nothing:
>
> BUG: unable to handle kernel paging request at ffffffffa02f842a
> ^^^^^^^^^^^^^^^^
> modules are loaded near these addresses here
>
> ...
>
> If module was quickly removed after autoloading, return -E.
>
> Return -EPROTONOSUPPORT if module was quickly removed after autoloading.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
> NOTE: due to commit 513c25000005257e5474f261bf27d4a3c1dff1e3
> "[NETLINK]: Don't prevent creating sockets when no kernel socket is registered"
> error should probably be -ENOENT, but I have no idea what this
> pam-audit thing is.
Quoting from the thread back then (couldn't find a public reference):
> FC4 includes a pam-0.77-audit.patch which adds a pam module that
> uses libaudit to probe for audit availability. It calls audit_open
> and ignores connection refused but returns an pam error for all
> other errors.
The current version of libaudit properly checks for EPROTONOSUPPORT,
but I don't know when this was fixed and whether we can assume the
broken code is not used anymore.
^ permalink raw reply
* Re: [PATCH] hrtimer, softirq: Fix hrtimer->softirq trampoline
From: Peter Zijlstra @ 2010-02-02 14:35 UTC (permalink / raw)
To: Yury Polyanskiy
Cc: Herbert Xu, Wei Yongjun, netdev@vger.kernel.org, David S. Miller,
polyanskiy, Thomas Gleixner, lkml
In-Reply-To: <20100202092814.064a89c0@penta.localdomain>
On Tue, 2010-02-02 at 09:28 -0500, Yury Polyanskiy wrote:
> On Tue, 02 Feb 2010 15:20:01 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> > static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
> > {
> > struct tasklet_hrtimer *ttimer =
> > container_of(timer, struct tasklet_hrtimer, timer);
> >
> > - if (hrtimer_is_hres_active(timer)) {
> > - tasklet_hi_schedule(&ttimer->tasklet);
> > - return HRTIMER_NORESTART;
> > - }
> > - return ttimer->function(timer);
> > + tasklet_hi_schedule(&ttimer->tasklet);
> > + return HRTIMER_NORESTART;
> > }
> >
>
> Are you totally against if(in_irq())?
Yeah, things like that are an indication that you really don't know wtf
you're doing and are just patching up.
There is a single site where hrtimer callbacks can indeed be done from
softirq, but in that case the above still works correctly, and I've been
meaning to get rid of that anyway.
^ permalink raw reply
* Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data
From: Patrick McHardy @ 2010-02-02 14:34 UTC (permalink / raw)
To: Simon Arlott
Cc: Jan Engelhardt, William Allen Simpson, netdev,
Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <4B58B578.9080505@simon.arlott.org.uk>
Simon Arlott wrote:
> The TCPMSS target is dropping SYN packets where:
> 1) There is data, or
> 2) The data offset makes the TCP header larger than the packet.
>
> Both of these result in an error level printk. This printk has been
> removed.
>
> This change avoids dropping SYN packets containing data. If there
> is also no MSS option (as well as data), one will not be added
> because of possible complications due to the increased packet size.
Applied, thanks Simon.
^ permalink raw reply
* Re: [PATCH] hrtimer, softirq: Fix hrtimer->softirq trampoline
From: Yury Polyanskiy @ 2010-02-02 14:28 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Herbert Xu, Wei Yongjun, netdev@vger.kernel.org, David S. Miller,
polyanskiy, Thomas Gleixner, lkml
In-Reply-To: <1265120401.24455.306.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Tue, 02 Feb 2010 15:20:01 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
> {
> struct tasklet_hrtimer *ttimer =
> container_of(timer, struct tasklet_hrtimer, timer);
>
> - if (hrtimer_is_hres_active(timer)) {
> - tasklet_hi_schedule(&ttimer->tasklet);
> - return HRTIMER_NORESTART;
> - }
> - return ttimer->function(timer);
> + tasklet_hi_schedule(&ttimer->tasklet);
> + return HRTIMER_NORESTART;
> }
>
Are you totally against if(in_irq())?
Yury
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] hrtimer, softirq: Fix hrtimer->softirq trampoline
From: Peter Zijlstra @ 2010-02-02 14:20 UTC (permalink / raw)
To: Yury Polyanskiy
Cc: Herbert Xu, Wei Yongjun, netdev@vger.kernel.org, David S. Miller,
polyanskiy, Thomas Gleixner, lkml
In-Reply-To: <20100202085117.7a5c3530@penta.localdomain>
On Tue, 2010-02-02 at 08:51 -0500, Yury Polyanskiy wrote:
> If hrtimer_tasklet interface functions properly, the
> xfrm_timer_handler should be called in softirq context (and thus is
> never in parallel with xfrm_input()). The deadlock isn't possible then.
>
> In this case it seems that for some reason xfrm_timer_handler() is
> called in the hardirq context. The relevant code in hrtimer_tasklet:
>
> static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
> {
> struct tasklet_hrtimer *ttimer =
> container_of(timer, struct tasklet_hrtimer, timer);
>
> if (hrtimer_is_hres_active(timer)) {
> tasklet_hi_schedule(&ttimer->tasklet);
> return HRTIMER_NORESTART;
> }
> return ttimer->function(timer);
> }
>
> I am copying Peter on this. Peter, how is it possible that
> ttimer->function() is called in hardirq?
>
> Could it be that switch from hres_active happened after the call to
> trampoline and before the if() above?
The original email had more information:
> {IN-HARDIRQ-W} state was registered at:
> [<c04718dc>] __lock_acquire+0xa9c/0x1890
> [<c047274f>] lock_acquire+0x7f/0xf0
> [<c0762958>] _raw_spin_lock+0x38/0x50
> [<c072b5ca>] xfrm_timer_handler+0x3a/0x260
> [<c0447d9d>] __hrtimer_tasklet_trampoline+0xd/0x10
> [<c04634ce>] hrtimer_run_queues+0x15e/0x2a0
> [<c045146d>] run_local_timers+0xd/0x20
> [<c04514b4>] update_process_times+0x34/0x70
> [<c046ce8a>] tick_periodic+0x2a/0x80
> [<c046cefe>] tick_handle_periodic+0x1e/0x90
> [<c0768377>] smp_apic_timer_interrupt+0x57/0x8b
> [<c076382f>] apic_timer_interrupt+0x2f/0x34
> [<c0401d3b>] cpu_idle+0x4b/0x80
> [<c074e0d7>] rest_init+0x67/0x70
> [<c0956874>] start_kernel+0x30e/0x314
> [<c095609e>] i386_start_kernel+0x9e/0xa5
Which indicates we were called from hardirq context, it appears that
that hrtimer_is_hres_active() case is indeed faulty. Not sure if I made
a mistake when I wrote that or if we changed hrtimer behaviour
afterwards, but the hrtimer fallback is still from hardirq context.
Which would seem to suggest the following patch:
---
Subject: hrtimer, softirq: Fix hrtimer->softirq trampoline
hrtimers callbacks are always done from hardirq context, either the
jiffy tick interrupt or the hrtimer device interrupt.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/softirq.c | 13 +++----------
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index a09502e..c1983b7 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -500,22 +500,15 @@ EXPORT_SYMBOL(tasklet_kill);
*/
/*
- * The trampoline is called when the hrtimer expires. If this is
- * called from the hrtimer interrupt then we schedule the tasklet as
- * the timer callback function expects to run in softirq context. If
- * it's called in softirq context anyway (i.e. high resolution timers
- * disabled) then the hrtimer callback is called right away.
+ * The trampoline is called when the hrtimer expires.
*/
static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
{
struct tasklet_hrtimer *ttimer =
container_of(timer, struct tasklet_hrtimer, timer);
- if (hrtimer_is_hres_active(timer)) {
- tasklet_hi_schedule(&ttimer->tasklet);
- return HRTIMER_NORESTART;
- }
- return ttimer->function(timer);
+ tasklet_hi_schedule(&ttimer->tasklet);
+ return HRTIMER_NORESTART;
}
/*
^ permalink raw reply related
* Re: [PATCH net-next-2.6 09/13] net-caif: add CAIF netdevice
From: Patrick McHardy @ 2010-02-02 14:19 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Sjur Brændeland, netdev, davem, stefano.babic, randy.dunlap
In-Reply-To: <1265120080.31341.87.camel@localhost.localdomain>
Marcel Holtmann wrote:
> Hi Sjur,
>
>>>> +int chnl_net_ioctl(unsigned int cmd, unsigned long arg, bool
>>>> +from_user_land) { + struct chnl_net *priv;
>>>> + int result = -1;
>>>> + struct chnl_net *dev;
>>>> + struct net_device *netdevptr;
>>>> + int ret;
>>>> + struct ifreq ifreq;
>>>> + struct ifcaif_param param;
>>>> + rtnl_lock();
>>>> + if (from_user_land) {
>>>> + if (copy_from_user(&ifreq, (const void *)arg, sizeof(ifreq)))
>>>> + return -EFAULT; + } else
>>>> + memcpy(&ifreq, (void *)arg, sizeof(ifreq));
>>> Why do you need both an ioctl and a netlink interface?
>> Well, I would like to keep support for both netlink and ioctl.
>> Internally we are using a netlink interface, and oFono is using ioctl to create interfaces.
>
> we could try to convert oFono in using netlink. Shouldn't be that hard
> as long as it is RTNL. Only the generic netlink is painful in userspace
> applications with a mainloop.
I would prefer that too.
^ permalink raw reply
* Re: [PATCH net-next-2.6 09/13] net-caif: add CAIF netdevice
From: Patrick McHardy @ 2010-02-02 14:17 UTC (permalink / raw)
To: Sjur Brændeland; +Cc: netdev, davem, marcel, stefano.babic, randy.dunlap
In-Reply-To: <61D8D34BB13CFE408D154529C120E079032A2145@eseldmw101.eemea.ericsson.se>
Sjur Brændeland wrote:
>>> + if (priv->config.type == CAIF_CHTY_DATAGRAM_LOOP) { + struct
>>> iphdr *hdr; + __be32 swap;
>>> + /* Retrieve IP header. */
>>> + hdr = ip_hdr(skb);
>>> + /* Change source and destination address. */
>>> + swap = hdr->saddr;
>>> + hdr->saddr = hdr->daddr;
>>> + hdr->daddr = swap;
>> swap()?
>
>
> The modem provides a loopback function for the CAIF link type (CAIF_CHTY_DATAGRAM_LOOP).
> This is useful for testing the physical link between modem and host.
> In this scenario we need to swap src and destination ip address.
> I'll move this to a separate function in next patch set.
There is already a swap() function which you can use.
>>> +static int ipcaif_newlink(struct net *src_net, struct net_device
>>> *dev, + struct nlattr *tb[], struct nlattr *data[]) { + int err;
>>> + struct chnl_net *caifdev;
>>> + ASSERT_RTNL();
>>> + caifdev = netdev_priv(dev);
>>> + caif_netlink_parms(data, &caifdev->config);
>>> + err = register_netdevice(dev);
>>> + if (err) {
>>> + pr_warning("CAIF: %s(): device rtml registration failed\n", +
>>> __func__); + goto out;
>>> + }
>>> + dev_hold(dev);
>> What is this reference used for? You don't have a dellink function,
>> so this looks like a leak.
>
> I don't think it leaks because I do dev_put in chnl_net_uninit,
> but you're right - I don't really need this. I'll remove the
> dev_hold and dev_put completely in next patch-set.
But it wouldn't get released when deleting a link using netlink
I think since without a dellink function I don't see what would
invoke chnl_net_uninit(). Anyways, removing it will fix this :)
^ permalink raw reply
* [PATCH 2/2] netxen: protect resource cleanup by rtnl lock
From: Amit Kumar Salecha @ 2010-02-02 14:16 UTC (permalink / raw)
To: davem; +Cc: netdev, dhananjay.phadke
In-Reply-To: <1265120181-1671-1-git-send-email-amit.salecha@qlogic.com>
o context resources can be in used, while resource cleanup is in progress,
during fw recover.
o Null pointer execption can occur in send_cmd_desc, if fw recovery
module frees tx ring without rtnl lock.
o Same applies to ethtool register dump.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 5209095..24279e6 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -2240,7 +2240,9 @@ netxen_detach_work(struct work_struct *work)
netxen_nic_down(adapter, netdev);
+ rtnl_lock();
netxen_nic_detach(adapter);
+ rtnl_unlock();
status = NXRD32(adapter, NETXEN_PEG_HALT_STATUS1);
--
1.5.6.1
^ permalink raw reply related
* [PATCH 0/2]netxen: tx timeout fix
From: Amit Kumar Salecha @ 2010-02-02 14:16 UTC (permalink / raw)
To: davem; +Cc: netdev, dhananjay.phadke
Hi
Series of 2 patches to fix tx timeout recovery and
null pointer exception while cleaning resources.
Plz apply these to net-2.6 tree.
Thanks
Amit Salecha
^ permalink raw reply
* [PATCH 1/2] netxen: fix tx timeout recovery for NX2031 chip
From: Amit Kumar Salecha @ 2010-02-02 14:16 UTC (permalink / raw)
To: davem; +Cc: netdev, dhananjay.phadke, Vernon Mauery
In-Reply-To: <1265120181-1671-1-git-send-email-amit.salecha@qlogic.com>
For NX2031, first try to scrub interrupt before requesting firmware
reset. Return statement was missing after scrubbbing interrupt.
Signed-off-by: Vernon Mauery <vernux@us.ibm.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9f9d608..5209095 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1941,7 +1941,7 @@ static void netxen_tx_timeout_task(struct work_struct *work)
netif_wake_queue(adapter->netdev);
clear_bit(__NX_RESETTING, &adapter->state);
-
+ return;
} else {
clear_bit(__NX_RESETTING, &adapter->state);
if (!netxen_nic_reset_context(adapter)) {
--
1.5.6.1
^ permalink raw reply related
* RE: [PATCH net-next-2.6 09/13] net-caif: add CAIF netdevice
From: Marcel Holtmann @ 2010-02-02 14:14 UTC (permalink / raw)
To: Sjur Brændeland
Cc: Patrick McHardy, netdev, davem, stefano.babic, randy.dunlap
In-Reply-To: <61D8D34BB13CFE408D154529C120E079032A2145@eseldmw101.eemea.ericsson.se>
Hi Sjur,
> >> +int chnl_net_ioctl(unsigned int cmd, unsigned long arg, bool
> >> +from_user_land) { + struct chnl_net *priv;
> >> + int result = -1;
> >> + struct chnl_net *dev;
> >> + struct net_device *netdevptr;
> >> + int ret;
> >> + struct ifreq ifreq;
> >> + struct ifcaif_param param;
> >> + rtnl_lock();
> >> + if (from_user_land) {
> >> + if (copy_from_user(&ifreq, (const void *)arg, sizeof(ifreq)))
> >> + return -EFAULT; + } else
> >> + memcpy(&ifreq, (void *)arg, sizeof(ifreq));
> >
> > Why do you need both an ioctl and a netlink interface?
>
> Well, I would like to keep support for both netlink and ioctl.
> Internally we are using a netlink interface, and oFono is using ioctl to create interfaces.
we could try to convert oFono in using netlink. Shouldn't be that hard
as long as it is RTNL. Only the generic netlink is painful in userspace
applications with a mainloop.
Regards
Marcel
^ permalink raw reply
* Re: [BUG]? xfrm: INFO: inconsistent lock state
From: Yury Polyanskiy @ 2010-02-02 13:51 UTC (permalink / raw)
To: Herbert Xu
Cc: Wei Yongjun, netdev@vger.kernel.org, David S. Miller, peterz,
polyanskiy
In-Reply-To: <20100202074914.GD11081@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
On Tue, 2 Feb 2010 18:49:14 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Feb 01, 2010 at 06:01:20PM +0800, Wei Yongjun wrote:
> > I got following lock INFO in my Fedora12 box uner 2.6.33-rc6.
> > Is this a BUG?
>
> Apparently.
>
> This is introduced by
>
> commit 9e0d57fd6dad37d72a3ca6db00ca8c76f2215454
> Author: Yury Polyanskiy <polyanskiy@gmail.com>
> Date: Sun Nov 8 20:58:41 2009 -0800
>
> xfrm: SAD entries do not expire correctly after suspend-resume
>
> Whether this is a real dead-lock depends on whether hrtimers
> behave as real hard IRQs. If they do then yes it can deadlock.
If hrtimer_tasklet interface functions properly, the
xfrm_timer_handler should be called in softirq context (and thus is
never in parallel with xfrm_input()). The deadlock isn't possible then.
In this case it seems that for some reason xfrm_timer_handler() is
called in the hardirq context. The relevant code in hrtimer_tasklet:
static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
{
struct tasklet_hrtimer *ttimer =
container_of(timer, struct tasklet_hrtimer, timer);
if (hrtimer_is_hres_active(timer)) {
tasklet_hi_schedule(&ttimer->tasklet);
return HRTIMER_NORESTART;
}
return ttimer->function(timer);
}
I am copying Peter on this. Peter, how is it possible that
ttimer->function() is called in hardirq?
Could it be that switch from hres_active happened after the call to
trampoline and before the if() above?
Best,
Yury
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH net-next-2.6 09/13] net-caif: add CAIF netdevice
From: Sjur Brændeland @ 2010-02-02 12:37 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, davem, marcel, stefano.babic, randy.dunlap
In-Reply-To: <4B580A39.3000805@trash.net>
Hi Patrick.
Sorry for late response.
Patrick McHardy wrote:
> sjur.brandeland@stericsson.com wrote:
>> +static void ipcaif_net_init(struct net_device *dev) { + struct
>> chnl_net *priv; + dev->netdev_ops = &netdev_ops;
>> + dev->destructor = free_netdev;
>
> These (especially ->destructor) should be set in the setup function.
The ipcaif_net_init is actually the setup function, but it is badly named.
I'll rename it to ipcaif_net_setup, sorry for the confusion.
>
>> + dev->flags |= IFF_NOARP;
>> + dev->flags |= IFF_POINTOPOINT;
>> + dev->needed_headroom = CAIF_NEEDED_HEADROOM;
>> + dev->needed_tailroom = CAIF_NEEDED_TAILROOM;
>> + dev->mtu = SIZE_MTU;
>> + dev->tx_queue_len = CAIF_NET_DEFAULT_QUEUE_LEN;
>
> These too I guess, its uncommon to reinitialize mtu and tx_queue_len
> when setting a device down and up again.
>
>> +
>> + priv = (struct chnl_net *)netdev_priv(dev);
>> + priv->chnl.receive = chnl_recv_cb;
>> + priv->chnl.ctrlcmd = chnl_flowctrl_cb;
>> + priv->netdev = dev;
>> + priv->config.type = CAIF_CHTY_DATAGRAM;
>> + priv->config.phy_pref = CFPHYPREF_HIGH_BW;
>> + priv->config.priority = CAIF_PRIO_LOW;
>> + priv->config.u.dgm.connection_id = -1; /* Insert illegal value */
>> + priv->flowenabled = false; +
>> + ASSERT_RTNL();
>> + init_waitqueue_head(&priv->netmgmt_wq);
>> + list_add(&priv->list_field, &chnl_net_list); }
>
>> +static int chnl_net_hard_start_xmit(struct sk_buff *skb, struct
>> +net_device *dev)
>
> static netdev_tx_t
>
>> +{
>> + struct chnl_net *priv;
>> + struct cfpkt *pkt = NULL;
>> + int len;
>> + int result = -1;
>> +
>> + /* Get our private data. */
>> + priv = (struct chnl_net *)netdev_priv(dev);
>> + if (!priv)
>> + return -ENOSPC;
>
> This is an impossible condition, netdev_priv() will never return NULL.
> The cast is also unnecessary.
Thanks, I'll fix this.
>> +
>> +
>> + if (skb->len > priv->netdev->mtu) {
>> + pr_warning("CAIF: %s(): Size of skb exceeded MTU\n", __func__);
>> + return -ENOSPC; + }
>> +
>> + if (!priv->flowenabled) {
>> + pr_debug("CAIF: %s(): dropping packets flow off\n", __func__);
>> + return NETDEV_TX_BUSY; + }
>> +
>> + if (priv->config.type == CAIF_CHTY_DATAGRAM_LOOP) { + struct
>> iphdr *hdr; + __be32 swap;
>> + /* Retrieve IP header. */
>> + hdr = ip_hdr(skb);
>> + /* Change source and destination address. */
>> + swap = hdr->saddr;
>> + hdr->saddr = hdr->daddr;
>> + hdr->daddr = swap;
>
> swap()?
The modem provides a loopback function for the CAIF link type (CAIF_CHTY_DATAGRAM_LOOP).
This is useful for testing the physical link between modem and host.
In this scenario we need to swap src and destination ip address.
I'll move this to a separate function in next patch set.
>
>
>> +
>> +static int ipcaif_newlink(struct net *src_net, struct net_device
>> *dev, + struct nlattr *tb[], struct nlattr *data[]) { + int err;
>> + struct chnl_net *caifdev;
>> + ASSERT_RTNL();
>> + caifdev = netdev_priv(dev);
>> + caif_netlink_parms(data, &caifdev->config);
>> + err = register_netdevice(dev);
>> + if (err) {
>> + pr_warning("CAIF: %s(): device rtml registration failed\n", +
>> __func__); + goto out;
>> + }
>> + dev_hold(dev);
>
> What is this reference used for? You don't have a dellink function,
> so this looks like a leak.
I don't think it leaks because I do dev_put in chnl_net_uninit,
but you're right - I don't really need this. I'll remove the
dev_hold and dev_put completely in next patch-set.
>> +static struct rtnl_link_ops ipcaif_link_ops __read_mostly = {
>> + .kind = "caif", + .priv_size = (size_t)sizeof(struct chnl_net),
>
> Unnecessary cast.
OK, Thanks.
>
>> + .setup = ipcaif_net_init,
>> + .maxtype = IFLA_CAIF_MAX,
>> + .policy = ipcaif_policy,
>> + .newlink = ipcaif_newlink,
>> + .changelink = ipcaif_changelink,
>> + .get_size = ipcaif_get_size,
>> + .fill_info = ipcaif_fill_info,
>> +
>> +};
>> +
>> +int chnl_net_ioctl(unsigned int cmd, unsigned long arg, bool
>> +from_user_land) { + struct chnl_net *priv;
>> + int result = -1;
>> + struct chnl_net *dev;
>> + struct net_device *netdevptr;
>> + int ret;
>> + struct ifreq ifreq;
>> + struct ifcaif_param param;
>> + rtnl_lock();
>> + if (from_user_land) {
>> + if (copy_from_user(&ifreq, (const void *)arg, sizeof(ifreq)))
>> + return -EFAULT; + } else
>> + memcpy(&ifreq, (void *)arg, sizeof(ifreq));
>
> Why do you need both an ioctl and a netlink interface?
Well, I would like to keep support for both netlink and ioctl.
Internally we are using a netlink interface, and oFono is using ioctl to create interfaces.
>> +static int __init chnl_init_module(void) {
>> + int err = -1;
>> + caif_register_ioctl(chnl_net_ioctl);
>> + err = rtnl_link_register(&ipcaif_link_ops);
>> + if (err < 0) {
>> + rtnl_link_unregister(&ipcaif_link_ops);
>
> You don't need to unregister on error. The ioctl should be
> unregistered I guess.
Very well spotted, thanks. This could leave wild pointers.
>> +static void __exit chnl_exit_module(void) {
>> + struct chnl_net *dev = NULL;
>> + struct list_head *list_node;
>> + struct list_head *_tmp;
>> + rtnl_lock();
>> + list_for_each_safe(list_node, _tmp, &chnl_net_list) {
>> + dev = list_entry(list_node, struct chnl_net, list_field);
>> + delete_device(dev); + }
>> + rtnl_unlock();
>> + rtnl_link_unregister(&ipcaif_link_ops);
>> + caif_register_ioctl(NULL);
>
> This is racy, rtnl_link_unregister() will clean up all CAIF devices,
> but the ioctl handler might register new ones after that. I'd suggest
> to drop the ioctl interface completely.
You're right thank you, I'll fix this.
BR/Sjur
^ permalink raw reply
* Re: [PATCH] netfilter: per netns nf_conntrack_cachep
From: Jon Masters @ 2010-02-02 11:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Dobriyan, Patrick McHardy, linux-kernel, netdev,
netfilter-devel, Paul E. McKenney
In-Reply-To: <1265108690.2861.118.camel@tonnant>
On Tue, 2010-02-02 at 06:04 -0500, Jon Masters wrote:
> On Mon, 2010-02-01 at 16:02 +0100, Eric Dumazet wrote:
> > Le lundi 01 février 2010 à 16:58 +0200, Alexey Dobriyan a écrit :
> > > On Mon, Feb 1, 2010 at 4:52 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > > + net->ct.nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
> > > > + sizeof(struct nf_conn), 0,
> > > > + SLAB_DESTROY_BY_RCU, NULL);
> > >
> > > Duplicate slab name detected.
> > >
> >
> > OK, need to build an unique name I guess... "nf_conntrack-%d", net->id
>
> I shoved in an kasprintf but of course there isn't a per-namespace "id".
> We probably should have one (or, a nice "name"), but meanwhile I am
> using the address of the net struct like "nf_ct-%p".
-ENOBANANA
Applying just this patch (without the per-ns hashtable metadata, but
with a trivial fix to name using nf_ct-%p for now), we still fall over
in the conntrack lookup code every single time:
[ 210.697337] device vnet2 entered promiscuous mode
[ 210.703868] br0: port 4(vnet2) entering forwarding state
[ 220.766146] vnet2: no IPv6 routers present
[ 236.216957] BUG: unable to handle kernel paging request at
ffff88037e613588
[ 236.217638] IP: [<ffffffff813d47cc>] __nf_conntrack_find+0x53/0xb1
[ 236.217638] PGD 1a3c063 PUD 0
[ 236.217638] Oops: 0000 [#1] SMP
[ 236.217638] last sysfs
file: /sys/devices/virtual/block/md0/md/sync_speed
Entering kdb (current=0xffff8801f32e8000, pid 3214) on processor 1 Oops:
(null)
due to oops @ 0xffffffff813d47cc
CPU 1 <c>
<d>Pid: 3214, comm: qemu-kvm Not tainted 2.6.33-rc5 #25 0F9382/Precision
WorkStation 490
<d>RIP: 0010:[<ffffffff813d47cc>] [<ffffffff813d47cc>]
__nf_conntrack_find+0x53/0xb1
<d>RSP: 0018:ffff8801d41a3758 EFLAGS: 00010286
<d>RAX: ffff88037e613588 RBX: ffff8801d41a3868 RCX: 000000004d1bab3a
<d>RDX: ffff8801f32e8000 RSI: 0000000081b04540 RDI: 0000000000000246
<d>RBP: ffff8801d41a3798 R08: 0000000045f1b45f R09: 000000005e5ffada
<d>R10: 00000000501b6d3f R11: ffff8801d41a388c R12: ffffffff8288ef70
<d>R13: ffff8801d41a3868 R14: ffffffffffffffb8 R15: 000000002bfc66b1
<d>FS: 00007f0059b01780(0000) GS:ffff88002fa00000(0000)
knlGS:0000000000000000
<d>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
<d>CR2: ffff88037e613588 CR3: 00000001f05ed000 CR4: 00000000000026e0
<d>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<d>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-kvm (pid: 3214, threadinfo ffff8801d41a2000, task
ffff8801f32e8000)
<0>Stack:
ffff8802206302e0 000000015fe33588 ffffffffffffffb8 ffffffff8288ef70
<0> ffff8802206302e0 ffff8801d41a3868 ffffffffffffffb8 ffffffff8288ef70
<0> ffff8801d41a37e8 ffffffff813d485d ffff8802206302e0 ffff8802206302e0
<0>Call Trace:
[1]more> <0> [<ffffffff813d485d>] nf_conntrack_find_get+0x33/0xb7
[1]more> <0> [<ffffffff813d58d5>] nf_conntrack_in+0x209/0x7b4
[1]more> <0> [<ffffffff8141a413>] ipv4_conntrack_local+0x40/0x49
[1]more> <0> [<ffffffff813d278a>] nf_iterate+0x46/0x89
[1]more> <0> [<ffffffff813e5458>] ? dst_output+0x0/0x12
[1]more> <0> [<ffffffff813d2845>] nf_hook_slow+0x78/0xe0
[1]more> <0> [<ffffffff813e5458>] ? dst_output+0x0/0x12
[1]more> <0> [<ffffffff813e67f2>] nf_hook_thresh.clone.0+0x41/0x4a
[1]more> <0> [<ffffffff81126846>] ? poll_freewait+0x32/0x70
[1]more> <0> [<ffffffff813e6ad2>] __ip_local_out+0x7e/0x80
[1]more> <0> [<ffffffff813e6aea>] ip_local_out+0x16/0x27
[1]more> <0> [<ffffffff813e7118>] ip_queue_xmit+0x30e/0x36e
[1]more> <0> [<ffffffff813f8aec>] tcp_transmit_skb+0x707/0x745
[1]more> <0> [<ffffffff813fb15e>] tcp_write_xmit+0x7cb/0x8ba
[1]more> <0> [<ffffffff813fb2b2>] __tcp_push_pending_frames+0x2f/0x5d
[1]more> <0> [<ffffffff813edecf>] tcp_push+0x88/0x8a
[1]more> <0> [<ffffffff813f01f0>] tcp_sendmsg+0x760/0x85b
[1]more> <0> [<ffffffff813a3ccc>] __sock_sendmsg+0x5e/0x69
[1]more> <0> [<ffffffff813a3fe2>] sock_sendmsg+0xa8/0xc1
[1]more> <0> [<ffffffff81119641>] ? fget_light+0x57/0xf2
[1]more> <0> [<ffffffff811195e8>] ? rcu_read_unlock+0x21/0x23
[1]more> <0> [<ffffffff81119641>] ? fget_light+0x57/0xf2
[1]more> <0> [<ffffffff8114893e>] ? eventfd_write+0x94/0x186
[1]more> <0> [<ffffffff813a4072>] ? sockfd_lookup_light+0x20/0x58
[1]more> <0> [<ffffffff813a5d37>] sys_sendto+0x110/0x152
[1]more> <0> [<ffffffff81118318>] ? fsnotify_modify+0x6c/0x74
[1]more> <0> [<ffffffff81118ad6>] ? vfs_write+0xd3/0x10b
[1]more> <0> [<ffffffff81457f00>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[1]more> <0> [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
[1]more> <0>Code: 48 89 df e8 21 f5 ff ff 41 89 c7 45 89 ff e8 e7 fb c7
ff 4a 8d 04 fd 00 00 00 00 48 89 45 c8 48 8b 45 c8 49 03 84 24 98 06 00
00 <4c> 8b 28 eb 14 65 83 40 04 01 e8 bc fc c7 ff eb 3b 65 83 00 01
[1]more> Call Trace:
[1]more> [<ffffffff813d47b4>] ? __nf_conntrack_find+0x3b/0xb1
[1]more> [<ffffffff813d485d>] nf_conntrack_find_get+0x33/0xb7
[1]more> [<ffffffff813d58d5>] nf_conntrack_in+0x209/0x7b4
[1]more> [<ffffffff8141a413>] ipv4_conntrack_local+0x40/0x49
[1]more> [<ffffffff813d278a>] nf_iterate+0x46/0x89
[1]more> [<ffffffff813e5458>] ? dst_output+0x0/0x12
[1]more> [<ffffffff813d2845>] nf_hook_slow+0x78/0xe0
[1]more> [<ffffffff813e5458>] ? dst_output+0x0/0x12
[1]more> [<ffffffff813e67f2>] nf_hook_thresh.clone.0+0x41/0x4a
[1]more> [<ffffffff81126846>] ? poll_freewait+0x32/0x70
[1]more> [<ffffffff813e6ad2>] __ip_local_out+0x7e/0x80
[1]more> [<ffffffff813e6aea>] ip_local_out+0x16/0x27
[1]more> [<ffffffff813e7118>] ip_queue_xmit+0x30e/0x36e
[1]more> [<ffffffff813f8aec>] tcp_transmit_skb+0x707/0x745
[1]more> [<ffffffff813fb15e>] tcp_write_xmit+0x7cb/0x8ba
[1]more> [<ffffffff813fb2b2>] __tcp_push_pending_frames+0x2f/0x5d
[1]more> [<ffffffff813edecf>] tcp_push+0x88/0x8a
[1]more> [<ffffffff813f01f0>] tcp_sendmsg+0x760/0x85b
[1]more> [<ffffffff813a3ccc>] __sock_sendmsg+0x5e/0x69
[1]more> [<ffffffff813a3fe2>] sock_sendmsg+0xa8/0xc1
[1]more> [<ffffffff81119641>] ? fget_light+0x57/0xf2
[1]more> [<ffffffff811195e8>] ? rcu_read_unlock+0x21/0x23
[1]more> [<ffffffff81119641>] ? fget_light+0x57/0xf2
[1]more> [<ffffffff8114893e>] ? eventfd_write+0x94/0x186
[1]more> [<ffffffff813a4072>] ? sockfd_lookup_light+0x20/0x58
[1]more> [<ffffffff813a5d37>] sys_sendto+0x110/0x152
[1]more> [<ffffffff81118318>] ? fsnotify_modify+0x6c/0x74
[1]more> [<ffffffff81118ad6>] ? vfs_write+0xd3/0x10b
[1]more> [<ffffffff81457f00>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[1]more> [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
I think there's something more fundamental going on here.
Jon.
^ permalink raw reply
* Re: [PATCH] netfilter: per netns nf_conntrack_cachep
From: Jon Masters @ 2010-02-02 11:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Dobriyan, Patrick McHardy, linux-kernel, netdev,
netfilter-devel, Paul E. McKenney
In-Reply-To: <1265036548.2848.55.camel@edumazet-laptop>
On Mon, 2010-02-01 at 16:02 +0100, Eric Dumazet wrote:
> Le lundi 01 février 2010 à 16:58 +0200, Alexey Dobriyan a écrit :
> > On Mon, Feb 1, 2010 at 4:52 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > + net->ct.nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
> > > + sizeof(struct nf_conn), 0,
> > > + SLAB_DESTROY_BY_RCU, NULL);
> >
> > Duplicate slab name detected.
> >
>
> OK, need to build an unique name I guess... "nf_conntrack-%d", net->id
I shoved in an kasprintf but of course there isn't a per-namespace "id".
We probably should have one (or, a nice "name"), but meanwhile I am
using the address of the net struct like "nf_ct-%p".
Jon.
^ permalink raw reply
* Re: [PATCH] netfilter: per netns nf_conntrack_cachep
From: Jon Masters @ 2010-02-02 10:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Dobriyan, Patrick McHardy, linux-kernel, netdev,
netfilter-devel, Paul E. McKenney
In-Reply-To: <1265035970.2848.50.camel@edumazet-laptop>
On Mon, 2010-02-01 at 15:52 +0100, Eric Dumazet wrote:
> [PATCH] netfilter: per netns nf_conntrack_cachep
>
> nf_conntrack_cachep is currently shared by all netns instances, but
> because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.
>
> If we use a shared slab cache, one object can instantly flight between
> one hash table (netns ONE) to another one (netns TWO), and concurrent
> reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
> can be fooled without notice, because no RCU grace period has to be
> observed between object freeing and its reuse.
I'll test this patch.
After some lengthy debugging, what actually happens here is that the
nf_conntrack_cachep SL*U*B gets corrupted such that the contained
per-cpu cpu_slabs are all pointing to the address of htable_size, which
is then helpfully set to be the value of the individual freelists (the
address of the base of the kmem_cache), or offset '51' into the table.
The worrying thing is it looks like this is actually corrupting other
random memory too, it just happens to bite once we get this far.
Jon.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: mcp251x: Move to threaded interrupts instead of workqueues.
From: Wolfgang Grandegger @ 2010-02-02 10:00 UTC (permalink / raw)
To: Christian Pellegrin; +Cc: socketcan-core, netdev
In-Reply-To: <1264959793-1797-1-git-send-email-chripell@fsfe.org>
Hi Christian,
the discussion about OSM brought up the issue with bus errors...
Christian Pellegrin wrote:
> This patch addresses concerns about efficiency of handling incoming
> packets. Handling of interrupts is done in a threaded interrupt handler
> which has a smaller latency than workqueues. This change needed a rework
> of the locking scheme that was much simplified. Some other (more or less
> longstanding) bugs are fixed: utilization of just half of the RX
> buffers, useless wait for interrupt on open, more reliable reset
> sequence. The MERR interrupt is not used anymore: it overloads the CPU
> in bus-off state without any additional information.
The MERR should not come when the device is in bus-off. Nevertheless, it
may come frequently in any state below, e.g. error passive. We regard
bus-errors as vital information and they should be communicated to user
space via error messages. For exactly that reason we do not disable bus
errors on other CAN controllers, like the SJA1000 or the AT91, even if
they may produce high load. But we may discuss some generic interface to
disable bus-errors somehow, maybe configurable via ctrlmode. What do you
think?
Wolfgang.
^ permalink raw reply
* virtio GSO makes IPv6 unbearably slow - might be e100 problem?
From: Bernhard Schmidt @ 2010-02-02 9:40 UTC (permalink / raw)
To: netdev
[ Forwarding from the KVM mailinglist, since an answer suggests it might
actually be related to broken IPv6 GSO in e100 of the host ]
Hi,
I have a really weird issue all of the sudden on _one_ of my two KVM
hosts. The other one, while running on a different hardware in a
different network, is configured in a very similar way and does not show
these issues (so far).
Host:
- AMD Athlon64 3500+
- Debian testing amd64
- Kernel 2.6.32-trunk from Debian
- Debian qemu-kvm 0.11.1+dfsg-1
The system has a routed uplink (Intel e100) and an internal bridge, that
connects all the VMs (only virtual ports). Networking in the VMs is
usually configured like this:
-net nic,model=virtio,macaddr=00:16:3E:7C:30:AA -net
tap,ifname=vm.compile,script=no
The guests are Debian amd64, either testing or stable, running a custom
stripped 2.6.31.6 or 2.6.32.7. I've also tested older kernels (2.6.28.2
and 2.6.30.4) and have seen the same problem.
Problem:
IPv6 tx throughput from a Guest to a host in the internet is extremely
low (around 16kB/s). IPv6 rx is fine, as well as throughput in IPv4
(both ways). Also fine is throughput from the guest to the host and from
the host to the internet (also both ways).
Running tcpdump on the tap-device on the host while doing an scp to
another system shows this:
20:43:27.130438 IP6 GUEST.59864 > DEST.22: Flags [.], seq 70785:73641, ack 2128, win 327, options [nop,nop,TS val 4294920148 ecr 63373335], length 2856
20:43:27.130506 IP6 HOST > GUEST: ICMP6, packet too big, mtu 1500, length 1240
20:43:27.131965 IP6 DEST.22 > GUEST.59864: Flags [.], ack 69357, win 501, options [nop,nop,TS val 63373335 ecr 4294920144], length 0
20:43:27.131996 IP6 DEST.22 > GUEST.59864: Flags [.], ack 70785, win 501, options [nop,nop,TS val 63373335 ecr 4294920144], length 0
20:43:27.132651 IP6 GUEST.59864 > DEST.22: Flags [.], seq 73641:76497, ack 2128, win 327, options [nop,nop,TS val 4294920148 ecr 63373335], length 2856
20:43:27.132704 IP6 HOST > GUEST: ICMP6, packet too big, mtu 1500, length 1240
20:43:27.346347 IP6 GUEST.59864 > DEST.22: Flags [.], seq 70785:72213, ack 2128, win 327, options [nop,nop,TS val 4294920202 ecr 63373335], length 1428
20:43:27.360411 IP6 DEST.22 > GUEST.59864: Flags [.], ack 72213, win 501, options [nop,nop,TS val 63373358 ecr 4294920202], length 0
20:43:27.361045 IP6 GUEST.59864 > DEST.22: Flags [.], seq 76497:79353, ack 2128, win 327, options [nop,nop,TS val 4294920205 ecr 63373358], length 2856
So, the guest sends packets of 2856 bytes, which are too large to pass
through the eth0 of the host (1500 bytes). Thus, the host rejects the
packet and sends back an ICMPv6 packet too big, which sometimes makes
the guest send at least one packet with the small MTU, but sometimes it
doesn't. This is repeated all over and slows down the process.
According to ethtool GSO is enabled on the guest, but disabling it using
ethtool does not have any effect. But giving the kernel
"virtio_net.gso=0" in append fixes the issue completely.
Anyone having any ideas?
Best Regards,
Bernhard
^ permalink raw reply
* Re: [net-next-2.6 v2] can: add support for CAN interface cards based on the PLX90xx PCI bridge
From: Wolfgang Grandegger @ 2010-02-02 8:02 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100201210507.GD32624-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
Ira W. Snyder wrote:
> On Mon, Feb 01, 2010 at 09:31:06PM +0100, Wolfgang Grandegger wrote:
>> Ira W. Snyder wrote:
>>> On Tue, Feb 02, 2010 at 01:42:44AM +0600, Pavel B. Cheblakov wrote:
>>>> From: Pavel Cheblakov <P.B.Cheblakov-tHBF8D5G73F4OK5fxMSSsQ@public.gmane.org>
>>>>
>>>> This driver is for CAN interface cards based on the PLX90xx PCI bridge.
>>>> Driver supports now:
>>>> - Adlink PCI-7841/cPCI-7841 card (http://www.adlinktech.com/)
>>>> - Adlink PCI-7841/cPCI-7841 SE card
>>>> - Marathon CAN-bus-PCI card (http://www.marathon.ru/)
>>>> - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
>>>>
>>>> Changes since v1:
>>>> - Added some defines for static inline int plx_pci_check_sja1000(...)
>>>> - static struct pci_device_id plx_pci_tbl[] replaced by
>>>> static DEFINE_PCI_DEVICE_TABLE(plx_pci_tbl)
>>>> - Typo fixed
>>>>
>>> Hello,
>>>
>>> Any ideas if this driver could support the Janz PCI CAN cards as well? I
>>> don't have any documentation for the cards, and I'd love to get away
>>> from their closed-source drivers.
>> Is it a passive or and intelligent CAN PCI card? What is the name of the
>> card? A intelligent card will run its own firmware and you do not have
>> direct access to the SJA1000. Pavel plx_pci driver is quite generic and
>> it should not be a big deal to support a PLX90xx based passive card.
>>
>
> It is an intelligent CAN PCI card. I'm pretty sure they're the card
> described here: http://www.janz.de/as/en/can-cp6/k2.html
>
> Since this driver is for passive cards, it clearly won't work. Are there
> any examples of drivers written for intelligent CAN cards? Until I found
> the website above, I'd never seen any data sheets for this card. They
> look like they may have enough information to write a driver to
> interface with the new Linux CAN layer.
The esd_pci331 driver from the SVN repository is for an intelligent
card, if I remember correctly. But using an intelligent card just for
the raw CAN protocol seems kind of overkill to me.
> We should probably start a new thread about this, it is getting
> off-topic for Pavel's CAN driver. Is the socketcan mailing list ok for
> this kind of discussion?
Of course, if it's about Socket-CAN.
Wolfgang.
> Thanks,
> Ira
> _______________________________________________
> Socketcan-core mailing list
> Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
> https://lists.berlios.de/mailman/listinfo/socketcan-core
>
>
^ 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