* [PATCH RFC] virtio_net: fix refill related races
From: Michael S. Tsirkin @ 2011-12-07 15:21 UTC (permalink / raw)
To: Amit Shah; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
Fix theoretical races related to refill work:
1. After napi is disabled by ndo_stop, refill work
can run and re-enable it.
2. Refill can reschedule itself, if this happens
it can run after cancel_delayed_work_sync,
and will access device after it is destroyed.
As a solution, add flags to track napi state and
to disable refill, and toggle them on start, stop
and remove; check these flags on refill.
refill work structure and new fields aren't used
on data path, so put them together near the end of
struct virtnet_info.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
RFC only since it's untested at this point.
A bugfix so 3.2 material?
Comments?
drivers/net/virtio_net.c | 57 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f5b3f19..39eb24c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -21,6 +21,7 @@
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/virtio.h>
#include <linux/virtio_net.h>
#include <linux/scatterlist.h>
@@ -68,15 +69,24 @@ struct virtnet_info {
/* Active statistics */
struct virtnet_stats __percpu *stats;
- /* Work struct for refilling if we run low on memory. */
- struct delayed_work refill;
-
/* Chain pages by the private ptr. */
struct page *pages;
/* fragments + linear part + virtio header */
struct scatterlist rx_sg[MAX_SKB_FRAGS + 2];
struct scatterlist tx_sg[MAX_SKB_FRAGS + 2];
+
+ /* Work struct for refilling if we run low on memory. */
+ struct delayed_work refill;
+
+ /* Set flag to allow delayed refill work, protected by a refill_lock. */
+ bool refill_enable;
+
+ /* Whether napi is enabled, protected by a refill_lock. */
+ bool napi_enable;
+
+ /* Lock to protect refill and napi enable/disable operations. */
+ struct mutex refill_lock;
};
struct skb_vnet_hdr {
@@ -477,20 +487,35 @@ static void virtnet_napi_enable(struct virtnet_info *vi)
}
}
+static void virtnet_refill_enable(struct virtnet_info *vi, bool enable)
+{
+ mutex_lock(&vi->refill_lock);
+ vi->refill_enable = enable;
+ mutex_unlock(&vi->refill_lock);
+}
+
static void refill_work(struct work_struct *work)
{
struct virtnet_info *vi;
bool still_empty;
vi = container_of(work, struct virtnet_info, refill.work);
- napi_disable(&vi->napi);
- still_empty = !try_fill_recv(vi, GFP_KERNEL);
- virtnet_napi_enable(vi);
- /* In theory, this can happen: if we don't get any buffers in
- * we will *never* try to fill again. */
- if (still_empty)
- schedule_delayed_work(&vi->refill, HZ/2);
+ mutex_lock(&vi->refill_lock);
+ if (vi->refill_enable) {
+ if (vi->napi_enable)
+ napi_disable(&vi->napi);
+ still_empty = !try_fill_recv(vi, GFP_KERNEL);
+ if (vi->napi_enable)
+ virtnet_napi_enable(vi);
+
+ /* In theory, this can happen: if we don't get any buffers in
+ * we will *never* try to fill again. */
+ if (still_empty)
+ schedule_delayed_work(&vi->refill, HZ/2);
+
+ }
+ mutex_unlock(&vi->refill_lock);
}
static int virtnet_poll(struct napi_struct *napi, int budget)
@@ -708,7 +733,10 @@ static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
+ mutex_lock(&vi->refill_lock);
+ vi->napi_enable = true;
virtnet_napi_enable(vi);
+ mutex_unlock(&vi->refill_lock);
return 0;
}
@@ -761,7 +789,10 @@ static int virtnet_close(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
+ mutex_lock(&vi->refill_lock);
+ vi->napi_enable = false;
napi_disable(&vi->napi);
+ mutex_unlock(&vi->refill_lock);
return 0;
}
@@ -1010,6 +1041,7 @@ static int virtnet_probe(struct virtio_device *vdev)
if (vi->stats == NULL)
goto free;
+ mutex_init(&vi->refill_lock);
INIT_DELAYED_WORK(&vi->refill, refill_work);
sg_init_table(vi->rx_sg, ARRAY_SIZE(vi->rx_sg));
sg_init_table(vi->tx_sg, ARRAY_SIZE(vi->tx_sg));
@@ -1047,6 +1079,8 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_vqs;
}
+ virtnet_refill_enable(vi, true);
+
/* Last of all, set up some receive buffers. */
try_fill_recv(vi, GFP_KERNEL);
@@ -1107,10 +1141,11 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
{
struct virtnet_info *vi = vdev->priv;
+ virtnet_refill_enable(vi, false);
+
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
-
unregister_netdev(vi->dev);
cancel_delayed_work_sync(&vi->refill);
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Mike Maxim @ 2011-12-07 15:24 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov
In-Reply-To: <20111207113038.GA18166@1984>
The reason I put that in is because the size of that table becomes
more relevant/important if you decide to use the weights in the manner
the patch lets you. It would be conceivable that someone might need to
increase the size of that table to accommodate their configuration, so
I thought it would be handy to be able to do that through the regular
configuration system instead of editing the source.
On Wed, Dec 7, 2011 at 6:30 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Wed, Dec 07, 2011 at 05:07:03PM +0900, Simon Horman wrote:
>> From: Michael Maxim <mike@okcupid.com>
>>
>> Modify the algorithm to build the source hashing hash table to add
>> extra slots for destinations with higher weight. This has the effect
>> of allowing an IPVS SH user to give more connections to hosts that
>> have been configured to have a higher weight.
>>
>> Signed-off-by: Michael Maxim <mike@okcupid.com>
>> Signed-off-by: Simon Horman <horms@verge.net.au>
>> ---
>> net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
>> net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
>> 2 files changed, 33 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
>> index 70bd1d0..af4c0b8 100644
>> --- a/net/netfilter/ipvs/Kconfig
>> +++ b/net/netfilter/ipvs/Kconfig
>> @@ -232,6 +232,21 @@ config IP_VS_NQ
>> If you want to compile it in kernel, say Y. To compile it as a
>> module, choose M here. If unsure, say N.
>>
>> +comment 'IPVS SH scheduler'
>> +
>> +config IP_VS_SH_TAB_BITS
>> + int "IPVS source hashing table size (the Nth power of 2)"
>> + range 4 20
>> + default 8
>> + ---help---
>> + The source hashing scheduler maps source IPs to destinations
>> + stored in a hash table. This table is tiled by each destination
>> + until all slots in the table are filled. When using weights to
>> + allow destinations to receive more connections, the table is
>> + tiled an amount proportional to the weights specified. The table
>> + needs to be large enough to effectively fit all the destinations
>> + multiplied by their respective weights.
>
> Hm, does this really belong to this patch?
>
>> +
>> comment 'IPVS application helper'
>>
>> config IP_VS_FTP
>> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
>> index 33815f4..e0ca520 100644
>> --- a/net/netfilter/ipvs/ip_vs_sh.c
>> +++ b/net/netfilter/ipvs/ip_vs_sh.c
>> @@ -30,6 +30,11 @@
>> * server is dead or overloaded, the load balancer can bypass the cache
>> * server and send requests to the original server directly.
>> *
>> + * The weight destination attribute can be used to control the
>> + * distribution of connections to the destinations in servernode. The
>> + * greater the weight, the more connections the destination
>> + * will receive.
>> + *
>> */
>>
>> #define KMSG_COMPONENT "IPVS"
>> @@ -99,9 +104,11 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
>> struct ip_vs_sh_bucket *b;
>> struct list_head *p;
>> struct ip_vs_dest *dest;
>> + int d_count;
>>
>> b = tbl;
>> p = &svc->destinations;
>> + d_count = 0;
>> for (i=0; i<IP_VS_SH_TAB_SIZE; i++) {
>> if (list_empty(p)) {
>> b->dest = NULL;
>> @@ -113,14 +120,23 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
>> atomic_inc(&dest->refcnt);
>> b->dest = dest;
>>
>> - p = p->next;
>> + IP_VS_DBG_BUF(6, "assigned i: %d dest: %s weight: %d\n",
>> + i, IP_VS_DBG_ADDR(svc->af, &dest->addr),
>> + atomic_read(&dest->weight));
>> +
>> + /* Don't move to next dest until filling weight */
>> + if (++d_count >= atomic_read(&dest->weight)) {
>> + p = p->next;
>> + d_count = 0;
>> + }
>> +
>> }
>> b++;
>> }
>> +
>> return 0;
>> }
>>
>> -
>
> While at it, would you remove this unnecessary deletions/additions.
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] macvtap: Fix macvtap_get_queue to use rxhash first
From: Michael S. Tsirkin @ 2011-12-07 16:10 UTC (permalink / raw)
To: David Miller; +Cc: krkumar2, arnd, netdev, virtualization, levinsasha928
In-Reply-To: <20111125.013552.1613051198566054931.davem@davemloft.net>
On Fri, Nov 25, 2011 at 01:35:52AM -0500, David Miller wrote:
> From: Krishna Kumar2 <krkumar2@in.ibm.com>
> Date: Fri, 25 Nov 2011 09:39:11 +0530
>
> > Jason Wang <jasowang@redhat.com> wrote on 11/25/2011 08:51:57 AM:
> >>
> >> My description is not clear again :(
> >> I mean the same vhost thead:
> >>
> >> vhost thread #0 transmits packets of flow A on processor M
> >> ...
> >> vhost thread #0 move to another process N and start to transmit packets
> >> of flow A
> >
> > Thanks for clarifying. Yes, binding vhosts to CPU's
> > makes the incoming packet go to the same vhost each
> > time. BTW, are you doing any binding and/or irqbalance
> > when you run your tests? I am not running either at
> > this time, but thought both might be useful.
>
> So are we going with this patch or are we saying that vhost binding
> is a requirement?
OK we didn't come to a conclusion so I would be inclined
to merge this patch as is for 3.2, and revisit later.
One question though: do these changes affect userspace
in any way? For example, will this commit us to
ensure that a single flow gets a unique hash even
for strange configurations that transmit the same flow
from multiple cpus?
--
MST
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Mark Lord @ 2011-12-07 16:21 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1323193537.2772.9.camel@bwh-desktop>
On 11-12-06 12:45 PM, Ben Hutchings wrote:
> On Tue, 2011-12-06 at 07:44 -0500, Mark Lord wrote:
>> On 11-12-05 10:18 AM, Ben Hutchings wrote:
>>> On Mon, 2011-12-05 at 09:41 -0500, Mark Lord wrote:
..
>>> If this hardware recognises specific protocols and works out the offsets
>>> itself, then you must claim NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM instead.
>>
>> Yeah, the hardware seems to understand quite a few protocol formats.
>> Okay, so I'll claim the protocol-specific flags in net->hw_features.
>>
>> But what do I use in net->features?
>> The exact same protocol flags,
>> or the generic NETIF_F_HW_CSUM | NETIF_F_RXCSUM ones?
>
> You set the flags for features that are actually being implemented!
>
> But do set NETIF_F_RXCSUM in both places. The network stack doesn't
> know or care exactly what protocols you can do RX checksum validation
> for, so there is only one flag for this. Only the TX checksum
> generation features have to be distinguished.
>
>> The set_features() function also has to test for flags
>> to know what to do. Should it test specific protocol flags,
>> or just the generic two ?
>
> Think it through.
..
Heh.. my thinking side says to use the exact same protocol-specific flags
in both "hw_features" and "features", and therefore check for those flags
inside the "set_features()" function.
But that's not what earlier versions of this driver did,
and nor what the vendor's driver does.
Those versions all mix the protocol-specific and generic flags.
thus my confusion.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Ben Hutchings @ 2011-12-07 16:27 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4EDF9293.8070809@teksavvy.com>
On Wed, 2011-12-07 at 11:21 -0500, Mark Lord wrote:
> On 11-12-06 12:45 PM, Ben Hutchings wrote:
> > On Tue, 2011-12-06 at 07:44 -0500, Mark Lord wrote:
> >> On 11-12-05 10:18 AM, Ben Hutchings wrote:
> >>> On Mon, 2011-12-05 at 09:41 -0500, Mark Lord wrote:
> ..
> >>> If this hardware recognises specific protocols and works out the offsets
> >>> itself, then you must claim NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM instead.
> >>
> >> Yeah, the hardware seems to understand quite a few protocol formats.
> >> Okay, so I'll claim the protocol-specific flags in net->hw_features.
> >>
> >> But what do I use in net->features?
> >> The exact same protocol flags,
> >> or the generic NETIF_F_HW_CSUM | NETIF_F_RXCSUM ones?
> >
> > You set the flags for features that are actually being implemented!
> >
> > But do set NETIF_F_RXCSUM in both places. The network stack doesn't
> > know or care exactly what protocols you can do RX checksum validation
> > for, so there is only one flag for this. Only the TX checksum
> > generation features have to be distinguished.
> >
> >> The set_features() function also has to test for flags
> >> to know what to do. Should it test specific protocol flags,
> >> or just the generic two ?
> >
> > Think it through.
> ..
>
> Heh.. my thinking side says to use the exact same protocol-specific flags
> in both "hw_features" and "features", and therefore check for those flags
> inside the "set_features()" function.
Right.
> But that's not what earlier versions of this driver did,
> and nor what the vendor's driver does.
> Those versions all mix the protocol-specific and generic flags.
The in-tree driver doesn't seem to have ever enabled checksum offload
features.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: atl1c: WARNING: at net/sched/sch_generic.c:255 dev_watchdog
From: Borislav Petkov @ 2011-12-07 16:32 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, LKML
In-Reply-To: <CA+5PVA7bM8ZGaCiyZdHcMVccJYh2=bk-gsHLo9ZmBP_SYT208w@mail.gmail.com>
On Tue, Dec 06, 2011 at 07:12:21PM -0500, Josh Boyer wrote:
> On Tue, Dec 6, 2011 at 6:27 PM, Borislav Petkov <bp@alien8.de> wrote:
> > Hi,
> >
> > this seems like a pretty old issue judging by a quick net search. It
> > still triggers on latest -rc4 here, below the whole trace. I'm willing
> > to test patches :).
> >
> > [14622.820555] atl1c 0000:02:00.0: atl1c: eth0 NIC Link is Up<100 Mbps Full Duplex>
> > [14632.816280] ------------[ cut here ]------------
> > [14632.816314] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x237/0x240()
> > [14632.816323] Hardware name: 30515QG
> > [14632.816332] NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
>
> Matthew Garrett has a patch to the atl1c driver that changed it's ASPM
> behavior that seemed to help. Dave Miller applied it, but I don't see
> it in linux-next for some reason.
Yeah, he reverted them due to build issues. I'm not sure they'll be
coming back though, judging by the thread.
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* [PATCH 2/2] e1000: cleanup CE4100 MDIO registers access
From: Florian Fainelli @ 2011-12-07 16:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: e1000-devel, netdev, Florian Fainelli
In-Reply-To: <1323276062-10906-1-git-send-email-ffainelli@freebox.fr>
A global variable is currently used to hold the virtual address of the
CE4100 MDIO base register address. Store the address in the e1000_hw
structure and update macros accordingly.
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
---
drivers/net/ethernet/intel/e1000/e1000_hw.h | 4 ++--
drivers/net/ethernet/intel/e1000/e1000_main.c | 14 ++++----------
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.h b/drivers/net/ethernet/intel/e1000/e1000_hw.h
index cf7e3c0..f6c4d7e 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.h
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.h
@@ -812,8 +812,7 @@ struct e1000_ffvt_entry {
#define E1000_FLA 0x0001C /* Flash Access - RW */
#define E1000_MDIC 0x00020 /* MDI Control - RW */
-extern void __iomem *ce4100_gbe_mdio_base_virt;
-#define INTEL_CE_GBE_MDIO_RCOMP_BASE (ce4100_gbe_mdio_base_virt)
+#define INTEL_CE_GBE_MDIO_RCOMP_BASE (hw->ce4100_gbe_mdio_base_virt)
#define E1000_MDIO_STS (INTEL_CE_GBE_MDIO_RCOMP_BASE + 0)
#define E1000_MDIO_CMD (INTEL_CE_GBE_MDIO_RCOMP_BASE + 4)
#define E1000_MDIO_DRV (INTEL_CE_GBE_MDIO_RCOMP_BASE + 8)
@@ -1343,6 +1342,7 @@ struct e1000_hw_stats {
struct e1000_hw {
u8 __iomem *hw_addr;
u8 __iomem *flash_address;
+ void __iomem *ce4100_gbe_mdio_base_virt;
e1000_mac_type mac_type;
e1000_phy_type phy_type;
u32 phy_init_script;
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 7bb3337..39d3178 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -33,11 +33,6 @@
#include <linux/bitops.h>
#include <linux/if_vlan.h>
-/* Intel Media SOC GbE MDIO physical base address */
-static unsigned long ce4100_gbe_mdio_base_phy;
-/* Intel Media SOC GbE MDIO virtual base address */
-void __iomem *ce4100_gbe_mdio_base_virt;
-
char e1000_driver_name[] = "e1000";
static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver";
#define DRV_VERSION "7.3.21-k8-NAPI"
@@ -1054,11 +1049,10 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
err = -EIO;
if (hw->mac_type == e1000_ce4100) {
- ce4100_gbe_mdio_base_phy = pci_resource_start(pdev, BAR_1);
- ce4100_gbe_mdio_base_virt = ioremap(ce4100_gbe_mdio_base_phy,
+ hw->ce4100_gbe_mdio_base_virt = ioremap(pci_resource_start(pdev, BAR_1),
pci_resource_len(pdev, BAR_1));
- if (!ce4100_gbe_mdio_base_virt)
+ if (!hw->ce4100_gbe_mdio_base_virt)
goto err_mdio_ioremap;
}
@@ -1249,7 +1243,7 @@ err_eeprom:
err_dma:
err_sw_init:
err_mdio_ioremap:
- iounmap(ce4100_gbe_mdio_base_virt);
+ iounmap(hw->ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
err_ioremap:
free_netdev(netdev);
@@ -1287,7 +1281,7 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
kfree(adapter->rx_ring);
if (hw->mac_type == e1000_ce4100)
- iounmap(ce4100_gbe_mdio_base_virt);
+ iounmap(hw->ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
if (hw->flash_address)
iounmap(hw->flash_address);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] e1000: unmap ce4100_gbe_mdio_base_virt in e1000_remove
From: Florian Fainelli @ 2011-12-07 16:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: e1000-devel, netdev, Florian Fainelli
We are not unmapping ce4100_gbe_mdio_base_virt in exit path in case
we are running on a CE4100 adapter, fix that.
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 82f4ef1..7bb3337 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1286,6 +1286,8 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
kfree(adapter->tx_ring);
kfree(adapter->rx_ring);
+ if (hw->mac_type == e1000_ce4100)
+ iounmap(ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
if (hw->flash_address)
iounmap(hw->flash_address);
--
1.7.5.4
^ permalink raw reply related
* [11/27] gro: reset vlan_tci on reuse
From: Greg KH @ 2011-12-07 16:54 UTC (permalink / raw)
To: linux-kernel, stable, davem
Cc: torvalds, akpm, alan, netdev, Jesse Gross, Benjamin Poirier
In-Reply-To: <20111207165611.GA19872@kroah.com>
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
This one liner is part of upstream
commit 3701e51382a026cba10c60b03efabe534fba4ca4
Author: Jesse Gross <jesse@nicira.com>
vlan: Centralize handling of hardware acceleration.
The bulk of that commit is a rework of the hardware assisted vlan tagging
driver interface, and as such doesn't classify for -stable inclusion. The fix
that is needed is a part of that commit but can work independently of the
rest.
This patch can avoid panics on the 2.6.32.y -stable kernels and is in the same
spirit as mainline commits
66c46d7 gro: Reset dev pointer on reuse
6d152e2 gro: reset skb_iif on reuse
which are already in -stable.
For drivers using the vlan_gro_frags() interface, a packet with an invalid tci
leads to GRO_DROP and napi_reuse_skb(). The skb has to be sanitized before
being reused or we may send an skb with an invalid vlan_tci field up the stack
where it is not expected.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Cc: Jesse Gross <jesse@nicira.com>
Acked-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2614,6 +2614,7 @@ void napi_reuse_skb(struct napi_struct *
{
__skb_pull(skb, skb_headlen(skb));
skb_reserve(skb, NET_IP_ALIGN - skb_headroom(skb));
+ skb->vlan_tci = 0;
skb->dev = napi->dev;
skb->iif = 0;
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Mark Lord @ 2011-12-07 16:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1323275233.2728.3.camel@bwh-desktop>
On 11-12-07 11:27 AM, Ben Hutchings wrote:
> On Wed, 2011-12-07 at 11:21 -0500, Mark Lord wrote:
..
>> Heh.. my thinking side says to use the exact same protocol-specific flags
>> in both "hw_features" and "features", and therefore check for those flags
>> inside the "set_features()" function.
>
> Right.
Thanks.
Now now we have:
static int ax88772b_set_features(struct net_device *netdev, u32 features)
{
struct usbnet *dev = netdev_priv(netdev);
u16 tx_csum = 0, rx_csum = 0;
if (features & NETIF_F_IP_CSUM)
tx_csum |= AX_TXCOE_TCP | AX_TXCOE_UDP;
if (features & NETIF_F_IPV6_CSUM)
tx_csum |= AX_TXCOE_TCPV6 | AX_TXCOE_UDPV6;
if (features & NETIF_F_RXCSUM)
rx_csum = AX_RXCOE_DEF_CSUM;
ax8817x_write_cmd(dev, AX_CMD_WRITE_TXCOE_CTL, tx_csum, 0, 0, NULL);
ax8817x_write_cmd(dev, AX_CMD_WRITE_RXCOE_CTL, rx_csum, 0, 0, NULL);
return 0;
}
static int ax88772b_bind(struct usbnet *dev, struct usb_interface *intf)
{
...
/* enable hardware checksums */
dev->net->hw_features |=
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM;
dev->net->features |=
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM;
ax88772b_set_features(dev->net, dev->net->features);
...
}
^ permalink raw reply
* Re: [net-next RFC PATCH 0/5] Series short description
From: Ben Hutchings @ 2011-12-07 17:02 UTC (permalink / raw)
To: Jason Wang, Rusty Russell
Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928
In-Reply-To: <4EDF4E82.7050201@redhat.com>
On Wed, 2011-12-07 at 19:31 +0800, Jason Wang wrote:
> On 12/07/2011 03:30 PM, Rusty Russell wrote:
> > On Mon, 05 Dec 2011 16:58:37 +0800, Jason Wang<jasowang@redhat.com> wrote:
> >> multiple queue virtio-net: flow steering through host/guest cooperation
> >>
> >> Hello all:
> >>
> >> This is a rough series adds the guest/host cooperation of flow
> >> steering support based on Krish Kumar's multiple queue virtio-net
> >> driver patch 3/3 (http://lwn.net/Articles/467283/).
> > Is there a real (physical) device which does this kind of thing? How do
> > they do it? Can we copy them?
> >
> > Cheers,
> > Rusty.
> As far as I see, ixgbe and sfc have similar but much more sophisticated
> mechanism.
>
> The idea was originally suggested by Ben and it was just borrowed form
> those real physical nic cards who can dispatch packets based on their
> hash. All of theses cards can filter the flow based on the hash of
> L2/L3/L4 header and the stack would tell the card which queue should
> this flow goes.
Solarflare controllers (sfc driver) have 8192 perfect filters for
TCP/IPv4 and UDP/IPv4 which can be used for flow steering. (The filters
are organised as a hash table, but matched based on 5-tuples.) I
implemented the 'accelerated RFS' interface in this driver.
I believe the Intel 82599 controllers (ixgbe driver) have both
hash-based and perfect filter modes and the driver can be configured to
use one or the other. The driver has its own independent mechanism for
steering RX and TX flows which predates RFS; I don't know whether it
uses hash-based or perfect filters.
Most multi-queue controllers could support a kind of hash-based
filtering for TCP/IP by adjusting the RSS indirection table. However,
this table is usually quite small (64-256 entries). This means that
hash collisions will be quite common and this can result in reordering.
The same applies to the small table Jason has proposed for virtio-net.
> So in host, a simple hash to queue table were introduced in tap/macvtap
> and in guest, the guest driver would tell the desired queue of a flow
> through changing this table.
I don't think accelerated RFS can work well without the use of perfect
filtering or hash-based filtering with a very low rate of collisions.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Ben Hutchings @ 2011-12-07 17:03 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4EDF9B5F.6050500@teksavvy.com>
On Wed, 2011-12-07 at 11:59 -0500, Mark Lord wrote:
> On 11-12-07 11:27 AM, Ben Hutchings wrote:
> > On Wed, 2011-12-07 at 11:21 -0500, Mark Lord wrote:
> ..
> >> Heh.. my thinking side says to use the exact same protocol-specific flags
> >> in both "hw_features" and "features", and therefore check for those flags
> >> inside the "set_features()" function.
> >
> > Right.
>
>
> Thanks.
> Now now we have:
>
> static int ax88772b_set_features(struct net_device *netdev, u32 features)
> {
> struct usbnet *dev = netdev_priv(netdev);
> u16 tx_csum = 0, rx_csum = 0;
>
> if (features & NETIF_F_IP_CSUM)
> tx_csum |= AX_TXCOE_TCP | AX_TXCOE_UDP;
> if (features & NETIF_F_IPV6_CSUM)
> tx_csum |= AX_TXCOE_TCPV6 | AX_TXCOE_UDPV6;
> if (features & NETIF_F_RXCSUM)
> rx_csum = AX_RXCOE_DEF_CSUM;
> ax8817x_write_cmd(dev, AX_CMD_WRITE_TXCOE_CTL, tx_csum, 0, 0, NULL);
> ax8817x_write_cmd(dev, AX_CMD_WRITE_RXCOE_CTL, rx_csum, 0, 0, NULL);
> return 0;
> }
>
> static int ax88772b_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> ...
>
> /* enable hardware checksums */
> dev->net->hw_features |=
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM;
> dev->net->features |=
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM;
> ax88772b_set_features(dev->net, dev->net->features);
> ...
> }
Not knowing the hardware, that looks plausible...
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 1/2] bnx2x: dont handle storage drv_info req if no cnic
From: Joe Perches @ 2011-12-07 17:04 UTC (permalink / raw)
To: Barak Witkowski; +Cc: davem, netdev, Eilon Greenstein
In-Reply-To: <1323265536-9760-1-git-send-email-barak@broadcom.com>
On Wed, 2011-12-07 at 15:45 +0200, Barak Witkowski wrote:
> This patch returns ACK with zeroed buffer to FW upon fcoe/iscsi drv_info
> request if cnic is not defined. This is better handling in comparison to
> send NACK to FW upon such request, as it's a valid request.
Hi Barak.
Other than the good comment,
I think this patch isn't useful.
It adds maintenance overhead.
It just adds more #ifdefs.
gcc should remove the call to the
empty static void funcs.
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Barak Witkowski <barak@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> index 418e7d3..d104695 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -2941,9 +2941,9 @@ static void bnx2x_drv_info_ether_stat(struct bnx2x *bp)
> ether_stat->rxq_size = bp->rx_ring_size;
> }
>
> +#ifdef BCM_CNIC
> static void bnx2x_drv_info_fcoe_stat(struct bnx2x *bp)
> {
> -#ifdef BCM_CNIC
> struct bnx2x_dcbx_app_params *app = &bp->dcbx_port_params.app;
> struct fcoe_stats_info *fcoe_stat =
> &bp->slowpath->drv_info_to_mcp.fcoe_stat;
> @@ -3029,12 +3029,12 @@ static void bnx2x_drv_info_fcoe_stat(struct bnx2x *bp)
>
> /* ask L5 driver to add data to the struct */
> bnx2x_cnic_notify(bp, CNIC_CTL_FCOE_STATS_GET_CMD);
> -#endif
> }
> +#endif
>
> +#ifdef BCM_CNIC
> static void bnx2x_drv_info_iscsi_stat(struct bnx2x *bp)
> {
> -#ifdef BCM_CNIC
> struct bnx2x_dcbx_app_params *app = &bp->dcbx_port_params.app;
> struct iscsi_stats_info *iscsi_stat =
> &bp->slowpath->drv_info_to_mcp.iscsi_stat;
> @@ -3046,8 +3046,8 @@ static void bnx2x_drv_info_iscsi_stat(struct bnx2x *bp)
>
> /* ask L5 driver to add data to the struct */
> bnx2x_cnic_notify(bp, CNIC_CTL_ISCSI_STATS_GET_CMD);
> -#endif
> }
> +#endif
>
> /* called due to MCP event (on pmf):
> * reread new bandwidth configuration
> @@ -3091,10 +3091,14 @@ static void bnx2x_handle_drv_info_req(struct bnx2x *bp)
> bnx2x_drv_info_ether_stat(bp);
> break;
> case FCOE_STATS_OPCODE:
> +#ifdef BCM_CNIC
> bnx2x_drv_info_fcoe_stat(bp);
> +#endif
> break;
> case ISCSI_STATS_OPCODE:
> +#ifdef BCM_CNIC
> bnx2x_drv_info_iscsi_stat(bp);
> +#endif
> break;
> default:
> /* if op code isn't supported - send NACK */
^ permalink raw reply
* Re: [PATCH v3 1/2] net/macb: add DT support for Cadence macb/gem driver
From: David Miller @ 2011-12-07 18:27 UTC (permalink / raw)
To: nicolas.ferre
Cc: netdev, devicetree-discuss, linux-kernel, grant.likely, jamie,
plagnioj, linux-arm-kernel
In-Reply-To: <714ca7492d8d45b50eab34448c4b70933ce5701c.1323086095.git.nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Mon, 5 Dec 2011 12:59:52 +0100
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> Allow the device tree to provide the mac address and the phy mode.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> [nicolas.ferre@atmel.com: change "compatible" node property, doc and DT hwaddr]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> [jamie@jamieiles.com: add "gem" compatibility strings and doc]
> Acked-by: Jamie Iles<jamie@jamieiles.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: bridge: HSR support
From: Arvid Brodin @ 2011-12-07 18:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20111206152745.7dd6bc1c@nehalam.linuxnetplumber.net>
Stephen Hemminger wrote:
> On Wed, 7 Dec 2011 00:23:21 +0100
> Arvid Brodin <arvid.brodin@enea.com> wrote:
>
>> Stephen Hemminger wrote:
>>> On Fri, 28 Oct 2011 17:34:18 +0200
>>> Arvid Brodin <arvid.brodin@enea.com> wrote:
>>>
>>>> Ok, so after a lot of reading and looking through code I have this idea of a
>>>> standalone solution:
>>>>
>>>> 1) Add ioctls to create (and remove) "hsr" netdevs which encapsulates two
>>>> physical Ethernet interfaces each (somewhat like the bridge code does, but
>>>> with precisely 2 interfaces slaved).
>>> Please use the newer netlink interface and the master attribute for this
>>> rather than inventing yet another ioctl.
>>
>> Is the rtnl interface documented anywhere (the usage of the different IFLA_
>> flags etc.)? Specifically: how do I use the IFLA_MASTER flag (what's the
>> meaning of the 32-bit data it wants, and how is it used by the kernel)? I
>> haven't been very successful figuring this out by looking at the kernel code.
>
>
> Look at bridging or bonding.
Believe me, I have! :) Turns out IFLA_MASTER is actually handled in net/core/rtnetlink.c.
Although the message is sent to the slave device, the functions called are the
master device's ndo_{add,del}_slave(). Looking at the bridging and bonding
implementations br_add_slave() and bond_enslave() and the functions they call,
it all boils down mostly to
* netdev_set_master() which assigns slave_dev->master = master_dev.
* bonding also set IFF_SLAVE on the slave.
* netdev_rx_handler_register(slave_dev, ). "This handler will then be called
from __netif_receive_skb."
So far so good, but:
* I don't know the meaning of the IFF_SLAVE flag. It's referenced all over the place
(core, vlan, bonding, ipv6, eql). Do I need to/want to set this?
* I don't know the effects of setting dev->master. Do I need/want this?
* I don't want to forward all ingress frames on the slave devices to my master
device; I only want the ones with protocol 0x88FB to be forwarded (other
frames should be received by the slaves as normal). I think I already have this
covered by registering a protocol handler (using dev_add_pack(packet_type)).
So perhaps calling netdev_rx_handler_register() is not necessary in my case?
* As far as I can see, neither bridging nor bonding is handled by the ip program
(iproute2 suite)? I.e. no examples of binding more than one interface to a
virtual interface when it comes to which messages to send, etc. VLAN uses
IFLA_IFNAME (name of the vlan link), IFLA_LINK (physical link behind the vlan
link), and some IFLA_VLAN-specific messages.
What I want to do is to atomically (from a user space perspective) create the
HSR bonding, i.e.:
# ip link add name hsr0 type hsr slave1 slave2
I have written a hsr "plugin" to iproute2 that accepts these parameters, I'm
just not sure how to tell the kernel about them. Perhaps then I should define
my own IFLA_HSR_UNSPEC, IFLA_HSR_SLAVE1, IFLA_HSR_SLAVE2 messages?
>> Also, how do I best tell the kernel which my slave devices are when creating
>> the hsr device? Should I create my own IFLA_HSR_UNSPEC, etc, or can I use some
>> of the generic flags?
>
> Look at macvlan, vlan, or bridging. There this is done by processing a newlink
> message.
macvlan and vlan both use IFLA_LINK to tell the kernel about their single
underlying "real" device. None of these use more than one underlying device.
Bridging does not implement newlink at all (uses ioctls, I think).
>> Oh, and the kernel (struct rtnl_link_ops).newlink method has two (struct
>> nlattr *[]) params: tb and data. What are their roles?
>>
Heh, I just realised that the difference is that "tb" contains generic (IFLA_)
message data and "data" contains specific (e.g. IFLA_VLAN_) message data.
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply
* Re: [PATCH v2 0/8][NET] fec.c: several cleanups and bugfixes
From: David Miller @ 2011-12-07 18:38 UTC (permalink / raw)
To: LW; +Cc: netdev, linux-kernel, shawn.guo
In-Reply-To: <cover.1323256319.git.LW@KARO-electronics.de>
From: Lothar Waßmann <LW@KARO-electronics.de>
Date: Wed, 7 Dec 2011 14:37:12 +0100
> The following set of patches provides some cleanup and bugfixes for
> drivers/net/ethernet/freescale/fec.c and makes the driver buildable as
> a module.
1) I said to use a subject prefix of "fec: " not "fec.c: "
2) You did not integrate Shawn's "Acked-by: " tags, I'm not going to
go sifting through the previous patch postings to collect them up,
that's your job.
^ permalink raw reply
* Re: [PATCH] ppp: fix pptp double release_sock in pptp_bind()
From: David Miller @ 2011-12-07 18:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: tixxdz, xeb, netdev, linux-kernel
In-Reply-To: <1323233994.2690.29.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 07 Dec 2011 05:59:54 +0100
> Le mercredi 07 décembre 2011 à 02:47 +0100, Djalal Harouni a écrit :
>> Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
...
> Nice catch !
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: fix typo in fcoe stats collection
From: David Miller @ 2011-12-07 18:39 UTC (permalink / raw)
To: barak; +Cc: netdev, eilong
In-Reply-To: <1323265536-9760-2-git-send-email-barak@broadcom.com>
From: "Barak Witkowski" <barak@broadcom.com>
Date: Wed, 7 Dec 2011 15:45:36 +0200
> Signed-off-by: Barak Witkowski <barak@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/fec: fix the use of pdev->id
From: David Miller @ 2011-12-07 18:38 UTC (permalink / raw)
To: shawn.guo; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1323097275-7846-1-git-send-email-shawn.guo@linaro.org>
From: Shawn Guo <shawn.guo@linaro.org>
Date: Mon, 5 Dec 2011 23:01:15 +0800
> The pdev->id is used in several places for different purpose. All
> these uses assume it's always the id of fec device which is >= 0.
> However this is only true for non-DT case. When DT plays, pdev->id
> is always -1, which will break these pdev->id users.
>
> Instead of fixing all these users one by one, this patch introduces
> a new member 'dev_id' to 'struct fec_enet_private' for holding the
> correct fec device id, and replaces all the existing uses of pdev->id
> with this dev_id.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Applied.
^ permalink raw reply
* Re: [Patch V2 ] net: doc: cleanup Documentation/networking/scaling.txt
From: David Miller @ 2011-12-07 18:40 UTC (permalink / raw)
To: shanwei88; +Cc: rdunlap, willemb, benjamin.poirier, therbert, linux-doc, netdev
In-Reply-To: <4EDF77A9.4040808@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Wed, 07 Dec 2011 22:26:49 +0800
>
> 1) Fix some typos.
> 2) Change mode of the punctuation from full to half, eg.’,“ .
> So that the punctuation can be read at console.
>
> Signed-off-by: Shan Wei<shanwei88@gmail.com>
> ---
> v2: fix the broken in patchwork.
>
It's still broken, your email setup has some very serious issues as of late.
I don't know if it's the encoding you use or something else but you
must fix this before submitting any more patches.
^ permalink raw reply
* Re: [PATCH net-next 1/2] bnx2x: dont handle storage drv_info req if no cnic
From: David Miller @ 2011-12-07 18:45 UTC (permalink / raw)
To: joe; +Cc: barak, netdev, eilong
In-Reply-To: <1323277440.1762.46.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Wed, 07 Dec 2011 09:04:00 -0800
> On Wed, 2011-12-07 at 15:45 +0200, Barak Witkowski wrote:
>> This patch returns ACK with zeroed buffer to FW upon fcoe/iscsi drv_info
>> request if cnic is not defined. This is better handling in comparison to
>> send NACK to FW upon such request, as it's a valid request.
>
> Hi Barak.
>
> Other than the good comment,
> I think this patch isn't useful.
> It adds maintenance overhead.
>
> It just adds more #ifdefs.
>
> gcc should remove the call to the
> empty static void funcs.
Agreed, I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH net-next 0/3] bridge forwarding database patches
From: David Miller @ 2011-12-07 18:50 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111206230223.191544130@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 06 Dec 2011 15:02:23 -0800
> These three patches address issue of receiving packets when
> bridge mac address is modified.
Doesn't compile:
net/bridge/br_fdb.c: In function ‘br_fdb_update’:
net/bridge/br_fdb.c:447:5: warning: passing argument 1 of ‘fdb_notify’ from incompatible pointer type [enabled by default]
net/bridge/br_fdb.c:31:13: note: expected ‘struct net_bridge *’ but argument is of type ‘struct net_bridge_fdb_entry *’
net/bridge/br_fdb.c:447:5: warning: passing argument 2 of ‘fdb_notify’ makes pointer from integer without a cast [enabled by default]
net/bridge/br_fdb.c:31:13: note: expected ‘const struct net_bridge_fdb_entry *’ but argument is of type ‘int’
net/bridge/br_fdb.c:447:5: error: too few arguments to function ‘fdb_notify’
net/bridge/br_fdb.c:31:13: note: declared here
^ permalink raw reply
* Re: [PATCH] macvtap: Fix macvtap_get_queue to use rxhash first
From: David Miller @ 2011-12-07 18:52 UTC (permalink / raw)
To: mst; +Cc: krkumar2, arnd, netdev, virtualization, levinsasha928
In-Reply-To: <20111207161001.GD23845@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 7 Dec 2011 18:10:02 +0200
> On Fri, Nov 25, 2011 at 01:35:52AM -0500, David Miller wrote:
>> From: Krishna Kumar2 <krkumar2@in.ibm.com>
>> Date: Fri, 25 Nov 2011 09:39:11 +0530
>>
>> > Jason Wang <jasowang@redhat.com> wrote on 11/25/2011 08:51:57 AM:
>> >>
>> >> My description is not clear again :(
>> >> I mean the same vhost thead:
>> >>
>> >> vhost thread #0 transmits packets of flow A on processor M
>> >> ...
>> >> vhost thread #0 move to another process N and start to transmit packets
>> >> of flow A
>> >
>> > Thanks for clarifying. Yes, binding vhosts to CPU's
>> > makes the incoming packet go to the same vhost each
>> > time. BTW, are you doing any binding and/or irqbalance
>> > when you run your tests? I am not running either at
>> > this time, but thought both might be useful.
>>
>> So are we going with this patch or are we saying that vhost binding
>> is a requirement?
>
> OK we didn't come to a conclusion so I would be inclined
> to merge this patch as is for 3.2, and revisit later.
> One question though: do these changes affect userspace
> in any way? For example, will this commit us to
> ensure that a single flow gets a unique hash even
> for strange configurations that transmit the same flow
> from multiple cpus?
Once you sort this out, reply with an Acked-by: for me, thanks.
^ permalink raw reply
* Re: [PATCH] fsl_pq_mdio: Clean up tbi address configuration
From: David Miller @ 2011-12-07 18:55 UTC (permalink / raw)
To: galak; +Cc: afleming, netdev
In-Reply-To: <3FAC1EB0-2606-40BF-9BDF-8D2BCEB003E9@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 6 Dec 2011 23:35:31 -0600
> We need this patch in 3.2 regardless of DT. Currently we get the
> oops on 3.2 on ALL systems. Andy should be working up a device tree
> patch to fix the subset of .dts that are missing the tbi property.
Ok, applied to 'net'.
^ permalink raw reply
* [PATCH 0/3] crypto: Add per-cpu transform helpers
From: Seth Jennings @ 2011-12-07 18:59 UTC (permalink / raw)
To: David S . Miller
Cc: Seth Jennings, linux-crypto, linux-kernel, netdev, Eric Dumazet,
Brian King, Robert Jennings
This patchset includes two new functions for the cryptographic library,
crypto_alloc_percpu_tfms() and crypto_free_percpu_tfms(), which assist users
in allocating and freeing per-cpu transforms.
It also includes typing wrappers for the compression algorithm class.
The reason for this patch is that during my work to enable page compression
via the cryptographic API in the zcache staging driver, and realized that I
had rewritten some per-cpu transform code that already exists in the
xfrm_ipcomp code.
In an effort to avoid duplication, this patchset moves the per-cpu code into
helper functions in the cryptographic library and makes the necessary
modifications to the xfrm_ipcomp code.
After this change is (hopefully) merged, I will submit the zcache driver
changes, which will be the second user of these helpers.
Seth Jennings (3):
crypto: Add per-cpu transform alloc() and free()
crypto: Add inline per-cpu wrappers for compression
xfrm: Modify xfrm_ipcomp code to use new per-cpu helpers
crypto/api.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/crypto.h | 28 +++++++++++++++++++++
net/xfrm/xfrm_ipcomp.c | 34 ++++++--------------------
3 files changed, 98 insertions(+), 26 deletions(-)
--
1.7.5.4
^ 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