* [PATCH 0/5][6lowpan] several fixes for 6lowpan
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel
Dear David,
the following patch-set contains several fixes/improvements for 6lowpan:
1. fix: segmentation fault caused by mlme request
2. impr: move frame allocation code to a separate function
3. fix: clean up fragments list if module unloaded
4. impr: duplicate definition of IEEE802154_ALEN
5. fix: add missing spin_lock_init()
Could you please review them?
With best regards,
Alex
8<--
The following changes since commit ac807fa8e625aff58060876d70298c93a59c4252:
tcp: Fix build warning after tcp_{v4,v6}_init_sock consolidation. (2012-04-23 03:21:58 -0400)
are available in the git repository at:
git://local ..BRANCH.NOT.VERIFIED..
Alexander Smirnov (5):
6lowpan: fix segmentation fault caused by mlme request
6lowpan: move frame allocation code to a separate function
6lowpan: clean up fragments list if module unloaded
6lowpan: duplicate definition of IEEE802154_ALEN
6lowpan: add missing spin_lock_init()
net/ieee802154/6lowpan.c | 125 ++++++++++++++++++++++++++++++++--------------
net/ieee802154/6lowpan.h | 3 -
2 files changed, 88 insertions(+), 40 deletions(-)
^ permalink raw reply
* [PATCH 1/5] 6lowpan: fix segmentation fault caused by mlme request
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add nescesary mlme callbacks to satisfy "iz list" request from user space.
Due to 6lowpan device doesn't have its own phy, mlme implemented as a pipe
to real phy to which 6lowpan is attached.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 58c8895..7ce508f 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1044,6 +1044,24 @@ static void lowpan_dev_free(struct net_device *dev)
free_netdev(dev);
}
+static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_phy(real_dev);
+}
+
+static u16 lowpan_get_pan_id(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_pan_id(real_dev);
+}
+
+static u16 lowpan_get_short_addr(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1053,6 +1071,12 @@ static const struct net_device_ops lowpan_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+static struct ieee802154_mlme_ops lowpan_mlme = {
+ .get_pan_id = lowpan_get_pan_id,
+ .get_phy = lowpan_get_phy,
+ .get_short_addr = lowpan_get_short_addr,
+};
+
static void lowpan_setup(struct net_device *dev)
{
pr_debug("(%s)\n", __func__);
@@ -1070,6 +1094,7 @@ static void lowpan_setup(struct net_device *dev)
dev->netdev_ops = &lowpan_netdev_ops;
dev->header_ops = &lowpan_header_ops;
+ dev->ml_priv = &lowpan_mlme;
dev->destructor = lowpan_dev_free;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/5] 6lowpan: duplicate definition of IEEE802154_ALEN
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
The same macros is defined in 'include/net/af_ieee802154.h' and is called
IEEE802154_ADDR_LEN. No need another one, so remove it.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 4 ++--
net/ieee802154/6lowpan.h | 3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index a57174e..8c1d212 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -196,7 +196,7 @@ lowpan_compress_addr_64(u8 **hc06_ptr, u8 shift, const struct in6_addr *ipaddr,
static void
lowpan_uip_ds6_set_addr_iid(struct in6_addr *ipaddr, unsigned char *lladdr)
{
- memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ALEN);
+ memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ADDR_LEN);
/* second bit-flip (Universe/Local) is done according RFC2464 */
ipaddr->s6_addr[8] ^= 0x02;
}
@@ -221,7 +221,7 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct in6_addr *ipaddr,
if (lladdr)
lowpan_raw_dump_inline(__func__, "linklocal address",
- lladdr, IEEE802154_ALEN);
+ lladdr, IEEE802154_ADDR_LEN);
if (prefcount > 0)
memcpy(ipaddr, prefix, prefcount);
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index aeff3f3..8c2251f 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -53,9 +53,6 @@
#ifndef __6LOWPAN_H__
#define __6LOWPAN_H__
-/* need to know address length to manipulate with it */
-#define IEEE802154_ALEN 8
-
#define UIP_802154_SHORTADDR_LEN 2 /* compressed ipv6 address length */
#define UIP_IPH_LEN 40 /* ipv6 fixed header size */
#define UIP_PROTO_UDP 17 /* ipv6 next header value for UDP */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/5] 6lowpan: add missing spin_lock_init()
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add missing spin_lock_init() for frames list lock.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8c1d212..32eb417 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1183,6 +1183,8 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
list_add_tail(&entry->list, &lowpan_devices);
mutex_unlock(&lowpan_dev_info(dev)->dev_list_mtx);
+ spin_lock_init(&flist_lock);
+
register_netdevice(dev);
return 0;
--
1.7.2.3
^ permalink raw reply related
* Re: [net-next PATCH] net: dcb: add CEE notify calls
From: Shmulik Ravid @ 2012-04-24 12:56 UTC (permalink / raw)
To: John Fastabend; +Cc: davem, netdev, eilong, amirv
In-Reply-To: <20120420194923.8103.54825.stgit@jf-dev1-dcblab>
On Fri, 2012-04-20 at 12:49 -0700, John Fastabend wrote:
> 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>
> ---
>
Acked-by: Shmulik Ravid <shmulikr@broadcom.com>
Thanks John,
Shmulik
^ permalink raw reply
* Re: [PATCH 1/2] e1000e: Disable ASPM L1 on 82574
From: Nix @ 2012-04-24 11:08 UTC (permalink / raw)
To: Chris Boot; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <1335216578-21542-2-git-send-email-bootc@bootc.net>
On 23 Apr 2012, Chris Boot uttered the following:
> ASPM on the 82574 causes trouble. Currently the driver disables L0s for
> this NIC but only disables L1 if the MTU is >1500. This patch simply
> causes L1 to be disabled regardless of the MTU setting.
FWIW, that existing code doesn't actually work in any case. I've been
running with an MTU of 7200 on one such NIC for some time, and L0s and
L1 are definitely enabled, even though the driver says it's turning them
off.
I'll try your patch shortly, probably tomorrow. (Now I only have to
worry about the *other* bug that's been bruited about on this list --
the one where the card locks up if its peer shuts down. It's worrying
because one of my 82574Ls has a peer that's regularly suspended... I
guess I'll try and see if I can reproduce that lockup!)
--
NULL && (void)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
* Dear Subscriber
From: WEB ADMINISTRATOR @ 2012-04-24 12:00 UTC (permalink / raw)
Dear Subscriber,
Due to spam complaints of email users in our webmail system,
our investigation shows that your email address is compromised
and is used to send out spam message in our webmail system.
As a result, our network engineer will be conducting a maintenance in
our webmail system, your Username will be disabled if you do not send
us the required information within 72hrs.
Informations Required:
Your Full Names:
Username:
Password:
Retype Password:
We value your business and thanks for using our Webmail Service.
Maintenance Webmail Team. Webmail Upgrading Service
Email: webmaster2012@admin.in.th
^ permalink raw reply
* [PATCH V3 09/12] net/stmmac: Remove conditional compilation of clk code
From: Viresh Kumar @ 2012-04-24 11:21 UTC (permalink / raw)
To: akpm
Cc: spear-devel, viresh.linux, linux-kernel, linux-arm-kernel,
mturquette, sshtylyov, jgarzik, linux, Viresh Kumar,
Giuseppe Cavallaro, David S. Miller, netdev
In-Reply-To: <cover.1335266056.git.viresh.kumar@st.com>
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
This also fixes error paths of probe(), as a goto is required in this patch.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 41 ---------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 33 +++++++++--------
2 files changed, 17 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index db2de9a..7f85895 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -81,9 +81,7 @@ struct stmmac_priv {
struct stmmac_counters mmc;
struct dma_features dma_cap;
int hw_cap_support;
-#ifdef CONFIG_HAVE_CLK
struct clk *stmmac_clk;
-#endif
int clk_csr;
};
@@ -103,42 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
struct stmmac_priv *stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
void __iomem *addr);
-
-#ifdef CONFIG_HAVE_CLK
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- if (!IS_ERR(priv->stmmac_clk))
- return clk_enable(priv->stmmac_clk);
-
- return 0;
-}
-
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
- if (IS_ERR(priv->stmmac_clk))
- return;
-
- clk_disable(priv->stmmac_clk);
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- priv->stmmac_clk = clk_get(priv->device, NULL);
-
- if (IS_ERR(priv->stmmac_clk))
- return PTR_ERR(priv->stmmac_clk);
-
- return 0;
-}
-#else
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- return 0;
-}
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- return 0;
-}
-#endif /* CONFIG_HAVE_CLK */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a4cf81..bbdcb55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -28,6 +28,7 @@
https://bugzilla.stlinux.com/
*******************************************************************************/
+#include <linux/clk.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/ip.h>
@@ -165,12 +166,8 @@ static void stmmac_verify_args(void)
static void stmmac_clk_csr_set(struct stmmac_priv *priv)
{
-#ifdef CONFIG_HAVE_CLK
u32 clk_rate;
- if (IS_ERR(priv->stmmac_clk))
- return;
-
clk_rate = clk_get_rate(priv->stmmac_clk);
/* Platform provided default clk_csr would be assumed valid
@@ -192,7 +189,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
* we can not estimate the proper divider as it is not known
* the frequency of clk_csr_i. So we do not change the default
* divider. */
-#endif
}
#if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
@@ -971,7 +967,7 @@ static int stmmac_open(struct net_device *dev)
} else
priv->tm->enable = 1;
#endif
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
stmmac_check_ether_addr(priv);
@@ -1075,7 +1071,7 @@ open_error:
if (priv->phydev)
phy_disconnect(priv->phydev);
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return ret;
}
@@ -1128,7 +1124,7 @@ static int stmmac_release(struct net_device *dev)
#ifdef CONFIG_STMMAC_DEBUG_FS
stmmac_exit_fs();
#endif
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return 0;
}
@@ -1922,11 +1918,14 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
ret = register_netdev(ndev);
if (ret) {
pr_err("%s: ERROR %i registering the device\n", __func__, ret);
- goto error;
+ goto error_netdev_register;
}
- if (stmmac_clk_get(priv))
+ priv->stmmac_clk = clk_get(priv->device, NULL);
+ if (IS_ERR(priv->stmmac_clk)) {
pr_warning("%s: warning: cannot get CSR clock\n", __func__);
+ goto error_clk_get;
+ }
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
@@ -1944,15 +1943,17 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
if (ret < 0) {
pr_debug("%s: MDIO bus (id: %d) registration failed",
__func__, priv->plat->bus_id);
- goto error;
+ goto error_mdio_register;
}
return priv;
-error:
- netif_napi_del(&priv->napi);
-
+error_mdio_register:
+ clk_put(priv->stmmac_clk);
+error_clk_get:
unregister_netdev(ndev);
+error_netdev_register:
+ netif_napi_del(&priv->napi);
free_netdev(ndev);
return NULL;
@@ -2020,7 +2021,7 @@ int stmmac_suspend(struct net_device *ndev)
else {
stmmac_set_mac(priv->ioaddr, false);
/* Disable clock in case of PWM is off */
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
}
spin_unlock(&priv->lock);
return 0;
@@ -2044,7 +2045,7 @@ int stmmac_resume(struct net_device *ndev)
priv->hw->mac->pmt(priv->ioaddr, 0);
else
/* enable the clk prevously disabled */
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
netif_device_attach(ndev);
--
1.7.9
^ permalink raw reply related
* Re: [PATCH v2 5/5] decrement static keys on real destroy time
From: Glauber Costa @ 2012-04-24 11:41 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4F9612B9.7050705-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 04/23/2012 11:40 PM, KAMEZAWA Hiroyuki wrote:
> (2012/04/24 4:37), Glauber Costa wrote:
>
>> We call the destroy function when a cgroup starts to be removed,
>> such as by a rmdir event.
>>
>> However, because of our reference counters, some objects are still
>> inflight. Right now, we are decrementing the static_keys at destroy()
>> time, meaning that if we get rid of the last static_key reference,
>> some objects will still have charges, but the code to properly
>> uncharge them won't be run.
>>
>> This becomes a problem specially if it is ever enabled again, because
>> now new charges will be added to the staled charges making keeping
>> it pretty much impossible.
>>
>> We just need to be careful with the static branch activation:
>> since there is no particular preferred order of their activation,
>> we need to make sure that we only start using it after all
>> call sites are active. This is achieved by having a per-memcg
>> flag that is only updated after static_key_slow_inc() returns.
>> At this time, we are sure all sites are active.
>>
>> This is made per-memcg, not global, for a reason:
>> it also has the effect of making socket accounting more
>> consistent. The first memcg to be limited will trigger static_key()
>> activation, therefore, accounting. But all the others will then be
>> accounted no matter what. After this patch, only limited memcgs
>> will have its sockets accounted.
>>
>> [v2: changed a tcp limited flag for a generic proto limited flag ]
>> [v3: update the current active flag only after the static_key update ]
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>
>
> Acked-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>
> A small request below.
>
> <snip>
>
>
>> + * ->activated needs to be written after the static_key update.
>> + * This is what guarantees that the socket activation function
>> + * is the last one to run. See sock_update_memcg() for details,
>> + * and note that we don't mark any socket as belonging to this
>> + * memcg until that flag is up.
>> + *
>> + * We need to do this, because static_keys will span multiple
>> + * sites, but we can't control their order. If we mark a socket
>> + * as accounted, but the accounting functions are not patched in
>> + * yet, we'll lose accounting.
>> + *
>> + * We never race with the readers in sock_update_memcg(), because
>> + * when this value change, the code to process it is not patched in
>> + * yet.
>> + */
>> + mutex_lock(&tcp_set_limit_mutex);
>
>
> Could you explain for what this mutex is in above comment ?
>
This is explained at the site where the mutex is defined.
If you still want me to mention it here, or maybe expand the explanation
there, I surely can.
^ permalink raw reply
* Re: [PATCH v2 4/5] don't take cgroup_mutex in destroy()
From: Glauber Costa @ 2012-04-24 11:42 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A, Vivek Goyal
In-Reply-To: <4F96109A.8000907-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 04/23/2012 11:31 PM, KAMEZAWA Hiroyuki wrote:
> (2012/04/24 4:37), 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)
>>
>> [v2: don't cgroup_lock the freezer and blkcg ]
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> CC: Tejun Heo<tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> CC: Li Zefan<lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> CC: Kamezawa Hiroyuki<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>> CC: Vivek Goyal<vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> kernel/cgroup.c | 9 ++++-----
>> 1 files changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index 932c318..976d332 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -869,13 +869,13 @@ static void cgroup_diput(struct dentry *dentry, struct inode *inode)
>> * agent */
>> synchronize_rcu();
>>
>> - mutex_lock(&cgroup_mutex);
>> /*
>> * Release the subsystem state objects.
>> */
>> for_each_subsys(cgrp->root, ss)
>> ss->destroy(cgrp);
>>
>> + mutex_lock(&cgroup_mutex);
>> cgrp->root->number_of_cgroups--;
>> mutex_unlock(&cgroup_mutex);
>>
>> @@ -3994,13 +3994,12 @@ static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
>>
>> err_destroy:
>>
>> + mutex_unlock(&cgroup_mutex);
>> for_each_subsys(root, ss) {
>> if (cgrp->subsys[ss->subsys_id])
>> ss->destroy(cgrp);
>> }
>>
>> - mutex_unlock(&cgroup_mutex);
>> -
>> /* Release the reference count that we took on the superblock */
>> deactivate_super(sb);
>>
>> @@ -4349,9 +4348,9 @@ int __init_or_module cgroup_load_subsys(struct cgroup_subsys *ss)
>> int ret = cgroup_init_idr(ss, css);
>> if (ret) {
>> dummytop->subsys[ss->subsys_id] = NULL;
>> + mutex_unlock(&cgroup_mutex);
>> ss->destroy(dummytop);
>> subsys[i] = NULL;
>> - mutex_unlock(&cgroup_mutex);
>> return ret;
>> }
>> }
>> @@ -4447,10 +4446,10 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
>> * pointer to find their state. note that this also takes care of
>> * freeing the css_id.
>> */
>> + mutex_unlock(&cgroup_mutex);
>> ss->destroy(dummytop);
>> dummytop->subsys[ss->subsys_id] = NULL;
>>
>
> I'm not fully sure but...dummytop->subsys[] update can be done without locking ?
>
I don't see a reason why updates to subsys[] after destruction shouldn't
be safe. But maybe I am wrong.
Tejun? Li?
^ permalink raw reply
* Winner Pin No:4288/33
From: Microsoft Corporation @ 2012-04-24 11:43 UTC (permalink / raw)
Winner Pin No:4288/33
You won $552,000USD.Send Name,Telephone No,Country.to Renny Harling at
(claimsdepartment2012@hotmail.com)
^ permalink raw reply
* Re: net_sched: gred: red_calc_qavg() called with current qavg for backlog?
From: Thomas Graf @ 2012-04-24 12:37 UTC (permalink / raw)
To: David Miller; +Cc: david.ward, tgraf, eric.dumazet, netdev
In-Reply-To: <20120421.161032.2225288178918492428.davem@davemloft.net>
On Sat, Apr 21, 2012 at 04:10:32PM -0400, David Miller wrote:
> From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
> Date: Sat, 21 Apr 2012 14:46:31 -0400
>
> > In net/sched/sch_gred.c:
> >
> > static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
> > {
> > struct gred_sched *table = qdisc_priv(sch);
> > ...
> > for (i = 0; i < MAX_DPs; i++) {
> > struct gred_sched_data *q = table->tab[i];
> > struct tc_gred_qopt opt;
> > ...
> > opt.qave = red_calc_qavg(&q->parms, &q->vars, q->vars.qavg);
> >
> >
> > I can't tell if red_calc_qavg is intentionally being passed the current
> > qavg as the backlog (which effectively causes qavg to only be
> > re-calculated if we are idling)? Or should this be:
> >
> > opt.qave = red_calc_qavg(&q->parms,
> > &q->vars,
> > gred_backlog(table, q, sch));
>
> Looking at commit 22b33429ab93155895854e9518a253680a920493
> ("[PKT_SCHED]: GRED: Use new generic red interface") it appears
> that this line is intentional so that the dump reports the same
> qave as it would have before Thomas's changes.
When doing the convert, I simply preserved behaviour. I am not sure on
what basis the original behaviour has been written.
^ permalink raw reply
* [PATCH 3/4] mISDN: Fix division by zero
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Karsten Keil
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
If DTMF debug is set and tresh goes under 100, the printk will cause
a division by zero.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
---
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_dtmf.c b/drivers/isdn/mISDN/dsp_dtmf.c
index 887860b..642f30b 100644
--- a/drivers/isdn/mISDN/dsp_dtmf.c
+++ b/drivers/isdn/mISDN/dsp_dtmf.c
@@ -222,16 +222,25 @@ coefficients:
goto storedigit;
}
- if (dsp_debug & DEBUG_DSP_DTMFCOEFF)
+ if (dsp_debug & DEBUG_DSP_DTMFCOEFF) {
+ s32 tresh_100 = tresh/100;
+
+ if (tresh_100 == 0) {
+ tresh_100 = 1;
+ printk(KERN_DEBUG
+ "tresh(%d) too small set tresh/100 to 1\n",
+ tresh);
+ }
printk(KERN_DEBUG "a %3d %3d %3d %3d %3d %3d %3d %3d"
" tr:%3d r %3d %3d %3d %3d %3d %3d %3d %3d\n",
result[0] / 10000, result[1] / 10000, result[2] / 10000,
result[3] / 10000, result[4] / 10000, result[5] / 10000,
result[6] / 10000, result[7] / 10000, tresh / 10000,
- result[0] / (tresh / 100), result[1] / (tresh / 100),
- result[2] / (tresh / 100), result[3] / (tresh / 100),
- result[4] / (tresh / 100), result[5] / (tresh / 100),
- result[6] / (tresh / 100), result[7] / (tresh / 100));
+ result[0] / (tresh_100), result[1] / (tresh_100),
+ result[2] / (tresh_100), result[3] / (tresh_100),
+ result[4] / (tresh_100), result[5] / (tresh_100),
+ result[6] / (tresh_100), result[7] / (tresh_100));
+ }
/* calc digit (lowgroup/highgroup) */
lowgroup = -1;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/4] mISDN: Bugfixes for the mISDN DSP core
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This collection are bugfixes for the DSP functions of the mISDN
core.
Tested against net-next.
Hopeful the submission format is OK now with git send-email
(before I used sendmail).
Andreas Eversberg (2):
mISDN: Fix NULL pointer bug in if-condition of mISDN_dsp
mISDN: Fixed hardware bridging/conference check routine of
mISDN_dsp.ko.
Karsten Keil (2):
mISDN: Fix division by zero
mISDN: DSP scheduling fix
drivers/isdn/mISDN/dsp.h | 4 +++-
drivers/isdn/mISDN/dsp_cmx.c | 19 ++++++++++++-------
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
3 files changed, 29 insertions(+), 13 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 4/4] mISDN: DSP scheduling fix
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Karsten Keil
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
dsp_spl_jiffies need to be the same datatype as jiffies (which is ulong).
If not, on 64 bit systems it will fallback to schedule the DSP every jiffie
tic as soon jiffies become > 2^32.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
---
drivers/isdn/mISDN/dsp.h | 4 +++-
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp.h b/drivers/isdn/mISDN/dsp.h
index afe4173..e020957 100644
--- a/drivers/isdn/mISDN/dsp.h
+++ b/drivers/isdn/mISDN/dsp.h
@@ -76,7 +76,9 @@ extern u8 dsp_silence;
#define MAX_SECONDS_JITTER_CHECK 5
extern struct timer_list dsp_spl_tl;
-extern u32 dsp_spl_jiffies;
+
+/* the datatype need to match jiffies datatype */
+extern ulong dsp_spl_jiffies;
/* the structure of conferences:
*
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index 0c104b9..3a3b3a5 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -1624,7 +1624,7 @@ send_packet:
static u32 jittercount; /* counter for jitter check */
struct timer_list dsp_spl_tl;
-u32 dsp_spl_jiffies; /* calculate the next time to fire */
+ulong dsp_spl_jiffies; /* calculate the next time to fire */
static u16 dsp_count; /* last sample count */
static int dsp_count_valid; /* if we have last sample count */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/4] mISDN: Fix NULL pointer bug in if-condition of mISDN_dsp
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andreas Eversberg
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Andreas Eversberg <jolly@eversberg.eu>
Fix a bug (was introduced by a cut & paste error)
in cases when dsp->conf was NULL.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
---
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index 334feab..b7589c2 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -1328,7 +1328,7 @@ dsp_cmx_send_member(struct dsp *dsp, int len, s32 *c, int members)
}
if (dsp->conf && dsp->conf->software && dsp->conf->hardware)
tx_data_only = 1;
- if (dsp->conf->software && dsp->echo.hardware)
+ if (dsp->echo.software && dsp->echo.hardware)
tx_data_only = 1;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/4] mISDN: Fixed hardware bridging/conference check routine of mISDN_dsp.ko.
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andreas Eversberg
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Andreas Eversberg <jolly@eversberg.eu>
In some cases the hardware bridging/conference (2-n parties) was selected,
but still pure software bridging/conference was used.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
---
drivers/isdn/mISDN/dsp_cmx.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index b7589c2..0c104b9 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -742,8 +742,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
member->dsp->pcm_slot_tx,
member->dsp->pcm_bank_tx,
member->dsp->pcm_bank_rx);
- conf->hardware = 0;
- conf->software = 1;
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
/* find a new slot */
@@ -834,8 +834,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
nextm->dsp->name,
member->dsp->pcm_slot_tx,
member->dsp->pcm_slot_rx);
- conf->hardware = 0;
- conf->software = 1;
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
/* find two new slot */
@@ -939,8 +939,11 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
/* for more than two members.. */
/* if all members already have the same conference */
- if (all_conf)
+ if (all_conf) {
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
+ }
/*
* if there is an existing conference, but not all members have joined
@@ -1013,6 +1016,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
dsp_cmx_hw_message(member->dsp,
MISDN_CTRL_HFC_CONF_JOIN, current_conf, 0, 0, 0);
}
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
--
1.7.3.4
^ permalink raw reply related
* Problem with iosize in Davicom DM9000 driver
From: jonsmirl @ 2012-04-24 14:54 UTC (permalink / raw)
To: netdev
In the probe code of the DM9000 driver...
iosize = resource_size(db->data_res);
------ iosize is the size of the resource block
static inline resource_size_t resource_size(const struct resource *res)
{
return res->end - res->start + 1;
}
db->data_req = request_mem_region(db->data_res->start, iosize,
pdev->name);
if (db->data_req == NULL) {
dev_err(db->dev, "cannot claim data reg area\n");
ret = -EIO;
goto out;
}
db->io_data = ioremap(db->data_res->start, iosize);
if (db->io_data == NULL) {
dev_err(db->dev, "failed to ioremap data reg\n");
ret = -EINVAL;
goto out;
}
/* fill in parameters for net-dev structure */
ndev->base_addr = (unsigned long)db->io_addr;
ndev->irq = db->irq_res->start;
/* ensure at least we have a default set of IO routines */
dm9000_set_io(db, iosize);
--------------------------
---- but it is passed into this routine which is expecting byte_width.
---- luckily the default case turns it into 32b IO which works on most systems.
---- I hit this working on a system with a 16b bus
static void dm9000_set_io(struct board_info *db, int byte_width)
{
/* use the size of the data resource to work out what IO
* routines we want to use
*/
switch (byte_width) {
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Christoph Lameter @ 2012-04-24 15:02 UTC (permalink / raw)
To: Glauber Costa
Cc: Tejun Heo, netdev, cgroups, Li Zefan, kamezawa.hiroyu,
David Miller, devel
In-Reply-To: <1335209867-1831-4-git-send-email-glommer@parallels.com>
On Mon, 23 Apr 2012, Glauber Costa wrote:
> This will allow us to call destroy() without holding the
> cgroup_mutex(). Other important updates inside update_flags()
> are protected by the callback_mutex.
>
> We could protect this variable with the callback_mutex as well,
> as suggested by Li Zefan, but we need to make sure we are protected
> by that mutex at all times, and some of its updates happen inside the
> cgroup_mutex - which means we would deadlock.
Would this not also be a good case to introduce static branching?
number_of_cpusets is used to avoid going through unnecessary processing
should there be no cpusets in use.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Christoph Lameter @ 2012-04-24 15:25 UTC (permalink / raw)
To: Rick Jones
Cc: Eric Dumazet, David Miller, netdev, therbert, ncardwell, maze,
ycheng, ilpo.jarvinen
In-Reply-To: <4F95D4CA.7020005@hp.com>
On Mon, 23 Apr 2012, Rick Jones wrote:
> Is it at all possible to have the copies happen without the connection being
> locked? If indeed it is possible to be held-off with the connection locked
> for the better part of 3/4 of a millisecond, just what will that do to 40 or
> 100 GbE? If you've been seeing queues of 300 ACKs at 10 GbE that would be
> 3000 at 100 GbE, and assuming those are all in a 2048 byte buffer thats 6MB
> just of ACKs. I suppose 100GbE does mean non-trivial quantities of buffering
> anyway but that does still seem rather high.
At some point people will need to realize that it is not business as usual
if one tries to use the current network porotocols at speeds above 1G.
There is a reason for high speed networks implementing new protocols like
RDMA techniques and lossless characteristics of a network.
^ permalink raw reply
* Re: [PATCH v2] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes
From: Steve Glendinning @ 2012-04-24 15:45 UTC (permalink / raw)
To: David Miller; +Cc: fillods, paolo.pisati, steve.glendinning, netdev
In-Reply-To: <20120424.004240.51699724664176823.davem@davemloft.net>
Hi all,
On 24 April 2012 05:42, David Miller <davem@davemloft.net> wrote:
>>> v2: added mantainer to the list of recipient
>>
>> His e-mail address has changed, but somehow it has not been updated yet
>> in MAINTAINERS directory: steve.glendinning () shawell.net
>
> Steve, please send a maintainers etc. update and please provide
> feedback on this link status fix.
I submitted an update to MAINTAINERS last week, I don't think it's
been picked up yet.
Thanks for the patch Paulo, I'd like to test this out. I'll get back
to you in a few days.
--
Steve Glendinning
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Kyle Mestery (kmestery) @ 2012-04-24 16:02 UTC (permalink / raw)
To: Simon Horman
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
<shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
David Miller
In-Reply-To: <20120424022514.GB5357-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
>> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
>>>>>
>>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>>>>>
>>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
>>>>>>>> (which could be the local stack; something sent by a VM; or packets
>>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>>>>>>> just prepend the STT header (possibly slightly adjusting things like
>>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
>>>>>>>> possible to just output the resulting frame through the IP stack like
>>>>>>>> all tunnels do today.
>>>>>>>
>>>>>>> Which seems to potentially suggest a stronger intergration of the STT
>>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
>>>>>>> is taking
>>>>>>
>>>>>> Did you have something in mind?
>>>>>
>>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
>>>>> openvswitch approach Simon is using.
>>>>
>>>> Ahh, yes, that I agree with. Independent of this, there's work being
>>>> done to make it so that OVS can use the normal in-tree tunneling code
>>>> and not need its own. Once that's done I expect that STT will follow
>>>> the same model.
>>>
>>> Hi Jesse,
>>>
>>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
>>> code are. I'm happy to move my efforts over to an in-tree STT implementation
>>> but ultimately I would like to get STT running in conjunction with OVS.
>>
>> I would say that it's a firm goal but the implementation probably
>> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
>> on this in support of adding VXLAN, which needs some additional
>> flexibility that this approach would also provide. You might want to
>> talk to him to see if there are ways that you guys can work together
>> on it if you are interested. Having better integration with upstream
>> tunneling is definitely a step that OVS needs to make and sooner would
>> be better than later.
>
> Hi Jesse, Hi Kyle,
>
> that sounds like an excellent plan.
>
> Kyle, do you have any thoughts on how we might best work together on this?
> Perhaps there are some patches floating around that I could take a look at?
>
Hi Simon:
The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
https://github.com/mestery/ovs-vxlan/tree/vxlan
This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
Thanks!
Kyle
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Stephen Hemminger @ 2012-04-24 16:13 UTC (permalink / raw)
To: Kyle Mestery (kmestery)
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
David-/PVsmBQoxgPKo9QCiBeYKEEOCMrvLtNR,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
Miller
In-Reply-To: <807AC914-2F33-46C7-99DC-E2F8F0F97531-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Tue, 24 Apr 2012 16:02:41 +0000
"Kyle Mestery (kmestery)" <kmestery-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
> > On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> >> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> >>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> >>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> >>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> >>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
> >>>>>
> >>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> >>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> >>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> >>>>>>>
> >>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
> >>>>>>>> (which could be the local stack; something sent by a VM; or packets
> >>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
> >>>>>>>> just prepend the STT header (possibly slightly adjusting things like
> >>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
> >>>>>>>> possible to just output the resulting frame through the IP stack like
> >>>>>>>> all tunnels do today.
> >>>>>>>
> >>>>>>> Which seems to potentially suggest a stronger intergration of the STT
> >>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
> >>>>>>> is taking
> >>>>>>
> >>>>>> Did you have something in mind?
> >>>>>
> >>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
> >>>>> openvswitch approach Simon is using.
> >>>>
> >>>> Ahh, yes, that I agree with. Independent of this, there's work being
> >>>> done to make it so that OVS can use the normal in-tree tunneling code
> >>>> and not need its own. Once that's done I expect that STT will follow
> >>>> the same model.
> >>>
> >>> Hi Jesse,
> >>>
> >>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
> >>> code are. I'm happy to move my efforts over to an in-tree STT implementation
> >>> but ultimately I would like to get STT running in conjunction with OVS.
> >>
> >> I would say that it's a firm goal but the implementation probably
> >> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
> >> on this in support of adding VXLAN, which needs some additional
> >> flexibility that this approach would also provide. You might want to
> >> talk to him to see if there are ways that you guys can work together
> >> on it if you are interested. Having better integration with upstream
> >> tunneling is definitely a step that OVS needs to make and sooner would
> >> be better than later.
> >
> > Hi Jesse, Hi Kyle,
> >
> > that sounds like an excellent plan.
> >
> > Kyle, do you have any thoughts on how we might best work together on this?
> > Perhaps there are some patches floating around that I could take a look at?
> >
>
> Hi Simon:
>
> The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
>
> https://github.com/mestery/ovs-vxlan/tree/vxlan
>
> This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
>
> With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
>
My use of VXVLAN was to be key based (like existing GRE), not flow based.
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Glauber Costa @ 2012-04-24 16:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <alpine.DEB.2.00.1204241001050.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 04/24/2012 12:02 PM, Christoph Lameter wrote:
> On Mon, 23 Apr 2012, Glauber Costa wrote:
>
>> This will allow us to call destroy() without holding the
>> cgroup_mutex(). Other important updates inside update_flags()
>> are protected by the callback_mutex.
>>
>> We could protect this variable with the callback_mutex as well,
>> as suggested by Li Zefan, but we need to make sure we are protected
>> by that mutex at all times, and some of its updates happen inside the
>> cgroup_mutex - which means we would deadlock.
>
> Would this not also be a good case to introduce static branching?
>
> number_of_cpusets is used to avoid going through unnecessary processing
> should there be no cpusets in use.
>
Well,
static branches comes with a set of problems themselves, so I usually
prefer to use them only in places where we don't want to pay even a
cache miss if we can avoid, or a function call, or anything like that -
like the slub cache alloc as you may have seen in my kmem memcg series.
It doesn't seem to be the case here.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Kyle Mestery (kmestery) @ 2012-04-24 16:16 UTC (permalink / raw)
To: Stephen Hemminger
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
David Miller
In-Reply-To: <20120424091317.08953fd2-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org>
On Apr 24, 2012, at 11:13 AM, Stephen Hemminger wrote:
> On Tue, 24 Apr 2012 16:02:41 +0000
> "Kyle Mestery (kmestery)" <kmestery-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
>>> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
>>>> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>>>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>>>>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
>>>>>>>
>>>>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>>>>>>>
>>>>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
>>>>>>>>>> (which could be the local stack; something sent by a VM; or packets
>>>>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>>>>>>>>> just prepend the STT header (possibly slightly adjusting things like
>>>>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
>>>>>>>>>> possible to just output the resulting frame through the IP stack like
>>>>>>>>>> all tunnels do today.
>>>>>>>>>
>>>>>>>>> Which seems to potentially suggest a stronger intergration of the STT
>>>>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
>>>>>>>>> is taking
>>>>>>>>
>>>>>>>> Did you have something in mind?
>>>>>>>
>>>>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
>>>>>>> openvswitch approach Simon is using.
>>>>>>
>>>>>> Ahh, yes, that I agree with. Independent of this, there's work being
>>>>>> done to make it so that OVS can use the normal in-tree tunneling code
>>>>>> and not need its own. Once that's done I expect that STT will follow
>>>>>> the same model.
>>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
>>>>> code are. I'm happy to move my efforts over to an in-tree STT implementation
>>>>> but ultimately I would like to get STT running in conjunction with OVS.
>>>>
>>>> I would say that it's a firm goal but the implementation probably
>>>> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
>>>> on this in support of adding VXLAN, which needs some additional
>>>> flexibility that this approach would also provide. You might want to
>>>> talk to him to see if there are ways that you guys can work together
>>>> on it if you are interested. Having better integration with upstream
>>>> tunneling is definitely a step that OVS needs to make and sooner would
>>>> be better than later.
>>>
>>> Hi Jesse, Hi Kyle,
>>>
>>> that sounds like an excellent plan.
>>>
>>> Kyle, do you have any thoughts on how we might best work together on this?
>>> Perhaps there are some patches floating around that I could take a look at?
>>>
>>
>> Hi Simon:
>>
>> The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
>>
>> https://github.com/mestery/ovs-vxlan/tree/vxlan
>>
>> This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
>>
>> With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
>>
>
> My use of VXVLAN was to be key based (like existing GRE), not flow based.
>
Yes, for OVS the idea is to add the tunnel key values to the flow-key in the OVS kernel module.
^ 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