* RE: [PATCH 0/4] net/mlx4: Fixes to mlx4 driver
From: Yevgeny Petrilin @ 2012-08-03 7:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120802.161251.331601378090436432.davem@davemloft.net>
> > Yevgeny Petrilin (3):
> > net/mlx4_en: Setting the NETIF_F_GRO flag back to dev->hw_features
>
> As pointed out, this isn't a bug.
>
> You just made this change purely via code inspection, and that's very
> disappointing because this would have been so simple to validate.
Hello Dave,
You are absolutely right,
I should have checked it better.
There are few more modules setting this flag during device initialization, I guess we need to clean all.
Can you please apply the other 3 or should I resubmit them?
Thanks,
Yevgeny
^ permalink raw reply
* Re: [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 7:10 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20120802.234311.2108069975669469931.davem@davemloft.net>
On Thu, 2012-08-02 at 23:43 -0700, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Fri, 3 Aug 2012 14:27:51 +0800
>
> > @@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
> >
> > IP6CB(skb)->flags |= IP6SKB_FORWARDED;
> >
> > - return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
> > + return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
> > ip6mr_forward2_finish);
> >
>
> This patch has the same problem I mentioned, it means someone who is
> now matching on the VIF device will now fail to do son.
>
> You have to understand that you simply cannot change the behavior
> here without breaking something for someone.
Hi, David:
Can you give me some more details what I break in this fix?
As my understanding, in the ip6mr_forward2(), vifi is the VIF index for
output, we can get the output device used vif->dev and record input
device before change skb->dev; then used FORWARD chain match the rules.
Tks.
^ permalink raw reply
* [PATCH] ipv4/ipv6: multicast api unappropriate errno fix.
From: Li Wei @ 2012-08-03 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, dlstevens, Li Wei
commit 917f2f105([IPV4]: multicast API "join" issues) corrected
some errno values but also caused unappropriate errno returned.
With an unjoined group address, return -EADDRNOTAVAIL would be
much better than -EINVAL.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/ipv4/igmp.c | 8 +++-----
net/ipv6/mcast.c | 8 +++-----
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 6699f23..c45c092 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1933,10 +1933,8 @@ int ip_mc_source(int add, int omode, struct sock *sk, struct
(pmc->multi.imr_ifindex == imr.imr_ifindex))
break;
}
- if (!pmc) { /* must have a prior join */
- err = -EINVAL;
- goto done;
- }
+ if (!pmc) /* must have a prior join */
+ goto done; /* err = -EADDRNOTAVAIL */
/* if a source filter was set, must be the same mode as before */
if (pmc->sflist) {
if (pmc->sfmode != omode) {
@@ -2076,7 +2074,7 @@ int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf, int ifindex)
break;
}
if (!pmc) { /* must have a prior join */
- err = -EINVAL;
+ err = -EADDRNOTAVAIL;
goto done;
}
if (msf->imsf_numsrc) {
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 92f8e48..89dcefd 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -347,10 +347,8 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
if (ipv6_addr_equal(&pmc->addr, group))
break;
}
- if (!pmc) { /* must have a prior join */
- err = -EINVAL;
- goto done;
- }
+ if (!pmc) /* must have a prior join */
+ goto done; /* err = -EADDRNOTAVAIL */
/* if a source filter was set, must be the same mode as before */
if (pmc->sflist) {
if (pmc->sfmode != omode) {
@@ -488,7 +486,7 @@ int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf)
break;
}
if (!pmc) { /* must have a prior join */
- err = -EINVAL;
+ err = -EADDRNOTAVAIL;
goto done;
}
if (gsf->gf_numsrc) {
--
1.7.10.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: David Miller @ 2012-08-03 6:43 UTC (permalink / raw)
To: mypopydev; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1343975271-4263-1-git-send-email-mypopydev@gmail.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Fri, 3 Aug 2012 14:27:51 +0800
> @@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
>
> IP6CB(skb)->flags |= IP6SKB_FORWARDED;
>
> - return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
> + return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
> ip6mr_forward2_finish);
>
This patch has the same problem I mentioned, it means someone who is
now matching on the VIF device will now fail to do son.
You have to understand that you simply cannot change the behavior
here without breaking something for someone.
^ permalink raw reply
* [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 6:27 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, mypopydev
Current kernel change the skb's net device with output device before netfilter FORWARD chain,
that will lead to can't match the IPv6 multicast packets with input net device in netfilter
FORWARD chain.
the test case for reproduce this issue as follow:
IPv6 multicast udp stream from eth0(input device) to eth1(output device)
Dst Addr: Port
{ff03::4}:6789 --->
Router
+---------------------------+
-------> | [eth0] --FORWARD--> [eth1]| ------->
+---------------------------+
ip6tables -I FORWARD -p udp -i eth0 -o eth1 --dst ff03::4 -j ACCEPT [first rules ]
ip6tables -A FORWARD -p udp -i eth1 -o eth1 --dst ff03::4 -j ACCEPT [second rules]
Before fix this issue, it will match the second rules not the first rules. you can used
command "ip6tables -L -vnx" to check the match result.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv6/ip6mr.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 4532973..b099dfb 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1901,6 +1901,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
struct ipv6hdr *ipv6h;
struct mif_device *vif = &mrt->vif6_table[vifi];
struct net_device *dev;
+ struct net_device *indev;
struct dst_entry *dst;
struct flowi6 fl6;
@@ -1946,6 +1947,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
* result in receiving multiple packets.
*/
dev = vif->dev;
+ indev = skb->dev;
skb->dev = dev;
vif->pkt_out++;
vif->bytes_out += skb->len;
@@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
IP6CB(skb)->flags |= IP6SKB_FORWARDED;
- return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
+ return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
ip6mr_forward2_finish);
out_free:
--
1.7.2.5
^ permalink raw reply related
* 0432..180..52882...2004..
From: eef @ 2012-08-03 6:04 UTC (permalink / raw)
To: ppechmann
经理/财务您好！
我司可代开全国各地普通(国-地税)发&票，
点数优惠，承诺绝对真票，可验证后再付款。
（若打扰，请谅解）。
聯系人:杨小姐
手 機: 13818893119
Q Q: 925805893
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 6:10 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, netdev
In-Reply-To: <20120802.162015.2106150087918919160.davem@davemloft.net>
On Thu, 2012-08-02 at 16:20 -0700, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Thu, 2 Aug 2012 21:00:55 +0800
>
> > Current kernel change the skb's net device with output device before netfilter FORWARD chain,
> > that will lead to can't match the IPv6 multicast packets with input net device in netfilter
> > FORWARD chain.
> >
> > the test case for reproduce this issue as follow:
> >
> > IPv6 multicast udp stream from eth0(input device) to eth1(output device)
>
> Your change means we now can't match on the VIF device in this situation.
>
> I'm not applying this patch, it breaks as much as it fixes.
Hi, David:
Maybe I need to used conservative approach to fix it and don't breaks
much more, I will supply the version 2 patch for this issue.
Tks.
^ permalink raw reply
* RE: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Hiremath, Vaibhav @ 2012-08-03 5:53 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev@vger.kernel.org, N, Mugunthan V,
devicetree-discuss@lists.ozlabs.org, koen@dominion.thruhere.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <501B6020.7090502@gmail.com>
On Fri, Aug 03, 2012 at 10:52:40, Daniel Mack wrote:
> On 03.08.2012 07:16, Vaibhav Hiremath wrote:
> >
> >
> > On 8/3/2012 1:13 AM, Daniel Mack wrote:
> >> Make the driver control the device clocks. Appearantly, the Davinci
> >> platform probes this driver with the clock all powered up, but on OMAP,
> >> this isn't the case.
> >>
> >> Signed-off-by: Daniel Mack <zonque@gmail.com>
> >> ---
> >> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> >> 1 file changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> >> index cd7ee20..b4b6015 100644
> >> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> >> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> >> goto bail_out;
> >> }
> >>
> >> + clk_enable(data->clk);
> >> +
> >> dev_set_drvdata(dev, data);
> >> data->dev = dev;
> >> spin_lock_init(&data->lock);
> >> @@ -379,8 +381,11 @@ bail_out:
> >> if (data->bus)
> >> mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >> clk_put(data->clk);
> >> + }
> >> +
> >> pm_runtime_put_sync(&pdev->dev);
> >> pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
> >> if (data->bus)
> >> mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >> clk_put(data->clk);
> >> + }
> >> +
> >> pm_runtime_put_sync(&pdev->dev);
> >> pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> >> data->suspended = true;
> >> spin_unlock(&data->lock);
> >>
> >> + clk_disable(data->clk);
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> >> struct davinci_mdio_data *data = dev_get_drvdata(dev);
> >> u32 ctrl;
> >>
> >> + clk_enable(data->clk);
> >> +
> >
> > Danial,
> >
> > I would request you to wait for this, its not that simple and straight.
> > And once you migrate to runtime PM you don't need clk_enable/disable,
> > this should get handled under runtime PM api's.
>
> As I said, it can be dropped.
>
> > Also have you read my another email post -
> >
> > http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
> >
> > Certainly, with respect to CPSW & MDIO, this patch is not enough and
> > requires further investigation. I have started looking at this and
> > hopefully will have some solution soon...
>
> Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
> that applied, and the hwmod added (in the patch I posted yesterday), I
> can at least mount the rootfs via NFS, which is all I currently need.
>
>
I certainly understand your requirement here.
Actually this is not the only device we have, the same issue is applicable
to PWM subsystem available in AM335x. Hopefully I should have something soon
on this.
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:51 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343972729.9299.596.camel@edumazet-glaptop>
On Fri, 2012-08-03 at 07:45 +0200, Eric Dumazet wrote:
> Yes I am sure (by the way my output device was dummy0, not lo, but its
> the same for the case here)
Of course, the ifindex was related to lo, sorry for the confusion,
-ENOCOFFEE_YET_THIS_MORNING
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:45 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <20120802.162601.2080519313891137444.davem@davemloft.net>
On Thu, 2012-08-02 at 16:26 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 02 Aug 2012 12:28:30 +0200
>
> > Strange because I see no false sharing on this ifindex location for
> > loopback device.
>
> Are you sure netdev->rx_dropped isn't being incremented? That appears
> as if it would land on the same cache line as netdev->ifindex.
>
Yes I am sure (by the way my output device was dummy0, not lo, but its
the same for the case here)
offsetof(struct net_device, features)=0x80
... (all features are mostly read only)
offsetof(struct net_device, ifindex)=0xa0
struct net_device_stats stats; is untouched on dummy device
offsetof(struct net_device, rx_dropped)=0x160
So thats only the dereference done million times per second that show in
the profiles, even if cache lines are clean and in cpu cache.
I see that even more clear in the IN_DEV_ROUTE_LOCALNET(in_dev) macro in
ip_route_input_slow(), doing so many derefs :
Its actually faster to avoid it, if we already have the net pointer in
hand : IN_DEV_NET_ROUTE_LOCALNET(in_dev, net)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 67f9dda..d032780 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -104,9 +104,14 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
#define IN_DEV_ANDCONF(in_dev, attr) \
(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) && \
IN_DEV_CONF_GET((in_dev), attr))
-#define IN_DEV_ORCONF(in_dev, attr) \
- (IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) || \
+
+#define IN_DEV_NET_ORCONF(in_dev, net, attr) \
+ (IPV4_DEVCONF_ALL(net, attr) || \
IN_DEV_CONF_GET((in_dev), attr))
+
+#define IN_DEV_ORCONF(in_dev, attr) \
+ IN_DEV_NET_ORCONF(in_dev, dev_net(in_dev->dev), attr)
+
#define IN_DEV_MAXCONF(in_dev, attr) \
(max(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr), \
IN_DEV_CONF_GET((in_dev), attr)))
@@ -133,6 +138,8 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
IN_DEV_ORCONF((in_dev), \
PROMOTE_SECONDARIES)
#define IN_DEV_ROUTE_LOCALNET(in_dev) IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
+#define IN_DEV_NET_ROUTE_LOCALNET(in_dev, net) \
+ IN_DEV_NET_ORCONF(in_dev, net, ROUTE_LOCALNET)
#define IN_DEV_RX_REDIRECTS(in_dev) \
((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..5e88e3b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(daddr))
goto martian_destination;
- if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
- if (ipv4_is_loopback(daddr))
- goto martian_destination;
+ if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_destination;
- if (ipv4_is_loopback(saddr))
- goto martian_source;
- }
+ if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_source;
/*
* Now we are ready to route packet.
^ permalink raw reply related
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Daniel Mack @ 2012-08-03 5:22 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <501B5EC1.7010304@ti.com>
On 03.08.2012 07:16, Vaibhav Hiremath wrote:
>
>
> On 8/3/2012 1:13 AM, Daniel Mack wrote:
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
>> index cd7ee20..b4b6015 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
>> goto bail_out;
>> }
>>
>> + clk_enable(data->clk);
>> +
>> dev_set_drvdata(dev, data);
>> data->dev = dev;
>> spin_lock_init(&data->lock);
>> @@ -379,8 +381,11 @@ bail_out:
>> if (data->bus)
>> mdiobus_free(data->bus);
>>
>> - if (data->clk)
>> + if (data->clk) {
>> + clk_disable(data->clk);
>> clk_put(data->clk);
>> + }
>> +
>> pm_runtime_put_sync(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
>> if (data->bus)
>> mdiobus_free(data->bus);
>>
>> - if (data->clk)
>> + if (data->clk) {
>> + clk_disable(data->clk);
>> clk_put(data->clk);
>> + }
>> +
>> pm_runtime_put_sync(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
>> data->suspended = true;
>> spin_unlock(&data->lock);
>>
>> + clk_disable(data->clk);
>> +
>> return 0;
>> }
>>
>> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
>> struct davinci_mdio_data *data = dev_get_drvdata(dev);
>> u32 ctrl;
>>
>> + clk_enable(data->clk);
>> +
>
> Danial,
>
> I would request you to wait for this, its not that simple and straight.
> And once you migrate to runtime PM you don't need clk_enable/disable,
> this should get handled under runtime PM api's.
As I said, it can be dropped.
> Also have you read my another email post -
>
> http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
>
> Certainly, with respect to CPSW & MDIO, this patch is not enough and
> requires further investigation. I have started looking at this and
> hopefully will have some solution soon...
Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
that applied, and the hwmod added (in the patch I posted yesterday), I
can at least mount the rootfs via NFS, which is all I currently need.
Best regards,
Daniel
^ permalink raw reply
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Vaibhav Hiremath @ 2012-08-03 5:16 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <1343936616-29318-1-git-send-email-zonque@gmail.com>
On 8/3/2012 1:13 AM, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index cd7ee20..b4b6015 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> goto bail_out;
> }
>
> + clk_enable(data->clk);
> +
> dev_set_drvdata(dev, data);
> data->dev = dev;
> spin_lock_init(&data->lock);
> @@ -379,8 +381,11 @@ bail_out:
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> data->suspended = true;
> spin_unlock(&data->lock);
>
> + clk_disable(data->clk);
> +
> return 0;
> }
>
> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> struct davinci_mdio_data *data = dev_get_drvdata(dev);
> u32 ctrl;
>
> + clk_enable(data->clk);
> +
Danial,
I would request you to wait for this, its not that simple and straight.
And once you migrate to runtime PM you don't need clk_enable/disable,
this should get handled under runtime PM api's.
Also have you read my another email post -
http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
Certainly, with respect to CPSW & MDIO, this patch is not enough and
requires further investigation. I have started looking at this and
hopefully will have some solution soon...
Thanks,
Vaibhav
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: John Fastabend @ 2012-08-03 4:50 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Chris Friesen, e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <20421.1343948491@death.nxdomain>
On 8/2/2012 4:01 PM, Jay Vosburgh wrote:
> Chris Friesen <chris.friesen@genband.com> wrote:
>
>> On 08/02/2012 04:26 PM, Chris Friesen wrote:
>>> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>>
>>>> The best long term solution is to have a user space API that
>>>> provides link state input to bonding on a per-slave basis, and then some
>>>> user space entity can perform whatever link monitoring method is
>>>> appropriate (e.g., LLDP) and pass the results to bonding.
>>>
>>> I think this has potential. This requires a virtual communication
>>> channel between guest/host if we want the host to be able to influence
>>> the guest's choice of active link, but I think that's not unreasonable.
>
> Not necessarily, if something like LLDP runs across the virtual
> link between the guest and slave, then the guest will notice when the
> link goes down (although perhaps not very quickly). I'm pretty sure the
> infrastructure to make LLDP work on inactive slaves is already there; as
> I recall, the "no wildcard" or "deliver exact" business in the receive
> path is at least partially for LLDP.
Right we run LLDP over the inactive bond. However because LLDP
uses nearest customer bridge, nearest bridge, or neareast non-tpmr
addresses it should be dropped by switching components. The problem
with having VMs send LLDP and _not_ dropping the packets is it looks
like multiple neighbors to the peer. The point is there is really an
edge relay like component in the hardware with SR-IOV. So likely using
LLDP do to do this wouldn't work
If you happen to have the 2010 802.1Q rev section 8.6.3 "frame
filtering" has some more details. The 802.1AB spec has details on the
multiple neighbor case.
>
> Still, though, isn't "influence the guest's choice" pretty much
> satisified by having the VF interface go carrier down in the guest when
> the host wants it to? Or are you thinking about more fine grained than
> that?
>
Perhaps one argument against this is if the hardware supports loopback
modes or the edge relay in the hardware is acting like a VEB it may
still be possible to support VF to VF traffic even if the external link
is down. Not sure how useful this is though or if any existing hardware
even supports it.
Just in case its not clear (it might not be) an edge relay (ER) is
defined in the new 802.1Qbg-2012 spec. "An ER supports local relay
among virtual stations and/or between a virtual station and other
stations on a bridged LAN". Similar to a bridge but without spanning
tree operations.
.John
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: xufeng zhang @ 2012-08-03 2:24 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Xufeng Zhang, Neil Horman, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <501AEE5E.8090303@gmail.com>
On 08/03/2012 05:17 AM, Vlad Yasevich wrote:
> On 07/31/2012 02:51 AM, xufeng zhang wrote:
>> Sorry, please ignore the above patch, there was an paste error.
>> Please check the following patch.
>> ============================================
>> I'm wondering if the below solution is fine to you which is based on
>> your changes.
>> BTW, I have verified this patch and it works ok for all the situation,
>> but only one problem persists:
>> there is a potential that commands will exceeds SCTP_MAX_NUM_COMMANDS
>> which happens during sending lots of small error DATA chunks.
>>
>
> I started thinking along the same vein, but was thinking that maybe it
> makes sense to make error list more generic. I need to check the spec
> on the ordering of ERROR chunks. If they are always after other
> control chunks, then maybe make an error list and queue all errors
> there. Then when sending control chunks, drain the control queue
> first, then the error queue, and finally the data queue.
I didn't find the explicitly bundling order description in spec for
other ERROR chunks,
but it's reasonable to do this.
Anyway, I'll wait for your final solution.
Thanks,
Xufeng Zhang
>
> BTW, the patch below doesn't include the code to queue the error chunk
> onto the new error queue.
>
> -vlad
>
>> Thanks,
>> Xufeng Zhang
>>
>> ---
>> include/net/sctp/command.h | 1 +
>> include/net/sctp/structs.h | 3 +++
>> net/sctp/outqueue.c | 7 +++++++
>> net/sctp/sm_sideeffect.c | 16 ++++++++++++++++
>> net/sctp/sm_statefuns.c | 17 ++++++++++++++---
>> 5 files changed, 41 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
>> index 712b3be..62c34f5 100644
>> --- a/include/net/sctp/command.h
>> +++ b/include/net/sctp/command.h
>> @@ -110,6 +110,7 @@ typedef enum {
>> SCTP_CMD_SEND_NEXT_ASCONF, /* Send the next ASCONF after ACK */
>> SCTP_CMD_PURGE_ASCONF_QUEUE, /* Purge all asconf queues.*/
>> SCTP_CMD_SET_ASOC, /* Restore association context */
>> + SCTP_CMD_GEN_BAD_STREAM, /* Invalid Stream errors happened
>> command */
>> SCTP_CMD_LAST
>> } sctp_verb_t;
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index fc5e600..3d218e0 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -1183,6 +1183,9 @@ struct sctp_outq {
>> */
>> struct list_head abandoned;
>>
>> + /* Put Invalid Stream error chunks on this list */
>> + struct list_head bad_stream_err;
>> +
>> /* How many unackd bytes do we have in-flight? */
>> __u32 outstanding_bytes;
>>
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index e7aa177..1e87b0b 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -211,6 +211,7 @@ void sctp_outq_init(struct sctp_association *asoc,
>> struct sctp_outq *q)
>> INIT_LIST_HEAD(&q->retransmit);
>> INIT_LIST_HEAD(&q->sacked);
>> INIT_LIST_HEAD(&q->abandoned);
>> + INIT_LIST_HEAD(&q->bad_stream_err);
>>
>> q->fast_rtx = 0;
>> q->outstanding_bytes = 0;
>> @@ -283,6 +284,12 @@ void sctp_outq_teardown(struct sctp_outq *q)
>> list_del_init(&chunk->list);
>> sctp_chunk_free(chunk);
>> }
>> +
>> + /* Throw away any pending Invalid Stream error chunks */
>> + list_for_each_entry_safe(chunk, tmp,&q->bad_stream_err, list) {
>> + list_del_init(&chunk->list);
>> + sctp_chunk_free(chunk);
>> + }
>> }
>>
>> /* Free the outqueue structure and any related pending chunks. */
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fe99628..4698593 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -1060,6 +1060,18 @@ static void sctp_cmd_send_asconf(struct
>> sctp_association *asoc)
>> }
>> }
>>
>> +static void sctp_cmd_make_inv_stream_err(sctp_cmd_seq_t *commands,
>> + struct sctp_association *asoc)
>> +{
>> + struct sctp_chunk *err, *tmp;
>> + struct sctp_outq *q =&asoc->outqueue;
>> +
>> + list_for_each_entry_safe(err, tmp,&q->bad_stream_err, list) {
>> + list_del_init(&err->list);
>> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> + SCTP_CHUNK(err));
>> + }
>> +}
>>
>> /* These three macros allow us to pull the debugging code out of the
>> * main flow of sctp_do_sm() to keep attention focused on the real
>> @@ -1724,6 +1736,10 @@ static int sctp_cmd_interpreter(sctp_event_t
>> event_type,
>> asoc = cmd->obj.asoc;
>> break;
>>
>> + case SCTP_CMD_GEN_BAD_STREAM:
>> + sctp_cmd_make_inv_stream_err(commands, asoc);
>> + break;
>> +
>> default:
>> pr_warn("Impossible command: %u, %p\n",
>> cmd->verb, cmd->obj.ptr);
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index 9fca103..1c1bcd9 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -2967,8 +2967,14 @@ discard_force:
>> return SCTP_DISPOSITION_DISCARD;
>>
>> discard_noforce:
>> - if (chunk->end_of_packet)
>> + if (chunk->end_of_packet) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, force);
>> + /* Queue the INVALID STREAM error after the SACK if one
>> is needed. */
>> + if (!list_empty(&q->bad_stream_err))
>> + sctp_add_cmd_sf(commands,
>> SCTP_CMD_GEN_BAD_STREAM,
>> + SCTP_NULL());
>> + }
>>
>> return SCTP_DISPOSITION_DISCARD;
>> consume:
>> @@ -3037,11 +3043,16 @@ sctp_disposition_t
>> sctp_sf_eat_data_fast_4_4(const struct sctp_endpoint *ep,
>> * with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown
>> timer
>> */
>> if (chunk->end_of_packet) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> /* We must delay the chunk creation since the
>> cumulative
>> * TSN has not been updated yet.
>> */
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SHUTDOWN,
>> SCTP_NULL());
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK,
>> SCTP_FORCE());
>> + /* Queue the INVALID STREAM error after the SACK if one
>> is needed. */
>> + if (!list_empty(&q->bad_stream_err))
>> + sctp_add_cmd_sf(commands,
>> SCTP_CMD_GEN_BAD_STREAM,
>> + SCTP_NULL());
>> sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
>>
>> SCTP_TO(SCTP_EVENT_TIMEOUT_T2_SHUTDOWN));
>> }
>> @@ -6136,6 +6147,7 @@ static int sctp_eat_data(const struct
>> sctp_association *asoc,
>> */
>> sid = ntohs(data_hdr->stream);
>> if (sid>= asoc->c.sinit_max_instreams) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> /* Mark tsn as received even though we drop it */
>> sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN,
>> SCTP_U32(tsn));
>>
>> @@ -6144,8 +6156,7 @@ static int sctp_eat_data(const struct
>> sctp_association *asoc,
>> sizeof(data_hdr->stream),
>> sizeof(u16));
>> if (err)
>> - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> - SCTP_CHUNK(err));
>> + list_add_tail(&err->list,&q->bad_stream_err);
>> return SCTP_IERROR_BAD_STREAM;
>> }
>>
>
>
^ permalink raw reply
* ..656...565..265...356..
From: sodduuve @ 2012-08-03 0:14 UTC (permalink / raw)
To: yuexianana
负责人您好：
我公司有（国—地）税/票据代开，如有这方面的需
要请联系。若有打扰，请多包涵）谢谢。
联系人：王经理
手 机：13538292585
Q Q:1060046785
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-02 23:37 UTC (permalink / raw)
To: ebiederm; +Cc: eric.dumazet, xemul, netdev
In-Reply-To: <87wr1h35zg.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 02 Aug 2012 04:09:39 -0700
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>> If ifindex are per network space, I guess we'll need to change
>> arp_hashfn() or else we'll use some slots more than others.
>
> Darn. I hate being right about there being a few places to fix
> up.
>
> ndisc_hashfn also has the same limitation.
And netlabel's inteface hashing as well.
LLC works with ifindex hashing and is not namespace aware. It's
should therefore limited to &init_net and therefore OK. Likewise
for the CAN code.
^ permalink raw reply
* Re: discussion questions: SR-IOV, virtualization, and bonding
From: Jay Vosburgh @ 2012-08-02 23:36 UTC (permalink / raw)
To: Chris Friesen; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501B0A10.8030703@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>On 08/02/2012 05:01 PM, Jay Vosburgh wrote:
>> Chris Friesen<chris.friesen@genband.com> wrote:
>
>> Still, though, isn't "influence the guest's choice" pretty much
>> satisified by having the VF interface go carrier down in the guest when
>> the host wants it to? Or are you thinking about more fine grained than
>> that?
>
>That was the first thing we started looking at.
>
>It would actually be better technically (since it would use the
>back-channel between PF and VFs rather than needing an explicit virtual
>network link between host/guest) but it would require work in all the
>PF/VF drivers. We'd need to get support from all the driver maintainers.
It might also be better (for a different definition of "better")
to use the virtual network link and do more functionality in a generic
user space piece that's not in the kernel and wouldn't require special
driver support. Either way, I imagine there's going to have to be some
sort of message passing going on.
>The main advantage of doing it in bonding is that we'd only need to modify
>the code in one place.
As long as it works with VLANs bonded together; that seems to be
more common these days.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-02 23:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343903310.9299.184.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Aug 2012 12:28:30 +0200
> Strange because I see no false sharing on this ifindex location for
> loopback device.
Are you sure netdev->rx_dropped isn't being incremented? That appears
as if it would land on the same cache line as netdev->ifindex.
^ permalink raw reply
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: David Miller @ 2012-08-02 23:21 UTC (permalink / raw)
To: fengguang.wu
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120802110543.GA21745@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Thu, 2 Aug 2012 19:05:43 +0800
> Fix a buffer overflow bug by removing the revision transform code.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
The reason the "$Revision ..." prefix is there is so that automated
version control tools will change the string automatically when code
is committed in CVS.
In the GIT era this revision style is obsolete.
Therefore you might as well just delete this crap altogether.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: David Miller @ 2012-08-02 23:20 UTC (permalink / raw)
To: mypopydev; +Cc: kuznet, jmorris, yoshfuji, netdev
In-Reply-To: <1343912455-4444-1-git-send-email-mypopydev@gmail.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Thu, 2 Aug 2012 21:00:55 +0800
> Current kernel change the skb's net device with output device before netfilter FORWARD chain,
> that will lead to can't match the IPv6 multicast packets with input net device in netfilter
> FORWARD chain.
>
> the test case for reproduce this issue as follow:
>
> IPv6 multicast udp stream from eth0(input device) to eth1(output device)
Your change means we now can't match on the VIF device in this situation.
I'm not applying this patch, it breaks as much as it fixes.
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: Chris Friesen @ 2012-08-02 23:15 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <20421.1343948491@death.nxdomain>
On 08/02/2012 05:01 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@genband.com> wrote:
> Still, though, isn't "influence the guest's choice" pretty much
> satisified by having the VF interface go carrier down in the guest when
> the host wants it to? Or are you thinking about more fine grained than
> that?
That was the first thing we started looking at.
It would actually be better technically (since it would use the
back-channel between PF and VFs rather than needing an explicit virtual
network link between host/guest) but it would require work in all the
PF/VF drivers. We'd need to get support from all the driver maintainers.
The main advantage of doing it in bonding is that we'd only need to
modify the code in one place.
Chris
^ permalink raw reply
* Re: [PATCH 0/4] net/mlx4: Fixes to mlx4 driver
From: David Miller @ 2012-08-02 23:12 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343921456-19180-1-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Thu, 2 Aug 2012 18:30:52 +0300
> Yevgeny Petrilin (3):
> net/mlx4_en: Setting the NETIF_F_GRO flag back to dev->hw_features
As pointed out, this isn't a bug.
You just made this change purely via code inspection, and that's very
disappointing because this would have been so simple to validate.
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Eric W. Biederman @ 2012-08-02 23:03 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017F96B.1060701@free.fr>
Bernard Pidoux <bernard.pidoux@free.fr> writes:
> Here is a complementary observation.
> Trying to remove rose module with rmmod rose did not create any kernel panic.
> However, there is an endless message from the kernel saying :
>
> Message from syslogd@raspberrypi at Jul 31 17:22:40 ...
> kernel:[ 831.579007] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
>
> Message from syslogd@raspberrypi at Jul 31 17:22:50 ...
> kernel:[ 841.739390] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
>
> Message from syslogd@raspberrypi at Jul 31 17:23:00 ...
> kernel:[ 851.899758] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
> .....
>
> As observed at many occasions, count number seems to be random ! and
> the same message keeps going without any change of count number.
> At the same time, there is no possibility to recover the command line on any
> console.
> However I could loggin via ssh and I noticed that rose0 device is actually no
> more in the ifconfig list.
>
> If I try to remove rose with rmmod rose I get :
>
> root@raspberrypi:/home/pi# rmmod rose
> libkmod: ERROR ../libkmod/libkmod-module.c:753 kmod_module_remove_module: could
> not remove 'rose': Device or resource busy
> Error: could not remove module rose: Device or resource busy
>
>
> Does this help ?
Something presumably in the rose code is leaking a reference to the rose
device. That is probably a separate bug than your other one, but it may
be related. These are some of my least favorite bugs to track down.
That said in rose there is only one call to dev_hold and only one call
to dev_put.
Hmm. Looking at it dev_hold happens in rose_dev_get, and of which there
are several callers and only one of those callers calls dev_put. So
it should just be a matter of adding some more dev_put calls in the
appropriate places.
The usage in rose_loopback_timer looks easy to fix, the usage in
rose_bind seems more of a challenge.
Are you enough of a developer to take that observation and look at
the code and fix it?
Eric
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: Jay Vosburgh @ 2012-08-02 23:01 UTC (permalink / raw)
To: Chris Friesen; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501B0037.1010804@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>On 08/02/2012 04:26 PM, Chris Friesen wrote:
>> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>
>>> The best long term solution is to have a user space API that
>>> provides link state input to bonding on a per-slave basis, and then some
>>> user space entity can perform whatever link monitoring method is
>>> appropriate (e.g., LLDP) and pass the results to bonding.
>>
>> I think this has potential. This requires a virtual communication
>> channel between guest/host if we want the host to be able to influence
>> the guest's choice of active link, but I think that's not unreasonable.
Not necessarily, if something like LLDP runs across the virtual
link between the guest and slave, then the guest will notice when the
link goes down (although perhaps not very quickly). I'm pretty sure the
infrastructure to make LLDP work on inactive slaves is already there; as
I recall, the "no wildcard" or "deliver exact" business in the receive
path is at least partially for LLDP.
Still, though, isn't "influence the guest's choice" pretty much
satisified by having the VF interface go carrier down in the guest when
the host wants it to? Or are you thinking about more fine grained than
that?
>> Actually, couldn't we do this now? Turn off miimon and arpmon, then just
>> have the userspace thing write to /sys/class/net/bondX/bonding/active_slave
That might work for active-backup mode, yes, although it may not
handle the case when all slaves have failed if "failed" does not include
the slave being carrier down. It's not quite the same thing as input to
the link monitoring logic.
>Hmm...looks like the bonding code requires either miimon or arpmon. I
>wonder if setting miimon to INT_MAX might work, at least for some bonding
>modes.
Not true; it's legal to leave miimon and arp_interval set to 0.
Older versions of bonding will whine about it, but let you do it; in
mainline, it's a debug message you have to choose to turn on (because
current versions of initscripts, et al, create the bond first, and then
set those options, so it tended to whine all the time).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Eric W. Biederman @ 2012-08-02 22:55 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
Bernard Pidoux <bernard.pidoux@free.fr> writes:
> Hi,
>
> I observe systematically a kernel panic when I try to shutdown rose0 device
> using ifconfig rose0 down
>
> This is happening on two very different ROSE implementation, one is on a machine
> with x86-64 kernel 4.6.3 on an Intel core 2 duo CPU
> the other is on a RaspBerry Pi with Raspbian and 3.1.9+ wheezy kernel
> recompiled with AX.25 modules (ax25, rose, netrom, 6pack, kiss) enabled.
>
> Here is an image of the screen dump :
>
> http://f6bvp.org/photos/rose_device_event.JPG
For some reason I can not connect f6bvp.org.
> It can be noticed that PC is at rose_device_event and
> LR is at sock_def_wakeup
>
> One thing to be noticed is that when I close before all ROSE and AX.25
> applications, there are still a few populated sockets, probably for one of the
> program did not close the sockets properly.
>
> I that case, does rose module should accept to shutdown rose0 device ?
> However, I guess that it should not create a kernel panic due to a kernel NULL
> pointer.
No. The kernel should not panic.
> I don't know what to do in order to debug that issue.
I assume that rose is interesting to you and you would like for it to
work better?
In general you can read the code and figure out what it is doing ref
counting wise. It doesn't look like anyone has done much with the rose
code for years except very basic maintenance across the kernel. It
scares me to know that I was the last one to touch the rose code.
Part of what is happening at the time of the panic is
unregister_netdevice_notifier now generates synthetic removal for all of
the network devices in the system to remove the need for a special path
to handle network device removal in modules.
Unfortunately it looks like one of those modules is a problem.
You might want to simply try moving unregister_netdevice_notifier a bit
earlier in rose_exit and see if that helps. Otherwise I would recommend
instrumenting the code up with some printk so you can understand what
part of unregistration is failing.
Eric
^ 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