* Re: [PATCH -next] net: NET_DSA depends on NET_ETHERNET
From: David Miller @ 2010-07-21 0:45 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, linux-next, linux-kernel, buytenh
In-Reply-To: <4C462B44.5010107@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 20 Jul 2010 16:03:32 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> NET_DSA code selects and uses PHYLIB code, but PHYLIB depends on
> NET_ETHERNET. However, "select" does not follow kconfig dependencies,
> so explicitly list that requirement here instead.
>
> Fixes this kconfig warning:
>
> warning: (NET_DSA && NET && EXPERIMENTAL && !S390 ...) selects PHYLIB which has unmet direct dependencies (!S390 && NET_ETHERNET)
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Randy, this has been fixed in net-2.6 for some time now.
And I'm pretty sure I sent a copy of this to you when I
checked it in :-)
--------------------
>From 336a283b9cbe47748ccd68fd8c5158f67cee644b Mon Sep 17 00:00:00 2001
From: David S. Miller <davem@davemloft.net>
Date: Mon, 12 Jul 2010 20:03:42 -0700
Subject: [PATCH 09/24] dsa: Fix Kconfig dependencies.
Based upon a report by Randy Dunlap.
DSA needs PHYLIB, but PHYLIB needs NET_ETHERNET. So, in order
to select PHYLIB we have to make DSA depend upon NET_ETHERNET.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/dsa/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index c51b554..1120178 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -1,7 +1,7 @@
menuconfig NET_DSA
bool "Distributed Switch Architecture support"
default n
- depends on EXPERIMENTAL && !S390
+ depends on EXPERIMENTAL && NET_ETHERNET && !S390
select PHYLIB
---help---
This allows you to use hardware switch chips that use
--
1.7.1.1
^ permalink raw reply related
* Re: [patch v2.2 1/4] [PATCH v2.1 1/4] netfilter: xt_ipvs (netfilter matcher for IPVS)
From: Simon Horman @ 2010-07-20 23:34 UTC (permalink / raw)
To: Hannes Eder
Cc: Patrick McHardy, lvs-devel, netdev, linux-kernel, netfilter,
Wensong Zhang, Julius Volz, David S. Miller,
Netfilter Development Mailinglist
In-Reply-To: <AANLkTimUEJGAJ6tsPKGltUGBwrdotK5YyKBIkQWbA8qZ@mail.gmail.com>
On Tue, Jul 20, 2010 at 02:44:11PM +0200, Hannes Eder wrote:
> Hi Simon,
>
> On Tue, Jun 22, 2010 at 09:13, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, May 03, 2010 at 01:29:46PM +0200, Hannes Eder wrote:
> >> Thank you for picking this series of patches up again and thanks for
> >> the feedback.
> >>
> >> I'll send an updated version in the next days.
> >
> > Hi Hanes,
> >
> > more than a few days seems to have passed.
> > Do you have time to fix the patches up?
> > If not, I'll take a stab at it.
>
> /me working through the backlog of emails after vacation, however this
> email was buried in my inbox before my vacation, my bad. I've been
> extremely busy lately and I did not have the time to work on the
> patches. I saw your updated versions, I appreciate very much that you
> are taking it from there.
No problem, I assumed that you were busy with something.
^ permalink raw reply
* [PATCH -next] net: NET_DSA depends on NET_ETHERNET
From: Randy Dunlap @ 2010-07-20 23:03 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, Lennert Buytenhek
In-Reply-To: <20100710.190954.245403400.davem@davemloft.net>
From: Randy Dunlap <randy.dunlap@oracle.com>
NET_DSA code selects and uses PHYLIB code, but PHYLIB depends on
NET_ETHERNET. However, "select" does not follow kconfig dependencies,
so explicitly list that requirement here instead.
Fixes this kconfig warning:
warning: (NET_DSA && NET && EXPERIMENTAL && !S390 ...) selects PHYLIB which has unmet direct dependencies (!S390 && NET_ETHERNET)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
---
net/dsa/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Is there some reason that NET_DSA is bool instead of tristate?
I.e., net/dsa/ code cannot be built as loadable modules?
--- linux-next-20100713.orig/net/dsa/Kconfig
+++ linux-next-20100713/net/dsa/Kconfig
@@ -1,7 +1,7 @@
menuconfig NET_DSA
bool "Distributed Switch Architecture support"
default n
- depends on EXPERIMENTAL && !S390
+ depends on EXPERIMENTAL && !S390 && NET_ETHERNET
select PHYLIB
---help---
This allows you to use hardware switch chips that use
^ permalink raw reply
* Re: [BUG net-next-2.6] vlan, bonding, bnx2 problems
From: Jay Vosburgh @ 2010-07-20 22:58 UTC (permalink / raw)
Cc: Michael Chan, Eric Dumazet, David Miller,
pedro.netdev@dondevamos.com, netdev@vger.kernel.org,
kaber@trash.net, bhutchings@solarflare.com
In-Reply-To: <25515.1279570766@death>
Jay Vosburgh <fubar@us.ibm.com> wrote:
>Michael Chan <mchan@broadcom.com> wrote:
>
>>Adding Jay to CC.
>>
>>On Mon, 2010-07-19 at 06:24 -0700, Eric Dumazet wrote:
>>> [ 32.046479] BUG: scheduling while atomic: ifenslave/4586/0x00000100
>>> [ 32.046540] Modules linked in: ipmi_si ipmi_msghandler hpilo
>>> bonding ipv6
>>> [ 32.046784] Pid: 4586, comm: ifenslave Tainted: G W
>>> 2.6.35-rc1-01453-g3e12451-dirty #836
>>> [ 32.046860] Call Trace:
>>> [ 32.046910] [<c13421c4>] ? printk+0x18/0x1c
>>> [ 32.046965] [<c10315c9>] __schedule_bug+0x59/0x60
>>> [ 32.047019] [<c1342a2c>] schedule+0x57c/0x850
>>> [ 32.047074] [<c104a106>] ? lock_timer_base+0x26/0x50
>>> [ 32.047128] [<c1342f78>] schedule_timeout+0x118/0x250
>>> [ 32.047183] [<c104a2c0>] ? process_timeout+0x0/0x10
>>> [ 32.047238] [<c13430c5>] schedule_timeout_uninterruptible
>>> +0x15/0x20
>>> [ 32.047295] [<c104a345>] msleep+0x15/0x20
>>> [ 32.047350] [<c1227082>] bnx2_napi_disable+0x52/0x80
>>> [ 32.047405] [<c122b56f>] bnx2_netif_stop+0x3f/0xa0
>>> [ 32.047460] [<c122b62a>] bnx2_vlan_rx_register+0x5a/0x80
>>> [ 32.047516] [<f8ced776>] bond_enslave+0x526/0xa90 [bonding]
>>> [ 32.047576] [<f8b8f0d0>] ? fib6_clean_node+0x0/0xb0 [ipv6]
>>> [ 32.047634] [<f8b8dda0>] ? fib6_age+0x0/0x90 [ipv6]
>>> [ 32.047689] [<c129d2d3>] ? netdev_set_master+0x3/0xc0
>>> [ 32.047746] [<f8cee4cb>] bond_do_ioctl+0x31b/0x430 [bonding]
>>> [ 32.047804] [<c105b19a>] ? raw_notifier_call_chain+0x1a/0x20
>>> [ 32.047861] [<c12abd5d>] ? __rtnl_unlock+0xd/0x10
>>> [ 32.047915] [<c129f8cd>] ? __dev_get_by_name+0x7d/0xa0
>>> [ 32.047970] [<c12a19b0>] dev_ifsioc+0xf0/0x290
>>> [ 32.048025] [<f8cee1b0>] ? bond_do_ioctl+0x0/0x430 [bonding]
>>> [ 32.048081] [<c12a1ce1>] dev_ioctl+0x191/0x610
>>> [ 32.048136] [<c12eeb20>] ? udp_ioctl+0x0/0x70
>>> [ 32.048189] [<c128f67c>] sock_ioctl+0x6c/0x240
>>> [ 32.048243] [<c10d3a44>] vfs_ioctl+0x34/0xa0
>>> [ 32.048297] [<c10c7cab>] ? alloc_file+0x1b/0xa0
>>> [ 32.048351] [<c128f610>] ? sock_ioctl+0x0/0x240
>>> [ 32.048404] [<c10d4186>] do_vfs_ioctl+0x66/0x550
>>> [ 32.048459] [<c1022ca0>] ? do_page_fault+0x0/0x350
>>> [ 32.048513] [<c1022e41>] ? do_page_fault+0x1a1/0x350
>>> [ 32.048568] [<c129098c>] ? sys_socket+0x5c/0x70
>>> [ 32.048622] [<c1291860>] ? sys_socketcall+0x60/0x270
>>> [ 32.048677] [<c10d46a9>] sys_ioctl+0x39/0x60
>>> [ 32.048730] [<c1002bd0>] sysenter_do_call+0x12/0x26
>>> [ 32.052025] bonding: bond0: enslaving eth1 as a backup interface
>>> with a down link.
>>> [ 32.100207] tg3 0000:14:04.0: PME# enabled
>>> [ 32.100222] pci0000:00: wake-up capability enabled by ACPI
>>> [ 32.224488] pci0000:00: wake-up capability disabled by ACPI
>>> [ 32.224492] tg3 0000:14:04.0: PME# disabled
>>> [ 32.348516] tg3 0000:14:04.0: BAR 0: set to [mem
>>> 0xfdff0000-0xfdffffff 64bit] (PCI address [0xfdff0000-0xfdffffff]
>>> [ 32.348524] tg3 0000:14:04.0: BAR 2: set to [mem
>>> 0xfdfe0000-0xfdfeffff 64bit] (PCI address [0xfdfe0000-0xfdfeffff]
>>> [ 32.363711] bonding: bond0: enslaving eth2 as a backup interface
>>> with a down link.
>>>
>>>
>>>
>>> For bnx2, it seems commit 212f9934afccf9c9739921
>>> was not sufficient to correct the "scheduling while atomic" bug...
>>> enslaving a bnx2 on a bond device with one vlan already set :
>>> bond_enslave -> bnx2_vlan_rx_register -> bnx2_netif_stop ->
>>> bnx2_napi_disable -> msleep()
>>>
>>
>>There are a number of drivers that call napi_disable() during
>>->ndo_vlan_rx_regsiter(). bnx2 is lockless in the rx path and so we
>>need to disable NAPI rx processing and wait for it to be done before
>>modifying the vlgrp.
>>
>>Jay, is there an alternative to holding the bond->lock when calling the
>>slave's ->ndo_vlan_rx_register()?
>
> I believe so. The lock is held here nominally to mutex
>bonding's vlan_list. The bond_add_vlans_on_slave function actually does
>the lock and call to ndo_vlan_rx_register (plus one add_vid call per
>configured VLAN); I think the call frame in the above stack has been
>optimized out.
>
> For the specific cases of bond_add_vlans_on_slave and
>bond_del_vlans_from_slave, we should be able to get away without holding
>the bond->lock because we also hold RTNL, and it looks like all changes
>to the vlan_list are implicitly mutexed by RTNL because all VLAN add /
>remove for device or vid end up being done under RTNL.
>
> The cases within bonding that change the vlan_list will still
>have to hold bond->lock, because other call sites within bonding check
>the vlan_list without RTNL (and it would be impractical to have them do
>so).
>
> The patch is as follows; I'm compiling this now to test. If it
>pans out, I'll post a formal submission in a bit.
Just an update; the "VLAN 0" patch:
commit ad1afb00393915a51c21b1ae8704562bf036855f
Author: Pedro Garcia <pedro.netdev@dondevamos.com>
Date: Sun Jul 18 15:38:44 2010 -0700
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
has broken a bunch of VLAN-related things in bonding (more than
just the ipv6 event thing that was already fixed). Now, 8021q will do
an "add_vid" for VLAN 0 without doing a vlan_rx_register and supplying a
struct vlan_group; this confuses the existing bonding code, which
assumes that register comes first.
I'm working out the best way to fix the VLAN breakage before I
can test the below patch (which may have to change).
-J
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 8228088..decddf5 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -565,10 +565,8 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
> struct vlan_entry *vlan;
> const struct net_device_ops *slave_ops = slave_dev->netdev_ops;
>
>- write_lock_bh(&bond->lock);
>-
> if (list_empty(&bond->vlan_list))
>- goto out;
>+ return;
>
> if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
> slave_ops->ndo_vlan_rx_register)
>@@ -576,13 +574,10 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
>
> if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
> !(slave_ops->ndo_vlan_rx_add_vid))
>- goto out;
>+ return;
>
> list_for_each_entry(vlan, &bond->vlan_list, vlan_list)
> slave_ops->ndo_vlan_rx_add_vid(slave_dev, vlan->vlan_id);
>-
>-out:
>- write_unlock_bh(&bond->lock);
> }
>
> static void bond_del_vlans_from_slave(struct bonding *bond,
>@@ -592,10 +587,8 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
> struct vlan_entry *vlan;
> struct net_device *vlan_dev;
>
>- write_lock_bh(&bond->lock);
>-
> if (list_empty(&bond->vlan_list))
>- goto out;
>+ return;
>
> if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
> !(slave_ops->ndo_vlan_rx_kill_vid))
>@@ -614,9 +607,6 @@ unreg:
> if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
> slave_ops->ndo_vlan_rx_register)
> slave_ops->ndo_vlan_rx_register(slave_dev, NULL);
>-
>-out:
>- write_unlock_bh(&bond->lock);
> }
>
> /*------------------------------- Link status -------------------------------*/
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [patch 1/3] drivers/net/cxgb3/t3_hw.c: use new hex_to_bin() method
From: akpm @ 2010-07-20 22:25 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, ext-andriy.shevchenko, divy
From: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Get rid of own implementation of hex_to_bin().
Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Acked-by: Divy Le Ray <divy@chelsio.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/cxgb3/t3_hw.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff -puN drivers/net/cxgb3/t3_hw.c~drivers-net-cxgb3-t3_hwc-use-new-hex_to_bin-method drivers/net/cxgb3/t3_hw.c
--- a/drivers/net/cxgb3/t3_hw.c~drivers-net-cxgb3-t3_hwc-use-new-hex_to_bin-method
+++ a/drivers/net/cxgb3/t3_hw.c
@@ -679,14 +679,6 @@ int t3_seeprom_wp(struct adapter *adapte
return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ? 0xc : 0);
}
-/*
- * Convert a character holding a hex digit to a number.
- */
-static unsigned int hex2int(unsigned char c)
-{
- return isdigit(c) ? c - '0' : toupper(c) - 'A' + 10;
-}
-
/**
* get_vpd_params - read VPD parameters from VPD EEPROM
* @adapter: adapter to read
@@ -727,15 +719,15 @@ static int get_vpd_params(struct adapter
p->port_type[0] = uses_xaui(adapter) ? 1 : 2;
p->port_type[1] = uses_xaui(adapter) ? 6 : 2;
} else {
- p->port_type[0] = hex2int(vpd.port0_data[0]);
- p->port_type[1] = hex2int(vpd.port1_data[0]);
+ p->port_type[0] = hex_to_bin(vpd.port0_data[0]);
+ p->port_type[1] = hex_to_bin(vpd.port1_data[0]);
p->xauicfg[0] = simple_strtoul(vpd.xaui0cfg_data, NULL, 16);
p->xauicfg[1] = simple_strtoul(vpd.xaui1cfg_data, NULL, 16);
}
for (i = 0; i < 6; i++)
- p->eth_base[i] = hex2int(vpd.na_data[2 * i]) * 16 +
- hex2int(vpd.na_data[2 * i + 1]);
+ p->eth_base[i] = hex_to_bin(vpd.na_data[2 * i]) * 16 +
+ hex_to_bin(vpd.na_data[2 * i + 1]);
return 0;
}
_
^ permalink raw reply
* [patch 2/3] arch/um/drivers: remove duplicate structure field initialization
From: akpm @ 2010-07-20 22:25 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, julia, shemminger
From: Julia Lawall <julia@diku.dk>
There are two initializations of ndo_set_mac_address, one to a local
function that is not used otherwise and one to a function that is defined
elsewhere.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier I, s, fld;
position p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@s@
identifier I, s, r.fld;
position r.p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@script:python@
p0 << r.p0;
fld << r.fld;
ps << s.p;
pr << r.p;
@@
if int(ps[0].line)<int(pr[0].line) or int(ps[0].column)<int(pr[0].column):
cocci.print_main(fld,p0)
// </smpl>
akpm:
- Use the standard eth_mac_addr() in uml_net_set_mac()
- Remove unneeded and racy local set_ether_mac()
- Remove duplicated (and incorrect)
uml_netdev_ops.ndo_set_mac_address initializer.
Fixes 8bb95b39a16ed55226810596f92216c53329d2fe ("uml: convert network
device to netdevice ops").
[akpm@linux-foundation.org: rework as above]
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/um/drivers/net_kern.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff -puN arch/um/drivers/net_kern.c~arch-um-drivers-remove-duplicate-structure-field-initialization arch/um/drivers/net_kern.c
--- a/arch/um/drivers/net_kern.c~arch-um-drivers-remove-duplicate-structure-field-initialization
+++ a/arch/um/drivers/net_kern.c
@@ -25,11 +25,6 @@
#include "net_kern.h"
#include "net_user.h"
-static inline void set_ether_mac(struct net_device *dev, unsigned char *addr)
-{
- memcpy(dev->dev_addr, addr, ETH_ALEN);
-}
-
#define DRIVER_NAME "uml-netdev"
static DEFINE_SPINLOCK(opened_lock);
@@ -266,7 +261,7 @@ static int uml_net_set_mac(struct net_de
struct sockaddr *hwaddr = addr;
spin_lock_irq(&lp->lock);
- set_ether_mac(dev, hwaddr->sa_data);
+ eth_mac_addr(dev, hwaddr->sa_data);
spin_unlock_irq(&lp->lock);
return 0;
@@ -380,7 +375,6 @@ static const struct net_device_ops uml_n
.ndo_tx_timeout = uml_net_tx_timeout,
.ndo_set_mac_address = uml_net_set_mac,
.ndo_change_mtu = uml_net_change_mtu,
- .ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
@@ -478,7 +472,7 @@ static void eth_configure(int n, void *i
((*transport->user->init)(&lp->user, dev) != 0))
goto out_unregister;
- set_ether_mac(dev, device->mac);
+ eth_mac_addr(dev, device->mac);
dev->mtu = transport->user->mtu;
dev->netdev_ops = ¨_netdev_ops;
dev->ethtool_ops = ¨_net_ethtool_ops;
_
^ permalink raw reply
* [patch 3/3] drivers/net/82596.c: fix warning
From: akpm @ 2010-07-20 22:25 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, segooon
From: Andrew Morton <akpm@linux-foundation.org>
drivers/net/82596.c: In function 'i596_open':
drivers/net/82596.c:1044: warning: label 'err_irq_dev' defined but not used
Caused by "82596: free resources on error"
Cc: Kulikov Vasiliy <segooon@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/82596.c~drivers-net-82596c-fix-warning drivers/net/82596.c
--- a/drivers/net/82596.c~drivers-net-82596c-fix-warning
+++ a/drivers/net/82596.c
@@ -1040,8 +1040,8 @@ err_queue:
err_irq_56:
#ifdef ENABLE_MVME16x_NET
free_irq(0x56, dev);
-#endif
err_irq_dev:
+#endif
free_irq(dev->irq, dev);
return res;
_
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgbe: fix ethtool stats
From: Jeff Kirsher @ 2010-07-20 22:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Jesse Brandeburg, PJ Waskiewicz, netdev
In-Reply-To: <1279646906.2498.103.camel@edumazet-laptop>
On Tue, Jul 20, 2010 at 10:28, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Note : I am currently unable to test following patch, could you please
> Intel guys test it and Ack (or Nack) it ?
>
> Thanks !
>
> [PATCH net-next-2.6] ixgbe: fix ethtool stats
>
> In latest changes about 64bit stats on 32bit arches,
> [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
> I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
> definition.
>
> IXGBE_NETDEV_STAT() must now assume offsets relative to
> rtnl_link_stats64, not relative do dev->stats.
>
> As a bonus, we also get 64bit stats on ethtool -S
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/ixgbe/ixgbe_ethtool.c | 42 ++++++++++++++--------------
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
Thanks Eric, I have added it to my queue.
--
Cheers,
Jeff
^ permalink raw reply
* Re: net/dsa
From: Lennert Buytenhek @ 2010-07-20 21:54 UTC (permalink / raw)
To: Karl Beldan; +Cc: netdev
In-Reply-To: <AANLkTinBA3uqfML78PRr1-xN2ye_3Pjj-NQE5t7eHxGy@mail.gmail.com>
On Tue, Jul 20, 2010 at 11:28:19PM +0200, Karl Beldan wrote:
> >> I found the dsa code very handy to help manage a switch.
> >
> > Ah. What particular part are you using?
>
> The whole thing but the cascading stuff.
> I could even reuse a tagging format almost as is!
I meant, which silicon part, i.e. which hardware/chips? Anything with
available data sheets?
> >> Yet I was surprised I had to tweak the code to simply use the phy
> >> layer state machine.
> >
> > You mean that net/dsa uses phy_attach() but not phy_start_machine() ?
> > Have you seen problems arising from this?
>
> I did not mean that, but I do not think there would be a problem,
> since every in-tree driver provide their poll_link() to do the job of
> the phylib's state_queue, unless one does not provide its poll_link(),
> I guess this is what you had in mind.
> What I had in mind in fact was the re-use of the phylib's interrupt
> based code, in this situation poll_link() is not there, but there
> replacing phy_attach() with phy_start_machine is not enough.
We cannot rely on the switch's interrupt pin being hooked up -- there
are many boards out where it's not wired up at all. Therefore, polling
for link state changes is the only reliable and portable way.
(Of course, interrupt support can always be added, and that used
instead of polling if a load-time test shows that the interrupt pin
actually works.)
> Those are not big changes, but the code seems to aim at such versatile
> behavior (and more), I can only imagine it would be useful for the
> plethora of boards embedding a switch.
Although it supports Marvell chips only for now, net/dsa was written to
be able to handle other models of switch chips as well. As I said, I
would love to see support for other switch chips added to it.
> > > So I was wondering if there was anybody playing with this code, or
> > > having ideas about features to add (vlan/stp callbacks) ?
> >
> > As far as I know, the code currently in the kernel works well for what
> > it intends to do (which is to just expose the switch ports), and I'm
> > not aware of any bugs in it.
> >
> > That said, you're right in that there are several more features that
> > the hardware supports that the software could be extended to handle.
> >
> > For one, I don't have access to any Marvell switch chip hardware
> > anymore, so that limits my ability to play with this. Also, the
> > relevant documentation is under a rather restrictive license, so the
> > only way I can see net/dsa support for Marvell parts improving is if
> > there's pressure from a large enough customer to make this happen.
>
> Now I understand, but still, I am surprised nobody else touched the
> code, with all those switches in the embedded business.
Me too..
..then again, "embedded people" tend to hack up stuff in private
and ship whatever works -- they aren't exactly known for working with
upstream.
^ permalink raw reply
* Re: net/dsa
From: Karl Beldan @ 2010-07-20 21:28 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100720135950.GZ14513@mail.wantstofly.org>
On Tue, Jul 20, 2010 at 3:59 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Mon, Jul 12, 2010 at 10:59:29PM +0200, Karl Beldan wrote:
>
>> Hi,
>
> Hi Karl,
>
> Sorry, I didn't see your mail initially -- please CC me in the future.
>
>
>> I found the dsa code very handy to help manage a switch.
>
> Ah. What particular part are you using?
>
>
The whole thing but the cascading stuff.
I could even reuse a tagging format almost as is!
>> Yet I was surprised I had to tweak the code to simply use the phy
>> layer state machine.
>
> You mean that net/dsa uses phy_attach() but not phy_start_machine() ?
> Have you seen problems arising from this?
>
>
I did not mean that, but I do not think there would be a problem,
since every in-tree driver provide their poll_link() to do the job of
the phylib's state_queue, unless one does not provide its poll_link(),
I guess this is what you had in mind.
What I had in mind in fact was the re-use of the phylib's interrupt
based code, in this situation poll_link() is not there, but there
replacing phy_attach() with phy_start_machine is not enough.
Those are not big changes, but the code seems to aim at such versatile
behavior (and more), I can only imagine it would be useful for the
plethora of boards embedding a switch.
>> And I don't see much activity in the code nor any discussion, e.g no
>> follow up to http://patchwork.ozlabs.org/patch/16578.
>>
>> So I was wondering if there was anybody playing with this code, or
>> having ideas about features to add (vlan/stp callbacks) ?
>
> As far as I know, the code currently in the kernel works well for what
> it intends to do (which is to just expose the switch ports), and I'm
> not aware of any bugs in it.
>
> That said, you're right in that there are several more features that
> the hardware supports that the software could be extended to handle.
>
> For one, I don't have access to any Marvell switch chip hardware
> anymore, so that limits my ability to play with this. Also, the
> relevant documentation is under a rather restrictive license, so the
> only way I can see net/dsa support for Marvell parts improving is if
> there's pressure from a large enough customer to make this happen.
>
Now I understand, but still, I am surprised nobody else touched the
code, with all those switches in the embedded business.
> If this is about non-Marvell parts, I'd welcome adding support for
> those into net/dsa. For one, I would really like to see Broadcom
> switch chip support added -- the documentation for those chips is
> under similarly restrictive licensing, though.
>
>
Thanks,
Karl
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-20 21:20 UTC (permalink / raw)
To: shemminger
Cc: bhutchings, sassmann, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <20100720141816.16f0a939@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 20 Jul 2010 14:18:16 -0700
> No one mentioned that the first octet of an Ethernet address already
> indicates "software generated" Ethernet address. Per the standard,
> if bit 1 is set it means address is locally assigned.
>
> static inline bool is_locally_assigned_ether(const u8 *addr)
> {
> return (addr[0] & 0x2) != 0;
> }
W00t!
Indeed, can udev just use that? :-)
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-07-20 21:19 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Several really small fixes, as is customary this late in the -rc
series...
1) Three bluetooth fixes via Marcel Holtmann:
a) Fix L2CAP state machine race, from Andrei Emeltchenko
b) HCI conn security level must be reset after auth failure, from
Johan Hedberg.
c) Existng HCI connections need auth levels adjusted when
constrained by new connection settings. From Ville Tervo.
2) TX queue hash is set incorrectly in stacked device situations
because of how we early orphan the socket from the SKB these
days. Fix, by remembering sk->sk_hash in skb->rxhash and using
it later, from Eric Dumazet.
3) Neighbour ->cache_update header op is optional, check for NULL
was missing in neigh_update_hhs() leading to OOPS with GRE
tunnels. Fix from Doug Kehn.
4) RFS Socket sk->sk_tx_queue_mapping is read asynchronously from it's
setting. Therefore doing two reads (one to analyze it's validity,
a second to fetch the actual value) is racey. Do it on one read
to fix the problem. From Tom Herbert.
5) Don't do vhost-net flushes with mutex held, otherwise we deadlock
with workqueue. From Michael S. Tsirkin.
6) Guest triggerable condition results in pr_err() log, change to
pr_debug(). Also From Michael S. Tsirkin.
7) Multicast router code in ipv4 leaks SKB is fib lookup fails, fix
from Ben Greear.
8) Initialize workqueue earlier in rt2x00 wireless to avoid access to
uninitialized lock on probe failure. From Stephen Boyd.
9) Dangling hypervisor VIO interrupt can wedge ibmveth device on close.
Fix using explicit hypervisor call to disable it before the free.
From Robert Jennings.
10) Mobile ipv6 routing header code checks wrong address, should look at
ipv6 header address not the one in the routing header. From
Arnaud Ebalard.
11) There are circumstances, that which we do not %100 understand yet but
is proven by testing and experimentation, where we can call
tcp_xmit_retransmit_queue() when the send queue of the socket is empty.
If this happens, we deref a NULL skb trying to look at SACK information
of the head skb.
Just return immediately if ->packets_out is zero.
From Ilpo Järvinen.
12) Bridge netpoll support is buggy, but we were only able to fix the
problem with a series of non-trivial changes in net-next-2.6 which
are not appropriate this late in the -rc series. Just disable
netpoll support in bridging for 2.6.35, it'll be working fine in
2.6.36
13) Phone SKB leak fix from Rémi Denis-Courmont.
14) 8168dp ID fix in r8169 driver from Francois Romieu.
15) Packet scheduler NAT module requires all ICMPs to have an IP
header in their payload, this is not correct, only some ICMPs do.
Fix from Changli Gao based upon a patch and analysis by Rodrigo
Partearroyo González.
16) NET_DSA needs to depend upon NET_ETHERNET. Based upon a report by
Randy Dunlap.
17) Fix locking in the axnet_cs interrupt handler since it can be
invoked by the watchdog too. From Ken Kawasaki.
18) hostap driver must unconditionally set dev->base_addr during probe.
From John W. Linville.
19) Fix crash in xfrm bundle lookup, it assumed template resolution always
results in constructed xfrms. From Timo Teräs.
20) tcp_splice_read() doesn't hit sock_rps_record_flow() but it needs to.
From Changli Gao.
Please pull, thanks a lot!
The following changes since commit 2f7989efd4398d92b8adffce2e07dd043a0895fe:
Merge master.kernel.org:/home/rmk/linux-2.6-arm (2010-07-14 17:28:13 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: Check L2CAP pending status before sending connect request
Arnaud Ebalard (1):
IPv6: fix CoA check in RH2 input handler (mip6_rthdr_input())
Ben Greear (1):
ipmr: Don't leak memory if fib lookup fails.
Changli Gao (2):
act_nat: not all of the ICMP packets need an IP header payload
rfs: call sock_rps_record_flow() in tcp_splice_read()
David S. Miller (4):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
dsa: Fix Kconfig dependencies.
Merge branch 'vhost-net' of git://git.kernel.org/.../mst/vhost
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Doug Kehn (1):
net/core: neighbour update Oops
Eric Dumazet (1):
net: skb_tx_hash() fix relative to skb_orphan_try()
Francois Romieu (1):
r8169: incorrect identifier for a 8168dp
Herbert Xu (1):
bridge: Partially disable netpoll support
Ilpo Järvinen (1):
tcp: fix crash in tcp_xmit_retransmit_queue
Johan Hedberg (1):
Bluetooth: Reset the security level after an authentication failure
John W. Linville (1):
hostap_pci: set dev->base_addr during probe
Ken Kawasaki (1):
axnet_cs: use spin_lock_irqsave in ax_interrupt
Michael S. Tsirkin (2):
vhost-net: avoid flush under lock
vhost: avoid pr_err on condition guest can trigger
Rajkumar Manoharan (1):
ath9k_htc: fix memory leak in ath9k_hif_usb_alloc_urbs
Reinette Chatre (1):
iwlwifi: remove key information during device restart
Robert Jennings (1):
ibmveth: lost IRQ while closing/opening device leads to service loss
Rémi Denis-Courmont (1):
Phonet: fix skb leak in pipe endpoint accept()
Stephen Boyd (1):
rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
Timo Teräs (1):
xfrm: do not assume that template resolving always returns xfrms
Tom Herbert (1):
net: fix problem in reading sock TX queue
Ville Tervo (1):
Bluetooth: Update sec_level/auth_type for already existing connections
drivers/net/ibmveth.c | 4 +++-
drivers/net/pcmcia/axnet_cs.c | 7 ++++---
drivers/net/r8169.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 8 ++++++--
drivers/net/wireless/hostap/hostap_pci.c | 1 +
drivers/net/wireless/iwlwifi/iwl-sta.h | 11 +++++++++++
drivers/net/wireless/rt2x00/rt2x00dev.c | 10 +++++-----
drivers/vhost/net.c | 13 +++++++++----
include/net/sock.h | 7 +------
net/bluetooth/hci_conn.c | 5 +++++
net/bluetooth/hci_event.c | 2 ++
net/bluetooth/l2cap.c | 14 +++++++++++---
net/bridge/br_device.c | 9 ---------
net/bridge/br_forward.c | 23 +----------------------
net/core/dev.c | 20 +++++++++++++-------
net/core/neighbour.c | 5 ++++-
net/dsa/Kconfig | 2 +-
net/ipv4/ipmr.c | 8 ++++++--
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_output.c | 3 +++
net/ipv6/mip6.c | 3 ++-
net/phonet/pep.c | 1 +
net/sched/act_nat.c | 5 ++++-
net/xfrm/xfrm_policy.c | 15 +++++++++++++--
24 files changed, 108 insertions(+), 71 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Stephen Hemminger @ 2010-07-20 21:18 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, sassmann, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <20100720.131748.51255156.davem@davemloft.net>
On Tue, 20 Jul 2010 13:17:48 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 20 Jul 2010 15:29:54 +0100
>
> > On Tue, 2010-07-20 at 14:41 +0200, Stefan Assmann wrote:
> >> Btw, the driver itself could also alter the flag. Then we'd have a well
> >> defined way of setting a stable address.
> >
> > The driver can't know whether an address assigned by the user is stable.
>
> If userspace can somehow obtain a persistent address, it can kick
> udev too.
>
> I really don't see any real value provided by letting userspace mess
> with this. Because the permanence communicated in this value is from
> the perspective of the kernel driver, it's really therefore about the
> thing that's in ->perm_addr[] not what happens to be in ->addr[] right
> now.
No one mentioned that the first octet of an Ethernet address already
indicates "software generated" Ethernet address. Per the standard,
if bit 1 is set it means address is locally assigned.
static inline bool is_locally_assigned_ether(const u8 *addr)
{
return (addr[0] & 0x2) != 0;
}
^ permalink raw reply
* Re: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
From: Andrew Morton @ 2010-07-20 21:07 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Rafael J. Wysocki, mark gross, e1000-devel, netdev, linux-kernel,
James Bottomley, Thomas Gleixner, David S. Miller
In-Reply-To: <6182.1279658125@localhost>
On Tue, 20 Jul 2010 16:35:25 -0400
Valdis.Kletnieks@vt.edu wrote:
> On Mon, 19 Jul 2010 16:38:09 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Throws a warning at boot:
>
> [ 1.786060] WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x28/0x54()
> [ 1.786088] Hardware name: Latitude E6500
> [ 1.787045] pm_qos_update_request() called for unknown object
> [ 1.787966] Modules linked in:
> [ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
> [ 1.790035] Call Trace:
> [ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
> [ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
> [ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
> [ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
> [ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
> [ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
> [ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
> [ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
> [ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
> [ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
> [ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
> [ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
> [ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
> [ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
> [ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> [ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
> [ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
> [ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> [ 1.809958] ---[ end trace 84b562a00a60539e ]---
>
> Looks like a repeat of something I reported against -mmotm 2010-05-11, though a
> WARNING rather than an outright crash - the traceback is pretty much identical.
> I have *no* idea why -rc3-mmotm0701 doesn't whinge similarly.
>
I don't recall you reporting that, sorry.
The warning was added by
: commit 82f682514a5df89ffb3890627eebf0897b7a84ec
: Author: James Bottomley <James.Bottomley@suse.de>
: AuthorDate: Mon Jul 5 22:53:06 2010 +0200
: Commit: Rafael J. Wysocki <rjw@sisk.pl>
: CommitDate: Mon Jul 19 02:00:34 2010 +0200
:
: pm_qos: Get rid of the allocation in pm_qos_add_request()
It's a pretty crappy warning too. Neither the warning nor the code
comments provide developers with any hint as to what they have done
wrong, nor what they must do to fix things. And the patch changelog
doesn't mention the new warnings *at all*.
So one must assume that the people who stuck this thing in the tree
have volunteered to fix e1000e. Let's cc 'em.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
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: With disable_ipv6 set to 1 on an interface, ff00:/8 and fe80::/64 are still added on device UP
From: David Miller @ 2010-07-20 20:48 UTC (permalink / raw)
To: brian.haley; +Cc: maheshkelkar, netdev
In-Reply-To: <4C460856.5090701@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Tue, 20 Jul 2010 16:34:30 -0400
> I believe the easiest way to fix this is the following patch, can
> you please test it?
...
> If the interface has IPv6 disabled, don't add a multicast or
> link-local route since we won't be adding a link-local address.
>
> Reported-by: Mahesh Kelkar <maheshkelkar@gmail.com>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
This looks good to me, let me know when it has been tested.
^ permalink raw reply
* mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
From: Valdis.Kletnieks @ 2010-07-20 20:35 UTC (permalink / raw)
To: akpm, Thomas Gleixner, David S. Miller; +Cc: linux-kernel, e1000-devel, netdev
In-Reply-To: <201007200007.o6K07Xbg028863@imap1.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
On Mon, 19 Jul 2010 16:38:09 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Throws a warning at boot:
[ 1.786060] WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x28/0x54()
[ 1.786088] Hardware name: Latitude E6500
[ 1.787045] pm_qos_update_request() called for unknown object
[ 1.787966] Modules linked in:
[ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
[ 1.790035] Call Trace:
[ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
[ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
[ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
[ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
[ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
[ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
[ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
[ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
[ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
[ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
[ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
[ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
[ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
[ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
[ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
[ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
[ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
[ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
[ 1.809958] ---[ end trace 84b562a00a60539e ]---
Looks like a repeat of something I reported against -mmotm 2010-05-11, though a
WARNING rather than an outright crash - the traceback is pretty much identical.
I have *no* idea why -rc3-mmotm0701 doesn't whinge similarly.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: With disable_ipv6 set to 1 on an interface, ff00:/8 and fe80::/64 are still added on device UP
From: Brian Haley @ 2010-07-20 20:34 UTC (permalink / raw)
To: Mahesh Kelkar; +Cc: netdev@vger.kernel.org
In-Reply-To: <AANLkTinHkaL49MS9agf525GRhWXSWIvVmn-Qz33Hcg6Y@mail.gmail.com>
Hi Mahesh,
Cc-ing netdev...
On 07/20/2010 12:07 PM, Mahesh Kelkar wrote:
> Brian,
>
> I came across a patch that you submitted in 2009 (2009-05-29 20:48:49):
> IPv6: Add 'autoconf' and 'disable_ipv6' module parameters
>
> Question:
> With disable_ipv6 set to 1 on the interface, when device/interface
> reaches UP state, the link local address is not added, but ipv6 routes
> i.e. ff00::/8 & fe80::/64 routes are still added to the route table:
> In net/ipv6/addrconf.c
> addrconf_notify => addrconf_dev_config => addrconf_add_dev =>
> addrconf_add_mroute & addrconf_add_lroute
> The link local address is not assigned because of the check
> (idev->cnf.disable_ipv6) added in ipv6_add_addr.
>
> - Is there any particular reason for doing this? (i.e. not assigning
> the link local address to interface, but adding link local & mcast
> routes)
> - when disable_ipv6 is set to 1, is there any reason not to skip the
> NETDEV_UP processing in the addrconf_notify in addrconf.c
I believe the easiest way to fix this is the following patch, can
you please test it?
Thanks,
-Brian
---
If the interface has IPv6 disabled, don't add a multicast or
link-local route since we won't be adding a link-local address.
Reported-by: Mahesh Kelkar <maheshkelkar@gmail.com>
Signed-off-by: Brian Haley <brian.haley@hp.com>
---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e81155d..ab70a3f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1763,7 +1763,10 @@ static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
idev = ipv6_find_idev(dev);
if (!idev)
- return NULL;
+ return ERR_PTR(-ENOBUFS);
+
+ if (idev->cnf.disable_ipv6)
+ return ERR_PTR(-EACCES);
/* Add default multicast route */
addrconf_add_mroute(dev);
@@ -2132,8 +2135,9 @@ static int inet6_addr_add(struct net *net, int ifindex, struct in6_addr *pfx,
if (!dev)
return -ENODEV;
- if ((idev = addrconf_add_dev(dev)) == NULL)
- return -ENOBUFS;
+ idev = addrconf_add_dev(dev);
+ if (IS_ERR(idev))
+ return PTR_ERR(idev);
scope = ipv6_addr_scope(pfx);
@@ -2380,7 +2384,7 @@ static void addrconf_dev_config(struct net_device *dev)
}
idev = addrconf_add_dev(dev);
- if (idev == NULL)
+ if (IS_ERR(idev))
return;
memset(&addr, 0, sizeof(struct in6_addr));
@@ -2471,7 +2475,7 @@ static void addrconf_ip6_tnl_config(struct net_device *dev)
ASSERT_RTNL();
idev = addrconf_add_dev(dev);
- if (!idev) {
+ if (IS_ERR(idev)) {
printk(KERN_DEBUG "init ip6-ip6: add_dev failed\n");
return;
}
^ permalink raw reply related
* Re: [PATCH] __dst_free(): put EXPORT_SYMBOLS after the fct
From: David Miller @ 2010-07-20 20:28 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4C4571AA.5060107@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 20 Jul 2010 11:51:38 +0200
> this patch is just cosmetic: EXPORT_SYMBOLS(__dst_free) has been put
> after ___dst_free() function instead of __dst_free().
Applied.
^ permalink raw reply
* Re: [PATCH] drop_monitor: convert some kfree_skb call sites to consume_skb
From: David Miller @ 2010-07-20 20:28 UTC (permalink / raw)
To: nhorman; +Cc: netdev, viro, eparis
In-Reply-To: <20100720164556.GF1995@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 20 Jul 2010 12:45:56 -0400
> Convert a few calls from kfree_skb to consume_skb
>
> Noticed while I was working on dropwatch that I was detecting lots of internal
> skb drops in several places. While some are legitimate, several were not,
> freeing skbs that were at the end of their life, rather than being discarded due
> to an error. This patch converts those calls sites from using kfree_skb to
> consume_skb, which quiets the in-kernel drop_monitor code from detecting them as
> drops. Tested successfully by myself
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH] drop_monitor: Add error code to detect duplicate state changes
From: David Miller @ 2010-07-20 20:28 UTC (permalink / raw)
To: nhorman; +Cc: netdev
In-Reply-To: <20100720145209.GE1995@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 20 Jul 2010 10:52:09 -0400
> Hey-
> Patch to add -EAGAIN error to dropwatch netlink message handling code.
> -EAGAIN will be returned anytime userspace attempts to transition the state of
> the drop monitor service to a state that its already in. That allows user space
> to detect this condition, so it doesn't wait for a success ACK that will never
> arrive. Tested successfully by me
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sysfs: Don't allow the creation of symlinks we can't remove
From: Greg KH @ 2010-07-20 20:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, Eric W. Biederman, Rafael J. Wysocki, Maciej W. Rozycki,
Kay Sievers, Johannes Berg, netdev
In-Reply-To: <20100719133451.0862ca62.akpm@linux-foundation.org>
On Mon, Jul 19, 2010 at 01:34:51PM -0700, Andrew Morton wrote:
> On Thu, 8 Jul 2010 16:06:01 -0700
> Greg KH <greg@kroah.com> wrote:
>
> > On Thu, Jul 08, 2010 at 03:28:53PM -0700, Eric W. Biederman wrote:
> > > Greg KH <greg@kroah.com> writes:
> > >
> > > > With this patch, how does the existing code fail as the drivers aren't
> > > > fixed up?
> > > >
> > > > I like this change, just worried it will cause problems if it gets into
> > > > .35, without your RFC patch. Will it?
> > >
> > > It don't expect this patch to be worse than where we are current at.
> > > Network devices are renamed, and come and go enough that both the
> > > mac80211_hwsim and the bnep driver are currently unusable with a
> > > failure only the rename and remove.
> > >
> > > This patch simply moves the failure into creation where we are a little more
> > > prepared to deal with problems, and this patch is limited to mac80211_hwsim,
> > > bnep, and any hypothetically undiscovered other network devices that
> > > have the same problem.
> > >
> > > mac80211_hwsim with just this patch becomes somewhat usable as it's primary
> > > network device gets registered and the module can be loaded and unloaded. It
> > > just doesn't create the wlan0 and wlan1 interfaces for the wifi interfaces.
> >
> > Fair enough, I've commited it now, let's see what happens :)
>
> geethanks!
>
> On the FC6 test box I have no networking.
Ick.
Eric, any ideas?
^ permalink raw reply
* Re: [PATCH] phy: add suspend/resume in the ic+
From: David Miller @ 2010-07-20 20:24 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1279609954-30274-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Tue, 20 Jul 2010 09:12:34 +0200
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] cxgb4vf: Fix bug where we were only allocating one queue in MSI mode
From: David Miller @ 2010-07-20 20:23 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201007200859.30269.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 20 Jul 2010 08:59:30 -0700
>>From 7e141cafe989958267803791aa1bcacfffe5cfb2 Mon Sep 17 00:00:00 2001
> From: Casey Leedom <leedom@chelsio.com>
> Date: Mon, 19 Jul 2010 17:53:48 -0700
> Subject: [PATCH net-next 2/3] cxgb4vf: Fix bug where we were only allocating one queue in MSI mode
>
> Fix bug in setup_sge_queues() where we were incorrectly only allocating a
> single "Queue Set" for MSI mode.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/3] cxgb4vf: Fix off-by-one error checking for the end of the mailbox delay array
From: David Miller @ 2010-07-20 20:23 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201007200858.52364.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 20 Jul 2010 08:58:52 -0700
>>From 1d32860335fad8c67e23254aec7c30750276f2b4 Mon Sep 17 00:00:00 2001
> From: Casey Leedom <leedom@chelsio.com>
> Date: Mon, 19 Jul 2010 17:51:46 -0700
> Subject: [PATCH net-next 1/3] cxgb4vf: Fix off-by-one error checking for the end of the mailbox delay array
>
> Fix off-by-one error in checking for the end of the mailbox response delay
> array. We ended up walking off the end and, if we were unlucky, we'd end up
> pulling in a 0 and never terminate the mailbox response delay loop ...
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
From: David Miller @ 2010-07-20 20:23 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201007200859.57111.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 20 Jul 2010 08:59:56 -0700
>>From 7710873beb494b46333fdf9841b4a117bdb66a5a Mon Sep 17 00:00:00 2001
> From: Casey Leedom <leedom@chelsio.com>
> Date: Mon, 19 Jul 2010 17:55:33 -0700
> Subject: [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
>
> Adding myself as the official maintainer of the Chelsio T4 Virtual function
> Driver (cxgb4vf).
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied.
^ 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