* [PATCH 17/18] net: vxlan: use wrapper functions of net_ratelimit() to simplify code
From: Kefeng Wang @ 2013-10-15 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, David S. Miller, Pablo Neira Ayuso,
Stephen Hemminger, Johannes Berg, John W. Linville,
Stanislaw Gruszka, Johannes Berg, Francois Romieu, Ben Hutchings,
Chas Williams, Marc Kleine-Budde, Samuel Ortiz, Paul Mackerras,
Oliver Neukum, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Rusty Russell, Michael S. Tsirkin, netfilter,
netdev
In-Reply-To: <1381837514-50660-1-git-send-email-wangkefeng.wang@huawei.com>
net_ratelimited_function() is called to simplify code.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/net/vxlan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2ef5b62..56583ab 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -893,8 +893,7 @@ static bool vxlan_snoop(struct net_device *dev,
if (f->state & NUD_NOARP)
return true;
- if (net_ratelimit())
- netdev_info(dev,
+ net_ratelimited_function(netdev_info, dev,
"%pM migrated from %pIS to %pIS\n",
src_mac, &rdst->remote_ip, &src_ip);
--
1.8.2.1
^ permalink raw reply related
* [PATCH 18/18] net: wimax: use wrapper functions of net_ratelimit() to simplify code
From: Kefeng Wang @ 2013-10-15 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, David S. Miller, Pablo Neira Ayuso,
Stephen Hemminger, Johannes Berg, John W. Linville,
Stanislaw Gruszka, Johannes Berg, Francois Romieu, Ben Hutchings,
Chas Williams, Marc Kleine-Budde, Samuel Ortiz, Paul Mackerras,
Oliver Neukum, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Rusty Russell, Michael S. Tsirkin, netfilter,
netdev
In-Reply-To: <1381837514-50660-1-git-send-email-wangkefeng.wang@huawei.com>
net_ratelimited_function() is called to simplify code.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/net/wimax/i2400m/netdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
index 4889613..678717a 100644
--- a/drivers/net/wimax/i2400m/netdev.c
+++ b/drivers/net/wimax/i2400m/netdev.c
@@ -305,8 +305,7 @@ int i2400m_net_wake_tx(struct i2400m *i2400m, struct net_device *net_dev,
* queue -- blame the queue disciplines that
* queue without looking -- I guess there is a reason
* for that. */
- if (net_ratelimit())
- d_printf(1, dev, "NETTX: device exiting idle, "
+ net_ratelimited_function(d_printf, 1, dev, "NETTX: device exiting idle, "
"dropping skb %p, queue running %d\n",
skb, netif_queue_stopped(net_dev));
result = -EBUSY;
--
1.8.2.1
^ permalink raw reply related
* [PATCH 0/2] be2net: patch set
From: Sathya Perla @ 2013-10-15 11:51 UTC (permalink / raw)
To: netdev
Pls apply the following fixes to the net tree. Thanks.
Vasundhara Volam (2):
be2net: pass if_id for v1 and V2 versions of TX_CREATE cmd
be2net: drop non-tso frames longer than mtu
drivers/net/ethernet/emulex/benet/be_cmds.c | 3 ++-
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] be2net: pass if_id for v1 and V2 versions of TX_CREATE cmd
From: Sathya Perla @ 2013-10-15 11:56 UTC (permalink / raw)
To: netdev
From: Vasundhara Volam <vasundhara.volam@emulex.com>
It is a required field for all TX_CREATE cmd versions > 0.
This fixes a driver initialization failure, caused by recent SH-R Firmwares
(versions > 10.0.639.0) failing the TX_CREATE cmd when if_id field is
not passed.
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index bd0e0c0..c08fd32 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1198,7 +1198,6 @@ int be_cmd_txq_create(struct be_adapter *adapter, struct be_tx_obj *txo)
if (lancer_chip(adapter)) {
req->hdr.version = 1;
- req->if_id = cpu_to_le16(adapter->if_handle);
} else if (BEx_chip(adapter)) {
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC)
req->hdr.version = 2;
@@ -1206,6 +1205,8 @@ int be_cmd_txq_create(struct be_adapter *adapter, struct be_tx_obj *txo)
req->hdr.version = 2;
}
+ if (req->hdr.version > 0)
+ req->if_id = cpu_to_le16(adapter->if_handle);
req->num_pages = PAGES_4K_SPANNED(q_mem->va, q_mem->size);
req->ulp_num = BE_ULP1_NUM;
req->type = BE_ETH_TX_RING_TYPE_STANDARD;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Sathya Perla @ 2013-10-15 11:56 UTC (permalink / raw)
To: netdev
In-Reply-To: <1381838188-9625-1-git-send-email-sathya.perla@emulex.com>
From: Vasundhara Volam <vasundhara.volam@emulex.com>
Pktgen can generate non-TSO frames of arbitrary length disregarding
the MTU value of the physical interface. Drop such frames in the driver
instead of sending them to HW as it cannot handle such frames.
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2c38cc4..76057b8 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
unsigned int eth_hdr_len;
struct iphdr *ip;
+ /* Don't allow non-TSO packets longer than MTU */
+ eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
+ VLAN_ETH_HLEN : ETH_HLEN;
+ if (!skb_is_gso(skb) &&
+ (skb->len - eth_hdr_len) > adapter->netdev->mtu)
+ goto tx_drop;
+
/* Lancer, SH-R ASICs have a bug wherein Packets that are 32 bytes or less
* may cause a transmit stall on that port. So the work-around is to
* pad short packets (<= 32 bytes) to a 36-byte length.
@@ -869,8 +876,6 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
* incorrecly when VLAN tag is inserted by HW.
* For padded packets, Lancer computes incorrect checksum.
*/
- eth_hdr_len = ntohs(skb->protocol) == ETH_P_8021Q ?
- VLAN_ETH_HLEN : ETH_HLEN;
if (skb->len <= 60 &&
(lancer_chip(adapter) || vlan_tx_tag_present(skb)) &&
is_ipv4_pkt(skb)) {
--
1.7.1
^ permalink raw reply related
* [PATCH 13/18] net: ppp: use wrapper functions of net_ratelimit() to simplify code
From: Kefeng Wang @ 2013-10-15 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, David S. Miller, Pablo Neira Ayuso,
Stephen Hemminger, Johannes Berg, John W. Linville,
Stanislaw Gruszka, Johannes Berg, Francois Romieu, Ben Hutchings,
Chas Williams, Marc Kleine-Budde, Samuel Ortiz, Paul Mackerras,
Oliver Neukum, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Rusty Russell, Michael S. Tsirkin, netfilter,
netdev
In-Reply-To: <1381837514-50660-1-git-send-email-wangkefeng.wang@huawei.com>
net_ratelimited_function() is called to simplify code.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/net/ppp/ppp_generic.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 72ff14b..53900cd 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1125,8 +1125,8 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
ppp->xcomp->comp_extra + PPP_HDRLEN;
new_skb = alloc_skb(new_skb_size, GFP_ATOMIC);
if (!new_skb) {
- if (net_ratelimit())
- netdev_err(ppp->dev, "PPP: no memory (comp pkt)\n");
+ net_ratelimited_function(netdev_err, ppp->dev,
+ "PPP: no memory (comp pkt)\n");
return NULL;
}
if (ppp->dev->hard_header_len > PPP_HDRLEN)
@@ -1155,8 +1155,8 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
* the compress_proto because MPPE and MPPC share
* the same number.
*/
- if (net_ratelimit())
- netdev_err(ppp->dev, "ppp: compressor dropped pkt\n");
+ net_ratelimited_function(netdev_err, ppp->dev,
+ "ppp: compressor dropped pkt\n");
kfree_skb(skb);
consume_skb(new_skb);
new_skb = NULL;
@@ -1251,8 +1251,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state &&
proto != PPP_LCP && proto != PPP_CCP) {
if (!(ppp->flags & SC_CCP_UP) && (ppp->flags & SC_MUST_COMP)) {
- if (net_ratelimit())
- netdev_err(ppp->dev,
+ net_ratelimited_function(netdev_err, ppp->dev,
"ppp: compression required but "
"down - pkt dropped.\n");
goto drop;
--
1.8.2.1
^ permalink raw reply related
* How to filter and intercept packets by using net_dev_add api?
From: Milad khajavi @ 2013-10-15 12:04 UTC (permalink / raw)
To: netdev
I'm writing ethernet network driver for linux. I want to receive
packets, edit and resend them. I know how to edit the packet in
packet_interceptor function, but how can I drop incoming packets in
this function??
Yesterday I've asked this question in stackoverflow [1], but since
now, no one reply that.
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <linux/ip.h>
struct packet_type my_proto;
int packet_interceptor(struct sk_buff *skb,
struct net_device *dev,
struct packet_type *pt,
struct net_device *orig_dev) {
//// I don't want certain packets go to upper in net_devices for
further processing.
//// How can I drop sk_buff here?!
return 0;
}
static int hello_init( void ) {
printk(KERN_INFO "Hello, world!\n");
my_proto.type = htons(ETH_P_ALL);
my_proto.dev = NULL;
my_proto.func = packet_interceptor;
dev_add_pack(&my_proto);
return 0;
}
static void hello_exit(void) {
dev_remove_pack(&my_proto);
printk(KERN_INFO "Bye, world\n");
}
module_init(hello_init);
module_exit(hello_exit);
[1] - http://stackoverflow.com/questions/19342252/how-to-filter-and-intercept-linux-packets-by-using-net-dev-add-api
--
Milād Khājavi
http://blog.khajavi.ir
Having the source means you can do it yourself.
I tried to change the world, but I couldn’t find the source code.
^ permalink raw reply
* Re: DomU's network interface will hung when Dom0 running 32bit
From: Wei Liu @ 2013-10-15 12:58 UTC (permalink / raw)
To: jianhai luan; +Cc: Wei Liu, Ian Campbell, xen-devel, netdev, ANNIE LI
In-Reply-To: <525D2667.6040102@oracle.com>
On Tue, Oct 15, 2013 at 07:26:31PM +0800, jianhai luan wrote:
[...]
> >>>Can you propose a patch?
> >>Because credit_timeout.expire always after jiffies, i judge the
> >>value over the range of time_after_eq() by time_before(now,
> >>vif->credit_timeout.expires). please check the patch.
> >I don't think this really fix the issue for you. You still have chance
> >that now wraps around and falls between expires and next_credit. In that
> >case it's stalled again.
>
> if time_before(now, vif->credit_timeout.expires) is true, time wrap
> and do operation. Otherwise time_before(now,
> vif->credit_timeout.expires) isn't true, now -
> vif->credit_timeout.expires should be letter than ULONG_MAX/2.
> Because next_credit large than vif->credit_timeout.expires
> (next_crdit = vif->credit_timeout.expires +
> msecs_to_jiffies(vif->credit_usec/1000)), the delta between now and
> next_credit should be in range of time_after_eq(). So
> time_after_eq() do correctly judge.
>
Not sure I understand you. Consider "now" is placed like this:
expires now next_credit
----time increases this direction--->
* time_after_eq(now, next_credit) -> false
* time_before(now, expires) -> false
Then it's stuck again. You're merely narrowing the window, not fixing
the real problem.
Wei.
> Jason
> >
> >Wei.
^ permalink raw reply
* [PATCH] usb: serial: option: blacklist Olivetti Olicard200
From: Enrico Mioso @ 2013-10-15 13:06 UTC (permalink / raw)
To: gregkh, davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel
Cc: Enrico Mioso, Antonella Pellizzari
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 80a7104..d7c10d6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1257,7 +1257,9 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
- { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
+ .driver_info = (kernel_ulong_t)&net_intf6_blacklist
+ },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
--
1.8.4
^ permalink raw reply related
* [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: Enrico Mioso @ 2013-10-15 13:06 UTC (permalink / raw)
To: gregkh, davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel
Cc: Enrico Mioso, Antonella Pellizzari
In-Reply-To: <1381842408-10800-1-git-send-email-mrkiko.rs@gmail.com>
This is a QMI device, manufactured by TCT Mobile Phones.
A companion patch blacklisting this device's QMI interface in the option.c
driver has been sent.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3d6aaf7..818ce90 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -714,6 +714,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
+ {QMI_FIXED_INTF(0x0b3c, 0xc005, 6)}, /* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
/* 4. Gobi 1000 devices */
--
1.8.4
^ permalink raw reply related
* Re: [Ilw] drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
From: Sander Eikelenboom @ 2013-10-15 13:10 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: John W. Linville, Berg, Johannes, ilw@linux.intel.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DC46E5@HASMSX103.ger.corp.intel.com>
Tuesday, October 15, 2013, 12:52:04 PM, you wrote:
>>
>> Hi,
>>
>> I'm having a:
>>
>> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev
>> 24)
>>
>> And i'm running into this warning on boot with a 3.11.2 and 3.12-rc5 kernel.
>>
>> [ 23.904950] ------------[ cut here ]------------
>> [ 23.904957] WARNING: CPU: 0 PID: 2531 at
>> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
> Can you reproduce easily?
> If yes, please reproduce with debug parameters:
> modprobe iwlwifi debug=0xC0800000
> Also, please enable MAC80211_HT_DEBUG
> Thanks
It happens when starting hostapd:
[ 7.101116] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 7.110722] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
[ 7.154478] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 9 on FIFO 7 WrPtr: 0
[ 7.157691] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 0 on FIFO 3 WrPtr: 0
[ 7.160812] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 1 on FIFO 2 WrPtr: 0
[ 7.164900] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 2 on FIFO 1 WrPtr: 0
[ 7.165019] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 3 on FIFO 0 WrPtr: 0
[ 7.165139] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 4 on FIFO 0 WrPtr: 0
[ 7.165258] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 5 on FIFO 4 WrPtr: 0
[ 7.165377] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 6 on FIFO 2 WrPtr: 0
[ 7.165495] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 7 on FIFO 5 WrPtr: 0
[ 7.165614] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 8 on FIFO 4 WrPtr: 0
[ 7.165733] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 10 on FIFO 5 WrPtr: 0
[ 7.404295] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 7.415368] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
[ 7.462417] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 9 on FIFO 7 WrPtr: 0
[ 7.466588] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 0 on FIFO 3 WrPtr: 0
[ 7.470415] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 1 on FIFO 2 WrPtr: 0
[ 7.474144] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 2 on FIFO 1 WrPtr: 0
[ 7.477514] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 3 on FIFO 0 WrPtr: 0
[ 7.480843] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 4 on FIFO 0 WrPtr: 0
[ 7.484148] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 5 on FIFO 4 WrPtr: 0
[ 7.487432] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 6 on FIFO 2 WrPtr: 0
[ 7.490496] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 7 on FIFO 5 WrPtr: 0
[ 7.493534] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 8 on FIFO 4 WrPtr: 0
[ 7.496562] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 10 on FIFO 5 WrPtr: 0
[ 7.542143] device wlan0 entered promiscuous mode
[ 7.544749] xen_bridge: port 2(wlan0) entered forwarding state
[ 7.546915] xen_bridge: port 2(wlan0) entered forwarding state
[ 7.548825] cfg80211: Pending regulatory request, waiting for it to be processed...
[ 7.552798] ------------[ cut here ]------------
[ 7.554821] WARNING: CPU: 1 PID: 2445 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x776/0x979()
[ 7.554824] Modules linked in: acpi_cpufreq
[ 7.554827] CPU: 1 PID: 2445 Comm: hostapd Not tainted 3.12.0-rc5+ #1
[ 7.554828] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
[ 7.554831] 0000000000000000 0000000000000009 ffffffff818a8082 0000000000000000
[ 7.554833] ffffffff8105a4f2 0000000000000000 ffffffff815f440a ffff8800d6df1c80
[ 7.554835] ffff8800d6cb1790 ffff8800d6df1c80 0000000000000007 0000000000000000
[ 7.554835] Call Trace:
[ 7.554842] [<ffffffff818a8082>] ? dump_stack+0x41/0x51
[ 7.554845] [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
[ 7.554850] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
[ 7.554852] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
[ 7.554855] [<ffffffff815f2407>] ? iwlagn_mac_tx+0x19/0x30
[ 7.554858] [<ffffffff8187a259>] ? __ieee80211_tx+0x226/0x29b
[ 7.554860] [<ffffffff8187bcd1>] ? ieee80211_tx+0xa6/0xb5
[ 7.554865] [<ffffffff8187bf9f>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
[ 7.554867] [<ffffffff8172e1eb>] ? dev_hard_start_xmit+0x271/0x3ec
[ 7.554871] [<ffffffff81746538>] ? sch_direct_xmit+0x66/0x164
[ 7.554873] [<ffffffff8172e54b>] ? dev_queue_xmit+0x1e5/0x3c8
[ 7.554876] [<ffffffff8180bfe6>] ? packet_sendmsg+0xac5/0xb3d
[ 7.554881] [<ffffffff8171ad95>] ? sock_sendmsg+0x37/0x52
[ 7.554884] [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
[ 7.554886] [<ffffffff81724bac>] ? verify_iovec+0x44/0x94
[ 7.554889] [<ffffffff8171b1ef>] ? ___sys_sendmsg+0x1f1/0x283
[ 7.554893] [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
[ 7.554895] [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
[ 7.554897] [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
[ 7.554900] [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
[ 7.554902] [<ffffffff81132f6f>] ? dput+0xe5/0xef
[ 7.554905] [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
[ 7.554908] [<ffffffff8171c1ee>] ? __sys_sendmsg+0x39/0x57
[ 7.554911] [<ffffffff818b5e39>] ? system_call_fastpath+0x16/0x1b
[ 7.554912] ---[ end trace beb2b581b91027a7 ]---
[ 7.554917] iwlwifi 0000:02:00.0: I iwlagn_tx_skb TX to [14|8] Q:7 - seq: 0x0
[ 7.555036] device wlan0 left promiscuous mode
[ 7.555042] xen_bridge: port 2(wlan0) entered disabled state
[ 7.557861] iwlwifi 0000:02:00.0: I iwl_trans_pcie_reclaim [Q 7] 0 -> 1 (1)
[ 7.557865] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx TXQ 7 status SUCCESS (0x00000201)
[ 7.557867] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx initial_rate 0x820a retries 0, idx=0 ssn=1 seq_ctl=0x0
[ 7.626274] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x23
[ 7.670694] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x24
[ 7.673864] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x25
[ 7.677083] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x26
[ 7.681410] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x27
[ 7.684761] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x28
[ 7.686906] iwlwifi 0000:02:00.0: I iwl_pcie_txq_unmap Q 9 Free 39
^ permalink raw reply
* RE: [Ilw] drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
From: Grumbach, Emmanuel @ 2013-10-15 13:35 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: John W. Linville, Berg, Johannes, ilw@linux.intel.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1127865420.20131015151054@eikelenboom.it>
Please apply this:
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
index d131f85..5968f19 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -457,8 +457,8 @@ int iwlagn_tx_skb(struct iwl_priv *priv,
WARN_ON_ONCE(is_agg &&
priv->queue_to_mac80211[txq_id] != info->hw_queue);
- IWL_DEBUG_TX(priv, "TX to [%d|%d] Q:%d - seq: 0x%x\n", sta_id, tid,
- txq_id, seq_number);
+ IWL_DEBUG_TX(priv, "TX to [%d|%d] Q:%d info Q %d - seq: 0x%x\n", sta_id, tid,
+ txq_id, info->hw_queue, seq_number);
if (iwl_trans_tx(priv->trans, skb, dev_cmd, txq_id))
goto drop_unlock_sta;
and send the output back to me
Thanks.
>
> >>
> >> Hi,
> >>
> >> I'm having a:
> >>
> >> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235
> (rev
> >> 24)
> >>
> >> And i'm running into this warning on boot with a 3.11.2 and 3.12-rc5
> kernel.
> >>
> >> [ 23.904950] ------------[ cut here ]------------
> >> [ 23.904957] WARNING: CPU: 0 PID: 2531 at
> >> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
>
> > Can you reproduce easily?
> > If yes, please reproduce with debug parameters:
> > modprobe iwlwifi debug=0xC0800000
>
> > Also, please enable MAC80211_HT_DEBUG
>
> > Thanks
>
> It happens when starting hostapd:
>
> [ 7.101116] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
> [ 7.110722] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
> [ 7.154478] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 9 on FIFO 7 WrPtr: 0
> [ 7.157691] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 0 on FIFO 3 WrPtr: 0
> [ 7.160812] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 1 on FIFO 2 WrPtr: 0
> [ 7.164900] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 2 on FIFO 1 WrPtr: 0
> [ 7.165019] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 3 on FIFO 0 WrPtr: 0
> [ 7.165139] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 4 on FIFO 0 WrPtr: 0
> [ 7.165258] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 5 on FIFO 4 WrPtr: 0
> [ 7.165377] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 6 on FIFO 2 WrPtr: 0
> [ 7.165495] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 7 on FIFO 5 WrPtr: 0
> [ 7.165614] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 8 on FIFO 4 WrPtr: 0
> [ 7.165733] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 10 on FIFO 5 WrPtr: 0
> [ 7.404295] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
> [ 7.415368] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
> [ 7.462417] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 9 on FIFO 7 WrPtr: 0
> [ 7.466588] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 0 on FIFO 3 WrPtr: 0
> [ 7.470415] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 1 on FIFO 2 WrPtr: 0
> [ 7.474144] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 2 on FIFO 1 WrPtr: 0
> [ 7.477514] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 3 on FIFO 0 WrPtr: 0
> [ 7.480843] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 4 on FIFO 0 WrPtr: 0
> [ 7.484148] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 5 on FIFO 4 WrPtr: 0
> [ 7.487432] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 6 on FIFO 2 WrPtr: 0
> [ 7.490496] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 7 on FIFO 5 WrPtr: 0
> [ 7.493534] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 8 on FIFO 4 WrPtr: 0
> [ 7.496562] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 10 on FIFO 5 WrPtr: 0
> [ 7.542143] device wlan0 entered promiscuous mode
> [ 7.544749] xen_bridge: port 2(wlan0) entered forwarding state
> [ 7.546915] xen_bridge: port 2(wlan0) entered forwarding state
> [ 7.548825] cfg80211: Pending regulatory request, waiting for it to be
> processed...
> [ 7.552798] ------------[ cut here ]------------
> [ 7.554821] WARNING: CPU: 1 PID: 2445 at
> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x776/0x979()
> [ 7.554824] Modules linked in: acpi_cpufreq
> [ 7.554827] CPU: 1 PID: 2445 Comm: hostapd Not tainted 3.12.0-rc5+ #1
> [ 7.554828] Hardware name: /D53427RKE, BIOS
> RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
> [ 7.554831] 0000000000000000 0000000000000009 ffffffff818a8082
> 0000000000000000
> [ 7.554833] ffffffff8105a4f2 0000000000000000 ffffffff815f440a
> ffff8800d6df1c80
> [ 7.554835] ffff8800d6cb1790 ffff8800d6df1c80 0000000000000007
> 0000000000000000
> [ 7.554835] Call Trace:
> [ 7.554842] [<ffffffff818a8082>] ? dump_stack+0x41/0x51
> [ 7.554845] [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
> [ 7.554850] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
> [ 7.554852] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
> [ 7.554855] [<ffffffff815f2407>] ? iwlagn_mac_tx+0x19/0x30
> [ 7.554858] [<ffffffff8187a259>] ? __ieee80211_tx+0x226/0x29b
> [ 7.554860] [<ffffffff8187bcd1>] ? ieee80211_tx+0xa6/0xb5
> [ 7.554865] [<ffffffff8187bf9f>] ?
> ieee80211_monitor_start_xmit+0x1e9/0x204
> [ 7.554867] [<ffffffff8172e1eb>] ? dev_hard_start_xmit+0x271/0x3ec
> [ 7.554871] [<ffffffff81746538>] ? sch_direct_xmit+0x66/0x164
> [ 7.554873] [<ffffffff8172e54b>] ? dev_queue_xmit+0x1e5/0x3c8
> [ 7.554876] [<ffffffff8180bfe6>] ? packet_sendmsg+0xac5/0xb3d
> [ 7.554881] [<ffffffff8171ad95>] ? sock_sendmsg+0x37/0x52
> [ 7.554884] [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
> [ 7.554886] [<ffffffff81724bac>] ? verify_iovec+0x44/0x94
> [ 7.554889] [<ffffffff8171b1ef>] ? ___sys_sendmsg+0x1f1/0x283
> [ 7.554893] [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
> [ 7.554895] [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
> [ 7.554897] [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
> [ 7.554900] [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
> [ 7.554902] [<ffffffff81132f6f>] ? dput+0xe5/0xef
> [ 7.554905] [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
> [ 7.554908] [<ffffffff8171c1ee>] ? __sys_sendmsg+0x39/0x57
> [ 7.554911] [<ffffffff818b5e39>] ? system_call_fastpath+0x16/0x1b
> [ 7.554912] ---[ end trace beb2b581b91027a7 ]---
> [ 7.554917] iwlwifi 0000:02:00.0: I iwlagn_tx_skb TX to [14|8] Q:7 - seq: 0x0
> [ 7.555036] device wlan0 left promiscuous mode
> [ 7.555042] xen_bridge: port 2(wlan0) entered disabled state
> [ 7.557861] iwlwifi 0000:02:00.0: I iwl_trans_pcie_reclaim [Q 7] 0 -> 1 (1)
> [ 7.557865] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx TXQ 7 status SUCCESS
> (0x00000201)
> [ 7.557867] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx
> initial_rate 0x820a retries 0, idx=0 ssn=1 seq_ctl=0x0
> [ 7.626274] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x23
> [ 7.670694] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x24
> [ 7.673864] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x25
> [ 7.677083] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x26
> [ 7.681410] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x27
> [ 7.684761] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x28
> [ 7.686906] iwlwifi 0000:02:00.0: I iwl_pcie_txq_unmap Q 9 Free 39
^ permalink raw reply related
* Re: [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Sergei Shtylyov @ 2013-10-15 13:45 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <1381838188-9625-2-git-send-email-sathya.perla@emulex.com>
Hello.
On 15-10-2013 15:56, Sathya Perla wrote:
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
> Pktgen can generate non-TSO frames of arbitrary length disregarding
> the MTU value of the physical interface. Drop such frames in the driver
> instead of sending them to HW as it cannot handle such frames.
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..76057b8 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
> unsigned int eth_hdr_len;
> struct iphdr *ip;
>
> + /* Don't allow non-TSO packets longer than MTU */
> + eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
> + VLAN_ETH_HLEN : ETH_HLEN;
> + if (!skb_is_gso(skb) &&
> + (skb->len - eth_hdr_len) > adapter->netdev->mtu)
> + goto tx_drop;
This *goto* is indented one tab too much.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Eric Dumazet @ 2013-10-15 13:47 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <1381838188-9625-2-git-send-email-sathya.perla@emulex.com>
On Tue, 2013-10-15 at 17:26 +0530, Sathya Perla wrote:
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
>
> Pktgen can generate non-TSO frames of arbitrary length disregarding
> the MTU value of the physical interface. Drop such frames in the driver
> instead of sending them to HW as it cannot handle such frames.
>
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..76057b8 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
> unsigned int eth_hdr_len;
> struct iphdr *ip;
>
> + /* Don't allow non-TSO packets longer than MTU */
> + eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
> + VLAN_ETH_HLEN : ETH_HLEN;
> + if (!skb_is_gso(skb) &&
> + (skb->len - eth_hdr_len) > adapter->netdev->mtu)
> + goto tx_drop;
> +
When you say 'cannot handle them', is it some kind of nasty thing like
hang / crash ?
One could imagine gso_size + sizeof(headers) > mtu, and give the same
problem ?
AFAIK, we have no check in net/core/dev.c.
Maybe we should instead add them there (and in pktgen)
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-10-15 13:55 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1381680661.1831.16.camel@localhost.localdomain>
On 10/13/2013 12:11 PM, Toshiaki Makita wrote:
> On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
>> On 10/11/2013 03:34 AM, Toshiaki Makita wrote:
>>> On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote:
>>>> On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
>>>>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
>>>>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
>>>>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
>>>>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
>>>>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
>>>>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
>>>>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
>>>>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
>>>>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
>>>>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David
>>>>>>>>>>>>>>>>>>> Miller wrote:
>>>>>>>>>>>>>>>>>>>> From: Toshiaki Makita
>>>>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> Date: Tue,
>>>>>>>>>>>>>>>>>>>> 10 Sep 2013 19:27:54 +0900
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There seem to be some undesirable
>>>>>>>>>>>>>>>>>>>>> behaviors related with PVID. 1. It has no
>>>>>>>>>>>>>>>>>>>>> effect assigning PVID to a port. PVID
>>>>>>>>>>>>>>>>>>>>> cannot be applied to any frame regardless
>>>>>>>>>>>>>>>>>>>>> of whether we set it or not. 2. FDB
>>>>>>>>>>>>>>>>>>>>> entries learned via frames applied PVID
>>>>>>>>>>>>>>>>>>>>> are registered with VID 0 rather than VID
>>>>>>>>>>>>>>>>>>>>> value of PVID. 3. We can set 0 or 4095 as
>>>>>>>>>>>>>>>>>>>>> a PVID that are not allowed in IEEE
>>>>>>>>>>>>>>>>>>>>> 802.1Q. This leads interoperational
>>>>>>>>>>>>>>>>>>>>> problems such as sending frames with VID
>>>>>>>>>>>>>>>>>>>>> 4095, which is not allowed in IEEE
>>>>>>>>>>>>>>>>>>>>> 802.1Q, and treating frames with VID 0 as
>>>>>>>>>>>>>>>>>>>>> they belong to VLAN 0, which is expected
>>>>>>>>>>>>>>>>>>>>> to be handled as they have no VID
>>>>>>>>>>>>>>>>>>>>> according to IEEE 802.1Q.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential
>>>>>>>>>>>>>>>>>>>>> and not exposed unless 1st problem is
>>>>>>>>>>>>>>>>>>>>> fixed, because we cannot activate PVID
>>>>>>>>>>>>>>>>>>>>> due to it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please work out the issues in patch #2 with
>>>>>>>>>>>>>>>>>>>> Vlad and resubmit this series.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm hovering between whether we should fix
>>>>>>>>>>>>>>>>>>> the issue by changing vlan 0 interface
>>>>>>>>>>>>>>>>>>> behavior in 8021q module or enabling a bridge
>>>>>>>>>>>>>>>>>>> port to sending priority-tagged frames, or
>>>>>>>>>>>>>>>>>>> another better way.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you could comment it, I'd appreciate it
>>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW, I think what is discussed in patch #2 is
>>>>>>>>>>>>>>>>>>> another problem about handling priority-tags,
>>>>>>>>>>>>>>>>>>> and it exists without this patch set
>>>>>>>>>>>>>>>>>>> applied. It looks like that we should prepare
>>>>>>>>>>>>>>>>>>> another patch set than this to fix that
>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Should I include patches that fix the
>>>>>>>>>>>>>>>>>>> priority-tags problem in this patch set and
>>>>>>>>>>>>>>>>>>> resubmit them all together?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am thinking that we might need to do it in
>>>>>>>>>>>>>>>>>> bridge and it looks like the simplest way to do
>>>>>>>>>>>>>>>>>> it is to have default priority regeneration
>>>>>>>>>>>>>>>>>> table (table 6-5 from 802.1Q doc).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That way I think we would conform to the spec.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately I don't think the default priority
>>>>>>>>>>>>>>>>> regeneration table resolves the problem because
>>>>>>>>>>>>>>>>> IEEE 802.1Q says that a VLAN-aware bridge can
>>>>>>>>>>>>>>>>> transmit untagged or VLAN-tagged frames only (the
>>>>>>>>>>>>>>>>> end of section 7.5 and 8.1.7).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No mechanism to send priority-tagged frames is
>>>>>>>>>>>>>>>>> found as far as I can see the standard. I think
>>>>>>>>>>>>>>>>> the regenerated priority is used for outgoing
>>>>>>>>>>>>>>>>> PCP field only if egress policy is not untagged
>>>>>>>>>>>>>>>>> (i.e. transmitting as VLAN-tagged), and unused if
>>>>>>>>>>>>>>>>> untagged (Section 6.9.2 3rd/4th Paragraph).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If we want to transmit priority-tagged frames
>>>>>>>>>>>>>>>>> from a bridge port, I think we need to implement
>>>>>>>>>>>>>>>>> a new (optional) feature that is above the
>>>>>>>>>>>>>>>>> standard, as I stated previously.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How do you feel about adding a per-port policy
>>>>>>>>>>>>>>>>> that enables a bridge to send priority-tagged
>>>>>>>>>>>>>>>>> frames instead of untagged frames when egress
>>>>>>>>>>>>>>>>> policy for the port is untagged? With this
>>>>>>>>>>>>>>>>> change, we can transmit frames for a given vlan
>>>>>>>>>>>>>>>>> as either all untagged, all priority-tagged or
>>>>>>>>>>>>>>>>> all VLAN-tagged.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That would work. What I am thinking is that we do
>>>>>>>>>>>>>>>> it by special casing the vid 0 egress policy
>>>>>>>>>>>>>>>> specification. Let it be untagged by default and
>>>>>>>>>>>>>>>> if it is tagged, then we preserve the priority
>>>>>>>>>>>>>>>> field and forward it on.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This keeps the API stable and doesn't require
>>>>>>>>>>>>>>>> user/admin from knowing exactly what happens.
>>>>>>>>>>>>>>>> Default operation conforms to the spec and allows
>>>>>>>>>>>>>>>> simple change to make it backward-compatible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you think. I've done a simple prototype of
>>>>>>>>>>>>>>>> this an it seems to work with the VMs I am testing
>>>>>>>>>>>>>>>> with.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of
>>>>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and
>>>>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as
>>>>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If so, though it's attractive to keep current API,
>>>>>>>>>>>>>>> I'm worried about if it could be a bit confusing and
>>>>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID
>>>>>>>>>>>>>>> 0 has a special meaning only in the egress policy.
>>>>>>>>>>>>>>> Wouldn't it be better to adding a new member to
>>>>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of
>>>>>>>>>>>>>>> untagged_bitmap?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or are you saying that we use a new flag in struct
>>>>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED
>>>>>>>>>>>>>>> bit with VID 0 in netlink to set the flag?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even in that case, I'm afraid that it might be
>>>>>>>>>>>>>>> confusing for developers for the same reason. We are
>>>>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in
>>>>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering
>>>>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a
>>>>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a
>>>>>>>>>>>>>>> new nlattr is a straightforward approach to
>>>>>>>>>>>>>>> configure it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a
>>>>>>>>>>>>>> special case for any automatic tool that would
>>>>>>>>>>>>>> provision such filtering. Seeing vid 0 would mean that
>>>>>>>>>>>>>> these tools would have to know that this would have to
>>>>>>>>>>>>>> be translated to a different attribute instead of
>>>>>>>>>>>>>> setting the policy values.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, I agree with you that we can do it by the way you
>>>>>>>>>>>>> explained. What I don't understand is the advantage of
>>>>>>>>>>>>> using vid 0 over another way such as adding a new
>>>>>>>>>>>>> nlattr. I think we can indicate transmitting
>>>>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0
>>>>>>>>>>>>> seems to be easier to implement than a new nlattr, but,
>>>>>>>>>>>>> for me, it looks less intuitive and more difficult to
>>>>>>>>>>>>> maintain because we have to care about vid 0 instead of
>>>>>>>>>>>>> simply ignoring it.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The point I am trying to make is that regardless of the
>>>>>>>>>>>> approach someone has to know what to do when enabling
>>>>>>>>>>>> priority tagged frames. You proposal would require the
>>>>>>>>>>>> administrator or config tool to have that knowledge.
>>>>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev
>>>>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority
>>>>>>>>>>>> tagged frame support */
>>>>>>>>>>>>
>>>>>>>>>>>> My proposal would require the bridge filtering
>>>>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0
>>>>>>>>>>>> tagged Automated app: No special case.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO its better to have 1 piece code handling the special
>>>>>>>>>>>> case then putting it multiple places.
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the detailed explanation. Now I understand your
>>>>>>>>>>> intention.
>>>>>>>>>>>
>>>>>>>>>>> I have one question about your proposal. I guess the way to
>>>>>>>>>>> enable priority-tagged is something like bridge vlan add vid
>>>>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub
>>>>>>>>>>> interface vnet0.0.
>>>>>>>>>>>
>>>>>>>>>>> Here the admin have to know the egress policy is applied to a
>>>>>>>>>>> frame twice in a certain order when it is transmitted from
>>>>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10
>>>>>>>>>>> get untagged, and then, an untagged frame get
>>>>>>>>>>> priority-tagged.
>>>>>>>>>>>
>>>>>>>>>>> This behavior looks difficult to know without previous
>>>>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's
>>>>>>>>>>> additional knowledge?
>>>>>>>>>>
>>>>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is
>>>>>>>>>> eth0.0 in the guest or on the remote host) already tells the
>>>>>>>>>> admin vlan 0 has to be tagged. The fact that we codify this in
>>>>>>>>>> the policy makes it explicit.
>>>>>>>>>
>>>>>>>>> My worry is that the admin might not be able to guess how to use
>>>>>>>>> bridge commands to enable priority-tag without any additional
>>>>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually
>>>>>>>>> couldn't hit upon such a usage before seeing example commands you
>>>>>>>>> gave, because I had never think the egress policy could be
>>>>>>>>> applied twice.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, I can see strong argument to be made for an addition
>>>>>>>>>> egress policy attribute that could be for instance:
>>>>>>>>>>
>>>>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev
>>>>>>>>>> vnet0 pvid untagged prio_tag
>>>>>>>>>>
>>>>>>>>>> But this has the same connotations as wrt to egress policy.
>>>>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add
>>>>>>>>>> priority_tag.
>>>>>>>>>>
>>>>>>>>>> (2) only happens if initial fame received on eth0 was priority
>>>>>>>>>> tagged.
>>>>>>>>>
>>>>>>>>> If we do so, we will not be able to communicate using vlan 0
>>>>>>>>> interface under a certain circumstance. Eth0 can be receive mixed
>>>>>>>>> untagged and priority-tagged frames according to the network
>>>>>>>>> element it is connected to: for example, Open vSwitch can send
>>>>>>>>> such two kinds of frames from the same port even if original
>>>>>>>>> incoming frames belong to the same vlan.
>>>>>>>>
>>>>>>>> Which priority would you assign to the frame that was received
>>>>>>>> untagged?
>>>>>>>
>>>>>>> Untagged frame's priority is by default 0, so I think 0 is likely.
>>>>>>>
>>>>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
>>>>>>> parameter value are the values in the M_UNITDATA.indication.
>>>>>>>
>>>>>>> M_UNITDATA is passed from ISS.
>>>>>>>
>>>>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
>>>>>>> primitive shall take the value of the Default User Priority parameter
>>>>>>> for the Port through which the MAC frame was received. The default
>>>>>>> value of this parameter is 0, it may be set by management in which
>>>>>>> case the capability to set it to any of the values 0 through 7 shall
>>>>>>> be provided.
>>>>>>>
>>>>>>>>
>>>>>>>>> In this situation, we can only receive frames that is
>>>>>>>>> priority-tagged when received on eth0.
>>>>>>>>
>>>>>>>> Not sure I understand. Let's look at this config: bridge vlan add
>>>>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>>>> prio_tag
>>>>>>>>
>>>>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and
>>>>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame
>>>>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was
>>>>>>>> untagged, it should probably be sent untagged. 2) if the frame had
>>>>>>>> a priority tag, it should probably be sent as such.
>>>>>>>>
>>>>>>>> Now, I think a case could be made that if the frame had any
>>>>>>>> priority markings in the vlan header, we should try to preserve
>>>>>>>> those markings if prio_tag is turned on. We can assume value of 0
>>>>>>>> means not set.
>>>>>>>
>>>>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
>>>>>>> priority-tagged and untagged frames on eth0.
>>>>>>
>>>>>> Right, and that's what you were trying to handle in your patch:
>>>>>>
>>>>>>> + /* PVID is set on this port. Any untagged or priority-tagged +
>>>>>>> * ingress frame is considered to belong to this vlan. */
>>>>>>
>>>>>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
>>>>>>
>>>>>>> Even if we are sending frames from eth0.0 with some priority other
>>>>>>> than 0, we could receive frames with priority 0 or untagged on the
>>>>>>> other side of the bridge.
>>>>>>> For example, if we receive untagged arp reply on the bridge port, we
>>>>>>> migit not be able to communicate with such an end station, because
>>>>>>> untagged reply will not be passed to eth0.0.
>>>>>>
>>>>>> So the ARP request was sent tagged, but the reply came back untagged?
>>>>>
>>>>> Yes, it can happen.
>>>>> These are problematic cases.
>>>>>
>>>>> Example 1:
>>>>> prio_tagged prio_tagged
>>>>> +------------+ ---> +------------+ ---> +----------+
>>>>> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
>>>>> +------------+ <--- +------------+ <--- +----------+
>>>>> untagged untagged
>>>>>
>>>>> Note: Host2 eth0, which is an interface on Linux, can receive
>>>>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
>>>>
>>>> Hmm.. Just to see if this works, I ran the this scenario with
>>>> a dumb switch in the middle, and it did not work as you noted.
>>>> I then realized that one of the kernels was rather old and after
>>>> updating it, behaved differently. The communication still didn't
>>>> work, but host2 behaved properly.
>>>>
>>>>>>
>>>>>> How does that work when the end station is attached directly to the
>>>>>> HW switch instead of a linux bridge?
>>>>>>
>>>>>> The station configures eth0.0 and sends priority-tagged traffic to
>>>>>> the HW switch. If the HW switch sends back untagged traffic, then
>>>>>> the untagged traffic will never reach eth0.0.
>>>>>
>>>>> Currently we cannot communicate using eth0.0 via directly connected
>>>>> 802.1Q conformed switch, because we never receive priority-tagged frames
>>>>> from the switch.
>>>>> It is not a problem of Linux bridge and is why I wondered whether it
>>>>> should be fixed by bridge or vlan 0 interface.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> IMO, if prio_tag is configured, the bridge should send any
>>>>>>>>> untagged frame as priority-tagged regardless of whatever it is on
>>>>>>>>> eth0.
>>>>>>>>
>>>>>>>> Which priority would you use, 0? You are not guaranteed to
>>>>>>>> properly deliver the traffic then for a configuration such as: VM:
>>>>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24
>>>>>>>
>>>>>>> I'd like to use priority 0 for untagged frames.
>>>>>>>
>>>>>>> I am assuming that one of our goals is at least that eth0.0 comes to
>>>>>>> be able to communicate with another end station. It seems to be hard
>>>>>>> to use both eth0 and eth0.0 simultaneously.
>>>>>>
>>>>>> I understand, but I don't agree that we should always tag.
>>>>>>
>>>>>> Consider config:
>>>>>>
>>>>>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
>>>>>>
>>>>>> If the end station sends priority-tagged traffic it should receive
>>>>>> priority tagged traffic back. Otherwise, untagged traffic may be
>>>>>> dropped by the end station. This is true whether it is connected to
>>>>>> the hw switch or Linux bridge.
>>>>>
>>>>> Though such a behavior is generally not necessary as far as I can read
>>>>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
>>>>> My proposal aims to resolve it at least when we use Linux bridge.
>>>>>
>>>>> Example configuration:
>>>>> bridge vlan add vid 10 dev eth1 pvid untagged
>>>>> bridge vlan add vid 10 dev eth0
>>>>> bridge vlan set prio_tag on dev eth1
>>>>>
>>>>> Intended behavior:
>>>>>
>>>>> VID10-tagged prio_tagged
>>>>> +---------+ <--- +------------------------+ <--- +-----------------+
>>>>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
>>>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>>>> VID10-tagged prio_tagged
>>>>> (always if egress policy untagged)
>>>>
>>>> Ok, I think you've convinced me that this is the right approach. The
>>>> only thing that I am not crazy about is the API. I'd almost want to
>>>> introduce a new flag that can be set in a 'vlan add' or 'vlan set'
>>>> command that communicates a new policy.
>>>
>>> I'm glad that we reached a consensus on the approach :)
>>>
>>> I agree with you that the API is flag based.
>>> I'm guessing your intention is that 'vlan add' means a per vlan per port
>>> policy and 'vlan set' means a per port one, that is,
>>> 'vlan add': bridge vlan add vid 10 dev eth1 prio_tag
>>> 'vlan set': bridge vlan set prio_tag on dev eth1
>>>
>>> I think they can behave differently only when we set untagged to
>>> multiple vlans on the same port.
>>>
>>> 'vlan add' example with vid 10 and 20:
>>> bridge vlan add vid 10 dev eth1 pvid untagged prio_tag
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 20 dev eth1 untagged
>>> bridge vlan add vid 20 dev eth2
>>>
>>> VID10-tagged prio_tagged (from eth0)
>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>> |hw switch|------|eth0 eth1|------|em1.0:end station|
>>> +---------+ | Linux Bridge | ---> +-----------------+
>>> +---------+ | | *untagged*
>>> |hw switch|------|eth2 | (from eth2)
>>> +---------+ ---> +------------------------+
>>> VID20-tagged
>>>
>>
>> This is what I was thinking of, but I was actually considering that
>> untagged and prio_tag can not co-exist for the same vlan as they don't
>> really make sence together anymore.
>
> You're right.
> In this case 'untagged' for 'vid 10' is no longer necessary.
>
>>
>> So one can do:
>> bridge vlan add vid 10 dev eth1 pvid prio_tag
>> bridge vlan add vid 20 dev eth1 untagged
>>
>> and recieve VLAN 10 as priority tagged and vlan 20 as untagged.
>
> Can you make a patch set implementing this?
>
> I'd like to re-send this patch set related to PVID with more comments
> about the unresolved vlan 0 interface problem and the prospect that it
> will be addressed by another patch set of yours.
>
> Is this procedure OK with you?
Sure. Can you re-send the patch series, since I think 3 of the paches
are really needed. I'll work on the prio_tag stuff.
-vlad
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -vlad
>>
>>>
>>> 'vlan set' example with vid 10 and 20:
>>> bridge vlan add vid 10 dev eth1 pvid untagged
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 20 dev eth1 untagged
>>> bridge vlan add vid 20 dev eth2
>>> bridge vlan set prio_tag on dev eth1
>>>
>>> VID10-tagged prio_tagged (from eth0)
>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>> |hw switch|------|eth0 eth1|------|em1.0:end station|
>>> +---------+ | Linux Bridge | ---> +-----------------+
>>> +---------+ | | prio_tagged
>>> |hw switch|------|eth2 | (from eth2)
>>> +---------+ ---> +------------------------+
>>> VID20-tagged
>>>
>>> Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'.
>>> However, I cannot imagine when multiple untagged vlans is required, so
>>> cannot figure out whether 'vlan add' is useful or harmful.
>>> Anyway, both of approaches are OK with me.
>>>
>>> Thanks,
>>> Toshiaki Makita
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Toshiaki Makita
>>>>>
>>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Toshiaki Makita
>>>>>>>
>>>>>>>>
>>>>>>>> -vlad
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I am ok with either approach. Explicit vid 0 policy is
>>>>>>>>>> easier for automatic provisioning. The flag based one is
>>>>>>>>>> easier for admin/ manual provisioning.
>>>>>>>>>
>>>>>>>>> Supposing we have to add something to help or man in any case, I
>>>>>>>>> think flag based is better. The format below seems to suitable
>>>>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Toshiaki Makita
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -vlad.
>>>>>>>>>>
>>>>>>>>>> -vlad
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks -vlad
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How it is implemented internally in the kernel isn't as
>>>>>>>>>>>>>> big of an issue. We can do it as a separate flag or as
>>>>>>>>>>>>>> part of existing policy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -- 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH] net: sctp: fix a cacc_saw_newack missetting issue
From: Vlad Yasevich @ 2013-10-15 14:11 UTC (permalink / raw)
To: Chang Xiangzhong, nhorman; +Cc: davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <1381757623-12803-1-git-send-email-changxiangzhong@gmail.com>
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
> For for each TSN t being newly acked (Not only cumulatively,
> but also SELECTIVELY) cacc_saw_newack should be set to 1.
>
> Signed-off-by: Xiangzhong Chang <changxiangzhong@gmail.com>
> ---
> net/sctp/outqueue.c | 42 +++++++++++++++++++++---------------------
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 94df758..d86032b 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1398,6 +1398,27 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> forward_progress = true;
> }
>
> + if (!tchunk->tsn_gap_acked) {
You can remove this test since the block just above already performs
it. Just fold this code into the block above.
-vlad
> + /*
> + * SFR-CACC algorithm:
> + * 2) If the SACK contains gap acks
> + * and the flag CHANGEOVER_ACTIVE is
> + * set the receiver of the SACK MUST
> + * take the following action:
> + *
> + * B) For each TSN t being acked that
> + * has not been acked in any SACK so
> + * far, set cacc_saw_newack to 1 for
> + * the destination that the TSN was
> + * sent to.
> + */
> + if (transport &&
> + sack->num_gap_ack_blocks &&
> + q->asoc->peer.primary_path->cacc.
> + changeover_active)
> + transport->cacc.cacc_saw_newack = 1;
> + }
> +
> if (TSN_lte(tsn, sack_ctsn)) {
> /* RFC 2960 6.3.2 Retransmission Timer Rules
> *
> @@ -1411,27 +1432,6 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> restart_timer = 1;
> forward_progress = true;
>
> - if (!tchunk->tsn_gap_acked) {
> - /*
> - * SFR-CACC algorithm:
> - * 2) If the SACK contains gap acks
> - * and the flag CHANGEOVER_ACTIVE is
> - * set the receiver of the SACK MUST
> - * take the following action:
> - *
> - * B) For each TSN t being acked that
> - * has not been acked in any SACK so
> - * far, set cacc_saw_newack to 1 for
> - * the destination that the TSN was
> - * sent to.
> - */
> - if (transport &&
> - sack->num_gap_ack_blocks &&
> - q->asoc->peer.primary_path->cacc.
> - changeover_active)
> - transport->cacc.cacc_saw_newack
> - = 1;
> - }
>
> list_add_tail(&tchunk->transmitted_list,
> &q->sacked);
>
^ permalink raw reply
* Re: [PATCH] net: sctp: fix a cacc_saw_newack missetting issue
From: Chang @ 2013-10-15 14:27 UTC (permalink / raw)
To: Vlad Yasevich, nhorman; +Cc: davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <525D4D2D.8000506@gmail.com>
On 10/15/2013 04:11 PM, Vlad Yasevich wrote:
> On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
>> For for each TSN t being newly acked (Not only cumulatively,
>> but also SELECTIVELY) cacc_saw_newack should be set to 1.
>>
>> Signed-off-by: Xiangzhong Chang <changxiangzhong@gmail.com>
>> ---
>> net/sctp/outqueue.c | 42 +++++++++++++++++++++---------------------
>> 1 file changed, 21 insertions(+), 21 deletions(-)
>>
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index 94df758..d86032b 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -1398,6 +1398,27 @@ static void sctp_check_transmitted(struct
>> sctp_outq *q,
>> forward_progress = true;
>> }
>>
>> + if (!tchunk->tsn_gap_acked) {
>
> You can remove this test since the block just above already performs
> it. Just fold this code into the block above.
>
> -vlad
>
Sorry, I'm not sure if I fully understand you. There are code blocks
which checking the tchunk->tsn_gap_acked. In addition, they check other
states as well.
>> + /*
>> + * SFR-CACC algorithm:
>> + * 2) If the SACK contains gap acks
>> + * and the flag CHANGEOVER_ACTIVE is
>> + * set the receiver of the SACK MUST
>> + * take the following action:
>> + *
>> + * B) For each TSN t being acked that
>> + * has not been acked in any SACK so
>> + * far, set cacc_saw_newack to 1 for
>> + * the destination that the TSN was
>> + * sent to.
>> + */
>> + if (transport &&
>> + sack->num_gap_ack_blocks &&
>> + q->asoc->peer.primary_path->cacc.
>> + changeover_active)
>> + transport->cacc.cacc_saw_newack = 1;
>> + }
>> +
>> if (TSN_lte(tsn, sack_ctsn)) {
>> /* RFC 2960 6.3.2 Retransmission Timer Rules
>> *
>> @@ -1411,27 +1432,6 @@ static void sctp_check_transmitted(struct
>> sctp_outq *q,
>> restart_timer = 1;
>> forward_progress = true;
>>
>> - if (!tchunk->tsn_gap_acked) {
>> - /*
>> - * SFR-CACC algorithm:
>> - * 2) If the SACK contains gap acks
>> - * and the flag CHANGEOVER_ACTIVE is
>> - * set the receiver of the SACK MUST
>> - * take the following action:
>> - *
>> - * B) For each TSN t being acked that
>> - * has not been acked in any SACK so
>> - * far, set cacc_saw_newack to 1 for
>> - * the destination that the TSN was
>> - * sent to.
>> - */
>> - if (transport &&
>> - sack->num_gap_ack_blocks &&
>> - q->asoc->peer.primary_path->cacc.
>> - changeover_active)
>> - transport->cacc.cacc_saw_newack
>> - = 1;
>> - }
>>
>> list_add_tail(&tchunk->transmitted_list,
>> &q->sacked);
>>
>
^ permalink raw reply
* [PATCH net 0/9] bnx2x: Bug fixes patch series
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong
Hi Dave,
This patch series contains fixes for various flows - several SR-IOV issues
are fixed, ethtool callbacks (coalescing and register dump) are corrected,
null pointer dereference on error flows is prevented, etc.
Please consider applying this series to 'net'.
Thanks,
Yuval Mintz
^ permalink raw reply
* [PATCH] X.25: Fix address field length calculation
From: Kelleter, Günther @ 2013-10-15 14:29 UTC (permalink / raw)
To: andrew.hendry@gmail.com
Cc: davem@davemloft.net, linux-x25@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
Signed-off-by: Guenther Kelleter <gkelleter@datus.com>
---
Wrong length calculation leads to rejection of CALL ACCEPT packets.
net/x25/af_x25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 45a3ab5..2daf224 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -98,7 +98,7 @@ int x25_parse_address_block(struct sk_buff *skb,
}
len = *skb->data;
- needed = 1 + (len >> 4) + (len & 0x0f);
+ needed = 1 + ((len >> 4) + (len & 0x0f) + 1) / 2;
if (!pskb_may_pull(skb, needed)) {
/* packet is too short to hold the addresses it claims
--
1.8.3.4.71.g0878476
^ permalink raw reply related
* [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
During a panic, the driver tries to print the Management FW buffer of recent
commands. To do so, the driver reads the address of that buffer from a known
address. If the buffer is unavailable (e.g., PCI reads don't work, MCP is
failing, etc.), the driver will try to access the address it has read, possibly
causing a kernel panic.
This check 'sanitizes' the access, validating the read value is indeed a valid
address inside the management FW's buffers.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 4 ++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 19 ++++++++++++++-----
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 97b3d32..d21742c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -2498,4 +2498,8 @@ enum bnx2x_pci_bus_speed {
};
void bnx2x_set_local_cmng(struct bnx2x *bp);
+
+#define MCPR_SCRATCH_BASE(bp) \
+ (CHIP_IS_E1x(bp) ? MCP_REG_MCPR_SCRATCH : MCP_A_REG_MCPR_SCRATCH)
+
#endif /* bnx2x.h */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 60f9e68..3fd76b9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
trace_shmem_base = bp->common.shmem_base;
else
trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
+
+ /* sanity */
+ if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
+ trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
+ BNX2X_ERR("Unable to dump trace buffer (mark %x)\n",
+ trace_shmem_base);
+ return;
+ }
+
addr = trace_shmem_base - 0x800;
/* validate TRCB signature */
@@ -787,8 +796,7 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
/* read cyclic buffer pointer */
addr += 4;
mark = REG_RD(bp, addr);
- mark = (CHIP_IS_E1x(bp) ? MCP_REG_MCPR_SCRATCH : MCP_A_REG_MCPR_SCRATCH)
- + ((mark + 0x3) & ~0x3) - 0x08000000;
+ mark = MCPR_SCRATCH_BASE(bp) + ((mark + 0x3) & ~0x3) - 0x08000000;
printk("%s" "begin fw dump (mark 0x%x)\n", lvl, mark);
printk("%s", lvl);
@@ -11685,9 +11693,6 @@ static int bnx2x_init_bp(struct bnx2x *bp)
static int bnx2x_open(struct net_device *dev)
{
struct bnx2x *bp = netdev_priv(dev);
- bool global = false;
- int other_engine = BP_PATH(bp) ? 0 : 1;
- bool other_load_status, load_status;
int rc;
bp->stats_init = true;
@@ -11703,6 +11708,10 @@ static int bnx2x_open(struct net_device *dev)
* Parity recovery is only relevant for PF driver.
*/
if (IS_PF(bp)) {
+ int other_engine = BP_PATH(bp) ? 0 : 1;
+ bool other_load_status, load_status;
+ bool global = false;
+
other_load_status = bnx2x_get_load_status(bp, other_engine);
load_status = bnx2x_get_load_status(bp, BP_PATH(bp));
if (!bnx2x_reset_is_done(bp, BP_PATH(bp)) ||
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 1/9] bnx2x: Fix Maximum CoS estimation for VFs
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
bnx2x VFs do not support Multi-CoS; Current implementation
erroneously sets the VFs maximal number of CoS to be > 1.
This will cause the driver to call alloc_etherdev_mqs() with
a number of queues it cannot possibly support and reflects
in 'odd' driver prints.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 82b658d..60f9e68 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12612,24 +12612,24 @@ static int set_max_cos_est(int chip_id)
return BNX2X_MULTI_TX_COS_E1X;
case BCM57712:
case BCM57712_MF:
- case BCM57712_VF:
return BNX2X_MULTI_TX_COS_E2_E3A0;
case BCM57800:
case BCM57800_MF:
- case BCM57800_VF:
case BCM57810:
case BCM57810_MF:
case BCM57840_4_10:
case BCM57840_2_20:
case BCM57840_O:
case BCM57840_MFO:
- case BCM57810_VF:
case BCM57840_MF:
- case BCM57840_VF:
case BCM57811:
case BCM57811_MF:
- case BCM57811_VF:
return BNX2X_MULTI_TX_COS_E3B0;
+ case BCM57712_VF:
+ case BCM57800_VF:
+ case BCM57810_VF:
+ case BCM57840_VF:
+ case BCM57811_VF:
return 1;
default:
pr_err("Unknown board_type (%d), aborting\n", chip_id);
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 4/9] bnx2x: Fix Coalescing configuration
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
bnx2x drivers configure coalescing incorrectly (e.g., as a result of a call
to 'ethtool -c'). Although this is almost invisible to the user (due to NAPI)
designated tests will show the configuration is incorrect.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index d21742c..986edbf 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1621,7 +1621,7 @@ struct bnx2x {
u16 rx_ticks_int;
u16 rx_ticks;
/* Maximal coalescing timeout in us */
-#define BNX2X_MAX_COALESCE_TOUT (0xf0*12)
+#define BNX2X_MAX_COALESCE_TOUT (0xff*BNX2X_BTR)
u32 lin_cnt;
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 3/9] bnx2x: Unlock VF-PF channel on MAC/VLAN config error
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Ariel Elior <ariele@broadcom.com>
Current code returns upon failure, leaving the VF-PF in an unusable state;
This patch adds the missing release so further commands could pass between
PF and VF.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 9ad012b..997c661 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -3390,14 +3390,16 @@ int bnx2x_set_vf_mac(struct net_device *dev, int vfidx, u8 *mac)
rc = bnx2x_del_all_macs(bp, mac_obj, BNX2X_ETH_MAC, true);
if (rc) {
BNX2X_ERR("failed to delete eth macs\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* remove existing uc list macs */
rc = bnx2x_del_all_macs(bp, mac_obj, BNX2X_UC_LIST_MAC, true);
if (rc) {
BNX2X_ERR("failed to delete uc_list macs\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* configure the new mac to device */
@@ -3405,6 +3407,7 @@ int bnx2x_set_vf_mac(struct net_device *dev, int vfidx, u8 *mac)
bnx2x_set_mac_one(bp, (u8 *)&bulletin->mac, mac_obj, true,
BNX2X_ETH_MAC, &ramrod_flags);
+out:
bnx2x_unlock_vf_pf_channel(bp, vf, CHANNEL_TLV_PF_SET_MAC);
}
@@ -3467,7 +3470,8 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
&ramrod_flags);
if (rc) {
BNX2X_ERR("failed to delete vlans\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* send queue update ramrod to configure default vlan and silent
@@ -3501,7 +3505,8 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
rc = bnx2x_config_vlan_mac(bp, &ramrod_param);
if (rc) {
BNX2X_ERR("failed to configure vlan\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* configure default vlan to vf queue and set silent
@@ -3519,18 +3524,18 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
rc = bnx2x_queue_state_change(bp, &q_params);
if (rc) {
BNX2X_ERR("Failed to configure default VLAN\n");
- return rc;
+ goto out;
}
/* clear the flag indicating that this VF needs its vlan
- * (will only be set if the HV configured th Vlan before vf was
- * and we were called because the VF came up later
+ * (will only be set if the HV configured the Vlan before vf was
+ * up and we were called because the VF came up later
*/
+out:
vf->cfg_flags &= ~VF_CFG_VLAN;
-
bnx2x_unlock_vf_pf_channel(bp, vf, CHANNEL_TLV_PF_SET_VLAN);
}
- return 0;
+ return rc;
}
/* crc is the first field in the bulletin board. Compute the crc over the
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 6/9] bnx2x: Prevent null pointer dereference on error flow
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
If debug message is open and bnx2x_vfop_qdtor_cmd() were to fail,
the resulting print would have caused a null pointer dereference.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 997c661..bf08ad6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -470,10 +470,10 @@ static int bnx2x_vfop_qdtor_cmd(struct bnx2x *bp,
bnx2x_vfop_qdtor, cmd->done);
return bnx2x_vfop_transition(bp, vf, bnx2x_vfop_qdtor,
cmd->block);
+ } else {
+ BNX2X_ERR("VF[%d] failed to add a vfop\n", vf->abs_vfid);
+ return -ENOMEM;
}
- DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop. rc %d\n",
- vf->abs_vfid, vfop->rc);
- return -ENOMEM;
}
static void
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net net 5/9] bnx2x: Fix config when SR-IOV and iSCSI are enabled
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Ariel Elior <ariele@broadcom.com>
Starting with commit b9871bc "bnx2x: VF RSS support - PF side", if a PF will
have SR-IOV supported in its PCI configuration space, storage drivers will not
work for that interface.
This patch fixes the resource calculation to allow such a configuration to
properly work.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 986edbf..275b126 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1197,8 +1197,9 @@ union cdu_context {
/* TM (timers) host DB constants */
#define TM_ILT_PAGE_SZ_HW 0
#define TM_ILT_PAGE_SZ (4096 << TM_ILT_PAGE_SZ_HW) /* 4K */
-/* #define TM_CONN_NUM (CNIC_STARTING_CID+CNIC_ISCSI_CXT_MAX) */
-#define TM_CONN_NUM 1024
+#define TM_CONN_NUM (BNX2X_FIRST_VF_CID + \
+ BNX2X_VF_CIDS + \
+ CNIC_ISCSI_CID_MAX)
#define TM_ILT_SZ (8 * TM_CONN_NUM)
#define TM_ILT_LINES DIV_ROUND_UP(TM_ILT_SZ, TM_ILT_PAGE_SZ)
--
1.8.1.227.g44fe835
^ permalink raw reply related
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