* [patch 0/2] s390: network bug fixes for net
From: frank.blaschka @ 2013-04-02 10:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
Hi Dave,
here are 2 bug fixes for net.
shortlog:
Hendrik Brueckner (1)
af_iucv: recvmsg: use correct skb_pull() function
Stefan Raspl (1)
qeth: fix qeth_wait_for_threads() deadlock for OSN devices
Thanks,
Frank
^ permalink raw reply
* Re: Freescale FEC: fall back to random address
From: Pavel Machek @ 2013-04-02 11:35 UTC (permalink / raw)
To: Frank Li; +Cc: kernel list, fabio.estevam, l.stach, Frank.Li, netdev, davem
In-Reply-To: <CAHrpEqSVUc1yedCoyOrRoxkjY7=N_pCDB1F7-WvRaP+4UEY68A@mail.gmail.com>
Hi!
> I think it is okay.
Ok, now... is there someone maintianing Freescale FEC? Or, Dave, can
you merge the patch?
Thanks,
Pavel
> 2013/4/1 Pavel Machek <pavel@denx.de>:
> > If there's no valid ethernet address, fall back to randomly generated
> > one.
> >
> > (Yes, I need to get newer u-boot for the board, but as the only
> > available one is from 2009... this might be good idea).
> >
> > Signed-off-by: Pavel Machek <pavel@denx.de>
> >
> >
> > index e3f3937..5a7d1e1 100644
> > pp--- a/drivers/net/ethernet/freescale/fec.c
> > +++ b/drivers/net/ethernet/freescale/fec.c
> > @@ -906,6 +914,16 @@ static void fec_get_mac(struct net_device *ndev)
> > iap = &tmpaddr[0];
> > }
> >
> > + /*
> > + * 5) random mac address
> > + */
> > + if (!is_valid_ether_addr(iap)) {
> > + /* Report it and use a random ethernet address instead */
> > + netdev_err(ndev, "Invalid MAC address: %pM\n", iap);
> > + random_ether_addr(iap);
> > + netdev_info(ndev, "Using random MAC address: %pM\n", iap);
> > + }
> > +
> > memcpy(ndev->dev_addr, iap, ETH_ALEN);
> >
> > /* Adjust MAC if using macaddr */
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
From: Anders Boström @ 2013-04-02 12:22 UTC (permalink / raw)
To: hannes; +Cc: ben, Jie.Yang, netdev, 565404, Xiong.Huang
In-Reply-To: <20130402094102.GD4924@order.stressinduktion.org>
>>>>> "HFS" == Hannes Frederic Sowa <hannes@stressinduktion.org> writes:
HFS> The bug is definitely still around. Yesterday I could reproduce it and will
HFS> look for a solution in the next days.
This sounds great!
HFS> Do you have any details on the hangs every 6 months? Could you catch
HFS> thread dumps or oopses?
As I wrote, the computer is a live file-server, so we have restarted
the computer as soon as possible when this has occured, and currently
use an Intel NIC instead.
The following was logged when the hang occured:
May 19 12:50:32 flash kernel: [12182478.782248] ATL1E 0000:03:00.0: atl1e_clean is called when AT_DOWN
...
Dec 8 15:00:28 flash kernel: [5282450.781172] ATL1E 0000:03:00.0: atl1e_clean is called when AT_DOWN
/ Anders
^ permalink raw reply
* Re: [net-next.git 4/8] stmmac: initial support to manage pcs modes
From: Giuseppe CAVALLARO @ 2013-04-02 12:29 UTC (permalink / raw)
To: Byungho An; +Cc: netdev, rayagond
In-Reply-To: <000301ce2d05$57a153c0$06e3fb40$%an@samsung.com>
Hello Byungho
On 3/30/2013 6:13 AM, Byungho An wrote:
> On 3/26/2013 11:46 PM, Giuseppe CAVALLARO wrote:
>> This patch adds the minimal support to manage the PCS
>> modes (RGMII/SGMII) and restart the ANE.
>> Both TBI and RTBI are not yet supported.
>>
> [snip]
> .
>> /**
>> * stmmac_init_phy - PHY initialization
>> * @dev: net device structure
>> @@ -1141,10 +1159,13 @@ static int stmmac_open(struct net_device *dev)
>>
>> stmmac_check_ether_addr(priv);
>>
>> - ret = stmmac_init_phy(dev);
>> - if (unlikely(ret)) {
>> - pr_err("%s: Cannot attach to PHY (error: %d)\n", __func__,
>> ret);
>> - goto open_error;
>> + if (!priv->pcs) {
>> + ret = stmmac_init_phy(dev);
>> + if (ret) {
>> + pr_err("%s: Cannot attach to PHY (error: %d)\n",
>> + __func__, ret);
>> + goto open_error;
>> + }
>> }
>>
> I think, even though SGMII do auto-negotiation with phy, stmmac_init_phy
> function is needed. In this condition "if (!priv->pcs)", SGMII platform
> can't attach phy.
> IMO, it is same in case of stmmac_mdio_register(ndev).
> In my platform, I modified this condition for SGMII like below.
> if (priv->pcs != STMMAC_PCS_RGMII && priv->pcs STMMAC_PCS_TBI &&
> priv->pcs != STMMAC_PCS_RTBI)
pls can you send a patch for this on top of net-next branch (with me on Cc)?
Indeed for sgmii I expected to also manage ane w/o invoking the PAL.
As you know I have no SGMII hw where test; at any rate I will check
again asap.
peppe
>
>> /* Create and initialize the TX/RX descriptors chains. */
>> @@ -1233,7 +1254,12 @@ static int stmmac_open(struct net_device *dev)
>> phy_start(priv->phydev);
>>
>> priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS_TIMER;
>> - priv->eee_enabled = stmmac_eee_init(priv);
>> +
>> + /* Using PCS we cannot dial with the phy registers at this stage
>> + * so we do not support extra feature like EEE.
>> + */
>> + if (!priv->pcs)
>> + priv->eee_enabled = stmmac_eee_init(priv);
>>
>> stmmac_init_tx_coalesce(priv);
>>
>> @@ -1242,6 +1268,9 @@ static int stmmac_open(struct net_device *dev)
>> priv->hw->dma->rx_watchdog(priv->ioaddr, MAX_DMA_RIWT);
>> }
>>
>> + if (priv->pcs && priv->hw->mac->ctrl_ane)
>> + priv->hw->mac->ctrl_ane(priv->ioaddr, 0);
>> +
>> napi_enable(&priv->napi);
>> netif_start_queue(dev);
>>
>> @@ -2225,12 +2254,16 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
>> *device,
>> else
>> priv->clk_csr = priv->plat->clk_csr;
>>
>> - /* MDIO bus Registration */
>> - ret = stmmac_mdio_register(ndev);
>> - if (ret < 0) {
>> - pr_debug("%s: MDIO bus (id: %d) registration failed",
>> - __func__, priv->plat->bus_id);
>> - goto error_mdio_register;
>> + stmmac_check_pcs_mode(priv);
>> +
>> + if (!priv->pcs) {
>> + /* MDIO bus Registration */
>> + ret = stmmac_mdio_register(ndev);
>> + if (ret < 0) {
>> + pr_debug("%s: MDIO bus (id: %d) registration
> failed",
>> + __func__, priv->plat->bus_id);
>> + goto error_mdio_register;
>> + }
>> }
>>
>> return priv;
>> @@ -2263,7 +2296,8 @@ int stmmac_dvr_remove(struct net_device *ndev)
>> priv->hw->dma->stop_tx(priv->ioaddr);
>>
>> stmmac_set_mac(priv->ioaddr, false);
>> - stmmac_mdio_unregister(ndev);
>> + if (!priv->pcs)
>> + stmmac_mdio_unregister(ndev);
>> netif_carrier_off(ndev);
>> unregister_netdev(ndev);
>> free_netdev(ndev);
>> --
>> 1.7.4.4
>>
>> --
>> 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 Resend] core: should call pskb_expand_head if skb header is cloned in skb_gso_segment in rx path
From: Cong Wang @ 2013-04-02 12:32 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1364783861-3363-1-git-send-email-roy.qing.li@gmail.com>
On Mon, 2013-04-01 at 10:37 +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> 12b0004d1d1 (adjust skb_gso_segment() for calling in rx path) tries to kill warnings
> by checking if ip_summed is CHECK_NONE or not in rx path, since if skb_gso_segment()
> is called on rx path, and ->ip_summed has different meaning.
>
> but this maybe break skb if skb header is cloned, and not expand the header, since when
> step into skb_mac_gso_segment(), which will still check ip_summed with CHECKSUM_PARTIAL,
> then do gso_send_check(). and after __skb_gso_segment() in queue_gso_packets() of
> openvswitch, queue_userspace_packet() still checks ip_summed with CHECKSUM_PARTIAL,
> and do checksum.
>
> so I think it is enough to ignore the warning in rx path.
>
Did you see any bogus warning triggered by it?
BTW, please Cc all the people involved in the original commit you
mentioned above.
^ permalink raw reply
* Re: [Patch net-next v1 3/4] vxlan: add ipv6 support
From: David Stevens @ 2013-04-02 13:13 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev, netdev-owner, stephen
In-Reply-To: <1364867203.17029.7.camel@cr0>
Cong Wang <amwang@redhat.com> wrote on 04/01/2013 09:46:43 PM:
> Well, besides avoid redefining another type, what else could we gain by
> using sockaddr_in6?
The gain is code readability. If you have a type that's
already defined and used throughout the network code, someone
trying to understand your code won't need to look up the type
and details to figure it out and modify it.
> Look, we would have "vip->vip_sin.sin_addr.s_addr" instead of
> "ipa->ip4", much longer than the current one...
>
> So why defining a shorter and less complex struct matters?
>
>
Because you have entire sections of nearly duplicated
code that handle IPv4 alone or IPv6 alone. That's a maintenance
issue over time because future changes need to happen in 2
separate places and are more likely to be missed in one or
not replicated identically.
Using sockaddrs, the field containing an address is
the same (e.g., "gaddr" or "dst") whether it is v4 or v6
because the structure self-identifies the address format
by the address family. So, you can have common code for
either address family -- "vxlan->gaddr = group;" or similar--
and you only have family-specific code where there is a
difference between the families.
VXLAN is an in-kernel client and server and like its
user-space counterparts, you can write a v4-only implementation
and a v6-only implementation separately, or you can use common code
for both with generic addresses. Using common code is usually
easier to understand, modify and debug.
+-DLS
^ permalink raw reply
* Re-confirm
From: support @ 2013-04-02 9:27 UTC (permalink / raw)
This is a personal email directed to you. I am Adrian Bayford,I and my
wife won a Jackpot Lottery of 148 million pounds in the latest
Euromillion Lottery result that was announced recently. If you get this
mail, I want you to consider yourself lucky.Kindly provide the requried
details of yours for claims(click reply )
NAME-----
ADDRESS------
MOBILE-----------
AGE------------
KINDLY VIEW LINK FOR PROPER
UNDERSTANDING(http://www.bbc.co.uk/news/uk-england-19254228) We await your
response in this regards
^ permalink raw reply
* intel 82580 nic hang problem.
From: Peter Huang(Peng) @ 2013-04-02 13:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Majun, netdev, Zhoukang
Hi Eric
Here I have a nic hang problem in our customer environment, from Intel's 82575
driver release notes, there was a similar problem, but only occurred with older
linux 2.6 kernel ( we are using 3.0.13-0.27-xen kernel).
We are using 82580 dual port NIC:
#ethtool -i eth1
driver: igb
version: 3.0.6-k2
firmware-version: 3.2-9
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
Below is the error message (this msg will repeated over 8 hours):
Mar 28 10:46:25 CNA001_0_010203 kernel: [ 4412.812078] igb 0000:02:00.1: eth1: Reset adapter
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816189] igb 0000:02:00.1: Detected Tx Unit Hang
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816191] Tx Queue <1>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816191] TDH <0>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816192] TDT <2>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816192] next_to_use <2>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816193] next_to_clean <0>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816193] buffer_info[next_to_clean]
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816194] time_stamp <1000fb54c>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816194] next_to_watch <0>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816195] jiffies <1000fb649>
Mar 28 10:46:31 CNA001_0_010203 kernel: [ 4418.816196] desc.status <118000>
Are you familiar with this problem, or could you give us any suggestion to move on?
Thanks very much!
Peter.Huang
^ permalink raw reply
* [PATCH net-next] ipconfig: add informative timeout messages while waiting for carrier
From: Paul Gortmaker @ 2013-04-02 13:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul Gortmaker
Commit 3fb72f1e6e6165c5f495e8dc11c5bbd14c73385c ("ipconfig wait
for carrier") added a "wait for carrier on at least one interface"
policy, with a worst case maximum wait of two minutes.
However, if you encounter this, you won't get any feedback from
the console as to the nature of what is going on. You just see
the booting process hang for two minutes and then continue.
Here we add a message so the user knows what is going on, and
hence can take action to rectify the situation (e.g. fix network
cable or whatever.) After the 1st 10s pause, output now begins
that looks like this:
Waiting up to 110 more seconds for network.
Waiting up to 100 more seconds for network.
Waiting up to 90 more seconds for network.
Waiting up to 80 more seconds for network.
...
Since most systems will have no problem getting link/carrier in the
1st 10s, the only people who will see these messages are people with
genuine issues that need to be resolved.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/ipv4/ipconfig.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index bf6c5cf..efa1138 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -206,7 +206,7 @@ static int __init ic_open_devs(void)
struct ic_device *d, **last;
struct net_device *dev;
unsigned short oflags;
- unsigned long start;
+ unsigned long start, next_msg;
last = &ic_first_dev;
rtnl_lock();
@@ -263,12 +263,23 @@ static int __init ic_open_devs(void)
/* wait for a carrier on at least one device */
start = jiffies;
+ next_msg = start + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
while (jiffies - start < msecs_to_jiffies(CONF_CARRIER_TIMEOUT)) {
+ int wait, elapsed;
+
for_each_netdev(&init_net, dev)
if (ic_is_init_dev(dev) && netif_carrier_ok(dev))
goto have_carrier;
msleep(1);
+
+ if time_before(jiffies, next_msg)
+ continue;
+
+ elapsed = jiffies_to_msecs(jiffies - start);
+ wait = (CONF_CARRIER_TIMEOUT - elapsed + 500)/1000;
+ pr_info("Waiting up to %d more seconds for network.\n", wait);
+ next_msg = jiffies + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
}
have_carrier:
rtnl_unlock();
--
1.8.1.2
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8188ee: Fix wrong header patch
From: Chen, Chien-Chia @ 2013-04-02 14:01 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
zhiyuan_yang-kXabqFNEczNtrwSWzY7KCg,
page_he-kXabqFNEczNtrwSWzY7KCg,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
From: "Chen, Chien-Chia" <machen-IBi9RG/b67k@public.gmane.org>
This patch is to fix some wrong header file path.
It has caused the build failed.
Signed-off-by: Chen, Chien-Chia <machen-IBi9RG/b67k@public.gmane.org>
Cc: larry.finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org
Cc: zhiyuan_yang-kXabqFNEczNtrwSWzY7KCg@public.gmane.org
Cc: page_he-kXabqFNEczNtrwSWzY7KCg@public.gmane.org
Cc: mmarek-AlSwsSmVLrQ@public.gmane.org
---
drivers/net/wireless/rtlwifi/rtl8188ee/dm.c | 6 +++---
drivers/net/wireless/rtlwifi/rtl8188ee/fw.c | 6 +++---
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 14 +++++++-------
drivers/net/wireless/rtlwifi/rtl8188ee/led.c | 4 ++--
drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 6 +++---
drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h | 2 +-
drivers/net/wireless/rtlwifi/rtl8188ee/rf.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8188ee/sw.c | 6 +++---
drivers/net/wireless/rtlwifi/rtl8188ee/trx.c | 8 ++++----
9 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c b/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
index 0a338cc..21a5cf0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
@@ -27,9 +27,9 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "base.h"
-#include "pci.h"
+#include "../wifi.h"
+#include "../base.h"
+#include "../pci.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
index 66ff30b..57e4cc5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
@@ -27,9 +27,9 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "pci.h"
-#include "base.h"
+#include "../wifi.h"
+#include "../pci.h"
+#include "../base.h"
#include "reg.h"
#include "def.h"
#include "fw.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index d734d19..0f464d0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -27,13 +27,13 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "efuse.h"
-#include "base.h"
-#include "regd.h"
-#include "cam.h"
-#include "ps.h"
-#include "pci.h"
+#include "../wifi.h"
+#include "../efuse.h"
+#include "../base.h"
+#include "../regd.h"
+#include "../cam.h"
+#include "../ps.h"
+#include "../pci.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/led.c b/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
index 95d42af..c81a9cb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
@@ -27,8 +27,8 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "pci.h"
+#include "../wifi.h"
+#include "../pci.h"
#include "reg.h"
#include "led.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
index c285631..224f801 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
@@ -27,9 +27,9 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "pci.h"
-#include "ps.h"
+#include "../wifi.h"
+#include "../pci.h"
+#include "../ps.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h b/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
index 622ea7e..70456ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
@@ -30,7 +30,7 @@
#ifndef __RTL8723E_PWRSEQCMD_H__
#define __RTL8723E_PWRSEQCMD_H__
-#include "wifi.h"
+#include "../wifi.h"
/*---------------------------------------------*/
/* The value of cmd: 4 bits */
/*---------------------------------------------*/
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
index e62bcab..4faafdb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
@@ -27,7 +27,7 @@
*
*****************************************************************************/
-#include "wifi.h"
+#include "../wifi.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
index e8ce189..c254693 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
@@ -27,9 +27,9 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "core.h"
-#include "pci.h"
+#include "../wifi.h"
+#include "../core.h"
+#include "../pci.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
index 2518531..d075237 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
@@ -27,10 +27,10 @@
*
*****************************************************************************/
-#include "wifi.h"
-#include "pci.h"
-#include "base.h"
-#include "stats.h"
+#include "../wifi.h"
+#include "../pci.h"
+#include "../base.h"
+#include "../stats.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net] net/mlx4_en: Fix setting initial MAC address
From: Yan Burman @ 2013-04-02 13:49 UTC (permalink / raw)
To: netdev; +Cc: Yan Burman, Or Gerlitz, Amir Vadai
Commit 6bbb6d9 "net/mlx4_en: Optimize Rx fast path filter checks" introduced a regression
under which the MAC address read from the card was not converted correctly
(the most significant byte was not handled), fix that.
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yan Burman <yanb@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index f278b10..30d78f8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -411,8 +411,8 @@ static int mlx4_en_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
static void mlx4_en_u64_to_mac(unsigned char dst_mac[ETH_ALEN + 2], u64 src_mac)
{
- unsigned int i;
- for (i = ETH_ALEN - 1; i; --i) {
+ int i;
+ for (i = ETH_ALEN - 1; i >= 0; --i) {
dst_mac[i] = src_mac & 0xff;
src_mac >>= 8;
}
--
1.7.10.1
^ permalink raw reply related
* [PATCH] bonding: get netdev_rx_handler_unregister out of locks
From: Veaceslav Falico @ 2013-04-02 15:15 UTC (permalink / raw)
To: netdev; +Cc: vfalico, fubar, andy, edumazet
Now that netdev_rx_handler_unregister contains synchronize_net(), we need
to call it outside of bond->lock, cause it might sleep. Also, remove the
already unneded synchronize_net().
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 11a8cb3..78c9e2d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1975,12 +1975,11 @@ static int __bond_release_one(struct net_device *bond_dev,
return -EINVAL;
}
+ write_unlock_bh(&bond->lock);
/* unregister rx_handler early so bond_handle_frame wouldn't be called
* for this slave anymore.
*/
netdev_rx_handler_unregister(slave_dev);
- write_unlock_bh(&bond->lock);
- synchronize_net();
write_lock_bh(&bond->lock);
if (!all && !bond->params.fail_over_mac) {
--
1.7.1
^ permalink raw reply related
* Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking
From: Jesper Dangaard Brouer @ 2013-04-02 15:23 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Eric Dumazet, David S. Miller, netdev, Florian Westphal,
Daniel Borkmann
In-Reply-To: <1364583693.3232.257.camel@localhost>
On Fri, 2013-03-29 at 20:01 +0100, Jesper Dangaard Brouer wrote:
> I'm officially back from vacation Tuesday, and I'll repost then (after
> testing it on my 10G testlab).
Argh- just deleted a long mail with a lot of test results, showing
strange performance results ... as I just realized that /boot ran dry
during my testing procedure, thus invalidating all the test I spend most
of the day performing, argh!
--Jesper
^ permalink raw reply
* How to find an available TCP port
From: Teto @ 2013-04-02 15:25 UTC (permalink / raw)
To: netdev
Hi,
I would like to do deterministic port-based load balancing, that is
choosing a free port number N so that N % K = X while knowing K and X.
Since I am patching a specific implementation, I would like to check
the availibility of the port without having to check bind() return
value.
I believe the function tcp_lport_inuse ( in this file
http://www.cab.u-szeged.hu/linux/kernel/linux/net/ipv4/tcp.c.html)
does what I wish. I would like to call it from another file but it is
static. So here are my questions:
1st/ Is that the correct function ?
2/ How to use it in another src file ? or do you have any other workaround ?
Sorry if that's too noobish a question, I am not used to kernel
development (yet). I f that's the case redirect me to the proper
mailing list.
Best regards
Matt
^ permalink raw reply
* Re: [PATCH] bonding: get netdev_rx_handler_unregister out of locks
From: Eric Dumazet @ 2013-04-02 15:26 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, fubar, andy, edumazet
In-Reply-To: <1364915716-4857-1-git-send-email-vfalico@redhat.com>
On Tue, 2013-04-02 at 17:15 +0200, Veaceslav Falico wrote:
> Now that netdev_rx_handler_unregister contains synchronize_net(), we need
> to call it outside of bond->lock, cause it might sleep. Also, remove the
> already unneded synchronize_net().
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
> ---
> drivers/net/bonding/bond_main.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 11a8cb3..78c9e2d 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1975,12 +1975,11 @@ static int __bond_release_one(struct net_device *bond_dev,
> return -EINVAL;
> }
>
> + write_unlock_bh(&bond->lock);
> /* unregister rx_handler early so bond_handle_frame wouldn't be called
> * for this slave anymore.
> */
> netdev_rx_handler_unregister(slave_dev);
> - write_unlock_bh(&bond->lock);
> - synchronize_net();
> write_lock_bh(&bond->lock);
>
> if (!all && !bond->params.fail_over_mac) {
Good catch, thanks !
Acked-by: Eric Dumazet <edumazet@google.com>
I'll send a net-next patch to remove the synchronize_net() from bridge
code as well.
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8188ee: Fix wrong header patch
From: Larry Finger @ 2013-04-02 15:32 UTC (permalink / raw)
To: Chen, Chien-Chia; +Cc: linux-wireless, linville, netdev, zhiyuan_yang, page_he
In-Reply-To: <1364911315-3601-1-git-send-email-machen@suse.com>
On 04/02/2013 09:01 AM, Chen, Chien-Chia wrote:
> From: "Chen, Chien-Chia" <machen@suse.com>
>
> This patch is to fix some wrong header file path.
> It has caused the build failed.
>
> Signed-off-by: Chen, Chien-Chia <machen@suse.com>
> Cc: larry.finger@lwfinger.net
> Cc: zhiyuan_yang@realsil.com.cn
> Cc: page_he@realsil.com.cn
> Cc: mmarek@suse.cz
ACK this for the interim. I still plan to remove all the relative paths for the
headers. Maybe I will get it right next time.
Larry
> ---
> drivers/net/wireless/rtlwifi/rtl8188ee/dm.c | 6 +++---
> drivers/net/wireless/rtlwifi/rtl8188ee/fw.c | 6 +++---
> drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 14 +++++++-------
> drivers/net/wireless/rtlwifi/rtl8188ee/led.c | 4 ++--
> drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 6 +++---
> drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h | 2 +-
> drivers/net/wireless/rtlwifi/rtl8188ee/rf.c | 2 +-
> drivers/net/wireless/rtlwifi/rtl8188ee/sw.c | 6 +++---
> drivers/net/wireless/rtlwifi/rtl8188ee/trx.c | 8 ++++----
> 9 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c b/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
> index 0a338cc..21a5cf0 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/dm.c
> @@ -27,9 +27,9 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "base.h"
> -#include "pci.h"
> +#include "../wifi.h"
> +#include "../base.h"
> +#include "../pci.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
> index 66ff30b..57e4cc5 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/fw.c
> @@ -27,9 +27,9 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "pci.h"
> -#include "base.h"
> +#include "../wifi.h"
> +#include "../pci.h"
> +#include "../base.h"
> #include "reg.h"
> #include "def.h"
> #include "fw.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> index d734d19..0f464d0 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> @@ -27,13 +27,13 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "efuse.h"
> -#include "base.h"
> -#include "regd.h"
> -#include "cam.h"
> -#include "ps.h"
> -#include "pci.h"
> +#include "../wifi.h"
> +#include "../efuse.h"
> +#include "../base.h"
> +#include "../regd.h"
> +#include "../cam.h"
> +#include "../ps.h"
> +#include "../pci.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/led.c b/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
> index 95d42af..c81a9cb 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/led.c
> @@ -27,8 +27,8 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "pci.h"
> +#include "../wifi.h"
> +#include "../pci.h"
> #include "reg.h"
> #include "led.h"
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
> index c285631..224f801 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
> @@ -27,9 +27,9 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "pci.h"
> -#include "ps.h"
> +#include "../wifi.h"
> +#include "../pci.h"
> +#include "../ps.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h b/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
> index 622ea7e..70456ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/pwrseqcmd.h
> @@ -30,7 +30,7 @@
> #ifndef __RTL8723E_PWRSEQCMD_H__
> #define __RTL8723E_PWRSEQCMD_H__
>
> -#include "wifi.h"
> +#include "../wifi.h"
> /*---------------------------------------------*/
> /* The value of cmd: 4 bits */
> /*---------------------------------------------*/
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
> index e62bcab..4faafdb 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.c
> @@ -27,7 +27,7 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> +#include "../wifi.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> index e8ce189..c254693 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> @@ -27,9 +27,9 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "core.h"
> -#include "pci.h"
> +#include "../wifi.h"
> +#include "../core.h"
> +#include "../pci.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
> index 2518531..d075237 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
> @@ -27,10 +27,10 @@
> *
> *****************************************************************************/
>
> -#include "wifi.h"
> -#include "pci.h"
> -#include "base.h"
> -#include "stats.h"
> +#include "../wifi.h"
> +#include "../pci.h"
> +#include "../base.h"
> +#include "../stats.h"
> #include "reg.h"
> #include "def.h"
> #include "phy.h"
>
^ permalink raw reply
* Re: [patch 1/2] af_iucv: recvmsg: use correct skb_pull() function
From: Eric Dumazet @ 2013-04-02 15:37 UTC (permalink / raw)
To: frank.blaschka; +Cc: davem, netdev, linux-s390, Hendrik Brueckner
In-Reply-To: <20130402105707.116460653@de.ibm.com>
On Tue, 2013-04-02 at 12:56 +0200, frank.blaschka@de.ibm.com wrote:
> plain text document attachment (601-af-iucv-skb-pull.diff)
> From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
>
> When receiving data messages, the "BUG_ON(skb->len < skb->data_len)" in
> the skb_pull() function triggers a kernel panic.
>
> Check if the skb uses paged data (is non-linear) and use the pskb_pull()
> function. Use skb_pull() for linear skbs' only.
>
> Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
> Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
> Signed-off-by: Frank Blaschka <blaschka@linux.vnet.ibm.com>
> ---
> net/iucv/af_iucv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/net/iucv/af_iucv.c
> +++ b/net/iucv/af_iucv.c
> @@ -1382,7 +1382,10 @@ static int iucv_sock_recvmsg(struct kioc
>
> /* SOCK_STREAM: re-queue skb if it contains unreceived data */
> if (sk->sk_type == SOCK_STREAM) {
> - skb_pull(skb, copied);
> + if (skb_is_nonlinear(skb))
> + pskb_pull(skb, copied);
> + else
> + skb_pull(skb, copied);
> if (skb->len) {
> skb_queue_head(&sk->sk_receive_queue, skb);
> goto done;
That cant be right. You can not ignore pskb_pull() return value.
Its also not very efficient.
I would advise using a per skb offset, to avoid skb_pull()
^ permalink raw reply
* [PATCH net-next] bridge: remove a redundant synchronize_net()
From: Eric Dumazet @ 2013-04-02 15:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Veaceslav Falico, Stephen Hemminger
From: Eric Dumazet <edumazet@google.com>
commit 00cfec37484761 (net: add a synchronize_net() in
netdev_rx_handler_unregister())
allows us to remove the synchronized_net() call from del_nbp()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/bridge/br_if.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index ef1b914..f17fcb3 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -148,7 +148,6 @@ static void del_nbp(struct net_bridge_port *p)
dev->priv_flags &= ~IFF_BRIDGE_PORT;
netdev_rx_handler_unregister(dev);
- synchronize_net();
netdev_upper_dev_unlink(dev, br->dev);
^ permalink raw reply related
* Re: [PATCH] bonding: get netdev_rx_handler_unregister out of locks
From: Veaceslav Falico @ 2013-04-02 15:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, fubar, andy, edumazet
In-Reply-To: <1364916362.5113.167.camel@edumazet-glaptop>
On Tue, Apr 02, 2013 at 08:26:02AM -0700, Eric Dumazet wrote:
>On Tue, 2013-04-02 at 17:15 +0200, Veaceslav Falico wrote:
>> Now that netdev_rx_handler_unregister contains synchronize_net(), we need
>> to call it outside of bond->lock, cause it might sleep. Also, remove the
>> already unneded synchronize_net().
>>
>> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
>> ---
>> drivers/net/bonding/bond_main.c | 3 +--
>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 11a8cb3..78c9e2d 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -1975,12 +1975,11 @@ static int __bond_release_one(struct net_device *bond_dev,
>> return -EINVAL;
>> }
>>
>> + write_unlock_bh(&bond->lock);
>> /* unregister rx_handler early so bond_handle_frame wouldn't be called
>> * for this slave anymore.
>> */
>> netdev_rx_handler_unregister(slave_dev);
>> - write_unlock_bh(&bond->lock);
>> - synchronize_net();
>> write_lock_bh(&bond->lock);
>>
>> if (!all && !bond->params.fail_over_mac) {
>
>Good catch, thanks !
>
>Acked-by: Eric Dumazet <edumazet@google.com>
>
>I'll send a net-next patch to remove the synchronize_net() from bridge
>code as well.
Nice, when I've checked it not to be under other locks I've somehow missed
the part where the bridge calls synchronize_net() right after it.
Thank you!
>
>
>
^ permalink raw reply
* Re: Freescale FEC: fall back to random address
From: David Miller @ 2013-04-02 15:49 UTC (permalink / raw)
To: lznuaa; +Cc: pavel, linux-kernel, fabio.estevam, l.stach, Frank.Li, netdev
In-Reply-To: <CAHrpEqTdTnRx_htZkFyG2KU5wixdhqmWZ-3R5s=fdedQYc6D9w@mail.gmail.com>
From: Frank Li <lznuaa@gmail.com>
Date: Tue, 2 Apr 2013 21:23:17 +0800
> David will merge it
Someone needs to make a clean resubmission of it though, thanks.
^ permalink raw reply
* [PATCH net-next 3/4] qlcnic: Fix sparse warnings.
From: Rajesh Borundia @ 2013-04-02 15:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1364916883-10109-1-git-send-email-rajesh.borundia@qlogic.com>
warning: 'pf_info.max_tx_ques' may be used uninitialized in this function
[-Wmaybe-uninitialized]
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
index d6ac7dc..bed5056 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
@@ -156,6 +156,7 @@ static int qlcnic_sriov_get_pf_info(struct qlcnic_adapter *adapter,
npar_info->max_local_ipv6_addrs = LSW(cmd.rsp.arg[8]);
npar_info->max_remote_ipv6_addrs = MSW(cmd.rsp.arg[8]);
+ qlcnic_sriov_pf_set_ff_max_res(adapter, npar_info);
dev_info(&adapter->pdev->dev,
"\n\ttotal_pf: %d,\n"
"\n\ttotal_rss_engines: %d max_vports: %d max_tx_ques %d,\n"
@@ -376,8 +377,6 @@ static int qlcnic_sriov_pf_init(struct qlcnic_adapter *adapter)
if (err)
goto delete_vport;
- qlcnic_sriov_pf_set_ff_max_res(adapter, &pf_info);
-
err = qlcnic_get_nic_info(adapter, &nic_info, func);
if (err)
goto delete_vport;
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 4/4] qlcnic: Bump up the version to 5.2.40
From: Rajesh Borundia @ 2013-04-02 15:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1364916883-10109-1-git-send-email-rajesh.borundia@qlogic.com>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index e5af69d..ef55718 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -38,8 +38,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 2
-#define _QLCNIC_LINUX_SUBVERSION 39
-#define QLCNIC_LINUX_VERSIONID "5.2.39"
+#define _QLCNIC_LINUX_SUBVERSION 40
+#define QLCNIC_LINUX_VERSIONID "5.2.40"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 1/4] qlcnic: Fix potential NULL dereference
From: Rajesh Borundia @ 2013-04-02 15:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1364916883-10109-1-git-send-email-rajesh.borundia@qlogic.com>
[net-next:master 301/302] drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c:563
qlcnic_set_multi() error: potential null dereference 'cur'. (kzalloc returns null)
o Break out of the loop after memory allocation failure. Program all the
MAC addresses that were cached in the return path.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index ddc130b..253b3ac 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -560,6 +560,8 @@ void qlcnic_set_multi(struct net_device *netdev)
netdev_for_each_mc_addr(ha, netdev) {
cur = kzalloc(sizeof(struct qlcnic_mac_list_s),
GFP_ATOMIC);
+ if (cur == NULL)
+ break;
memcpy(cur->mac_addr,
ha->addr, ETH_ALEN);
list_add_tail(&cur->list, &adapter->vf_mc_list);
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 2/4] qlcnic: Fix NULL dereference in error path.
From: Rajesh Borundia @ 2013-04-02 15:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1364916883-10109-1-git-send-email-rajesh.borundia@qlogic.com>
o Fix for smatch tool reported error
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c:2029
qlcnic_probe() error: potential NULL dereference 'adapter'.
o While returning from an error path in probe, adapter is not
initialized. So do not access adapter in cleanup path.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 3ee593e..0d00b2b 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -546,11 +546,10 @@ void qlcnic_teardown_intr(struct qlcnic_adapter *adapter)
}
}
-static void
-qlcnic_cleanup_pci_map(struct qlcnic_adapter *adapter)
+static void qlcnic_cleanup_pci_map(struct qlcnic_hardware_context *ahw)
{
- if (adapter->ahw->pci_base0 != NULL)
- iounmap(adapter->ahw->pci_base0);
+ if (ahw->pci_base0 != NULL)
+ iounmap(ahw->pci_base0);
}
static int qlcnic_get_act_pci_func(struct qlcnic_adapter *adapter)
@@ -2026,7 +2025,7 @@ err_out_free_netdev:
free_netdev(netdev);
err_out_iounmap:
- qlcnic_cleanup_pci_map(adapter);
+ qlcnic_cleanup_pci_map(ahw);
err_out_free_hw_res:
kfree(ahw);
@@ -2083,7 +2082,7 @@ static void qlcnic_remove(struct pci_dev *pdev)
qlcnic_remove_sysfs(adapter);
- qlcnic_cleanup_pci_map(adapter);
+ qlcnic_cleanup_pci_map(adapter->ahw);
qlcnic_release_firmware(adapter);
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 0/4] qlcnic: Bug Fixes
From: Rajesh Borundia @ 2013-04-02 15:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
Please apply it to net-next.
Rajesh Borundia (4):
qlcnic: Fix potential NULL dereference
qlcnic: Fix NULL dereference in error path.
qlcnic: Fix sparse warnings.
qlcnic: Bump up the version to 5.2.40
^ 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