* Re: [PATCH] ppp: add 64 bit stats
From: Kevin Groeneveld @ 2012-07-25 2:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <1343110954.2626.11040.camel@edumazet-glaptop>
On Tue, Jul 24, 2012 at 2:22 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-07-23 at 21:53 -0400, Kevin Groeneveld wrote:
>> On Mon, Jul 23, 2012 at 11:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> Would proper synchronization in this case just be wrapping the updates
>> >> in a spin_lock/spin_unlock?
>> >
>> > Would be fine (if the proper BH safe variant is used), or you could also
>> > use atomic64_t.
>>
>> Which would you recommend, spin locks or atomic64_t?
>>
>> atomic64_t seems like it would be simpler.
>
> Simpler but a bit more expensive when two counters are changed at the
> same time.
>
> (two atomic ops instead of a single one for the spinlock)
After looking at the existing ppp code more I wonder if I would even
need to add my own spinlocks. It seems the only spots I am updating
the 64 bit stats are already protected by either ppp->wlock or
ppp->rlock spinlocks. If I used two separate u64_stats_sync
structures, one for tx stats and one for rx stats, wouldn't the
existing spinlocks be enough?
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:28 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <75bdd73e-1c47-4fd6-bc29-5b86ee6da69a@email.android.com>
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?
Thanks,
Xufeng Zhang
>
> -vlad
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:34 UTC (permalink / raw)
To: Neil Horman
Cc: xufeng zhang, vyasevich, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20120724113802.GA30142@hmsreliant.think-freely.org>
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.
Thanks,
Xufeng Zhang
>
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e7aa177c..eeac32f 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -300,7 +300,7 @@ void sctp_outq_free(struct sctp_outq *q)
> int sctp_outq_tail(struct sctp_outq *q, struct sctp_chunk *chunk)
> {
> int error = 0;
> -
> + struct sctp_chunk *cptr;
> SCTP_DEBUG_PRINTK("sctp_outq_tail(%p, %p[%s])\n",
> q, chunk, chunk && chunk->chunk_hdr ?
> sctp_cname(SCTP_ST_CHUNK(chunk->chunk_hdr->type))
> @@ -344,7 +344,21 @@ int sctp_outq_tail(struct sctp_outq *q, struct
> sctp_chunk *chunk)
> break;
> }
> } else {
> - list_add_tail(&chunk->list, &q->control_chunk_list);
> + list_del_init(&chunk->list);
> + if (chunk->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + list_add_head(&chunk->list, &q->control_chunk_list);
> + else if (!list_empty(&q->control_chunk_list) &&
> + chunk->chunk_hdr->type == SCTP_CID_SACK) {
> + list_for_each_entry(cptr, &q->control_chunk_list, list) {
> + if (cptr->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + continue;
> + list_add(&chunk->list, &cptr->list);
> + break;
> + }
> + }
> +
> + if (list_empty(&chunk->list))
> + list_add_tail(&chunk->list, &q->control_chunk_list);
> SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> }
>
>>
>> Thanks,
>> Xufeng Zhang
>> >Regards
>> >Neil
>> >
>> >
>>
>
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Eric Dumazet @ 2012-07-25 4:04 UTC (permalink / raw)
To: Kevin Groeneveld; +Cc: netdev
In-Reply-To: <CABF+-6Wpn8yEvru1FDsaFbXYZ7tyeQqqbEU2VY8hLKvmXXFBXA@mail.gmail.com>
On Tue, 2012-07-24 at 22:27 -0400, Kevin Groeneveld wrote:
> After looking at the existing ppp code more I wonder if I would even
> need to add my own spinlocks. It seems the only spots I am updating
> the 64 bit stats are already protected by either ppp->wlock or
> ppp->rlock spinlocks. If I used two separate u64_stats_sync
> structures, one for tx stats and one for rx stats, wouldn't the
> existing spinlocks be enough?
It there are spinlocks already, why even adding u64_stats_sync ?
Just use existing spinlocks to protect your new u64 fields (in the
ngso_get_stats64())
^ permalink raw reply
* [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Li Wei @ 2012-07-25 5:25 UTC (permalink / raw)
To: David Miller; +Cc: David.Laight, netdev, shemminger
In-Reply-To: <20120720.112241.2111041227435292899.davem@davemloft.net>
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;
--
1.7.10.1
^ permalink raw reply related
* iproute2 - IPsec ESN support
From: Geanta Neag Horia Ioan-B05471 @ 2012-07-25 6:14 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Cc: Stephen Hemminger, Steffen Klassert
Hello,
Is there any way to create an IPsec tunnel and indicate using
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
http://patchwork.ozlabs.org/patch/85962/
Thank you,
Horia
^ permalink raw reply
* 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
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