* [PATCH v3.4-rc 3/9] pch_gbe: reprogram multicast address register on reset
From: Richard Cochran @ 2012-04-20 20:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Takahiro Shimizu
In-Reply-To: <cover.1334949388.git.richardcochran@gmail.com>
From: Takahiro Shimizu <tshimizu818@gmail.com>
The reset logic after a Rx FIFO overrun will clear the programmed
multicast addresses. This patch fixes the issue by reprogramming the
registers after the reset.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 60 +++++++++++++++++++-
1 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 6a9a63b..dc15e93 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -383,31 +383,85 @@ static void pch_gbe_mac_mar_set(struct pch_gbe_hw *hw, u8 * addr, u32 index)
}
/**
+ * pch_gbe_mac_save_mac_addr_regs - Save MAC addresse registers
+ * @hw: Pointer to the HW structure
+ * @addr: Pointer to the MAC address
+ * @index: MAC address array register
+ */
+static void
+pch_gbe_mac_save_mac_addr_regs(struct pch_gbe_hw *hw,
+ struct pch_gbe_regs_mac_adr *mac_adr, u32 index)
+{
+ mac_adr->high = ioread32(&hw->reg->mac_adr[index].high);
+ mac_adr->low = ioread32(&hw->reg->mac_adr[index].low);
+}
+
+/**
+ * pch_gbe_mac_store_mac_addr_regs - Store MAC addresse registers
+ * @hw: Pointer to the HW structure
+ * @addr: Pointer to the MAC address
+ * @index: MAC address array register
+ */
+static void
+pch_gbe_mac_store_mac_addr_regs(struct pch_gbe_hw *hw,
+ struct pch_gbe_regs_mac_adr *mac_adr, u32 index)
+{
+ u32 adrmask;
+
+ adrmask = ioread32(&hw->reg->ADDR_MASK);
+ iowrite32((adrmask | (0x0001 << index)), &hw->reg->ADDR_MASK);
+ /* wait busy */
+ pch_gbe_wait_clr_bit(&hw->reg->ADDR_MASK, PCH_GBE_BUSY);
+ /* Set the MAC address to the MAC address xA/xB register */
+ iowrite32(mac_adr->high, &hw->reg->mac_adr[index].high);
+ iowrite32(mac_adr->low, &hw->reg->mac_adr[index].low);
+ iowrite32((adrmask & ~(0x0001 << index)), &hw->reg->ADDR_MASK);
+ /* wait busy */
+ pch_gbe_wait_clr_bit(&hw->reg->ADDR_MASK, PCH_GBE_BUSY);
+}
+
+#define MAC_ADDR_LIST_NUM 16
+/**
* pch_gbe_mac_reset_hw - Reset hardware
* @hw: Pointer to the HW structure
*/
static void pch_gbe_mac_reset_hw(struct pch_gbe_hw *hw)
{
+ struct pch_gbe_regs_mac_adr mac_addr_list[MAC_ADDR_LIST_NUM];
+ int i;
+
/* Read the MAC address. and store to the private data */
pch_gbe_mac_read_mac_addr(hw);
+ /* Read other MAC addresses */
+ for (i = 1; i < MAC_ADDR_LIST_NUM; i++)
+ pch_gbe_mac_save_mac_addr_regs(hw, &mac_addr_list[i], i);
iowrite32(PCH_GBE_ALL_RST, &hw->reg->RESET);
#ifdef PCH_GBE_MAC_IFOP_RGMII
iowrite32(PCH_GBE_MODE_GMII_ETHER, &hw->reg->MODE);
#endif
pch_gbe_wait_clr_bit(&hw->reg->RESET, PCH_GBE_ALL_RST);
- /* Setup the receive address */
+ /* Setup the receive addresses */
pch_gbe_mac_mar_set(hw, hw->mac.addr, 0);
+ for (i = 1; i < MAC_ADDR_LIST_NUM; i++)
+ pch_gbe_mac_store_mac_addr_regs(hw, &mac_addr_list[i], i);
return;
}
static void pch_gbe_mac_reset_rx(struct pch_gbe_hw *hw)
{
- /* Read the MAC address. and store to the private data */
+ struct pch_gbe_regs_mac_adr mac_addr_list[MAC_ADDR_LIST_NUM];
+ int i;
+
+ /* Read the MAC addresses. and store to the private data */
pch_gbe_mac_read_mac_addr(hw);
+ for (i = 1; i < MAC_ADDR_LIST_NUM; i++)
+ pch_gbe_mac_save_mac_addr_regs(hw, &mac_addr_list[i], i);
iowrite32(PCH_GBE_RX_RST, &hw->reg->RESET);
pch_gbe_wait_clr_bit_irq(&hw->reg->RESET, PCH_GBE_RX_RST);
- /* Setup the MAC address */
+ /* Setup the MAC addresses */
pch_gbe_mac_mar_set(hw, hw->mac.addr, 0);
+ for (i = 1; i < MAC_ADDR_LIST_NUM; i++)
+ pch_gbe_mac_store_mac_addr_regs(hw, &mac_addr_list[i], i);
return;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH v3.4-rc 2/9] pch_gbe: simplify transmit time stamping flag test
From: Richard Cochran @ 2012-04-20 20:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Takahiro Shimizu
In-Reply-To: <cover.1334949388.git.richardcochran@gmail.com>
From: Takahiro Shimizu <tshimizu818@gmail.com>
This patch makes logic surrounding the test of the
transmit time stamping flag more readable.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 7c2dabb..6a9a63b 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -199,11 +199,11 @@ static void pch_tx_timestamp(
u32 cnt, val;
shtx = skb_shinfo(skb);
- if (unlikely(shtx->tx_flags & SKBTX_HW_TSTAMP && adapter->hwts_tx_en))
- shtx->tx_flags |= SKBTX_IN_PROGRESS;
- else
+ if (likely(!(shtx->tx_flags & SKBTX_HW_TSTAMP && adapter->hwts_tx_en)))
return;
+ shtx->tx_flags |= SKBTX_IN_PROGRESS;
+
/* Get ieee1588's dev information */
pdev = adapter->ptp_pdev;
--
1.7.2.5
^ permalink raw reply related
* [PATCH v3.4-rc 1/9] pch_gbe: scale time stamps to nanoseconds
From: Richard Cochran @ 2012-04-20 20:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Takahiro Shimizu
In-Reply-To: <cover.1334949388.git.richardcochran@gmail.com>
From: Takahiro Shimizu <tshimizu818@gmail.com>
This patch fixes the helper functions that give the transmit and
receive time stamps to return nanoseconds, instead of arbitrary clock
ticks.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 4 ----
drivers/ptp/ptp_pch.c | 2 ++
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 8035e5f..7c2dabb 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -101,8 +101,6 @@ const char pch_driver_version[] = DRV_VERSION;
#ifdef CONFIG_PCH_PTP
/* Macros for ieee1588 */
-#define TICKS_NS_SHIFT 5
-
/* 0x40 Time Synchronization Channel Control Register Bits */
#define MASTER_MODE (1<<0)
#define SLAVE_MODE (0<<0)
@@ -183,7 +181,6 @@ static void pch_rx_timestamp(
goto out;
ns = pch_rx_snap_read(pdev);
- ns <<= TICKS_NS_SHIFT;
shhwtstamps = skb_hwtstamps(skb);
memset(shhwtstamps, 0, sizeof(*shhwtstamps));
@@ -226,7 +223,6 @@ static void pch_tx_timestamp(
}
ns = pch_tx_snap_read(pdev);
- ns <<= TICKS_NS_SHIFT;
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
shhwtstamps.hwtstamp = ns_to_ktime(ns);
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index 375eb04..847a3c3 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -261,6 +261,7 @@ u64 pch_rx_snap_read(struct pci_dev *pdev)
ns = ((u64) hi) << 32;
ns |= lo;
+ ns <<= TICKS_NS_SHIFT;
return ns;
}
@@ -277,6 +278,7 @@ u64 pch_tx_snap_read(struct pci_dev *pdev)
ns = ((u64) hi) << 32;
ns |= lo;
+ ns <<= TICKS_NS_SHIFT;
return ns;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH v3.4-rc 0/9] pch_gbe: ptp bug fixes
From: Richard Cochran @ 2012-04-20 20:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Takahiro Shimizu
The content in this patch series originally was posted to netdev by
Takahiro on March 23, 2012, as a loose group of five patches. These
patches addressed problems pointed out in review, both on and off
list.
I have taken his work and rebased, squashed, and split it into the
present form, and I also wrote commit messages that more fully explain
the changes. Also, I added the last two patches myself.
Richard Cochran (2):
pch_gbe: run the ptp bpf just once per packet
pch_gbe: remove suspicious comment
Takahiro Shimizu (7):
pch_gbe: scale time stamps to nanoseconds
pch_gbe: simplify transmit time stamping flag test
pch_gbe: reprogram multicast address register on reset
pch_gbe: export a method to set the receive match address
pch_gbe: improve coding style
pch_gbe: do not set the channel control register
pch_gbe: correct receive time stamp filtering
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 1 +
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 107 +++++++++++++++-----
drivers/ptp/Kconfig | 10 ++-
drivers/ptp/ptp_pch.c | 7 +-
4 files changed, 95 insertions(+), 30 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [net-next PATCH] net: dcb: add CEE notify calls
From: John Fastabend @ 2012-04-20 19:49 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong, amirv
This adds code to trigger CEE events when an APP change or setall
command is made from user space. This simplifies user space code
significantly by creating a single interface to listen on that
works with both firmware and userland agents.
And if we end up with multiple agents this keeps every thing in
sync userland agents, firmware agents, and kernel notifier consumers.
For an example agent that listens for these events see:
https://github.com/jrfastab/cgdcbxd
cgdcbxd is a daemon used to monitor DCB netlink events and manage
the net_prio control group sub-system.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/dcb/dcbnl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 8dfa1da..656c7c7 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -704,6 +704,7 @@ static int dcbnl_setapp(struct net_device *netdev, struct nlattr **tb,
ret = dcbnl_reply(err, RTM_SETDCB, DCB_CMD_SAPP, DCB_ATTR_APP,
pid, seq, flags);
+ dcbnl_cee_notify(netdev, RTM_SETDCB, DCB_CMD_SAPP, seq, 0);
out:
return ret;
}
@@ -936,6 +937,7 @@ static int dcbnl_setall(struct net_device *netdev, struct nlattr **tb,
ret = dcbnl_reply(netdev->dcbnl_ops->setall(netdev), RTM_SETDCB,
DCB_CMD_SET_ALL, DCB_ATTR_SET_ALL, pid, seq, flags);
+ dcbnl_cee_notify(netdev, RTM_SETDCB, DCB_CMD_SET_ALL, seq, 0);
return ret;
}
^ permalink raw reply related
* Re: e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
From: John Fastabend @ 2012-04-20 19:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: Ben Greear, netdev, e1000-devel list, Eric Dumazet
In-Reply-To: <4F91B554.9060902@candelatech.com>
On 4/20/2012 12:13 PM, Ben Greear wrote:
> On 04/20/2012 12:05 PM, Tom Herbert wrote:
>>> I am seeing something similar with the 'igb' driver, though this
>>> NIC also involves a side-driver that does bypass. When I enable/disable
>>> bypass, the links bounce (as expected), and igb reports the same
>>> timeout that I was seeing with e1000e.
>>>
>>
[...]
>>>>>
>>>>> 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c is the first bad commit
>>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>>> Author: Tom Herbert<therbert@google.com>
>>>>> Date: Mon Nov 28 16:33:16 2011 +0000
>>>>>
>>>>> e1000e: Support for byte queue limits
>>>>>
>>>>> Changes to e1000e to use byte queue limits.
>>>>>
>>>>> Signed-off-by: Tom Herbert<therbert@google.com>
>>>>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>>>>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>>>>
>>>>> :040000 040000 bf3e2ec64fd74253563e1ab39797b27a5f2df3fe
>>>>> 51914e221547b95a989b5c7e9b037c9370fd734e M drivers
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
Tom, did you see these two patches? Maybe this is resolved by
the second patch.
We needed these to fixup ixgbe and igb (i didn't test e1000e)
looks like we might want to push these at stable. I don't
believe they are in 3.3.
commit b37c0fbe3f6dfba1f8ad2aed47fb40578a254635
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue Feb 7 02:29:06 2012 +0000
net: Add memory barriers to prevent possible race in byte queue limits
This change adds a memory barrier to the byte queue limit code to address a
possible race as has been seen in the past with the
netif_stop_queue/netif_wake_queue logic.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b37c0fbe3f6dfba1f8ad2aed47fb40578a254635
commit 5c4903549c05bbb373479e0ce2992573c120654a
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue Feb 7 02:29:01 2012 +0000
net: Fix issue with netdev_tx_reset_queue not resetting queue from XOFF state
We are seeing dev_watchdog hangs on several drivers. I suspect this is due
to the __QUEUE_STATE_STACK_XOFF bit being set prior to a reset for link
change, and then not being cleared by netdev_tx_reset_queue. This change
corrects that.
In addition we were seeing dev_watchdog hangs on igb after running the
ethtool tests. We found this to be due to the fact that the ethtool test
runs the same logic as ndo_start_xmit, but we were never clearing the XOFF
flag since the loopback test in ethtool does not do byte queue accounting.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5c4903549c05bbb373479e0ce2992573c120654a
^ permalink raw reply
* [PATCH] net: usb: smsc95xx: fix mtu
From: Stephane Fillod @ 2012-04-20 19:39 UTC (permalink / raw)
To: netdev; +Cc: steve.glendinning
Make smsc95xx recalculate the hard_mtu after adjusting the
hard_header_len.
Without this, usbnet adjusts the MTU down to 1488 bytes, and the host is
unable to receive standard 1500-byte frames from the device.
Inspired by same fix on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9.
Tested on ARM/Beagle.
Signed-off-by: Stephane Fillod <fillods@users.sf.net>
---
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1016,6 +1016,7 @@
dev->net->ethtool_ops = &smsc95xx_ethtool_ops;
dev->net->flags |= IFF_MULTICAST;
dev->net->hard_header_len += SMSC95XX_TX_OVERHEAD_CSUM;
+ dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
return 0;
}
^ permalink raw reply
* Re: [PATCH 3/3] decrement static keys on real destroy time
From: Glauber Costa @ 2012-04-20 19:39 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4F911289.1050403-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 04/20/2012 04:38 AM, KAMEZAWA Hiroyuki wrote:
>> mem_cgroup_get(memcg);
>> > - sk->sk_cgrp = sk->sk_prot->proto_cgroup(memcg);
>> > + sk->sk_cgrp = cg_proto;
>> > }
>
>
> Is this correct ? cg_proto->active can be true before all jump_labels are
> patched, then we can loose accounting. That will cause underflow of
> res_countner.
>
> cg_proto->active should be set after jump_label modification.
> Then, things will work, I guess.
>
> Thanks,
> -Kame
>
Kame,
You are right.
The first update needs to be done after the jump label activation as
well. I got myself confused with the two flags =(
I will repost with this fixed once I get into agreement with Tejun and
Li about the lockless ->destroy()
^ permalink raw reply
* Re: e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
From: Ben Greear @ 2012-04-20 19:13 UTC (permalink / raw)
To: Tom Herbert; +Cc: e1000-devel list, netdev
In-Reply-To: <CA+mtBx9s70wawA4E3+LyOQhJXRr1y-0j_Pzno5bBSz8TS3SUOA@mail.gmail.com>
On 04/20/2012 12:05 PM, Tom Herbert wrote:
>> I am seeing something similar with the 'igb' driver, though this
>> NIC also involves a side-driver that does bypass. When I enable/disable
>> bypass, the links bounce (as expected), and igb reports the same
>> timeout that I was seeing with e1000e.
>>
>
> Hi Ben,
>
> Are the circumstances the same between igb and e1000e for the issue?
> That is in both cases are links being bounced or reset?
Yes, peer interface is being bounced in both cases. The igb NIC is
in a different machine, running Fedora 14 instead of F16 for the
e1000e.
I have the bypass NIC cabled to itself..2 ports sending/receiving
traffic, and 2 doing bypass (in hardware, or bridging in software).
When I twiddle to/from hardware/software bridging on the two
bypass ports, link is re-negotiated on the traffic-generating ports,
and the traffic generating ports have the tx queue timeout
issue.
If you have an igb or e1000e system that can generate traffic
while resetting the peer interface, I think you should easily
see the problem. If you DON'T see the problem, please let me
know and I will try to provide a more concise test case using
open-source traffic generators (we're using our own
traffic generator, but at least on the e1000e bisect, I was
using standard upstream kernels and pure user-space API to
generate traffic).
Thanks,
Ben
>
> Thanks,
> Tom
>
>> If I revert the igb BQL patch, then it works fine (kernel 3.3.2+).
>>
>> I did not do an exhaustive bisect, nor have tested non-bypass
>> igb hardware, but since reverting the patch fixes the problem....
>>
>> Maybe there is some fundamental issue with BQL when a NIC
>> resets itself (in this case, due to remote port doing
>> a reset) Maybe we are not properly accounting pkts cleared
>> from the xmit queue on reset or something of that nature?
>>
>> I'm happy to test patches of someone has suggestions...
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Tom
>>>
>>> On Thu, Apr 19, 2012 at 4:27 PM, Ben Greear<greearb@candelatech.com>
>>> wrote:
>>>>
>>>> Test case:
>>>>
>>>> Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic
>>>> (moderate speeds of traffic has issues as well, maybe not as easy to
>>>> reproduce)
>>>> reset peer interface
>>>> ----> tx queue timeout
>>>>
>>>>
>>>> Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down
>>>> Apr 19 16:12:48 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>>> adapter
>>>> Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down
>>>> Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>>> Full
>>>> Duplex, Flow Control: Rx/Tx
>>>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>>> becomes ready
>>>> Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps
>>>> Full
>>>> Duplex, Flow Control: Rx/Tx
>>>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link
>>>> becomes ready
>>>> Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing,
>>>> re-enabling all cpus for irq balancing
>>>> Apr 19 16:12:55 localhost kernel: ------------[ cut here ]------------
>>>> Apr 19 16:12:55 localhost kernel: WARNING: at
>>>> /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256
>>>> dev_watchdog+0xf4/0x154()
>>>> Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU
>>>> Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e):
>>>> transmit
>>>> queue 0 timed out
>>>> Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw
>>>> 8021q
>>>> garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen
>>>> iscsi_tcp
>>>> libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf
>>>> hwmon_vid
>>>> coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma
>>>> i2c_i801
>>>> i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy
>>>> radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded:
>>>> nf_nat]
>>>> Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted
>>>> 3.2.0-rc2+ #36
>>>> Apr 19 16:12:55 localhost kernel: Call Trace:
>>>> Apr 19 16:12:55 localhost kernel:<IRQ> [<ffffffff81042902>]
>>>> warn_slowpath_common+0x80/0x98
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff810429ae>]
>>>> warn_slowpath_fmt+0x41/0x43
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f8a3>]
>>>> dev_watchdog+0xf4/0x154
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8104d371>]
>>>> run_timer_softirq+0x16f/0x201
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f7af>] ?
>>>> netif_tx_unlock+0x57/0x57
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047e47>]
>>>> __do_softirq+0x86/0x12f
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8105d54e>] ?
>>>> hrtimer_interrupt+0x12b/0x1bd
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8144296c>]
>>>> call_softirq+0x1c/0x30
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8100bb75>]
>>>> do_softirq+0x41/0x7e
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047c26>] irq_exit+0x3f/0xbb
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81021df5>]
>>>> smp_apic_timer_interrupt+0x85/0x93
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff814411de>]
>>>> apic_timer_interrupt+0x6e/0x80
>>>> Apr 19 16:12:55 localhost kernel:<EOI> [<ffffffff81010b8c>] ?
>>>> mwait_idle+0x6e/0x8c
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81010b7f>] ?
>>>> mwait_idle+0x61/0x8c
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81009e72>] cpu_idle+0x67/0xbe
>>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81435477>]
>>>> start_secondary+0x194/0x199
>>>> Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]---
>>>> Apr 19 16:12:55 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>>> adapter
>>>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found
>>>> oopses:
>>>> 1
>>>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating
>>>> dump
>>>> directories
>>>> Apr 19 16:12:57 localhost abrtd: Directory
>>>> 'oops-2012-04-19-16:12:57-898-0'
>>>> creation detected
>>>> Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to
>>>> Abrt
>>>> Apr 19 16:12:57 localhost abrtd: Can't open file
>>>> '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or
>>>> directory
>>>> Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR:
>>>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>>>> Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of
>>>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>>>> Apr 19 16:12:57 localhost abrtd: Deleting dump directory
>>>> oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0),
>>>> sending dbus signal
>>>> Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>>> Full
>>>> Duplex, Flow Control: Rx/Tx
>>>> Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>>> becomes ready
>>>> Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing,
>>>> re-enabling all cpus for irq balancing
>>>> Apr 19 16:13:04 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>>> adapter
>>>> Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194
>>>> Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>>> Full
>>>> Duplex, Flow Control: Rx/Tx
>>>> Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>>> becomes ready
>>>> ....
>>>>
>>>> lspci:
>>>>
>>>> 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>>>> Controller (rev 06)
>>>> Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>>> ParErr+
>>>> Stepping- SERR+ FastB2B- DisINTx+
>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-
>>>> <TAbort-<MAbort->SERR-<PERR- INTx-
>>>> Latency: 0, Cache Line Size: 32 bytes
>>>> Interrupt: pin A routed to IRQ 74
>>>> Region 0: Memory at d8300000 (32-bit, non-prefetchable)
>>>> [size=128K]
>>>> Region 2: I/O ports at 3000 [size=32]
>>>> [virtual] Expansion ROM at d8d00000 [disabled] [size=128K]
>>>> Capabilities: [c8] Power Management version 2
>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>>>> PME(D0+,D1-,D2-,D3hot+,D3cold-)
>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>> Address: 00000000feeff00c Data: 41a3
>>>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>>>> <512ns, L1<64us
>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>>>> Unsupported+
>>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>> MaxPayload 128 bytes, MaxReadReq 4096 bytes
>>>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
>>>> TransPend-
>>>> LnkCap: Port #1, Speed 2.5GT/s, Width x2, ASPM L0s L1,
>>>> Latency L0<4us, L1<64us
>>>> ClockPM- Surprise- LLActRep- BwNot-
>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>>>> CommClk-
>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>> LnkSta: Speed 2.5GT/s, Width x2, TrErr- Train- SlotClk+
>>>> DLActive- BWMgmt- ABWMgmt-
>>>> Capabilities: [100 v1] Advanced Error Reporting
>>>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
>>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr-
>>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr-
>>>> AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap-
>>>> ChkEn-
>>>> Capabilities: [140 v1] Device Serial Number
>>>> 00-e0-ed-ff-ff-0c-11-6e
>>>> Kernel driver in use: e1000e
>>>> Kernel modules: e1000e
>>>>
>>>>
>>>> 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c is the first bad commit
>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>> Author: Tom Herbert<therbert@google.com>
>>>> Date: Mon Nov 28 16:33:16 2011 +0000
>>>>
>>>> e1000e: Support for byte queue limits
>>>>
>>>> Changes to e1000e to use byte queue limits.
>>>>
>>>> Signed-off-by: Tom Herbert<therbert@google.com>
>>>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>>>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>>>
>>>> :040000 040000 bf3e2ec64fd74253563e1ab39797b27a5f2df3fe
>>>> 51914e221547b95a989b5c7e9b037c9370fd734e M drivers
>>>>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> --
>>>> Ben Greear<greearb@candelatech.com>
>>>> Candela Technologies Inc http://www.candelatech.com
>>>>
>>
>>
>> --
>> Ben Greear<greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Security Alert
From: Web Admin @ 2012-04-20 19:53 UTC (permalink / raw)
Security Alert,
En DGTJTO virus har blitt oppdaget i din Webmail-kontoen. Din
Webmail-kontoen må beskyttes til våre nye Sikret VQZZF! MacAfee
anti-virus 2011/1012 versjonen til å forebygge skader på vår database og
viktige filer og meldinger. Bare fyll de nødvendige opplysningene
nedenfor og send tilbake til oss for beskyttelse av filene og vår
database for å unngå spredning av viruset.
E-postadresse:
Brukernavn:
passord:
Gjenta-Passord:
Anti Virus Kode: QQ1 76
Webmaster Webmail. Merk at passordet ditt blir kryptert og e-posten din
kvoten vil også bli oppgradert for din sikkerhet.
Takk for samarbeidet,
Web Admin
^ permalink raw reply
* Re: e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
From: Tom Herbert @ 2012-04-20 19:05 UTC (permalink / raw)
To: Ben Greear; +Cc: e1000-devel list, netdev
In-Reply-To: <4F91B250.8090509@candelatech.com>
> I am seeing something similar with the 'igb' driver, though this
> NIC also involves a side-driver that does bypass. When I enable/disable
> bypass, the links bounce (as expected), and igb reports the same
> timeout that I was seeing with e1000e.
>
Hi Ben,
Are the circumstances the same between igb and e1000e for the issue?
That is in both cases are links being bounced or reset?
Thanks,
Tom
> If I revert the igb BQL patch, then it works fine (kernel 3.3.2+).
>
> I did not do an exhaustive bisect, nor have tested non-bypass
> igb hardware, but since reverting the patch fixes the problem....
>
> Maybe there is some fundamental issue with BQL when a NIC
> resets itself (in this case, due to remote port doing
> a reset) Maybe we are not properly accounting pkts cleared
> from the xmit queue on reset or something of that nature?
>
> I'm happy to test patches of someone has suggestions...
>
> Thanks,
> Ben
>
>
>>
>> Tom
>>
>> On Thu, Apr 19, 2012 at 4:27 PM, Ben Greear<greearb@candelatech.com>
>> wrote:
>>>
>>> Test case:
>>>
>>> Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic
>>> (moderate speeds of traffic has issues as well, maybe not as easy to
>>> reproduce)
>>> reset peer interface
>>> ----> tx queue timeout
>>>
>>>
>>> Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down
>>> Apr 19 16:12:48 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>> adapter
>>> Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down
>>> Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>> Full
>>> Duplex, Flow Control: Rx/Tx
>>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>> becomes ready
>>> Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps
>>> Full
>>> Duplex, Flow Control: Rx/Tx
>>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link
>>> becomes ready
>>> Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing,
>>> re-enabling all cpus for irq balancing
>>> Apr 19 16:12:55 localhost kernel: ------------[ cut here ]------------
>>> Apr 19 16:12:55 localhost kernel: WARNING: at
>>> /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256
>>> dev_watchdog+0xf4/0x154()
>>> Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU
>>> Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e):
>>> transmit
>>> queue 0 timed out
>>> Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw
>>> 8021q
>>> garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen
>>> iscsi_tcp
>>> libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf
>>> hwmon_vid
>>> coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma
>>> i2c_i801
>>> i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy
>>> radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded:
>>> nf_nat]
>>> Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted
>>> 3.2.0-rc2+ #36
>>> Apr 19 16:12:55 localhost kernel: Call Trace:
>>> Apr 19 16:12:55 localhost kernel:<IRQ> [<ffffffff81042902>]
>>> warn_slowpath_common+0x80/0x98
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff810429ae>]
>>> warn_slowpath_fmt+0x41/0x43
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f8a3>]
>>> dev_watchdog+0xf4/0x154
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8104d371>]
>>> run_timer_softirq+0x16f/0x201
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f7af>] ?
>>> netif_tx_unlock+0x57/0x57
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047e47>]
>>> __do_softirq+0x86/0x12f
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8105d54e>] ?
>>> hrtimer_interrupt+0x12b/0x1bd
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8144296c>]
>>> call_softirq+0x1c/0x30
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff8100bb75>]
>>> do_softirq+0x41/0x7e
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047c26>] irq_exit+0x3f/0xbb
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81021df5>]
>>> smp_apic_timer_interrupt+0x85/0x93
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff814411de>]
>>> apic_timer_interrupt+0x6e/0x80
>>> Apr 19 16:12:55 localhost kernel:<EOI> [<ffffffff81010b8c>] ?
>>> mwait_idle+0x6e/0x8c
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81010b7f>] ?
>>> mwait_idle+0x61/0x8c
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81009e72>] cpu_idle+0x67/0xbe
>>> Apr 19 16:12:55 localhost kernel: [<ffffffff81435477>]
>>> start_secondary+0x194/0x199
>>> Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]---
>>> Apr 19 16:12:55 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>> adapter
>>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found
>>> oopses:
>>> 1
>>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating
>>> dump
>>> directories
>>> Apr 19 16:12:57 localhost abrtd: Directory
>>> 'oops-2012-04-19-16:12:57-898-0'
>>> creation detected
>>> Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to
>>> Abrt
>>> Apr 19 16:12:57 localhost abrtd: Can't open file
>>> '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or
>>> directory
>>> Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR:
>>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>>> Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of
>>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>>> Apr 19 16:12:57 localhost abrtd: Deleting dump directory
>>> oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0),
>>> sending dbus signal
>>> Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>> Full
>>> Duplex, Flow Control: Rx/Tx
>>> Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>> becomes ready
>>> Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing,
>>> re-enabling all cpus for irq balancing
>>> Apr 19 16:13:04 localhost kernel: e1000e 0000:08:00.0: eth2: Reset
>>> adapter
>>> Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194
>>> Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps
>>> Full
>>> Duplex, Flow Control: Rx/Tx
>>> Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>>> becomes ready
>>> ....
>>>
>>> lspci:
>>>
>>> 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>>> Controller (rev 06)
>>> Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr+
>>> Stepping- SERR+ FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-
>>> <TAbort-<MAbort->SERR-<PERR- INTx-
>>> Latency: 0, Cache Line Size: 32 bytes
>>> Interrupt: pin A routed to IRQ 74
>>> Region 0: Memory at d8300000 (32-bit, non-prefetchable)
>>> [size=128K]
>>> Region 2: I/O ports at 3000 [size=32]
>>> [virtual] Expansion ROM at d8d00000 [disabled] [size=128K]
>>> Capabilities: [c8] Power Management version 2
>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>>> PME(D0+,D1-,D2-,D3hot+,D3cold-)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>> Address: 00000000feeff00c Data: 41a3
>>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>>> <512ns, L1<64us
>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>>> Unsupported+
>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>> MaxPayload 128 bytes, MaxReadReq 4096 bytes
>>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
>>> TransPend-
>>> LnkCap: Port #1, Speed 2.5GT/s, Width x2, ASPM L0s L1,
>>> Latency L0<4us, L1<64us
>>> ClockPM- Surprise- LLActRep- BwNot-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>>> CommClk-
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x2, TrErr- Train- SlotClk+
>>> DLActive- BWMgmt- ABWMgmt-
>>> Capabilities: [100 v1] Advanced Error Reporting
>>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr-
>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr-
>>> AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap-
>>> ChkEn-
>>> Capabilities: [140 v1] Device Serial Number
>>> 00-e0-ed-ff-ff-0c-11-6e
>>> Kernel driver in use: e1000e
>>> Kernel modules: e1000e
>>>
>>>
>>> 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c is the first bad commit
>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>> Author: Tom Herbert<therbert@google.com>
>>> Date: Mon Nov 28 16:33:16 2011 +0000
>>>
>>> e1000e: Support for byte queue limits
>>>
>>> Changes to e1000e to use byte queue limits.
>>>
>>> Signed-off-by: Tom Herbert<therbert@google.com>
>>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>>
>>> :040000 040000 bf3e2ec64fd74253563e1ab39797b27a5f2df3fe
>>> 51914e221547b95a989b5c7e9b037c9370fd734e M drivers
>>>
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear<greearb@candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>>
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
From: Ben Greear @ 2012-04-20 19:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, e1000-devel list, Eric Dumazet
In-Reply-To: <CA+mtBx9ZjfC692g1EwNsw=37ijWcGBOUaENCogVS=Bi9rfz0sg@mail.gmail.com>
On 04/19/2012 07:39 PM, Tom Herbert wrote:
> Thanks, will try to reproduce.
I am seeing something similar with the 'igb' driver, though this
NIC also involves a side-driver that does bypass. When I enable/disable
bypass, the links bounce (as expected), and igb reports the same
timeout that I was seeing with e1000e.
If I revert the igb BQL patch, then it works fine (kernel 3.3.2+).
I did not do an exhaustive bisect, nor have tested non-bypass
igb hardware, but since reverting the patch fixes the problem....
Maybe there is some fundamental issue with BQL when a NIC
resets itself (in this case, due to remote port doing
a reset) Maybe we are not properly accounting pkts cleared
from the xmit queue on reset or something of that nature?
I'm happy to test patches of someone has suggestions...
Thanks,
Ben
>
> Tom
>
> On Thu, Apr 19, 2012 at 4:27 PM, Ben Greear<greearb@candelatech.com> wrote:
>> Test case:
>>
>> Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic
>> (moderate speeds of traffic has issues as well, maybe not as easy to
>> reproduce)
>> reset peer interface
>> ----> tx queue timeout
>>
>>
>> Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down
>> Apr 19 16:12:48 localhost kernel: e1000e 0000:08:00.0: eth2: Reset adapter
>> Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down
>> Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full
>> Duplex, Flow Control: Rx/Tx
>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>> becomes ready
>> Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps Full
>> Duplex, Flow Control: Rx/Tx
>> Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link
>> becomes ready
>> Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing,
>> re-enabling all cpus for irq balancing
>> Apr 19 16:12:55 localhost kernel: ------------[ cut here ]------------
>> Apr 19 16:12:55 localhost kernel: WARNING: at
>> /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256
>> dev_watchdog+0xf4/0x154()
>> Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU
>> Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit
>> queue 0 timed out
>> Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw 8021q
>> garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen iscsi_tcp
>> libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf hwmon_vid
>> coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma
>> i2c_i801
>> i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy
>> radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded:
>> nf_nat]
>> Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted
>> 3.2.0-rc2+ #36
>> Apr 19 16:12:55 localhost kernel: Call Trace:
>> Apr 19 16:12:55 localhost kernel:<IRQ> [<ffffffff81042902>]
>> warn_slowpath_common+0x80/0x98
>> Apr 19 16:12:55 localhost kernel: [<ffffffff810429ae>]
>> warn_slowpath_fmt+0x41/0x43
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f8a3>]
>> dev_watchdog+0xf4/0x154
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8104d371>]
>> run_timer_softirq+0x16f/0x201
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8139f7af>] ?
>> netif_tx_unlock+0x57/0x57
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047e47>]
>> __do_softirq+0x86/0x12f
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8105d54e>] ?
>> hrtimer_interrupt+0x12b/0x1bd
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8144296c>]
>> call_softirq+0x1c/0x30
>> Apr 19 16:12:55 localhost kernel: [<ffffffff8100bb75>] do_softirq+0x41/0x7e
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81047c26>] irq_exit+0x3f/0xbb
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81021df5>]
>> smp_apic_timer_interrupt+0x85/0x93
>> Apr 19 16:12:55 localhost kernel: [<ffffffff814411de>]
>> apic_timer_interrupt+0x6e/0x80
>> Apr 19 16:12:55 localhost kernel:<EOI> [<ffffffff81010b8c>] ?
>> mwait_idle+0x6e/0x8c
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81010b7f>] ?
>> mwait_idle+0x61/0x8c
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81009e72>] cpu_idle+0x67/0xbe
>> Apr 19 16:12:55 localhost kernel: [<ffffffff81435477>]
>> start_secondary+0x194/0x199
>> Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]---
>> Apr 19 16:12:55 localhost kernel: e1000e 0000:08:00.0: eth2: Reset adapter
>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found oopses:
>> 1
>> Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating dump
>> directories
>> Apr 19 16:12:57 localhost abrtd: Directory 'oops-2012-04-19-16:12:57-898-0'
>> creation detected
>> Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt
>> Apr 19 16:12:57 localhost abrtd: Can't open file
>> '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or
>> directory
>> Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR:
>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>> Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of
>> /var/spool/abrt/oops-2012-04-19-15:02:13-862-0
>> Apr 19 16:12:57 localhost abrtd: Deleting dump directory
>> oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0),
>> sending dbus signal
>> Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full
>> Duplex, Flow Control: Rx/Tx
>> Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>> becomes ready
>> Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing,
>> re-enabling all cpus for irq balancing
>> Apr 19 16:13:04 localhost kernel: e1000e 0000:08:00.0: eth2: Reset adapter
>> Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194
>> Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full
>> Duplex, Flow Control: Rx/Tx
>> Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link
>> becomes ready
>> ....
>>
>> lspci:
>>
>> 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>> Controller (rev 06)
>> Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>> Stepping- SERR+ FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-
>> <TAbort-<MAbort->SERR-<PERR- INTx-
>> Latency: 0, Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 74
>> Region 0: Memory at d8300000 (32-bit, non-prefetchable) [size=128K]
>> Region 2: I/O ports at 3000 [size=32]
>> [virtual] Expansion ROM at d8d00000 [disabled] [size=128K]
>> Capabilities: [c8] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0+,D1-,D2-,D3hot+,D3cold-)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000feeff00c Data: 41a3
>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>> <512ns, L1<64us
>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>> Unsupported+
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>> MaxPayload 128 bytes, MaxReadReq 4096 bytes
>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
>> TransPend-
>> LnkCap: Port #1, Speed 2.5GT/s, Width x2, ASPM L0s L1,
>> Latency L0<4us, L1<64us
>> ClockPM- Surprise- LLActRep- BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>> CommClk-
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x2, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>> Capabilities: [100 v1] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr-
>> AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap-
>> ChkEn-
>> Capabilities: [140 v1] Device Serial Number 00-e0-ed-ff-ff-0c-11-6e
>> Kernel driver in use: e1000e
>> Kernel modules: e1000e
>>
>>
>> 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c is the first bad commit
>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>> Author: Tom Herbert<therbert@google.com>
>> Date: Mon Nov 28 16:33:16 2011 +0000
>>
>> e1000e: Support for byte queue limits
>>
>> Changes to e1000e to use byte queue limits.
>>
>> Signed-off-by: Tom Herbert<therbert@google.com>
>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>
>> :040000 040000 bf3e2ec64fd74253563e1ab39797b27a5f2df3fe
>> 51914e221547b95a989b5c7e9b037c9370fd734e M drivers
>>
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear<greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH][RFC] bonding: delete migrated IP addresses from the rlb hash table
From: Jiri Bohac @ 2012-04-20 18:56 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: jbohac, Andy Gospodarek, netdev
In-Reply-To: <20120307160216.GB11474@midget.suse.cz>
I finally got back to this, sorry for such a long delay ...
Start of this thread is here:
http://thread.gmane.org/gmane.linux.network/222233
On Wed, Mar 07, 2012 at 05:02:16PM +0100, Jiri Bohac wrote:
> On Wed, Feb 29, 2012 at 06:12:20PM -0800, Jay Vosburgh wrote:
> > I've done some initial testing with this, and so far I'm seeing
> > one problem: every time the local host (with bonding) sends a broadcast
> > ARP, that ends up flushing the entire RLB table. Well, all entries that
> > match the IP on the bond that's sending an ARP request, which is just
> > one address in my testing.
> >
> > Anyway, this happens because the switch forwards the broadcast
> > ARP back around to one of the other bond slaves, and then that
> > "incoming" ARP bears an ip_src of our already-in-use IP address, and
> > that matches everything in the table.
>
> Good catch! I did not notice this.
>
> > Perhaps a check that the ip_src being flushed is not actually in
> > use locally is warranted?
>
> This would not work for the setups where the bonding master is
> bridget to some other network. I think it would be better to also
> store the source (server) MAC address in struct client_info and
> only flush the hash table entries if the MAC address from the
> incoming APR packet and the source MAC address stored in the hash
> table differ.
>
> Updated patch follows (compile-tested only) I also
> fixed the coding style problems you pointed out. As for the
> forward/reverse naming, it's your call. Should I change it to
> src/dst?
I now thoroughly tested this updated patch in a real setup. It
works as intended - it does not purge the entries when receiving the
looped-back ARP requests. It correctly purges the offending
entries when an ARP packet arrives with a its SRC IP address
matching a SRC IP address in the table and having differrent MAC
address -- exactly the case that would cause the ARP cache
poisoning if not purged from the table.
Jay, would you please consider applying this? Or do you want me
to somehow rename the RLB table forward/reverse elements?
Re-sending the fixed patch with the original description:
------
Bonding in balance-alb mode records information from ARP packets
passing through the bond in a hash table (rx_hashtbl).
At certain situations (e.g. link change of a slave),
rlb_update_rx_clients() will send out ARP packets to update ARP
caches of other hosts on the network to achieve RX load balancing.
The problem is that once an IP address is recorded in the hash
table, it stays there indefinitely. If this IP address is
migrated to a different host in the network, bonding still sends
out ARP packets that poison other systems' ARP caches with
invalid information.
This patch solves this by looking at all incoming ARP packets,
and checking if the source IP address is one of the source
addresses stored in the rx_hashtbl. If it is, the corresponding
hash table entries are removed. Thus, when an IP address is
migrated, the first ARP broadcast by its new owner will purge the
offending entries of rx_hashtbl.
The hash table is hashed by ip_dst. To be able to do the above
check efficiently (not walking the whole hash table), we need a
reverse mapping (by ip_src).
I added three new members in struct rlb_client_info:
rx_hashtbl[x].reverse_first will point to the start of a list of
entries for which hash(ip_src) == x.
The list is linked with reverse_next and reverse_prev.
When an incoming ARP packet arrives at rlb_arp_recv()
rlb_purge_src_ip() can quickly walk only the entries on the
corresponding lists, i.e. the entries that are likely to contain
the offending IP address.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index f820b26..a938ab6 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -84,6 +84,9 @@ static inline struct arp_pkt *arp_pkt(const struct sk_buff *skb)
/* Forward declaration */
static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[]);
+static void rlb_purge_src_ip(struct bonding *bond, struct arp_pkt *arp);
+static void rlb_delete_table_entry_reverse(struct bonding *bond, u32 index);
+static void rlb_set_reverse_entry(struct bonding *bond, u32 ip_src_hash, u32 ip_dst_hash);
static inline u8 _simple_hash(const u8 *hash_start, int hash_size)
{
@@ -366,6 +369,17 @@ static void rlb_arp_recv(struct sk_buff *skb, struct bonding *bond,
return;
}
+ /* We received an ARP from arp->ip_src.
+ * We might have used this IP address previously (on the bonding host
+ * itself or on a system that is bridged together with the bond).
+ * However, if arp->mac_src is different than what is stored in
+ * rx_hashtbl, some other host is now using the IP and we must prevent
+ * sending out client updates with this IP address as the source.
+ * Clean up all hash table entries that have this address as ip_src but
+ * have a dirrerent mac_src.
+ */
+ rlb_purge_src_ip(bond, arp);
+
if (arp->op_code == htons(ARPOP_REPLY)) {
/* update rx hash table for this ARP */
rlb_update_entry_from_arp(bond, arp);
@@ -635,6 +649,7 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
/* update mac address from arp */
memcpy(client_info->mac_dst, arp->mac_dst, ETH_ALEN);
}
+ memcpy(client_info->mac_src, arp->mac_src, ETH_ALEN);
assigned_slave = client_info->slave;
if (assigned_slave) {
@@ -657,6 +672,13 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
assigned_slave = rlb_next_rx_slave(bond);
if (assigned_slave) {
+ if (!(client_info->assigned && client_info->ip_src == arp->ip_src)) {
+ /* ip_src is going to be updated, fix the reverse hashing */
+ u32 hash_src = _simple_hash((u8 *)&arp->ip_src, sizeof(arp->ip_src));
+ rlb_delete_table_entry_reverse(bond, hash_index);
+ rlb_set_reverse_entry(bond, hash_src, hash_index);
+ }
+
client_info->ip_src = arp->ip_src;
client_info->ip_dst = arp->ip_dst;
/* arp->mac_dst is broadcast for arp reqeusts.
@@ -664,6 +686,7 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
* upon receiving an arp reply.
*/
memcpy(client_info->mac_dst, arp->mac_dst, ETH_ALEN);
+ memcpy(client_info->mac_src, arp->mac_src, ETH_ALEN);
client_info->slave = assigned_slave;
if (compare_ether_addr_64bits(client_info->mac_dst, mac_bcast)) {
@@ -769,11 +792,109 @@ static void rlb_rebalance(struct bonding *bond)
}
/* Caller must hold rx_hashtbl lock */
-static void rlb_init_table_entry(struct rlb_client_info *entry)
+static void rlb_init_table_entry_forward(struct rlb_client_info *entry)
{
- memset(entry, 0, sizeof(struct rlb_client_info));
entry->next = RLB_NULL_INDEX;
entry->prev = RLB_NULL_INDEX;
+ entry->assigned = 0;
+ entry->slave = NULL;
+ entry->tag = 0;
+}
+static void rlb_init_table_entry_reverse(struct rlb_client_info *entry)
+{
+ entry->reverse_first = RLB_NULL_INDEX;
+ entry->reverse_prev = RLB_NULL_INDEX;
+ entry->reverse_next = RLB_NULL_INDEX;
+}
+
+static void rlb_init_table_entry(struct rlb_client_info *entry)
+{
+ memset(entry, 0, sizeof(struct rlb_client_info));
+ rlb_init_table_entry_forward(entry);
+ rlb_init_table_entry_reverse(entry);
+}
+
+static void rlb_delete_table_entry_forward(struct bonding *bond, u32 index)
+{
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ u32 next_index = bond_info->rx_hashtbl[index].next;
+ u32 prev_index = bond_info->rx_hashtbl[index].prev;
+
+ if (index == bond_info->rx_hashtbl_head)
+ bond_info->rx_hashtbl_head = next_index;
+ if (prev_index != RLB_NULL_INDEX)
+ bond_info->rx_hashtbl[prev_index].next = next_index;
+ if (next_index != RLB_NULL_INDEX)
+ bond_info->rx_hashtbl[next_index].prev = prev_index;
+}
+
+static void rlb_delete_table_entry_reverse(struct bonding *bond, u32 index)
+{
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ u32 next_index = bond_info->rx_hashtbl[index].reverse_next;
+ u32 prev_index = bond_info->rx_hashtbl[index].reverse_prev;
+
+ bond_info->rx_hashtbl[index].reverse_next = RLB_NULL_INDEX;
+ bond_info->rx_hashtbl[index].reverse_prev = RLB_NULL_INDEX;
+
+ if (next_index != RLB_NULL_INDEX)
+ bond_info->rx_hashtbl[next_index].reverse_prev = prev_index;
+
+ if (prev_index == RLB_NULL_INDEX)
+ return;
+
+ /* is prev_index pointing to the head of this chain? */
+ if (bond_info->rx_hashtbl[prev_index].reverse_first == index)
+ bond_info->rx_hashtbl[prev_index].reverse_first = next_index;
+ else
+ bond_info->rx_hashtbl[prev_index].reverse_next = next_index;
+
+}
+
+static void rlb_delete_table_entry(struct bonding *bond, u32 index)
+{
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ struct rlb_client_info *entry = &(bond_info->rx_hashtbl[index]);
+
+ rlb_delete_table_entry_forward(bond, index);
+ rlb_init_table_entry_forward(entry);
+
+ rlb_delete_table_entry_reverse(bond, index);
+}
+
+static void rlb_set_reverse_entry(struct bonding *bond, u32 ip_src_hash, u32 ip_dst_hash)
+{
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ u32 next;
+
+ bond_info->rx_hashtbl[ip_dst_hash].reverse_prev = ip_src_hash;
+ next = bond_info->rx_hashtbl[ip_src_hash].reverse_first;
+ bond_info->rx_hashtbl[ip_dst_hash].reverse_next = next;
+ if (next != RLB_NULL_INDEX)
+ bond_info->rx_hashtbl[next].reverse_prev = ip_dst_hash;
+ bond_info->rx_hashtbl[ip_src_hash].reverse_first = ip_dst_hash;
+}
+
+/* deletes all rx_hashtbl entries with arp->ip_src if their mac_src does
+ * not match arp->mac_src */
+static void rlb_purge_src_ip(struct bonding *bond, struct arp_pkt *arp)
+{
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ u32 ip_src_hash = _simple_hash((u8*)&(arp->ip_src), sizeof(arp->ip_src));
+ u32 index;
+
+ _lock_rx_hashtbl_bh(bond);
+
+ index = bond_info->rx_hashtbl[ip_src_hash].reverse_first;
+ while (index != RLB_NULL_INDEX) {
+ struct rlb_client_info *entry = &(bond_info->rx_hashtbl[index]);
+ u32 next_index = entry->reverse_next;
+ if (entry->ip_src == arp->ip_src &&
+ compare_ether_addr_64bits(arp->mac_src, entry->mac_src))
+ rlb_delete_table_entry(bond, index);
+ index = next_index;
+ }
+ _unlock_rx_hashtbl_bh(bond);
}
static int rlb_initialize(struct bonding *bond)
@@ -831,21 +952,9 @@ static void rlb_clear_vlan(struct bonding *bond, unsigned short vlan_id)
while (curr_index != RLB_NULL_INDEX) {
struct rlb_client_info *curr = &(bond_info->rx_hashtbl[curr_index]);
u32 next_index = bond_info->rx_hashtbl[curr_index].next;
- u32 prev_index = bond_info->rx_hashtbl[curr_index].prev;
-
- if (curr->tag && (curr->vlan_id == vlan_id)) {
- if (curr_index == bond_info->rx_hashtbl_head) {
- bond_info->rx_hashtbl_head = next_index;
- }
- if (prev_index != RLB_NULL_INDEX) {
- bond_info->rx_hashtbl[prev_index].next = next_index;
- }
- if (next_index != RLB_NULL_INDEX) {
- bond_info->rx_hashtbl[next_index].prev = prev_index;
- }
- rlb_init_table_entry(curr);
- }
+ if (curr->tag && (curr->vlan_id == vlan_id))
+ rlb_delete_table_entry(bond, curr_index);
curr_index = next_index;
}
diff --git a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h
index 90f140a..8286df52 100644
--- a/drivers/net/bonding/bond_alb.h
+++ b/drivers/net/bonding/bond_alb.h
@@ -100,6 +100,7 @@ struct tlb_client_info {
struct rlb_client_info {
__be32 ip_src; /* the server IP address */
__be32 ip_dst; /* the client IP address */
+ u8 mac_src[ETH_ALEN]; /* the server MAC address */
u8 mac_dst[ETH_ALEN]; /* the client MAC address */
u32 next; /* The next Hash table entry index */
u32 prev; /* The previous Hash table entry index */
@@ -108,6 +109,9 @@ struct rlb_client_info {
struct slave *slave; /* the slave assigned to this client */
u8 tag; /* flag - need to tag skb */
unsigned short vlan_id; /* VLAN tag associated with IP address */
+ u32 reverse_next; /* next entry with same hash(ip_src) */
+ u32 reverse_prev; /* prev entry with same hash(ip_src) */
+ u32 reverse_first; /* first entry with hash(ip_src) == this entry's index */
};
struct tlb_slave_info {
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* [PATCH net-next] net: change big iov allocations
From: Eric Dumazet @ 2012-04-20 18:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mike Waychison
From: Eric Dumazet <edumazet@google.com>
iov of more than 8 entries are allocated in sendmsg()/recvmsg() through
sock_kmalloc()
As these allocations are temporary only and small enough, it makes sense
to use plain kmalloc() and avoid sk_omem_alloc atomic overhead.
Slightly changed fast path to be even faster.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Mike Waychison <mikew@google.com>
---
net/socket.c | 37 ++++++++++++++++---------------------
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index d6c1af9..4240d6e 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1908,7 +1908,7 @@ static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
__attribute__ ((aligned(sizeof(__kernel_size_t))));
/* 20 is size of ipv6_pktinfo */
unsigned char *ctl_buf = ctl;
- int err, ctl_len, iov_size, total_len;
+ int err, ctl_len, total_len;
err = -EFAULT;
if (MSG_CMSG_COMPAT & flags) {
@@ -1917,16 +1917,13 @@ static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
} else if (copy_from_user(msg_sys, msg, sizeof(struct msghdr)))
return -EFAULT;
- /* do not move before msg_sys is valid */
- err = -EMSGSIZE;
- if (msg_sys->msg_iovlen > UIO_MAXIOV)
- goto out;
-
- /* Check whether to allocate the iovec area */
- err = -ENOMEM;
- iov_size = msg_sys->msg_iovlen * sizeof(struct iovec);
if (msg_sys->msg_iovlen > UIO_FASTIOV) {
- iov = sock_kmalloc(sock->sk, iov_size, GFP_KERNEL);
+ err = -EMSGSIZE;
+ if (msg_sys->msg_iovlen > UIO_MAXIOV)
+ goto out;
+ err = -ENOMEM;
+ iov = kmalloc(msg_sys->msg_iovlen * sizeof(struct iovec),
+ GFP_KERNEL);
if (!iov)
goto out;
}
@@ -2005,7 +2002,7 @@ out_freectl:
sock_kfree_s(sock->sk, ctl_buf, ctl_len);
out_freeiov:
if (iov != iovstack)
- sock_kfree_s(sock->sk, iov, iov_size);
+ kfree(iov);
out:
return err;
}
@@ -2103,7 +2100,7 @@ static int __sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
struct iovec iovstack[UIO_FASTIOV];
struct iovec *iov = iovstack;
unsigned long cmsg_ptr;
- int err, iov_size, total_len, len;
+ int err, total_len, len;
/* kernel mode address */
struct sockaddr_storage addr;
@@ -2118,15 +2115,13 @@ static int __sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
} else if (copy_from_user(msg_sys, msg, sizeof(struct msghdr)))
return -EFAULT;
- err = -EMSGSIZE;
- if (msg_sys->msg_iovlen > UIO_MAXIOV)
- goto out;
-
- /* Check whether to allocate the iovec area */
- err = -ENOMEM;
- iov_size = msg_sys->msg_iovlen * sizeof(struct iovec);
if (msg_sys->msg_iovlen > UIO_FASTIOV) {
- iov = sock_kmalloc(sock->sk, iov_size, GFP_KERNEL);
+ err = -EMSGSIZE;
+ if (msg_sys->msg_iovlen > UIO_MAXIOV)
+ goto out;
+ err = -ENOMEM;
+ iov = kmalloc(msg_sys->msg_iovlen * sizeof(struct iovec),
+ GFP_KERNEL);
if (!iov)
goto out;
}
@@ -2180,7 +2175,7 @@ static int __sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
out_freeiov:
if (iov != iovstack)
- sock_kfree_s(sock->sk, iov, iov_size);
+ kfree(iov);
out:
return err;
}
^ permalink raw reply related
* Re: [PATCH 1/2] workqueue: Catch more locking problems with flush_work()
From: Tejun Heo @ 2012-04-20 17:35 UTC (permalink / raw)
To: Stephen Boyd; +Cc: linux-kernel, netdev, Ben Dooks
In-Reply-To: <4F905521.9020901@codeaurora.org>
Hello,
On Thu, Apr 19, 2012 at 11:10:41AM -0700, Stephen Boyd wrote:
> On 04/19/12 08:28, Tejun Heo wrote:
> > On Wed, Apr 18, 2012 at 08:25:57PM -0700, Stephen Boyd wrote:
> >> @@ -2513,8 +2513,11 @@ bool flush_work(struct work_struct *work)
> >> wait_for_completion(&barr.done);
> >> destroy_work_on_stack(&barr.work);
> >> return true;
> >> - } else
> >> + } else {
> >> + lock_map_acquire(&work->lockdep_map);
> >> + lock_map_release(&work->lockdep_map);
> >> return false;
> > We don't have this annotation when start_flush_work() succeeds either,
> > right? IOW, would lockdep trigger when an actual deadlock happens?
>
> I believe it does although I haven't tested it.
How does it do that? While wq->lockdep_map would be able to detect
some of the chaining, the read acquire paths probably would miss some
other. In general, wq->lockdep_map is used to express dependencies
regarding workqueue flushing (and the self flushing) and it would
probably be better to express work item dependencies explicitly using
work->lockdep_map even if it becomes redundant through wq->lockdep_map
sometimes.
> > If not, why not add the acquire/release() before flush_work() does
> > anything?
>
> I was worried about causing false positive lockdep warnings in the case
> that start_flush_work() succeeds and returns true. In that case, lockdep
> is told about the cwq lockdep map:
>
> static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
> bool wait_executing)
> {
>
> .....
>
> if (cwq->wq->saved_max_active == 1 || cwq->wq->flags & WQ_RESCUER)
> lock_map_acquire(&cwq->wq->lockdep_map);
> else
> lock_map_acquire_read(&cwq->wq->lockdep_map);
>
>
> and so if we acquired the work->lockdep_map before the
> cwq->wq->lockdep_map we would get a warning about ABBA between these two
> lockdep maps. At least that is what I'm lead to believe when I look at
> what process_one_work() is doing. Please correct me if I'm wrong.
All that's necessary is acquiring and releasing work->lockdep_map.
There's no need to nest start_flush_work() inside it. Without
nesting, there's nothing to worry about ABBA lockdeps.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/9] atl1c: update hardware settings - v3
From: David Miller @ 2012-04-20 17:20 UTC (permalink / raw)
To: xiong; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <157393863283F442885425D2C454285623D5AA79@nasanexd02a.na.qualcomm.com>
From: "Huang, Xiong" <xiong@qca.qualcomm.com>
Date: Fri, 20 Apr 2012 10:34:13 +0000
> Please ignore this patch set, we found some NICs sometimes may
> fail to get IP via DHCP, this issue doesn't 100% happen. So,
> after fixing it, we will re-send a new patch set.
Ok.
^ permalink raw reply
* Re: RTM_NEWLINK not received by application when connecting multiple devices simultaneously
From: Stephen Hemminger @ 2012-04-20 16:15 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Ben Greear, netdev
In-Reply-To: <CAKfDRXiPOj64M0oSW9Dc5F0+src3mAjKYna+UM8hwEiHEJXniQ@mail.gmail.com>
On Fri, 20 Apr 2012 18:04:49 +0200
Kristian Evensen <kristian.evensen@gmail.com> wrote:
> I have uploaded a compressed version of my listener code here:
> http://pastebin.com/f1NPYGSh
>
> The othe operations my application do related to netlink, is to
> configure the sockets. Could it be that the configuration messages
> somehow disturb the retrieval of other messages, as they all use the
> same mnl_sock? None of them requests any replies (they are all
> RTM_NEW*/NLM_F_CREATE), but I am not sure about the internal working
> of netlink.
Most applications using netlink listening have two sockets, one
for events the other for requests. The problem is that your own requests
will generate events and it is hard to tell what to expect next
the response (ACK) or the async event when using the same socket.
^ permalink raw reply
* Re: RTM_NEWLINK not received by application when connecting multiple devices simultaneously
From: Kristian Evensen @ 2012-04-20 16:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ben Greear, netdev
In-Reply-To: <CAKfDRXgd-9w_PL47OynVL3LX-Z7vG4skGOkQxOLc74=7jWBBXQ@mail.gmail.com>
I have uploaded a compressed version of my listener code here:
http://pastebin.com/f1NPYGSh
The othe operations my application do related to netlink, is to
configure the sockets. Could it be that the configuration messages
somehow disturb the retrieval of other messages, as they all use the
same mnl_sock? None of them requests any replies (they are all
RTM_NEW*/NLM_F_CREATE), but I am not sure about the internal working
of netlink.
^ permalink raw reply
* Re: RTM_NEWLINK not received by application when connecting multiple devices simultaneously
From: Kristian Evensen @ 2012-04-20 15:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ben Greear, netdev
In-Reply-To: <20120420081400.67a98836@nehalam.linuxnetplumber.net>
On Fri, Apr 20, 2012 at 5:14 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
>
> Check if ip command catches the events (ip monitor).
ip monitor catches the event, also when I run ip monitor link. I.e.,
the message is sent to the RTMGRP_LINK, which the application
subscribes to.
> What is the type of device? and what do you mean by connecting?
> (ie installing, doing admin up, operstate transition, carrier)
The devices are USB 3G Modems (Huawei e173). By connecting, I mean
when ppp has established a successful connection. I.e., the device is
seen as IFF_RUNNING/IF_OPER_UP.
-Kristian
^ permalink raw reply
* RE: rx_dropped packets stop with tcpdump running
From: Marco Berizzi @ 2012-04-20 15:25 UTC (permalink / raw)
To: brian.haley; +Cc: tushar.n.dave, netdev, eric.dumazet
In-Reply-To: <4F9179E3.5020507@hp.com>
brian.haley@hp.com wrote:
> 0x886d or 0x86DD? That second one is IPv6, you might just need to load the module.
here is the tcpdump:
17:23:25.561398 00:19:99:90:ba:72 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x886d), length 64:
0x0000: 0001 0001 000c 24e2 0001 0019 9990 ba72 ......$........r
0x0010: 0000 0500 2304 6364 726f 447b d700 80f8 ....#.cdroD{....
0x0020: ffff 20d1 b631 80fa ffff e02b fb30 80fa .....1.....+.0..
0x0030: ffff ..
17:23:25.561402 00:19:99:90:ba:73 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x886d), length 64:
0x0000: 0001 0001 000c 24e2 0002 0019 9990 ba72 ......$........r
0x0010: 6700 5400 6800 7200 6500 7300 6800 6f00 g.T.h.r.e.s.h.o.
0x0020: 6c00 6400 0000 3700 3200 0000 0000 0000 l.d...7.2.......
0x0030: 0000 ..
^ permalink raw reply
* Re: RTM_NEWLINK not received by application when connecting multiple devices simultaneously
From: Stephen Hemminger @ 2012-04-20 15:14 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Ben Greear, netdev
In-Reply-To: <CAKfDRXih39RVnx1P72due=_v9-ORWf=YUfUTPKcvVbNzVuTLdw@mail.gmail.com>
On Fri, 20 Apr 2012 16:07:42 +0200
Kristian Evensen <kristian.evensen@gmail.com> wrote:
> Thank you very much for all the help.
>
> >> I spent some more time debugging this now. It turns out that which
> >> interface is seen by my application is not random, it is always the
> >> first one that is connected. This indicates that the bug is that the
> >> netlink message contains information about more than one interface.
> >> However, I am not able to prove this.
> >
> > There is no filtering. A dump request always returns all interfaces.
>
> I think maybe I didnt explain myself clearly enough, I am sorry. This
> does not happen when I dump interface info, but at the event of
> connecting two interfaces at the same time.
>
> I have now converted the application to using libmnl, but I still see
> the same error. There is one message that is not received by my
> netlink socket, or at least, the application does not process it. Just
> in case it was bundled together with the message about the first
> interface, I tried adding a loop where I received the packets (similar
> to the one in the -dump example). However, this did not help.
>
> -Kristian
Check if ip command catches the events (ip monitor).
What is the type of device? and what do you mean by connecting?
(ie installing, doing admin up, operstate transition, carrier)
^ permalink raw reply
* Re: use-after-free in usbnet
From: Huajun Li @ 2012-04-20 15:07 UTC (permalink / raw)
To: Ming Lei
Cc: Oliver Neukum, Alan Stern, Dave Jones,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Fedora Kernel Team
In-Reply-To: <CA+v9cxZWtGbz6uCSysVbAc1hT27rCiuJXzcvSiTxH-zuQYnrZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Apr 20, 2012 at 10:56 PM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Apr 20, 2012 at 10:22 PM, Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Apr 20, 2012 at 9:37 PM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> Above patch has already been integrated to mainline. However, maybe
>>> there still exists another potentail use-after-free issue, here is a
>>> case:
>>> After release the lock in unlink_urbs(), defer_bh() may move
>>> current skb from rxq/txq to dev->done queue, even cause the skb be
>>> released. Then in next loop cycle, it can't refer to expected skb, and
>>> may Oops again.
>>
>> Could you explain in a bit detail? Why can't the expected skb be refered
>> to in next loop?
>
>
> unlink_urbs() complete handler
> --------------------------------------
> -------------------------------------------------
> spin_unlock_irqrestore()
> rx_complete()
> derver_bh()
>
> __skb_unlink()
>
> __skb_queue_tail(&dev->done, skb) =======> skb is moved to
> dev->done, and can be freed by usbnet_bh()
> skb_queue_walk_safe()
> tmp = skb->next ===> refer to freed skb
>
Sorry, email client messed up these lines, resend it:
unlink_urbs() complete handler
------------------------ ------------------------------
spin_unlock_irqrestore()
rx_complete()
derver_bh()
__skb_unlink()
__skb_queue_tail(&dev->done, skb)
=======> skb is moved to dev->done,
and can be freed by usbnet_bh()
skb_queue_walk_safe()
tmp = skb->next ===> refer to freed skb
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH 1/3] don't attach a task to a dead cgroup
From: Glauber Costa @ 2012-04-20 15:05 UTC (permalink / raw)
To: Tejun Heo; +Cc: netdev, cgroups, Li Zefan, kamezawa.hiroyu, David Miller, devel
In-Reply-To: <20120419225322.GC10553@google.com>
On 04/19/2012 07:53 PM, Tejun Heo wrote:
> On Thu, Apr 19, 2012 at 07:49:16PM -0300, Glauber Costa wrote:
>> Not all external callers of cgroup_attach_task() test to
>> see if the cgroup is still live - the internal callers at
>> cgroup.c does.
>>
>> With this test in cgroup_attach_task, we can assure that
>> no tasks are ever moved to a cgroup that is past its
>> destruction point and was already marked as dead.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: Tejun Heo<tj@kernel.org>
>> CC: Li Zefan<lizefan@huawei.com>
>> CC: Kamezawa Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>> ---
>> kernel/cgroup.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index b61b938..932c318 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -1927,6 +1927,9 @@ int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
>> struct cgroup_taskset tset = { };
>> struct css_set *newcg;
>>
>> + if (cgroup_is_removed(cgrp))
>> + return -ENODEV;
>> +
>
> Isn't the test in cgroup_lock_live_group() enough?
>
Yes, when it is done.
Not all callers take it, specially the external ones.
^ permalink raw reply
* Re: [PATCH 2/3] don't take cgroup_mutex in destroy()
From: Glauber Costa @ 2012-04-20 15:04 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Li Zefan, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A, Vivek Goyal
In-Reply-To: <20120419225704.GE10553-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 04/19/2012 07:57 PM, Tejun Heo wrote:
> On Thu, Apr 19, 2012 at 07:49:17PM -0300, Glauber Costa wrote:
>> Most of the destroy functions are only doing very simple things
>> like freeing memory.
>>
>> The ones who goes through lists and such, already use its own
>> locking for those.
>>
>> * The cgroup itself won't go away until we free it, (after destroy)
>> * The parent won't go away because we hold a reference count
>> * There are no more tasks in the cgroup, and the cgroup is declared
>> dead (cgroup_is_removed() == true)
>>
>> For the blk-cgroup and the cpusets, I got the impression that the mutex
>> is still necessary.
>>
>> For those, I grabbed it from within the destroy function itself.
>>
>> If the maintainer for those subsystems consider it safe to remove
>> it, we can discuss it separately.
>
> I really don't like cgroup_lock() usage spreading more. It's
> something which should be contained in cgroup.c proper. I looked at
> the existing users a while ago and they seemed to be compensating
> deficencies in API, so, if at all possible, let's not spread the
> disease.
Well, I can dig deeper and see if they are really needed. I don't know
cpusets and blkcg *that* well, that's why I took them there, hoping that
someone could enlighten me, maybe they aren't really needed even now.
I agree with the compensating: As I mentioned, most of them are already
taking other kinds of lock to protect their structures, which is the
right thing to do.
There were only two or three spots in cpusets and blkcg where I wasn't
that sure that we could drop the lock... What do you say about that ?
^ permalink raw reply
* Re: [PATCH 0/3] Fix problem with static_key decrement
From: Glauber Costa @ 2012-04-20 15:01 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Li Zefan, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20120419225441.GD10553-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 04/19/2012 07:54 PM, Tejun Heo wrote:
> On Thu, Apr 19, 2012 at 07:49:15PM -0300, Glauber Costa wrote:
>> Hi,
>>
>> This is my proposed fix for the sock memcg static_key
>> problem raised by Kamezawa. It works for me, but I would
>> Kame, please confirm.
>
> Please detail the problem. I don't follow what's the purpose here.
>
Ok.
1) Kame found the following bug: we were decrementing the jump label
when the socket limit was set back to unlimited. The problem is that the
sockets outlive the memcg, so we can only do that when the last
reference count is dropped. It is worth mentioning that kmem controller
for memcg will have the exact same problem - I am actually updating my
series with all the results of this discussion here.
2) If, however, there are no sockets in flight, mem_cgroup_put() during
->destroy() will be the last one, and the decrementing will happen there.
3) static_key updates cannot happen with the cgroup_mutex held. This is
because cpusets hold it from within the cpu_hotplug.lock - that
static_keys take through get_online_cpus() in its cpu hotplug handler.
4) Looking at the cpusets code, it really seems necessary, at least by now.
5) Deferring all this to worker threads as you suggested in the cpu
thread - that has a similar problem - can solve this problem, but in
general, will create tons of others, like windows of inconsistent
information.
That's basically it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox