* [Patch] scm: Capture the full credentials of the scm sender
From: Tim Chen @ 2011-08-09 16:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric W. Biederman, David S. Miller, Al Viro, ak, linux-kernel,
netdev
In-Reply-To: <1312857834.2531.15.camel@edumazet-laptop>
On Tue, 2011-08-09 at 04:43 +0200, Eric Dumazet wrote:
> Good catch Tim.
>
> BTW your patch is a bit flawed : one wrapped line and "---" marker
> missing.
>
> Could you add in Changelog bug came from commit 257b5358b32f17
> (scm: Capture the full credentials of the scm sender) to ease stable
> teams work ?
> (linux-2.6.36 was the first kernel to include this commit)
>
>
>
Updated the log as requested. Thanks.
Tim
------------
This patch corrects an erroneous update of credential's gid with uid
introduced in commit 257b5358b32f17 since 2.6.36.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
diff --git a/net/core/scm.c b/net/core/scm.c
index 4c1ef02..811b53f 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -192,7 +192,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
goto error;
cred->uid = cred->euid = p->creds.uid;
- cred->gid = cred->egid = p->creds.uid;
+ cred->gid = cred->egid = p->creds.gid;
put_cred(p->cred);
p->cred = cred;
}
^ permalink raw reply related
* [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: stufever @ 2011-08-09 16:39 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, Wang Shaoyan
From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
---
drivers/net/gianfar_ethtool.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..134fe1b 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,21 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfpr || !local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ got err;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -765,7 +776,10 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+err:
+ kfree(local_rqfcr);
+ kfree(local_rqfpr);
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Wang Shaoyan @ 2011-08-09 16:37 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, netdev, davem, Wang Shaoyan
In-Reply-To: <1312906118.11924.8.camel@Joe-Laptop>
I thought kfree should not call, when kmalloc is failed. Now I think
is fine, thanks, it is much clearer
> Perhaps it'd be clearer to use:
>
> local_rqfpr = kmalloc(...)
> local_rqfcr = kmalloc(...)
> if (!local_rqfpr || !local_rqfcr) {
> pr_err(...)
> ret = -ENOMEM;
> goto err;
> }
>
> [...]
>
> err:
> kfree(local_rqfpr);
> kfree(local_rqfcr);
> return ret;
>
> Is the "local_" prefix useful?
> It seems like visual noise to me.
They are some temporary variable, we better to left them
>
>
--
Wang Shaoyan
^ permalink raw reply
* Re: [PATCH net-next 0/6] be2net: fixes
From: Eric Dumazet @ 2011-08-09 16:23 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev, David Miller
In-Reply-To: <1312904848.2371.42.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le mardi 09 août 2011 à 17:47 +0200, Eric Dumazet a écrit :
> Le mercredi 03 août 2011 à 11:27 +0530, Sathya Perla a écrit :
>
> > Pls apply.
> >
> > Sathya Perla (6):
> > be2net: remove wrong and unnecessary calls to netif_carrier_off()
> > be2net: no need to query link status
> > be2net: non-member vlan pkts not received in promiscous mode
> > be2net: use RX_FILTER cmd to program multicast addresses
> > be2net: add support for flashing Teranetics PHY firmware
> > be2net: drop pkts that do not belong to the port
> >
> > drivers/net/benet/be.h | 8 ++-
> > drivers/net/benet/be_cmds.c | 140 +++++++++++++-----------------------
> > drivers/net/benet/be_cmds.h | 38 ++++------
> > drivers/net/benet/be_ethtool.c | 32 ++-------
> > drivers/net/benet/be_hw.h | 21 ++++--
> > drivers/net/benet/be_main.c | 155 ++++++++++++++++++++++++----------------
> > 6 files changed, 185 insertions(+), 209 deletions(-)
> >
>
> Not sure which recent be2net patch is problematic on 32bit arches :
>
> Kernel: arch/x86/boot/bzImage is ready (#280)
> Building modules, stage 2.
> MODPOST 1854 modules
> ERROR: "__udivdi3" [drivers/net/benet/be2net.ko] undefined!
> make[1]: *** [__modpost] Erreur 1
> make: *** [modules] Erreur 2
>
> Please fix this, thanks.
>
>
Comes from commit ac124ff973e27802797
(be2net: cleanup and refactor stats code)
be_rx_eqd_update() now performs u64 divides.
Following patch should be enough, there is no way packet count can
overwrap a long anyway between two samples...
[PATCH] benet: fix build error on 32bit arch
Error comes from commit ac124ff973e27802797
(be2net: cleanup and refactor stats code)
ERROR: "__udivdi3" [drivers/net/benet/be2net.ko] undefined!
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 1a3acca..7c98d8e 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -936,7 +936,7 @@ static void be_rx_eqd_update(struct be_adapter *adapter, struct be_rx_obj *rxo)
pkts = stats->rx_pkts;
} while (u64_stats_fetch_retry_bh(&stats->sync, start));
- stats->rx_pps = (pkts - stats->rx_pkts_prev) / (delta / HZ);
+ stats->rx_pps = (unsigned long)(pkts - stats->rx_pkts_prev) / (delta / HZ);
stats->rx_pkts_prev = pkts;
stats->rx_jiffies = now;
eqd = stats->rx_pps / 110000;
^ permalink raw reply related
* Re: [PATCH 1/6] Security: define security_sk_getsecid.
From: Casey Schaufler @ 2011-08-09 16:13 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, linux-security-module, sds, Casey Schaufler
In-Reply-To: <1312874910-31010-2-git-send-email-rongqing.li@windriver.com>
On 8/9/2011 12:28 AM, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> Define security_sk_getsecid to get the security id of a sock.
Why are you requesting the secid when you're just going to
use it to get the secctx? Why not ask for that directly?
Is there ever a case where you only want the secid?
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> include/linux/security.h | 6 ++++++
> security/security.c | 6 ++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/security.h b/include/linux/security.h
> index ebd2a53..739ac39 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -2560,6 +2560,7 @@ int security_sk_alloc(struct sock *sk, int family, gfp_t priority);
> void security_sk_free(struct sock *sk);
> void security_sk_clone(const struct sock *sk, struct sock *newsk);
> void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
> +void security_sk_getsecid(struct sock *sk, u32 *secid);
> void security_req_classify_flow(const struct request_sock *req, struct flowi *fl);
> void security_sock_graft(struct sock*sk, struct socket *parent);
> int security_inet_conn_request(struct sock *sk,
> @@ -2701,6 +2702,11 @@ static inline void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
> {
> }
>
> +static inline void security_sk_getsecid(struct sock *sk, u32 *secid)
> +{
> + *secid = 0;
> +}
> +
> static inline void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
> {
> }
> diff --git a/security/security.c b/security/security.c
> index 0e4fccf..b0e0825 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1104,6 +1104,12 @@ void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
> }
> EXPORT_SYMBOL(security_sk_classify_flow);
>
> +void security_sk_getsecid(struct sock *sk, u32 *secid)
> +{
> + security_ops->sk_getsecid(sk, secid);
> +}
> +EXPORT_SYMBOL(security_sk_getsecid);
> +
> void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
> {
> security_ops->req_classify_flow(req, fl);
^ permalink raw reply
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Joe Perches @ 2011-08-09 16:08 UTC (permalink / raw)
To: stufever; +Cc: linux-kernel, netdev, davem, Sandeep.Kumar, Wang Shaoyan
In-Reply-To: <1312904711-1855-1-git-send-email-wangshaoyan.pt@taobao.com>
On Tue, 2011-08-09 at 23:45 +0800, stufever@gmail.com wrote:
> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
> drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
[]
> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
[]
> @@ -686,10 +686,26 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
> {
> unsigned int last_rule_idx = priv->cur_filer_idx;
> unsigned int cmp_rqfpr;
> - unsigned int local_rqfpr[MAX_FILER_IDX + 1];
> - unsigned int local_rqfcr[MAX_FILER_IDX + 1];
> + unsigned int *local_rqfpr;
> + unsigned int *local_rqfcr;
> int i = 0x0, k = 0x0;
> int j = MAX_FILER_IDX, l = 0x0;
> + int ret = 1;
> +
> + local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
> + GFP_KERNEL);
> + if (!local_rqfpr) {
> + pr_err("Out of memory\n");
> + ret = 0;
> + got err;
> + }
> + local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
> + GFP_KERNEL);
> + if (!local_rqfcr) {
> + pr_err("Out of memory\n");
> + ret = 0;
> + goto err1;
> + }
Perhaps it'd be clearer to use:
local_rqfpr = kmalloc(...)
local_rqfcr = kmalloc(...)
if (!local_rqfpr || !local_rqfcr) {
pr_err(...)
ret = -ENOMEM;
goto err;
}
[...]
err:
kfree(local_rqfpr);
kfree(local_rqfcr);
return ret;
Is the "local_" prefix useful?
It seems like visual noise to me.
^ permalink raw reply
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Wang Shaoyan @ 2011-08-09 16:06 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, Sandeep.Kumar, wangshaoyan.pt
In-Reply-To: <20110809.085049.747100276988072226.davem@davemloft.net>
Thanks for remainding, I just want to cover up my careless asap:-)
2011/8/9 David Miller <davem@davemloft.net>:
> From: stufever@gmail.com
> Date: Tue, 9 Aug 2011 23:45:11 +0800
>
>> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>>
>> drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
>>
>> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>
> Would you be so kind as to actually acknowledge in some way the person
> who found all the bugs in your first version of this patch? :-/
>
>
--
Wang Shaoyan
^ permalink raw reply
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Wang Shaoyan @ 2011-08-09 16:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, davem, Wang Shaoyan
In-Reply-To: <1312904624.2371.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Thanks, I'm sorry to my careless.
2011/8/9 Eric Dumazet <eric.dumazet@gmail.com>:
> Le mardi 09 août 2011 à 23:18 +0800, stufever@gmail.com a écrit :
>> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>>
>> drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
>>
>> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>> ---
>> drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++++---
>> 1 files changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
>> index 6e35069..039e9c3 100644
>> --- a/drivers/net/gianfar_ethtool.c
>> +++ b/drivers/net/gianfar_ethtool.c
>> @@ -686,10 +686,26 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
>> {
>> unsigned int last_rule_idx = priv->cur_filer_idx;
>> unsigned int cmp_rqfpr;
>> - unsigned int local_rqfpr[MAX_FILER_IDX + 1];
>> - unsigned int local_rqfcr[MAX_FILER_IDX + 1];
>> + unsigned int *local_rqfpr;
>> + unsigned int *local_rqfcr;
>> int i = 0x0, k = 0x0;
>> int j = MAX_FILER_IDX, l = 0x0;
>> + int ret = 1;
>> +
>> + local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
>> + GFP_KERNEL);
>> + if (local_rqfpr) {
>
> if (!local_rqfpr) {
>
>> + pr_err("Out of memory\n");
>> + ret = 0;
>> + got err;
>> + }
>> + local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
>> + GFP_KERNEL);
>> + if (local_rqfcr) {
>
> same here : if (!local_rqfcr) ...
>
>> + pr_err("Out of memory\n");
>> + ret = 0;
>> + goto err1;
>> + }
>>
>> switch (class) {
>> case TCP_V4_FLOW:
>> @@ -765,7 +781,11 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
>> priv->cur_filer_idx = priv->cur_filer_idx - 1;
>> }
>>
>> - return 1;
>> + kfree(local_rqfcr);
>> +err1:
>> + kfree(local_rqfpr);
>> +err:
>> + return ret;
>> }
>>
>> static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
>
>
>
--
Wang Shaoyan
^ permalink raw reply
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: David Miller @ 2011-08-09 15:50 UTC (permalink / raw)
To: stufever; +Cc: linux-kernel, netdev, Sandeep.Kumar, wangshaoyan.pt
In-Reply-To: <1312904711-1855-1-git-send-email-wangshaoyan.pt@taobao.com>
From: stufever@gmail.com
Date: Tue, 9 Aug 2011 23:45:11 +0800
> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>
> drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
>
> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
Would you be so kind as to actually acknowledge in some way the person
who found all the bugs in your first version of this patch? :-/
^ permalink raw reply
* Re: [PATCH net-next 0/6] be2net: fixes
From: Eric Dumazet @ 2011-08-09 15:47 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev, David Miller
In-Reply-To: <1312351066-16745-1-git-send-email-sathya.perla@emulex.com>
Le mercredi 03 août 2011 à 11:27 +0530, Sathya Perla a écrit :
> Pls apply.
>
> Sathya Perla (6):
> be2net: remove wrong and unnecessary calls to netif_carrier_off()
> be2net: no need to query link status
> be2net: non-member vlan pkts not received in promiscous mode
> be2net: use RX_FILTER cmd to program multicast addresses
> be2net: add support for flashing Teranetics PHY firmware
> be2net: drop pkts that do not belong to the port
>
> drivers/net/benet/be.h | 8 ++-
> drivers/net/benet/be_cmds.c | 140 +++++++++++++-----------------------
> drivers/net/benet/be_cmds.h | 38 ++++------
> drivers/net/benet/be_ethtool.c | 32 ++-------
> drivers/net/benet/be_hw.h | 21 ++++--
> drivers/net/benet/be_main.c | 155 ++++++++++++++++++++++++----------------
> 6 files changed, 185 insertions(+), 209 deletions(-)
>
Not sure which recent be2net patch is problematic on 32bit arches :
Kernel: arch/x86/boot/bzImage is ready (#280)
Building modules, stage 2.
MODPOST 1854 modules
ERROR: "__udivdi3" [drivers/net/benet/be2net.ko] undefined!
make[1]: *** [__modpost] Erreur 1
make: *** [modules] Erreur 2
Please fix this, thanks.
^ permalink raw reply
* [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: stufever @ 2011-08-09 15:45 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, Sandeep.Kumar, Wang Shaoyan
From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
---
drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..9bca11c 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,26 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfpr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ got err;
+ }
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ goto err1;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -765,7 +781,11 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+ kfree(local_rqfcr);
+err1:
+ kfree(local_rqfpr);
+err:
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Eric Dumazet @ 2011-08-09 15:43 UTC (permalink / raw)
To: stufever; +Cc: linux-kernel, netdev, davem, Sandeep.Kumar, Wang Shaoyan
In-Reply-To: <1312903103-1734-1-git-send-email-wangshaoyan.pt@taobao.com>
Le mardi 09 août 2011 à 23:18 +0800, stufever@gmail.com a écrit :
> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>
> drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
>
> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
> ---
> drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++++---
> 1 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
> index 6e35069..039e9c3 100644
> --- a/drivers/net/gianfar_ethtool.c
> +++ b/drivers/net/gianfar_ethtool.c
> @@ -686,10 +686,26 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
> {
> unsigned int last_rule_idx = priv->cur_filer_idx;
> unsigned int cmp_rqfpr;
> - unsigned int local_rqfpr[MAX_FILER_IDX + 1];
> - unsigned int local_rqfcr[MAX_FILER_IDX + 1];
> + unsigned int *local_rqfpr;
> + unsigned int *local_rqfcr;
> int i = 0x0, k = 0x0;
> int j = MAX_FILER_IDX, l = 0x0;
> + int ret = 1;
> +
> + local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
> + GFP_KERNEL);
> + if (local_rqfpr) {
if (!local_rqfpr) {
> + pr_err("Out of memory\n");
> + ret = 0;
> + got err;
> + }
> + local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
> + GFP_KERNEL);
> + if (local_rqfcr) {
same here : if (!local_rqfcr) ...
> + pr_err("Out of memory\n");
> + ret = 0;
> + goto err1;
> + }
>
> switch (class) {
> case TCP_V4_FLOW:
> @@ -765,7 +781,11 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
> priv->cur_filer_idx = priv->cur_filer_idx - 1;
> }
>
> - return 1;
> + kfree(local_rqfcr);
> +err1:
> + kfree(local_rqfpr);
> +err:
> + return ret;
> }
>
> static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
^ permalink raw reply
* [PATCH net-next] neigh: reduce arp latency
From: Eric Dumazet @ 2011-08-09 15:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Remove the artificial HZ latency on arp resolution.
Instead of firing a timer in one jiffy (up to 10 ms if HZ=100), lets
send the ARP message immediately.
Before patch :
# arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=9.91 ms
64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.061 ms
After patch :
$ arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=0.152 ms
64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.074 ms
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/neighbour.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 8fab9b0..d99f908 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -844,6 +844,19 @@ static void neigh_invalidate(struct neighbour *neigh)
skb_queue_purge(&neigh->arp_queue);
}
+static void neigh_probe(struct neighbour *neigh)
+ __releases(neigh->lock)
+{
+ struct sk_buff *skb = skb_peek(&neigh->arp_queue);
+ /* keep skb alive even if arp_queue overflows */
+ if (skb)
+ skb = skb_copy(skb, GFP_ATOMIC);
+ write_unlock(&neigh->lock);
+ neigh->ops->solicit(neigh, skb);
+ atomic_inc(&neigh->probes);
+ kfree_skb(skb);
+}
+
/* Called when a timer expires for a neighbour entry. */
static void neigh_timer_handler(unsigned long arg)
@@ -920,14 +933,7 @@ static void neigh_timer_handler(unsigned long arg)
neigh_hold(neigh);
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
- struct sk_buff *skb = skb_peek(&neigh->arp_queue);
- /* keep skb alive even if arp_queue overflows */
- if (skb)
- skb = skb_copy(skb, GFP_ATOMIC);
- write_unlock(&neigh->lock);
- neigh->ops->solicit(neigh, skb);
- atomic_inc(&neigh->probes);
- kfree_skb(skb);
+ neigh_probe(neigh);
} else {
out:
write_unlock(&neigh->lock);
@@ -943,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
int rc;
unsigned long now;
+ bool immediate_probe = false;
write_lock_bh(&neigh->lock);
@@ -957,7 +964,8 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
atomic_set(&neigh->probes, neigh->parms->ucast_probes);
neigh->nud_state = NUD_INCOMPLETE;
neigh->updated = jiffies;
- neigh_add_timer(neigh, now + 1);
+ neigh_add_timer(neigh, now + HZ);
+ immediate_probe = true;
} else {
neigh->nud_state = NUD_FAILED;
neigh->updated = jiffies;
@@ -989,7 +997,11 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
rc = 1;
}
out_unlock_bh:
- write_unlock_bh(&neigh->lock);
+ if (immediate_probe)
+ neigh_probe(neigh);
+ else
+ write_unlock(&neigh->lock);
+ local_bh_enable();
return rc;
}
EXPORT_SYMBOL(__neigh_event_send);
^ permalink raw reply related
* Re: [PATCH 09/12] headers, xtables: Add missing #include <linux/netfilter.h>
From: Patrick McHardy @ 2011-08-09 15:29 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, netfilter-devel
In-Reply-To: <1312809632.2591.1148.camel@deadeye>
On 08.08.2011 15:20, Ben Hutchings wrote:
> Various headers use union nf_inet_addr, defined in <linux/netfilter.h>.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
All netfilter related patches:
Acked-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: stufever @ 2011-08-09 15:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, Sandeep.Kumar, Wang Shaoyan
From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
---
drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..039e9c3 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,26 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (local_rqfpr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ got err;
+ }
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ goto err1;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -765,7 +781,11 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+ kfree(local_rqfcr);
+err1:
+ kfree(local_rqfpr);
+err:
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCHv3 0/9] macb: add support for Cadence GEM
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:59 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-1-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> This is largely a repost of the series I posted back in March. The only changes
> since then are rebasing onto 3.1-rc1 and changing the gem conditionals from a
> boolean in the macb structure to an inline helper as requested by
> Jean-Christophe.
>
> This has been run-tested on picoxcell and compile tested for all AT91 platforms
> but I couldn't get a working cross compiler for avr32.
>
> All patches are available in a git branch at
>
> git://github.com/jamieiles/linux-2.6-ji.git macb-gem
>
looks good except few comments
I'll test it later this week
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Marc Kleine-Budde @ 2011-08-09 15:11 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, U Bhaskar-B22300,
PPC list, Wolfgang Grandegger
In-Reply-To: <20110809145507.GY4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 718 bytes --]
On 08/09/2011 04:55 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:45:58PM +0000, U Bhaskar-B22300 wrote:
>> Hi Robin,
>> Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
>> Or the existing code of ARM based FlexCAN will work for P1010 ??
>
> It appears that the of_device stuff got moved under the struct device
> and that allows the request_irq() to just magically work.
cool :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Wolfgang Grandegger @ 2011-08-09 15:10 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, U Bhaskar-B22300, PPC list,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110809145507.GY4926-sJ/iWh9BUns@public.gmane.org>
On 08/09/2011 04:55 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:45:58PM +0000, U Bhaskar-B22300 wrote:
>> Hi Robin,
>> Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
>> Or the existing code of ARM based FlexCAN will work for P1010 ??
>
> It appears that the of_device stuff got moved under the struct device
> and that allows the request_irq() to just magically work.
Cool! Actually I was also missing of_address_to_resource (or of_iomap)
and irq_of_parse_and_map(). But the resources seem to be filled in here:
http://lxr.linux.no/#linux+v3.0.1/drivers/of/platform.c#L121
Wolfgang.
^ permalink raw reply
* Re: [PATCHv3 9/9] macb: allow GEM to have configurable receive buffer size
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:59 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-10-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM has configurable receive buffer sizes so requires this to be
> programmed up. Any size < 2048 and a multiple of 64 bytes is permitted.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 8/9] macb: support DMA bus widths > 32 bits
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:57 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-9-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> Some GEM implementations may support DMA bus widths up to 128 bits. We
> can get the maximum supported DMA bus width from the design
> configuration register so use that to program the device up.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 7/9] macb: support statistics for GEM devices
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:57 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-8-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM devices have a different number of statistics registers and they
> are at a different offset to MACB devices. Make the statistics
> collection method dependent on device type.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 6/9] macb: support higher rate GEM MDIO clock divisors
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:56 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-7-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM devices support larger clock divisors and have a different
> range of divisors. Program the MDIO clock divisors based on the
> device type.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 5/9] macb: initial support for Cadence GEM
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:55 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-6-git-send-email-jamie@jamieiles.com>
>
> MODULE_LICENSE("GPL");
> -MODULE_DESCRIPTION("Atmel MACB Ethernet driver");
> -MODULE_AUTHOR("Haavard Skinnemoen (Atmel)");
> +MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
> +MODULE_AUTHOR("Haavard Skinnemoen");
Haavard do it as a Atmel emloyee so please keep the (Atmel)
otherwise
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-09 14:55 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, PPC list, Wolfgang Grandegger
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1C4A88-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
On Tue, Aug 09, 2011 at 02:45:58PM +0000, U Bhaskar-B22300 wrote:
> Hi Robin,
> Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
> Or the existing code of ARM based FlexCAN will work for P1010 ??
It appears that the of_device stuff got moved under the struct device
and that allows the request_irq() to just magically work.
Robin
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-09 14:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, therbert, netdev
In-Reply-To: <1312877173.2371.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 09 Aug 2011 10:06:13 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 8 Aug 2011 11:19:17 -0700
> >
> > > On Mon, 8 Aug 2011 11:01:57 -0700
> > > Tom Herbert <therbert@google.com> wrote:
> > >
> > >> > Since transmit completion means calling dev_kfree_skb() why not account
> > >> > there? You could add some info to netdev if necessary to get compile
> > >> > the statistics.
> > >> >
> > >> The algorithm depends on knowing the total number of packets competed
> > >> in a single execution of transmit completion (epic based). We only
> > >> want to recalculate the limits once per completion, which happens when
> > >> the completion function is called.
> > >
> > > So just add some stats to netdev and count the number of dev_kfree_skb
> > > calls and do your work at napi complete.
> >
> > No, I think what Tom's doing here is reasonable.
> >
> > First off, drivers have never been required to do specific things if
> > they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
> > and return NET_TX_SUCCESS, and that's fine.
> >
> > This mean we can't use ->ndo_start_xmit() return values to drive the
> > BQL engine.
> >
> > So we simply have a way for the driver to say when it really does
> > queue up a packet, and that might be useful for other things.
> >
> > Second, you absolutely do not want to run the BQL engine on every
> > single dev_kfree_skb() call. You want to batch it, and that's what
> > Tom's new interface does, and that is therefore quite reasonable
> > too.
> >
> > In fact, I think the best part about this revision of the BQL patches
> > is the device driver interface. :-)
> >
>
> I agree, it permits a smooth transition to selected drivers, even some
> non NAPI ones ;)
>
> In some stress situations, NAPI never completes, so it would also mean
> adding a dql call in this case...
Ok. then we need to fix all NAPI drivers at once, and get more
drivers converted over to NAPI. It is really annoying how there
is just too much variation among network drivers.
^ 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