* patch kobject-send-hotplug-events-in-all-network-namespaces.patch added to gregkh-2.6 tree
From: gregkh @ 2010-05-20 18:10 UTC (permalink / raw)
To: ebiederm, bcrl, cornelia.huck, davem, eric.dumazet, gregkh,
kay.sievers, netdev, serue
In-Reply-To: <1273019809-16472-1-git-send-email-ebiederm@xmission.com>
This is a note to let you know that I've just added the patch titled
Subject: kobject: Send hotplug events in all network namespaces
to my gregkh-2.6 tree. Its filename is
kobject-send-hotplug-events-in-all-network-namespaces.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From ebiederm@xmission.com Thu May 20 10:40:26 2010
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Tue, 4 May 2010 17:36:44 -0700
Subject: kobject: Send hotplug events in all network namespaces
To: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>, Cornelia Huck <cornelia.huck@de.ibm.com>, Eric Dumazet <eric.dumazet@gmail.com>, Benjamin LaHaise <bcrl@lhnet.ca>, Serge Hallyn <serue@us.ibm.com>, <netdev@vger.kernel.org>, David Miller <davem@davemloft.net>, "Eric W. Biederman" <ebiederm@xmission.com>
Message-ID: <1273019809-16472-1-git-send-email-ebiederm@xmission.com>
From: Eric W. Biederman <ebiederm@xmission.com>
Open a copy of the uevent kernel socket in each network
namespace so we can send uevents in all network namespaces.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
lib/kobject_uevent.c | 68 +++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 60 insertions(+), 8 deletions(-)
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -24,13 +24,19 @@
#include <linux/skbuff.h>
#include <linux/netlink.h>
#include <net/sock.h>
+#include <net/net_namespace.h>
u64 uevent_seqnum;
char uevent_helper[UEVENT_HELPER_PATH_LEN] = CONFIG_UEVENT_HELPER_PATH;
static DEFINE_SPINLOCK(sequence_lock);
-#if defined(CONFIG_NET)
-static struct sock *uevent_sock;
+#ifdef CONFIG_NET
+struct uevent_sock {
+ struct list_head list;
+ struct sock *sk;
+};
+static LIST_HEAD(uevent_sock_list);
+static DEFINE_MUTEX(uevent_sock_mutex);
#endif
/* the strings here must match the enum in include/linux/kobject.h */
@@ -100,6 +106,9 @@ int kobject_uevent_env(struct kobject *k
u64 seq;
int i = 0;
int retval = 0;
+#ifdef CONFIG_NET
+ struct uevent_sock *ue_sk;
+#endif
pr_debug("kobject: '%s' (%p): %s\n",
kobject_name(kobj), kobj, __func__);
@@ -211,7 +220,9 @@ int kobject_uevent_env(struct kobject *k
#if defined(CONFIG_NET)
/* send netlink message */
- if (uevent_sock) {
+ mutex_lock(&uevent_sock_mutex);
+ list_for_each_entry(ue_sk, &uevent_sock_list, list) {
+ struct sock *uevent_sock = ue_sk->sk;
struct sk_buff *skb;
size_t len;
@@ -241,6 +252,7 @@ int kobject_uevent_env(struct kobject *k
} else
retval = -ENOMEM;
}
+ mutex_unlock(&uevent_sock_mutex);
#endif
/* call uevent_helper, usually only enabled during early boot */
@@ -320,18 +332,58 @@ int add_uevent_var(struct kobj_uevent_en
EXPORT_SYMBOL_GPL(add_uevent_var);
#if defined(CONFIG_NET)
-static int __init kobject_uevent_init(void)
+static int uevent_net_init(struct net *net)
{
- uevent_sock = netlink_kernel_create(&init_net, NETLINK_KOBJECT_UEVENT,
- 1, NULL, NULL, THIS_MODULE);
- if (!uevent_sock) {
+ struct uevent_sock *ue_sk;
+
+ ue_sk = kzalloc(sizeof(*ue_sk), GFP_KERNEL);
+ if (!ue_sk)
+ return -ENOMEM;
+
+ ue_sk->sk = netlink_kernel_create(net, NETLINK_KOBJECT_UEVENT,
+ 1, NULL, NULL, THIS_MODULE);
+ if (!ue_sk->sk) {
printk(KERN_ERR
"kobject_uevent: unable to create netlink socket!\n");
return -ENODEV;
}
- netlink_set_nonroot(NETLINK_KOBJECT_UEVENT, NL_NONROOT_RECV);
+ mutex_lock(&uevent_sock_mutex);
+ list_add_tail(&ue_sk->list, &uevent_sock_list);
+ mutex_unlock(&uevent_sock_mutex);
return 0;
}
+static void uevent_net_exit(struct net *net)
+{
+ struct uevent_sock *ue_sk;
+
+ mutex_lock(&uevent_sock_mutex);
+ list_for_each_entry(ue_sk, &uevent_sock_list, list) {
+ if (sock_net(ue_sk->sk) == net)
+ goto found;
+ }
+ mutex_unlock(&uevent_sock_mutex);
+ return;
+
+found:
+ list_del(&ue_sk->list);
+ mutex_unlock(&uevent_sock_mutex);
+
+ netlink_kernel_release(ue_sk->sk);
+ kfree(ue_sk);
+}
+
+static struct pernet_operations uevent_net_ops = {
+ .init = uevent_net_init,
+ .exit = uevent_net_exit,
+};
+
+static int __init kobject_uevent_init(void)
+{
+ netlink_set_nonroot(NETLINK_KOBJECT_UEVENT, NL_NONROOT_RECV);
+ return register_pernet_subsys(&uevent_net_ops);
+}
+
+
postcore_initcall(kobject_uevent_init);
#endif
^ permalink raw reply
* Re: bnx2x + SFP+ DA/2.6.33.3: Got bad status 0x0 when reading from SFP+ EEPROM -> SFP+ module is not initialized
From: Eilon Greenstein @ 2010-05-20 17:49 UTC (permalink / raw)
To: Krzysztof Olędzki; +Cc: Michael Chan, netdev@vger.kernel.org
In-Reply-To: <4BF56CA6.8080306@ans.pl>
On Thu, 2010-05-20 at 10:08 -0700, Krzysztof Olędzki wrote:
> Hello,
>
> I would like to connect a dual port SFP+ NetXtreme II BCM57711
> 10-Gigabit NIC to a HP J9309A ProCurve 4-Port 10GbE SFP+ zl Module
> using a HP ProCurve 10-GbE SFP+ 7m Direct Attach Cable (J9285B).
>
> Unfortuantely, it does not work. :( After connecting the switch and
> the server together and loading the bnx2x module the switch logs:
>
> I 05/20/10 18:32:23 ports: port E4 is Blocked by STP
> I 05/20/10 18:32:23 ports: port E4 is now on-line
>
> Here is the dmesg output from the server:
>
> Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.52.1-5 (2009/11/09)
> bnx2x 0000:04:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
> bnx2x 0000:04:00.0: setting latency timer to 64
> bnx2x: part number 394D4342-31373735-31314131-473331
> bnx2x: Loading bnx2x-e1h-5.2.7.0.fw
> bnx2x 0000:04:00.0: firmware: requesting bnx2x-e1h-5.2.7.0.fw
> eth4: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem dc000000, IRQ 38, node addr 00:10:18:5f:e4:b4
> bnx2x 0000:04:00.1: PCI INT B -> GSI 45 (level, low) -> IRQ 45
> bnx2x 0000:04:00.1: setting latency timer to 64
> bnx2x: part number 394D4342-31373735-31314131-473331
> bnx2x: Loading bnx2x-e1h-5.2.7.0.fw
> bnx2x 0000:04:00.1: firmware: requesting bnx2x-e1h-5.2.7.0.fw
> eth5: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem dd000000, IRQ 45, node addr 00:10:18:5f:e4:b6
> bnx2x 0000:04:00.0: irq 97 for MSI/MSI-X
> bnx2x 0000:04:00.0: irq 98 for MSI/MSI-X
> bnx2x 0000:04:00.0: irq 99 for MSI/MSI-X
> bnx2x 0000:04:00.0: irq 100 for MSI/MSI-X
> bnx2x 0000:04:00.0: irq 101 for MSI/MSI-X
> bnx2x 0000:04:00.0: irq 102 for MSI/MSI-X
> bnx2x: eth4: using MSI-X IRQs: sp 97 fp[0] 99 ... fp[3] 102
> ADDRCONF(NETDEV_UP): eth4: link is not ready
> bnx2x 0000:04:00.1: irq 103 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 104 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 105 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 106 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 107 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 108 for MSI/MSI-X
> bnx2x: eth5: using MSI-X IRQs: sp 103 fp[0] 105 ... fp[3] 108
> ADDRCONF(NETDEV_UP): eth5: link is not ready
> bnx2x: eth5 NIC Link is Down
> bnx2x: eth5 NIC Link is Down
>
> Loading the driver with debug mode enabled (modprobe bnx2x debug=0x20004) I got:
Thank you for this debug information! You saved one email round trip :)
However, I still need some more information about the FW version and
nvram settings. Can you please send me the output of ethtool -i and
ethtool -e? Since ethtool -e is quite long, it is best to send it as an
attached file.
>
> bnx2x 0000:04:00.1: irq 103 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 104 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 105 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 106 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 107 for MSI/MSI-X
> bnx2x 0000:04:00.1: irq 108 for MSI/MSI-X
> bnx2x: eth5: using MSI-X IRQs: sp 103 fp[0] 105 ... fp[3] 108
> [bnx2x_nic_load:7524(eth5)]pmf 1
> [bnx2x_link_reset:6171(eth5)]Resetting the link of port 1
> [bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
> [bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
> [bnx2x_stats_init:4597(eth5)]port_stx 0xa72f4 func_stx 0x0
> [bnx2x_phy_init:5966(eth5)]Phy Initialization started
> [bnx2x_phy_init:5968(eth5)]req_speed 10000, req_flowctrl 0
> [bnx2x_emac_init:255(eth5)]EMAC reset reg is 1024
> [bnx2x_phy_deassert:534(eth5)]bnx2x_phy_deassert:XGXS
> [bnx2x_phy_init:6140(eth5)]Phy address = 0x1
> [bnx2x_ext_phy_reset:2092(eth5)]Port 1: bnx2x_ext_phy_reset
> [bnx2x_calc_ieee_aneg_adv:1383(eth5)]ieee_fc = 0x1a0
> [bnx2x_ext_phy_init:3672(eth5)]control reg 0x2040 (after 0 ms)
> [bnx2x_ext_phy_init:4136(eth5)]Initializing BCM8727
> [bnx2x_ext_phy_init:4285(eth5)]Setting TX_CTRL1 0xc000,TX_CTRL2 0x40
> [bnx2x_link_int_enable:5338(eth5)]enabled XGXS interrupt
> [bnx2x_link_int_enable:5345(eth5)]enabled external phy int
> [bnx2x_link_int_enable:5366(eth5)]port 1, is_xgxs 1, int_status 0x0
> [bnx2x_link_int_enable:5370(eth5)] int_mask 0x3c8001, MI_INT 1, SERDES_LINK 0
> [bnx2x_link_int_enable:5373(eth5)] 10G 0, XGXS_LINK 0
> [bnx2x_stats_handle:4469(eth5)]state 0 -> event 3 -> state 0
> [bnx2x_link_update:6375(eth5)]port 1, XGXS?1, int_status 0x0
> [bnx2x_link_update:6383(eth5)]int_mask 0x0 MI_INT 1, SERDES_LINK 0
> [bnx2x_link_update:6387(eth5)] 10G 0, XGXS_LINK 0
> [bnx2x_ext_phy_is_link_up:4809(eth5)]8727 RX_ALARM_STATUS 0x439
> ADDRCONF(NETDEV_UP): eth5: link is not ready
> [bnx2x_ext_phy_is_link_up:4819(eth5)]8727 LASI status 0x6
> [bnx2x_8727_handle_mod_abs:4622(eth5)]MOD_ABS indication show module is present
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
> [bnx2x_8727_handle_mod_abs:4660(eth5)]SFP+ module is not initialized
> [bnx2x_8727_handle_mod_abs:4664(eth5)]8727 RX_ALARM_STATUS 0x438
> [bnx2x_ext_phy_is_link_up:4916(eth5)]Tx is disabled
> [bnx2x_link_settings_status:1958(eth5)]phy link down
> [bnx2x_link_settings_status:1976(eth5)]gp_status 0x208 phy_link_up 0 line_speed 2710
> [bnx2x_link_settings_status:1980(eth5)]duplex 1 flow_ctrl 0x400 autoneg 0x0
> [bnx2x_link_settings_status:1981(eth5)]link_status 0x0
> [bnx2x_update_link_down:6285(eth5)]Port 1: Link is down
> [bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
> [bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
> bnx2x: eth5 NIC Link is Down
> [bnx2x_stats_handle:4469(eth5)]state 0 -> event 3 -> state 0
> [bnx2x_link_update:6375(eth5)]port 1, XGXS?1, int_status 0x0
> [bnx2x_link_update:6383(eth5)]int_mask 0x0 MI_INT 1, SERDES_LINK 0
> [bnx2x_link_update:6387(eth5)] 10G 0, XGXS_LINK 0
> [bnx2x_ext_phy_is_link_up:4809(eth5)]8727 RX_ALARM_STATUS 0x41c
> [bnx2x_ext_phy_is_link_up:4819(eth5)]8727 LASI status 0x2
> [bnx2x_ext_phy_is_link_up:4916(eth5)]Tx is disabled
> [bnx2x_link_settings_status:1958(eth5)]phy link down
> [bnx2x_link_settings_status:1976(eth5)]gp_status 0x208 phy_link_up 0 line_speed 0
> [bnx2x_link_settings_status:1980(eth5)]duplex 1 flow_ctrl 0x400 autoneg 0x0
> [bnx2x_link_settings_status:1981(eth5)]link_status 0x0
> [bnx2x_update_link_down:6285(eth5)]Port 1: Link is down
> [bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
> [bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
> bnx2x: eth5 NIC Link is Down
>
> # uname -r
> 2.6.33.3
>
> Is there something I can do to fix this? Like for example kernel/driver or the firmware upgrade?
>
> Best regards,
>
> Krzysztof Olędzki
>
I assume it is the same when you unplug the module and insert it again
when the driver is already up and running, right? I also assumed you
verified it is firmly plugged in (no offense, bug I had to ask...)
Eilon
^ permalink raw reply
* Re: [PATCH 0/6] tagged sysfs support
From: Greg KH @ 2010-05-20 17:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg Kroah-Hartman, Kay Sievers, linux-kernel, Tejun Heo,
Cornelia Huck, linux-fsdevel, Eric Dumazet, Benjamin LaHaise,
Serge Hallyn, netdev
In-Reply-To: <m1fx3hk6gw.fsf@fess.ebiederm.org>
On Tue, Mar 30, 2010 at 11:30:23AM -0700, Eric W. Biederman wrote:
>
> The main short coming of using multiple network namespaces today
> is that only network devices for the primary network namespaces
> can be put in the kobject layer and sysfs.
>
> This is essentially the earlier version of this patchset that was
> reviewed before, just now on top of a version of sysfs that doesn't
> need cleanup patches to support it.
>
> I have been running these patches in some form for well over a
> year so the basics should at least be solid.
>
> This patchset is currently against 2.6.34-rc1.
>
> This patchset is just the basic infrastructure a couple of more pretty
> trivial patches are needed to actually enable network namespaces to use this.
> My current plan is to send those after these patches have made it through
> review.
All queued up now.
thanks,
greg k-h
^ permalink raw reply
* Re: tun: Use netif_receive_skb instead of netif_rx
From: Neil Horman @ 2010-05-20 17:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric Dumazet, David Miller, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100520054642.GA7836@gondor.apana.org.au>
On Thu, May 20, 2010 at 03:46:42PM +1000, Herbert Xu wrote:
> On Thu, May 20, 2010 at 07:36:19AM +0200, Eric Dumazet wrote:
> >
> > I am ok with any kind of clarification, if its really documented as
> > such, not as indirect effects of changes.
>
> But I did document this semantic change, quite verbosely too
> at that :)
>
> > Right now, I am not sure classification is performed by the current
> > process/cpu. Our queue handling can process packets queued by other cpus
> > while we own the queue (__QDISC_STATE_RUNNING,) anyway.
>
> Classification should be done when the packet is enqueued. So
> you shouldn't really see other people's traffic.
>
> The original requeueing would have broken this too, but that is
> no longer with us :)
>
> In my original submission I forgot to mention the case of TCP
> transmission triggered by an incoming ACK, which is really the
> same case as this.
>
> So let me take this opportunity to resubmit with an updated
> description:
>
> cls_cgroup: Store classid in struct sock
>
> Up until now cls_cgroup has relied on fetching the classid out of
> the current executing thread. This runs into trouble when a packet
> processing is delayed in which case it may execute out of another
> thread's context.
>
> Furthermore, even when a packet is not delayed we may fail to
> classify it if soft IRQs have been disabled, because this scenario
> is indistinguishable from one where a packet unrelated to the
> current thread is processed by a real soft IRQ.
>
> In fact, the current semantics is inherently broken, as a single
> skb may be constructed out of the writes of two different tasks.
> A different manifestation of this problem is when the TCP stack
> transmits in response of an incoming ACK. This is currently
> unclassified.
>
> As we already have a concept of packet ownership for accounting
> purposes in the skb->sk pointer, this is a natural place to store
> the classid in a persistent manner.
>
> This patch adds the cls_cgroup classid in struct sock, filling up
> an existing hole on 64-bit :)
>
> The value is set at socket creation time. So all sockets created
> via socket(2) automatically gains the ID of the thread creating it.
> Now you may argue that this may not be the same as the thread that
> is sending the packet. However, we already have a precedence where
> an fd is passed to a different thread, its security property is
> inherited. In this case, inheriting the classid of the thread
> creating the socket is also the logical thing to do.
>
> For sockets created on inbound connections through accept(2), we
> inherit the classid of the original listening socket through
> sk_clone, possibly preceding the actual accept(2) call.
>
> In order to minimise risks, I have not made this the authoritative
> classid. For now it is only used as a backup when we execute
> with soft IRQs disabled. Once we're completely happy with its
> semantics we can use it as the sole classid.
>
> Footnote: I have rearranged the error path on cls_group module
> creation. If we didn't do this, then there is a window where
> someone could create a tc rule using cls_group before the cgroup
> subsystem has been registered.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 8f78073..63c5036 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -410,6 +410,12 @@ struct cgroup_scanner {
> void *data;
> };
>
> +struct cgroup_cls_state
> +{
> + struct cgroup_subsys_state css;
> + u32 classid;
> +};
> +
> /*
> * Add a new file to the given cgroup directory. Should only be
> * called by subsystems from within a populate() method
> @@ -515,6 +521,10 @@ struct cgroup_subsys {
> struct module *module;
> };
>
> +#ifndef CONFIG_NET_CLS_CGROUP
> +extern int net_cls_subsys_id;
> +#endif
> +
> #define SUBSYS(_x) extern struct cgroup_subsys _x ## _subsys;
> #include <linux/cgroup_subsys.h>
> #undef SUBSYS
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 1ad6435..361a5dc 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -307,7 +307,7 @@ struct sock {
> void *sk_security;
> #endif
> __u32 sk_mark;
> - /* XXX 4 bytes hole on 64 bit */
> + u32 sk_classid;
> void (*sk_state_change)(struct sock *sk);
> void (*sk_data_ready)(struct sock *sk, int bytes);
> void (*sk_write_space)(struct sock *sk);
> diff --git a/net/core/sock.c b/net/core/sock.c
> index c5812bb..70bc529 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -110,6 +110,7 @@
> #include <linux/tcp.h>
> #include <linux/init.h>
> #include <linux/highmem.h>
> +#include <linux/cgroup.h>
>
> #include <asm/uaccess.h>
> #include <asm/system.h>
> @@ -217,6 +218,32 @@ __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
> int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
> EXPORT_SYMBOL(sysctl_optmem_max);
>
> +#ifdef CONFIG_NET_CLS_CGROUP
> +static inline u32 task_cls_classid(struct task_struct *p)
> +{
> + return container_of(task_subsys_state(p, net_cls_subsys_id),
> + struct cgroup_cls_state, css).classid;
> +}
> +#else
> +int net_cls_subsys_id = -1;
> +EXPORT_SYMBOL_GPL(net_cls_subsys_id);
> +
> +static inline u32 task_cls_classid(struct task_struct *p)
> +{
> + int id;
> + u32 classid;
> +
> + rcu_read_lock();
> + id = rcu_dereference(net_cls_subsys_id);
> + if (id >= 0)
> + classid = container_of(task_subsys_state(p, id),
> + struct cgroup_cls_state, css)->classid;
> + rcu_read_unlock();
> +
> + return classid;
> +}
> +#endif
> +
> static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
> {
> struct timeval tv;
> @@ -1064,6 +1091,9 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
> sock_lock_init(sk);
> sock_net_set(sk, get_net(net));
> atomic_set(&sk->sk_wmem_alloc, 1);
> +
> + if (!in_interrupt())
> + sk->sk_classid = task_cls_classid(current);
> }
>
> return sk;
> diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
> index 2211803..32c1296 100644
> --- a/net/sched/cls_cgroup.c
> +++ b/net/sched/cls_cgroup.c
> @@ -16,14 +16,10 @@
> #include <linux/errno.h>
> #include <linux/skbuff.h>
> #include <linux/cgroup.h>
> +#include <linux/rcupdate.h>
> #include <net/rtnetlink.h>
> #include <net/pkt_cls.h>
> -
> -struct cgroup_cls_state
> -{
> - struct cgroup_subsys_state css;
> - u32 classid;
> -};
> +#include <net/sock.h>
>
> static struct cgroup_subsys_state *cgrp_create(struct cgroup_subsys *ss,
> struct cgroup *cgrp);
> @@ -112,6 +108,10 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
> struct cls_cgroup_head *head = tp->root;
> u32 classid;
>
> + rcu_read_lock();
> + classid = task_cls_state(current)->classid;
> + rcu_read_unlock();
> +
> /*
> * Due to the nature of the classifier it is required to ignore all
> * packets originating from softirq context as accessing `current'
> @@ -122,12 +122,12 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
> * calls by looking at the number of nested bh disable calls because
> * softirqs always disables bh.
> */
> - if (softirq_count() != SOFTIRQ_OFFSET)
> - return -1;
> -
> - rcu_read_lock();
> - classid = task_cls_state(current)->classid;
> - rcu_read_unlock();
> + if (softirq_count() != SOFTIRQ_OFFSET) {
> + /* If there is an sk_classid we'll use that. */
> + if (!skb->sk)
> + return -1;
> + classid = skb->sk->sk_classid;
> + }
>
> if (!classid)
> return -1;
> @@ -289,18 +289,35 @@ static struct tcf_proto_ops cls_cgroup_ops __read_mostly = {
>
> static int __init init_cgroup_cls(void)
> {
> - int ret = register_tcf_proto_ops(&cls_cgroup_ops);
> - if (ret)
> - return ret;
> + int ret;
> +
> ret = cgroup_load_subsys(&net_cls_subsys);
> if (ret)
> - unregister_tcf_proto_ops(&cls_cgroup_ops);
> + goto out;
> +
> +#ifndef CONFIG_NET_CLS_CGROUP
> + /* We can't use rcu_assign_pointer because this is an int. */
> + smp_wmb();
> + net_cls_subsys_id = net_cls_subsys.subsys_id;
> +#endif
> +
> + ret = register_tcf_proto_ops(&cls_cgroup_ops);
> + if (ret)
> + cgroup_unload_subsys(&net_cls_subsys);
> +
> +out:
> return ret;
> }
>
> static void __exit exit_cgroup_cls(void)
> {
> unregister_tcf_proto_ops(&cls_cgroup_ops);
> +
> +#ifndef CONFIG_NET_CLS_CGROUP
> + net_cls_subsys_id = -1;
> + synchronize_rcu();
> +#endif
> +
> cgroup_unload_subsys(&net_cls_subsys);
> }
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> 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
>
So, I'm testing this patch out now, and unfotunately it doesn't seem to be
working. Every frame seems to be holding a classid of 0. Trying to figure out
why now.
Neil
^ permalink raw reply
* bnx2x + SFP+ DA/2.6.33.3: Got bad status 0x0 when reading from SFP+ EEPROM -> SFP+ module is not initialized
From: Krzysztof Olędzki @ 2010-05-20 17:08 UTC (permalink / raw)
To: Eilon Greenstein, Michael Chan; +Cc: netdev
Hello,
I would like to connect a dual port SFP+ NetXtreme II BCM57711
10-Gigabit NIC to a HP J9309A ProCurve 4-Port 10GbE SFP+ zl Module
using a HP ProCurve 10-GbE SFP+ 7m Direct Attach Cable (J9285B).
Unfortuantely, it does not work. :( After connecting the switch and
the server together and loading the bnx2x module the switch logs:
I 05/20/10 18:32:23 ports: port E4 is Blocked by STP
I 05/20/10 18:32:23 ports: port E4 is now on-line
Here is the dmesg output from the server:
Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.52.1-5 (2009/11/09)
bnx2x 0000:04:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
bnx2x 0000:04:00.0: setting latency timer to 64
bnx2x: part number 394D4342-31373735-31314131-473331
bnx2x: Loading bnx2x-e1h-5.2.7.0.fw
bnx2x 0000:04:00.0: firmware: requesting bnx2x-e1h-5.2.7.0.fw
eth4: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem dc000000, IRQ 38, node addr 00:10:18:5f:e4:b4
bnx2x 0000:04:00.1: PCI INT B -> GSI 45 (level, low) -> IRQ 45
bnx2x 0000:04:00.1: setting latency timer to 64
bnx2x: part number 394D4342-31373735-31314131-473331
bnx2x: Loading bnx2x-e1h-5.2.7.0.fw
bnx2x 0000:04:00.1: firmware: requesting bnx2x-e1h-5.2.7.0.fw
eth5: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem dd000000, IRQ 45, node addr 00:10:18:5f:e4:b6
bnx2x 0000:04:00.0: irq 97 for MSI/MSI-X
bnx2x 0000:04:00.0: irq 98 for MSI/MSI-X
bnx2x 0000:04:00.0: irq 99 for MSI/MSI-X
bnx2x 0000:04:00.0: irq 100 for MSI/MSI-X
bnx2x 0000:04:00.0: irq 101 for MSI/MSI-X
bnx2x 0000:04:00.0: irq 102 for MSI/MSI-X
bnx2x: eth4: using MSI-X IRQs: sp 97 fp[0] 99 ... fp[3] 102
ADDRCONF(NETDEV_UP): eth4: link is not ready
bnx2x 0000:04:00.1: irq 103 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 104 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 105 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 106 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 107 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 108 for MSI/MSI-X
bnx2x: eth5: using MSI-X IRQs: sp 103 fp[0] 105 ... fp[3] 108
ADDRCONF(NETDEV_UP): eth5: link is not ready
bnx2x: eth5 NIC Link is Down
bnx2x: eth5 NIC Link is Down
Loading the driver with debug mode enabled (modprobe bnx2x debug=0x20004) I got:
bnx2x 0000:04:00.1: irq 103 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 104 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 105 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 106 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 107 for MSI/MSI-X
bnx2x 0000:04:00.1: irq 108 for MSI/MSI-X
bnx2x: eth5: using MSI-X IRQs: sp 103 fp[0] 105 ... fp[3] 108
[bnx2x_nic_load:7524(eth5)]pmf 1
[bnx2x_link_reset:6171(eth5)]Resetting the link of port 1
[bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
[bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
[bnx2x_stats_init:4597(eth5)]port_stx 0xa72f4 func_stx 0x0
[bnx2x_phy_init:5966(eth5)]Phy Initialization started
[bnx2x_phy_init:5968(eth5)]req_speed 10000, req_flowctrl 0
[bnx2x_emac_init:255(eth5)]EMAC reset reg is 1024
[bnx2x_phy_deassert:534(eth5)]bnx2x_phy_deassert:XGXS
[bnx2x_phy_init:6140(eth5)]Phy address = 0x1
[bnx2x_ext_phy_reset:2092(eth5)]Port 1: bnx2x_ext_phy_reset
[bnx2x_calc_ieee_aneg_adv:1383(eth5)]ieee_fc = 0x1a0
[bnx2x_ext_phy_init:3672(eth5)]control reg 0x2040 (after 0 ms)
[bnx2x_ext_phy_init:4136(eth5)]Initializing BCM8727
[bnx2x_ext_phy_init:4285(eth5)]Setting TX_CTRL1 0xc000,TX_CTRL2 0x40
[bnx2x_link_int_enable:5338(eth5)]enabled XGXS interrupt
[bnx2x_link_int_enable:5345(eth5)]enabled external phy int
[bnx2x_link_int_enable:5366(eth5)]port 1, is_xgxs 1, int_status 0x0
[bnx2x_link_int_enable:5370(eth5)] int_mask 0x3c8001, MI_INT 1, SERDES_LINK 0
[bnx2x_link_int_enable:5373(eth5)] 10G 0, XGXS_LINK 0
[bnx2x_stats_handle:4469(eth5)]state 0 -> event 3 -> state 0
[bnx2x_link_update:6375(eth5)]port 1, XGXS?1, int_status 0x0
[bnx2x_link_update:6383(eth5)]int_mask 0x0 MI_INT 1, SERDES_LINK 0
[bnx2x_link_update:6387(eth5)] 10G 0, XGXS_LINK 0
[bnx2x_ext_phy_is_link_up:4809(eth5)]8727 RX_ALARM_STATUS 0x439
ADDRCONF(NETDEV_UP): eth5: link is not ready
[bnx2x_ext_phy_is_link_up:4819(eth5)]8727 LASI status 0x6
[bnx2x_8727_handle_mod_abs:4622(eth5)]MOD_ABS indication show module is present
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_read_sfp_module_eeprom:2818(eth5)]Got bad status 0x0 when reading from SFP+ EEPROM
[bnx2x_8727_handle_mod_abs:4660(eth5)]SFP+ module is not initialized
[bnx2x_8727_handle_mod_abs:4664(eth5)]8727 RX_ALARM_STATUS 0x438
[bnx2x_ext_phy_is_link_up:4916(eth5)]Tx is disabled
[bnx2x_link_settings_status:1958(eth5)]phy link down
[bnx2x_link_settings_status:1976(eth5)]gp_status 0x208 phy_link_up 0 line_speed 2710
[bnx2x_link_settings_status:1980(eth5)]duplex 1 flow_ctrl 0x400 autoneg 0x0
[bnx2x_link_settings_status:1981(eth5)]link_status 0x0
[bnx2x_update_link_down:6285(eth5)]Port 1: Link is down
[bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
[bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
bnx2x: eth5 NIC Link is Down
[bnx2x_stats_handle:4469(eth5)]state 0 -> event 3 -> state 0
[bnx2x_link_update:6375(eth5)]port 1, XGXS?1, int_status 0x0
[bnx2x_link_update:6383(eth5)]int_mask 0x0 MI_INT 1, SERDES_LINK 0
[bnx2x_link_update:6387(eth5)] 10G 0, XGXS_LINK 0
[bnx2x_ext_phy_is_link_up:4809(eth5)]8727 RX_ALARM_STATUS 0x41c
[bnx2x_ext_phy_is_link_up:4819(eth5)]8727 LASI status 0x2
[bnx2x_ext_phy_is_link_up:4916(eth5)]Tx is disabled
[bnx2x_link_settings_status:1958(eth5)]phy link down
[bnx2x_link_settings_status:1976(eth5)]gp_status 0x208 phy_link_up 0 line_speed 0
[bnx2x_link_settings_status:1980(eth5)]duplex 1 flow_ctrl 0x400 autoneg 0x0
[bnx2x_link_settings_status:1981(eth5)]link_status 0x0
[bnx2x_update_link_down:6285(eth5)]Port 1: Link is down
[bnx2x_set_led:5804(eth5)]bnx2x_set_led: port 1, mode 0
[bnx2x_set_led:5806(eth5)]speed 0x0, hw_led_mode 0x1
bnx2x: eth5 NIC Link is Down
# uname -r
2.6.33.3
Is there something I can do to fix this? Like for example kernel/driver or the firmware upgrade?
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* [PATCH][VHOST] fix race with guest on multi-buffer used buffer updates
From: David L Stevens @ 2010-05-20 16:58 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm
[for Michael Tsirkin's vhost development git tree]
This patch fixes a race between guest and host when
adding used buffers wraps the ring. Without it, guests
can see partial packets before num_buffers is set in
the vnet header.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 7f2568d..74790ab 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1065,14 +1065,6 @@ static int __vhost_add_used_n(struct vhost_virtqueue *vq,
vq_err(vq, "Failed to write used");
return -EFAULT;
}
- /* Make sure buffer is written before we update index. */
- smp_wmb();
- if (put_user(vq->last_used_idx + count, &vq->used->idx)) {
- vq_err(vq, "Failed to increment used idx");
- return -EFAULT;
- }
- if (unlikely(vq->log_used))
- vhost_log_used(vq, used);
vq->last_used_idx += count;
return 0;
}
@@ -1093,7 +1085,17 @@ int vhost_add_used_n(struct vhost_virtqueue *vq, struct vring_used_elem *heads,
heads += n;
count -= n;
}
- return __vhost_add_used_n(vq, heads, count);
+ r = __vhost_add_used_n(vq, heads, count);
+
+ /* Make sure buffer is written before we update index. */
+ smp_wmb();
+ if (put_user(vq->last_used_idx, &vq->used->idx)) {
+ vq_err(vq, "Failed to increment used idx");
+ return -EFAULT;
+ }
+ if (unlikely(vq->log_used))
+ vhost_log_used(vq, vq->used->ring + start);
+ return r;
}
/* This actually signals the guest, using eventfd. */
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2010-05-20 16:31 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20100519.193426.09743465.davem@davemloft.net>
On Wed, 19 May 2010, David Miller wrote:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6.git master
>
> Ping?
I'm still merging. I don't want to merge everything in one day, because I
want to encourage people that do nightly snapshots or find problems
quickly, and not force them to bisect through multiple thousand commits.
So I tend to try to merge in chunks.
Linus
^ permalink raw reply
* [PATCH 3/3] netfilter: fix description of expected checkentry return code on xt_target
From: kaber @ 2010-05-20 16:00 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1274371246-26760-1-git-send-email-kaber@trash.net>
From: Luciano Coelho <luciano.coelho@nokia.com>
The text describing the return codes that are expected on calls to
checkentry() was incorrect. Instead of returning true or false, or an error
code, it should return 0 or an error code.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/linux/netfilter/x_tables.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index c2ee5d8..c00cc0c 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -333,7 +333,7 @@ struct xt_target {
/* Called when user tries to insert an entry of this type:
hook_mask is a bitmask of hooks from which it can be
called. */
- /* Should return true or false, or an error code (-Exxxx). */
+ /* Should return 0 on success or an error code otherwise (-Exxxx). */
int (*checkentry)(const struct xt_tgchk_param *);
/* Called when entry of this type deleted. */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] netfilter: nf_conntrack: fix a race in __nf_conntrack_confirm against nf_ct_get_next_corpse()
From: kaber @ 2010-05-20 16:00 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1274371246-26760-1-git-send-email-kaber@trash.net>
From: Joerg Marx <joerg.marx@secunet.com>
This race was triggered by a 'conntrack -F' command running in parallel
to the insertion of a hash for a new connection. Losing this race led to
a dead conntrack entry effectively blocking traffic for a particular
connection until timeout or flushing the conntrack hashes again.
Now the check for an already dying connection is done inside the lock.
Signed-off-by: Joerg Marx <joerg.marx@secunet.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/net/netfilter/nf_conntrack_core.h | 2 +-
net/netfilter/nf_conntrack_core.c | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_core.h b/include/net/netfilter/nf_conntrack_core.h
index dffde8e..3d7524f 100644
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -61,7 +61,7 @@ static inline int nf_conntrack_confirm(struct sk_buff *skb)
int ret = NF_ACCEPT;
if (ct && ct != &nf_conntrack_untracked) {
- if (!nf_ct_is_confirmed(ct) && !nf_ct_is_dying(ct))
+ if (!nf_ct_is_confirmed(ct))
ret = __nf_conntrack_confirm(skb);
if (likely(ret == NF_ACCEPT))
nf_ct_deliver_cached_events(ct);
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index b83c530..eeeb8bc 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -424,6 +424,16 @@ __nf_conntrack_confirm(struct sk_buff *skb)
spin_lock_bh(&nf_conntrack_lock);
+ /* We have to check the DYING flag inside the lock to prevent
+ a race against nf_ct_get_next_corpse() possibly called from
+ user context, else we insert an already 'dead' hash, blocking
+ further use of that particular connection -JM */
+
+ if (unlikely(nf_ct_is_dying(ct))) {
+ spin_unlock_bh(&nf_conntrack_lock);
+ return NF_ACCEPT;
+ }
+
/* See if there's one in the list already, including reverse:
NAT could have grabbed it without realizing, since we're
not in the hash. If there is, we lost race. */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] netfilter: nf_ct_sip: handle non-linear skbs
From: kaber @ 2010-05-20 16:00 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1274371246-26760-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Handle non-linear skbs by linearizing them instead of silently failing.
Long term the helper should be fixed to either work with non-linear skbs
directly by using the string search API or work on a copy of the data.
Based on patch by Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/nf_conntrack_sip.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index b20f427..53d8922 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1393,10 +1393,8 @@ static int sip_help_tcp(struct sk_buff *skb, unsigned int protoff,
nf_ct_refresh(ct, skb, sip_timeout * HZ);
- if (skb_is_nonlinear(skb)) {
- pr_debug("Copy of skbuff not supported yet.\n");
- return NF_ACCEPT;
- }
+ if (unlikely(skb_linearize(skb)))
+ return NF_DROP;
dptr = skb->data + dataoff;
datalen = skb->len - dataoff;
@@ -1455,10 +1453,8 @@ static int sip_help_udp(struct sk_buff *skb, unsigned int protoff,
nf_ct_refresh(ct, skb, sip_timeout * HZ);
- if (skb_is_nonlinear(skb)) {
- pr_debug("Copy of skbuff not supported yet.\n");
- return NF_ACCEPT;
- }
+ if (unlikely(skb_linearize(skb)))
+ return NF_DROP;
dptr = skb->data + dataoff;
datalen = skb->len - dataoff;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/3] netfilter: netfilter fixes
From: kaber @ 2010-05-20 16:00 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
following are three fixes for netfilter:
- handling of non-linear skbs in the SIP conntrack helper. This fixes tracking
failures when running on the same machine as a SIP application that is
producing non-linear skbs. Long term this should be fixed by using the string
search API, but that is a bigger piece of work.
- fix for a race condition in nf_conntrack that might lead to conntrack entries
marked as dead entering the hash tables, blocking new connections with similar
keys.
- a fix for an incorrect comment about the checkentry return conventions.
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Thanks!
^ permalink raw reply
* Re: [patch] IPVS: one-packet scheduling
From: Patrick McHardy @ 2010-05-20 15:17 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, lvs-devel, netfilter-devel, Wensong Zhang,
Julian Anastasov, Nick Chalk
In-Reply-To: <20100519031408.GC18534@verge.net.au>
Simon Horman wrote:
> From: Nick Chalk <nick@loadbalancer.org>
>
> IPVS: one-packet scheduling
>
> Allow one-packet scheduling for UDP connections. When the fwmark-based or
> normal virtual service is marked with '-o' or '--ops' options all
> connections are created only to schedule one packet. Useful to schedule UDP
> packets from same client port to different real servers. Recommended with
> RR or WRR schedulers (the connections are not visible with ipvsadm -L).
I'm afraid its too late in this merge window for new features
since Dave has already sent his merge request to Linus.
Please resend once the net-next (and nf-next) tree opens up.
^ permalink raw reply
* [ANNOUNCE]: Release of iptables-1.4.8
From: Patrick McHardy @ 2010-05-20 15:08 UTC (permalink / raw)
To: Netfilter Development Mailinglist
Cc: netfilter, netfilter-announce, Linux Netdev List, netfilter-core
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
The netfilter coreteam presents:
iptables version 1.4.8
the iptables release for the 2.6.34 kernel. Changes include:
- support for the new CT target
- port parsing fixes in the REDIRECT and MASQUERADE targets
- iprange v0 parsing fixes
- removal of MARK target restriction to the mangle table
- documentation updates
- inclusion of the nfnl_osf program for OS fingerprinting support
See the Changelog for more details.
Version 1.4.8 can be obtained from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
git://git.netfilter.org/iptables.git
On behalf of the Netfilter Core Team.
Happy firewalling!
[-- Attachment #2: changes-iptables-1.4.8.txt --]
[-- Type: text/plain, Size: 1035 bytes --]
Dmitry V. Levin (3):
extensions: REDIRECT: fix --to-ports parser
iptables: add noreturn attribute to exit_tryhelp()
extensions: MASQUERADE: fix --to-ports parser
Jan Engelhardt (8):
libxt_comment: avoid use of IPv4-specific examples
libxt_CT: add a manpage
iptables: correctly check for too-long chain/target/match names
doc: libxt_MARK: no longer restricted to mangle table
doc: remove claim that TCPMSS is limited to mangle
libxt_recent: add a missing space in output
doc: add manpage for libxt_osf
libxt_osf: import nfnl_osf program
Karl Hiramoto (1):
iptables: optionally disable largefile support
Pablo Neira Ayuso (1):
CT: fix --ctevents parsing
Patrick McHardy (3):
extensions: add CT extension
libxt_CT: print conntrack zone in ->print/->save
xtables: fix compilation when debugging is enabled
Simon Lodal (1):
libxt_conntrack: document --ctstate UNTRACKED
Vincent Bernat (1):
iprange: fix xt_iprange v0 parsing
^ permalink raw reply
* RE: loosing IPMI-card by loading netconsole
From: Allan, Bruce W @ 2010-05-20 15:01 UTC (permalink / raw)
To: Henning Fehrmann, Tejun Heo
Cc: Ronciak, John, Kirsher, Jeffrey T, Brandeburg, Jesse,
Waskiewicz Jr, Peter P, netdev@vger.kernel.org, Carsten Aulbert
In-Reply-To: <20100520101601.GA26235@localhost>
Those lines should not be removed as the default behavior should be to strip the CRC, there was a bug in previous versions of the kernel/driver that caused the default behavior to be reversed from what was intended. For your particular BMC, however, the CRC appears to be required so you will need to use the CrcStripping=0 module parameter to reverse the default behavior.
-----Original Message-----
From: Henning Fehrmann [mailto:henning.fehrmann@aei.mpg.de]
Sent: Thursday, May 20, 2010 3:16 AM
To: Tejun Heo
Cc: Ronciak, John; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Waskiewicz Jr, Peter P; netdev@vger.kernel.org; Carsten Aulbert
Subject: Re: loosing IPMI-card by loading netconsole
Hello,
>
>
> Let me re-describe the symptoms.
> I am not loading any ipmi related modules and not the netconsole
> module.
> When booting out current 2.6.32 kernel we can not access the IPMI
> remotely.
>
> We had one case where the IPMI card was accessible while using this
> kernel but probably due to the fact that eth0 was removed. We do not
> consider this case anymore.
>
> This problem does not occur when using an older kernel.
>
> It has likely nothing to do with netconsole.
>
> Here is the bisecting result:
>
> The sha1 sum of the first bad commit is:
> 6e50912a442947d5fafd296ca6fdcbeb36b163ff
>
> Hence, the last good commit has:
> b2f8f7525c8aa1fdd8ad8c72c832dfb571d5f768
I 'reverse patched' the changes:
diff --git a/drivers/net/e1000e/param.c b/drivers/net/e1000e/param.c
index e909f96..1342e0b 100644
--- a/drivers/net/e1000e/param.c
+++ b/drivers/net/e1000e/param.c
@@ -427,6 +427,8 @@ void __devinit e1000e_check_options(struct e1000_adapter *adapter)
e1000_validate_option(&crc_stripping, &opt, adapter);
if (crc_stripping == OPTION_ENABLED)
adapter->flags2 |= FLAG2_CRC_STRIPPING;
+ } else {
+ adapter->flags2 |= FLAG2_CRC_STRIPPING;
}
}
{ /* Kumeran Lock Loss Workaround */
and compiled the kernel. This kernel works and the IPMI card is remotely accessible.
Can we savely remove this two lines or are we running into other problems?
Cheers,
Henning
^ permalink raw reply related
* Re: RFC: netfilter: synproxy iptables target
From: Changli Gao @ 2010-05-20 14:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <1274365963.4046.39.camel@edumazet-laptop>
On Thu, May 20, 2010 at 10:32 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 20 mai 2010 à 22:21 +0800, Changli Gao a écrit :
>
>>
>> pure synproxy can be used on firewall to protect the internal servers,
>> which don't support neither syncookies and synproxy, from the attack
>> of SYN-flood.
>>
>
> protecting servers using conntracking ?
>
> Thats seems very dangerous to me.
If NAT is needed, conntracking is needed in any way. The conntrack
won't be confirmed until the connection between firewall and client is
established.
>
>> synproxy with defered connection relay acts as a layer 7 proxy, but
>> works in kernel space totally, unlike tcp splice tech., which needs
>> the applications in user space parse the requests, and establish the
>> connections.
>>
>
> In the example given, only non persistent connections are handled...
>
> These days, browsers and servers dont establish one socket per http
> request...
>
>
Yea. But some users still use non persistent connections, as they want
to fetch URLs in parallel.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: netfilter: synproxy iptables target
From: Changli Gao @ 2010-05-20 14:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Developer Mailing List, Linux Netdev List
In-Reply-To: <4BF5464D.4090409@trash.net>
On Thu, May 20, 2010 at 10:25 PM, Patrick McHardy <kaber@trash.net> wrote:
>
> I can't say much before seeing any code, but no general objections
> from my side.
>
The code is on github. (http://github.com/xiaosuo/xiaosuo). As it
isn't in good shape, and needs future modifications, I leave it there.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: netfilter: synproxy iptables target
From: Eric Dumazet @ 2010-05-20 14:32 UTC (permalink / raw)
To: Changli Gao
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <AANLkTimjY_0yKfMtAUxI7He-QH5R5AdDCR3V8eKSgbGq@mail.gmail.com>
Le jeudi 20 mai 2010 à 22:21 +0800, Changli Gao a écrit :
>
> pure synproxy can be used on firewall to protect the internal servers,
> which don't support neither syncookies and synproxy, from the attack
> of SYN-flood.
>
protecting servers using conntracking ?
Thats seems very dangerous to me.
> synproxy with defered connection relay acts as a layer 7 proxy, but
> works in kernel space totally, unlike tcp splice tech., which needs
> the applications in user space parse the requests, and establish the
> connections.
>
In the example given, only non persistent connections are handled...
These days, browsers and servers dont establish one socket per http
request...
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: netfilter: synproxy iptables target
From: Patrick McHardy @ 2010-05-20 14:25 UTC (permalink / raw)
To: Changli Gao; +Cc: Netfilter Developer Mailing List, Linux Netdev List
In-Reply-To: <AANLkTimjY_0yKfMtAUxI7He-QH5R5AdDCR3V8eKSgbGq@mail.gmail.com>
Changli Gao wrote:
> On Thu, May 20, 2010 at 10:11 PM, Patrick McHardy <kaber@trash.net> wrote:
>> Changli Gao wrote:
>>> I have implemented a simple SYNPROXY iptables target. It is much like
>>> the SYNPROXY implementation in pf of OpenBSD, but won't have state
>>> until the first connection is established with the help of syncookies.
>>> The code is hosted at github:
>>>
>>> http://github.com/xiaosuo/xiaosuo/tree/master/synproxy/
>>>
>>> Currently, it can work with firewall and local socket.
>>>
>>> It is in the very early stage, and ugly. And I will add --timeout
>>> parameter to this target as TCP_DFER_ACCEPT, so I can do NAT basing on
>>> the request data.
>>>
>>> i.e.
>>>
>>> iptables -t nat -A OUTPUT -p tcp -m synproxy --http-url "*.jpg" -j
>>> DNAT --to-destination $image_http_server:80
>>>
>>> And is there any chance to merge it into mainline?
>> If you can state a good use case, sure. I don't know much about the
>> PF synproxy myself.
>>
>
> pure synproxy can be used on firewall to protect the internal servers,
> which don't support neither syncookies and synproxy, from the attack
> of SYN-flood.
>
> synproxy with defered connection relay acts as a layer 7 proxy, but
> works in kernel space totally, unlike tcp splice tech., which needs
> the applications in user space parse the requests, and establish the
> connections.
I can't say much before seeing any code, but no general objections
from my side.
^ permalink raw reply
* Re: [net-next-2.6 V9 PATCH 1/2] Add netlink support for virtual port management (was iovnl)
From: Patrick McHardy @ 2010-05-20 14:24 UTC (permalink / raw)
To: Scott Feldman; +Cc: davem, netdev, chrisw, arnd
In-Reply-To: <20100518054833.21787.45456.stgit@savbu-pc100.cisco.com>
Scott Feldman wrote:
> From: Scott Feldman <scofeldm@cisco.com>
>
> Add new netdev ops ndo_{set|get}_vf_port to allow setting of
> port-profile on a netdev interface. Extends netlink socket RTM_SETLINK/
> RTM_GETLINK with two new sub msgs called IFLA_VF_PORTS and IFLA_PORT_SELF
> (added to end of IFLA_cmd list). These are both nested atrtibutes
> using this layout:
>
>...
Appologies for the delay, my mailserver failed me once again :|
This version looks very good to me, just one question:
> +static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct nlattr *vf_ports;
> + struct nlattr *vf_port;
> + int vf;
> + int err;
> +
> + vf_ports = nla_nest_start(skb, IFLA_VF_PORTS);
> + if (!vf_ports)
> + return -EMSGSIZE;
> +
> + for (vf = 0; vf < dev_num_vf(dev->dev.parent); vf++) {
> + vf_port = nla_nest_start(skb, IFLA_VF_PORT);
> + if (!vf_port) {
> + nla_nest_cancel(skb, vf_ports);
> + return -EMSGSIZE;
> + }
> + NLA_PUT_U32(skb, IFLA_PORT_VF, vf);
> + err = dev->netdev_ops->ndo_get_vf_port(dev, vf, skb);
> + if (err) {
> +nla_put_failure:
> + nla_nest_cancel(skb, vf_port);
> + continue;
Are you sure you want to continue here? During a full dump
this means that the last VF port fitting in the skb will most
likely be incomplete since the higher layer code won't
notice that the size was exceeded and the entry should be
dumped into another skb.
> + }
> + nla_nest_end(skb, vf_port);
> + }
> +
> + nla_nest_end(skb, vf_ports);
> +
> + return 0;
> +}
^ permalink raw reply
* Re: RFC: netfilter: synproxy iptables target
From: Changli Gao @ 2010-05-20 14:21 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Developer Mailing List, Linux Netdev List
In-Reply-To: <4BF54310.6030004@trash.net>
On Thu, May 20, 2010 at 10:11 PM, Patrick McHardy <kaber@trash.net> wrote:
> Changli Gao wrote:
>> I have implemented a simple SYNPROXY iptables target. It is much like
>> the SYNPROXY implementation in pf of OpenBSD, but won't have state
>> until the first connection is established with the help of syncookies.
>> The code is hosted at github:
>>
>> http://github.com/xiaosuo/xiaosuo/tree/master/synproxy/
>>
>> Currently, it can work with firewall and local socket.
>>
>> It is in the very early stage, and ugly. And I will add --timeout
>> parameter to this target as TCP_DFER_ACCEPT, so I can do NAT basing on
>> the request data.
>>
>> i.e.
>>
>> iptables -t nat -A OUTPUT -p tcp -m synproxy --http-url "*.jpg" -j
>> DNAT --to-destination $image_http_server:80
>>
>> And is there any chance to merge it into mainline?
>
> If you can state a good use case, sure. I don't know much about the
> PF synproxy myself.
>
pure synproxy can be used on firewall to protect the internal servers,
which don't support neither syncookies and synproxy, from the attack
of SYN-flood.
synproxy with defered connection relay acts as a layer 7 proxy, but
works in kernel space totally, unlike tcp splice tech., which needs
the applications in user space parse the requests, and establish the
connections.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: RFC: netfilter: synproxy iptables target
From: Patrick McHardy @ 2010-05-20 14:11 UTC (permalink / raw)
To: Changli Gao; +Cc: Netfilter Developer Mailing List, Linux Netdev List
In-Reply-To: <AANLkTimp6S7MpwDAT8l-M0ZWjs2HIcUEfL5f8j9-QDZh@mail.gmail.com>
Changli Gao wrote:
> I have implemented a simple SYNPROXY iptables target. It is much like
> the SYNPROXY implementation in pf of OpenBSD, but won't have state
> until the first connection is established with the help of syncookies.
> The code is hosted at github:
>
> http://github.com/xiaosuo/xiaosuo/tree/master/synproxy/
>
> Currently, it can work with firewall and local socket.
>
> It is in the very early stage, and ugly. And I will add --timeout
> parameter to this target as TCP_DFER_ACCEPT, so I can do NAT basing on
> the request data.
>
> i.e.
>
> iptables -t nat -A OUTPUT -p tcp -m synproxy --http-url "*.jpg" -j
> DNAT --to-destination $image_http_server:80
>
> And is there any chance to merge it into mainline?
If you can state a good use case, sure. I don't know much about the
PF synproxy myself.
^ permalink raw reply
* Re: [PATCH iproute] ip: add support for multicast rules
From: Patrick McHardy @ 2010-05-20 14:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
In-Reply-To: <20100519090354.6dc6d82b@nehalam>
Stephen Hemminger wrote:
> On Tue, 13 Apr 2010 17:06:24 +0200
> Patrick McHardy <kaber@trash.net> wrote:
>
>> This patch adds support for a "ip mrule" command, which is used
>> to configure multicast routing rules.
>>
>> The corresponding kernel patches have been sent to Dave and
>> should (hopefully) appear in net-next soon.
>
> The fib_rules.h file in iproute2 is kept in sync with the kernel
> headers. But I do not see the definitions of FIB_RULES_IPV4 etc
> in net-next kernel. What happened to this?
Those got changed again during the addition of IPv6 support.
I'll send a new version shortly, including IPv6 support.
^ permalink raw reply
* [PATCH] sh_eth: Fix memleak in sh_mdio_release
From: Denis Kirjanov @ 2010-05-20 14:00 UTC (permalink / raw)
To: davem; +Cc: shimoda.yoshihiro, iwamatsu, morimoto.kuninori, netdev
Allocated memory for IRQs should be freed when releasing the mii_bus
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/sh_eth.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 586ed09..501a55f 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -1294,6 +1294,9 @@ static int sh_mdio_release(struct net_device *ndev)
/* remove mdio bus info from net_device */
dev_set_drvdata(&ndev->dev, NULL);
+ /* free interrupts memory */
+ kfree(bus->irq);
+
/* free bitbang info */
free_mdio_bitbang(bus);
^ permalink raw reply related
* Re: [PATCH] netfilter: fix description of expected checkentry return code on xt_target
From: Patrick McHardy @ 2010-05-20 13:59 UTC (permalink / raw)
To: Luciano Coelho; +Cc: netfilter-devel, netdev
In-Reply-To: <1274126430-13744-1-git-send-email-luciano.coelho@nokia.com>
Luciano Coelho wrote:
> The text describing the return codes that are expected on calls to
> checkentry() was incorrect. Instead of returning true or false, or an error
> code, it should return 0 or an error code.
Applied, thanks.
^ permalink raw reply
* Re: will 2 cpu simultaneously process packets which have same hash value on multiqueue nic?
From: Eilon Greenstein @ 2010-05-20 12:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jon Zhou, netdev@vger.kernel.org
In-Reply-To: <1274356826.4046.29.camel@edumazet-laptop>
On Thu, 2010-05-20 at 05:00 -0700, Eric Dumazet wrote:
> Le jeudi 20 mai 2010 à 14:46 +0300, Eilon Greenstein a écrit :
> > On Wed, 2010-05-19 at 22:37 -0700, Jon Zhou wrote:
> > > will 2 cpu simultaneously process packets which have same hash value on multiqueue nic?
> > >
> > > let 's take broadcom 57711 bnx2x_main.c as an example:
> > >
> > > #1 packet1->queue=1
> > > #2 packet2->queue=1
> > >
> > > will cpu1 and cpu2 execute the function " bnx2x_rx_int" in parallel, to receive packet1 & packet2
> > Both packets will be handled by the same queue and the queue processing
> > is serialized - so the packets will be handled one after the other.
>
> I am scratching my head to understand both the question and your
> answer...
>
I was trying to say that since both packets are handled on the same
queue - it is handled one after the other and not by two different CPUs
working on the same queue at once.
> if cpu1 is handling an interrupt, cpu2 cannot handle an interrupt at the
> same time for same queue. It must be for a different queue.
>
> Therefore, packets will be handled in parallel.
What do you mean "in parallel"? As you wrote above, only one cpu is
handling the packets from that queue, and since the hash is the same,
even RPS will not allow different CPUs to handle those 2 packets.
>
> Serialization might be done later, at socket layer to queue packets in a
> receive queue for example, if both packets must be delivered on same
> socket.
Though this is always true, the case of receiving packets on the same
queue is even simpler, is not it?
^ 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