Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Eric Dumazet @ 2012-07-25  6:51 UTC (permalink / raw)
  To: Li Wei; +Cc: David Miller, David.Laight, netdev, shemminger
In-Reply-To: <500F8356.5040008@cn.fujitsu.com>

On Wed, 2012-07-25 at 13:25 +0800, Li Wei wrote:
> When userspace use RTM_GETROUTE to dump route table, with an already
> expired route entry, we always got an 'expires' value(2147157)
> calculated base on INT_MAX.
> 
> The reason of this problem is in the following satement:
> 	rt->dst.expires - jiffies < INT_MAX
> gcc promoted the type of both sides of '<' to unsigned long, thus
> a small negative value would be considered greater than INT_MAX.
> 
> This patch fix this by use the same trick as time_after macro to
> avoid the 'unsigned long' type promotion and deal with jiffies
> wrapping.
> 
> Also we should do some fix in rtnl_put_cacheinfo() which use
> jiffies_to_clock_t(which take an unsigned long as parameter) to
> convert jiffies to clock_t to handle the negative expires.
> 
> With the help of David Laight, we can make the code a little clean.
> 
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
> ---
>  net/core/rtnetlink.c |    3 ++-
>  net/ipv6/route.c     |   11 ++++++-----
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 334b930..2e96396 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
>  	};
>  
>  	if (expires)
> -		ci.rta_expires = jiffies_to_clock_t(expires);
> +		ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
> +			: -jiffies_to_clock_t(-expires);
>  
>  	return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
>  }
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cf02cb9..6efeb28 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
>  		goto nla_put_failure;
>  	if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
>  		goto nla_put_failure;
> -	if (!(rt->rt6i_flags & RTF_EXPIRES))
> +	if (!(rt->rt6i_flags & RTF_EXPIRES)) {
>  		expires = 0;
> -	else if (rt->dst.expires - jiffies < INT_MAX)
> -		expires = rt->dst.expires - jiffies;
> -	else
> -		expires = INT_MAX;
> +	} else {
> +		expires = (long)rt->dst.expires - (long)jiffies;
> +		if (expires != (int)expires)
> +			expires = expires > 0 ? INT_MAX : INT_MIN;
> +	}
>  
>  	if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
>  		goto nla_put_failure;

All this sounds not very clean.

rtnl_put_cacheinfo( ... long expires ... )

Any out of bound checks should be done in rtnl_put_cacheinfo(), _after_
conversion to clock_t.


diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 334b930..c1c950b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -625,9 +625,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
 		.rta_id =  id,
 	};
 
-	if (expires)
-		ci.rta_expires = jiffies_to_clock_t(expires);
+	if (expires) {
+		unsigned long clock;
 
+		clock = jiffies_to_clock_t(abs(expires));
+		clock = min_t(unsigned long, clock, INT_MAX);
+		ci.rta_expires = (expires > 0) ? clock : -clock;
+	}
 	return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
 }
 EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cf02cb9..8e80fd2 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2480,12 +2480,8 @@ static int rt6_fill_node(struct net *net,
 		goto nla_put_failure;
 	if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
 		goto nla_put_failure;
-	if (!(rt->rt6i_flags & RTF_EXPIRES))
-		expires = 0;
-	else if (rt->dst.expires - jiffies < INT_MAX)
-		expires = rt->dst.expires - jiffies;
-	else
-		expires = INT_MAX;
+
+	expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
 
 	if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
 		goto nla_put_failure;

^ permalink raw reply related

* Share network traffic between process with respect to a priority number.
From: Sameer Rahmani @ 2012-07-25  6:51 UTC (permalink / raw)
  To: netdev@vger.kernel.org

Hi guys

for years i have problems with sharing my network bandwidth between my 
processes. when one of my running processes (e.g axel) start to download 
data my other processes that needs bandwidth stop working (because they 
can't download their data) . i know that there is some tools like lartc 
but i was thinking about a priority value like NICE for this matter. 
kernel will share the bandwidth between process with respect to their 
network priority number let's call it NNICE ( or what ever ) . The 
process with highest NNICE will use the highest bandwidth.

It's just an raw idea, i want to know your idea about the basic , and 
improve it.
What do you think?

With respect
Sameer Rahmani

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Vlad Yasevich @ 2012-07-25  7:16 UTC (permalink / raw)
  To: Xufeng Zhang; +Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <CA+=dFzg=Bpsv5bMzECoAXYVcbD95eYy6xDAzL6fwiHrunfq-tg@mail.gmail.com>

Xufeng Zhang <xufengzhang.main@gmail.com> wrote:

>On 7/24/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>>> And I should clarify the above judgment code.
>>>>> AFAIK, there should be two cases for the bundling when invalid
>>>stream
>>>>> identifier error happens:
>>>>> 1). COOKIE_ACK ERROR SACK
>>>>> 2). ERROR SACK
>>>>> So I need to deal with the two cases differently.
>>>>>
>>>>>
>>>> Sorry but I just don't buy that the above are the only 2 cases. 
>What
>>>if there are addip chunks as well?  What if there are some other
>>>extensions also.  This code has to be generic enough to handle any
>>>condition.
>>>>
>>>Aha, you are right, this may happens.
>>>So I think the general solution is to fix this problem in the enqueue
>>>side.
>>>What do you think? any better suggestion!
>>>
>>
>> Don't have code in front of me but what if we carry the error
>condition to
>> where we queue the Sack and add the error side effect then?
>Yes, this is the most direct way to fix this problem.
>But I don't think it's the best way since we will take care of a lot
>of things and
>it also involves in lots of changes to side effect processing.
>I prefer to Neil Horman's way for the solution since only COOKIE_ACK
>chunk is
>allowed to place ahead of SACK chunk when bundling into one packet.
>What do you think?
>
>

Actually not true.  AUTH can be before SACK.  So can any addip chunks that aid in locating an association. 

Now AUTH isn't a big issue since its autogenerated to the packet but ADDIP is since it could be queued up for retransmission.

There could be other extensions as well.  It really needs to be done either through side effects or making error chunks go at the end of other control chunks.  Need to audit the spec to see if that's ok.

-vlad
>
>Thanks,
>Xufeng Zhang
>>
>> -vlad


-- 
Sent from my Android phone with SkitMail. Please excuse my brevity.

^ permalink raw reply

* Re: [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Li Wei @ 2012-07-25  7:33 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, David.Laight, netdev, shemminger
In-Reply-To: <1343199114.2626.11088.camel@edumazet-glaptop>

On 07/25/2012 02:51 PM, Eric Dumazet wrote:
> On Wed, 2012-07-25 at 13:25 +0800, Li Wei wrote:
>> When userspace use RTM_GETROUTE to dump route table, with an already
>> expired route entry, we always got an 'expires' value(2147157)
>> calculated base on INT_MAX.
>>
>> The reason of this problem is in the following satement:
>> 	rt->dst.expires - jiffies < INT_MAX
>> gcc promoted the type of both sides of '<' to unsigned long, thus
>> a small negative value would be considered greater than INT_MAX.
>>
>> This patch fix this by use the same trick as time_after macro to
>> avoid the 'unsigned long' type promotion and deal with jiffies
>> wrapping.
>>
>> Also we should do some fix in rtnl_put_cacheinfo() which use
>> jiffies_to_clock_t(which take an unsigned long as parameter) to
>> convert jiffies to clock_t to handle the negative expires.
>>
>> With the help of David Laight, we can make the code a little clean.
>>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
>> ---
>>  net/core/rtnetlink.c |    3 ++-
>>  net/ipv6/route.c     |   11 ++++++-----
>>  2 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 334b930..2e96396 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
>>  	};
>>  
>>  	if (expires)
>> -		ci.rta_expires = jiffies_to_clock_t(expires);
>> +		ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
>> +			: -jiffies_to_clock_t(-expires);
>>  
>>  	return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
>>  }
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index cf02cb9..6efeb28 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
>>  		goto nla_put_failure;
>>  	if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
>>  		goto nla_put_failure;
>> -	if (!(rt->rt6i_flags & RTF_EXPIRES))
>> +	if (!(rt->rt6i_flags & RTF_EXPIRES)) {
>>  		expires = 0;
>> -	else if (rt->dst.expires - jiffies < INT_MAX)
>> -		expires = rt->dst.expires - jiffies;
>> -	else
>> -		expires = INT_MAX;
>> +	} else {
>> +		expires = (long)rt->dst.expires - (long)jiffies;
>> +		if (expires != (int)expires)
>> +			expires = expires > 0 ? INT_MAX : INT_MIN;
>> +	}
>>  
>>  	if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
>>  		goto nla_put_failure;
> 
> All this sounds not very clean.
> 
> rtnl_put_cacheinfo( ... long expires ... )
> 
> Any out of bound checks should be done in rtnl_put_cacheinfo(), _after_
> conversion to clock_t.

Ok, I got it.

I tested the following patch, got the correct expires value and not found
any problem.

Thanks Eric :)

> 
> 
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 334b930..c1c950b 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -625,9 +625,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
>  		.rta_id =  id,
>  	};
>  
> -	if (expires)
> -		ci.rta_expires = jiffies_to_clock_t(expires);
> +	if (expires) {
> +		unsigned long clock;
>  
> +		clock = jiffies_to_clock_t(abs(expires));
> +		clock = min_t(unsigned long, clock, INT_MAX);
> +		ci.rta_expires = (expires > 0) ? clock : -clock;
> +	}
>  	return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
>  }
>  EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cf02cb9..8e80fd2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2480,12 +2480,8 @@ static int rt6_fill_node(struct net *net,
>  		goto nla_put_failure;
>  	if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
>  		goto nla_put_failure;
> -	if (!(rt->rt6i_flags & RTF_EXPIRES))
> -		expires = 0;
> -	else if (rt->dst.expires - jiffies < INT_MAX)
> -		expires = rt->dst.expires - jiffies;
> -	else
> -		expires = INT_MAX;
> +
> +	expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
>  
>  	if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
>  		goto nla_put_failure;
> 
> 
> 
> 

^ permalink raw reply

* Re: [PATCH RESEND net-next V2] IB/ipoib: break linkage to neighbouring system
From: Roland Dreier @ 2012-07-25  7:52 UTC (permalink / raw)
  To: David Miller; +Cc: ogerlitz, netdev, eric.dumazet, cl, shlomop
In-Reply-To: <20120724.140015.1545062339709165330.davem@davemloft.net>

On Tue, Jul 24, 2012 at 2:00 PM, David Miller <davem@davemloft.net> wrote:
> Looks good, Roland you got this?

Yes, I'll read it over and pick it up, thanks.

^ permalink raw reply

* Re: Share network traffic between process with respect to a priority number.
From: Eric Dumazet @ 2012-07-25  7:54 UTC (permalink / raw)
  To: Sameer Rahmani; +Cc: netdev@vger.kernel.org
In-Reply-To: <500F9762.1090702@lxsameer.com>

On Wed, 2012-07-25 at 11:21 +0430, Sameer Rahmani wrote:
> Hi guys
> 
> for years i have problems with sharing my network bandwidth between my 
> processes. when one of my running processes (e.g axel) start to download 
> data my other processes that needs bandwidth stop working (because they 
> can't download their data) . i know that there is some tools like lartc 
> but i was thinking about a priority value like NICE for this matter. 
> kernel will share the bandwidth between process with respect to their 
> network priority number let's call it NNICE ( or what ever ) . The 
> process with highest NNICE will use the highest bandwidth.
> 
> It's just an raw idea, i want to know your idea about the basic , and 
> improve it.
> What do you think?

I think that's its hard to limit incoming data, on a general case.

Once frame is received, its too late, it already used the link
bandwidth.

A solution is to install a shaper on ingress, so that incoming tcp
frames might be delayed a bit _before_ incoming tcp stack, if they come
on a busy flow/link.

Using fq_codel sounds the right way : delay should be minimal for
interactive flows, and bigger for elephant flows.

It really should help you.

Check your kernel config has :

CONFIG_IFB=m
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_SCH_FQ_CODEL=m (or y)
CONFIG_NET_SCH_CBQ=m (or y)

Then adapt/use following script (can use HTB instead of CBQ of course)

ETH=eth0
IFB=ifb0
LOCALNETS="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"
RATE="rate 4Mbit bandwidth 4Mbit maxburst 80 minburst 40"
ALLOT="allot 8000" 

modprobe ifb
ip link set dev $IFB up

tc qdisc add dev $ETH ingress 2>/dev/null

tc filter add dev $ETH parent ffff: \
   protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
   redirect dev $IFB

tc qdisc del dev $IFB root


# Lets say our NIC is 100Mbit
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \
    rate 100Mbit bandwidth 100Mbit

tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \
	mpu 64 rate 100Mbit prio 1 \
	bandwidth 100Mbit maxburst 150 avpkt 1500 bounded

# Class for traffic coming from Internet : limited to X Mbits
tc class add dev $IFB parent 1:1 classid 1:11 \
	cbq $ALLOT mpu 64      \
	$RATE prio 2 \
	avpkt 1400 bounded

tc qdisc add dev $IFB parent 1:11 handle 11: fq_codel


# Traffic from machines in our LAN : no limit
for privnet in $LOCALNETS
do
	tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
		match ip src $privnet flowid 1:1
done

tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
	match ip protocol 0 0x00 flowid 1:11

^ permalink raw reply

* Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
From: Olaf Hering @ 2012-07-25  7:59 UTC (permalink / raw)
  To: K. Y. Srinivasan
  Cc: gregkh, linux-kernel, devel, virtualization, apw, netdev, ben
In-Reply-To: <1343145701-3691-3-git-send-email-kys@microsoft.com>

On Tue, Jul 24, K. Y. Srinivasan wrote:


> +++ b/drivers/hv/hv_kvp.c
> @@ -48,13 +48,24 @@ static struct {
>  	void *kvp_context; /* for the channel callback */
>  } kvp_transaction;
>  
> +/*
> + * Before we can accept KVP messages from the host, we need
> + * to handshake with the user level daemon. This state tarcks

tracks

> + * if we are in the handshake phase.
> + */

> -		 * Something failed or the we have timedout;
> +		 * Something failed or  we have timedout;

extra space

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25  8:05 UTC (permalink / raw)
  To: Vlad Yasevich, Neil Horman
  Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <e7f8a685-9635-4aa9-bd67-1044e0720b29@email.android.com>

On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>
> Actually not true.  AUTH can be before SACK.  So can any addip chunks that
> aid in locating an association.
>
> Now AUTH isn't a big issue since its autogenerated to the packet but ADDIP
> is since it could be queued up for retransmission.
>
> There could be other extensions as well.  It really needs to be done either
> through side effects or making error chunks go at the end of other control
> chunks.  Need to audit the spec to see if that's ok.
You are right, I just found SHUTDOWN chunks are also before SACK based on
your commit "[SCTP]: Fix SACK sequence during shutdown".
Maybe the only solution is to do some work on side effects just as you said.
Thanks for your explanation!



Thanks,
Xufeng Zhang
>
> -vlad
>>
>>Thanks,
>>Xufeng Zhang
>>>
>>> -vlad
>
>
> --
> Sent from my Android phone with SkitMail. Please excuse my brevity.
>

^ permalink raw reply

* [patch 3/3] [PATCH] qeth: repair crash in qeth_l3_vlan_rx_kill_vid()
From: frank.blaschka @ 2012-07-25  8:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-s390, stable, Ursula Braun
In-Reply-To: <20120725083426.704834478@de.ibm.com>

[-- Attachment #1: 602-qeth-vlan-rx-kill.diff --]
[-- Type: text/plain, Size: 1358 bytes --]

Commit efc73f4b "net: Fix memory leak - vlan_info struct" adds deletion of
VLAN 0 for devices with feature NETIF_F_HW_VLAN_FILTER. For driver
qeth these are the layer 3 devices. Usually there exists no
separate vlan net_device for VLAN 0. Thus the qeth functions
qeth_l3_free_vlan_addresses4() and qeth_l3_free_vlan_addresses6()
require an extra checking if function __vlan_find_dev_deep()
returns with a net_device.

Cc: stable@vger.kernel.org
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
 drivers/s390/net/qeth_l3_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index f0045ca..d01a617 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1758,6 +1758,8 @@ static void qeth_l3_free_vlan_addresses4(struct qeth_card *card,
 	QETH_CARD_TEXT(card, 4, "frvaddr4");
 
 	netdev = __vlan_find_dev_deep(card->dev, vid);
+	if (!netdev)
+		return;
 	in_dev = in_dev_get(netdev);
 	if (!in_dev)
 		return;
@@ -1786,6 +1788,8 @@ static void qeth_l3_free_vlan_addresses6(struct qeth_card *card,
 	QETH_CARD_TEXT(card, 4, "frvaddr6");
 
 	netdev = __vlan_find_dev_deep(card->dev, vid);
+	if (!netdev)
+		return;
 	in6_dev = in6_dev_get(netdev);
 	if (!in6_dev)
 		return;
-- 
1.7.11.3

^ permalink raw reply related

* [patch 2/3] [PATCH] netiucv: cleanup attribute usage
From: frank.blaschka @ 2012-07-25  8:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-s390, Sebastian Ott, Ursula Braun
In-Reply-To: <20120725083426.704834478@de.ibm.com>

[-- Attachment #1: 601-netiucv-attr-usage.diff --]
[-- Type: text/plain, Size: 2312 bytes --]

Let the driver core handle device attribute creation and removal. This
will simplify the code and eliminates races between attribute
availability and userspace notification via uevents.

Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Acked-by: Ursula Braun <ursula.braun@de.ibm.com>
---
 drivers/s390/net/netiucv.c | 34 ++++++----------------------------
 1 file changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index 8160591..4ffa66c 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1854,26 +1854,11 @@ static struct attribute_group netiucv_stat_attr_group = {
 	.attrs = netiucv_stat_attrs,
 };
 
-static int netiucv_add_files(struct device *dev)
-{
-	int ret;
-
-	IUCV_DBF_TEXT(trace, 3, __func__);
-	ret = sysfs_create_group(&dev->kobj, &netiucv_attr_group);
-	if (ret)
-		return ret;
-	ret = sysfs_create_group(&dev->kobj, &netiucv_stat_attr_group);
-	if (ret)
-		sysfs_remove_group(&dev->kobj, &netiucv_attr_group);
-	return ret;
-}
-
-static void netiucv_remove_files(struct device *dev)
-{
-	IUCV_DBF_TEXT(trace, 3, __func__);
-	sysfs_remove_group(&dev->kobj, &netiucv_stat_attr_group);
-	sysfs_remove_group(&dev->kobj, &netiucv_attr_group);
-}
+static const struct attribute_group *netiucv_attr_groups[] = {
+	&netiucv_stat_attr_group,
+	&netiucv_attr_group,
+	NULL,
+};
 
 static int netiucv_register_device(struct net_device *ndev)
 {
@@ -1887,6 +1872,7 @@ static int netiucv_register_device(struct net_device *ndev)
 		dev_set_name(dev, "net%s", ndev->name);
 		dev->bus = &iucv_bus;
 		dev->parent = iucv_root;
+		dev->groups = netiucv_attr_groups;
 		/*
 		 * The release function could be called after the
 		 * module has been unloaded. It's _only_ task is to
@@ -1904,22 +1890,14 @@ static int netiucv_register_device(struct net_device *ndev)
 		put_device(dev);
 		return ret;
 	}
-	ret = netiucv_add_files(dev);
-	if (ret)
-		goto out_unreg;
 	priv->dev = dev;
 	dev_set_drvdata(dev, priv);
 	return 0;
-
-out_unreg:
-	device_unregister(dev);
-	return ret;
 }
 
 static void netiucv_unregister_device(struct device *dev)
 {
 	IUCV_DBF_TEXT(trace, 3, __func__);
-	netiucv_remove_files(dev);
 	device_unregister(dev);
 }
 
-- 
1.7.11.3

^ permalink raw reply related

* [patch 1/3] [PATCH] net: wiznet add missing HAS_IOMEM dependency
From: frank.blaschka @ 2012-07-25  8:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-s390, Martin Schwidefsky
In-Reply-To: <20120725083426.704834478@de.ibm.com>

[-- Attachment #1: 600-wiznet-kconfig.diff --]
[-- Type: text/plain, Size: 705 bytes --]

The "WIZnet devices" config option should depend on HAS_IOMEM as
all wiznet drivers require it as well.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
 drivers/net/ethernet/wiznet/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/wiznet/Kconfig b/drivers/net/ethernet/wiznet/Kconfig
index cb18043..b4d2816 100644
--- a/drivers/net/ethernet/wiznet/Kconfig
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -4,6 +4,7 @@
 
 config NET_VENDOR_WIZNET
 	bool "WIZnet devices"
+	depends on HAS_IOMEM
 	default y
 	---help---
 	  If you have a network (Ethernet) card belonging to this class, say Y
-- 
1.7.11.3

^ permalink raw reply related

* [patch 0/3] s390: bug fixes for net
From: frank.blaschka @ 2012-07-25  8:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-s390

Hi Dave,

here are some bug fixes for net.

shortlog:

Martin Schwidefsky (1)
net: wiznet add missing HAS_IOMEM dependency

Sebastian Ott (1)
netiucv: cleanup attribute usage

Ursula Braun (1)
qeth: repair crash in qeth_l3_vlan_rx_kill_vid()

Thanks,
        Frank

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25  9:22 UTC (permalink / raw)
  To: Vlad Yasevich, Neil Horman
  Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <CA+=dFzifKwbiXmw=pu0+rWmz72+4jsbv6bXOBHyL0LmxaL9byg@mail.gmail.com>

On 7/25/12, Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
> On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>
>> Actually not true.  AUTH can be before SACK.  So can any addip chunks
>> that
>> aid in locating an association.
>>
>> Now AUTH isn't a big issue since its autogenerated to the packet but
>> ADDIP
>> is since it could be queued up for retransmission.
>>
>> There could be other extensions as well.  It really needs to be done
>> either
>> through side effects or making error chunks go at the end of other
>> control
>> chunks.  Need to audit the spec to see if that's ok.
> You are right, I just found SHUTDOWN chunks are also before SACK based on
> your commit "[SCTP]: Fix SACK sequence during shutdown".
> Maybe the only solution is to do some work on side effects just as you
> said.
> Thanks for your explanation!

And after take a moment to look into the relative codes, I think we
can implement it
by below way:
1). Add a flag(isi_err_needed) in the embedded struct peer of struct
struct sctp_association
just like sack_needed flag.
2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
function, we just
set isi_err_needed flag and don't create ERROR chunk and also don't
insert SCTP_CMD_REPLY command.
3). In sctp_gen_sack() function, we create ERROR chunk and also insert
SCTP_CMD_REPLY command if isi_err_needed flag is set.

Is this way proper?


Thanks,
Xufeng Zhang
>
>
>
> Thanks,
> Xufeng Zhang
>>
>> -vlad
>>>
>>>Thanks,
>>>Xufeng Zhang
>>>>
>>>> -vlad
>>
>>
>> --
>> Sent from my Android phone with SkitMail. Please excuse my brevity.
>>
>

^ permalink raw reply

* Re: iproute2 - IPsec ESN support
From: Steffen Klassert @ 2012-07-25  9:51 UTC (permalink / raw)
  To: Geanta Neag Horia Ioan-B05471
  Cc: netdev@vger.kernel.org, linux-crypto@vger.kernel.org,
	Stephen Hemminger
In-Reply-To: <FD18E5D573A8AB48A365D4D78185DE992602BD@039-SN1MPN1-001.039d.mgd.msft.net>

On Wed, Jul 25, 2012 at 06:14:52AM +0000, Geanta Neag Horia Ioan-B05471 wrote:
> Hello,
> 
> Is there any way to create an IPsec tunnel and indicate using
> extended sequnce numbers?

The strongswan ike deamon supports extended sequnce numbers.

> 
> It seems that currently iproute2 doesn't support this.
> Grepping for "esn" reveals that XFRM_STATE_ESN shows only in kernel headers.
> 
> The only relevant thing I found was a RFC sent by Steffen (Cc-ed),
> but it was never applied (don't know why):
> [RFC] iproute2: Add IPsec extended sequence number support

I'll take this as a reminder to respin this patch.

^ permalink raw reply

* skb_ts_get_next_block panic
From: kendo @ 2012-07-25  9:52 UTC (permalink / raw)
  To: netdev

My server every few days, or more than 10 days will restart,Probably because of the use of the Netfilter xt_string module,
But it seems not xt_string bug, but because of the bogus SKB buffer:


Jul 25 15:13:18 AnShion <9> klogd: [ 5413.055010] BUG: unable to handle kernel paging request at 2f3c0a3e
Jul 25 15:13:18 AnShion <9> klogd: [ 5413.130063] IP: [<c012c928>] kmap_atomic_prot+0x18/0xf0
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.192555] *pde = 00000000 
Jul 25 15:13:18 AnShion <8> klogd: [ 5413.227015] Oops: 0000 [#1] SMP 
Jul 25 15:13:18 AnShion <8> klogd: [ 5413.265738] last sysfs file: /sys/devices/virtual/net/bond0/bonding/slaves
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.347824] Modules linked in: igb e1000e
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.578307] 
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.596059] Pid: 0, comm: kworker/0:0 Tainted: G   M        2.6.38.8 #412 Intel Corporation S1200BTL/S1200BTL
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.715011] EIP: 0060:[<c012c928>] EFLAGS: 00010202 CPU: 1
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.780491] EIP is at kmap_atomic_prot+0x18/0xf0
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.835595] EAX: f48b2000 EBX: 00000163 ECX: 2f3c0a3e EDX: 00000163
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.910417] ESI: f1f95e40 EDI: 00000000 EBP: f48b3bc4 ESP: f48b3bb4
Jul 25 15:13:18 AnShion <12> klogd: [ 5413.985237]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 25 15:13:18 AnShion <8> klogd: [ 5414.049680] Process kworker/0:0 (pid: 0, ti=f48b2000 task=f48a8000 task.ti=f489e000)
Jul 25 15:13:18 AnShion <8> klogd: [ 5414.142138] Stack:
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.166117]  00000001 f48b3c6c f1f95e40 00000000 f48b3bcc c012ca0e f48b3bf4 c069ecde
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.259457]  00000004 eb636a80 f48b3c28 000005f8 00007365 00000000 f48b3c68 f1f9584e
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.352797]  f48b3bfc c069ed1e f48b3c38 c038c2da f48b3c68 f48b3c68 f11c9d20 f11c9d30
Jul 25 15:13:18 AnShion <8> klogd: [ 5414.446140] Call Trace:
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.475306]  [<c012ca0e>] __kmap_atomic+0xe/0x10
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.530416]  [<c069ecde>] skb_seq_read+0x19e/0x1d0
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.587597]  [<c069ed1e>] skb_ts_get_next_block+0xe/0x10
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.651007]  [<c038c2da>] kmp_find+0x3a/0x150
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.703003]  [<c069c842>] skb_find_text+0x62/0x90
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.759145]  [<c06faa3b>] string_mt+0x5b/0x90
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.811140]  [<c074a6b5>] ipt_do_table+0x295/0x3b0
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.868323]  [<c074b020>] iptable_mangle_hook+0x40/0x150
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.931729]  [<c06db8e7>] nf_iterate+0x67/0x90
Jul 25 15:13:18 AnShion <12> klogd: [ 5414.984760]  [<c0702040>] ? ip_forward_finish+0x0/0x60
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.046089]  [<c06dba90>] nf_hook_slow+0xa0/0xf0
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.101195]  [<c0702040>] ? ip_forward_finish+0x0/0x60
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.162525]  [<c070227d>] ip_forward+0x1dd/0x430
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.217631]  [<c0702040>] ? ip_forward_finish+0x0/0x60
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.278962]  [<c0700941>] ip_rcv_finish+0x241/0x3c0
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.337181]  [<c0700d66>] ip_rcv+0x2a6/0x320
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.388142]  [<c0700700>] ? ip_rcv_finish+0x0/0x3c0
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.446365]  [<c06a9518>] __netif_receive_skb+0x258/0x520
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.510811]  [<c01e8d10>] ? add_partial+0x40/0x70
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.566956]  [<c06a9913>] netif_receive_skb+0x23/0x50
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.627248]  [<c06a9a37>] napi_skb_finish+0x37/0x50
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.685469]  [<c06aa07b>] napi_gro_receive+0xdb/0xf0
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.744722]  [<c069d8bf>] ? consume_skb+0x4f/0x70
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.800881]  [<f815c79c>] igb_poll+0x5fc/0xef0 [igb]
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.860137]  [<c0819538>] ? _raw_spin_lock+0x8/0x10
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.918359]  [<c01e8d10>] ? add_partial+0x40/0x70
Jul 25 15:13:18 AnShion <12> klogd: [ 5415.974502]  [<c01eb8e7>] ? __slab_free+0xc7/0xd0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.030645]  [<c01eb8e7>] ? __slab_free+0xc7/0xd0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.086787]  [<c0819538>] ? _raw_spin_lock+0x8/0x10
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.145008]  [<c0125708>] ? default_spin_lock_flags+0x8/0x10
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.212568]  [<c0819568>] ? _raw_spin_lock_irqsave+0x28/0x40
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.280124]  [<c06a9eaa>] net_rx_action+0xaa/0x1a0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.337306]  [<c014bff1>] __do_softirq+0xb1/0x190
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.393445]  [<c014bf40>] ? __do_softirq+0x0/0x190
Jul 25 15:13:18 AnShion <8> klogd: [ 5416.450626]  <IRQ> 
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.475750]  [<c014bebd>] ? irq_exit+0x5d/0x80
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.528782]  [<c0104bc5>] ? do_IRQ+0x45/0xb0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.579736]  [<c014bed5>] ? irq_exit+0x75/0x80
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.632767]  [<c011c9f6>] ? smp_apic_timer_interrupt+0x56/0x90
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.702403]  [<c01036f0>] ? common_interrupt+0x30/0x38
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.763733]  [<c040e42e>] ? acpi_idle_enter_c1+0x78/0x95
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.827142]  [<c06740d9>] ? cpuidle_idle_call+0xd9/0x1c0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.890545]  [<c010214a>] ? cpu_idle+0x8a/0xc0
Jul 25 15:13:18 AnShion <12> klogd: [ 5416.943574]  [<c0813979>] ? start_secondary+0x1a1/0x1e8
Jul 25 15:13:18 AnShion <8> klogd: [ 5417.005943] Code: 74 26 00 8b 15 8c a4 d5 c1 55 89 e5 e8 e2 f8 ff ff 5d c3 55 89 c1 89 e5 57 56 53 89 d3 83 ec 04 89 e0 25 00 e0 ff ff 83 40 14 01 <8b> 01 c1 e8 1e 69 c0 80 03 00 00 05 00 79 b3 c0 2b 80 4c 03 00

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Neil Horman @ 2012-07-25 11:15 UTC (permalink / raw)
  To: Xufeng Zhang
  Cc: xufeng zhang, vyasevich, sri, davem, linux-sctp, netdev,
	linux-kernel
In-Reply-To: <CA+=dFzjW_=T6DwtRrSCxjzE9HKKvpQ=LUmGpAggJEujZT+VX+g@mail.gmail.com>

On Wed, Jul 25, 2012 at 10:34:32AM +0800, Xufeng Zhang wrote:
> On 7/24/12, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Tue, Jul 24, 2012 at 09:50:18AM +0800, xufeng zhang wrote:
> >> On 07/23/2012 08:14 PM, Neil Horman wrote:
> >> >On Mon, Jul 23, 2012 at 10:30:34AM +0800, xufeng zhang wrote:
> >> >>On 07/23/2012 08:49 AM, Neil Horman wrote:
> >> >>>Not sure I understand how you came into this error.  If we get an
> >> >>> invalid
> >> >>>stream, we issue an SCTP_REPORT_TSN side effect, followed by an
> >> >>> SCTP_CMD_REPLY
> >> >>>which sends the error chunk.  The reply goes through
> >> >>>sctp_outq_tail->sctp_outq_chunk->sctp_outq_transmit_chunk->sctp_outq_append_chunk.
> >> >>>That last function checks to see if a sack is already part of the
> >> >>> packet, and if
> >> >>>there isn't one, appends one, using the updated tsn map.
> >> >>Yes, you are right, but consider the invalid stream identifier's
> >> >>DATA chunk is the first
> >> >>DATA chunk in the association which will need SACK immediately.
> >> >>Here is what I thought of the scenario:
> >> >>     sctp_sf_eat_data_6_2()
> >> >>         -->sctp_eat_data()
> >> >>             -->sctp_make_op_error()
> >> >>             -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >> >> SCTP_CHUNK(err))
> >> >>             -->sctp_outq_tail()          /* First enqueue ERROR chunk
> >> >> */
> >> >>         -->sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE())
> >> >>             -->sctp_gen_sack()
> >> >>                 -->sctp_make_sack()
> >> >>                 -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >> >>SCTP_CHUNK(sack))
> >> >>                 -->sctp_outq_tail()          /* Then enqueue SACK chunk
> >> >> */
> >> >>
> >> >>So SACK chunk is enqueued after ERROR chunk.
> >> >Ah, I see.  Since the ERROR and SACK chunks are both control chunks, and
> >> > since
> >> >we explicitly add the SACK to the control queue instead of going through
> >> > the
> >> >bundle path in sctp_packet_append_chunk the ordering gets wrong.
> >> >
> >> >Ok, so the problem makes sense.  I think the soultion could be alot
> >> > easier
> >> >though.  IIRC SACK chunks always live at the head of a packet, so why not
> >> > just
> >> >special case it in sctp_outq_tail?  I.e. instead of doing a
> >> > list_add_tail, in
> >> >the else clause of sctp_outq_tail check the chunk_hdr->type to see if
> >> > its
> >> >SCTP_CID_SACK.  If it is, use list_add_head rather than list_add_tail.  I
> >> > think
> >> >that will fix up both the COOKIE_ECHO and ESTABLISHED cases, won't it?
> >> > And then
> >> >you won't have keep track of extra state in the packet configuration.
> >> Yes, it's a good idea, but I think the premise is not correct:
> >> RFC 4960 page 57:
> >> "D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply
> >>    with a COOKIE ACK chunk after building a TCB and moving to the
> >>    ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
> >>    pending DATA chunks (and/or SACK chunks), *but the COOKIE ACK chunk
> >>    MUST be the first chunk in the packet*."
> >>
> >> So we can't put SACK chunk always at the head of the packet.
> >>
> > Ok, Fair point, but that just changes the ordering a bit to:
> > COOKIE_ACK
> > SACK
> > OTHER CONTROL CHUNKS
> >
> > What about something like this?  Its completely untested, and I'm sure it
> > can be
> > cleaned up a bunch, but this keeps us from having to add additional state to
> > the
> > packet structure.
> Yeah! I like this modification, thank you very much for your work!
> I'll try to send a V2 patch based on your changes and run some tests.
> 
Awesome, thank you!
Neil

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Neil Horman @ 2012-07-25 11:27 UTC (permalink / raw)
  To: Xufeng Zhang
  Cc: Vlad Yasevich, xufeng zhang, sri, davem, linux-sctp, netdev,
	linux-kernel
In-Reply-To: <CA+=dFzgXq3Sx-Ny+6oDZ3BEdsMQCgswNEVPVnhmhedHFvazzWw@mail.gmail.com>

On Wed, Jul 25, 2012 at 05:22:19PM +0800, Xufeng Zhang wrote:
> On 7/25/12, Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
> > On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
> >>
> >> Actually not true.  AUTH can be before SACK.  So can any addip chunks
> >> that
> >> aid in locating an association.
> >>
> >> Now AUTH isn't a big issue since its autogenerated to the packet but
> >> ADDIP
> >> is since it could be queued up for retransmission.
> >>
> >> There could be other extensions as well.  It really needs to be done
> >> either
> >> through side effects or making error chunks go at the end of other
> >> control
> >> chunks.  Need to audit the spec to see if that's ok.
> > You are right, I just found SHUTDOWN chunks are also before SACK based on
> > your commit "[SCTP]: Fix SACK sequence during shutdown".
> > Maybe the only solution is to do some work on side effects just as you
> > said.
> > Thanks for your explanation!
> 
> And after take a moment to look into the relative codes, I think we
> can implement it
> by below way:
> 1). Add a flag(isi_err_needed) in the embedded struct peer of struct
> struct sctp_association
> just like sack_needed flag.
> 2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
> function, we just
> set isi_err_needed flag and don't create ERROR chunk and also don't
> insert SCTP_CMD_REPLY command.
> 3). In sctp_gen_sack() function, we create ERROR chunk and also insert
> SCTP_CMD_REPLY command if isi_err_needed flag is set.
> 
> Is this way proper?
> 
That would probably work yes.  Another way might just be to do some re-ordering
in sctp_outq_flush.  Before processing the control chunk list, scan it, and:
1) move all error chunks to the head of the list
2) move all sack chunks to the head of the list
3) move all shutdown chunks to the head of the list

You can do that in a single iteration of the list if you use a few on-stack
lists and list_splice

Neil

> 
> Thanks,
> Xufeng Zhang
> >
> >
> >
> > Thanks,
> > Xufeng Zhang
> >>
> >> -vlad
> >>>
> >>>Thanks,
> >>>Xufeng Zhang
> >>>>
> >>>> -vlad
> >>
> >>
> >> --
> >> Sent from my Android phone with SkitMail. Please excuse my brevity.
> >>
> >
> 

^ permalink raw reply

* [PATCH v0 net-next 1/1] net/pch_gpe: Cannot disable ethernet autonegation
From: w90p710 @ 2012-07-25 12:13 UTC (permalink / raw)
  To: davem; +Cc: netdev, Wei Yang

From: Wei Yang <w90p710@gmail.com>

When attempting to disable ethernet autonegation via ethtool,
the pch_gpe driver will set software reset bit of PHY chip, But 
control register of PHY chip of FRI2 will reenable ethernet autonegation.

Signed-off-by: Wei Yang <w90p710@gmail.com>
---
 .../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c    |    1 -
 .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c   |    4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
index ac4e72d..e2be4a7 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
@@ -129,7 +129,6 @@ static int pch_gbe_set_settings(struct net_device *netdev,
 	hw->mac.link_duplex = ecmd->duplex;
 	hw->phy.autoneg_advertised = ecmd->advertising;
 	hw->mac.autoneg = ecmd->autoneg;
-	pch_gbe_hal_phy_sw_reset(hw);
 
 	/* reset the link */
 	if (netif_running(adapter->netdev)) {
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 3787c64..8e6d2aa 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -1988,6 +1988,7 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
 void pch_gbe_down(struct pch_gbe_adapter *adapter)
 {
 	struct net_device *netdev = adapter->netdev;
+	struct pci_dev *pdev = adapter->pdev;
 	struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
 
 	/* signal that we're down so the interrupt handler does not
@@ -2004,7 +2005,8 @@ void pch_gbe_down(struct pch_gbe_adapter *adapter)
 	netif_carrier_off(netdev);
 	netif_stop_queue(netdev);
 
-	pch_gbe_reset(adapter);
+	if ((pdev->error_state) && (pdev->error_state != pci_channel_io_normal))
+		pch_gbe_reset(adapter);
 	pch_gbe_clean_tx_ring(adapter, adapter->tx_ring);
 	pch_gbe_clean_rx_ring(adapter, adapter->rx_ring);
 
-- 
1.7.9.5

^ permalink raw reply related

* RE: [PATCH] be2net: Missing byteswap in be_get_fw_log_level causes oops on PowerPC
From: Sathya.Perla @ 2012-07-25 12:18 UTC (permalink / raw)
  To: anton, subbu.seetharaman, Ajit.Khaparde, netdev
In-Reply-To: <20120725110525.0468f754@kryten>

>-----Original Message-----
>From: Anton Blanchard [mailto:anton@samba.org]
>
>We are seeing an oops in be_get_fw_log_level on ppc64 where we walk
>off the end of memory.
>
>commit 941a77d582c8 (be2net: Fix to allow get/set of debug levels in
>the firmware.) requires byteswapping of num_modes and num_modules.
>
>Cc: stable@vger.kernel.org # 3.5+
>Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Sathya Perla <sperla@emulex.com>

Thanks for the fix!
>---
>
>diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
>b/drivers/net/ethernet/emulex/benet/be_ethtool.c
>index 63e51d4..59ee51a 100644
>--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
>+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
>@@ -910,8 +910,9 @@ static void be_set_fw_log_level(struct be_adapter *adapter,
>u32 level)
> 	if (!status) {
> 		cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
> 					sizeof(struct be_cmd_resp_hdr));
>-		for (i = 0; i < cfgs->num_modules; i++) {
>-			for (j = 0; j < cfgs->module[i].num_modes; j++) {
>+		for (i = 0; i < le32_to_cpu(cfgs->num_modules); i++) {
>+			u32 num_modes = le32_to_cpu(cfgs-
>>module[i].num_modes);
>+			for (j = 0; j < num_modes; j++) {
> 				if (cfgs->module[i].trace_lvl[j].mode ==
> 								MODE_UART)
> 					cfgs->module[i].trace_lvl[j].dbg_lvl =
>diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
>b/drivers/net/ethernet/emulex/benet/be_main.c
>index 501dfa9..bd5cf7e 100644
>--- a/drivers/net/ethernet/emulex/benet/be_main.c
>+++ b/drivers/net/ethernet/emulex/benet/be_main.c
>@@ -3479,7 +3479,7 @@ u32 be_get_fw_log_level(struct be_adapter *adapter)
> 	if (!status) {
> 		cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
> 						sizeof(struct be_cmd_resp_hdr));
>-		for (j = 0; j < cfgs->module[0].num_modes; j++) {
>+		for (j = 0; j < le32_to_cpu(cfgs->module[0].num_modes); j++) {
> 			if (cfgs->module[0].trace_lvl[j].mode == MODE_UART)
> 				level = cfgs->module[0].trace_lvl[j].dbg_lvl;
> 		}

^ permalink raw reply

* Re: [PATCH net-next] netns: correctly use per-netns ipv4 sysctl_tcp_mem
From: Glauber Costa @ 2012-07-25 12:45 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Huang Qiang, David Miller, netdev, containers, yangzhenzhang
In-Reply-To: <1342677832.2626.3839.camel@edumazet-glaptop>

Hi,


On 07/19/2012 10:03 AM, Eric Dumazet wrote:
> On Thu, 2012-07-19 at 13:38 +0800, Huang Qiang wrote:
>> From: Yang Zhenzhang <yangzhenzhang@huawei.com>
>>
>> Now, kernel allows each net namespace to independently set up its levels
>> for tcp memory pressure thresholds.

Not really.

So the real limitation here, is done by the memory controller in cgroup,
not the proc files. AFAIK, lxc does not (yet) touches that file by
default, but it does create a memcg placeholder for you container, where
you can set that yourself.

cgroups are outside the realm of the admin, however. So once the
limitation is in place, you might want to restrain their further,
and that's the role of the files in /proc.

The goal is to have something that is as close as possible to a real
system in a container, where an admin could freely set this. (but of
course, never going over its allowance)

You can note this by what reads in sysctl_ipv4.c, when that file is
written to:

#ifdef CONFIG_MEMCG_KMEM
        rcu_read_lock();
        memcg = mem_cgroup_from_task(current);

        tcp_prot_mem(memcg, vec[0], 0);
        tcp_prot_mem(memcg, vec[1], 1);
        tcp_prot_mem(memcg, vec[2], 2);
        rcu_read_unlock();
#endif

This function is defined in tcp_memcontrol.c

void tcp_prot_mem(struct mem_cgroup *memcg, long val, int idx)
{
        struct tcp_memcontrol *tcp;
        struct cg_proto *cg_proto;

        cg_proto = tcp_prot.proto_cgroup(memcg);
        if (!cg_proto)
                return;

        tcp = tcp_from_cgproto(cg_proto);

        tcp->tcp_prot_mem[idx] = val;
}

tcp_prot_mem[] ends up being the vector you access as:

	prot = sk->sk_cgrp->sysctl_mem;

in the function you patch.

I hope it helps.

^ permalink raw reply

* open sockets preventing unregister_netdevice from completing in linux-next (next-20120724)
From: Bjørn Mork @ 2012-07-25 13:45 UTC (permalink / raw)
  To: netdev

I am currently researching several power management regressions in
linux-next as of next-20120724, spread over the PCI, USB and net
subsystems. This one I believe belongs to the net subsystem, although I
definitely may be wrong, mixing these together.

My test case is:

- open a ssh connection over a USB network device (qmi_wwan - which is why
  I am looking at this, but I really don't think it's the driver this time)
- suspend laptop with netdev and ssh connection up
- attempt to resume

The USB device will be gone on resume because it is power cycled, so the
drivers need to clean up, to let the device be rediscovered and bound
again.  But this does not happen anymore in linux-next as long as some
socket is open.  Instead we have these messages:

 Jul 25 15:13:11 nemi kernel: [ 7704.560306] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1
 Jul 25 15:13:21 nemi kernel: [ 7714.800308] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1
 Jul 25 15:13:31 nemi kernel: [ 7725.040316] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1


There are quite a few problems with the system in this state.  Any write
to the power/control associated with that USB device will hang,
presumably because the USB device does not exist anymore.  This will
also make new attempts to suspend fail.  And the USB device is of course
not functional.  The driver has not yet had a chance to clean up any of
the other devices associated with the dead USB device (wwan1,
/dev/cdc-wdm0 and /dev/cdc-wdm1), so these ghost devices will appear as
non- functional.  And new devices cannot be registered until the
previous USB device is deleted and a new one created.

Killing the ssh session let the unregister_netdevice continue and
everything will be cleaned up and go back to normal.

This is a regression compared to 3.5, where unregister_netdevice would
succeed regardless of any open sockets. Or maybe the sockets were
auto-reaped?  I don't know the inner details - just observing the
results.

The test case above is quite normal operational mode for me.  I often
leave open sessions while suspending (because I intend to continue using
them after resuming).  And I always forget that this won't work for the
USB modem case.  I don't really care either.  I expect the netdev to be
removed, routes deleted and any sockets referencing either should just
die or live on as zombies or whatever.  The important part is that they
should not prevent deletion of a netdev when e.g. the physical device is
gone. That's the way things used to work.



Bjørn

^ permalink raw reply

* re: bonding: sync netpoll code with bridge
From: Dan Carpenter @ 2012-07-25 13:47 UTC (permalink / raw)
  To: amwang; +Cc: netdev

Hello Amerigo Wang,

The patch 8a8efa22f51b: "bonding: sync netpoll code with bridge" from 
Feb 17, 2011, leads to the following warning:
drivers/net/bonding/bond_main.c:1849 bond_enslave()
	 error: scheduling with locks held: 'read_lock:&bond->lock'

drivers/net/bonding/bond_main.c
  1301          read_lock(&bond->lock);
  1302          bond_for_each_slave(bond, slave, i) {
  1303                  err = slave_enable_netpoll(slave);
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This can lead to a scheduling while atomic bug because it does a
GFP_KERNEL allocation and calls __netpoll_setup() which sleeps.

  1304                  if (err) {
  1305                          __bond_netpoll_cleanup(bond);
  1306                          break;
  1307                  }
  1308          }
  1309          read_unlock(&bond->lock);

Also later in the file:

  1848          if (slave_dev->npinfo) {
  1849                  if (slave_enable_netpoll(new_slave)) {
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We are holding read_lock(&bond->lock);

  1850                          read_unlock(&bond->lock);
  1851                          pr_info("Error, %s: master_dev is using netpoll, "
  1852                                   "but new slave device does not support netpoll.\n",
  1853                                   bond_dev->name);
  1854                          res = -EBUSY;
  1855                          goto err_detach;
  1856                  }

The easy way to trigger this warning is to test with
CONFIG_DEBUG_ATOMIC_SLEEP=y.

regards,
dan carpenter

^ permalink raw reply

* RE: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
From: KY Srinivasan @ 2012-07-25 14:10 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: olaf@aepfle.de, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
	netdev@vger.kernel.org, apw@canonical.com,
	devel@linuxdriverproject.org
In-Reply-To: <1343178644.5132.103.camel@deadeye.wl.decadent.org.uk>



> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> Sent: Tuesday, July 24, 2012 9:11 PM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; olaf@aepfle.de;
> apw@canonical.com; netdev@vger.kernel.org
> Subject: Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
> 
> On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> > In preparation to implementing IP injection, cleanup the way we propagate
> > and handle errors both in the driver as well as in the user level daemon.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> >  drivers/hv/hv_kvp.c      |  112 +++++++++++++++++++++++++++++++++++++-
> --------
> >  include/linux/hyperv.h   |   17 +++++---
> >  tools/hv/hv_kvp_daemon.c |   70 +++++++++++++++-------------
> >  3 files changed, 138 insertions(+), 61 deletions(-)
> >
> > diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> > index 0012eed..9b7fc4a 100644
> > --- a/drivers/hv/hv_kvp.c
> > +++ b/drivers/hv/hv_kvp.c
> [...]
> > @@ -109,27 +154,52 @@ kvp_cn_callback(struct cn_msg *msg, struct
> netlink_skb_parms *nsp)
> >  {
> >  	struct hv_kvp_msg *message;
> >  	struct hv_kvp_msg_enumerate *data;
> > +	int	error = 0;
> >
> >  	message = (struct hv_kvp_msg *)msg->data;
> > -	switch (message->kvp_hdr.operation) {
> > +
> > +	/*
> > +	 * If we are negotiating the version information
> > +	 * with the daemon; handle that first.
> > +	 */
> > +
> > +	if (in_hand_shake) {
> > +		if (kvp_handle_handshake(message))
> > +			in_hand_shake = false;
> > +		return;
> > +	}
> > +
> > +	/*
> > +	 * Based on the version of the daemon, we propagate errors from the
> > +	 * daemon differently.
> > +	 */
> > +
> > +	data = &message->body.kvp_enum_data;
> > +
> > +	switch (dm_reg_value) {
> >  	case KVP_OP_REGISTER:
> > -		pr_info("KVP: user-mode registering done.\n");
> > -		kvp_register();
> > -		kvp_transaction.active = false;
> > -		hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
> > +		/*
> > +		 * Null string is used to pass back error condition.
> > +		 */
> > +		if (!strlen(data->data.key))
> 
> Do we know that the key is null-terminated here?  Shouldn't we just
> check whether data->data.key[0] == 0?

Yes, currently we do return null string to indicate error.

> 
> > +			error = HV_S_CONT;
> >  		break;
> >
> > -	default:
> > -		data = &message->body.kvp_enum_data;
> > +	case KVP_OP_REGISTER1:
> >  		/*
> > -		 * Complete the transaction by forwarding the key value
> > -		 * to the host. But first, cancel the timeout.
> > +		 * We use the message header information from
> > +		 * the user level daemon to transmit errors.
> >  		 */
> > -		if (cancel_delayed_work_sync(&kvp_work))
> > -			kvp_respond_to_host(data->data.key,
> > -					 data->data.value,
> > -					!strlen(data->data.key));
> > +		error = *((int *)(&message->kvp_hdr.operation));
> [...]
> 
> What's with the casting (repeated in many other places)?  Wouldn't it be
> better to redefine struct hv_kvp_msg to start with something like:
> 
> 	union {
> 		struct hv_kvp_hdr	request;
> 		int			error;
> 	} kvp_hdr;

Agreed; will do.
> 
> Ben.
> 
> --
> Ben Hutchings
> If more than one person is responsible for a bug, no one is at fault.

^ permalink raw reply

* RE: [PATCH 08/17] Tools: hv: Gather subnet information
From: KY Srinivasan @ 2012-07-25 14:10 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org,
	olaf@aepfle.de, apw@canonical.com, netdev@vger.kernel.org
In-Reply-To: <1343178850.5132.104.camel@deadeye.wl.decadent.org.uk>



> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> Sent: Tuesday, July 24, 2012 9:14 PM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; olaf@aepfle.de;
> apw@canonical.com; netdev@vger.kernel.org
> Subject: Re: [PATCH 08/17] Tools: hv: Gather subnet information
> 
> On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> > Now gather sub-net information for the specified interface.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> >  tools/hv/hv_kvp_daemon.c |   31 +++++++++++++++++++++++++++++--
> >  1 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> > index 79eb130..2c24ebf 100644
> > --- a/tools/hv/hv_kvp_daemon.c
> > +++ b/tools/hv/hv_kvp_daemon.c
> > @@ -534,6 +534,7 @@ kvp_get_ip_address(int family, char *if_name, int op,
> >  	struct ifaddrs *ifap;
> >  	struct ifaddrs *curp;
> >  	int offset = 0;
> > +	int sn_offset = 0;
> >  	const char *str;
> >  	int error = 0;
> >  	char *buffer;
> > @@ -594,12 +595,38 @@ kvp_get_ip_address(int family, char *if_name, int op,
> >  			 * Gather info other than the IP address.
> >  			 * IP address info will be gathered later.
> >  			 */
> > -			if (curp->ifa_addr->sa_family == AF_INET)
> > +			if (curp->ifa_addr->sa_family == AF_INET) {
> >  				ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
> > -			else
> > +				/*
> > +				 * Get subnet info.
> > +				 */
> > +				error = kvp_process_ip_address(
> > +							curp->ifa_netmask,
> > +							AF_INET,
> > +							(char *)
> > +							ip_buffer->sub_net,
> > +							length,
> > +							&sn_offset);
> [...]
> 
> This is barely readable; why don't you indent the arguments by just one
> extra tab?

Will do.

Regards,

K. Y

^ permalink raw reply

* [PATCH net] net/mlx4_en: Limit the RFS filter IDs to be < RPS_NO_FILTER
From: Or Gerlitz @ 2012-07-25 14:35 UTC (permalink / raw)
  To: davem; +Cc: netdev, oren, Amir Vadai, Ben Hutchings, Or Gerliz

From: Amir Vadai <amirv@mellanox.com>

RFS filter id can't have the special value RPS_NO_FILTER, 
need to skip it when allocating id's.

Also, changed an ifdef into a more elegant IS_DEFINED.

CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Or Gerliz <ogerlitz@mellanox.com>
---

Addressing feedback from Ben Hutchings

 drivers/net/ethernet/mellanox/mlx4/en_cq.c     |    8 ++------
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c |    2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index aa9c2f6..866829b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -77,12 +77,8 @@ int mlx4_en_activate_cq(struct mlx4_en_priv *priv, struct mlx4_en_cq *cq,
 	struct mlx4_en_dev *mdev = priv->mdev;
 	int err = 0;
 	char name[25];
-	struct cpu_rmap *rmap =
-#ifdef CONFIG_RFS_ACCEL
-		priv->dev->rx_cpu_rmap;
-#else
-		NULL;
-#endif
+	struct cpu_rmap *rmap = IS_ENABLED(CONFIG_RFS_ACCEL) ?
+		priv->dev->rx_cpu_rmap : NULL;
 
 	cq->dev = mdev->pndev[priv->port];
 	cq->mcq.set_ci_db  = cq->wqres.db.db;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 8864d8b..edd9cb8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -201,7 +201,7 @@ mlx4_en_filter_alloc(struct mlx4_en_priv *priv, int rxq_index, __be32 src_ip,
 
 	filter->flow_id = flow_id;
 
-	filter->id = priv->last_filter_id++;
+	filter->id = priv->last_filter_id++ % RPS_NO_FILTER;
 
 	list_add_tail(&filter->next, &priv->filters);
 	hlist_add_head(&filter->filter_chain,
-- 
1.7.8.2

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox