* Re: xen-netback: fix oopes during shutdown and error handling
From: Christopher S. Aker @ 2013-02-14 21:57 UTC (permalink / raw)
To: David Vrabel
Cc: Ian Campbell, Konrad Rzeszutek Wilk, netdev, xen-devel,
Jan Beulich, Wei Liu
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
On 2/14/13 8:18 AM, David Vrabel wrote:
> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.
On 2/14/13 11:39 AM, Ian Campbell wrote:
> Although I would like to add a Tested-by: Christopher too if
> possible.
Tested-by: Christopher S. Aker <caker@theshore.net> (and team)
We are no longer able to trigger the last OOPs we provided by downing
the vif. Further testing of the other issues will take time, but we're
deploying a few patched hosts now.
Thanks!
-Chris
^ permalink raw reply
* [PATCH 4/5 net-next] tg3: Set initial carrier state to off.
From: Michael Chan @ 2013-02-14 22:13 UTC (permalink / raw)
To: davem; +Cc: netdev, nsujir
In-Reply-To: <1360880022-12856-3-git-send-email-mchan@broadcom.com>
Before the device is opened, the carrier state should be off. It
will not race with the link interrupt if we set it before calling
register_netdev().
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 7ac0bd0..3829321 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -16902,6 +16902,8 @@ static int tg3_init_one(struct pci_dev *pdev,
tg3_timer_init(tp);
+ tg3_carrier_off(tp);
+
err = register_netdev(dev);
if (err) {
dev_err(&pdev->dev, "Cannot register net device, aborting\n");
--
1.7.1
^ permalink raw reply related
* [PATCH 1/5 net-next] tg3: Add 57766 device support.
From: Michael Chan @ 2013-02-14 22:13 UTC (permalink / raw)
To: davem; +Cc: netdev, nsujir
From: Matt Carlson <mcarlson@broadcom.com>
The patch also adds a couple of fixes
- For the 57766, bootcode needs to setup the PCIE Fast Training
Sequence (FTS) value to prevent transmit hangs. Unfortunately, it
does not have enough room in the selfboot case (i.e. devices with no
NVRAM). The driver needs to implement this.
- For performance reasons, the 2k DMA engine mode on the 57766 should
be enabled and dma size limited to 2k for standard sized packets.
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 18 +++++++++++++++++-
drivers/net/ethernet/broadcom/tg3.h | 2 ++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index b1b3bc0..6e676a7 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -332,6 +332,7 @@ static DEFINE_PCI_DEVICE_TABLE(tg3_pci_tbl) = {
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5719)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5720)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57762)},
+ {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57766)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5762)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5725)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5727)},
@@ -9179,7 +9180,14 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
}
if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_57765_AX) {
- u32 grc_mode = tr32(GRC_MODE);
+ u32 grc_mode;
+
+ /* Fix transmit hangs */
+ val = tr32(TG3_CPMU_PADRNG_CTL);
+ val |= TG3_CPMU_PADRNG_CTL_RDIV2;
+ tw32(TG3_CPMU_PADRNG_CTL, val);
+
+ grc_mode = tr32(GRC_MODE);
/* Access the lower 1K of DL PCIE block registers. */
val = grc_mode & ~GRC_MODE_PCIE_PORT_MASK;
@@ -9492,6 +9500,14 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
if (tg3_flag(tp, PCI_EXPRESS))
rdmac_mode |= RDMAC_MODE_FIFO_LONG_BURST;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57766) {
+ tp->dma_limit = 0;
+ if (tp->dev->mtu <= ETH_DATA_LEN) {
+ rdmac_mode |= RDMAC_MODE_JMB_2K_MMRR;
+ tp->dma_limit = TG3_TX_BD_DMA_MAX_2K;
+ }
+ }
+
if (tg3_flag(tp, HW_TSO_1) ||
tg3_flag(tp, HW_TSO_2) ||
tg3_flag(tp, HW_TSO_3))
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index ef6ced2..b676728 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -1164,6 +1164,8 @@
#define CPMU_MUTEX_GNT_DRIVER 0x00001000
#define TG3_CPMU_PHY_STRAP 0x00003664
#define TG3_CPMU_PHY_STRAP_IS_SERDES 0x00000020
+#define TG3_CPMU_PADRNG_CTL 0x00003668
+#define TG3_CPMU_PADRNG_CTL_RDIV2 0x00040000
/* 0x3664 --> 0x36b0 unused */
#define TG3_CPMU_EEE_MODE 0x000036b0
--
1.7.1
^ permalink raw reply related
* [PATCH 2/5 net-next] tg3: Add EEE support for 5717 B0
From: Michael Chan @ 2013-02-14 22:13 UTC (permalink / raw)
To: davem; +Cc: netdev, nsujir
In-Reply-To: <1360880022-12856-1-git-send-email-mchan@broadcom.com>
This chip supports Energy Efficient Ethernet.
Signed-off-by: Michael Chan <mchan@broadocm.com>
---
drivers/net/ethernet/broadcom/tg3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 6e676a7..3004d69 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14514,7 +14514,7 @@ static int tg3_phy_probe(struct tg3 *tp)
(GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5720 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5762 ||
- (tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 &&
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5717 &&
tp->pci_chip_rev_id != CHIPREV_ID_5717_A0) ||
(GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
tp->pci_chip_rev_id != CHIPREV_ID_57765_A0)))
--
1.7.1
^ permalink raw reply related
* [PATCH 5/5 net-next] tg3: Update version to 3.130
From: Michael Chan @ 2013-02-14 22:13 UTC (permalink / raw)
To: davem; +Cc: netdev, nsujir
In-Reply-To: <1360880022-12856-4-git-send-email-mchan@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3829321..1b59876 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -94,10 +94,10 @@ static inline void _tg3_flag_clear(enum TG3_FLAGS flag, unsigned long *bits)
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
-#define TG3_MIN_NUM 129
+#define TG3_MIN_NUM 130
#define DRV_MODULE_VERSION \
__stringify(TG3_MAJ_NUM) "." __stringify(TG3_MIN_NUM)
-#define DRV_MODULE_RELDATE "January 06, 2013"
+#define DRV_MODULE_RELDATE "February 14, 2013"
#define RESET_KIND_SHUTDOWN 0
#define RESET_KIND_INIT 1
--
1.7.1
^ permalink raw reply related
* [PATCH 3/5 net-next] tg3: Fix 5762 NVRAM sizing
From: Michael Chan @ 2013-02-14 22:13 UTC (permalink / raw)
To: davem; +Cc: netdev, nsujir
In-Reply-To: <1360880022-12856-2-git-send-email-mchan@broadcom.com>
Don't set the default size to 128K if it is 5762. Instead, rely on the
size we obtain from NVRAM location 0xf0.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3004d69..7ac0bd0 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -13883,7 +13883,8 @@ static void tg3_get_5720_nvram_info(struct tg3 *tp)
tp->nvram_size = TG3_NVRAM_SIZE_1MB;
break;
default:
- tp->nvram_size = TG3_NVRAM_SIZE_128KB;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5762)
+ tp->nvram_size = TG3_NVRAM_SIZE_128KB;
break;
}
break;
@@ -13929,7 +13930,8 @@ static void tg3_get_5720_nvram_info(struct tg3 *tp)
tp->nvram_size = TG3_NVRAM_SIZE_1MB;
break;
default:
- tp->nvram_size = TG3_NVRAM_SIZE_128KB;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5762)
+ tp->nvram_size = TG3_NVRAM_SIZE_128KB;
break;
}
break;
--
1.7.1
^ permalink raw reply related
* Re: bonding inactive slaves vs rx_dropped
From: Jay Vosburgh @ 2013-02-14 21:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet, andy
In-Reply-To: <20130214.160657.1394358701071068786.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
>People are starting to notice that rx_dropped now increments on every
>packet received on an bond's inactive slave.
>
>I'm actually fine with rx_dropped incrementing in this situation.
>
>The problem I want to address is that rx_dropped is encompassing
>several unrelated situations and thus has become less useful for
>diagnosis.
>
>I think we should add some new RX stats such that we can get at
>least a small amount of granularity for rx_dropped.
>
>This way team, bond, etc. can increment a new netdev_stats->rx_foo in
>this situation, and then someone doing diagnosis can see that
>rx_dropped and rx_foo are incrementing at similar rates.
This drop isn't really happening in bonding, though. From
looking at the code, it comes about because, for the inactive slave, the
rx_handler call returns EXACT, and there aren't any exact match ptype
bindings, so __netif_receive_skb throws it away. This isn't always the
case; sometimes there is an exact match, for things like iSCSI or FCoE
that are really determined to get the packet.
On a non-bonded interface, the same drop path (except for the
rx_handler) is taken for incoming packets for an unsupported protocol.
We could probably add an, oh, rx_dropped_inactive, or some
variation on that theme, that is incremented at the end of
__netif_receive_skb if deliver_exact is set, e.g., something like:
diff --git a/net/core/dev.c b/net/core/dev.c
index a87bc74..4cd7c1f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3559,6 +3559,8 @@ ncls:
} else {
drop:
atomic_long_inc(&skb->dev->rx_dropped);
+ if (deliver_exact)
+ atomic_long_inc(&skb->dev->rx_dropped_inactive);
kfree_skb(skb);
/* Jamal, now you will not able to escape explaining
* me how you were going to use this. :-)
I think this would only hit frames that have been soft-rejected
(rx_handler says EXACT) by bonding or team, but were not subsequently
delivered to an exact match listener.
There's the separate questions of whether there should be more
counters (e.g., drops in dev_skb_forward or enqueue_to_backlog), and how
to deliver the counter(s) to user space.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply related
* bonding inactive slaves vs rx_dropped
From: David Miller @ 2013-02-14 21:06 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, fubar, andy
People are starting to notice that rx_dropped now increments on every
packet received on an bond's inactive slave.
I'm actually fine with rx_dropped incrementing in this situation.
The problem I want to address is that rx_dropped is encompassing
several unrelated situations and thus has become less useful for
diagnosis.
I think we should add some new RX stats such that we can get at
least a small amount of granularity for rx_dropped.
This way team, bond, etc. can increment a new netdev_stats->rx_foo in
this situation, and then someone doing diagnosis can see that
rx_dropped and rx_foo are incrementing at similar rates.
^ permalink raw reply
* [PATCH net-next] net: Don't write to current task flags on every packet received.
From: David Miller @ 2013-02-14 20:58 UTC (permalink / raw)
To: netdev
Even for non-pfmalloc SKBs, __netif_receive_skb() will do a
tsk_restore_flags() on current unconditionally.
Make __netif_receive_skb() a shim around the existing code, renamed to
__netif_receive_skb_core(). Let __netif_receive_skb() wrap the
__netif_receive_skb_core() call with the task flag modifications, if
necessary.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
I'll commit this after I do a bunch of tests.
net/core/dev.c | 46 ++++++++++++++++++++++++++++------------------
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 2f31bf9..f444736 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3457,7 +3457,7 @@ static bool skb_pfmemalloc_protocol(struct sk_buff *skb)
}
}
-static int __netif_receive_skb(struct sk_buff *skb)
+static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
@@ -3466,24 +3466,11 @@ static int __netif_receive_skb(struct sk_buff *skb)
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
- unsigned long pflags = current->flags;
net_timestamp_check(!netdev_tstamp_prequeue, skb);
trace_netif_receive_skb(skb);
- /*
- * PFMEMALLOC skbs are special, they should
- * - be delivered to SOCK_MEMALLOC sockets only
- * - stay away from userspace
- * - have bounded memory usage
- *
- * Use PF_MEMALLOC as this saves us from propagating the allocation
- * context down to all allocation sites.
- */
- if (sk_memalloc_socks() && skb_pfmemalloc(skb))
- current->flags |= PF_MEMALLOC;
-
/* if we've gotten here through NAPI, check netpoll */
if (netpoll_receive_skb(skb))
goto out;
@@ -3517,7 +3504,7 @@ another_round:
}
#endif
- if (sk_memalloc_socks() && skb_pfmemalloc(skb))
+ if (pfmemalloc)
goto skip_taps;
list_for_each_entry_rcu(ptype, &ptype_all, list) {
@@ -3536,8 +3523,7 @@ skip_taps:
ncls:
#endif
- if (sk_memalloc_socks() && skb_pfmemalloc(skb)
- && !skb_pfmemalloc_protocol(skb))
+ if (pfmemalloc && !skb_pfmemalloc_protocol(skb))
goto drop;
if (vlan_tx_tag_present(skb)) {
@@ -3607,7 +3593,31 @@ drop:
unlock:
rcu_read_unlock();
out:
- tsk_restore_flags(current, pflags, PF_MEMALLOC);
+ return ret;
+}
+
+static int __netif_receive_skb(struct sk_buff *skb)
+{
+ int ret;
+
+ if (sk_memalloc_socks() && skb_pfmemalloc(skb)) {
+ unsigned long pflags = current->flags;
+
+ /*
+ * PFMEMALLOC skbs are special, they should
+ * - be delivered to SOCK_MEMALLOC sockets only
+ * - stay away from userspace
+ * - have bounded memory usage
+ *
+ * Use PF_MEMALLOC as this saves us from propagating the allocation
+ * context down to all allocation sites.
+ */
+ current->flags |= PF_MEMALLOC;
+ ret = __netif_receive_skb_core(skb, true);
+ tsk_restore_flags(current, pflags, PF_MEMALLOC);
+ } else
+ ret = __netif_receive_skb_core(skb, false);
+
return ret;
}
--
1.7.11.7
^ permalink raw reply related
* Re: Fw: [Bug 53821] New: ip rules (policy routing) no longer applied consistency
From: Julian Anastasov @ 2013-02-14 20:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20130214082616.44ad070c@nehalam.linuxnetplumber.net>
Hello,
On Thu, 14 Feb 2013, Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Thu, 14 Feb 2013 01:26:32 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 53821] New: ip rules (policy routing) no longer applied consistency
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=53821
>
> Summary: ip rules (policy routing) no longer applied
> consistency
> Product: Networking
> Version: 2.5
> Kernel Version: 3.7
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: korn-kernel.org@elan.rulez.org
> Regression: Yes
>
>
> Hi,
>
> on upgrading to 3.7.x, I noticed that some of my ip rules were no longer
> applied.
>
> For example, I had:
>
> # ip ru sh
> 0: from all lookup local
> 32762: from 192.168.0.15 lookup foo
> 32763: from 1.2.3.4 lookup foo
> 32764: from 10.74.91.0/24 lookup foo
> 32765: from 192.168.0.19 lookup vpntunnel
> 32766: from all lookup main
> 32767: from all lookup default
>
> # ip ro sh table vpntunnel
> default via 192.168.0.144 dev br0
> 192.168.0.0/24 dev br0 scope link
>
> The 'lookup foo' rules were applied, but 'lookup vpntunnel' was not.
>
> I then tried to use an fwmark based rule to achieve the same result:
>
> # ip ru sh
> 0: from all lookup local
> 32761: from all fwmark 0x2 lookup vpntunnel
> 32762: from 192.168.0.15 lookup foo
> 32763: from 1.2.3.4 lookup foo
> 32764: from 10.74.91.0/24 lookup foo
> 32765: from 192.168.0.19 lookup vpntunnel
> 32766: from all lookup main
> 32767: from all lookup default
>
> Of course I made sure the appropriate packets were marked with 0x2. This worked
> a lot better and most packets go out via 192.168.0.144 now, but strangely, not
> all. I have a netfilter rule that catches the ones going the wrong way, and I
> get quite a few log messages along the lines of:
>
> kernel: FW: DROP: IN= OUT=eth1 SRC=192.168.0.19 DST=2.3.4.5 LEN=131 TOS=0x00
> PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17504 DPT=42834 LEN=111 UID=1007
> GID=1007 MARK=0x2
>
> As you can see, the packet is logged as having the correct fwmark, but is still
> sent out through eth1 instead of br0. (And the IP based rule should have
> applied to, but didn't.)
>
> This particular result was obtained with 3.7.6-vs2.3.5.5 (linux-vserver patch),
> but I've seen similar behaviour with 3.7.anything.
Not sure if it is related but in patch-3.7.7-vs2.3.5.6.diff
there is function ip_v4_find_src() that calls __ip_route_output_key
multiple times without resetting some input keys (oif, tos) with
flowi4_update_output(). ip_route_connect() is example for
such usage. This is needed in case we want to provide
original TOS and OIF for next lookups.
> Source IP based rules worked fine with kernels up to 3.6. Confusingly, _some_
> of them still work, but not all.
>
> Maybe something was broken by the removal of the route cache?
At first look I don't see other problems with
the route usage in this patch.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
From: Sasha Levin @ 2013-02-14 20:18 UTC (permalink / raw)
To: Andy King; +Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh, davem
In-Reply-To: <1360196636-9357-2-git-send-email-acking@vmware.com>
Hi Andy,
On Wed, Feb 6, 2013 at 7:23 PM, Andy King <acking@vmware.com> wrote:
> + * Specifically, we initialize the vsock_bind_table array to a size of
> + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
> + * vsock_bind_table[VSOCK_HASH_SIZE - 1] are for bound sockets and
> + * vsock_bind_table[VSOCK_HASH_SIZE] is for unbound sockets. The hash function
> + * mods with VSOCK_HASH_SIZE - 1 to ensure this.
> + */
> +#define VSOCK_HASH_SIZE 251
> +#define MAX_PORT_RETRIES 24
> +
> +#define VSOCK_HASH(addr) ((addr)->svm_port % (VSOCK_HASH_SIZE - 1))
> +#define vsock_bound_sockets(addr) (&vsock_bind_table[VSOCK_HASH(addr)])
> +#define vsock_unbound_sockets (&vsock_bind_table[VSOCK_HASH_SIZE])
> +
> +/* XXX This can probably be implemented in a better way. */
> +#define VSOCK_CONN_HASH(src, dst) \
> + (((src)->svm_cid ^ (dst)->svm_port) % (VSOCK_HASH_SIZE - 1))
> +#define vsock_connected_sockets(src, dst) \
> + (&vsock_connected_table[VSOCK_CONN_HASH(src, dst)])
> +#define vsock_connected_sockets_vsk(vsk) \
> + vsock_connected_sockets(&(vsk)->remote_addr, &(vsk)->local_addr)
> +
> +static struct list_head vsock_bind_table[VSOCK_HASH_SIZE + 1];
> +static struct list_head vsock_connected_table[VSOCK_HASH_SIZE];
> +static DEFINE_SPINLOCK(vsock_table_lock);
Why isn't it using the kernel's linux/hashtable.h?
Thanks,
Sasha
^ permalink raw reply
* Re: how to handle bonding failover when using a bridge over the bond?
From: Rick Jones @ 2013-02-14 19:42 UTC (permalink / raw)
To: Chris Friesen; +Cc: Jay Vosburgh, Cong Wang, netdev
In-Reply-To: <511D3AFC.10504@genband.com>
If a VM were to see its link to the bridge module bounce/cycle, might
that cause it to send a gratuitous ARP on its own? It would be
something akin to the "if this uplink fails, bring down these downlinks"
functionality that is out there in some places. Bond says "hey, I've
had a change" then bridge toggles the "downlinks" to the VMs.
rick jones
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv6: use newly introduced __ipv6_addr_needs_scope_id and ipv6_iface_scope_id
From: Brian Haley @ 2013-02-14 19:31 UTC (permalink / raw)
To: hannes; +Cc: YOSHIFUJI Hideaki, netdev
In-Reply-To: <20130214185326.GB8611@order.stressinduktion.org>
On 02/14/2013 01:53 PM, Hannes Frederic Sowa wrote:
> On Thu, Feb 14, 2013 at 10:25:46AM -0500, Brian Haley wrote:
>>> [PATCH net-next RFC] ipv6: introduce new type ipv6_addr_props to hold type and scope
>>>
>>> ---
>>> include/net/ipv6.h | 16 +++++---
>>> net/ipv6/addrconf.c | 27 +++++++-------
>>> net/ipv6/addrconf_core.c | 97 +++++++++++++++++++++++++++++++-----------------
>>> net/ipv6/datagram.c | 12 +++---
>>> 4 files changed, 95 insertions(+), 57 deletions(-)
>>>
>>> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
>>> index 851d541..3a3ec1cc 100644
>>> --- a/include/net/ipv6.h
>>> +++ b/include/net/ipv6.h
>>> @@ -298,20 +298,26 @@ static inline int ip6_frag_mem(struct net *net)
>>> #define IPV6_FRAG_LOW_THRESH (3 * 1024*1024) /* 3145728 */
>>> #define IPV6_FRAG_TIMEOUT (60 * HZ) /* 60 seconds */
>>>
>>> -extern int __ipv6_addr_type(const struct in6_addr *addr);
>>> +struct ipv6_addr_props {
>>> + u16 type;
>>> + s16 scope;
>>> +};
>>
>> Seeing this makes me think we should unify the flags and scope members of
>> inet6_ifaddr to something like this, moving to a single set of values for IPv6
>> addresses. Then ipv6_dev_get_saddr() wouldn't have to use __ipv6_adr_type() as
>> much since the address struct would already have the values. Possible future
>> work...
>
> Thanks for your feedback. I will incooperate it in my patch.
Ok, just don't worry about this above one right now, once you dig into it you
will realize it's not straightforward. I'd just fix any existing bugs first.
I'll see if I can find the time to send out an RFC patch of what I mean...
-Brian
^ permalink raw reply
* Re: how to handle bonding failover when using a bridge over the bond?
From: Chris Friesen @ 2013-02-14 19:29 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Cong Wang, netdev
In-Reply-To: <23692.1360864993@death.nxdomain>
On 02/14/2013 12:03 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@genband.com> wrote:
>> The problem is that L2 switch "B" still thinks that all the virtual
>> machines are accessible via L2 switch "A". Thus any incoming packets
>> destined for a virtual machine will get dropped.
>
> I'm trying to track down the system I tested previously to see
> exactly how it is set up and why it works when yours does not. It's
> possible that it doesn't work, and the testing we did simply missed this
> case.
After thinking about this for a while, it doesn't seem like a natural
thing for either the bond or the bridge to care about--though if someone
wanted to fix it generically that would be great.
It might be worth considering sending out a bonding-specific netlink
message when a bond fails over, giving the name of the bond as well as
the newly active slave device. This would allow for an efficient
userspace daemon to issue gratuitous arps for all the VM MAC addresses.
It almost seems like the most elegant way to deal with this would be to
forgo the bond completely and just add both links into the bridge, then
run STP to make sure there are no loops. That way link pulls get
handled immediately and STP will update the other L2 switches
appropriately. Unfortunately this doesn't seem to be an option for us
since some apparently customers frown on a server participating in STP.
(Not sure why, we're already dealing with much more complicated
protocols...)
Chris
^ permalink raw reply
* Re: [PATCH] net: Convert skb->csum_(start|offset) integrity BUG_ON() to WARN_ON() & drop
From: Eric Dumazet @ 2013-02-14 19:21 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev
In-Reply-To: <20130214185008.GA10745@casper.infradead.org>
On Thu, 2013-02-14 at 18:50 +0000, Thomas Graf wrote:
> On 02/14/13 at 08:22am, Eric Dumazet wrote:
> > It seems not possible to avoid bugs, being a BUG_ON() or a out of bound
> > memory access or whatever. We must fix them eventually.
>
> Of course, I never intended to not fix this but I still think
> leaving the BUG_ON() is wrong ;-)
>
> > In this case, it seems we must limit payload to
> >
> > 65535 - MAX_TCP_HEADER
> >
> > It would make tcp_xmit_size_goal() a bit shorter.
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 2c7e596..2f6c8e5 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -793,10 +793,7 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
> > xmit_size_goal = mss_now;
> >
> > if (large_allowed && sk_can_gso(sk)) {
> > - xmit_size_goal = ((sk->sk_gso_max_size - 1) -
> > - inet_csk(sk)->icsk_af_ops->net_header_len -
> > - inet_csk(sk)->icsk_ext_hdr_len -
> > - tp->tcp_header_len);
> > + xmit_size_goal = sk->sk_gso_max_size - 1 - MAX_TCP_HEADER;
> >
> > /* TSQ : try to have two TSO segments in flight */
> > xmit_size_goal = min_t(u32, xmit_size_goal,
>
> I don't think this would help. The allocated skb data will still
> exceed 64K and thus after trimming the acked data and collapsing
> the header might be stored after the 64K mark.
>
OK, I now understand your issue.
> We would have to limit the skb tailroom to 64K upon allocation.
> That would mean we would waste some of the additional space that
> kmalloc() might have given us:
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 32443eb..c8f9850 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -241,6 +241,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mas
> * to allow max possible filling before reallocation.
> */
> size = SKB_WITH_OVERHEAD(ksize(data));
> + /* ensure that all offsets based on skb->head fit into 16bits */
> + size = min_t(int, size, 65535);
> prefetchw(data + size);
>
This part is certainly not good.
alloc_skb() is generic and some users really want more than 64K
> /*
>
>
> Or if that is not ideal, avoiding the collapse that causes the overflow
> would also help:
>
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 5d45159..e9111b4 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2301,6 +2301,12 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
> if (after(TCP_SKB_CB(skb)->end_seq, tcp_wnd_end(tp)))
> break;
>
> + /* Never collapse if the resulting headroom + data exceeds
> + * 64K as that is the maximum csum_start can cover.
> + */
> + if (skb_headroom(to) + to->len + skb->len > 65535)
> + break;
> +
> tcp_collapse_retrans(sk, to);
>
Definitely better.
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv6: use newly introduced __ipv6_addr_needs_scope_id and ipv6_iface_scope_id
From: Hannes Frederic Sowa @ 2013-02-14 18:53 UTC (permalink / raw)
To: Brian Haley; +Cc: YOSHIFUJI Hideaki, netdev
In-Reply-To: <511D01FA.8080506@hp.com>
On Thu, Feb 14, 2013 at 10:25:46AM -0500, Brian Haley wrote:
> > [PATCH net-next RFC] ipv6: introduce new type ipv6_addr_props to hold type and scope
> >
> > ---
> > include/net/ipv6.h | 16 +++++---
> > net/ipv6/addrconf.c | 27 +++++++-------
> > net/ipv6/addrconf_core.c | 97 +++++++++++++++++++++++++++++++-----------------
> > net/ipv6/datagram.c | 12 +++---
> > 4 files changed, 95 insertions(+), 57 deletions(-)
> >
> > diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> > index 851d541..3a3ec1cc 100644
> > --- a/include/net/ipv6.h
> > +++ b/include/net/ipv6.h
> > @@ -298,20 +298,26 @@ static inline int ip6_frag_mem(struct net *net)
> > #define IPV6_FRAG_LOW_THRESH (3 * 1024*1024) /* 3145728 */
> > #define IPV6_FRAG_TIMEOUT (60 * HZ) /* 60 seconds */
> >
> > -extern int __ipv6_addr_type(const struct in6_addr *addr);
> > +struct ipv6_addr_props {
> > + u16 type;
> > + s16 scope;
> > +};
>
> Seeing this makes me think we should unify the flags and scope members of
> inet6_ifaddr to something like this, moving to a single set of values for IPv6
> addresses. Then ipv6_dev_get_saddr() wouldn't have to use __ipv6_adr_type() as
> much since the address struct would already have the values. Possible future
> work...
Thanks for your feedback. I will incooperate it in my patch.
> > if ((st & htonl(0xFFC00000)) == htonl(0xFEC00000))
> > - return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST |
> > - IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_SITELOCAL)); /* addr-select 3.1 */
> > + /* addr-select 3.1 */
> > + return (struct ipv6_addr_props){
> > + .type = IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST,
> > + .scope = IPV6_ADDR_SCOPE_SITELOCAL,
> > + };
>
> type here is wrong, should be IPV6_ADDR_SITELOCAL not linklocal.
Oops, of course. :)
> > @@ -653,13 +653,15 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
> > rcu_read_unlock();
> > return -ENODEV;
> > }
> > - } else if (addr_type & IPV6_ADDR_LINKLOCAL) {
> > + } else if (addr_props.type & IPV6_ADDR_LINKLOCAL) {
>
> Could be (addr_props.scope == IPV6_ADDR_SCOPE_LINKLOCAL), right?
This code will be changed by my other patches (see the series I posted
about introducing helper functions for checking for sin6_scope_id, patch
1/2). I think I will let it as is for the time being.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH] net: Convert skb->csum_(start|offset) integrity BUG_ON() to WARN_ON() & drop
From: Thomas Graf @ 2013-02-14 18:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1360858943.6884.47.camel@edumazet-glaptop>
On 02/14/13 at 08:22am, Eric Dumazet wrote:
> It seems not possible to avoid bugs, being a BUG_ON() or a out of bound
> memory access or whatever. We must fix them eventually.
Of course, I never intended to not fix this but I still think
leaving the BUG_ON() is wrong ;-)
> In this case, it seems we must limit payload to
>
> 65535 - MAX_TCP_HEADER
>
> It would make tcp_xmit_size_goal() a bit shorter.
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 2c7e596..2f6c8e5 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -793,10 +793,7 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
> xmit_size_goal = mss_now;
>
> if (large_allowed && sk_can_gso(sk)) {
> - xmit_size_goal = ((sk->sk_gso_max_size - 1) -
> - inet_csk(sk)->icsk_af_ops->net_header_len -
> - inet_csk(sk)->icsk_ext_hdr_len -
> - tp->tcp_header_len);
> + xmit_size_goal = sk->sk_gso_max_size - 1 - MAX_TCP_HEADER;
>
> /* TSQ : try to have two TSO segments in flight */
> xmit_size_goal = min_t(u32, xmit_size_goal,
I don't think this would help. The allocated skb data will still
exceed 64K and thus after trimming the acked data and collapsing
the header might be stored after the 64K mark.
We would have to limit the skb tailroom to 64K upon allocation.
That would mean we would waste some of the additional space that
kmalloc() might have given us:
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 32443eb..c8f9850 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -241,6 +241,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mas
* to allow max possible filling before reallocation.
*/
size = SKB_WITH_OVERHEAD(ksize(data));
+ /* ensure that all offsets based on skb->head fit into 16bits */
+ size = min_t(int, size, 65535);
prefetchw(data + size);
/*
Or if that is not ideal, avoiding the collapse that causes the overflow
would also help:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5d45159..e9111b4 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2301,6 +2301,12 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
if (after(TCP_SKB_CB(skb)->end_seq, tcp_wnd_end(tp)))
break;
+ /* Never collapse if the resulting headroom + data exceeds
+ * 64K as that is the maximum csum_start can cover.
+ */
+ if (skb_headroom(to) + to->len + skb->len > 65535)
+ break;
+
tcp_collapse_retrans(sk, to);
}
}
^ permalink raw reply related
* Re: how to handle bonding failover when using a bridge over the bond?
From: Jay Vosburgh @ 2013-02-14 18:03 UTC (permalink / raw)
To: Chris Friesen; +Cc: Cong Wang, netdev
In-Reply-To: <511D141B.602@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>On 02/14/2013 02:01 AM, Cong Wang wrote:
>> On Wed, 13 Feb 2013 at 00:30 GMT, Chris Friesen<chris.friesen@genband.com> wrote:
>>> On 02/12/2013 06:02 PM, Jay Vosburgh wrote:
>>>> The bond doesn't track all of the MACs that go through it, but
>>>> the bridge presumably does, and could respond to the FAILOVER notifier
>>>> with something to notify the switch that the port assignments for the
>>>> various MACs have changed.
>>>
>>> That would probably make sense. I've added the bridging folks, maybe
>>> they'll have a suggestion how this sort of thing should be handled.
>>>
>>
>> It is already handled. When BONDING_FAILOVER is triggered and the MAC has
>> been changed, NETDEV_CHANGEADDR is issued too, then bridge will capture
>> it and update its fdb:
>>
>> case NETDEV_CHANGEADDR:
>> spin_lock_bh(&br->lock);
>> br_fdb_changeaddr(p, dev->dev_addr);
>> changed_addr = br_stp_recalculate_bridge_id(br);
>> spin_unlock_bh(&br->lock);
>>
>> if (changed_addr)
>> call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
>>
>> break;
>
>I'm not familiar with the bridge code, can you elaborate on how this helps?
I'm not sure that it does, even if you're using STP (although
I'd want to try it with STP to make sure). This only updates the fdb's
MAC for the bond's port. It won't affect the VM's MACs (which it
shouldn't, because they don't change), and won't send any gratuitous
updates through the bond's port to the switch that would notify the
second switch ("B" in Chris's description, below) that the switch port
for the VM's MAC(s) has changed.
Also, if the bond has fail_over_mac=follow, then no CHANGEADDR
is issued, because the MAC address does not change. This is not common
(and not the case in the configuration described below), but does occur.
>The problem scenario is this:
>
>I have a host with eth0/eth1 bonded together as bond0. eth0/eth1 are
>connected to separate L2 switches, which are interconnected.
>
>On the host there are a number of virtual machines, each with a virtual
>interface.
>
>All the virtual interfaces as well as bond0 are bridged together to allow
>the VMs, the host, and the outside world to talk to each other.
>
>Currently the host does NOT participate in STP because it is considered an
>edge node.
>
>Suppose eth0 is the active link and we pull it. The bond will make eth1
>active and emit gratuitous arp packets for itself, so the external L2
>switches will update the location of the MAC address belonging to the
>bond. On loss of carrier for the link to eth0 L2 switch "A" will drop the
>entries for the MAC addresses, including the ones for the virtual
>machines.
>
>The problem is that L2 switch "B" still thinks that all the virtual
>machines are accessible via L2 switch "A". Thus any incoming packets
>destined for a virtual machine will get dropped.
I'm trying to track down the system I tested previously to see
exactly how it is set up and why it works when yours does not. It's
possible that it doesn't work, and the testing we did simply missed this
case.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] Fix, cleanup, optimize gfar_private and the Rx path
From: David Miller @ 2013-02-14 18:32 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, paul.gortmaker
In-Reply-To: <1360854007-11094-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Thu, 14 Feb 2013 17:00:00 +0200
> These patches went already through a review round with Paul.
> Changes since the initial version of the patches:
> * split the 1st patch into two patches (01 & 02, as suggested by Paul)
> * added the suggested trivial cleanup patch:
> gianfar: gfar_process_frame returns void
> * provided "long logs" with detailed comments and explanations
Series applied, thanks.
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2013-02-14
From: David Miller @ 2013-02-14 18:30 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1360842447-3344-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 14 Feb 2013 12:47:20 +0100
> 1) Remove a duplicated call to skb_orphan() in pf_key, from Cong Wang.
>
> 2) Prepare xfrm and pf_key for algorithms without pf_key support,
> from Jussi Kivilinna.
>
> 3) Fix an unbalanced lock in xfrm_output_one(), from Li RongQing.
>
> 4) Add an IPsec state resolution packet queue to handle
> packets that are send before the states are resolved.
>
> 5) xfrm4_policy_fini() is unused since 2.6.11, time to remove it.
> From Michal Kubecek.
>
> 6) The xfrm gc threshold was configurable just in the initial
> namespace, make it configurable in all namespaces. From
> Michal Kubecek.
>
> 7) We currently can not insert policies with mark and mask
> such that some flows would be matched from both policies.
> Allow this if the priorities of these policies are different,
> the one with the higher priority is used in this case.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [Patch net-next] bridge: make ifla_br_policy and br_af_ops static
From: David Miller @ 2013-02-14 18:28 UTC (permalink / raw)
To: amwang; +Cc: netdev, vyasevic, stephen
In-Reply-To: <1360821432-28155-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 14 Feb 2013 13:57:12 +0800
> From: Cong Wang <amwang@redhat.com>
>
> They are only used within this file.
>
> Cc: Vlad Yasevich <vyasevic@redhat.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: Mugunthan V N @ 2013-02-14 18:26 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-arm-kernel, linux-omap, Mugunthan V N
CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.
Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Changes from Initial Version:
* Changed Tx and Rx EOI seperated so that Tx interrupt will not be cleared
without processing any txpackets so that none of the interrupt are missed
or cleared without processing.
drivers/net/ethernet/ti/cpsw.c | 25 ++++++++++++++++---------
drivers/net/ethernet/ti/davinci_cpdma.c | 4 ++--
drivers/net/ethernet/ti/davinci_cpdma.h | 9 ++++++++-
3 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4ceed6e..7e93df6 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -510,19 +510,21 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
int num_tx, num_rx;
num_tx = cpdma_chan_process(priv->txch, 128);
- num_rx = cpdma_chan_process(priv->rxch, budget);
-
- if (num_rx || num_tx)
- cpsw_dbg(priv, intr, "poll %d rx, %d tx pkts\n",
- num_rx, num_tx);
+ if (num_tx)
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+ num_rx = cpdma_chan_process(priv->rxch, budget);
if (num_rx < budget) {
napi_complete(napi);
cpsw_intr_enable(priv);
- cpdma_ctlr_eoi(priv->dma);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
cpsw_enable_irq(priv);
}
+ if (num_rx || num_tx)
+ cpsw_dbg(priv, intr, "poll %d rx, %d tx pkts\n",
+ num_rx, num_tx);
+
return num_rx;
}
@@ -835,7 +837,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpdma_ctlr_start(priv->dma);
cpsw_intr_enable(priv);
napi_enable(&priv->napi);
- cpdma_ctlr_eoi(priv->dma);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
if (priv->data.dual_emac)
priv->slaves[priv->emac_port].open_stat = true;
@@ -1075,7 +1078,9 @@ static void cpsw_ndo_tx_timeout(struct net_device *ndev)
cpdma_chan_start(priv->txch);
cpdma_ctlr_int_ctrl(priv->dma, true);
cpsw_intr_enable(priv);
- cpdma_ctlr_eoi(priv->dma);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+
}
static struct net_device_stats *cpsw_ndo_get_stats(struct net_device *ndev)
@@ -1094,7 +1099,9 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
cpsw_interrupt(ndev->irq, priv);
cpdma_ctlr_int_ctrl(priv->dma, true);
cpsw_intr_enable(priv);
- cpdma_ctlr_eoi(priv->dma);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+ cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+
}
#endif
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 7d3bffd..68c3418 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -493,9 +493,9 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
return 0;
}
-void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value)
{
- dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+ dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, value);
}
struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
index a97d6ab..ac65033 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -63,6 +63,13 @@ struct cpdma_chan_stats {
u32 teardown_dequeue;
};
+enum {
+ CPDMA_EOI_RX_THRESH = 0,
+ CPDMA_EOI_RX,
+ CPDMA_EOI_TX,
+ CPDMA_EOI_MISC,
+};
+
struct cpdma_ctlr;
struct cpdma_chan;
@@ -88,7 +95,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
int cpdma_chan_process(struct cpdma_chan *chan, int quota);
int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
-void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr);
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value);
int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
bool cpdma_check_free_tx_desc(struct cpdma_chan *chan);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] bgmac: add read of interrupt mask after disabling interrupts
From: David Miller @ 2013-02-14 18:24 UTC (permalink / raw)
To: nlhintz; +Cc: netdev, hauke, zajec5
In-Reply-To: <BLU0-SMTP798071F8F18DD115610285AC0F0@phx.gbl>
From: Nathan Hintz <nlhintz@hotmail.com>
Date: Wed, 13 Feb 2013 21:14:10 -0800
> The specs prescribe an immediate read of the interrupt mask after
> disabling interrupts. This patch updates the driver to match the
> specs.
>
> Signed-off-by: Nathan Hintz <nlhintz@hotmail.com>
Applied to net-next.
Please state clearly, in your Subject line, what tree your patch is
targetted at. In this case "[PATCH net-next] " would have been
an appropriate subject prefix.
^ permalink raw reply
* Re: xen-netback: fix oopes during shutdown and error handling
From: David Miller @ 2013-02-14 18:21 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, ian.campbell, jbeulich, wei.liu, netdev
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 13:18:56 +0000
> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.
>
> They are stable candidants.
Both applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net-next v2] netpoll: add some missing __rcu marks in several places
From: David Miller @ 2013-02-14 18:20 UTC (permalink / raw)
To: amwang; +Cc: netdev, jiri, vyasevic, stephen
In-Reply-To: <1360831039-11418-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 14 Feb 2013 16:37:19 +0800
> From: Cong Wang <amwang@redhat.com>
>
> This fixes sparse warnings like the one below:
>
> drivers/net/team/team.c:953:25: warning: incorrect type in return expression (different address spaces)
> drivers/net/team/team.c:953:25: expected struct netpoll_info *
> drivers/net/team/team.c:953:25: got struct netpoll_info [noderef] <asn:4>*npinfo
>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: Vlad Yasevich <vyasevic@redhat.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
This is a very confusing patch submission.
You're posting a "v2" of a patch but with a completely different Subject
line so that it's hard, without looking into the details of the patch,
to determine what this patch is a "v2" of.
You've also not addressed Stephen's feedback about the lack of an
rcu_dereference() in these routines you've added __rcu annotations
to.
I'm tossing all versions of this patch, therefore.
^ 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