* Re: Increased multicast packet drops in 3.4
From: Shawn Bohrer @ 2012-09-06 13:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1346912560.13121.175.camel@edumazet-glaptop>
On Thu, Sep 06, 2012 at 08:22:40AM +0200, Eric Dumazet wrote:
> On Wed, 2012-09-05 at 19:11 -0500, Shawn Bohrer wrote:
> > I've been testing the 3.4 kernel compared to the 3.1 kernel and
> > noticed my application is experiencing a noticeable increase in packet
> > drops compared to 3.1. In this case I have 8 processes all listening
> > on the same multicast group and occasionally 1 or more of the
> > processes will report drops based on gaps in the sequence numbers on
> > the packets. One thing I find interesting is that some of the time 2
> > or 3 of the 8 processes will report that they missed the exact same
> > 50+ packets. Since the other processes receive the packets I know
> > that they are making it to the machine and past the driver.
> >
> > So far I have not been able to _see_ any OS counters increase when the
> > drops occur but perhaps there is a location that I have not yet
> > looked. I've been looking for drops in /proc/net/udp /proc/net/snmp
> > and /proc/net/dev.
> >
> > I've tried using dropwatch/drop_monitor but it is awfully noisy even
> > after back porting many of the patches Eric Dumazet has contributed to
> > silence the false positives. Similarly I setup trace-cmd/ftrace to
> > record skb:kfree_skb calls with a stacktrace and had my application
> > stop the trace when a drop was reported. From these traces I see a
> > number of the following:
> >
> > md_connector-12791 [014] 7952.982818: kfree_skb: skbaddr=0xffff880583bd7500 protocol=2048 location=0xffffffff813c930b
> > md_connector-12791 [014] 7952.982821: kernel_stack: <stack trace>
> > => skb_release_data (ffffffff813c930b)
> > => __kfree_skb (ffffffff813c934e)
> > => skb_free_datagram_locked (ffffffff813ccca8)
> > => udp_recvmsg (ffffffff8143335c)
> > => inet_recvmsg (ffffffff8143cbfb)
> > => sock_recvmsg_nosec (ffffffff813be80f)
> > => __sys_recvmsg (ffffffff813bfe70)
> > => __sys_recvmmsg (ffffffff813c2392)
> > => sys_recvmmsg (ffffffff813c25b0)
> > => system_call_fastpath (ffffffff8148cfd2)
> >
> > Looking at the code it does look like these could be the drops, since
> > I do not see any counters incremented in this code path. However I'm
> > not very familiar with this code so it could also be a false positive.
> > It does look like the above stack only gets called if
> > skb_has_frag_list(skb) does this imply the packet was over one MTU
> > (1500)?
> >
> > I'd appreciate any input on possible causes/solutions for these drops.
> > Or ways that I can further debug this issue to find the root cause of
> > the increase in drops on 3.4.
> >
> > Thanks,
> > Shawn
> >
>
> What NIC driver are you using ?
$ sudo ethtool -i eth4
driver: mlx4_en
version: 2.0 (Dec 2011)
firmware-version: 2.10.700
bus-info: 0000:05:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
This is the in tree driver from 3.4.9
[ sbohrer@berbox12:/home/sbohrer ]
$ /sbin/lspci | grep -i mell
05:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
> Could you trace if skb_copy_and_csum_datagram_iovec() or
> skb_copy_datagram_iovec() returns an error (it could be EFAULT by
> example) ?
>
> If so, you could add some debugging to these functions to track what
> exact error it is
>
> It seems following patch is needed anyway :
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 6f6d1ac..2c965c9 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1226,6 +1226,8 @@ try_again:
>
> if (unlikely(err)) {
> trace_kfree_skb(skb, udp_recvmsg);
> + if (!peeked)
> + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
> goto out_free;
> }
Sorry, I should have mentioned that it doesn't appear I'm hitting that
tracepoint. That tracepoint would have a location=udp_recvmsg and I
believe the stack trace would also start at udp_recvmsg. I didn't see
any of these in the traces I captured.
I think the one I'm hitting is the following with some of my own extra
annotation:
=> kfree_skb()
=> skb_drop_list()
=> skb_drop_fraglist()
> > => skb_release_data (ffffffff813c930b)
=> skb_release_all()
> > => __kfree_skb (ffffffff813c934e)
> > => skb_free_datagram_locked (ffffffff813ccca8)
> > => udp_recvmsg (ffffffff8143335c)
> > => inet_recvmsg (ffffffff8143cbfb)
> > => sock_recvmsg_nosec (ffffffff813be80f)
> > => __sys_recvmsg (ffffffff813bfe70)
> > => __sys_recvmmsg (ffffffff813c2392)
> > => sys_recvmmsg (ffffffff813c25b0)
> > => system_call_fastpath (ffffffff8148cfd2)
kfree_skb() has the trace_kfree_skb() call on net/core/skbuff.c:3283
I can of course still try your patch and double check that I'm not
hitting that one.
Thanks,
Shawn
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
^ permalink raw reply
* [PATCH] iproute2: Fix various manpage formatting nits
From: Andreas Schwab @ 2012-09-06 13:09 UTC (permalink / raw)
To: netdev
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
man/man8/ip-route.8.in | 10 +++++-----
man/man8/ip.8 | 4 ++--
man/man8/ss.8 | 2 +-
man/man8/tc-choke.8 | 8 ++++----
man/man8/tc-drr.8 | 1 +
man/man8/tc-ematch.8 | 25 +++++++++++--------------
6 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 0ca6107..f06fcba 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -202,11 +202,10 @@ error.
are considered to be dummy (or external) addresses which require translation
to real (or internal) ones before forwarding. The addresses to translate to
are selected with the attribute
+.BR "via" .
.B Warning:
Route NAT is no longer supported in Linux 2.6.
-
-.BR "via" .
.sp
.B anycast
.RI "- " "not implemented"
@@ -306,7 +305,7 @@ If this parameter is omitted,
assumes the
.B main
table, with the exception of
-.BR local " , " broadcast " and " nat
+.BR local ", " broadcast " and " nat
routes, which are put into the
.B local
table by default.
@@ -560,13 +559,14 @@ i.e. it lists the entire table.
.TP
.BI tos " TOS"
+.TP
.BI dsfield " TOS"
only select routes with the given TOS.
.TP
.BI table " TABLEID"
-show the routes from this table(s). The default setting is to show
-.BR table main "."
+show the routes from this table(s). The default setting is to show table
+.BR main "."
.I TABLEID
may either be the ID of a real table or one of the special values:
.sp
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 9ba3621..ac78c29 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -85,11 +85,11 @@ shortcut for
.BR "\-o" , " \-oneline"
output each record on a single line, replacing line feeds
with the
-.B '\e\'
+.B '\e'
character. This is convenient when you want to count records
with
.BR wc (1)
- or to
+or to
.BR grep (1)
the output.
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 0b9a8c4..f03c6d8 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -14,7 +14,7 @@ It can display more TCP and state informations than other tools.
.SH OPTIONS
When no option is used ss displays a list of
open non-listening TCP sockets that have established connection.
-.TP
+.P
These programs follow the usual GNU command line syntax, with long
options starting with two dashes (`-').
A summary of options is included below.
diff --git a/man/man8/tc-choke.8 b/man/man8/tc-choke.8
index 620c7f6..9d1081f 100644
--- a/man/man8/tc-choke.8
+++ b/man/man8/tc-choke.8
@@ -30,11 +30,11 @@ queue. If both the to-be-queued and the drawn packet belong to the same flow,
both packets are dropped. Otherwise, if the queue length is still below the maximum length,
the new packet has a configurable chance of being marked (which may mean dropped).
If the queue length exceeds
-.B max
-, the new packet will always be marked (or dropped).
+.BR max ,
+the new packet will always be marked (or dropped).
If the queue length exceeds
-.B limit
-, the new packet is always dropped.
+.BR limit ,
+the new packet is always dropped.
The marking probability computation is the same as used by the RED qdisc.
diff --git a/man/man8/tc-drr.8 b/man/man8/tc-drr.8
index e25d6dd..29daed8 100644
--- a/man/man8/tc-drr.8
+++ b/man/man8/tc-drr.8
@@ -45,6 +45,7 @@ To attach to device eth0, using the interface MTU as its quantum:
Adding two classes:
.P
# tc class add dev eth0 parent 1: classid 1:1 drr
+.br
# tc class add dev eth0 parent 1: classid 1:2 drr
.P
You also need to add at least one filter to classify packets.
diff --git a/man/man8/tc-ematch.8 b/man/man8/tc-ematch.8
index 53ae161..2eafc29 100644
--- a/man/man8/tc-ematch.8
+++ b/man/man8/tc-ematch.8
@@ -21,7 +21,7 @@ ematch \- extended matches for use with "basic" or "flow" filters
]
.ti -8
-.IR TERM " := [ " not " ] { " MATCH " | '(' " EXPR " ')' } "
+.IR TERM " := [ " \fBnot " ] { " MATCH " | '(' " EXPR " ')' } "
.ti -8
.IR MATCH " := " module " '(' " ARGS " ')' "
@@ -34,30 +34,27 @@ ematch \- extended matches for use with "basic" or "flow" filters
.SS cmp
Simple comparison ematch: arithmetic compare of packet data to a given value.
.ti
-.IR cmp "( " ALIGN " at " OFFSET " [ " ATTRS " ] { " eq " | " lt " | " gt " } " VALUE " )
+.IR cmp "( " ALIGN " at " OFFSET " [ " ATTRS " ] { " eq " | " lt " | " gt " } " VALUE " )
.ti
.IR ALIGN " := { " u8 " | " u16 " | " u32 " } "
.ti
-.IR ATTRS " := [ layer " LAYER " ] [ mask " MASK " ] [ " trans " ] "
+.IR ATTRS " := [ layer " LAYER " ] [ mask " MASK " ] [ trans ]
.ti
-.IR ALIGN " := { " u8 " | " u16 " | " u32 } "
-
-.ti
-.IR LAYER " := { " link " | " network " | " transport " | " 0..%d " }
+.IR LAYER " := { " link " | " network " | " transport " | " 0..2 " }
.SS meta
Metadata ematch
.ti
-.IR meta "( " OBJECT " { " eq " | " lt " |" gt " } " OBJECT " )
+.IR meta "( " OBJECT " { " eq " | " lt " |" gt " } " OBJECT " )
.ti
.IR OBJECT " := { " META_ID " | " VALUE " }
.ti
-.IR META_ID " := id " [ shift " SHIFT " ] [ mask " MASK " ]
+.IR META_ID " := " id " [ shift " SHIFT " ] [ mask " MASK " ]
.TP
meta attributes:
@@ -91,26 +88,26 @@ match packet data byte sequence
.IR OFFSET " := " int
.ti
-.IR LAYER " := { " link " | " network " | " transport " | " 0..%d " }
+.IR LAYER " := { " link " | " network " | " transport " | " 0..2 " }
.SS u32
u32 ematch
.ti
-.IR u32 "( " ALIGN VALUE MASK " at " [ nexthdr+ ] " OFFSET " )
+.IR u32 "( " ALIGN " " VALUE " " MASK " at [ nexthdr+ ] " OFFSET " )
.ti
-.IR ALIGN " := " { " u8 " | " u16 " | " u32 " }
+.IR ALIGN " := { " u8 " | " u16 " | " u32 " }
.SS ipset
test packet agains ipset membership
.ti
-.IR ipset "( " SETNAME FLAGS )
+.IR ipset "( " SETNAME " " FLAGS " )
.ti
.IR SETNAME " := " string
.ti
-.IR FLAGS " := " { " FLAG " [, " FLAGS "] }
+.IR FLAGS " := { " FLAG " [, " FLAGS "] }
The flag options are the same as those used by the iptables "set" match.
--
1.7.12
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: usbnet: fix oops in usbnet_start_xmit
From: Oliver Neukum @ 2012-09-06 13:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: khlebnikov-GEFAQzZX7r8dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120906125230.GI19410@mwanda>
On Thursday 06 September 2012 05:52:30 Dan Carpenter wrote:
> I sent this email a year ago when the patch was committed but I
> never received a response.
I probably should have checked then.
> regards,
> dan carpenter
>
> On Wed, Nov 09, 2011 at 10:34:59AM +0300, Dan Carpenter wrote:
> > Hello Konstantin Khlebnikov,
> >
> > This is a semi-automatic email about new static checker warnings.
> >
> > The patch 23ba07991dad: "usbnet: fix oops in usbnet_start_xmit" from
> > Nov 7, 2011, leads to the following Smatch complaint:
> >
> > drivers/net/usb/usbnet.c +1077 usbnet_start_xmit()
> > error: we previously assumed 'skb' could be null (see line 1060)
> >
> > drivers/net/usb/usbnet.c
> > 1059
> > 1060 if (skb)
> > ^^^
> > check introduced here.
> >
> > 1061 skb_tx_timestamp(skb);
> > 1062
> > 1063 // some devices want funky USB-level framing, for
> > 1064 // win32 driver (usually) and/or hardware quirks
> > 1065 if (info->tx_fixup) {
> > 1066 skb = info->tx_fixup (dev, skb, GFP_ATOMIC);
It turns out that skb == NULL implies info->tx_fixup != NULL
and skb will be reassigned.
This is very dirty.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Increased multicast packet drops in 3.4
From: Eric Dumazet @ 2012-09-06 13:21 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev
In-Reply-To: <20120906130316.GA2310@BohrerMBP.gateway.2wire.net>
On Thu, 2012-09-06 at 08:03 -0500, Shawn Bohrer wrote:
> On Thu, Sep 06, 2012 at 08:22:40AM +0200, Eric Dumazet wrote:
> > On Wed, 2012-09-05 at 19:11 -0500, Shawn Bohrer wrote:
> > > I've been testing the 3.4 kernel compared to the 3.1 kernel and
> > > noticed my application is experiencing a noticeable increase in packet
> > > drops compared to 3.1. In this case I have 8 processes all listening
> > > on the same multicast group and occasionally 1 or more of the
> > > processes will report drops based on gaps in the sequence numbers on
> > > the packets. One thing I find interesting is that some of the time 2
> > > or 3 of the 8 processes will report that they missed the exact same
> > > 50+ packets. Since the other processes receive the packets I know
> > > that they are making it to the machine and past the driver.
> > >
> > > So far I have not been able to _see_ any OS counters increase when the
> > > drops occur but perhaps there is a location that I have not yet
> > > looked. I've been looking for drops in /proc/net/udp /proc/net/snmp
> > > and /proc/net/dev.
> > >
> > > I've tried using dropwatch/drop_monitor but it is awfully noisy even
> > > after back porting many of the patches Eric Dumazet has contributed to
> > > silence the false positives. Similarly I setup trace-cmd/ftrace to
> > > record skb:kfree_skb calls with a stacktrace and had my application
> > > stop the trace when a drop was reported. From these traces I see a
> > > number of the following:
> > >
> > > md_connector-12791 [014] 7952.982818: kfree_skb: skbaddr=0xffff880583bd7500 protocol=2048 location=0xffffffff813c930b
> > > md_connector-12791 [014] 7952.982821: kernel_stack: <stack trace>
> > > => skb_release_data (ffffffff813c930b)
> > > => __kfree_skb (ffffffff813c934e)
> > > => skb_free_datagram_locked (ffffffff813ccca8)
> > > => udp_recvmsg (ffffffff8143335c)
> > > => inet_recvmsg (ffffffff8143cbfb)
> > > => sock_recvmsg_nosec (ffffffff813be80f)
> > > => __sys_recvmsg (ffffffff813bfe70)
> > > => __sys_recvmmsg (ffffffff813c2392)
> > > => sys_recvmmsg (ffffffff813c25b0)
> > > => system_call_fastpath (ffffffff8148cfd2)
> > >
> > > Looking at the code it does look like these could be the drops, since
> > > I do not see any counters incremented in this code path. However I'm
> > > not very familiar with this code so it could also be a false positive.
> > > It does look like the above stack only gets called if
> > > skb_has_frag_list(skb) does this imply the packet was over one MTU
> > > (1500)?
> > >
> > > I'd appreciate any input on possible causes/solutions for these drops.
> > > Or ways that I can further debug this issue to find the root cause of
> > > the increase in drops on 3.4.
> > >
> > > Thanks,
> > > Shawn
> > >
> >
> > What NIC driver are you using ?
>
> $ sudo ethtool -i eth4
> driver: mlx4_en
> version: 2.0 (Dec 2011)
> firmware-version: 2.10.700
> bus-info: 0000:05:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: no
>
> This is the in tree driver from 3.4.9
>
> [ sbohrer@berbox12:/home/sbohrer ]
> $ /sbin/lspci | grep -i mell
> 05:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
>
> > Could you trace if skb_copy_and_csum_datagram_iovec() or
> > skb_copy_datagram_iovec() returns an error (it could be EFAULT by
> > example) ?
> >
> > If so, you could add some debugging to these functions to track what
> > exact error it is
> >
> > It seems following patch is needed anyway :
> >
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 6f6d1ac..2c965c9 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -1226,6 +1226,8 @@ try_again:
> >
> > if (unlikely(err)) {
> > trace_kfree_skb(skb, udp_recvmsg);
> > + if (!peeked)
> > + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
> > goto out_free;
> > }
>
> Sorry, I should have mentioned that it doesn't appear I'm hitting that
> tracepoint. That tracepoint would have a location=udp_recvmsg and I
> believe the stack trace would also start at udp_recvmsg. I didn't see
> any of these in the traces I captured.
>
> I think the one I'm hitting is the following with some of my own extra
> annotation:
>
> => kfree_skb()
> => skb_drop_list()
> => skb_drop_fraglist()
> > > => skb_release_data (ffffffff813c930b)
> => skb_release_all()
> > > => __kfree_skb (ffffffff813c934e)
> > > => skb_free_datagram_locked (ffffffff813ccca8)
> > > => udp_recvmsg (ffffffff8143335c)
> > > => inet_recvmsg (ffffffff8143cbfb)
> > > => sock_recvmsg_nosec (ffffffff813be80f)
> > > => __sys_recvmsg (ffffffff813bfe70)
> > > => __sys_recvmmsg (ffffffff813c2392)
> > > => sys_recvmmsg (ffffffff813c25b0)
> > > => system_call_fastpath (ffffffff8148cfd2)
>
> kfree_skb() has the trace_kfree_skb() call on net/core/skbuff.c:3283
>
> I can of course still try your patch and double check that I'm not
> hitting that one.
kfree_skb() can free a list of skb, and we use a generic function to do
so, without forwarding the drop/notdrop status. So its unfortunate, but
adding extra parameters just for the sake of drop_monitor is not worth
it. skb_drop_fraglist() doesnt know if the parent skb is dropped or
only freed, so it calls kfree_skb(), not consume_skb() or kfree_skb()
Are you receiving fragmented UDP frames ?
I ask this because with latest kernels (linux-3.5), we should no longer
build a list of skb, but a single skb with page fragments.
commit 3cc4949269e01f39443d0fcfffb5bc6b47878d45
Author: Eric Dumazet <edumazet@google.com>
Date: Sat May 19 03:02:20 2012 +0000
ipv4: use skb coalescing in defragmentation
ip_frag_reasm() can use skb_try_coalesce() to build optimized skb,
reducing memory used by them (truesize), and reducing number of cache
line misses and overhead for the consumer.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: IPv6 routing type - not at par with IPv4 one?
From: Nicolas Dichtel @ 2012-09-06 13:21 UTC (permalink / raw)
To: Markus; +Cc: Eric Dumazet, Markus Stenberg, netdev
In-Reply-To: <7F0FC925-D0A4-4E27-AE8A-F2E0A619FB36@iki.fi>
Le 06/09/2012 12:54, Markus a écrit :
> On 6.9.2012, at 13.35, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Well, it seems you missed this :
>>
>> http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=ef2c7d7b59708d54213c7556a82d14de9a7e4475
>>
>> At least the blackhole is now supported on IPv6, so you probably have to
>> add the 'throw' bit, if it makes any sense.
>
>
> Ah, cool, teaches me to refresh my git trees before posting ;-)
> Nicolas, want to update for that too or will I?
Ok, I will send another patch for this.
Thank you,
Nicolas
^ permalink raw reply
* Re: Increased multicast packet drops in 3.4
From: Eric Dumazet @ 2012-09-06 13:31 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev
In-Reply-To: <1346937667.2484.33.camel@edumazet-glaptop>
On Thu, 2012-09-06 at 15:21 +0200, Eric Dumazet wrote:
>
> Are you receiving fragmented UDP frames ?
>
> I ask this because with latest kernels (linux-3.5), we should no longer
> build a list of skb, but a single skb with page fragments.
>
> commit 3cc4949269e01f39443d0fcfffb5bc6b47878d45
> Author: Eric Dumazet <edumazet@google.com>
> Date: Sat May 19 03:02:20 2012 +0000
>
> ipv4: use skb coalescing in defragmentation
>
> ip_frag_reasm() can use skb_try_coalesce() to build optimized skb,
> reducing memory used by them (truesize), and reducing number of cache
> line misses and overhead for the consumer.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
Unfortunately mlx4 pulls too many bytes from the frame to skb->head, so
it defeats coalescing completely.
Try following patch (if you also try linux-3.5)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 9d27e42..700e70e 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -150,7 +150,7 @@ enum {
#define ETH_LLC_SNAP_SIZE 8
#define SMALL_PACKET_SIZE (256 - NET_IP_ALIGN)
-#define HEADER_COPY_SIZE (128 - NET_IP_ALIGN)
+#define HEADER_COPY_SIZE ETH_HLEN
#define MLX4_LOOPBACK_TEST_PAYLOAD (HEADER_COPY_SIZE - ETH_HLEN)
#define MLX4_EN_MIN_MTU 46
^ permalink raw reply related
* [PATCH net-next] ipv6: fix handling of throw routes
From: Nicolas Dichtel @ 2012-09-06 15:53 UTC (permalink / raw)
To: davem; +Cc: netdev, markus.stenberg, eric.dumazet, Nicolas Dichtel
In-Reply-To: <5048A374.60005@6wind.com>
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <markus.stenberg@iki.fi>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/route.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fa26444..339d921 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1471,6 +1471,9 @@ int ip6_route_add(struct fib6_config *cfg)
case RTN_PROHIBIT:
rt->dst.error = -EACCES;
break;
+ case RTN_THROW:
+ rt->dst.error = -EAGAIN;
+ break;
default:
rt->dst.error = -ENETUNREACH;
break;
@@ -2275,7 +2278,8 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
if (rtm->rtm_type == RTN_UNREACHABLE ||
rtm->rtm_type == RTN_BLACKHOLE ||
- rtm->rtm_type == RTN_PROHIBIT)
+ rtm->rtm_type == RTN_PROHIBIT ||
+ rtm->rtm_type == RTN_THROW)
cfg->fc_flags |= RTF_REJECT;
if (rtm->rtm_type == RTN_LOCAL)
@@ -2412,6 +2416,9 @@ static int rt6_fill_node(struct net *net,
case -EACCES:
rtm->rtm_type = RTN_PROHIBIT;
break;
+ case -EAGAIN:
+ rtm->rtm_type = RTN_THROW;
+ break;
default:
rtm->rtm_type = RTN_UNREACHABLE;
break;
--
1.7.12
^ permalink raw reply related
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-09-06 13:53 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Pedro Alves, Steven Rostedt, Tejun Heo, torvalds, akpm,
linux-kernel, linux-mm, paul.gortmaker, davem, mingo, ebiederm,
aarcange, ericvh, netdev, josh, eric.dumazet, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <20120904170138.GB31934@Krystal>
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
>> #define do_for_each_ftrace_rec(pg, rec) \
>> > for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
>> > pg && rec == &pg->records[pg->index]; \
>> > pg = pg->next) \
>> > for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
> Maybe in some cases there might be ways to combine the two loops into
> one ? I'm not seeing exactly how to do it for this one, but it should
> not be impossible. If the inner loop condition can be moved to the outer
> loop, and if we use (blah ? loop1_conf : loop2_cond) to test for
> different conditions depending on the context, and do the same for the
> 3rd argument of the for() loop. The details elude me for now though, so
> maybe it's complete non-sense ;)
>
> It might not be that useful for do_for_each_ftrace_rec, but if we can do
> it for the hash table iterator, it might be worth it.
So I think that for the hash iterator it might actually be simpler.
My solution to making 'break' work in the iterator is:
for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
hlist_for_each_entry(obj, node, &name[bkt], member)
We initialize our node loop cursor with NULL in the external loop, and the
external loop will have a new condition to loop while that cursor is NULL.
My logic is that we can only 'break' when we are iterating over an object in the
internal loop. If we're iterating over an object in that loop then 'node != NULL'.
This way, if we broke from within the internal loop, the external loop will see
node as not NULL, and so it will stop looping itself. On the other hand, if the
internal loop has actually ended, then node will be NULL, and the outer loop
will keep running.
Is there anything I've missed?
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: CBQ(but probably u32 filter bug), kernel "freeze", at least from 3.2.0
From: Denys Fedoryshchenko @ 2012-09-06 13:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1346920806.13121.180.camel@edumazet-glaptop>
On 2012-09-06 11:40, Eric Dumazet wrote:
> On Tue, 2012-08-28 at 03:59 -0700, Eric Dumazet wrote:
>> On Tue, 2012-08-28 at 07:50 +0300, Denys Fedoryshchenko wrote:
>> > Hi
>> >
>> > Got information from friend, confirmed that it crashed at least
>> two my
>> > boxes also :)
>> > 3.0.5-rc1 is working fine, 3.4.1 , 3.2.0 from ubuntu - crashing
>> > No watchdog fired, and didn't got yet significant debugging
>> > information.
>> >
>> > Very easy to reproduce:
>> > 1)run the script
>> > 2)ping 192.168.3.234
>> >
>> > script:
>> > DEV_OUT=eth0
>> > ICMP="match ip protocol 1 0xff"
>> > U32="protocol ip u32"
>> > DST="match ip dst"
>> > tc qdisc add dev $DEV_OUT root handle 1: cbq avpkt 1000 bandwidth
>> > 100mbit
>> > tc class add dev $DEV_OUT parent 1: classid 1:1 cbq rate 512kbit
>> allot
>> > 1500 prio 5 bounded isolated
>> > tc filter add dev $DEV_OUT parent 1: prio 3 $U32
>> $ICMP
>> > $DST 192.168.3.234 flowid 1:
>> > tc qdisc add dev $DEV_OUT parent 1:1 sfq perturb 10
>>
>> Not sure what your friend expected from this buggy configuration.
>>
>> It probably never worked at all.
>>
>> CBQ needs at least one child class and one leaf class.
>>
>> This scripts creates a loop inside CBQ, so cpu is probably looping
>> in
>> cbq_enqueue() (or more exactly cbq_classify()), as instructed by the
>> sysadmin ;)
>>
>> u32 (or sfq) seems ok.
>>
>> Could you try the following patch ?
>>
>> Thanks !
>>
>> diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
>> index 6aabd77..564b9fc 100644
>> --- a/net/sched/sch_cbq.c
>> +++ b/net/sched/sch_cbq.c
>> @@ -250,10 +250,11 @@ cbq_classify(struct sk_buff *skb, struct Qdisc
>> *sch, int *qerr)
>> else if ((cl = defmap[res.classid & TC_PRIO_MAX]) == NULL)
>> cl = defmap[TC_PRIO_BESTEFFORT];
>>
>> - if (cl == NULL || cl->level >= head->level)
>> + if (cl == NULL)
>> goto fallback;
>> }
>> -
>> + if (cl->level >= head->level)
>> + goto fallback;
>> #ifdef CONFIG_NET_CLS_ACT
>> switch (result) {
>> case TC_ACT_QUEUED:
>>
>
> Hi Denys
>
> Any feedback on the suggested patch ?
>
> Thanks !
Dear Eric
Very sorry for delay, most of time in desert, without decent internet.
I will try to test today or tomorrow.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: CBQ(but probably u32 filter bug), kernel "freeze", at least from 3.2.0
From: Eric Dumazet @ 2012-09-06 13:56 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <3012b13d6556b629a84089b68bce9a6b@visp.net.lb>
On Thu, 2012-09-06 at 16:47 +0300, Denys Fedoryshchenko wrote:
> Dear Eric
>
> Very sorry for delay, most of time in desert, without decent internet.
> I will try to test today or tomorrow.
No problem, I reproduced the bug on my dev machine, but its always
better to have bug reporter adding its own 'Tested-by:' tag ;)
Thanks
^ permalink raw reply
* Re: [PATCH] mac80211: use list_move instead of list_del/list_add
From: Wei Yongjun @ 2012-09-06 13:57 UTC (permalink / raw)
To: johannes; +Cc: linville, yongjun_wei, linux-wireless, netdev
On 09/06/2012 05:56 PM, Johannes Berg wrote:
Hi Johannes,
> On Thu, 2012-09-06 at 13:20 +0800, Wei Yongjun wrote:
>> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>>
>> Using list_move() instead of list_del() + list_add().
>>
>> spatch with a semantic match is used to found this problem.
>> (http://coccinelle.lip6.fr/)
>>
>> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> Applied. FWIW, I don't think it's really a "problem" rather than a
> simplification or something like that, but anyway.
That is right, I will change the patch description if I send some other
patchs like this cleanup.
Thanks,
Yongjun Wei
>
> johannes
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix handling of throw routes
From: Eric Dumazet @ 2012-09-06 13:58 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev, markus.stenberg
In-Reply-To: <1346946815-3094-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, 2012-09-06 at 11:53 -0400, Nicolas Dichtel wrote:
> It's the same problem that previous fix about blackhole and prohibit routes.
>
> When adding a throw route, it was handled like a classic route.
> Moreover, it was only possible to add this kind of routes by specifying
> an interface.
>
> Before the patch:
> $ ip route add throw 2001::2/128
> RTNETLINK answers: No such device
> $ ip route add throw 2001::2/128 dev eth0
> $ ip -6 route | grep 2001::2
> 2001::2 dev eth0 metric 1024
>
> After:
> $ ip route add throw 2001::2/128
> $ ip -6 route | grep 2001::2
> throw 2001::2 dev lo metric 1024 error -11
>
> Reported-by: Markus Stenberg <markus.stenberg@iki.fi>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ipv6/route.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks Nicolas
^ permalink raw reply
* Re: [PATCH 08/10] net/macb: macb_get_drvinfo: add GEM/MACB suffix to differentiate revision
From: Nicolas Ferre @ 2012-09-06 14:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, linux-arm-kernel, davem, havard, plagnioj, jamie,
linux-kernel, patrice.vilchez
In-Reply-To: <1346887671.5325.47.camel@bwh-desktop.uk.solarflarecom.com>
On 09/06/2012 01:27 AM, Ben Hutchings :
> On Wed, 2012-09-05 at 11:00 +0200, Nicolas Ferre wrote:
>> Add an indication about which revision of the hardware we are running in
>> info->driver string.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>> drivers/net/ethernet/cadence/macb.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>> index bd331fd..c7c39f1 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -1313,6 +1313,10 @@ static void macb_get_drvinfo(struct net_device *dev,
>> struct macb *bp = netdev_priv(dev);
>>
>> strcpy(info->driver, bp->pdev->dev.driver->name);
>> + if (macb_is_gem(bp))
>> + strcat(info->driver, " GEM");
>> + else
>> + strcat(info->driver, " MACB");
>> strcpy(info->version, "$Revision: 1.14 $");
>
> Related to hardware revisions (which don't belong here, as David said),
> I rather doubt this CVS ID is very useful as a driver version.
>
> If the driver doesn't have a meaningful version (aside from the kernel
> version) then you can remove this function and let the ethtool core fill
> in the other two fields automatically.
Absolutely, I will do this.
Thanks for the tip.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Pedro Alves @ 2012-09-06 14:19 UTC (permalink / raw)
To: Sasha Levin
Cc: Mathieu Desnoyers, Steven Rostedt, Tejun Heo, torvalds, akpm,
linux-kernel, linux-mm, paul.gortmaker, davem, mingo, ebiederm,
aarcange, ericvh, netdev, josh, eric.dumazet, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <5048AAF6.5090101@gmail.com>
On 09/06/2012 02:53 PM, Sasha Levin wrote:
> So I think that for the hash iterator it might actually be simpler.
>
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
> hlist_for_each_entry(obj, node, &name[bkt], member)
>
> We initialize our node loop cursor with NULL in the external loop, and the
> external loop will have a new condition to loop while that cursor is NULL.
>
> My logic is that we can only 'break' when we are iterating over an object in the
> internal loop. If we're iterating over an object in that loop then 'node != NULL'.
>
> This way, if we broke from within the internal loop, the external loop will see
> node as not NULL, and so it will stop looping itself. On the other hand, if the
> internal loop has actually ended, then node will be NULL, and the outer loop
> will keep running.
>
> Is there anything I've missed?
Looks right to me, from a cursory look at hlist_for_each_entry. That's exactly
what I meant with this most often being trivial when the inner loop's iterator
is a pointer that goes NULL at the end.
--
Pedro Alves
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v2 09/10] net/macb: ethtool interface: add register dump feature
From: Nicolas Ferre @ 2012-09-06 14:20 UTC (permalink / raw)
To: netdev, bhutchings, davem
Cc: linux-arm-kernel, havard, plagnioj, patrice.vilchez, linux-kernel,
Nicolas Ferre
In-Reply-To: <1346888174.5325.55.camel@bwh-desktop.uk.solarflarecom.com>
Add macb_get_regs() ethtool function and its helper function:
macb_get_regs_len().
The version field is deduced from the IP revision which gives the
"MACB or GEM" information. An additional version field is reserved.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
v2: - modify MACB_GREGS_NBR name and adapt to number of registers
actually displayed.
- change version format to reflect register layout and
add a version number to be future proof.
drivers/net/ethernet/cadence/macb.c | 40 +++++++++++++++++++++++++++++++++++
drivers/net/ethernet/cadence/macb.h | 3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index dc34ff1..cab42e7 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1223,9 +1223,49 @@ static int macb_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
return phy_ethtool_sset(phydev, cmd);
}
+static int macb_get_regs_len(struct net_device *netdev)
+{
+ return MACB_GREGS_NBR * sizeof(u32);
+}
+
+static void macb_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct macb *bp = netdev_priv(dev);
+ unsigned int tail, head;
+ u32 *regs_buff = p;
+
+ regs->version = (macb_readl(bp, MID) & ((1 << MACB_REV_SIZE) - 1))
+ | MACB_GREGS_VERSION;
+
+ tail = macb_tx_ring_wrap(bp->tx_tail);
+ head = macb_tx_ring_wrap(bp->tx_head);
+
+ regs_buff[0] = macb_readl(bp, NCR);
+ regs_buff[1] = macb_or_gem_readl(bp, NCFGR);
+ regs_buff[2] = macb_readl(bp, NSR);
+ regs_buff[3] = macb_readl(bp, TSR);
+ regs_buff[4] = macb_readl(bp, RBQP);
+ regs_buff[5] = macb_readl(bp, TBQP);
+ regs_buff[6] = macb_readl(bp, RSR);
+ regs_buff[7] = macb_readl(bp, IMR);
+
+ regs_buff[8] = tail;
+ regs_buff[9] = head;
+ regs_buff[10] = macb_tx_dma(bp, tail);
+ regs_buff[11] = macb_tx_dma(bp, head);
+
+ if (macb_is_gem(bp)) {
+ regs_buff[12] = gem_readl(bp, USRIO);
+ regs_buff[13] = gem_readl(bp, DMACFG);
+ }
+}
+
static const struct ethtool_ops macb_ethtool_ops = {
.get_settings = macb_get_settings,
.set_settings = macb_set_settings,
+ .get_regs_len = macb_get_regs_len,
+ .get_regs = macb_get_regs,
.get_link = ethtool_op_get_link,
};
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index f69ceef..bcadc3c 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -10,6 +10,9 @@
#ifndef _MACB_H
#define _MACB_H
+#define MACB_GREGS_NBR 16
+#define MACB_GREGS_VERSION 1
+
/* MACB register offsets */
#define MACB_NCR 0x0000
#define MACB_NCFGR 0x0004
--
1.7.10
^ permalink raw reply related
* Re: NULL pointer dereference in xt_register_target()
From: Cong Wang @ 2012-09-06 14:27 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Eric Dumazet, netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <20120905164831.GA21836@1984>
On Thu, Sep 6, 2012 at 12:48 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Wed, Sep 05, 2012 at 05:55:06PM +0200, Eric Dumazet wrote:
>> On Wed, 2012-09-05 at 23:43 +0800, Cong Wang wrote:
>> > Hi, folks,
>> >
>> > The latest net-next tree can't boot due to a NULL ptr def
>> > bug in the kernel, the full backtrack is:
>> >
>> > http://img1.douban.com/view/photo/photo/public/p1697139550.jpg
>> >
>> > the kernel .config file is:
>> >
>> > http://pastebin.com/9YTnkqKN
>> >
>> > I don't have time to look into the issue. If you need other info,
>> > please let me know.
>>
>> It seems xt_nat_init() is called before xt_init(), so xt array is not
>> yet setup.
>
> I have enqueued the following patch to fix this:
>
> http://1984.lsi.us.es/git/nf-next/commit/?id=00545bec9412d130c77f72a08d6c8b6ad21d4a1
> e
> commit 00545bec9412d130c77f72a08d6c8b6ad21d4a1e
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Wed Sep 5 18:24:55 2012 +0200
>
> netfilter: fix crash during boot if NAT has been compiled built-in
>
Yeah, this indeed fixes the bug.
Please push it to net-next as soon as possible?
Thanks!
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Mathieu Desnoyers @ 2012-09-06 14:33 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
Pedro Alves, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <5048AAF6.5090101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
> On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
> >> #define do_for_each_ftrace_rec(pg, rec) \
> >> > for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> >> > pg && rec == &pg->records[pg->index]; \
> >> > pg = pg->next) \
> >> > for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
> > Maybe in some cases there might be ways to combine the two loops into
> > one ? I'm not seeing exactly how to do it for this one, but it should
> > not be impossible. If the inner loop condition can be moved to the outer
> > loop, and if we use (blah ? loop1_conf : loop2_cond) to test for
> > different conditions depending on the context, and do the same for the
> > 3rd argument of the for() loop. The details elude me for now though, so
> > maybe it's complete non-sense ;)
> >
> > It might not be that useful for do_for_each_ftrace_rec, but if we can do
> > it for the hash table iterator, it might be worth it.
>
> So I think that for the hash iterator it might actually be simpler.
>
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
> hlist_for_each_entry(obj, node, &name[bkt], member)
>
> We initialize our node loop cursor with NULL in the external loop, and the
> external loop will have a new condition to loop while that cursor is NULL.
>
> My logic is that we can only 'break' when we are iterating over an object in the
> internal loop. If we're iterating over an object in that loop then 'node != NULL'.
>
> This way, if we broke from within the internal loop, the external loop will see
> node as not NULL, and so it will stop looping itself. On the other hand, if the
> internal loop has actually ended, then node will be NULL, and the outer loop
> will keep running.
>
> Is there anything I've missed?
This sounds good. Unless I'm missing something too.
Thanks!
Mathieu
>
>
> Thanks,
> Sasha
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH v2 09/10] net/macb: ethtool interface: add register dump feature
From: Ben Hutchings @ 2012-09-06 14:34 UTC (permalink / raw)
To: Nicolas Ferre
Cc: netdev, davem, linux-arm-kernel, havard, plagnioj,
patrice.vilchez, linux-kernel
In-Reply-To: <1346941256-15676-1-git-send-email-nicolas.ferre@atmel.com>
On Thu, 2012-09-06 at 16:20 +0200, Nicolas Ferre wrote:
> Add macb_get_regs() ethtool function and its helper function:
> macb_get_regs_len().
> The version field is deduced from the IP revision which gives the
> "MACB or GEM" information. An additional version field is reserved.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> v2: - modify MACB_GREGS_NBR name and adapt to number of registers
> actually displayed.
> - change version format to reflect register layout and
> add a version number to be future proof.
>
> drivers/net/ethernet/cadence/macb.c | 40 +++++++++++++++++++++++++++++++++++
> drivers/net/ethernet/cadence/macb.h | 3 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index dc34ff1..cab42e7 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -1223,9 +1223,49 @@ static int macb_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> return phy_ethtool_sset(phydev, cmd);
> }
>
> +static int macb_get_regs_len(struct net_device *netdev)
> +{
> + return MACB_GREGS_NBR * sizeof(u32);
> +}
> +
> +static void macb_get_regs(struct net_device *dev, struct ethtool_regs *regs,
> + void *p)
> +{
> + struct macb *bp = netdev_priv(dev);
> + unsigned int tail, head;
> + u32 *regs_buff = p;
> +
> + regs->version = (macb_readl(bp, MID) & ((1 << MACB_REV_SIZE) - 1))
> + | MACB_GREGS_VERSION;
> +
> + tail = macb_tx_ring_wrap(bp->tx_tail);
> + head = macb_tx_ring_wrap(bp->tx_head);
> +
> + regs_buff[0] = macb_readl(bp, NCR);
> + regs_buff[1] = macb_or_gem_readl(bp, NCFGR);
> + regs_buff[2] = macb_readl(bp, NSR);
> + regs_buff[3] = macb_readl(bp, TSR);
> + regs_buff[4] = macb_readl(bp, RBQP);
> + regs_buff[5] = macb_readl(bp, TBQP);
> + regs_buff[6] = macb_readl(bp, RSR);
> + regs_buff[7] = macb_readl(bp, IMR);
> +
> + regs_buff[8] = tail;
> + regs_buff[9] = head;
> + regs_buff[10] = macb_tx_dma(bp, tail);
> + regs_buff[11] = macb_tx_dma(bp, head);
> +
> + if (macb_is_gem(bp)) {
> + regs_buff[12] = gem_readl(bp, USRIO);
> + regs_buff[13] = gem_readl(bp, DMACFG);
> + }
> +}
> +
> static const struct ethtool_ops macb_ethtool_ops = {
> .get_settings = macb_get_settings,
> .set_settings = macb_set_settings,
> + .get_regs_len = macb_get_regs_len,
> + .get_regs = macb_get_regs,
> .get_link = ethtool_op_get_link,
> };
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index f69ceef..bcadc3c 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,9 @@
> #ifndef _MACB_H
> #define _MACB_H
>
> +#define MACB_GREGS_NBR 16
> +#define MACB_GREGS_VERSION 1
> +
> /* MACB register offsets */
> #define MACB_NCR 0x0000
> #define MACB_NCFGR 0x0004
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: David Laight @ 2012-09-06 14:36 UTC (permalink / raw)
To: Sasha Levin, Mathieu Desnoyers
Cc: Pedro Alves, Steven Rostedt, Tejun Heo, torvalds, akpm,
linux-kernel, linux-mm, paul.gortmaker, davem, mingo, ebiederm,
aarcange, ericvh, netdev, josh, eric.dumazet, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <5048AAF6.5090101@gmail.com>
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node ==
NULL; bkt++)
> hlist_for_each_entry(obj, node, &name[bkt], member)
I'd take a look at the generated code.
Might come out a bit better if the condition is changed to:
node == NULL && bkt < HASH_SIZE(name)
you might find the compiler always optimises out the
node == NULL comparison.
(It might anyway, but switching the order gives it a better
chance.)
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: NULL pointer dereference in xt_register_target()
From: Pablo Neira Ayuso @ 2012-09-06 14:44 UTC (permalink / raw)
To: Cong Wang; +Cc: Eric Dumazet, netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVAZwKhZxLdk-BLMjnK3eX4DD_o9KvzuAoTttyxvmCsJA@mail.gmail.com>
On Thu, Sep 06, 2012 at 10:27:22PM +0800, Cong Wang wrote:
> On Thu, Sep 6, 2012 at 12:48 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Wed, Sep 05, 2012 at 05:55:06PM +0200, Eric Dumazet wrote:
> >> On Wed, 2012-09-05 at 23:43 +0800, Cong Wang wrote:
> >> > Hi, folks,
> >> >
> >> > The latest net-next tree can't boot due to a NULL ptr def
> >> > bug in the kernel, the full backtrack is:
> >> >
> >> > http://img1.douban.com/view/photo/photo/public/p1697139550.jpg
> >> >
> >> > the kernel .config file is:
> >> >
> >> > http://pastebin.com/9YTnkqKN
> >> >
> >> > I don't have time to look into the issue. If you need other info,
> >> > please let me know.
> >>
> >> It seems xt_nat_init() is called before xt_init(), so xt array is not
> >> yet setup.
> >
> > I have enqueued the following patch to fix this:
> >
> > http://1984.lsi.us.es/git/nf-next/commit/?id=00545bec9412d130c77f72a08d6c8b6ad21d4a1
> > e
> > commit 00545bec9412d130c77f72a08d6c8b6ad21d4a1e
> > Author: Pablo Neira Ayuso <pablo@netfilter.org>
> > Date: Wed Sep 5 18:24:55 2012 +0200
> >
> > netfilter: fix crash during boot if NAT has been compiled built-in
> >
>
> Yeah, this indeed fixes the bug.
>
> Please push it to net-next as soon as possible?
Will do, thanks for testing.
^ permalink raw reply
* Re: [PATCH 04/10] net/macb: Fix a race in macb_start_xmit()
From: Nicolas Ferre @ 2012-09-06 14:52 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-arm-kernel, havard, plagnioj, jamie, linux-kernel,
patrice.vilchez
In-Reply-To: <20120905.173023.2235590074897156746.davem@davemloft.net>
On 09/05/2012 11:30 PM, David Miller :
> From: Nicolas Ferre <nicolas.ferre@atmel.com>
> Date: Wed, 5 Sep 2012 10:19:11 +0200
>
>> From: Havard Skinnemoen <havard@skinnemoen.net>
>>
>> Fix a race in macb_start_xmit() where we unconditionally set the TSTART bit.
>> If an underrun just happened (we do this with interrupts disabled, so it might
>> not have been handled yet), the controller starts transmitting from the first
>> entry in the ring, which is usually wrong.
>> Restart the controller after error handling.
>>
>> Signed-off-by: Havard Skinnemoen <havard@skinnemoen.net>
>> [nicolas.ferre@atmel.com: split patch in topics]
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Accumulating special case code and checks into the hot path of TX packet
> processing is extremely unwise.
>
> Instead, when you handle the TX error conditions and reset the chip you
> should first ensure that there are no flows of control in the transmit
> function of your driver by using the appropriate locking et al. facilities.
>
> For example, you can quiesce the transmit path by handling the chip error
> interrupt as follows:
>
> 1) Disable chip interrupt generation.
>
> 2) Schedule a workqueue so you can process the reset outside of hard
> interrupt context.
>
> 3) In the workqueue function, disable NAPI and perform a
> netif_tx_disable() to guarentee there are no threads of
> execution trying to queue up packets for TX into the driver.
>
> 4) Perform your chip reset and whatever else is necessary.
>
> 5) Re-enable NAPI and TX.
>
> Then you don't need any special checks in your xmit method at all.
I see... I will rework the series and try to implement this as part of
the "[PATCH 06/10] net/macb: better manage tx errors"
So this patch will disappear in future v2 series and patch 06 will be
seriously modified. In fact I will also try to stack "cosmetic" patches
at the beginning of the series.
Thanks, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Josh Triplett @ 2012-09-06 14:55 UTC (permalink / raw)
To: Sasha Levin
Cc: Mathieu Desnoyers, Pedro Alves, Steven Rostedt, Tejun Heo,
torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
mingo, ebiederm, aarcange, ericvh, netdev, eric.dumazet, axboe,
agk, dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust,
bfields, fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer,
edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <5048AAF6.5090101@gmail.com>
On Thu, Sep 06, 2012 at 03:53:58PM +0200, Sasha Levin wrote:
> On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
> >> #define do_for_each_ftrace_rec(pg, rec) \
> >> > for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> >> > pg && rec == &pg->records[pg->index]; \
> >> > pg = pg->next) \
> >> > for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
> > Maybe in some cases there might be ways to combine the two loops into
> > one ? I'm not seeing exactly how to do it for this one, but it should
> > not be impossible. If the inner loop condition can be moved to the outer
> > loop, and if we use (blah ? loop1_conf : loop2_cond) to test for
> > different conditions depending on the context, and do the same for the
> > 3rd argument of the for() loop. The details elude me for now though, so
> > maybe it's complete non-sense ;)
> >
> > It might not be that useful for do_for_each_ftrace_rec, but if we can do
> > it for the hash table iterator, it might be worth it.
>
> So I think that for the hash iterator it might actually be simpler.
>
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
> hlist_for_each_entry(obj, node, &name[bkt], member)
>
> We initialize our node loop cursor with NULL in the external loop, and the
> external loop will have a new condition to loop while that cursor is NULL.
>
> My logic is that we can only 'break' when we are iterating over an object in the
> internal loop. If we're iterating over an object in that loop then 'node != NULL'.
>
> This way, if we broke from within the internal loop, the external loop will see
> node as not NULL, and so it will stop looping itself. On the other hand, if the
> internal loop has actually ended, then node will be NULL, and the outer loop
> will keep running.
>
> Is there anything I've missed?
Looks reasonable. However, it would break (or rather, not break) on
code like this:
hash_for_each_entry(...) {
if (...) {
foo(node);
node = NULL;
break;
}
}
Hiding the double loop still seems error-prone.
- Josh Triplett
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-09-06 15:11 UTC (permalink / raw)
To: Josh Triplett
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
Tejun-/PVsmBQoxgPKo9QCiBeYKEEOCMrvLtNR,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
lw-BthXqXjhjHXQFUHtdCDX3A, Mathieu Desnoyers, Sasha Levin,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
Pedro Alves, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20120906145545.GA17332@leaf>
On Thu, 2012-09-06 at 07:55 -0700, Josh Triplett wrote:
> > My solution to making 'break' work in the iterator is:
> >
> > for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
> > hlist_for_each_entry(obj, node, &name[bkt], member)
> >
>
> Looks reasonable. However, it would break (or rather, not break) on
> code like this:
>
> hash_for_each_entry(...) {
> if (...) {
> foo(node);
> node = NULL;
> break;
> }
> }
>
> Hiding the double loop still seems error-prone.
We've already had this conversation ;-) A guess a big comment is in
order:
/*
* NOTE! Although this is a double loop, 'break' still works because of
* the 'node == NULL' condition in the outer loop. On break of
* the inner loop, node will be !NULL, and the outer loop will
* exit as well.
*/
-- Steve
^ permalink raw reply
* WARNING: at net/ipv4/tcp.c:1303 tcp_cleanup_rbuf+0x54/0x120()
From: Dave Jones @ 2012-09-06 15:32 UTC (permalink / raw)
To: netdev; +Cc: Fedora Kernel Team
In-Reply-To: <bug-854367-176318@bugzilla.redhat.com>
We've had about 20 reports of this bug in the last 2 days.
No idea why it only just started showing up, but it may coincide with
users updating from 3.4->3.5 when we pushed an update.
Seems to be affecting multiple different network drivers.
(The original trace is a 'crap' driver from staging, but there are
reports from e1000e and iwlwifi for eg)
> https://bugzilla.redhat.com/show_bug.cgi?id=854367
>
> backtrace:
> :WARNING: at net/ipv4/tcp.c:1303 tcp_cleanup_rbuf+0x54/0x120()
> :Hardware name: GA-MA785GM-US2H
> :cleanup rbuf bug: copied A48FD80 seq A48FD80 rcvnxt A48FD80
> :Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE
> nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT
> nf_conntrack_ipv6 nf_defrag_ipv6 lockd ip6table_filter sunrpc ip6_tables
> iptable_nat nf_nat rfcomm iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 bnep
> xt_conntrack nf_conntrack binfmt_misc btusb bluetooth snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_intel joydev r8712u(C) snd_hda_codec rfkill
> snd_hwdep shpchp sp5100_tco r8169 mii serio_raw snd_pcm snd_page_alloc
> snd_timer snd soundcore i2c_piix4 edac_core edac_mce_amd ppdev parport_pc
> parport microcode k10temp vhost_net tun macvtap macvlan kvm_amd kvm uinput
> ata_generic pata_acpi firewire_ohci firewire_core crc_itu_t pata_atiixp wmi
> usb_storage radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded:
> scsi_wait_scan]
> :Pid: 2241, comm: Chrome_IOThread Tainted: G C 3.5.3-1.fc17.x86_64 #1
> :Call Trace:
> : [<ffffffff810584bf>] warn_slowpath_common+0x7f/0xc0
> : [<ffffffff810585b6>] warn_slowpath_fmt+0x46/0x50
> : [<ffffffff815443c4>] tcp_cleanup_rbuf+0x54/0x120
> : [<ffffffff8154564c>] tcp_recvmsg+0x76c/0xd30
> : [<ffffffff81569c1b>] inet_recvmsg+0x6b/0x80
> : [<ffffffff814e7612>] sock_aio_read.part.9+0x142/0x170
> : [<ffffffff814e7665>] sock_aio_read+0x25/0x40
> : [<ffffffff81187a06>] do_sync_read+0xe6/0x120
> : [<ffffffff8127948a>] ? inode_has_perm.isra.31.constprop.61+0x2a/0x30
> : [<ffffffff812764d2>] ? security_file_permission+0x92/0xb0
> : [<ffffffff81187ea1>] ? rw_verify_area+0x61/0xf0
> : [<ffffffff811883ed>] vfs_read+0x15d/0x180
> : [<ffffffff8118845a>] sys_read+0x4a/0x90
> : [<ffffffff81614ae9>] system_call_fastpath+0x16/0x1b
Could this be related to the "recvmsg bug" WARN's we've also been seeing recently ?
Dave
^ permalink raw reply
* [PATCH] sctp: check dst validity after IPsec operations
From: Nicolas Dichtel @ 2012-09-06 17:40 UTC (permalink / raw)
To: vyasevich, sri, linux-sctp; +Cc: netdev, Nicolas Dichtel
dst stored in struct sctp_transport needs to be recalculated when ipsec policy
are updated. We use flow_cache_genid for that.
For example, if a SCTP connection is established and then an IPsec policy is
set, the old SCTP flow will not be updated and thus will not use the new
IPsec policy.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/net/sctp/sctp.h | 3 ++-
include/net/sctp/structs.h | 3 +++
net/sctp/ipv6.c | 1 +
net/sctp/protocol.c | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 9c6414f..3267246 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -712,7 +712,8 @@ static inline void sctp_v4_map_v6(union sctp_addr *addr)
*/
static inline struct dst_entry *sctp_transport_dst_check(struct sctp_transport *t)
{
- if (t->dst && !dst_check(t->dst, 0)) {
+ if ((t->dst && !dst_check(t->dst, 0)) ||
+ (t->flow_cache_genid != atomic_read(&flow_cache_genid))) {
dst_release(t->dst);
t->dst = NULL;
}
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 0fef00f..9dab882 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -948,6 +948,9 @@ struct sctp_transport {
/* 64-bit random number sent with heartbeat. */
__u64 hb_nonce;
+
+ /* used to check validity of dst */
+ __u32 flow_cache_genid;
};
struct sctp_transport *sctp_transport_new(struct net *, const union sctp_addr *,
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index ea14cb4..2ed7410 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -349,6 +349,7 @@ out:
struct rt6_info *rt;
rt = (struct rt6_info *)dst;
t->dst = dst;
+ t->flow_cache_genid = atomic_read(&flow_cache_genid);
SCTP_DEBUG_PRINTK("rt6_dst:%pI6 rt6_src:%pI6\n",
&rt->rt6i_dst.addr, &fl6->saddr);
} else {
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 2d51842..4795a1a 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -512,6 +512,7 @@ out_unlock:
rcu_read_unlock();
out:
t->dst = dst;
+ t->flow_cache_genid = atomic_read(&flow_cache_genid);
if (dst)
SCTP_DEBUG_PRINTK("rt_dst:%pI4, rt_src:%pI4\n",
&fl4->daddr, &fl4->saddr);
--
1.7.12
^ permalink raw reply related
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