* Re: pull request: wireless 2013-01-09
From: John W. Linville @ 2013-01-09 19:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130109191817.GA17321@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 7845 bytes --]
Ooops! Forgot to sign it...
On Wed, Jan 09, 2013 at 02:18:18PM -0500, John W. Linville wrote:
> Dave,
>
> Please pull this batch of fixes (and a new driver) for the 3.8 stream...
>
> Included is a mac80211 pull, of which Johannes says the following:
>
> 'This includes a number of fixes for various pieces of mac80211. I've
> also included Thomas's memory RMC hash table optimisation since it
> saves so much memory.'
>
> Also from Johannes is an iwlwifi pull:
>
> 'I have two fixes for iwlwifi: one to fix a lost return value that was
> dropped in a previous patch and could cause "nobody cared" IRQ messages,
> and one to work around a firmware issue.'
>
> Amitkumar Karwar brings an mwifiex for a typo in an comparison.
>
> Bing Zhao gives us an mwifiex fix to properly check the return value
> from wait_event_interruptible and handle it properly.
>
> Chen Gang provides a fix to make iwlegacy use strlcpy instead of
> strncpy, avoiding a potential buffer underflow.
>
> Julian Wollrath fixes a typo in an error message in rtlwifi.
>
> Larry Finger brings a b43 fix for a firmware loading problem.
>
> Nickolai Zeldovich avoids a use-after-free in the mwl8k driver.
>
> Vladimir Kondratiev brings the last big piece, the new Qualcomm/Atheros
> wil6210 802.11ad driver. Since it is for new hardware, I hope that
> taking it for 3.8 is not a problem.
>
> Please let me know if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit c9be4a5c49cf51cc70a993f004c5bb30067a65ce:
>
> net: prevent setting ttl=0 via IP_TTL (2013-01-08 17:57:10 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
>
> for you to fetch changes up to a9b8a894ad7d0b90b0464c9ac7e8e5c1687edcae:
>
> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-01-09 11:01:37 -0500)
>
> ----------------------------------------------------------------
>
> Amitkumar Karwar (1):
> mwifiex: fix typo in setting up ibss network parameters
>
> Bing Zhao (1):
> mwifiex: check wait_event_interruptible return value
>
> Chaitanya (1):
> mac80211: fix maximum MTU
>
> Chen Gang (1):
> drivers/net/wireless/iwlegacy: use strlcpy instead of strncpy
>
> Emmanuel Grumbach (1):
> iwlwifi: fix the reclaimed packet tracking upon flush queue
>
> Felix Fietkau (1):
> mac80211: flush AP_VLAN stations when tearing down the BSS AP
>
> Johannes Berg (5):
> mac80211: assign VLAN channel contexts
> mac80211: fix station destruction in AP/mesh modes
> mac80211: use del_timer_sync for final sta cleanup timer deletion
> mac80211: fix dtim_period in hidden SSID AP association
> iwlwifi: fix PCIe interrupt handle return value
>
> John W. Linville (3):
> Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
> Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
> Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
>
> Julian Wollrath (1):
> rtlwifi: Fix typo in debug output of rtl8192c and rtl8723ae
>
> Larry Finger (1):
> b43: Fix firmware loading when driver is built into the kernel
>
> Nickolai Zeldovich (1):
> drivers/net/wireless/mwl8k.c: avoid use-after-free
>
> Stanislaw Gruszka (1):
> mac80211: fix ibss scanning
>
> Thomas Pedersen (1):
> mac80211: RMC buckets are just list heads
>
> Vladimir Kondratiev (1):
> wireless: add new wil6210 802.11ad 60GHz driver
>
> MAINTAINERS | 8 +
> drivers/net/wireless/ath/Kconfig | 1 +
> drivers/net/wireless/ath/Makefile | 1 +
> drivers/net/wireless/ath/wil6210/Kconfig | 29 +
> drivers/net/wireless/ath/wil6210/Makefile | 13 +
> drivers/net/wireless/ath/wil6210/cfg80211.c | 573 ++++++++++
> drivers/net/wireless/ath/wil6210/dbg_hexdump.h | 30 +
> drivers/net/wireless/ath/wil6210/debugfs.c | 603 +++++++++++
> drivers/net/wireless/ath/wil6210/interrupt.c | 471 +++++++++
> drivers/net/wireless/ath/wil6210/main.c | 407 +++++++
> drivers/net/wireless/ath/wil6210/netdev.c | 157 +++
> drivers/net/wireless/ath/wil6210/pcie_bus.c | 223 ++++
> drivers/net/wireless/ath/wil6210/txrx.c | 871 +++++++++++++++
> drivers/net/wireless/ath/wil6210/txrx.h | 362 +++++++
> drivers/net/wireless/ath/wil6210/wil6210.h | 363 +++++++
> drivers/net/wireless/ath/wil6210/wmi.c | 975 +++++++++++++++++
> drivers/net/wireless/ath/wil6210/wmi.h | 1116 ++++++++++++++++++++
> drivers/net/wireless/b43/b43.h | 5 +
> drivers/net/wireless/b43/main.c | 54 +-
> drivers/net/wireless/b43/main.h | 5 +-
> drivers/net/wireless/iwlegacy/3945-mac.c | 2 +-
> drivers/net/wireless/iwlwifi/dvm/tx.c | 24 +-
> drivers/net/wireless/iwlwifi/pcie/rx.c | 1 +
> drivers/net/wireless/mwifiex/cfg80211.c | 2 +-
> drivers/net/wireless/mwifiex/sta_ioctl.c | 21 +-
> drivers/net/wireless/mwl8k.c | 4 +-
> drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 2 +-
> drivers/net/wireless/rtlwifi/rtl8723ae/phy.c | 2 +-
> net/mac80211/cfg.c | 2 +
> net/mac80211/chan.c | 38 +
> net/mac80211/ibss.c | 9 +-
> net/mac80211/ieee80211_i.h | 16 +-
> net/mac80211/iface.c | 48 +-
> net/mac80211/mesh.c | 8 +-
> net/mac80211/mesh.h | 2 +-
> net/mac80211/mlme.c | 75 +-
> net/mac80211/scan.c | 46 +-
> net/mac80211/sta_info.c | 46 +-
> net/mac80211/sta_info.h | 3 +-
> 39 files changed, 6488 insertions(+), 130 deletions(-)
> create mode 100644 drivers/net/wireless/ath/wil6210/Kconfig
> create mode 100644 drivers/net/wireless/ath/wil6210/Makefile
> create mode 100644 drivers/net/wireless/ath/wil6210/cfg80211.c
> create mode 100644 drivers/net/wireless/ath/wil6210/dbg_hexdump.h
> create mode 100644 drivers/net/wireless/ath/wil6210/debugfs.c
> create mode 100644 drivers/net/wireless/ath/wil6210/interrupt.c
> create mode 100644 drivers/net/wireless/ath/wil6210/main.c
> create mode 100644 drivers/net/wireless/ath/wil6210/netdev.c
> create mode 100644 drivers/net/wireless/ath/wil6210/pcie_bus.c
> create mode 100644 drivers/net/wireless/ath/wil6210/txrx.c
> create mode 100644 drivers/net/wireless/ath/wil6210/txrx.h
> create mode 100644 drivers/net/wireless/ath/wil6210/wil6210.h
> create mode 100644 drivers/net/wireless/ath/wil6210/wmi.c
> create mode 100644 drivers/net/wireless/ath/wil6210/wmi.h
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value
From: Ani Sinha @ 2013-01-09 20:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: tcpdump-workers, Paul Pearce, netdev, dborkman, edumazet,
Jiri Pirko
In-Reply-To: <1357761063.27446.60.camel@edumazet-glaptop>
On Wed, Jan 9, 2013 at 11:51 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote:
>
>> This is wrong. Accelerated or not, the kernel code was organized to
>> have the tags in the packet aux data. So I think this is how user land
>> should be coded as well.
>
> You have your opinion, thats good.
>
> My opinion as a kernel developer is that the network tap is here to have
> a copy of the exact frame given to the _device_.
>
It is fine by me if that is how you see it. In that case. the
behaviour can me made symmetric on both TX and RX. Tap processing in
__netif_receive_skb() can be done before vlan_untag() so that taps see
the exact frame received from the _device_ as you put it.
ani
^ permalink raw reply
* Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value
From: Ani Sinha @ 2013-01-09 20:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: tcpdump-workers, Paul Pearce, netdev, dborkman, edumazet,
Jiri Pirko
In-Reply-To: <CAOxq_8OsumXX92odrVcREqsLkeUkcS_0uQvbdaTmtyr1HtuTOw@mail.gmail.com>
On Wed, Jan 9, 2013 at 12:01 PM, Ani Sinha <ani@aristanetworks.com> wrote:
> On Wed, Jan 9, 2013 at 11:51 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote:
>>
>>> This is wrong. Accelerated or not, the kernel code was organized to
>>> have the tags in the packet aux data. So I think this is how user land
>>> should be coded as well.
>>
>> You have your opinion, thats good.
>>
>> My opinion as a kernel developer is that the network tap is here to have
>> a copy of the exact frame given to the _device_.
>>
>
> It is fine by me if that is how you see it. In that case. the
> behaviour can me made symmetric on both TX and RX. Tap processing in
> __netif_receive_skb() can be done before vlan_untag() so that taps see
> the exact frame received from the _device_ as you put it.
Although for accelerated vlan tags, it will be in the meta data
anyways. All I am asking is, let's have the same behaviour on both TX
and RX. If the tag in the packet let's have it that way in both ways
in what the tap sees.
^ permalink raw reply
* [patch 3.8-rc2] drivers/net/phy/micrel.c
From: Choi, David @ 2013-01-09 20:09 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, Choi, David, Doong, Ping
From: David J. Choi <david.choi@micrel.com>
Summary of changes:
This patch is primarily intended to cover more Ethernet phys from Micrel Inc. Additionally it
.supports ksz8081/91, ksz8061, ksz9051 device.
.changes KSxxx to KSZxxx for unified naming convention. For example, change KS8737 to KSZ8737.
.changes 9021 to 90x1 for commonly used names between 9021 and 9031 device, as this patch includes
KSZ9031 which belongs to same family as 9021.
2 files(include/linux/micrel_phy.h, drivers/net/phy/micrel.c) are changed.
Signed-off-by: David J. Choi <david.choi@micrel.com>
---
--- linux-3.8-rc2/include/linux/micrel_phy.h.orig 2013-01-03 12:37:30.176895530 -0800
+++ linux-3.8-rc2/include/linux/micrel_phy.h 2013-01-09 11:32:10.361384007 -0800
@@ -17,12 +17,17 @@
#define PHY_ID_KSZ8873MLL 0x000e7237
#define PHY_ID_KSZ9021 0x00221610
-#define PHY_ID_KS8737 0x00221720
+#define PHY_ID_KSZ8737 0x00221720
+/* same id: KS8021, KS8031 */
#define PHY_ID_KSZ8021 0x00221555
#define PHY_ID_KSZ8041 0x00221510
#define PHY_ID_KSZ8051 0x00221550
-/* both for ks8001 Rev. A/B, and for ks8721 Rev 3. */
+/* same id: ks8001 Rev. A/B, and ks8721 Rev 3. */
#define PHY_ID_KSZ8001 0x0022161A
+/* same id: KS8081, KS8091 */
+#define PHY_ID_KSZ8081 0x00221560
+#define PHY_ID_KSZ8061 0x00221570
+#define PHY_ID_KSZ9031 0x00221620
/* struct phy_device dev_flags definitions */
#define MICREL_PHY_50MHZ_CLK 0x00000001
--- linux-3.8-rc2/drivers/net/phy/micrel.c.orig 2013-01-03 10:12:26.961502521 -0800
+++ linux-3.8-rc2/drivers/net/phy/micrel.c 2013-01-09 11:24:03.119235092 -0800
@@ -12,8 +12,12 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*
- * Support : ksz9021 1000/100/10 phy from Micrel
- * ks8001, ks8737, ks8721, ks8041, ks8051 100/10 phy
+ * Support : Micrel Phys/switches:
+ * Giga phys: ksz9021, ksz9031
+ * 100/10 Phys: ksz8001, ksz8021, ksz8031, ksz8041, ksz8051,
+ * ksz8061, ksz8081, ksz8091,
+ * ksz8721, ksz8737,
+ * Switches: ksz8873
*/
#include <linux/kernel.h>
@@ -44,8 +48,8 @@
#define MII_KSZPHY_CTRL 0x1F
/* bitmap of PHY register to set interrupt mode */
#define KSZPHY_CTRL_INT_ACTIVE_HIGH (1 << 9)
-#define KSZ9021_CTRL_INT_ACTIVE_HIGH (1 << 14)
-#define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
+#define KSZ90X1_CTRL_INT_ACTIVE_HIGH (1 << 14)
+#define KSZ8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
#define KSZ8051_RMII_50MHZ_CLK (1 << 7)
static int kszphy_ack_interrupt(struct phy_device *phydev)
@@ -78,25 +82,25 @@ static int kszphy_config_intr(struct phy
return rc < 0 ? rc : 0;
}
-static int ksz9021_config_intr(struct phy_device *phydev)
+static int ksz90x1_config_intr(struct phy_device *phydev)
{
int temp, rc;
/* set the interrupt pin active low */
temp = phy_read(phydev, MII_KSZPHY_CTRL);
- temp &= ~KSZ9021_CTRL_INT_ACTIVE_HIGH;
+ temp &= ~KSZ90X1_CTRL_INT_ACTIVE_HIGH;
phy_write(phydev, MII_KSZPHY_CTRL, temp);
rc = kszphy_set_interrupt(phydev);
return rc < 0 ? rc : 0;
}
-static int ks8737_config_intr(struct phy_device *phydev)
+static int ksz8737_config_intr(struct phy_device *phydev)
{
int temp, rc;
/* set the interrupt pin active low */
temp = phy_read(phydev, MII_KSZPHY_CTRL);
- temp &= ~KS8737_CTRL_INT_ACTIVE_HIGH;
+ temp &= ~KSZ8737_CTRL_INT_ACTIVE_HIGH;
phy_write(phydev, MII_KSZPHY_CTRL, temp);
rc = kszphy_set_interrupt(phydev);
return rc < 0 ? rc : 0;
@@ -162,21 +166,21 @@ static int ksz8873mll_config_aneg(struct
static struct phy_driver ksphy_driver[] = {
{
- .phy_id = PHY_ID_KS8737,
+ .phy_id = PHY_ID_KSZ8737,
.phy_id_mask = 0x00fffff0,
- .name = "Micrel KS8737",
+ .name = "Micrel KSZ8737",
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
- .config_intr = ks8737_config_intr,
+ .config_intr = ksz8737_config_intr,
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = PHY_ID_KSZ8021,
.phy_id_mask = 0x00ffffff,
- .name = "Micrel KSZ8021",
+ .name = "Micrel KSZ8021 or KSZ8031",
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
SUPPORTED_Asym_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
@@ -214,7 +218,7 @@ static struct phy_driver ksphy_driver[]
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = PHY_ID_KSZ8001,
- .name = "Micrel KSZ8001 or KS8721",
+ .name = "Micrel KSZ8001 or KSZ8721",
.phy_id_mask = 0x00ffffff,
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
@@ -225,8 +229,32 @@ static struct phy_driver ksphy_driver[]
.config_intr = kszphy_config_intr,
.driver = { .owner = THIS_MODULE,},
}, {
+ .phy_id = PHY_ID_KSZ8081,
+ .name = "Micrel KSZ8081 or KSZ8091",
+ .phy_id_mask = 0x00fffff0,
+ .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = kszphy_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = kszphy_ack_interrupt,
+ .config_intr = kszphy_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+}, {
+ .phy_id = PHY_ID_KSZ8061,
+ .name = "Micrel KSZ8061",
+ .phy_id_mask = 0x00fffff0,
+ .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = kszphy_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = kszphy_ack_interrupt,
+ .config_intr = kszphy_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+}, {
.phy_id = PHY_ID_KSZ9021,
- .phy_id_mask = 0x000ffffe,
+ .phy_id_mask = 0x00fffffe,
.name = "Micrel KSZ9021 Gigabit PHY",
.features = (PHY_GBIT_FEATURES | SUPPORTED_Pause
| SUPPORTED_Asym_Pause),
@@ -235,7 +263,20 @@ static struct phy_driver ksphy_driver[]
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
- .config_intr = ksz9021_config_intr,
+ .config_intr = ksz90x1_config_intr,
+ .driver = { .owner = THIS_MODULE, },
+}, {
+ .phy_id = PHY_ID_KSZ9031,
+ .phy_id_mask = 0x00fffff0,
+ .name = "Micrel KSZ9031 Gigabit PHY",
+ .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause
+ | SUPPORTED_Asym_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = kszphy_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = kszphy_ack_interrupt,
+ .config_intr = ksz90x1_config_intr,
.driver = { .owner = THIS_MODULE, },
}, {
.phy_id = PHY_ID_KSZ8873MLL,
@@ -269,12 +310,15 @@ MODULE_AUTHOR("David J. Choi");
MODULE_LICENSE("GPL");
static struct mdio_device_id __maybe_unused micrel_tbl[] = {
- { PHY_ID_KSZ9021, 0x000ffffe },
+ { PHY_ID_KSZ9021, 0x00fffffe },
+ { PHY_ID_KSZ9031, 0x00fffff0 },
{ PHY_ID_KSZ8001, 0x00ffffff },
- { PHY_ID_KS8737, 0x00fffff0 },
+ { PHY_ID_KSZ8737, 0x00fffff0 },
{ PHY_ID_KSZ8021, 0x00ffffff },
{ PHY_ID_KSZ8041, 0x00fffff0 },
{ PHY_ID_KSZ8051, 0x00fffff0 },
+ { PHY_ID_KSZ8061, 0x00fffff0 },
+ { PHY_ID_KSZ8081, 0x00fffff0 },
{ PHY_ID_KSZ8873MLL, 0x00fffff0 },
{ }
};
---
^ permalink raw reply
* [patch 3.8-rc2] drivers/net/ethernet/micrel/ks8851_mll
From: Choi, David @ 2013-01-09 20:17 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, Choi, David, Doong, Ping
From: David J. Choi <david.choi@micrel.com>
Summary of changes:
.add codes to collect statistical information(for example rx/tx packets/bytes, error packets)
about Ethernet packets.
Signed-off-by: David J. Choi <david.choi@micrel.com>
---
--- linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c.orig 2013-01-03 09:45:57.830447923 -0800
+++ linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c 2013-01-03 10:05:57.675756568 -0800
@@ -801,7 +801,14 @@ static void ks_rcv(struct ks_net *ks, st
skb_put(skb, frame_hdr->len);
skb->protocol = eth_type_trans(skb, netdev);
netif_rx(skb);
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += (frame_hdr->len - 4);
} else {
+ netdev->stats.rx_dropped++;
+ if ((frame_hdr->len >= RX_BUF_SIZE) || (frame_hdr->len == 0))
+ netdev->stats.rx_length_errors++;
+ if (frame_hdr->sts & RXFSHR_RXFV)
+ netdev->stats.rx_frame_errors++;
pr_err("%s: err:skb alloc\n", __func__);
ks_wrreg16(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_RRXEF));
if (skb)
@@ -876,6 +883,8 @@ static irqreturn_t ks_irq(int irq, void
pmecr &= ~PMECR_WKEVT_MASK;
ks_wrreg16(ks, KS_PMECR, pmecr | PMECR_WKEVT_LINK);
}
+ if (unlikely(status & IRQ_RXOI))
+ ks->netdev->stats.rx_over_errors++;
/* this should be the last in IRQ handler*/
ks_restore_cmd_reg(ks);
@@ -1015,6 +1024,8 @@ static int ks_start_xmit(struct sk_buff
if (likely(ks_tx_fifo_space(ks) >= skb->len + 12)) {
ks_write_qmu(ks, skb->data, skb->len);
+ netdev->stats.tx_bytes += skb->len;
+ netdev->stats.tx_packets++;
dev_kfree_skb(skb);
} else
retv = NETDEV_TX_BUSY;
---
^ permalink raw reply
* [ 57/80] batman-adv: fix random jitter calculation
From: Greg Kroah-Hartman @ 2013-01-09 20:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Akinobu Mita, Antonio Quartulli,
Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev
In-Reply-To: <20130109201500.410171651@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <akinobu.mita@gmail.com>
[ Upstream commit 143cdd8f33909ff5a153e3f02048738c5964ba26 ]
batadv_iv_ogm_emit_send_time() attempts to calculates a random integer
in the range of 'orig_interval +- BATADV_JITTER' by the below lines.
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
msecs += (random32() % 2 * BATADV_JITTER);
But it actually gets 'orig_interval' or 'orig_interval - BATADV_JITTER'
because '%' and '*' have same precedence and associativity is
left-to-right.
This adds the parentheses at the appropriate position so that it matches
original intension.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/batman-adv/bat_iv_ogm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -72,7 +72,7 @@ static unsigned long bat_iv_ogm_emit_sen
{
return jiffies + msecs_to_jiffies(
atomic_read(&bat_priv->orig_interval) -
- JITTER + (random32() % 2*JITTER));
+ JITTER + (random32() % (2*JITTER)));
}
/* when do we schedule a ogm packet to be sent */
^ permalink raw reply
* [ 084/123] batman-adv: fix random jitter calculation
From: Greg Kroah-Hartman @ 2013-01-09 20:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Akinobu Mita, Antonio Quartulli,
Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev
In-Reply-To: <20130109201458.392601412@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <akinobu.mita@gmail.com>
[ Upstream commit 143cdd8f33909ff5a153e3f02048738c5964ba26 ]
batadv_iv_ogm_emit_send_time() attempts to calculates a random integer
in the range of 'orig_interval +- BATADV_JITTER' by the below lines.
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
msecs += (random32() % 2 * BATADV_JITTER);
But it actually gets 'orig_interval' or 'orig_interval - BATADV_JITTER'
because '%' and '*' have same precedence and associativity is
left-to-right.
This adds the parentheses at the appropriate position so that it matches
original intension.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/batman-adv/bat_iv_ogm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -119,7 +119,7 @@ batadv_iv_ogm_emit_send_time(const struc
unsigned int msecs;
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
- msecs += (random32() % 2 * BATADV_JITTER);
+ msecs += random32() % (2 * BATADV_JITTER);
return jiffies + msecs_to_jiffies(msecs);
}
^ permalink raw reply
* Re: [patch 3.8-rc2] drivers/net/phy/micrel.c
From: Ben Hutchings @ 2013-01-09 20:54 UTC (permalink / raw)
To: Choi, David; +Cc: davem@davemloft.net, netdev@vger.kernel.org, Doong, Ping
In-Reply-To: <FD9AD8C5375B924CABC56D982DB3A802079D2509@EXMB1.micrel.com>
You'll need to give this a proper subject, like 'micrel_phy: Add support
for new PHYs'.
On Wed, 2013-01-09 at 20:09 +0000, Choi, David wrote:
> From: David J. Choi <david.choi@micrel.com>
>
> Summary of changes:
> This patch is primarily intended to cover more Ethernet phys from Micrel Inc. Additionally it
> .supports ksz8081/91, ksz8061, ksz9051 device.
This is new hardware support which is probably acceptable for the 'net'
tree.
The additional cleanup:
> .changes KSxxx to KSZxxx for unified naming convention. For example, change KS8737 to KSZ8737.
> .changes 9021 to 90x1 for commonly used names between 9021 and 9031 device, as this patch includes
> KSZ9031 which belongs to same family as 9021.
[...]
should be a separate patch that goes into the 'net-next' tree.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch 3.8-rc2] drivers/net/ethernet/micrel/ks8851_mll
From: Ben Hutchings @ 2013-01-09 20:59 UTC (permalink / raw)
To: Choi, David; +Cc: davem@davemloft.net, netdev@vger.kernel.org, Doong, Ping
In-Reply-To: <FD9AD8C5375B924CABC56D982DB3A802079D2520@EXMB1.micrel.com>
Again this needs a proper subject, like 'ks8851_mll: Implement basic
statistics'.
It should be based on the 'net-next' tree.
On Wed, 2013-01-09 at 20:17 +0000, Choi, David wrote:
> From: David J. Choi <david.choi@micrel.com>
>
> Summary of changes:
> .add codes to collect statistical information(for example rx/tx packets/bytes, error packets)
> about Ethernet packets.
>
> Signed-off-by: David J. Choi <david.choi@micrel.com>
> ---
>
> --- linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c.orig 2013-01-03 09:45:57.830447923 -0800
> +++ linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c 2013-01-03 10:05:57.675756568 -0800
> @@ -801,7 +801,14 @@ static void ks_rcv(struct ks_net *ks, st
> skb_put(skb, frame_hdr->len);
> skb->protocol = eth_type_trans(skb, netdev);
> netif_rx(skb);
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += (frame_hdr->len - 4);
You're subtracting 4 for the CRC? That really shouldn't be visible to
the kernel (unless the NETIF_F_RXFCS feature is enabled on the device).
So you should also substract 4 from the length passed to skb_put().
(That would be a separate patch, probably suitable for the 'net' tree.)
> } else {
> + netdev->stats.rx_dropped++;
> + if ((frame_hdr->len >= RX_BUF_SIZE) || (frame_hdr->len == 0))
> + netdev->stats.rx_length_errors++;
> + if (frame_hdr->sts & RXFSHR_RXFV)
> + netdev->stats.rx_frame_errors++;
[...]
These two increment statements are indented wrongly.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-09 21:29 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130108224313.GA13304@suse.de>
Mel Gorman <mgorman@suse.de> wrote:
> When I looked at it for long enough I found a number of problems. Most
> affect timing but two serious issues are in there. One affects how long
> kswapd spends compacting versus reclaiming and the other increases lock
> contention meaning that async compaction can abort early. Both are serious
> and could explain why a driver would fail high-order allocations.
>
> Please try the following patch. However, even if it works the benefit of
> capture may be so marginal that partially reverting it and simplifying
> compaction.c is the better decision.
Btw, I'm still testing this patch with the "page->pfemalloc = false"
change on top of it.
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 6b807e4..03c82c0 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -857,7 +857,8 @@ static int compact_finished(struct zone *zone,
> } else {
> unsigned int order;
> for (order = cc->order; order < MAX_ORDER; order++) {
> - struct free_area *area = &zone->free_area[cc->order];
> + struct free_area *area = &zone->free_area[order];
I noticed something like this hunk wasn't in your latest partial revert
(<20130109135010.GB13475@suse.de>)
I admit I don't understand this code, but this jumped out at me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Greg Rose @ 2013-01-09 21:37 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Stefan Assmann, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D1F8B539A@FMSMSX107.amr.corp.intel.com>
On Wed, 9 Jan 2013 18:56:36 +0000
"Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> > >> When the PF is up and igbvf is loaded the MAC address is not
> > >> generated using eth_hw_addr_random(). This results in
> > >> addr_assign_type not to be set.
> > >> Make sure it gets set.
> > >>
> > >
> > > NAK - In this case, the address may or may not be random. The
> > > user may have (and should have!) explicitly set this address from
> > > the host to ensure that the VF device receives the same address
> > > each time it
> > boots.
> >
> > Maybe you can give me some advice on this then. Why is there
> > different behaviour depending on the PF being up or down? The
> > problem I'm facing is that if the user did not set a MAC address
> > for the VF manually and the PF is up during igbvf_probe it will not
> > be labelled as random although it is.
> > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > NET_ADDR_RANDOM if the flag is cleared?
> >
>
> The difference in behavior is because we cannot get any MAC address
> at all if the PF is down. The interface won't operate at all in this
> case, but if the PF comes up sometime later, we can start working.
> The other alternative is to leave the MAC address as all zeros and
> forcing the user to assign an address manually. We chose to use a
> random address to at least give it a chance of working once the PF
> woke up.
Having been around at the inception of SR-IOV in Linux I recall that
the primary reason we used a random ethernet address was so
that the VF could at least work because there was no infrastructure
to allow the host administrator to set the MAC address of the VF. This
hobbled testing and validation because the user would have to go to
each VM and use a command local to the VM to set the VF MAC address to
some LAA via ifconfig or ip. When testing large numbers of VFs this was
a definite pain.
Now that has changed and I wonder if maybe we shouldn't back out the
random ethernet address assignment and go ahead with all zeros, leaving
the device non-functional until the user has intentionally set either
an LAA through the VF itself, or an administratively assigned MAC
through the ip tool via the PF.
Use of the random MAC address is not recommended by Intel's own best
known methods literature, it was used mostly so that we could get the
technology working and it should probably be at least considered for
deprecation or out right elimination.
My two cents...
- Greg
^ permalink raw reply
* [PATCH net-next] doc: Clarify behavior when sysctl tcp_ecn = 1
From: Vijay Subramanian @ 2013-01-09 22:21 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, rick.jones2, Vijay Subramanian
Recent commit (commit 7e3a2dc52953 doc: make the description of how tcp_ecn
works more explicit and clear ) clarified the behavior of tcp_ecn sysctl
variable but description is inconsistent. When requested by incoming conections,
ECN is enabled with not just tcp_ecn = 2 but also with tcp_ecn = 1.
This patch makes it clear that with tcp_ecn = 1, ECN is enabled when requested
by incoming connections.
Also fix spelling of 'incoming'.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
Documentation/networking/ip-sysctl.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d51..51dcd52 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -214,8 +214,9 @@ tcp_ecn - INTEGER
congestion before having to drop packets.
Possible values are:
0 Disable ECN. Neither initiate nor accept ECN.
- 1 Always request ECN on outgoing connection attempts.
- 2 Enable ECN when requested by incomming connections
+ 1 Enable ECN when requested by incoming connections and
+ also request ECN on outgoing connection attempts.
+ 2 Enable ECN when requested by incoming connections
but do not request ECN on outgoing connections.
Default: 2
--
1.7.0.4
^ permalink raw reply related
* Re: recvmmsg() timeout behavior strangeness
From: Chris Friesen @ 2013-01-09 22:33 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Arnaldo Carvalho de Melo, Caitlin Bestler, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, Chris Van Hoof, Clark Williams,
Neil Horman, Arnaldo Carvalho de Melo, Andrew Grover,
Elie De Brauwer, linux-man-u79uwXL29TY76Z2rM5mHXA,
Steven Whitehouse, Rémi Denis-Courmont
In-Reply-To: <CAHO5Pa2goUtiBU8ye2beTBExL4it2-aDCPBhDOGyO3NX_PV_pQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/23/2012 02:50 PM, Michael Kerrisk wrote:
> If I understand correctly, the *intended* purpose of the timeout
> argument is to set a limit on how long to wait for additional
> datagrams after the arrival of an initial datagram. However, the
> syscall behaves in quite a different way. Instead, it potentially
> blocks forever, regardless of the timeout.
Looking at the code, I think you're correct.
The comments for a2e2725 say the timeout works like for ppoll(), where
it is "an upper limit on the time for which poll() will block, in
milliseconds."
I wonder if we could play some games with sk->sk_rcvtimeo to accomplish
this?
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-09 22:58 UTC (permalink / raw)
To: Linux Networking Developer Mailing List; +Cc: sparclinux
Hi,
I am observing that a machine with a niu card/driver automatically
enables itself and then goes dormant again.
[ 4410.930078] niu 0000:10:00.0 eth4: Link is up at 100Mbit/sec, full duplex
[ 4410.930137] br0: port 4(eth4) entered forwarding state
[ 4410.930156] br0: port 4(eth4) entered forwarding state
[ 4420.957745] niu 0000:10:00.0 eth4: Link is down
The interface itself is marked UP, and is part of a bridge,
if that matters. The kernel version is 3.7.1 on sparc64.
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
qdisc mq master br0 state DOWN qlen 1000
link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
inet6 fe80::221:28ff:fe71:325a/64 scope link
valid_lft forever preferred_lft forever
At the same time, eth5, to which a cable+machine _is_ connected,
randomly goes out. At first I thought it might be the connected peer,
but seeing that eth4 randomly does a up-down cycle leads me to assume
that niu is doing a cycle here rather than the peer.
[ 3839.724721] niu 0000:10:00.1 eth5: Link is down
[ 3839.725077] br0: port 5(eth5) entered disabled state
[ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
[ 3840.725195] br0: port 5(eth5) entered forwarding state
[ 3840.725327] br0: port 5(eth5) entered forwarding state
[ 3855.762171] br0: port 5(eth5) entered forwarding state
dmesg for niu:
[ 60.158957] niu: niu.c:v1.1 (Apr 22, 2010)
[ 60.160457] niu: niu0: Found PHY 002060b1 type MII at phy_port 10
[ 60.160887] niu: niu0: Found PHY 002060b1 type MII at phy_port 11
[ 60.161314] niu: niu0: Found PHY 002060b1 type MII at phy_port 12
[ 60.161739] niu: niu0: Found PHY 002060b1 type MII at phy_port 13
[ 60.168250] niu: niu0: Port 0 [4 RX chans] [6 TX chans]
[ 60.168319] niu: niu0: Port 1 [4 RX chans] [6 TX chans]
[ 60.168386] niu: niu0: Port 2 [4 RX chans] [6 TX chans]
[ 60.168452] niu: niu0: Port 3 [4 RX chans] [6 TX chans]
[ 60.168519] niu: niu0: Port 0 RDC tbl(0) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ]
[ 60.168913] niu: niu0: Port 0 RDC tbl(1) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ]
[ 60.169213] niu: niu0: Port 1 RDC tbl(2) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ]
[ 60.169503] niu: niu0: Port 1 RDC tbl(3) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ]
[ 60.169790] niu: niu0: Port 2 RDC tbl(4) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ]
[ 60.170078] niu: niu0: Port 2 RDC tbl(5) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ]
[ 60.170366] niu: niu0: Port 3 RDC tbl(6) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ]
[ 60.170657] niu: niu0: Port 3 RDC tbl(7) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ]
[ 60.416607] niu: eth4: NIU Ethernet 00:21:28:71:32:5a
[ 60.416679] niu: eth4: Port type[XMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 60.624669] niu: eth5: NIU Ethernet 00:21:28:71:32:5b
[ 60.624741] niu: eth5: Port type[XMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 60.832774] niu: eth6: NIU Ethernet 00:21:28:71:32:5c
[ 60.832845] niu: eth6: Port type[BMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 61.040806] niu: eth7: NIU Ethernet 00:21:28:71:32:5d
[ 61.040877] niu: eth7: Port type[BMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
lspci:
10:00.0 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000015
Memory at 01000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d00000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d08000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 00e00000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.1 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000016
Memory at 02000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d10000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d18000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 00f00000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.2 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000017
Memory at 03000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d20000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d28000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 04000000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.3 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000014
Memory at 05000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d30000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d38000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 04100000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
Any other info needed?
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: David Miller @ 2013-01-09 23:56 UTC (permalink / raw)
To: jengelh; +Cc: netdev, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301092342290.21351@nerf07.vanv.qr>
I'm just letting you know ahead of time that, given my current
workload and travel schedule, I will not be able to look into
this problem at all and someone else will need to do so.
Thanks.
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Julian Calaby @ 2013-01-10 0:24 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301092342290.21351@nerf07.vanv.qr>
Hi Jan,
I'm not familiar with the hardware or drivers, so I won't be able to
help you that much either, but I can ask a couple of pointed
questions. =)
On Thu, Jan 10, 2013 at 9:58 AM, Jan Engelhardt <jengelh@inai.de> wrote:
> Hi,
>
> I am observing that a machine with a niu card/driver automatically
> enables itself and then goes dormant again.
>
> [ 4410.930078] niu 0000:10:00.0 eth4: Link is up at 100Mbit/sec, full duplex
> [ 4410.930137] br0: port 4(eth4) entered forwarding state
> [ 4410.930156] br0: port 4(eth4) entered forwarding state
> [ 4420.957745] niu 0000:10:00.0 eth4: Link is down
>
> The interface itself is marked UP, and is part of a bridge,
> if that matters. The kernel version is 3.7.1 on sparc64.
>
> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
> qdisc mq master br0 state DOWN qlen 1000
> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
> inet6 fe80::221:28ff:fe71:325a/64 scope link
> valid_lft forever preferred_lft forever
That is rather odd. Is this particular interface connected to anything
that could be causing this?
> At the same time, eth5, to which a cable+machine _is_ connected,
> randomly goes out. At first I thought it might be the connected peer,
> but seeing that eth4 randomly does a up-down cycle leads me to assume
> that niu is doing a cycle here rather than the peer.
>
> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
> [ 3839.725077] br0: port 5(eth5) entered disabled state
> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
> [ 3840.725195] br0: port 5(eth5) entered forwarding state
> [ 3840.725327] br0: port 5(eth5) entered forwarding state
> [ 3855.762171] br0: port 5(eth5) entered forwarding state
Again, could it be the device at the end of the link?
Out of curiosity, why do you have these two ports bridged together and
what is the purpose of this configuration?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH V3 1/2] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
From: Rusty Russell @ 2013-01-10 0:49 UTC (permalink / raw)
To: Wanlong Gao
Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization,
Eric Dumazet
In-Reply-To: <50ECCDF3.9050403@cn.fujitsu.com>
Wanlong Gao <gaowanlong@cn.fujitsu.com> writes:
> On 01/09/2013 07:31 AM, Rusty Russell wrote:
>> Wanlong Gao <gaowanlong@cn.fujitsu.com> writes:
>>> */
>>> static u16 virtnet_select_queue(struct net_device *dev, struct sk_buff *skb)
>>> {
>>> - int txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) :
>>> - smp_processor_id();
>>> + int txq = 0;
>>> +
>>> + if (skb_rx_queue_recorded(skb))
>>> + txq = skb_get_rx_queue(skb);
>>> + else if ((txq = per_cpu(vq_index, smp_processor_id())) == -1)
>>> + txq = 0;
>>
>> You should use __get_cpu_var() instead of smp_processor_id() here, ie:
>>
>> else if ((txq = __get_cpu_var(vq_index)) == -1)
>>
>> And AFAICT, no reason to initialize txq to 0 to start with.
>>
>> So:
>>
>> int txq;
>>
>> if (skb_rx_queue_recorded(skb))
>> txq = skb_get_rx_queue(skb);
>> else {
>> txq = __get_cpu_var(vq_index);
>> if (txq == -1)
>> txq = 0;
>> }
>
> Got it, thank you.
>
>>
>> Now, just to confirm, I assume this can happen even if we use vq_index,
>> right, because of races with virtnet_set_channels?
>
> I still can't understand this race, could you explain more? thank you.
I assume that someone can call virtnet_set_channels() while we are
inside virtnet_select_queue(), so they reduce dev->real_num_tx_queues,
causing virtnet_set_channels to do:
while (unlikely(txq >= dev->real_num_tx_queues))
txq -= dev->real_num_tx_queues;
Otherwise, when is this loop called?
Thanks,
Rusty.
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-10 0:55 UTC (permalink / raw)
To: Julian Calaby; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <CAGRGNgWqweBphbr+rpTZ2Fe=yLG_xNSvS4sf8XteoCiAx8b81A@mail.gmail.com>
On Thursday 2013-01-10 01:24, Julian Calaby wrote:
>>
>> The interface itself is marked UP, and is part of a bridge,
>> if that matters. The kernel version is 3.7.1 on sparc64.
>>
>> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
>> qdisc mq master br0 state DOWN qlen 1000
>> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::221:28ff:fe71:325a/64 scope link
>> valid_lft forever preferred_lft forever
>
>That is rather odd. Is this particular interface connected to anything
>that could be causing this?
Nope, there is nothing connected to eth4. UP indicates that
I had issue `ip link set dev eth4 up`.
>> At the same time, eth5, to which a cable+machine _is_ connected,
>> randomly goes out. At first I thought it might be the connected peer,
>> but seeing that eth4 randomly does a up-down cycle leads me to assume
>> that niu is doing a cycle here rather than the peer.
>>
>> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
>> [ 3839.725077] br0: port 5(eth5) entered disabled state
>> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
>> [ 3840.725195] br0: port 5(eth5) entered forwarding state
>> [ 3840.725327] br0: port 5(eth5) entered forwarding state
>> [ 3855.762171] br0: port 5(eth5) entered forwarding state
>
>Again, could it be the device at the end of the link?
>Out of curiosity, why do you have these two ports bridged together and
>what is the purpose of this configuration?
Nobody expects the... lack of a switch. And since there are
plenty of ports in the machine anyway, might as well use them as a
software switch as an intermediate solution.
eth0 through eth3 is a quad-port e1000e.
eth4 through eth7 is the quad-port niu.
The e1000e ports don't flake out at all, therefore I rate
the peer(s) being at fault with a very low probability.
The issue is not pressing, since it's just service processors
which are connected.
^ permalink raw reply
* Re: [PATCH 01/19] netfilter: move nf_conntrack initialize out of pernet operations
From: Gao feng @ 2013-01-10 1:03 UTC (permalink / raw)
To: canqun zhang
Cc: netfilter-devel, netdev@vger.kernel.org, Patrick McHardy, pablo,
Eric W. Biederman
In-Reply-To: <CAFFEFTXU1Yptqx0x6CjtqXMU+7HYu4F7Hk7u29oPCeghZ9Wc_Q@mail.gmail.com>
Hi canqun,
On 2012/12/28 16:48, canqun zhang wrote:
> ok, I can help you take a test, please send a big patch container this
> patchset to my email.
>
Can you give me your tested-by to this patchset besides patch [19/19]?
Thanks!
>
> 2012/12/28 Gao feng <gaofeng@cn.fujitsu.com>:
>> On 12/28/12 11:52, canqun zhang wrote:
>>> Hi all
>>> As discussed above,if the host machine create several linux
>>> containers, there will be several net namespaces.Resources with "nf
>>> conntrack" are registered or unregistered on the first net
>>> namespace(init_net),But init_net is not unregistered lastly,so
>>> cleanuping other net namespaces will triger painic.
>>> If net namespaces are created with the order of 1,2,...n,they should
>>> be cleaned with the order of n,...2,1,so in this case init_net will be
>>> unregistered lastly.
>>> I fixed it up (see below). I have taken a lot of test!
>>>
>>
>> I thinks this BUG is a netfilter BUG,not a netns BUG.
>> Other subsystems implemented netns support don't use init_net to
>> do some special works((un)register/(un)set).
>>
>> In fact,we can't use init_net to do this job well.such as function
>> nf_conntrack_clean,we shoud set ip_ct_attach to NULL before any
>> netns doing cleanup jobs, and set nf_ct_destroy to NULL after all of
>> netns finish these cleanup jobs.
>>
>> So I think finally we still need this patchset,And this is a regular
>> way to fix this problem.
>>
>> Can you help me to test if the panic bug is fixed by this patchset?
>> and then give me your tested-by?
>>
>> thank you very much!
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Julian Calaby @ 2013-01-10 1:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301100134300.29388@nerf07.vanv.qr>
Hi Jan,
Thanks for the answers.
On Thu, Jan 10, 2013 at 11:55 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Thursday 2013-01-10 01:24, Julian Calaby wrote:
>>>
>>> The interface itself is marked UP, and is part of a bridge,
>>> if that matters. The kernel version is 3.7.1 on sparc64.
>>>
>>> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
>>> qdisc mq master br0 state DOWN qlen 1000
>>> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::221:28ff:fe71:325a/64 scope link
>>> valid_lft forever preferred_lft forever
>>
>>That is rather odd. Is this particular interface connected to anything
>>that could be causing this?
>
> Nope, there is nothing connected to eth4. UP indicates that
> I had issue `ip link set dev eth4 up`.
I assumed that from the "NO-CARRIER" status, but I had to check: for
all I know it's some sort of failover connection and is hooked up to a
disabled port on a different switch.
>>> At the same time, eth5, to which a cable+machine _is_ connected,
>>> randomly goes out. At first I thought it might be the connected peer,
>>> but seeing that eth4 randomly does a up-down cycle leads me to assume
>>> that niu is doing a cycle here rather than the peer.
>>>
>>> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
>>> [ 3839.725077] br0: port 5(eth5) entered disabled state
>>> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
>>> [ 3840.725195] br0: port 5(eth5) entered forwarding state
>>> [ 3840.725327] br0: port 5(eth5) entered forwarding state
>>> [ 3855.762171] br0: port 5(eth5) entered forwarding state
>>
>>Again, could it be the device at the end of the link?
>>Out of curiosity, why do you have these two ports bridged together and
>>what is the purpose of this configuration?
>
> Nobody expects the... lack of a switch. And since there are
> plenty of ports in the machine anyway, might as well use them as a
> software switch as an intermediate solution.
True that. I have an overabundance of PCI network cards and have built
temporary servers with two of them bridged together so I'm not
stealing a port that might be needed.
> eth0 through eth3 is a quad-port e1000e.
> eth4 through eth7 is the quad-port niu.
>
> The e1000e ports don't flake out at all, therefore I rate
> the peer(s) being at fault with a very low probability.
Makes sense.
> The issue is not pressing, since it's just service processors
> which are connected.
Ok, I'm guessing that this is production so heavy debugging isn't
going to happen.
I'm out of ideas. Tag?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-10 1:52 UTC (permalink / raw)
To: Julian Calaby; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <CAGRGNgX6u=Q4_8pFhLNHDQYRCv1m3ULBgyc+wA=+_KDjDDbSjQ@mail.gmail.com>
On Thursday 2013-01-10 02:27, Julian Calaby wrote:
>
>> The issue is not pressing, since it's just service processors
>> which are connected.
>
>Ok, I'm guessing that this is production so heavy debugging isn't
>going to happen.
No production, free to toy.
>I'm out of ideas. Tag?
Here is a fun fact. If I disable autonegotiation (via ethtool) on the
link on the niu side, the remote side will deassert the carrier and
won't return it until autoneg is turned on again.
In fact, if I do `ethtool -s eth7 autoneg off; ethtool -s eth7 autoneg
on;`, it will take a good exact second (~1.000400 s) for the HW to
reestablish an autonegotiated link. This delay is of the same magnitude
and value as when the link bounces on its own.
Hypothesis: maybe the niu HW drops autoneg for a splitsecond (or it
gets lost due to some other reason), causing the observed bounces.
^ permalink raw reply
* Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Andy King @ 2013-01-10 2:42 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Dmitry Torokhov, pv-drivers, gregkh, linux-kernel, virtualization,
netdev, David Miller
In-Reply-To: <50ED25E7.9010609@redhat.com>
> > Our position is that VSOCK feature set is more complete and that it
> > should be possible to use transports other than VMCI for VSOCK
> > traffic, should interested parties implement them,
>
> Implementing other transports requires restructing vsock (and vmci)
> first as the current vsock code is not a hypervisor neutral service.
I'm going to bite the bullet and spend the next couple of days doing
just that: factoring out the VMCI bits and hiding them behind a
transport layer. It'll be a bit rough, but it'll be a start. We'll
submit another patch series next week with that. I'm hoping that'll
get us over this hump, since it should by hypervisor agnostic at
that point. It'll be up to you guys to add virtio, though :)
And in the meantime, are there any other glaring errors that we need
to address?
Thanks!
- Andy
^ permalink raw reply
* Re: [patch net-next 5/7] net: remove unnecessary NET_ADDR_RANDOM "bitclean"
From: Antonio Quartulli @ 2013-01-10 2:55 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <1357047019-1037-6-git-send-email-jiri@resnulli.us>
Il 01.01.2013 15:30 Jiri Pirko ha scritto:
> NET_ADDR_SET is set in dev_set_mac_address() no need to alter
> dev->addr_assign_type value in drivers.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Hello Jiri,
please, next time it would be good if you CC all the poeple involved in
a patch: in this way
everybody can easily realise that the code they are maintaining is
going to be touched/modified.
If you don't (like this time) we have to wait some somebody/something
comparing net-next with
our tree to trigger a reaction in our repo.
The get_maintainer.pl script will give you all the email addresses that
you should include
(some of them can possibly be skept).
Thanks a lot,
Antonio
--
Antonio Quartulli
^ permalink raw reply
* Re: tainted warnings with tcp splicing in 3.7.1
From: Eric Dumazet @ 2013-01-10 6:59 UTC (permalink / raw)
To: Christian Becker, David Miller; +Cc: netdev@vger.kernel.org, Willy Tarreau
In-Reply-To: <1357751372.27446.40.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
On Wed, 2013-01-09 at 09:09 -0800, Eric Dumazet wrote:
> My feeling is that tcp_recv_skb() should eat skbs instead of only
> finding the right one
>
Thats indeed the case.
> Thats because skb_splice_bits() releases the socket lock before calling
> splice_to_pipe()
>
> Once socket is released, other incoming TCP frames can be processed, and
> the skb we are actually processing might be 'collapsed' into smaller
> units.
>
> Christian, if I send you patches, are you OK to test them ?
>
>
Here is the patch fixing this issue.
Thanks a lot for your report, this is a very very old bug.
GRO being more deployed, and with TCP coalescing as well, chances to
trigger this bug increased a lot.
To reproduce it, I had to force MSS=400 and stress the receiver,
adding extra delays in skb_splice_bits() with socket lock being not
held.
[PATCH] tcp: fix splice() and tcp collapsing interaction
Under unusual circumstances, TCP collapse can split a big GRO TCP packet
while its being used in a splice(socket->pipe) operation.
skb_splice_bits() releases the socket lock before calling
splice_to_pipe().
[ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
[ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
[ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
To fix this problem, we must eat skbs in tcp_recv_skb().
Remove the inline keyword from tcp_recv_skb() definition since
it has three call sites.
Reported-by: Christian Becker <c.becker@traviangames.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1ca2536..1f901be 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1428,12 +1428,12 @@ static void tcp_service_net_dma(struct sock *sk, bool wait)
}
#endif
-static inline struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
+static struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
{
struct sk_buff *skb;
u32 offset;
- skb_queue_walk(&sk->sk_receive_queue, skb) {
+ while ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) {
offset = seq - TCP_SKB_CB(skb)->seq;
if (tcp_hdr(skb)->syn)
offset--;
@@ -1441,6 +1441,11 @@ static inline struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
*off = offset;
return skb;
}
+ /* This looks weird, but this can happen if TCP collapsing
+ * splitted a fat GRO packet, while we released socket lock
+ * in skb_splice_bits()
+ */
+ sk_eat_skb(sk, skb, false);
}
return NULL;
}
@@ -1520,8 +1525,10 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
tcp_rcv_space_adjust(sk);
/* Clean up data we have read: This will do ACK frames. */
- if (copied > 0)
+ if (copied > 0) {
+ tcp_recv_skb(sk, seq, &offset);
tcp_cleanup_rbuf(sk, copied);
+ }
return copied;
}
EXPORT_SYMBOL(tcp_read_sock);
^ permalink raw reply related
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: jianhai luan @ 2013-01-10 7:00 UTC (permalink / raw)
To: Ian Campbell; +Cc: Jan Beulich, xen-devel, netdev
In-Reply-To: <50EDA624.1010008@163.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
The patch main to fix the below circumstance:
Bonding run in Active-Backup mode.
Out PC --> switcher
port A --> eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
port B -- eth1 /
Or
Out PC (R)--> switcher A --> eth0 --> bond0 --> xenbr0 --> netbackend
--> DomU
\ switcher B -- eth1 /
When Switcher Port A (active port) don't reach, or switcher A don't reach,
the surroundings will changed to the below circumstance.
Out PC --> switcher
port A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
port B -- eth1 /
Or
Out PC (R)--> switcher A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
\ switcher B -- eth1 /
So, the former traffic will be unreachable before find the correct path
(by sending
ARP request).
So, the patch is main to found the bonding change event, and gratutious
ARP initialtivly
to out PC find the correct path.
the correct path should be the below circumstance:
Out PC --> switcher
port A -X- eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
port B --> eth1 /
Or
Out PC (R)--> switcher A -X- eth0 --> bond0 --> xenbr0 --> netbackend
--> DomU
\ switcher B --> eth1 /
Thanks,
Jason
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch --]
[-- Type: text/plain; charset=gb18030; name="0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch", Size: 3502 bytes --]
From cd5a33f9137a60f27c2a8c6c77a520d2df356c7a Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
Date: Fri, 28 Dec 2012 15:43:06 +0800
Subject: [PATCH] xen-netback notify frontend to send gratuitous ARP.
In the real network environment, some cause will lead
to Active-Backup mode bonding chose new actived port.
After that, the trffic, destinated to DomU by inactived
port (former actived port), will be unreachable at now.
DomU should send gratutious ARP initialtivly to find the
new corrected path.
By netback's Connected->Connected transition, frontend
will watch the change, and send gratuitous ARP.
Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
drivers/net/xen-netback/xenbus.c | 68 ++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..ebea683 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -26,6 +26,7 @@ struct backend_info {
struct xenvif *vif;
enum xenbus_state frontend_state;
struct xenbus_watch hotplug_status_watch;
+ struct notifier_block vif_notifier;
u8 have_hotplug_status_watch:1;
};
@@ -34,11 +35,74 @@ static void connect(struct backend_info *);
static void backend_create_xenvif(struct backend_info *be);
static void unregister_hotplug_status_watch(struct backend_info *be);
+/*
+ * By Connected->Connected transition, netfront will watch the change and
+ * send gratuitous ARP.
+ */
+static void notify_front_arping(struct xenbus_device *dev)
+{
+ struct xenbus_transaction xbt;
+ int err;
+
+ if (xenbus_read_driver_state(dev->nodename) != XenbusStateConnected)
+ return;
+
+again:
+ err = xenbus_transaction_start(&xbt);
+ if (err) {
+ pr_fmt("Error starting transaction");
+ return;
+ }
+
+ err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
+ if (err) {
+ pr_fmt("Error writing the state");
+ goto abort;
+ }
+
+ err = xenbus_transaction_end(xbt, 0);
+ if (err == -EAGAIN)
+ goto again;
+ if (err)
+ pr_fmt("Error ending transaction");
+
+ return;
+abort:
+ xenbus_transaction_end(xbt, 1);
+}
+
+#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier)
+/**
+ * When network condition of vif change, notify the frontend.
+ */
+static int netback_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = ptr;
+ struct backend_info *be = nb_to_backend(this);
+
+ pr_debug("event_dev: %s, event: %lx\n",
+ event_dev ? event_dev->name : "None", event);
+
+ if (!be->vif)
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_NOTIFY_PEERS:
+ /* Notify frontend to Send gratuitous ARP */
+ notify_front_arping(be->dev);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static int netback_remove(struct xenbus_device *dev)
{
struct backend_info *be = dev_get_drvdata(&dev->dev);
unregister_hotplug_status_watch(be);
+ unregister_netdevice_notifier(&be->vif_notifier);
if (be->vif) {
kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
@@ -129,6 +193,10 @@ static int netback_probe(struct xenbus_device *dev,
/* This kicks hotplug scripts, so do it immediately. */
backend_create_xenvif(be);
+ /* Register Frontend Event Notify */
+ be->vif_notifier.notifier_call = netback_netdev_event;
+ register_netdevice_notifier(&be->vif_notifier);
+
return 0;
abort_transaction:
--
1.7.6.5
^ 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