* [PATCH] drivers/net: use is_zero_ether_addr() instead of memcmp()
From: Wei Yongjun @ 2012-08-23 7:16 UTC (permalink / raw)
To: j, linville; +Cc: yongjun_wei, linux-wireless, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/hostap/hostap_info.c | 4 ++--
drivers/net/wireless/hostap/hostap_main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_info.c b/drivers/net/wireless/hostap/hostap_info.c
index 47932b2..970a48b 100644
--- a/drivers/net/wireless/hostap/hostap_info.c
+++ b/drivers/net/wireless/hostap/hostap_info.c
@@ -4,6 +4,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/export.h>
+#include <linux/etherdevice.h>
#include "hostap_wlan.h"
#include "hostap.h"
#include "hostap_ap.h"
@@ -463,8 +464,7 @@ static void handle_info_queue_scanresults(local_info_t *local)
prism2_host_roaming(local);
if (local->host_roaming == 2 && local->iw_mode == IW_MODE_INFRA &&
- memcmp(local->preferred_ap, "\x00\x00\x00\x00\x00\x00",
- ETH_ALEN) != 0) {
+ !is_zero_ether_addr(local->preferred_ap)) {
/*
* Firmware seems to be getting into odd state in host_roaming
* mode 2 when hostscan is used without join command, so try
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 627bc12..15f0fad 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -1084,7 +1084,7 @@ int prism2_sta_deauth(local_info_t *local, u16 reason)
__le16 val = cpu_to_le16(reason);
if (local->iw_mode != IW_MODE_INFRA ||
- memcmp(local->bssid, "\x00\x00\x00\x00\x00\x00", ETH_ALEN) == 0 ||
+ is_zero_ether_addr(local->bssid) ||
memcmp(local->bssid, "\x44\x44\x44\x44\x44\x44", ETH_ALEN) == 0)
return 0;
^ permalink raw reply related
* Re: [PATCH v2] net: add new QCA alx ethernet driver
From: David Miller @ 2012-08-23 7:13 UTC (permalink / raw)
To: xiong; +Cc: cjren, netdev, linux-kernel, qca-linux-team, nic-devel, rodrigue
In-Reply-To: <157393863283F442885425D2C45428562A4F519A@nasanexd02f.na.qualcomm.com>
From: "Huang, Xiong" <xiong@qca.qualcomm.com>
Date: Thu, 23 Aug 2012 06:56:51 +0000
> I'm afraid someone also rejects my request to add such operation to
> ethtool
If you don't design it properly, we certainly will ask you to make
changes.
But it stands a chance of actually being accepted, whereas your
debugfs thing absolutely does not.
^ permalink raw reply
* Re: [PATCH net-next v3] net: remove delay at device dismantle
From: Eric Dumazet @ 2012-08-23 7:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, gaofeng, netdev, maheshb, therbert
In-Reply-To: <87txvum80h.fsf@xmission.com>
On Wed, 2012-08-22 at 23:34 -0700, Eric W. Biederman wrote:
> raw_notifier_call_chain isn't safe without holding some sort of lock.
> So removing the ASSERT_RTNL assert here is papering over a bug elsewhere
> in this patch.
>
> Without holding a lock for traversing the notifier chain there will
> be races with network module load and unload that could corrupt
> this list while we are traversing it.
> load/unlod.
>
> You already have one of your NETDEV_UNREGISTER_FINAL calls under the
> rtnl_lock so it doesn't look like a burden to put the other call under
> the rtnl_lock as well.
Hmm right, I have been fooled by the rcu_dereference_raw() calls in
notifier_call_chain()
I'll send an update, thanks !
^ permalink raw reply
* RE: [PATCH v2] net: add new QCA alx ethernet driver
From: Huang, Xiong @ 2012-08-23 6:56 UTC (permalink / raw)
To: David Miller
Cc: Ren, Cloud, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
qca-linux-team, nic-devel, Rodriguez, Luis
In-Reply-To: <20120822.234019.1546353507351890178.davem@davemloft.net>
>
> Then add a new ethtool operation to support your use case, that's exactly
> what I was telling you to do.
>
> Did it really not occur to you that you perhaps you should extend existing
> generic facilities to suit your needs instead of creating private facilities that no
> other driver can use?
I'm afraid someone also rejects my request to add such operation to ethtool
By your same reason.
before adding this interface, we had searched the kernel, marvell driver also
Uses it, we had thought could be ok.
Of course, we will respect your opinion if it's not appropriated.
Thanks
Xiong
^ permalink raw reply
* Re: TIPC handling of ethernet mac address change
From: Ying Xue @ 2012-08-23 6:56 UTC (permalink / raw)
To: Chris Friesen; +Cc: Allan Stephens, Jon Maloy, netdev
In-Reply-To: <5034FC88.8030403@genband.com>
Hi Chris,
You are right.
Currently TIPC does not handle the change of mac address.
So I will submit a related patch to fix the issue to net-next tree.
Thanks for your report.
Regards,
Ying
Chris Friesen wrote:
> Hi,
>
> I'm pretty new to tipc so pardon me if I use the wrong terminology. :)
>
> I'm using TIPC 1.7.7 and bonding. I'm seeing some strange behaviour
> when the bond MAC address changes--the tipc LINK_CONFIG messages still
> contain the old MAC address embedded in them. This causes the other
> end to send back to us on the wrong MAC and the packets get dropped.
>
> I see recv_notification() has a case for NETDEV_CHANGEADDR so it looks
> like MAC address change was intended to be handled, but I'm not
> entirely clear on where the MAC address is supposed to be changed.
>
> Any assistance on debugging/patching this would be appreciated.
>
> Chris
>
>
^ permalink raw reply
* [PATCH] orinoco: use is_zero_ether_addr() instead of memcmp()
From: Wei Yongjun @ 2012-08-23 6:55 UTC (permalink / raw)
To: linville; +Cc: yongjun_wei, linux-wireless, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/orinoco/wext.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/orinoco/wext.c b/drivers/net/wireless/orinoco/wext.c
index 33747e1..3b5508f 100644
--- a/drivers/net/wireless/orinoco/wext.c
+++ b/drivers/net/wireless/orinoco/wext.c
@@ -7,6 +7,7 @@
#include <linux/if_arp.h>
#include <linux/wireless.h>
#include <linux/ieee80211.h>
+#include <linux/etherdevice.h>
#include <net/iw_handler.h>
#include <net/cfg80211.h>
#include <net/cfg80211-wext.h>
@@ -159,15 +160,13 @@ static int orinoco_ioctl_setwap(struct net_device *dev,
struct orinoco_private *priv = ndev_priv(dev);
int err = -EINPROGRESS; /* Call commit handler */
unsigned long flags;
- static const u8 off_addr[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
- static const u8 any_addr[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
if (orinoco_lock(priv, &flags) != 0)
return -EBUSY;
/* Enable automatic roaming - no sanity checks are needed */
- if (memcmp(&ap_addr->sa_data, off_addr, ETH_ALEN) == 0 ||
- memcmp(&ap_addr->sa_data, any_addr, ETH_ALEN) == 0) {
+ if (is_zero_ether_addr(ap_addr->sa_data) ||
+ is_broadcast_ether_addr(ap_addr->sa_data)) {
priv->bssid_fixed = 0;
memset(priv->desired_bssid, 0, ETH_ALEN);
^ permalink raw reply related
* [PATCH] mwifiex: use is_zero_ether_addr() instead of memcmp()
From: Wei Yongjun @ 2012-08-23 6:54 UTC (permalink / raw)
To: bzhao, linville; +Cc: yongjun_wei, linux-wireless, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/mwifiex/sta_cmdresp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sta_cmdresp.c b/drivers/net/wireless/mwifiex/sta_cmdresp.c
index 0b09004..a2a33dc 100644
--- a/drivers/net/wireless/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/mwifiex/sta_cmdresp.c
@@ -17,6 +17,8 @@
* this warranty disclaimer.
*/
+#include <linux/etherdevice.h>
+
#include "decl.h"
#include "ioctl.h"
#include "util.h"
@@ -736,7 +738,6 @@ static int mwifiex_ret_ibss_coalescing_status(struct mwifiex_private *priv,
{
struct host_cmd_ds_802_11_ibss_status *ibss_coal_resp =
&(resp->params.ibss_coalescing);
- u8 zero_mac[ETH_ALEN] = { 0, 0, 0, 0, 0, 0 };
if (le16_to_cpu(ibss_coal_resp->action) == HostCmd_ACT_GEN_SET)
return 0;
@@ -745,7 +746,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct mwifiex_private *priv,
"info: new BSSID %pM\n", ibss_coal_resp->bssid);
/* If rsp has NULL BSSID, Just return..... No Action */
- if (!memcmp(ibss_coal_resp->bssid, zero_mac, ETH_ALEN)) {
+ if (is_zero_ether_addr(ibss_coal_resp->bssid)) {
dev_warn(priv->adapter->dev, "new BSSID is NULL\n");
return 0;
}
^ permalink raw reply related
* [PATCH] ipw2200: use is_zero_ether_addr() and is_broadcast_ether_addr()
From: Wei Yongjun @ 2012-08-23 6:54 UTC (permalink / raw)
To: stas.yakovlev, linville; +Cc: yongjun_wei, linux-wireless, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() and is_broadcast_ether_addr() instead of
directly use memcmp() to determine if the ethernet address is all zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 0df4591..935120f 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -9037,18 +9037,11 @@ static int ipw_wx_set_wap(struct net_device *dev,
{
struct ipw_priv *priv = libipw_priv(dev);
- static const unsigned char any[] = {
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
- };
- static const unsigned char off[] = {
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
- };
-
if (wrqu->ap_addr.sa_family != ARPHRD_ETHER)
return -EINVAL;
mutex_lock(&priv->mutex);
- if (!memcmp(any, wrqu->ap_addr.sa_data, ETH_ALEN) ||
- !memcmp(off, wrqu->ap_addr.sa_data, ETH_ALEN)) {
+ if (is_broadcast_ether_addr(wrqu->ap_addr.sa_data) ||
+ is_zero_ether_addr(wrqu->ap_addr.sa_data)) {
/* we disable mandatory BSSID association */
IPW_DEBUG_WX("Setting AP BSSID to ANY\n");
priv->config &= ~CFG_STATIC_BSSID;
^ permalink raw reply related
* [PATCH] ipw2100: use is_zero_ether_addr() and is_broadcast_ether_addr()
From: Wei Yongjun @ 2012-08-23 6:53 UTC (permalink / raw)
To: stas.yakovlev, linville; +Cc: yongjun_wei, linux-wireless, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() and is_broadcast_ether_addr() instead of
directly use memcmp() to determine if the ethernet address is all zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/ipw2x00/ipw2100.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index 95aa8e1..c3e14b2 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -6963,13 +6963,6 @@ static int ipw2100_wx_set_wap(struct net_device *dev,
struct ipw2100_priv *priv = libipw_priv(dev);
int err = 0;
- static const unsigned char any[] = {
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
- };
- static const unsigned char off[] = {
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
- };
-
// sanity checks
if (wrqu->ap_addr.sa_family != ARPHRD_ETHER)
return -EINVAL;
@@ -6980,8 +6973,8 @@ static int ipw2100_wx_set_wap(struct net_device *dev,
goto done;
}
- if (!memcmp(any, wrqu->ap_addr.sa_data, ETH_ALEN) ||
- !memcmp(off, wrqu->ap_addr.sa_data, ETH_ALEN)) {
+ if (is_broadcast_ether_addr(wrqu->ap_addr.sa_data) ||
+ is_zero_ether_addr(wrqu->ap_addr.sa_data)) {
/* we disable mandatory BSSID association */
IPW_DEBUG_WX("exit - disable mandatory BSSID\n");
priv->config &= ~CFG_STATIC_BSSID;
^ permalink raw reply related
* [PATCH] wimax/i2400m: use is_zero_ether_addr() instead of memcmp()
From: Wei Yongjun @ 2012-08-23 6:49 UTC (permalink / raw)
To: inaky.perez-gonzalez; +Cc: yongjun_wei, linux-wimax, wimax, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wimax/i2400m/driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c
index 0254261..9c34d2f 100644
--- a/drivers/net/wimax/i2400m/driver.c
+++ b/drivers/net/wimax/i2400m/driver.c
@@ -222,7 +222,6 @@ int i2400m_check_mac_addr(struct i2400m *i2400m)
struct sk_buff *skb;
const struct i2400m_tlv_detailed_device_info *ddi;
struct net_device *net_dev = i2400m->wimax_dev.net_dev;
- const unsigned char zeromac[ETH_ALEN] = { 0 };
d_fnstart(3, dev, "(i2400m %p)\n", i2400m);
skb = i2400m_get_device_info(i2400m);
@@ -244,7 +243,7 @@ int i2400m_check_mac_addr(struct i2400m *i2400m)
"to that of boot mode's\n");
dev_warn(dev, "device reports %pM\n", ddi->mac_address);
dev_warn(dev, "boot mode reported %pM\n", net_dev->perm_addr);
- if (!memcmp(zeromac, ddi->mac_address, sizeof(zeromac)))
+ if (is_zero_ether_addr(ddi->mac_address))
dev_err(dev, "device reports an invalid MAC address, "
"not updating\n");
else {
^ permalink raw reply related
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-23 6:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, davem, roland, netdev, Ali Ayoub, sean.hefty,
Erez Shitrit, Doug Ledford, Shlomo Pongratz
In-Reply-To: <20120820185625.GA5234@redhat.com>
On 20/08/2012 21:57, Michael S. Tsirkin wrote:
> On Sun, Aug 12, 2012 at 11:54:57PM +0300, Michael S. Tsirkin wrote:
>
>> If you want this, then you really want a limited form of IPoIB bridging.
>
> And to clarify that statement, here is how I would make such IPoIB "bridging" work:
>
> Guest side:
>
> - Implement virtio-ipoib. This would be a device like virtio-net,
> but instead of ethernet packets, it would pass packets
> that consist of:
> IPoIB destination address
> IP packet
>
> - this is passed to/from host without modifications, possibly with addition
> of header such as virtio net header
>
> - flags such as broadcast can also be added to header
>
> - like virtio net get capabilities from host and expose
> as netdev capabilities
>
> Host side:
> - create macvtap -passthrough like device that can sit on top of an
> ipoib interface
> - expose this device QPN and GID to guest as hardware address
> - as we get packet forward it on UD QPN or CM as appropriate
> depending on size,checksum and admin preference
> - expose capabilities such as TSO
> - can expose capability such as max MTU to guest too
>
> Above means hardware address changes with migration.
> So we need to notify guest when this happens.
>
> This can be addressed from host by notifying all neighbours.
>
> Alternatively guest can notify all neighbours.
>
> Notification can be done by broadcast.
> This second option seems preferable.
>
> this ipoib-vtap can support two modes
> - bridge like mode:
> guest to guest and guest to host packets
> can be detected by macvtap and passed
> to/from guest directly like macvlan bridge mode
>
> - vepa like mode
> guest to guest and guest to host packets
> are sent out and looped back by IB switch
> like macvlan vepa mode
>
> As compared to the custom protocol I sent, it has -
> Advantages: interoperates cleanly with ipoib
> Disadvantages: no support for legacy (ethernet-only) guest
>
Hi Michael,
As you mentioned, the approach doesn't address legacy guests, who either
don't have the virtio
driver, or don't have a virtio driver patched to support virtio-ipoib
-- which doesn't go inline
with a strong requirement I got.
Other than this giant obstacle, I liked the suggestion and it seems
valid and viable -- BTW IB HW has
loopback capability, so the VM/VM packets wouldn't actually go to the IB
switch, but remain within the
HCA.
Or.
^ permalink raw reply
* Re: [PATCH v2] net: add new QCA alx ethernet driver
From: David Miller @ 2012-08-23 6:40 UTC (permalink / raw)
To: xiong; +Cc: cjren, netdev, linux-kernel, qca-linux-team, nic-devel, rodrigue
In-Reply-To: <157393863283F442885425D2C45428562A4F5169@nasanexd02f.na.qualcomm.com>
From: "Huang, Xiong" <xiong@qca.qualcomm.com>
Date: Thu, 23 Aug 2012 06:35:40 +0000
>> This is why we require that portable, sane, interfaces are added to ethtool for
>> driver diagnostics. That way users can perform a task in the same way
>> regardless of what hardware and driver are underneath.
>
> I quite agree you on using ethtool to implement it. we did consider it.
> But ethtool has some limitation, for example, the NIC has built-in OTP (TWSI interface)
> And Flash (External SPI interface), their properties are quite different with EEPROM which
> Ethtool supports.
> To support such memory (OTP/Flash), we need additional input parameters.
Then add a new ethtool operation to support your use case, that's
exactly what I was telling you to do.
Did it really not occur to you that you perhaps you should extend
existing generic facilities to suit your needs instead of creating
private facilities that no other driver can use?
^ permalink raw reply
* Re: Which one is chosen on multiple default gateway set?
From: David Miller @ 2012-08-23 6:38 UTC (permalink / raw)
To: daviseago; +Cc: netdev, netfilter
In-Reply-To: <CAJPS4yY7sqqsOfhiouqjmfuW3Kof-ZzHEBs9E1+QoYYce01U4Q@mail.gmail.com>
From: Wei Huang <daviseago@gmail.com>
Date: Thu, 23 Aug 2012 14:31:26 +0800
> If multiple default gateways are set, which one will be chosen? And if
> the chosen one is down, will others take over?
Yes.
> It works sometime, but not most of the time. (example below) The
> behavior is inconsistent.
The problem is that when a nexthop becomes unresponsive we need
to wait for an event to timeout the routing cache entry.
In 3.6.0-rc1 and later, this inconsistent behavior will happen less
often, because the routing cache has been removed so we will do the
full default route resolution on every route lookup. The only problem
at that point is socket cached routes, those will still need to wait
for a timeout before the next default gateway will be tried.
^ permalink raw reply
* Re: [PATCH 0/8] netdev/MIPS: Improvements to octeon_mgmt Ethernet driver.
From: John Crispin @ 2012-08-23 6:35 UTC (permalink / raw)
To: ddaney.cavm; +Cc: linux-mips, ralf, netdev, linux-kernel, david.daney
In-Reply-To: <20120822.191654.1727215659090597701.davem@davemloft.net>
On 23/08/12 04:16, David Miller wrote:
> From: David Daney <ddaney.cavm@gmail.com>
> Date: Tue, 21 Aug 2012 11:45:04 -0700
>
>> From: David Daney <david.daney@cavium.com>
>>
>> Recent additions to the OCTEON SoC family have included enhancements
>> to the MIX (octeon_mgmt) Ethernet hardware. These include:
>>
>> o 1Gig support (up from 100M).
>>
>> o Hardware timestamping for PTP.
>>
>> Here we add support for these two features as well as some ethtool
>> improvements and cleanup of the MAC address handling.
>>
>> Patch 1/8 is a prerequisite for the rest, and lives in the MIPS
>> architecture part of the tree. Since octeon_mgmt devices are only
>> found in OCTEON SoCs we could merge the whole set via Ralf's tree, or
>> get Ralf to affix his Acked-by and have it go via the netdev tree.
>
> You can send this all via the MIPS tree, and feel free to add my:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thanks, queued for 3.7
John
^ permalink raw reply
* RE: [PATCH v2] net: add new QCA alx ethernet driver
From: Huang, Xiong @ 2012-08-23 6:35 UTC (permalink / raw)
To: David Miller, Ren, Cloud
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
qca-linux-team, nic-devel, Rodriguez, Luis
In-Reply-To: <20120822.225700.714020017287504609.davem@davemloft.net>
> This is why we require that portable, sane, interfaces are added to ethtool for
> driver diagnostics. That way users can perform a task in the same way
> regardless of what hardware and driver are underneath.
I quite agree you on using ethtool to implement it. we did consider it.
But ethtool has some limitation, for example, the NIC has built-in OTP (TWSI interface)
And Flash (External SPI interface), their properties are quite different with EEPROM which
Ethtool supports.
To support such memory (OTP/Flash), we need additional input parameters.
Same situation exists in diagnostic utility. Ethtool only provide two options : offline & online
That's too gross to locate which part/module of the chip is malfunction. we also need
more options to detect it.
that's why we finally selected a custom debugfs interface.
Thanks
Xiong
^ permalink raw reply
* Re: [PATCH net-next v3] net: remove delay at device dismantle
From: Eric W. Biederman @ 2012-08-23 6:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, gaofeng, netdev, maheshb, therbert
In-Reply-To: <1345691986.5904.40.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> From: Eric Dumazet <edumazet@google.com>
>
> I noticed extra one second delay in device dismantle, tracked down to
> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>
> These call_rcu() were posted by rt_free(struct rtable *rt) calls.
>
> We then wait a little (but one second) in netdev_wait_allrefs() before
> kicking again NETDEV_UNREGISTER.
>
> As the call_rcu() are now completed, dst_dev_event() can do the needed
> device swap on busy dst.
>
> To solve this problem, add a new NETDEV_UNREGISTER_FINAL, called
> after a rcu_barrier(), but outside of RTNL lock.
>
> Use NETDEV_UNREGISTER_FINAL with care !
>
> Change dst_dev_event() handler to react to NETDEV_UNREGISTER_FINAL
>
> Also remove NETDEV_UNREGISTER_BATCH, as its not used anymore after
> IP cache removal.
>
> With help from Gao feng
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> v3: Gao Feng reported a lockdep issue.
> I had to change some notifiers to check NETDEV_UNREGISTER_FINAL
>
> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
> as its more risky, base this patch on net-next
>
> include/linux/netdevice.h | 2 +-
> net/core/dev.c | 22 ++++++++--------------
> net/core/dst.c | 2 +-
> net/core/fib_rules.c | 3 ++-
> net/core/rtnetlink.c | 2 +-
> net/ipv4/devinet.c | 6 +++++-
> net/ipv4/fib_frontend.c | 8 ++++----
> net/ipv6/addrconf.c | 6 +++++-
> 8 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 4936f09..9ad7fa8 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1553,7 +1553,7 @@ struct packet_type {
> #define NETDEV_PRE_TYPE_CHANGE 0x000E
> #define NETDEV_POST_TYPE_CHANGE 0x000F
> #define NETDEV_POST_INIT 0x0010
> -#define NETDEV_UNREGISTER_BATCH 0x0011
> +#define NETDEV_UNREGISTER_FINAL 0x0011
> #define NETDEV_RELEASE 0x0012
> #define NETDEV_NOTIFY_PEERS 0x0013
> #define NETDEV_JOIN 0x0014
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 088923f..0640d2a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1406,7 +1406,6 @@ rollback:
> nb->notifier_call(nb, NETDEV_DOWN, dev);
> }
> nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
> - nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
> }
> }
>
> @@ -1448,7 +1447,6 @@ int unregister_netdevice_notifier(struct notifier_block *nb)
> nb->notifier_call(nb, NETDEV_DOWN, dev);
> }
> nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
> - nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
> }
> }
> unlock:
> @@ -1468,7 +1466,8 @@ EXPORT_SYMBOL(unregister_netdevice_notifier);
>
> int call_netdevice_notifiers(unsigned long val, struct net_device *dev)
> {
> - ASSERT_RTNL();
> + if (val != NETDEV_UNREGISTER_FINAL)
> + ASSERT_RTNL();
raw_notifier_call_chain isn't safe without holding some sort of lock.
So removing the ASSERT_RTNL assert here is papering over a bug elsewhere
in this patch.
Without holding a lock for traversing the notifier chain there will
be races with network module load and unload that could corrupt
this list while we are traversing it.
load/unlod.
You already have one of your NETDEV_UNREGISTER_FINAL calls under the
rtnl_lock so it doesn't look like a burden to put the other call under
the rtnl_lock as well.
> return raw_notifier_call_chain(&netdev_chain, val, dev);
> }
> EXPORT_SYMBOL(call_netdevice_notifiers);
> @@ -5331,10 +5330,6 @@ static void rollback_registered_many(struct list_head *head)
> netdev_unregister_kobject(dev);
> }
>
> - /* Process any work delayed until the end of the batch */
> - dev = list_first_entry(head, struct net_device, unreg_list);
> - call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
> -
> synchronize_net();
>
> list_for_each_entry(dev, head, unreg_list)
> @@ -5787,9 +5782,8 @@ static void netdev_wait_allrefs(struct net_device *dev)
>
> /* Rebroadcast unregister notification */
> call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
> - /* don't resend NETDEV_UNREGISTER_BATCH, _BATCH users
> - * should have already handle it the first time */
> -
> + rcu_barrier();
You have just added an rcu_barrier() under the rtnl_lock.
Can you make this.
__rtnl_unlock();
rcu_barrier();
rtnl_lock();
Which will be much better for rtnl_lock hold times.
> + call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL, dev);
> if (test_bit(__LINK_STATE_LINKWATCH_PENDING,
> &dev->state)) {
> /* We must not have linkwatch events
> @@ -5851,9 +5845,8 @@ void netdev_run_todo(void)
>
> __rtnl_unlock();
>
> - /* Wait for rcu callbacks to finish before attempting to drain
> - * the device list. This usually avoids a 250ms wait.
> - */
> +
> + /* Wait for rcu callbacks to finish before next phase */
> if (!list_empty(&list))
> rcu_barrier();
>
> @@ -5862,6 +5855,8 @@ void netdev_run_todo(void)
> = list_first_entry(&list, struct net_device, todo_list);
> list_del(&dev->todo_list);
> + call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL, dev);
> +
Why are you skipping grapping the rtl_lock here?
rtnl_lock();
__rtnl_unlock() doesn't look scary.
> if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
> pr_err("network todo '%s' but state %d\n",
> dev->name, dev->reg_state);
> @@ -6256,7 +6251,6 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
> the device is just moving and can keep their slaves up.
> */
> call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
> - call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
> rtmsg_ifinfo(RTM_DELLINK, dev, ~0U);
>
> /*
> diff --git a/net/core/dst.c b/net/core/dst.c
> index 56d6361..f6593d2 100644
> --- a/net/core/dst.c
> +++ b/net/core/dst.c
> @@ -374,7 +374,7 @@ static int dst_dev_event(struct notifier_block *this, unsigned long event,
> struct dst_entry *dst, *last = NULL;
>
> switch (event) {
> - case NETDEV_UNREGISTER:
> + case NETDEV_UNREGISTER_FINAL:
> case NETDEV_DOWN:
> mutex_lock(&dst_gc_mutex);
> for (dst = dst_busy_list; dst; dst = dst->next) {
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index ab7db83..5850937 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -711,15 +711,16 @@ static int fib_rules_event(struct notifier_block *this, unsigned long event,
> struct net *net = dev_net(dev);
> struct fib_rules_ops *ops;
>
> - ASSERT_RTNL();
>
> switch (event) {
> case NETDEV_REGISTER:
> + ASSERT_RTNL();
> list_for_each_entry(ops, &net->rules_ops, list)
> attach_rules(&ops->rules_list, dev);
> break;
>
> case NETDEV_UNREGISTER:
> + ASSERT_RTNL();
> list_for_each_entry(ops, &net->rules_ops, list)
> detach_rules(&ops->rules_list, dev);
> break;
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 34d975b..c64efcf 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2358,7 +2358,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
> case NETDEV_PRE_TYPE_CHANGE:
> case NETDEV_GOING_DOWN:
> case NETDEV_UNREGISTER:
> - case NETDEV_UNREGISTER_BATCH:
> + case NETDEV_UNREGISTER_FINAL:
> case NETDEV_RELEASE:
> case NETDEV_JOIN:
> break;
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index adf273f..6a5e6e4 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1147,8 +1147,12 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
> void *ptr)
> {
> struct net_device *dev = ptr;
> - struct in_device *in_dev = __in_dev_get_rtnl(dev);
> + struct in_device *in_dev;
>
> + if (event == NETDEV_UNREGISTER_FINAL)
> + goto out;
> +
> + in_dev = __in_dev_get_rtnl(dev);
> ASSERT_RTNL();
>
> if (!in_dev) {
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 7f073a3..fd7d9ae 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -1041,7 +1041,7 @@ static int fib_inetaddr_event(struct notifier_block *this, unsigned long event,
> static int fib_netdev_event(struct notifier_block *this, unsigned long event, void *ptr)
> {
> struct net_device *dev = ptr;
> - struct in_device *in_dev = __in_dev_get_rtnl(dev);
> + struct in_device *in_dev;
> struct net *net = dev_net(dev);
>
> if (event == NETDEV_UNREGISTER) {
> @@ -1050,9 +1050,11 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
> return NOTIFY_DONE;
> }
>
> - if (!in_dev)
> + if (event == NETDEV_UNREGISTER_FINAL)
> return NOTIFY_DONE;
>
> + in_dev = __in_dev_get_rtnl(dev);
> +
> switch (event) {
> case NETDEV_UP:
> for_ifa(in_dev) {
> @@ -1071,8 +1073,6 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
> case NETDEV_CHANGE:
> rt_cache_flush(dev_net(dev), 0);
> break;
> - case NETDEV_UNREGISTER_BATCH:
> - break;
> }
> return NOTIFY_DONE;
> }
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 6bc85f7..e581009 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2566,10 +2566,14 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
> void *data)
> {
> struct net_device *dev = (struct net_device *) data;
> - struct inet6_dev *idev = __in6_dev_get(dev);
> + struct inet6_dev *idev;
> int run_pending = 0;
> int err;
>
> + if (event == NETDEV_UNREGISTER_FINAL)
> + return NOTIFY_DONE;
> +
> + idev = __in6_dev_get(dev);
> switch (event) {
> case NETDEV_REGISTER:
> if (!idev && dev->mtu >= IPV6_MIN_MTU) {
^ permalink raw reply
* Which one is chosen on multiple default gateway set?
From: Wei Huang @ 2012-08-23 6:31 UTC (permalink / raw)
To: netdev, netfilter
Hi,
If multiple default gateways are set, which one will be chosen? And if
the chosen one is down, will others take over?
It works sometime, but not most of the time. (example below) The
behavior is inconsistent.
How the case is handled? On what condition another default gateway is
chosen? Thank you!
=======================
~ # ip r
10.65.30.0/24 dev bond0 src 10.65.30.71
default via 10.65.30.221 dev bond0 (this one is down!)
default via 10.65.30.1 dev bond0
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.221 dev bond0 src 10.65.30.71
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
// after a while
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=5.0 ms
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.1 dev bond0 src 10.65.30.71
// after two while
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.221 dev bond0 src 10.65.30.71
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
==================================
Best regards,
Wei
^ permalink raw reply
* [PATCH 2/2] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_queue()
From: Michael Wang @ 2012-08-23 6:00 UTC (permalink / raw)
To: LKML, netdev@vger.kernel.org, coreteam, netfilter,
netfilter-devel
Cc: David Miller, kaber, pablo
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Since 'list_for_each_continue_rcu' has already been replaced by
'list_for_each_entry_continue_rcu', pass 'list_head' to nf_queue() as a
parameter can not benefit us any more.
This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
nf_queue() and __nf_queue() to save code.
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
---
net/netfilter/core.c | 4 ++--
net/netfilter/nf_internals.h | 2 +-
net/netfilter/nf_queue.c | 8 ++++----
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index b4cd2a2..8bf1eef 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -189,8 +189,8 @@ next_hook:
if (ret == 0)
ret = -EPERM;
} else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
- int err = nf_queue(skb, &elem->list, pf, hook, indev, outdev,
- okfn, verdict >> NF_VERDICT_QBITS);
+ int err = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
+ verdict >> NF_VERDICT_QBITS);
if (err < 0) {
if (err == -ECANCELED)
goto next_hook;
diff --git a/net/netfilter/nf_internals.h b/net/netfilter/nf_internals.h
index 2886231..3deec99 100644
--- a/net/netfilter/nf_internals.h
+++ b/net/netfilter/nf_internals.h
@@ -24,7 +24,7 @@ extern unsigned int nf_iterate(struct list_head *head,
/* nf_queue.c */
extern int nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index 29fe102..8d2cf9e 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -118,7 +118,7 @@ static void nf_queue_entry_release_refs(struct nf_queue_entry *entry)
* through nf_reinject().
*/
static int __nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
@@ -155,7 +155,7 @@ static int __nf_queue(struct sk_buff *skb,
*entry = (struct nf_queue_entry) {
.skb = skb,
- .elem = list_entry(elem, struct nf_hook_ops, list),
+ .elem = elem,
.pf = pf,
.hook = hook,
.indev = indev,
@@ -225,7 +225,7 @@ static void nf_bridge_adjust_segmented_data(struct sk_buff *skb)
#endif
int nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
@@ -323,7 +323,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
local_bh_enable();
break;
case NF_QUEUE:
- err = __nf_queue(skb, &elem->list, entry->pf, entry->hook,
+ err = __nf_queue(skb, elem, entry->pf, entry->hook,
entry->indev, entry->outdev, entry->okfn,
verdict >> NF_VERDICT_QBITS);
if (err < 0) {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_iterate()
From: Michael Wang @ 2012-08-23 5:59 UTC (permalink / raw)
To: LKML, netdev@vger.kernel.org, coreteam, netfilter,
netfilter-devel
Cc: David Miller, kaber, pablo
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Since 'list_for_each_continue_rcu' has already been replaced by
'list_for_each_entry_continue_rcu', pass 'list_head' to nf_iterate() as a
parameter can not benefit us any more.
This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
nf_iterate() to save code.
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
---
net/netfilter/core.c | 24 ++++++++++--------------
net/netfilter/nf_internals.h | 2 +-
net/netfilter/nf_queue.c | 6 +++---
3 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 8f4b0b2..b4cd2a2 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -126,42 +126,38 @@ unsigned int nf_iterate(struct list_head *head,
unsigned int hook,
const struct net_device *indev,
const struct net_device *outdev,
- struct list_head **i,
+ struct nf_hook_ops **elemp,
int (*okfn)(struct sk_buff *),
int hook_thresh)
{
unsigned int verdict;
- struct nf_hook_ops *elem = list_entry_rcu(*i, struct nf_hook_ops, list);
/*
* The caller must not block between calls to this
* function because of risk of continuing from deleted element.
*/
- list_for_each_entry_continue_rcu(elem, head, list) {
- if (hook_thresh > elem->priority)
+ list_for_each_entry_continue_rcu((*elemp), head, list) {
+ if (hook_thresh > (*elemp)->priority)
continue;
/* Optimization: we don't need to hold module
reference here, since function can't sleep. --RR */
repeat:
- verdict = elem->hook(hook, skb, indev, outdev, okfn);
+ verdict = (*elemp)->hook(hook, skb, indev, outdev, okfn);
if (verdict != NF_ACCEPT) {
#ifdef CONFIG_NETFILTER_DEBUG
if (unlikely((verdict & NF_VERDICT_MASK)
> NF_MAX_VERDICT)) {
NFDEBUG("Evil return from %p(%u).\n",
- elem->hook, hook);
+ (*elemp)->hook, hook);
continue;
}
#endif
- if (verdict != NF_REPEAT) {
- *i = &elem->list;
+ if (verdict != NF_REPEAT)
return verdict;
- }
goto repeat;
}
}
- *i = &elem->list;
return NF_ACCEPT;
}
@@ -174,14 +170,14 @@ int nf_hook_slow(u_int8_t pf, unsigned int hook, struct sk_buff *skb,
int (*okfn)(struct sk_buff *),
int hook_thresh)
{
- struct list_head *elem;
+ struct nf_hook_ops *elem;
unsigned int verdict;
int ret = 0;
/* We may already have this, but read-locks nest anyway */
rcu_read_lock();
- elem = &nf_hooks[pf][hook];
+ elem = list_entry_rcu(&nf_hooks[pf][hook], struct nf_hook_ops, list);
next_hook:
verdict = nf_iterate(&nf_hooks[pf][hook], skb, hook, indev,
outdev, &elem, okfn, hook_thresh);
@@ -193,8 +189,8 @@ next_hook:
if (ret == 0)
ret = -EPERM;
} else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
- int err = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
- verdict >> NF_VERDICT_QBITS);
+ int err = nf_queue(skb, &elem->list, pf, hook, indev, outdev,
+ okfn, verdict >> NF_VERDICT_QBITS);
if (err < 0) {
if (err == -ECANCELED)
goto next_hook;
diff --git a/net/netfilter/nf_internals.h b/net/netfilter/nf_internals.h
index 770f764..2886231 100644
--- a/net/netfilter/nf_internals.h
+++ b/net/netfilter/nf_internals.h
@@ -18,7 +18,7 @@ extern unsigned int nf_iterate(struct list_head *head,
unsigned int hook,
const struct net_device *indev,
const struct net_device *outdev,
- struct list_head **i,
+ struct nf_hook_ops **elemp,
int (*okfn)(struct sk_buff *),
int hook_thresh);
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index ce60cf0..29fe102 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -287,7 +287,7 @@ int nf_queue(struct sk_buff *skb,
void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
{
struct sk_buff *skb = entry->skb;
- struct list_head *elem = &entry->elem->list;
+ struct nf_hook_ops *elem = entry->elem;
const struct nf_afinfo *afinfo;
int err;
@@ -297,7 +297,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
/* Continue traversal iff userspace said ok... */
if (verdict == NF_REPEAT) {
- elem = elem->prev;
+ elem = list_entry(elem->list.prev, struct nf_hook_ops, list);
verdict = NF_ACCEPT;
}
@@ -323,7 +323,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
local_bh_enable();
break;
case NF_QUEUE:
- err = __nf_queue(skb, elem, entry->pf, entry->hook,
+ err = __nf_queue(skb, &elem->list, entry->pf, entry->hook,
entry->indev, entry->outdev, entry->okfn,
verdict >> NF_VERDICT_QBITS);
if (err < 0) {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] netfilter: code refine for using new interface 'list_for_each_entry_continue_rcu'
From: Michael Wang @ 2012-08-23 5:59 UTC (permalink / raw)
To: LKML, netdev@vger.kernel.org, coreteam, netfilter,
netfilter-devel
Cc: David Miller, kaber, pablo
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Since 'list_for_each_continue_rcu' has been replaced with the new interface
'list_for_each_entry_continue_rcu' by commit 6705e86, we can no longer saving
code by passing 'list_head' to nf_iterate() and nf_queue() any more.
This patch set will pass 'nf_hook_ops' instead of 'list_head' to nf_iterate()
and nf_queue() as the parameter and saving some code.
Tested:
add rule to iptables and check result by ping.
nfqnl_test which is a test utility of libnetfilter_queue.
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
---
b/net/netfilter/core.c | 24 ++++++++++--------------
b/net/netfilter/nf_internals.h | 2 +-
b/net/netfilter/nf_queue.c | 6 +++---
net/netfilter/core.c | 4 ++--
net/netfilter/nf_internals.h | 2 +-
net/netfilter/nf_queue.c | 8 ++++----
6 files changed, 21 insertions(+), 25 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] packet: Protect packet sk list with mutex (v2)
From: David Miller @ 2012-08-23 5:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: xemul, netdev
In-Reply-To: <1345618757.5158.612.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 22 Aug 2012 08:59:17 +0200
> On Tue, 2012-08-21 at 15:06 +0400, Pavel Emelyanov wrote:
>> Change since v1:
>>
>> * Fixed inuse counters access spotted by Eric
>>
>> In patch eea68e2f (packet: Report socket mclist info via diag module) I've
>> introduced a "scheduling in atomic" problem in packet diag module -- the
>> socket list is traversed under rcu_read_lock() while performed under it sk
>> mclist access requires rtnl lock (i.e. -- mutex) to be taken.
>>
>> [152363.820563] BUG: scheduling while atomic: crtools/12517/0x10000002
>> [152363.820573] 4 locks held by crtools/12517:
>> [152363.820581] #0: (sock_diag_mutex){+.+.+.}, at: [<ffffffff81a2dcb5>] sock_diag_rcv+0x1f/0x3e
>> [152363.820613] #1: (sock_diag_table_mutex){+.+.+.}, at: [<ffffffff81a2de70>] sock_diag_rcv_msg+0xdb/0x11a
>> [152363.820644] #2: (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81a67d01>] netlink_dump+0x23/0x1ab
>> [152363.820693] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff81b6a049>] packet_diag_dump+0x0/0x1af
>>
>> Similar thing was then re-introduced by further packet diag patches (fanount
>> mutex and pgvec mutex for rings) :(
>>
>> Apart from being terribly sorry for the above, I propose to change the packet
>> sk list protection from spinlock to mutex. This lock currently protects two
>> modifications:
>>
>> * sklist
>> * prot inuse counters
>>
>> The sklist modifications can be just reprotected with mutex since they already
>> occur in a sleeping context. The inuse counters modifications are trickier -- the
>> __this_cpu_-s are used inside, thus requiring the caller to handle the potential
>> issues with contexts himself. Since packet sockets' counters are modified in two
>> places only (packet_create and packet_release) we only need to protect the context
>> from being preempted. BH disabling is not required in this case.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH] mdio: translation of MMD EEE registers to/from ethtool settings
From: David Miller @ 2012-08-23 5:59 UTC (permalink / raw)
To: bruce.w.allan; +Cc: netdev, peppe.cavallaro
In-Reply-To: <20120820145529.19390.66175.stgit@bwallan-smackover2.jf.intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Date: Mon, 20 Aug 2012 07:55:29 -0700
> The helper functions which translate IEEE MDIO Manageable Device (MMD)
> Energy-Efficient Ethernet (EEE) registers 3.20, 7.60 and 7.61 to and from
> the comparable ethtool supported/advertised settings will be needed by
> drivers other than those in PHYLIB (e.g. e1000e in a follow-on patch).
>
> In the same fashion as similar translation functions in linux/mii.h, move
> these functions from the PHYLIB core to the linux/mdio.h header file so the
> code will not have to be duplicated in each driver needing MMD-to-ethtool
> (and vice-versa) translations. The function and some variable names have
> been renamed to be more descriptive.
>
> Not tested on the only hardware that currently calls the related functions,
> stmmac, because I don't have access to any. Has been compile tested and
> the translations have been tested on a locally modified version of e1000e.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] af_packet: use define instead of constant
From: David Miller @ 2012-08-23 5:58 UTC (permalink / raw)
To: danborkmann; +Cc: netdev
In-Reply-To: <1345469643.22726.2.camel@thinkbox>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Mon, 20 Aug 2012 15:34:03 +0200
> Instead of using a hard-coded value for the status variable, it would make
> the code more readable to use its destined define from linux/if_packet.h.
>
> Signed-off-by: daniel.borkmann@tik.ee.ethz.ch
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: add new QCA alx ethernet driver
From: David Miller @ 2012-08-23 5:57 UTC (permalink / raw)
To: cjren; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel, xiong, rodrigue
In-Reply-To: <1345480949-14800-1-git-send-email-cjren@qca.qualcomm.com>
From: <cjren@qca.qualcomm.com>
Date: Tue, 21 Aug 2012 00:42:29 +0800
> +config ALX_DEBUGFS
> + bool "Qualcomm Atheros debugging interface"
> + depends on ALX && DEBUG_FS
> + ---help---
> + This option adds ability to debug and test L1F. It can
> + support Qualcomm Atheros tools, including diagnostic, memcfg
> + and SWOI.
Sorry, no vendor specific interfaces, you have to remove this.
Anything diagnostic you think is special and unique to your piece of
hardware, is almost certainly not, and therefore needs to exist as a
generic ethtool or similar interface that other drivers can plug into,
not just your's.
Driver specific interfaces suck for several reasons, not least of
which is the fact that it leads to a terrible user experience. The
same task must be done in different ways depending upon what piece of
networking hardware and device driver are being used, which the user
should never need to know.
This is why we require that portable, sane, interfaces are added
to ethtool for driver diagnostics. That way users can perform
a task in the same way regardless of what hardware and driver
are underneath.
^ permalink raw reply
* Re: [PATCH] rds: Don't disable BH on BH context
From: David Miller @ 2012-08-23 5:52 UTC (permalink / raw)
To: ying.xue; +Cc: venkat.x.venkatsubra, netdev
In-Reply-To: <1345448648-30449-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Mon, 20 Aug 2012 15:44:08 +0800
> Since we have already in BH context when *_write_space(),
> *_data_ready() as well as *_state_change() are called, it's
> unnecessary to disable BH.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied to net-next, thanks.
^ 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