* [patch net-next-2.6 3/3] net: remove ndo_set_multicast_list callback
From: Jiri Pirko @ 2011-08-16 16:29 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, eric.dumazet, kaber, yoshfuji, rdunlap, kuznet,
jmorris, mirqus, jesse
In-Reply-To: <1313512142-3355-1-git-send-email-jpirko@redhat.com>
Remove no longer used operation.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
Documentation/networking/netdevices.txt | 4 ++--
include/linux/netdevice.h | 4 ----
net/core/dev.c | 6 ++----
net/core/dev_addr_lists.c | 4 ++--
net/ipv4/igmp.c | 2 +-
5 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index 87b3d15..8935834 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -73,7 +73,7 @@ dev->hard_start_xmit:
has to lock by itself when needed. It is recommended to use a try lock
for this and return NETDEV_TX_LOCKED when the spin lock fails.
The locking there should also properly protect against
- set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
+ set_rx_mode. Note that the use of NETIF_F_LLTX is deprecated.
Don't use it for new drivers.
Context: Process with BHs disabled or BH (timer),
@@ -92,7 +92,7 @@ dev->tx_timeout:
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
-dev->set_multicast_list:
+dev->set_rx_mode:
Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 96e4f7e..125f9fb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -726,9 +726,6 @@ struct netdev_tc_txq {
* If driver handles unicast address filtering, it should set
* IFF_UNICAST_FLT to its priv_flags.
*
- * void (*ndo_set_multicast_list)(struct net_device *dev);
- * This function is called when the multicast address list changes.
- *
* int (*ndo_set_mac_address)(struct net_device *dev, void *addr);
* This function is called when the Media Access Control address
* needs to be changed. If this interface is not defined, the
@@ -870,7 +867,6 @@ struct net_device_ops {
void (*ndo_change_rx_flags)(struct net_device *dev,
int flags);
void (*ndo_set_rx_mode)(struct net_device *dev);
- void (*ndo_set_multicast_list)(struct net_device *dev);
int (*ndo_set_mac_address)(struct net_device *dev,
void *addr);
int (*ndo_validate_addr)(struct net_device *dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 018c15c..f667dd3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4504,8 +4504,6 @@ void __dev_set_rx_mode(struct net_device *dev)
if (ops->ndo_set_rx_mode)
ops->ndo_set_rx_mode(dev);
- else if (ops->ndo_set_multicast_list)
- ops->ndo_set_multicast_list(dev);
}
void dev_set_rx_mode(struct net_device *dev)
@@ -4855,7 +4853,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
return -EOPNOTSUPP;
case SIOCADDMULTI:
- if ((!ops->ndo_set_multicast_list && !ops->ndo_set_rx_mode) ||
+ if (!ops->ndo_set_rx_mode ||
ifr->ifr_hwaddr.sa_family != AF_UNSPEC)
return -EINVAL;
if (!netif_device_present(dev))
@@ -4863,7 +4861,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
return dev_mc_add_global(dev, ifr->ifr_hwaddr.sa_data);
case SIOCDELMULTI:
- if ((!ops->ndo_set_multicast_list && !ops->ndo_set_rx_mode) ||
+ if (!ops->ndo_set_rx_mode ||
ifr->ifr_hwaddr.sa_family != AF_UNSPEC)
return -EINVAL;
if (!netif_device_present(dev))
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index e2e6693..283d1b8 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -591,8 +591,8 @@ EXPORT_SYMBOL(dev_mc_del_global);
* addresses that have no users left. The source device must be
* locked by netif_tx_lock_bh.
*
- * This function is intended to be called from the dev->set_multicast_list
- * or dev->set_rx_mode function of layered software devices.
+ * This function is intended to be called from the ndo_set_rx_mode
+ * function of layered software devices.
*/
int dev_mc_sync(struct net_device *to, struct net_device *from)
{
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 7069522..ce57bde 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1009,7 +1009,7 @@ static void ip_mc_filter_add(struct in_device *in_dev, __be32 addr)
/* Checking for IFF_MULTICAST here is WRONG-WRONG-WRONG.
We will get multicast token leakage, when IFF_MULTICAST
- is changed. This check should be done in dev->set_multicast_list
+ is changed. This check should be done in ndo_set_rx_mode
routine. Something sort of:
if (dev->mc_list && dev->flags&IFF_MULTICAST) { do it; }
--ANK
--
1.7.6
^ permalink raw reply related
* [patch net-next-2.6 0/3] net: remove ndo_set_multicast_list
From: Jiri Pirko @ 2011-08-16 16:28 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, eric.dumazet, kaber, yoshfuji, rdunlap, kuznet,
jmorris, mirqus, jesse
Now we have 2 callbacks exported to drivers to set rx filtering:
ndo_set_multicast_list
ndo_set_rx_mode
The second one was added with second unicast address list and only drivers
that are able to handle unicast filtering should use that.
Having these two together is confusing and as I found out in many drivers,
developers are not using them properly. So just kill one of them.
ndo_set_multicast_list gets the bullet because I believe that name "set_rx_mode"
is more appropriate.
IFF_UNICAST_FLT flag is used so core know if driver handles unicast filtering.
applies cleanly on most recent net-next with "[patch net-next-2.6 v2] bonding: use ndo_change_rx_flags callback"
Jiri Pirko (3):
net: introduce IFF_UNICAST_FLT private flag
net: remove use of ndo_set_multicast_list in drivers
net: remove ndo_set_multicast_list callback
Documentation/networking/netdevices.txt | 4 ++--
arch/ia64/hp/sim/simeth.c | 2 +-
arch/um/drivers/net_kern.c | 2 +-
arch/xtensa/platforms/iss/network.c | 2 +-
drivers/infiniband/hw/nes/nes_nic.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 +-
drivers/media/dvb/dvb-core/dvb_net.c | 2 +-
drivers/net/appletalk/cops.c | 2 +-
drivers/net/appletalk/ltpc.c | 2 +-
drivers/net/arcnet/com20020.c | 2 +-
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/cris/eth_v10.c | 2 +-
drivers/net/defxx.c | 2 +-
drivers/net/dummy.c | 2 +-
drivers/net/ethernet/3com/3c501.c | 2 +-
drivers/net/ethernet/3com/3c509.c | 2 +-
drivers/net/ethernet/3com/3c515.c | 2 +-
drivers/net/ethernet/3com/3c574_cs.c | 2 +-
drivers/net/ethernet/3com/3c589_cs.c | 2 +-
drivers/net/ethernet/3com/3c59x.c | 4 ++--
drivers/net/ethernet/3com/typhoon.c | 2 +-
drivers/net/ethernet/8390/3c503.c | 2 +-
drivers/net/ethernet/8390/8390.c | 2 +-
drivers/net/ethernet/8390/8390p.c | 2 +-
drivers/net/ethernet/8390/ac3200.c | 2 +-
drivers/net/ethernet/8390/ax88796.c | 2 +-
drivers/net/ethernet/8390/axnet_cs.c | 2 +-
drivers/net/ethernet/8390/e2100.c | 2 +-
drivers/net/ethernet/8390/etherh.c | 2 +-
drivers/net/ethernet/8390/hp-plus.c | 2 +-
drivers/net/ethernet/8390/hydra.c | 2 +-
drivers/net/ethernet/8390/mac8390.c | 2 +-
drivers/net/ethernet/8390/ne-h8300.c | 2 +-
drivers/net/ethernet/8390/ne2k-pci.c | 2 +-
drivers/net/ethernet/8390/pcnet_cs.c | 2 +-
drivers/net/ethernet/8390/smc-mca.c | 2 +-
drivers/net/ethernet/8390/smc-ultra.c | 2 +-
drivers/net/ethernet/8390/smc-ultra32.c | 2 +-
drivers/net/ethernet/8390/wd.c | 2 +-
drivers/net/ethernet/8390/zorro8390.c | 2 +-
drivers/net/ethernet/adaptec/starfire.c | 2 +-
drivers/net/ethernet/adi/bfin_mac.c | 2 +-
drivers/net/ethernet/aeroflex/greth.c | 2 +-
drivers/net/ethernet/alteon/acenic.c | 2 +-
drivers/net/ethernet/amd/a2065.c | 2 +-
drivers/net/ethernet/amd/am79c961a.c | 2 +-
drivers/net/ethernet/amd/amd8111e.c | 2 +-
drivers/net/ethernet/amd/ariadne.c | 2 +-
drivers/net/ethernet/amd/atarilance.c | 2 +-
drivers/net/ethernet/amd/au1000_eth.c | 2 +-
drivers/net/ethernet/amd/declance.c | 2 +-
drivers/net/ethernet/amd/depca.c | 2 +-
drivers/net/ethernet/amd/hplance.c | 2 +-
drivers/net/ethernet/amd/lance.c | 2 +-
drivers/net/ethernet/amd/mvme147.c | 2 +-
drivers/net/ethernet/amd/ni65.c | 2 +-
drivers/net/ethernet/amd/nmclan_cs.c | 2 +-
drivers/net/ethernet/amd/pcnet32.c | 2 +-
drivers/net/ethernet/amd/sun3lance.c | 2 +-
drivers/net/ethernet/amd/sunlance.c | 2 +-
drivers/net/ethernet/apple/bmac.c | 2 +-
drivers/net/ethernet/apple/cs89x0.c | 2 +-
drivers/net/ethernet/apple/mac89x0.c | 2 +-
drivers/net/ethernet/apple/mace.c | 2 +-
drivers/net/ethernet/apple/macmace.c | 2 +-
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 2 +-
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 2 +-
drivers/net/ethernet/atheros/atlx/atl1.c | 2 +-
drivers/net/ethernet/atheros/atlx/atl2.c | 2 +-
drivers/net/ethernet/broadcom/b44.c | 2 +-
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +-
drivers/net/ethernet/broadcom/bnx2.c | 2 ++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 +++
drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 2 +-
drivers/net/ethernet/brocade/bna/bnad.c | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 2 +-
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 2 +-
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 3 +++
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 2 ++
drivers/net/ethernet/cisco/enic/enic_main.c | 5 +++--
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dec/ewrk3.c | 2 +-
drivers/net/ethernet/dec/tulip/de2104x.c | 2 +-
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
drivers/net/ethernet/dec/tulip/dmfe.c | 2 +-
drivers/net/ethernet/dec/tulip/tulip_core.c | 2 +-
drivers/net/ethernet/dec/tulip/uli526x.c | 2 +-
drivers/net/ethernet/dec/tulip/winbond-840.c | 2 +-
drivers/net/ethernet/dlink/de620.c | 2 +-
drivers/net/ethernet/dlink/dl2k.c | 2 +-
drivers/net/ethernet/dlink/sundance.c | 2 +-
drivers/net/ethernet/ethoc.c | 2 +-
drivers/net/ethernet/fealnx.c | 2 +-
drivers/net/ethernet/freescale/fec.c | 2 +-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
drivers/net/ethernet/fujitsu/at1700.c | 2 +-
drivers/net/ethernet/fujitsu/eth16i.c | 2 +-
drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 2 +-
drivers/net/ethernet/hp/hp100.c | 4 ++--
drivers/net/ethernet/i825xx/3c505.c | 2 +-
drivers/net/ethernet/i825xx/3c523.c | 2 +-
drivers/net/ethernet/i825xx/3c527.c | 2 +-
drivers/net/ethernet/i825xx/82596.c | 2 +-
drivers/net/ethernet/i825xx/eepro.c | 2 +-
drivers/net/ethernet/i825xx/eexpress.c | 2 +-
drivers/net/ethernet/i825xx/ether1.c | 2 +-
drivers/net/ethernet/i825xx/lib82596.c | 2 +-
drivers/net/ethernet/i825xx/lp486e.c | 2 +-
drivers/net/ethernet/i825xx/ni52.c | 2 +-
drivers/net/ethernet/i825xx/sun3_82586.c | 2 +-
drivers/net/ethernet/i825xx/znet.c | 2 +-
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +-
drivers/net/ethernet/ibm/emac/core.c | 4 ++--
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
drivers/net/ethernet/ibm/iseries_veth.c | 2 +-
drivers/net/ethernet/icplus/ipg.c | 2 +-
drivers/net/ethernet/intel/e100.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 ++
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 4 +++-
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +++-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 +++-
drivers/net/ethernet/jme.c | 2 +-
drivers/net/ethernet/korina.c | 2 +-
drivers/net/ethernet/lantiq_etop.c | 2 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 ++
drivers/net/ethernet/marvell/skge.c | 2 +-
drivers/net/ethernet/marvell/sky2.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/micrel/ks8695net.c | 2 +-
drivers/net/ethernet/microchip/enc28j60.c | 2 +-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +-
drivers/net/ethernet/natsemi/ibmlana.c | 2 +-
drivers/net/ethernet/natsemi/jazzsonic.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/natsemi/natsemi.c | 2 +-
drivers/net/ethernet/natsemi/ns83820.c | 2 +-
drivers/net/ethernet/natsemi/xtsonic.c | 2 +-
drivers/net/ethernet/neterion/s2io.c | 2 +-
drivers/net/ethernet/neterion/vxge/vxge-main.c | 2 +-
drivers/net/ethernet/netx-eth.c | 2 +-
drivers/net/ethernet/nuvoton/w90p910_ether.c | 2 +-
drivers/net/ethernet/nvidia/forcedeth.c | 4 ++--
drivers/net/ethernet/octeon/octeon_mgmt.c | 4 +++-
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 +-
drivers/net/ethernet/packetengines/hamachi.c | 2 +-
drivers/net/ethernet/packetengines/yellowfin.c | 2 +-
drivers/net/ethernet/pasemi/pasemi_mac.c | 2 +-
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 +-
drivers/net/ethernet/qlogic/qla3xxx.c | 1 -
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +-
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 +-
drivers/net/ethernet/racal/ni5010.c | 2 +-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/realtek/8139cp.c | 2 +-
drivers/net/ethernet/realtek/8139too.c | 2 +-
drivers/net/ethernet/realtek/atp.c | 2 +-
drivers/net/ethernet/realtek/r8169.c | 2 +-
drivers/net/ethernet/realtek/sc92031.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/seeq/ether3.c | 2 +-
drivers/net/ethernet/seeq/seeq8005.c | 2 +-
drivers/net/ethernet/seeq/sgiseeq.c | 2 +-
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/ethernet/sgi/ioc3-eth.c | 2 +-
drivers/net/ethernet/sis/sis190.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/epic100.c | 2 +-
drivers/net/ethernet/smsc/smc911x.c | 2 +-
drivers/net/ethernet/smsc/smc9194.c | 2 +-
drivers/net/ethernet/smsc/smc91c92_cs.c | 2 +-
drivers/net/ethernet/smsc/smc91x.c | 2 +-
drivers/net/ethernet/smsc/smsc911x.c | 2 +-
drivers/net/ethernet/smsc/smsc9420.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 ++++++++-----
drivers/net/ethernet/sun/cassini.c | 2 +-
drivers/net/ethernet/sun/niu.c | 5 ++++-
drivers/net/ethernet/sun/sunbmac.c | 2 +-
drivers/net/ethernet/sun/sungem.c | 2 +-
drivers/net/ethernet/sun/sunhme.c | 2 +-
drivers/net/ethernet/sun/sunqe.c | 2 +-
drivers/net/ethernet/sun/sunvnet.c | 2 +-
drivers/net/ethernet/tehuti/tehuti.c | 2 +-
drivers/net/ethernet/ti/cpmac.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
drivers/net/ethernet/ti/tlan.c | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/tundra/tsi108_eth.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ethernet/via/via-velocity.c | 2 +-
drivers/net/ethernet/xilinx/ll_temac_main.c | 1 -
drivers/net/ethernet/xircom/xirc2ps_cs.c | 2 +-
drivers/net/ethernet/xscale/ixp4xx_eth.c | 2 +-
drivers/net/macvlan.c | 2 +-
drivers/net/skfp/skfddi.c | 2 +-
drivers/net/tokenring/3c359.c | 2 +-
drivers/net/tokenring/ibmtr.c | 2 +-
drivers/net/tokenring/lanstreamer.c | 2 +-
drivers/net/tokenring/olympic.c | 2 +-
drivers/net/tokenring/smctr.c | 2 +-
drivers/net/tokenring/tms380tr.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/usb/asix.c | 6 +++---
drivers/net/usb/catc.c | 2 +-
drivers/net/usb/dm9601.c | 2 +-
drivers/net/usb/int51x1.c | 2 +-
drivers/net/usb/kaweth.c | 2 +-
drivers/net/usb/mcs7830.c | 2 +-
drivers/net/usb/pegasus.c | 2 +-
drivers/net/usb/rtl8150.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/virtio_net.c | 1 +
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/net/wan/sbni.c | 2 +-
drivers/net/wireless/airo.c | 4 ++--
drivers/net/wireless/hostap/hostap_main.c | 6 +++---
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/libertas/main.c | 2 +-
drivers/net/wireless/libertas/mesh.c | 2 +-
drivers/net/wireless/mwifiex/main.c | 2 +-
drivers/net/wireless/orinoco/main.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 2 +-
drivers/net/wireless/ray_cs.c | 2 +-
drivers/net/wireless/rndis_wlan.c | 2 +-
drivers/net/wireless/zd1201.c | 2 +-
drivers/s390/net/lcs.c | 2 +-
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 4 ++--
drivers/staging/ath6kl/os/linux/ar6000_drv.c | 2 +-
drivers/staging/brcm80211/brcmfmac/dhd_linux.c | 2 +-
drivers/staging/et131x/et131x_netdev.c | 2 +-
drivers/staging/hv/netvsc_drv.c | 2 +-
drivers/staging/octeon/ethernet.c | 12 ++++++------
drivers/staging/rtl8187se/r8180_core.c | 2 +-
drivers/staging/rtl8192e/r8192E_core.c | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
drivers/staging/slicoss/slicoss.c | 2 +-
drivers/staging/vt6655/device_main.c | 2 +-
drivers/staging/vt6656/main_usb.c | 2 +-
drivers/staging/wlags49_h2/wl_netdev.c | 2 +-
drivers/staging/wlan-ng/p80211netdev.c | 2 +-
include/linux/if.h | 1 +
include/linux/netdevice.h | 6 ++----
net/8021q/vlan_dev.c | 1 -
net/atm/lec.c | 2 +-
net/bluetooth/bnep/netdev.c | 2 +-
net/bridge/br_device.c | 2 +-
net/core/dev.c | 14 ++++++--------
net/core/dev_addr_lists.c | 4 ++--
net/dsa/slave.c | 3 ---
net/ipv4/igmp.c | 2 +-
net/irda/irlan/irlan_eth.c | 2 +-
net/mac80211/iface.c | 4 ++--
266 files changed, 314 insertions(+), 294 deletions(-)
--
1.7.6
^ permalink raw reply
* Re: Transfer Offer
From: Song Li @ 2011-08-17 7:04 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank to you account.
Finally if you are interested I shall provide you with more details.
Email: songli1@w.cn
^ permalink raw reply
* Re: [RFC PATCH v2 4/9] bql: Byte queue limits
From: Ben Hutchings @ 2011-08-16 17:31 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072144010.13721@pokey.mtv.corp.google.com>
On Sun, 2011-08-07 at 21:48 -0700, Tom Herbert wrote:
> Networking stack support for byte queue limits, uses dynamic queue
> limits library. Byte queue limits are maintained per transmit queue,
> and a bql structure has been added to netdev_queue structure for this
> purpose.
>
> Configuration of bql is in the tx-<n> sysfs directory for the queue
> under the byte_queue_limits directory. Configuration includes:
> limit_min, bql minimum limit
> limit_max, bql maximum limit
> hold_time, bql slack hold time
>
> Also under the directory are:
> limit, current byte limit
> inflight, current number of bytes on the queue
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 16 +++
> net/core/dev.c | 1 +
> net/core/net-sysfs.c | 230 ++++++++++++++++++++++++++++++++++-----------
> 3 files changed, 192 insertions(+), 55 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 74e8862..d49265b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
[...]
> @@ -1913,29 +1915,43 @@ static inline int netif_xmit_frozen_or_stopped(const struct netdev_queue *dev_qu
> static inline void netdev_tx_sent_queue(struct netdev_queue *dev_queue,
> unsigned int pkts, unsigned int bytes)
> {
> + dql_queued(&dev_queue->dql, bytes);
> + if (dql_avail(&dev_queue->dql) < 0)
> + set_bit(__QUEUE_STATE_STACK_XOFF, &dev_queue->state);
> }
[...]
> static inline void netdev_tx_completed_queue(struct netdev_queue *dev_queue,
> unsigned pkts, unsigned bytes)
> {
> + if (bytes) {
> + dql_completed(&dev_queue->dql, bytes);
> + if (dql_avail(&dev_queue->dql) >= 0 &&
> + test_and_clear_bit(__QUEUE_STATE_STACK_XOFF,
> + &dev_queue->state))
> + netif_schedule_queue(dev_queue);
> + }
> }
There is generally no interlocking between initiation and completion
paths, and the dql library doesn't provide either interlocking or atomic
operations, so I'm pretty sure there is a race condition here where a
queue will not be woken.
Also, the cache line containing the struct dql can ping-pong between
CPUs doing initiation and completion. (I know we're aiming for these to
be the same, but we can't yet assume they will be.)
[...]
> diff --git a/net/core/dev.c b/net/core/dev.c
> index a7f8c38..bd5cd15 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5395,6 +5395,7 @@ static void netdev_init_one_queue(struct net_device *dev,
> queue->xmit_lock_owner = -1;
> netdev_queue_numa_node_write(queue, NUMA_NO_NODE);
> queue->dev = dev;
> + dql_init(&queue->dql, 1000);
I think you mean HZ, not 1000.
[...]
> +static ssize_t bql_show_inflight(struct netdev_queue *queue,
> + struct netdev_queue_attribute *attr,
> + char *buf)
> +{
> + struct dql *dql = &queue->dql;
> + int p = 0;
> +
> + p = sprintf(buf, "%lu\n", dql->num_queued - dql->num_completed);
> +
> + return p;
> +}
[...]
A certain amount of redundancy in the use of 'p' here...
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] Fix possible Null pointer dereference in ipoib_start_xmit()
From: Roland Dreier @ 2011-08-16 17:19 UTC (permalink / raw)
To: Bernd Schubert
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110816105654.1805137.9189.stgit@fsdevel3>
Thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/9] dql: Dynamic queue limits
From: Ben Hutchings @ 2011-08-16 17:15 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072130380.13721@pokey.mtv.corp.google.com>
On Sun, 2011-08-07 at 21:43 -0700, Tom Herbert wrote:
> Implementation of dynamic queue limits (dql). This is a libary which
> allows a queue limit to be dynamically managed. The goal of dql is
> to set the queue limit, number of ojects to the queue, to be minimized
> without allowing the queue to be starved.
>
> dql would be used with a queue whose use has these properties:
>
> 1) Objects are queued up to some limit which can be expressed as a
> count of objects.
> 2) Periodically a completion process executes which retires consumed
> objects.
> 3) Starvation occurs when limit has been reached, all queued data has
> actually been consumed but completion processing has not yet run,
> so queuing new data is blocked.
> 4) Minimizing the amount of queued data is desirable.
>
> A canonical example of such a queue would be a NIC HW transmit queue.
>
> The queue limit is dynamic, it will increase or decrease over time
> depending on the workload. The queue limit is recalculated each time
> completion processing is done. Increases occur when the queue is
> starved and can exponentially increase over successive intervals.
> Decreases occur when more data is being maintained in the queue than
> needed to prevent starvation. The number of extra objects, or "slack",
> is measured over successive intervals, and to avoid hysteresis the
> limit is only reduced by the miminum slack seen over a configurable
> time period.
How does this or could this interact with adaptive TX interrupt
coalescing?
> dql API provides routines to manage the queue:
> - dql_init is called to intialize the dql structure
> - dql_reset is called to reset dynamic structures
> - dql_queued when objects are being enqueued
> - dql_avail returns availability in the queue
> - dql_completed is called when objects have be consumed in the queue
These explanations should go in kernel-doc comments above the functions.
> Configuration consists of:
> - max_limit, maximum limit
> - min_limt, minimum limit
> - slack_hold_time, time to measure instances of slack before reducing
> queue limit.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/dynamic_queue_limits.h | 80 ++++++++++++++++++++
> lib/Makefile | 2 +-
> lib/dynamic_queue_limits.c | 132 ++++++++++++++++++++++++++++++++++
> 3 files changed, 213 insertions(+), 1 deletions(-)
> create mode 100644 include/linux/dynamic_queue_limits.h
> create mode 100644 lib/dynamic_queue_limits.c
>
> diff --git a/include/linux/dynamic_queue_limits.h b/include/linux/dynamic_queue_limits.h
> new file mode 100644
> index 0000000..3ffc591
> --- /dev/null
> +++ b/include/linux/dynamic_queue_limits.h
[...]
> +struct dql {
> + unsigned long limit; /* Current limit */
> + unsigned long prev_ovlimit; /* Previous over limit */
> +
> + unsigned long num_queued; /* Total ever queued */
> + unsigned long prev_num_queued; /* Previous queue total */
> + unsigned long num_completed; /* Total ever completed */
> +
> + unsigned long last_obj_cnt; /* Count at last queuing */
> + unsigned long prev_last_obj_cnt; /* Previous queuing cnt */
> +
> + unsigned long lowest_slack; /* Lowest slack found */
> + unsigned long slack_start_time; /* Time slacks seen */
> +
> + unsigned long max_limit; /* Maximum limit */
> + unsigned long min_limit; /* Minimum limit */
> + unsigned slack_hold_time; /* Time to measure slack */
> +};
Please put the descriptions in kernel-doc format. That would also make
it easy to expand them a little - for example, to say that 'limit' is
not a hard limit but the threshold above which the queue should be
stopped.
> +/* Set some static maximums */
> +#define DQL_MAX_OBJECT (-1UL / 16)
> +#define DQL_MAX_LIMIT ((-1UL / 2) - DQL_MAX_OBJECT)
ULONG_MAX would be clearer than -1UL.
[...]
> --- /dev/null
> +++ b/lib/dynamic_queue_limits.c
> @@ -0,0 +1,132 @@
> +/*
> + * Dynamic byte queue limits. See include/linux/dynamic_queue_limits.h
> + *
> + * Author: Tom Herbert (therbert@google.com)
> + */
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/ctype.h>
> +#include <linux/kernel.h>
> +#include <linux/dynamic_queue_limits.h>
> +
> +#define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
> +
> +/* Records completed count and recalculates the queue limit */
> +void dql_completed(struct dql *dql, unsigned long count)
> +{
> + unsigned long inprogress, prev_inprogress, limit;
> + unsigned long ovlimit, all_prev_completed, completed;
> +
> + /* Can't complete more than what's in queue */
> + BUG_ON(count > dql->num_queued - dql->num_completed);
> +
> + completed = dql->num_completed + count;
> + limit = dql->limit;
> + ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
> + inprogress = dql->num_queued - completed;
> + prev_inprogress = dql->prev_num_queued - dql->num_completed;
> + all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
all_prev_completed is named and used as a boolean, but initialised as a
count. Since the count is actually useful, it should be renamed to,
e.g. completed_newly_queued.
> + if ((ovlimit && !inprogress) ||
> + (dql->prev_ovlimit && all_prev_completed)) {
> + /*
> + * Queue considered starved if:
> + * - The queue was over-limit in the last interval,
> + * and there is no more data in the queue.
> + * OR
> + * - The queue was over-limit in the previous interval and
> + * when enqueuing it was possible that all queued data
> + * had been consumed. This covers the case when queue
> + * may have becomes starved between completion processing
> + * running and next time enqueue was scheduled.
> + *
> + * When queue is starved increase the limit by the amount
> + * of bytes both sent and completed in the last interval,
For consistency, this should say 'number of objects' not 'amount of
bytes'.
> + * plus any previous over-limit.
> + */
> + limit += POSDIFF(completed, dql->prev_num_queued) +
> + dql->prev_ovlimit;
limit += completed_newly_queued + dql->prev_ovlimit;
> + dql->slack_start_time = jiffies;
> + dql->lowest_slack = -1UL;
ULONG_MAX
> + } else if (inprogress && prev_inprogress && !all_prev_completed) {
> + /*
> + * Queue was not starved, check if the limit can be decreased.
> + * A decrease is only considered if the queue has been busy in
> + * the whole interval (the check above).
> + *
> + * If there is slack, the amount execess data queued above the
> + * the amount needed to prevent starvation, the queue limit can
> + * be decreased. To avoid hysteresis we consider the
> + * minimum amount of slack found over several iterations of the
> + * completion routine.
> + */
This is *adding* hysteresis (resistance to changing state).
> + unsigned long slack, slack_last_objs;
> +
> + /*
> + * Slack is the maximum of
> + * - The queue limit plus previous over-limit minus twice
> + * the number of objects completed. Note that two times
> + * number of completed bytes is basis for upper bound
'objects' not 'bytes'
> + * of the limit.
> + * - Portion of objects in the last queuing operation that
> + * was not part of non-zero previous over-limit. That is
> + * "round down" by non-overlimit portion of the last
> + * queueing operation.
I don't follow either the explanation or the calculation of this second
value (slack_last_objs).
If the queue was filled over the 'limit', doesn't that mean there was
less slack? Yet slack_last_objs can only be positive (and therefore
influence slack) if dql->prev_ovlimit is true.
> + */
> + slack = POSDIFF(limit + dql->prev_ovlimit,
> + 2 * (completed - dql->num_completed));
> + slack_last_objs = dql->prev_ovlimit ?
> + POSDIFF(dql->prev_last_obj_cnt, dql->prev_ovlimit) : 0;
> +
> + slack = max(slack, slack_last_objs);
> +
> + if (slack < dql->lowest_slack)
> + dql->lowest_slack = slack;
> +
> + if (time_after(jiffies,
> + dql->slack_start_time + dql->slack_hold_time)) {
> + limit = POSDIFF(limit, dql->lowest_slack);
> + dql->slack_start_time = jiffies;
> + dql->lowest_slack = -1UL;
[...]
ULONG_MAX
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* ath: Could not kill baseband RX
From: Justin P. Mattock @ 2011-08-16 16:11 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
seems with the current I have hit:
ath: Could not kill baseband RX
[ 966.943524] ath: Unable to reset channel (2412 MHz), reset status -5
[ 966.943631] ath: Unable to set channel
[ 967.066100] ath: Could not kill baseband RX
[ 967.189233] ath: Unable to reset channel (2417 MHz), reset status -5
[ 967.189294] ath: Unable to set channel
[ 967.311597] ath: Could not kill baseband RX
[ 967.434729] ath: Unable to reset channel (2422 MHz), reset status -5
[ 967.434796] ath: Unable to set channel
full dmesg..: http://fpaste.org/voy7/
wireless goes out, a reboot is the only way to get the wireless back up
and running.
there is a similar bug, but looks different than this one(but could be
wrong). https://bugzilla.kernel.org/show_bug.cgi?id=31702
Justin P. Mattock
^ permalink raw reply
* Re: [stable] [PATCH 1/1] OMAP: wlan: Set the WLAN Regulator to be always on
From: Greg KH @ 2011-08-16 16:07 UTC (permalink / raw)
To: panduranga_mallireddy
Cc: stable, ohad, pradeepgurumath, coelho, netdev, naveen_jain,
x-boudet, vishalm, manjunatha_halli, benzyg, linux-omap
In-Reply-To: <1313507037-2467-2-git-send-email-panduranga_mallireddy@ti.com>
On Tue, Aug 16, 2011 at 10:03:57AM -0500, panduranga_mallireddy@ti.com wrote:
> From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
>
> For regulator omap4_clk32k used by wlan, set .constraints.always_on to 1.
> This regulator should never be disabled.
>
> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
> ---
> arch/arm/mach-omap2/twl-common.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH 1/1] OMAP: wlan: Set the WLAN Regulator to be always on
From: panduranga_mallireddy @ 2011-08-16 15:03 UTC (permalink / raw)
To: stable
Cc: ohad, Panduranga Mallireddy, pradeepgurumath, coelho, netdev,
naveen_jain, x-boudet, vishalm, manjunatha_halli, benzyg,
linux-omap
In-Reply-To: <1313507037-2467-1-git-send-email-panduranga_mallireddy@ti.com>
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
For regulator omap4_clk32k used by wlan, set .constraints.always_on to 1.
This regulator should never be disabled.
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/twl-common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..536ad71 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -229,6 +229,7 @@ static struct regulator_init_data omap4_vusb_idata = {
static struct regulator_init_data omap4_clk32kg_idata = {
.constraints = {
.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
--
1.7.1
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply related
* [PATCH 0/1] OMAP: WLAN : To fix a WLAN related bug in Kernel 3.0
From: panduranga_mallireddy @ 2011-08-16 15:03 UTC (permalink / raw)
To: stable
Cc: ohad, Panduranga Mallireddy, pradeepgurumath, coelho, netdev,
naveen_jain, x-boudet, vishalm, manjunatha_halli, benzyg,
linux-omap
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Error reported for wl12xx driver with Kernel 3.0 is
[ 0.181457] error setting wl12xx data
FIX:
For regulator omap4_clk32k used by wlan, set .constraints.always_on to 1
Panduranga Mallireddy (1):
OMAP: wlan: Set the WLAN Regulator to be always on
arch/arm/mach-omap2/twl-common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Florian Mickler @ 2011-08-16 14:57 UTC (permalink / raw)
To: Bernd Schubert
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Maciej Rutecki,
Kernel Testers List, Network Development
In-Reply-To: <4E498E09.1000208-97jfqw80gc6171pxa8y+qA@public.gmane.org>
On Mon, 15 Aug 2011 23:22:17 +0200
Bernd Schubert <bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org> wrote:
> On 08/14/2011 09:02 PM, Rafael J. Wysocki wrote:
>
> > Please let the tracking team know if there are any Bugzilla entries that
> > should be added to the list in there.
> >
>
> Could you please add
>
> Bug-Entry : https://bugzilla.kernel.org/show_bug.cgi?id=41212
> Subject : ipoib causes kernel panic (NULL pointer dereference)
> Submitter : Bernd Schubert <bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>
> Date : 2011-08-15 15:40
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=68942
>
>
> Thanks,
> Bernd
Done. Please submit the patch to netdev mailinglist for review.
Regards,
Flo
^ permalink raw reply
* Re: [patch net-next-2.6] bonding: use ndo_change_rx_flags callback
From: Jiri Pirko @ 2011-08-16 13:15 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, fubar, andy
In-Reply-To: <CAHXqBFJL+y3TOj-OX4wXT-H1Z9R3EqJLnA64t5_ocCKLx6tPUQ@mail.gmail.com>
Tue, Aug 16, 2011 at 12:03:42PM CEST, mirqus@gmail.com wrote:
>2011/8/16 Jiri Pirko <jpirko@redhat.com>:
>> Benefit from use of ndo_change_rx_flags in handling change of promisc
>> and allmulti. No need to store previous state locally.
>[...]
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 854aa8d..731763a 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>[...]
>> -static void bond_set_multicast_list(struct net_device *bond_dev)
>> +static void bond_change_rx_flags(struct net_device *bond_dev, int change)
>> {
>[...]
>> + if (change & IFF_PROMISC)
>> + bond_set_promiscuity(bond,
>> + bond_dev->flags & IFF_ALLMULTI ? 1 : -1);
>
>Typo: flags & IFF_PROMISC ?
Sure, thanks Michał
V2:
Subject: [patch net-next-2.6 v2] bonding: use ndo_change_rx_flags callback
Benefit from use of ndo_change_rx_flags in handling change of promisc
and allmulti. No need to store previous state locally.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
v1->v2: fixed IFF_ALLMULTI/IFF_PROMISC c&p typo
---
drivers/net/bonding/bond_main.c | 44 ++++++++++++--------------------------
drivers/net/bonding/bonding.h | 1 -
2 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 854aa8d..c3e4683 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3686,44 +3686,27 @@ static bool bond_addr_in_mc_list(unsigned char *addr,
return false;
}
-static void bond_set_multicast_list(struct net_device *bond_dev)
+static void bond_change_rx_flags(struct net_device *bond_dev, int change)
{
struct bonding *bond = netdev_priv(bond_dev);
- struct netdev_hw_addr *ha;
- bool found;
- /*
- * Do promisc before checking multicast_mode
- */
- if ((bond_dev->flags & IFF_PROMISC) && !(bond->flags & IFF_PROMISC))
- /*
- * FIXME: Need to handle the error when one of the multi-slaves
- * encounters error.
- */
- bond_set_promiscuity(bond, 1);
-
-
- if (!(bond_dev->flags & IFF_PROMISC) && (bond->flags & IFF_PROMISC))
- bond_set_promiscuity(bond, -1);
+ if (change & IFF_PROMISC)
+ bond_set_promiscuity(bond,
+ bond_dev->flags & IFF_PROMISC ? 1 : -1);
+ if (change & IFF_ALLMULTI)
+ bond_set_allmulti(bond,
+ bond_dev->flags & IFF_ALLMULTI ? 1 : -1);
+}
- /* set allmulti flag to slaves */
- if ((bond_dev->flags & IFF_ALLMULTI) && !(bond->flags & IFF_ALLMULTI))
- /*
- * FIXME: Need to handle the error when one of the multi-slaves
- * encounters error.
- */
- bond_set_allmulti(bond, 1);
-
-
- if (!(bond_dev->flags & IFF_ALLMULTI) && (bond->flags & IFF_ALLMULTI))
- bond_set_allmulti(bond, -1);
-
+static void bond_set_multicast_list(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct netdev_hw_addr *ha;
+ bool found;
read_lock(&bond->lock);
- bond->flags = bond_dev->flags;
-
/* looking for addresses to add to slaves' mc list */
netdev_for_each_mc_addr(ha, bond_dev) {
found = bond_addr_in_mc_list(ha->addr, &bond->mc_list,
@@ -4282,6 +4265,7 @@ static const struct net_device_ops bond_netdev_ops = {
.ndo_select_queue = bond_select_queue,
.ndo_get_stats64 = bond_get_stats,
.ndo_do_ioctl = bond_do_ioctl,
+ .ndo_change_rx_flags = bond_change_rx_flags,
.ndo_set_multicast_list = bond_set_multicast_list,
.ndo_change_mtu = bond_change_mtu,
.ndo_set_mac_address = bond_set_mac_address,
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 43526a2..e823366 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -234,7 +234,6 @@ struct bonding {
struct netdev_hw_addr_list mc_list;
int (*xmit_hash_policy)(struct sk_buff *, int);
__be32 master_ip;
- u16 flags;
u16 rr_tx_counter;
struct ad_bond_info ad_info;
struct alb_bond_info alb_info;
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Eilon Greenstein @ 2011-08-16 12:45 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <4E4A56C0.4030009@redhat.com>
On Tue, 2011-08-16 at 04:38 -0700, Michal Schmidt wrote:
> On 08/15/2011 08:47 PM, Eilon Greenstein wrote:
> > On Mon, 2011-08-15 at 08:13 -0700, Michal Schmidt wrote:
> >> A tester reported getting only these 4 messages with the patch applied:
> >>
> >> [bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
> >> BW on vn 2 - using 100 instead
> >> [bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
> >> BW on vn 2 - using 100 instead
> >> [bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
> >> BW on vn 3 - using 100 instead
> >> [bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
> >> BW on vn 3 - using 100 instead
> >>
> >> This suggests that VNs 0 and 1 had non-zero Max BW configuration.
> >
> > Michal - this is a great point of data! It helped me finding a bug in
> > that code - the code is not suitable for 4 port devices, it always
> > assumes 4 VN per PCI function, while in 4 port devices there are only 2
> > VN per PCI function. I assume that you are seeing this problem on a
> > 57800 with 2x10G + 2x1G - and the 1G devices are in single function mode
> > and therefore you are seeing this error message. I will send a patch to
> > fix the problem on 4 port devices soon (after testing it for a while) -
> > please confirm that you are seeing this issue on 2x10G+2x1G 57800
> > device.
>
> Eilon,
> the tester is seeing this with BCM57711E. It's a HP-Blade bl460c-g6 with
> HP VirtualConnect. Quote from him:
>
> hp-agents reports 4 dual port nic's, Linux kernel reports 8 identical
> nic's but it's actual a blade with 2 LOM's (lan on motherboard) with
> each one port. Via VC we present max 4 FlexNic's per port, but for
> this server we present 2 FlexNic's per port.
>
> The fun with Linux is that it always sees all FlexNic's devices even
> if we configure 2 FlexNics via a VC profile on a port like on this
> server.
>
> Michal
I see. This seems to be a valid VC configuration and therefore the
message should be reduced to debug level all together. At least we
resolved a 4 port configuration problem...
Eilon
^ permalink raw reply
* Re: Transfer Offer
From: Song Li @ 2011-08-17 3:32 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank to you account.
Finally if you are interested I shall provide you with more details.
Email: songli1@w.cn
^ permalink raw reply
* Re: [PATCH net-2.6 V2] bonding:reset backup and inactive flag of slave
From: WANG Cong @ 2011-08-16 12:30 UTC (permalink / raw)
To: netdev
In-Reply-To: <8ed5a280dcc02566671810bcf7df83a05cb6a35d.1313459746.git.panweiping3@gmail.com>
On Tue, 16 Aug 2011 09:57:35 +0800, Weiping Pan wrote:
> Eduard Sinelnikov (eduard.sinelnikov@gmail.com) found that if we change
> bonding mode from active backup to round robin, some slaves are still
> keeping "backup", and won't transmit packets.
>
> As Jay Vosburgh(fubar@us.ibm.com) pointed out that we can work around
> that by removing the bond_is_active_slave() check, because the "backup"
> flag is only meaningful for active backup mode.
>
> But if we just simply ignore the bond_is_active_slave() check, the
> transmission will work fine, but we can't maintain the correct value of
> "backup" flag for each slaves, though it is meaningless for other mode
> than active backup.
>
> I'd like to reset "backup" and "inactive" flag in bond_open, thus we can
> keep the correct value of them.
>
> As for bond_is_active_slave(), I'd like to prepare another patch to
> handle it.
>
> V2:
> Use C style comment.
> Move read_lock(&bond->curr_slave_lock). Replace restore with reset, for
> active backup mode, it means "restore", but for other modes, it means
> "reset".
>
> Signed-off-by: Weiping Pan <panweiping3@gmail.com>
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Thanks.
^ permalink raw reply
* Re: Linux ipsec and dynamic routing
From: Stephen Clark @ 2011-08-16 11:51 UTC (permalink / raw)
To: hachi; +Cc: netdev
In-Reply-To: <2B8C0848-C5A1-4F19-AFDF-C7CB443789E0@kuiki.net>
On 08/14/2011 04:58 AM, hachi wrote:
> Hello heroes!
>
> I am after an eventual goal of dynamic routing (BGP) via the linux kernel using ipsec tunneling and no inner tunnel (gre or others). On the way to this goal I've done some light source diving of source and talked a little theory with others to hunt down as much as I could to get closer. I have a lot of questions here, so thanks for any answers or suggestions you may give.
>
> All of my testing is done using openswan, and debian stable (linux 2.6.32, iproute 20100519)
>
> * Are there any existing methods of implementing dynamic routed ipsec armored ip forwarding?
>
> I haven't been able to find anyone who has a working setup in this regard. My goal is very similar to the exposed routing setup of Amazon's VPC ipsec connections. I'm trying to implement one or both ends in linux successfully and haven't found any docs on the subject.
>
> * The ip xfrm policy selector syntax has a 'dev' argument that can be supplied. I was unable to figure out what the intention of this argument is via source, and I never found any docs or samples of its use. Can anyone enlighten me?
>
> * Are there any plans or generally accepted patches to expand the rules that may be used to select what frames are transformed?
>
> Currently the rules I can use are source address, destination address, and the mysterious 'dev' setting. I think the ultimate solution for me would be able to select frames for forwarding based on the gateway defined in the normal routing tables.
>
> * Do ip xfrm policy rules bypass normal routing policy?
>
> I'm relatively certain the answer to this is 'yes'. However I may not have the full story.
>
> I ran a simple test of two /24 exposed at either end of an ipsec tunnel. The left end is 10.24.2.0/24, the right is 10.24.3.0/24, and the transit is being done via 10.24.1.0/30. I configured this test using openswan and after setting up and checking to see if the boxes can pass frames I examined the policy list and the routing table.
>
> src 10.24.3.0/24 dst 10.24.2.0/24
> dir fwd priority 2344 ptype main
> tmpl src 10.24.1.2 dst 10.24.1.1
> proto esp reqid 16385 mode tunnel
>
> 10.24.1.0/30 dev eth1 proto kernel scope link src 10.24.1.1
> 10.24.2.0/24 dev eth0 proto kernel scope link src 10.24.2.2
> 172.16.3.0/24 dev eth0 proto kernel scope link src 172.16.3.16
> default via 172.16.3.1 dev eth0
>
> The opposite end is appropriately reversed, and there are two more policies for 'in' and 'out', but they are appropriately similar.
>
> What I notice is that despite not having a route for the exposed subnet on the other end of the tunnel linux happily forwards the frames and encodes them to the other end, and visa versa.
>
> I can watch the frames passing across eth1 and they are appropriately encrypted as specified, and if I turn the ipsec tunnel off on both sides the forwarding capability does indeed shut down. If I add routes for the opposing ends then the kernel starts forwarding frames as expected.
>
> * If I need to dive into this more to seek an implementation, does anyone know if the general theory should be the dynamic routing daemon in userspace should expand its code to update xfrm policies, or is the fact that xfrm policy is taking precedence over routing an oversight of the kernel code that should be fixed/updated/etc. ?
>
> * Is there any hope for policy routing table support to extend into this as well?
>
> I hope I'm reaching out to the proper group for this inquiry, please let me know if this was wrong :)
>
> --hachi--
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Did you get any responses? I would certainly like to know the answers to
some of the questions you posed.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-16 11:38 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313434042.30399.0.camel@lb-tlvb-eilong.il.broadcom.com>
On 08/15/2011 08:47 PM, Eilon Greenstein wrote:
> On Mon, 2011-08-15 at 08:13 -0700, Michal Schmidt wrote:
>> A tester reported getting only these 4 messages with the patch applied:
>>
>> [bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
>> BW on vn 2 - using 100 instead
>> [bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
>> BW on vn 2 - using 100 instead
>> [bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
>> BW on vn 3 - using 100 instead
>> [bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
>> BW on vn 3 - using 100 instead
>>
>> This suggests that VNs 0 and 1 had non-zero Max BW configuration.
>
> Michal - this is a great point of data! It helped me finding a bug in
> that code - the code is not suitable for 4 port devices, it always
> assumes 4 VN per PCI function, while in 4 port devices there are only 2
> VN per PCI function. I assume that you are seeing this problem on a
> 57800 with 2x10G + 2x1G - and the 1G devices are in single function mode
> and therefore you are seeing this error message. I will send a patch to
> fix the problem on 4 port devices soon (after testing it for a while) -
> please confirm that you are seeing this issue on 2x10G+2x1G 57800
> device.
Eilon,
the tester is seeing this with BCM57711E. It's a HP-Blade bl460c-g6 with
HP VirtualConnect. Quote from him:
hp-agents reports 4 dual port nic's, Linux kernel reports 8 identical
nic's but it's actual a blade with 2 LOM's (lan on motherboard) with
each one port. Via VC we present max 4 FlexNic's per port, but for
this server we present 2 FlexNic's per port.
The fun with Linux is that it always sees all FlexNic's devices even
if we configure 2 FlexNics via a VC profile on a port like on this
server.
Michal
^ permalink raw reply
* [PATCH 2/2] Rename 'n' into a longer variable name.
From: Bernd Schubert @ 2011-08-16 10:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110816105648.1805137.35191.stgit@fsdevel3>
When it comes to me variable names consisting of a single letter
should be forbidden by coding style guide lines, as it is rather
difficult to search for single letter, such as 'n'.
Rename struct neighbour *n to dst_neigh
Signed-off-by: Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index fe89c46..189d4cb 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -717,22 +717,22 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh;
- struct neighbour *n = NULL;
+ struct neighbour *dst_neigh = NULL;
unsigned long flags;
if (likely(skb_dst(skb)))
- n = dst_get_neighbour(skb_dst(skb));
+ dst_neigh = dst_get_neighbour(skb_dst(skb));
- if (likely(n)) {
- if (unlikely(!*to_ipoib_neigh(n))) {
+ if (likely(dst_neigh)) {
+ if (unlikely(!*to_ipoib_neigh(dst_neigh))) {
ipoib_path_lookup(skb, dev);
return NETDEV_TX_OK;
}
- neigh = *to_ipoib_neigh(n);
+ neigh = *to_ipoib_neigh(dst_neigh);
if (unlikely((memcmp(&neigh->dgid.raw,
- n->ha + 4,
+ dst_neigh->ha + 4,
sizeof(union ib_gid))) ||
(neigh->dev != dev))) {
spin_lock_irqsave(&priv->lock, flags);
@@ -758,7 +758,8 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
} else if (neigh->ah) {
- ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(n->ha));
+ ipoib_send(dev, skb, neigh->ah,
+ IPOIB_QPN(dst_neigh->ha));
return NETDEV_TX_OK;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] Fix possible Null pointer dereference in ipoib_start_xmit()
From: Bernd Schubert @ 2011-08-16 10:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110816105648.1805137.35191.stgit@fsdevel3>
This will fix https://bugzilla.kernel.org/show_bug.cgi?id=41212
fslab2 login: [ 114.392408] EXT4-fs (sdc): barriers disabled
[ 114.449737] EXT4-fs (sdc): mounted filesystem with writeback data mode.
Opts: journal_async_commit,barrier=0,data=writeback
[ 240.944030] BUG: unable to handle kernel NULL pointer dereference at
0000000000000040
[ 240.948007] IP: [<ffffffffa0366ce9>] ipoib_start_xmit+0x39/0x280 [ib_ipoib]
[...]
[ 240.948007] Call Trace:
[ 240.948007] <IRQ>
[ 240.948007] [<ffffffff812cd5e0>] dev_hard_start_xmit+0x2a0/0x590
[ 240.948007] [<ffffffff8131f680>] ? arp_create+0x70/0x200
[ 240.948007] [<ffffffff812e8e1f>] sch_direct_xmit+0xef/0x1c0
Signed-off-by: Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 43f89ba..fe89c46 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -717,11 +717,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh;
- struct neighbour *n;
+ struct neighbour *n = NULL;
unsigned long flags;
- n = dst_get_neighbour(skb_dst(skb));
- if (likely(skb_dst(skb) && n)) {
+ if (likely(skb_dst(skb)))
+ n = dst_get_neighbour(skb_dst(skb));
+
+ if (likely(n)) {
if (unlikely(!*to_ipoib_neigh(n))) {
ipoib_path_lookup(skb, dev);
return NETDEV_TX_OK;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] 3.1-git ipoib: fix NULL pointer dereference
From: Bernd Schubert @ 2011-08-16 10:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The following series
- fixes a NULL pointer dereferences in ipoib_start_xmit()
- renames variable 'n' to 'dst_neigh' to make the code better readable
Question: I am unsure about the usage of likely() here, as I run into the else branch,
maybe it is not that unlikely and likely() should be removed?
---
Bernd Schubert (2):
Fix possible Null pointer dereference in ipoib_start_xmit()
Rename 'n' into a longer variable name.
drivers/infiniband/ulp/ipoib/ipoib_main.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
--
Bernd Schubert
Fraunhofer ITWM / FhGFS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bug 41212] New: [regression] [3.1-git] ipoib causes kernel panic (NULL pointer dereference)
From: Bernd Schubert @ 2011-08-16 10:34 UTC (permalink / raw)
To: Erez Shitrit
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAAk-MO8EToGY4OhmX1xPN01iAXR9WSsJXWxHG9EVyrSGYP3h5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Erez,
are you sure? Commit 69cce1d1404968f78b177a0314f5822d5afdbbfb is not in
3.0 yet and I also don't see how 3.0 should fail there, as it tests
immediately for "if (likely(skb_dst(skb)"
Thanks,
Bernd
On 08/16/2011 10:06 AM, Erez Shitrit wrote:
> Hi,
> it happened in 3.0 also, if you take the git tag v3.0-rc7 and below it
> will work.
>
> Thanks, Erez
>
> On Mon, Aug 15, 2011 at 6:40 PM, <bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
> <mailto:bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org>> wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=41212
>
> Summary: [regression] [3.1-git] ipoib causes kernel panic
> (NULL
> pointer dereference)
> Product: Networking
> Version: 2.5
> Kernel Version: 3.1-git
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org
> <mailto:acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> ReportedBy: bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org
> <mailto:bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>
> CC: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> <mailto:linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Regression: Yes
>
>
> Each time when I start IPoIB with any 3.1-rcX git version I tested
> so far I get
> a kernel panic. This didn't happen in 3.0 yet.
>
>
> fslab2 login: [ 114.392408] EXT4-fs (sdc): barriers disabled
> [ 114.449737] EXT4-fs (sdc): mounted filesystem with writeback data
> mode.
> Opts: journal_async_commit,barrier=0,data=writeback
> [ 240.944030] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000040
> [ 240.948007] IP: [<ffffffffa0366ce9>] ipoib_start_xmit+0x39/0x280
> [ib_ipoib]
> [ 240.948007] PGD 1f964f067 PUD 1f9bf2067 PMD 0
> [ 240.948007] Oops: 0000 [#1] SMP
> [ 240.948007] CPU 1
> [ 240.948007] Modules linked in: ext4 mbcache jbd2 crc16 nfsd
> ib_umad rdma_ucm
> rdma_cm iw_cm ib_addr ib_uverbs ib_ipoib sg ib_cm ib_sa ipv6 sd_mod
> crc_t10dif
> loop arcmsr md_mod pcspkr ib_mthca ib_mad ib_core 8250_pnp fuse
> af_packet nfs
> lockd fscache auth_rpcgss nfs_acl sunrpc btrfs lzo_decompress
> lzo_compress
> zlib_deflate crc32c libcrc32c crypto_hash crypto_algapi ata_generic
> pata_acpi
> e1000 pata_amd sata_nv libata scsi_mod unix [last unloaded:
> scsi_wait_scan]
> [ 240.948007]
> [ 240.948007] Pid: 0, comm: kworker/0:0 Not tainted 3.1.0-rc2+ #29
> Supermicro
> H8DCE/H8DCE
> [ 240.948007] RIP: 0010:[<ffffffffa0366ce9>] [<ffffffffa0366ce9>]
> ipoib_start_xmit+0x39/0x280 [ib_ipoib]
> [ 240.948007] RSP: 0018:ffff8801ffc03c10 EFLAGS: 00010246
> [ 240.948007] RAX: 0000000000000000 RBX: ffff8801f99ea000 RCX:
> 0000000000004420
> [ 240.948007] RDX: 0000000000000000 RSI: ffff8801f99ea000 RDI:
> ffff8801f9afd500
> [ 240.948007] RBP: ffff8801ffc03c40 R08: ffff8801f940d49c R09:
> ffff8801f9852240
> [ 240.948007] R10: 0000000000000000 R11: 0000000000000020 R12:
> ffff8801f9afd500
> [ 240.948007] R13: 0000000000000050 R14: ffff8801f99ea600 R15:
> ffff8801f9852280
> [ 240.948007] FS: 00007f0b66016700(0000) GS:ffff8801ffc00000(0000)
> knlGS:0000000000000000
> [ 240.948007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 240.948007] CR2: 0000000000000040 CR3: 00000001f9a65000 CR4:
> 00000000000006e0
> [ 240.948007] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 240.948007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 240.948007] Process kworker/0:0 (pid: 0, threadinfo
> ffff8800bfe82000, task
> ffff8800bfe6f1a0)
> [ 240.948007] Stack:
> [ 240.948007] 0000000000000010 ffff8801f9afd500 0000000000004420
> 0000000000000050
> [ 240.948007] ffff8801f99ea000 ffff8801f9852280 ffff8801ffc03ca0
> ffffffff812cd5e0
> [ 240.948007] 0000000000000001 ffffffffa03721a0 ffffffff8131f680
> ffff8801fa110540
> [ 240.948007] Call Trace:
> [ 240.948007] <IRQ>
> [ 240.948007] [<ffffffff812cd5e0>] dev_hard_start_xmit+0x2a0/0x590
> [ 240.948007] [<ffffffff8131f680>] ? arp_create+0x70/0x200
> [ 240.948007] [<ffffffff812e8e1f>] sch_direct_xmit+0xef/0x1c0
> [ 240.948007] [<ffffffff812cd9f9>] dev_queue_xmit+0x129/0x3b0
> [ 240.948007] [<ffffffff8131f853>] arp_send+0x43/0x50
> [ 240.948007] [<ffffffff8131f96b>] arp_solicit+0x10b/0x240
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> <mailto:majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: get_random_int() should use hash[1]
From: George Spelvin @ 2011-08-16 10:30 UTC (permalink / raw)
To: davem, linux, mpm; +Cc: linux-kernel, netdev
In-Reply-To: <20110816.021031.1778295949152117484.davem@davemloft.net>
>From davem@davemloft.net Tue Aug 16 09:10:35 2011
Date: Tue, 16 Aug 2011 02:10:31 -0700 (PDT)
To: linux@horizon.com
Cc: netdev@vger.kernel.org
Subject: Re: get_random_int() should use hash[1]
From: David Miller <davem@davemloft.net>
In-Reply-To: <20110816.020935.717525957035990843.davem@davemloft.net>
References: <20110816090723.18492.qmail@science.horizon.com>
<20110816.020935.717525957035990843.davem@davemloft.net>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (shards.monkeyblade.net [198.137.202.13]); Tue, 16 Aug 2011 02:10:33 -0700 (PDT)
From: David Miller <davem@davemloft.net>
Date: Tue, 16 Aug 2011 02:09:35 -0700 (PDT)
> From: "George Spelvin" <linux@horizon.com>
> Date: 16 Aug 2011 05:07:23 -0400
>
>> Re: commit e997d47bff5a467262ef224b4cf8cbba2d3eceea
>>
>> As long as you're using MD5, you should know that each round only
>> modifies one word of the state. The order is [0], [3], [2], [1],
>> repeating 64 times. Thus, on output, word [1] is the "most hashed"
>> word. If you really wanted word [0], you could just skip the last
>> 3 rounds.
>>
>> It's not really critical, but as long as you're performing the
>> rounds, you might as well use them...
>
> Please provide a proper signoff with your change and properly
> "-p1" base your patch.
Not a problem. This came up in the middle of a rebase operation so I
didn't have a tree immediately at hand to work with.
I'll also get the various uses in net/core/secure_seq.c.
One thing about that commit I'm becoming more concerneed by: I notice that
it eliminates the periodic reseeding of the secret.
While the reduction in the number of random bits was a tradeoff (and it
can be increased to 28 or so), it had two great advantages:
- The usefulness of an attack drops off sharply after 5 minutes (you
can still attack connections established during the attack window,
but then you have to guess how much data has been sent across them).
- An initial shortage of seed entropy does not become a persistent
problem. Note that late_initcall() is still before any device
activity, much less entropy pool re-seeding from init scripts.
Put together, an attacker has the system uptime to try to guess
the low-entropy boot seed. That's not clearly a security improvement.
What I *really* wonder is whether such a change is really -stable
material. Cc: to Matt Mackall for comment.
It seems at least worth figuring out a way to defer seeding until
after /dev/random reseeding. (E.g. until first non-loopback
connection is made.)
(There are also both better and faster algorithms than MD5 for
the job, but that's a separate issue.)
Just for example, as long as you're actually willing to spend more CPU
time, you could do *both*. Compute both a fixed-secret 32-bit value and a
changing-secret 24-bit value and add them together. Best of both worlds.
^ permalink raw reply
* Re: [patch net-next-2.6] bonding: use ndo_change_rx_flags callback
From: Michał Mirosław @ 2011-08-16 10:03 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, fubar, andy
In-Reply-To: <1313487050-4048-1-git-send-email-jpirko@redhat.com>
2011/8/16 Jiri Pirko <jpirko@redhat.com>:
> Benefit from use of ndo_change_rx_flags in handling change of promisc
> and allmulti. No need to store previous state locally.
[...]
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 854aa8d..731763a 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
[...]
> -static void bond_set_multicast_list(struct net_device *bond_dev)
> +static void bond_change_rx_flags(struct net_device *bond_dev, int change)
> {
[...]
> + if (change & IFF_PROMISC)
> + bond_set_promiscuity(bond,
> + bond_dev->flags & IFF_ALLMULTI ? 1 : -1);
Typo: flags & IFF_PROMISC ?
Best Regards,
Michał Mirosław
^ permalink raw reply
* [patch net-next-2.6] bonding: use ndo_change_rx_flags callback
From: Jiri Pirko @ 2011-08-16 9:30 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy
Benefit from use of ndo_change_rx_flags in handling change of promisc
and allmulti. No need to store previous state locally.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/bonding/bond_main.c | 44 ++++++++++++--------------------------
drivers/net/bonding/bonding.h | 1 -
2 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 854aa8d..731763a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3686,44 +3686,27 @@ static bool bond_addr_in_mc_list(unsigned char *addr,
return false;
}
-static void bond_set_multicast_list(struct net_device *bond_dev)
+static void bond_change_rx_flags(struct net_device *bond_dev, int change)
{
struct bonding *bond = netdev_priv(bond_dev);
- struct netdev_hw_addr *ha;
- bool found;
- /*
- * Do promisc before checking multicast_mode
- */
- if ((bond_dev->flags & IFF_PROMISC) && !(bond->flags & IFF_PROMISC))
- /*
- * FIXME: Need to handle the error when one of the multi-slaves
- * encounters error.
- */
- bond_set_promiscuity(bond, 1);
-
-
- if (!(bond_dev->flags & IFF_PROMISC) && (bond->flags & IFF_PROMISC))
- bond_set_promiscuity(bond, -1);
+ if (change & IFF_PROMISC)
+ bond_set_promiscuity(bond,
+ bond_dev->flags & IFF_ALLMULTI ? 1 : -1);
+ if (change & IFF_ALLMULTI)
+ bond_set_allmulti(bond,
+ bond_dev->flags & IFF_ALLMULTI ? 1 : -1);
+}
- /* set allmulti flag to slaves */
- if ((bond_dev->flags & IFF_ALLMULTI) && !(bond->flags & IFF_ALLMULTI))
- /*
- * FIXME: Need to handle the error when one of the multi-slaves
- * encounters error.
- */
- bond_set_allmulti(bond, 1);
-
-
- if (!(bond_dev->flags & IFF_ALLMULTI) && (bond->flags & IFF_ALLMULTI))
- bond_set_allmulti(bond, -1);
-
+static void bond_set_multicast_list(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct netdev_hw_addr *ha;
+ bool found;
read_lock(&bond->lock);
- bond->flags = bond_dev->flags;
-
/* looking for addresses to add to slaves' mc list */
netdev_for_each_mc_addr(ha, bond_dev) {
found = bond_addr_in_mc_list(ha->addr, &bond->mc_list,
@@ -4282,6 +4265,7 @@ static const struct net_device_ops bond_netdev_ops = {
.ndo_select_queue = bond_select_queue,
.ndo_get_stats64 = bond_get_stats,
.ndo_do_ioctl = bond_do_ioctl,
+ .ndo_change_rx_flags = bond_change_rx_flags,
.ndo_set_multicast_list = bond_set_multicast_list,
.ndo_change_mtu = bond_change_mtu,
.ndo_set_mac_address = bond_set_mac_address,
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 43526a2..e823366 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -234,7 +234,6 @@ struct bonding {
struct netdev_hw_addr_list mc_list;
int (*xmit_hash_policy)(struct sk_buff *, int);
__be32 master_ip;
- u16 flags;
u16 rr_tx_counter;
struct ad_bond_info ad_info;
struct alb_bond_info alb_info;
--
1.7.6
^ permalink raw reply related
* Re: get_random_int() should use hash[1]
From: David Miller @ 2011-08-16 9:10 UTC (permalink / raw)
To: linux; +Cc: netdev
In-Reply-To: <20110816.020935.717525957035990843.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 16 Aug 2011 02:09:35 -0700 (PDT)
> From: "George Spelvin" <linux@horizon.com>
> Date: 16 Aug 2011 05:07:23 -0400
>
>> Re: commit e997d47bff5a467262ef224b4cf8cbba2d3eceea
>>
>> As long as you're using MD5, you should know that each round only
>> modifies one word of the state. The order is [0], [3], [2], [1],
>> repeating 64 times. Thus, on output, word [1] is the "most hashed"
>> word. If you really wanted word [0], you could just skip the last
>> 3 rounds.
>>
>> It's not really critical, but as long as you're performing the
>> rounds, you might as well use them...
>
> Please provide a proper signoff with your change and properly
> "-p1" base your patch.
>
> Thanks.
Also this change is of interest to, and effects, folks outside of
networking. So probably want to CC: linux-kernel when you respin
this.
^ 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