On 4/2/21 12:25 PM, Jiri Kosina wrote:
On Thu, 3 Sep 2020, John Fastabend wrote:
At this point I fear we could consider reverting the NOLOCK stuff.
I personally would hate doing so, but it looks like NOLOCK benefits are
outweighed by its issues.
I agree, NOLOCK brings more pains than gains. T
Hi Jike
On 8/20/20 12:43 AM, Jike Song wrote:
Hi Josh,
We met possibly the same problem when testing nvidia/mellanox's
GPUDirect RDMA product, we found that changing NET_SCH_DEFAULT to
DEFAULT_FQ_CODEL mitigated the problem, having no idea why. Maybe you
can also have a try?
We also did some
On 7/2/20 2:45 AM, Paolo Abeni wrote:
Hi all,
On Thu, 2020-07-02 at 08:14 +0200, Jonas Bonn wrote:
Hi Cong,
On 01/07/2020 21:58, Cong Wang wrote:
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
Do either of you know if there's bee
On 7/1/20 12:58 PM, Cong Wang wrote:
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
Do either of you know if there's been any development on a fix for this
issue? If not we can propose something.
If you have a reproducer, I can look
On 6/23/20 6:42 AM, Michael Zhivich wrote:
From: Jonas Bonn
To: Paolo Abeni ,
"netdev@vger.kernel.org" ,
LKML ,
"David S . Miller" ,
John Fastabend
Subject: Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
Date: Fri, 11 Oct 2019 02:39:48 +0200
Message-ID: <465a54
On Mon, Oct 21, 2019 at 10:42 AM Subash Abhinov Kasiviswanathan
wrote:
>
> > Please give us a pointer to the exact git tree and sha1.
> >
> > I do not analyze TCP stack problems without an exact starting point,
> > or at least a crystal ball, which I do not have.
>
> Hi Eric
>
> We are at this com
On Thu, Oct 17, 2019 at 5:33 AM Bowers, AndrewX
wrote:
>
> > -Original Message-
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Josh Hunt
> > Sent: Friday, October 11, 2019 9:54 AM
> > To: netdev@vger.kernel.org;
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Suggested-by: Alexander Duyck
Signed-off-by: Josh Hunt
---
drivers
4 66.45
61824 1201598.88 114019350 19350 15.11 75.44
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
On 10/11/19 8:29 AM, Alexander Duyck wrote:
On Thu, 2019-10-10 at 20:25 -0400, Josh Hunt wrote:
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net
On 10/10/19 5:21 PM, Brown, Aaron F wrote:
Adding Andrew as he is most likely going to be testing this patch.
Unfortunately my mail server flags attached scripts as potential threats and
strips them out. Can you resent it as an tar file? I don't believe it's smart
enough to open up tar and f
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Suggested-by: Alexander Duyck
Signed-off-by: Josh Hunt
---
drivers
19350 15.11 75.44
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12 +---
drive
On 10/10/19 2:32 PM, Alexander Duyck wrote:
On Thu, Oct 10, 2019 at 2:17 PM Josh Hunt wrote:
On 10/9/19 3:44 PM, Alexander Duyck wrote:
On Wed, Oct 9, 2019 at 3:08 PM Josh Hunt wrote:
Alexander Duyck posted a series in 2018 proposing adding UDP segmentation
offload support to ixgbe and
On 10/9/19 3:44 PM, Alexander Duyck wrote:
On Wed, Oct 9, 2019 at 3:08 PM Josh Hunt wrote:
Alexander Duyck posted a series in 2018 proposing adding UDP segmentation
offload support to ixgbe and ixgbevf, but those patches were never
accepted:
https://lore.kernel.org/netdev
On 10/9/19 3:06 PM, Josh Hunt wrote:
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
On 10/9/19 5:39 PM, Samudrala, Sridhar wrote:
On 10/9/2019 3:06 PM, Josh Hunt wrote:
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet
19348 19348 14.79 77.07
I was not sure how to proper attribute Alexander on the ixgbe patch so
please adjust this as necessary.
Thanks!
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/ixgbe
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
SEGMENT")
Signed-off-by: Josh Hunt
---
net/ipv4/udp.c | 11 +++
net/ipv6/udp.c | 11 +++
tools/testing/selftests/net/udpgso.c | 16
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/net/ipv4/udp.c b
UDP_SEGMENT")
Fixes: dfec0ee22c0a ("udp: Record gso_segs when supporting UDP segmentation
offload")
Signed-off-by: Josh Hunt
Reviewed-by: Alexander Duyck
Acked-by: Willem de Bruijn
---
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
dif
On 10/1/19 5:22 AM, Willem de Bruijn wrote:
On Mon, Sep 30, 2019 at 7:57 PM Alexander Duyck
wrote:
On Mon, Sep 30, 2019 at 3:13 PM Josh Hunt wrote:
Prior to this change an application sending <= 1MSS worth of data and
enabling UDP GSO would fail if the system had SW GSO enabled, but
On 9/30/19 4:56 PM, Alexander Duyck wrote:
On Mon, Sep 30, 2019 at 3:13 PM Josh Hunt wrote:
Prior to this change an application sending <= 1MSS worth of data and
enabling UDP GSO would fail if the system had SW GSO enabled, but the
same send would succeed if HW GSO offload is enabled.
On 10/1/19 5:12 AM, Willem de Bruijn wrote:
On Mon, Sep 30, 2019 at 7:51 PM Alexander Duyck
wrote:
On Mon, Sep 30, 2019 at 3:15 PM Josh Hunt wrote:
Commit dfec0ee22c0a ("udp: Record gso_segs when supporting UDP segmentation
offload")
added gso_segs calculation, but incor
On 9/30/19 4:51 PM, Alexander Duyck wrote:
On Mon, Sep 30, 2019 at 3:15 PM Josh Hunt wrote:
Commit dfec0ee22c0a ("udp: Record gso_segs when supporting UDP segmentation
offload")
added gso_segs calculation, but incorrectly got sizeof() the pointer and
not the underlying data typ
when supporting UDP segmentation
offload")
Signed-off-by: Josh Hunt
---
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index cf755156a684..be98d0b8f014 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/ud
SEGMENT")
Signed-off-by: Josh Hunt
---
net/ipv4/udp.c | 5 +++--
net/ipv6/udp.c | 5 +++--
tools/testing/selftests/net/udpgso.c | 16
3 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp
On 9/18/19 8:35 AM, Willem de Bruijn wrote:
On Tue, Sep 17, 2019 at 4:20 PM Josh Hunt wrote:
I was running some tests recently with the udpgso_bench_tx benchmark in
selftests and noticed that in some configurations it reported sending
more than line rate! Looking into it more I found that I
I was running some tests recently with the udpgso_bench_tx benchmark in
selftests and noticed that in some configurations it reported sending
more than line rate! Looking into it more I found that I was overflowing
the qdisc queue and so it was sending back NET_XMIT_DROP however this
error did
On 6/26/19 4:41 PM, Willem de Bruijn wrote:
On Wed, Jun 26, 2019 at 3:17 PM Jason Baron wrote:
On 6/14/19 4:53 PM, Jason Baron wrote:
On 6/13/19 5:20 PM, Willem de Bruijn wrote:
@@ -237,6 +237,7 @@ static inline int find_next_netdev_feature(u64 feature,
unsigned long start)
On 8/9/19 11:43 AM, David Miller wrote:
From: Josh Hunt
Date: Fri, 9 Aug 2019 11:38:05 -0700
I forgot to tag these at net-next. Do I need to resubmit a v3 with
net-next in the subject?
No need.
Thanks
On 8/7/19 11:13 PM, Eric Dumazet wrote:
On 8/8/19 1:52 AM, Josh Hunt wrote:
TCP_BASE_MSS is used as the default initial MSS value when MTU probing is
enabled. Update the comment to reflect this.
Suggested-by: Neal Cardwell
Signed-off-by: Josh Hunt
---
Signed-off-by: Eric Dumazet
Dave
On 8/7/19 11:12 PM, Eric Dumazet wrote:
On 8/8/19 1:52 AM, Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections allowing the MSS to get down to
48. We have found that in almost all of these cases on our networks these
paths
TCP_BASE_MSS is used as the default initial MSS value when MTU probing is
enabled. Update the comment to reflect this.
Suggested-by: Neal Cardwell
Signed-off-by: Josh Hunt
---
include/net/tcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net
reasonble floor set we've had it
enabled for the past 6 months.
The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives
administrators the ability to control the floor of MSS probing.
Signed-off-by: Josh Hunt
---
Documentation/networking/ip-sysctl.txt | 6 ++
include/n
On 7/29/19 6:12 AM, Neal Cardwell wrote:
On Sun, Jul 28, 2019 at 5:14 PM Josh Hunt wrote:
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current
On 7/28/19 2:14 PM, Josh Hunt wrote:
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections allowing the MSS to get down to
48. We have found that in almost all of these cases on our
reasonble floor set we've had it
enabled for the past 6 months.
The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives
administrators the ability to control the floor of MSS probing.
Signed-off-by: Josh Hunt
---
Documentation/networking/ip-sysctl.txt | 6 ++
include/n
.6 rcv_space:43725 rcv_ssthresh:43690 minrtt:0.007
Signed-off-by: Josh Hunt
---
v1 -> v2
* Update long option to --oneline to match other ip tools as per David.
man/man8/ss.8 | 3 +++
misc/ss.c | 51 +--
2 files changed, 44 insertions(+
On 4/30/19 12:41 PM, David Ahern wrote:
On 4/30/19 12:55 PM, Josh Hunt wrote:
Actually, David can you clarify what you meant by "use 'oneline' as the
long option without the '-'."?
for your patch:
1,$s/one-line/oneline/
ip has -oneline which is most likely u
On 4/30/19 11:31 AM, Josh Hunt wrote:
On 4/30/19 11:30 AM, David Ahern wrote:
On 4/25/19 3:21 PM, Josh Hunt wrote:
@@ -4877,6 +4903,7 @@ static void _usage(FILE *dest)
"\n"
" -K, --kill forcibly close sockets, display what was
closed\n"
" -H,
On 4/30/19 11:30 AM, David Ahern wrote:
On 4/25/19 3:21 PM, Josh Hunt wrote:
@@ -4877,6 +4903,7 @@ static void _usage(FILE *dest)
"\n"
" -K, --kill forcibly close sockets, display what was closed\n"
" -H, --no-header Suppress header li
On 4/25/19 3:59 PM, Stephen Hemminger wrote:
On Thu, 25 Apr 2019 17:21:48 -0400
Josh Hunt wrote:
Multi-line output in ss makes it difficult to search for things with
grep. This new option will make it easier to find sockets matching
certain criteria with simple grep commands.
Example without
.6 rcv_space:43725 rcv_ssthresh:43690 minrtt:0.007
Signed-off-by: Josh Hunt
---
man/man8/ss.8 | 3 +++
misc/ss.c | 51 +--
2 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 03a3dcc6c9c3..dd5ebc9
On Thu, Aug 2, 2018 at 4:34 PM, Peter Oskolkov wrote:
> This patchset
> * changes IPv4 defrag behavior to match that of IPv6: overlapping
>fragments now cause the whole IP datagram to be discarded (suggested
>by David Miller): there are no legitimate use cases for overlapping
>fragme
On Mon, Jan 22, 2018 at 10:30 AM, Ben Greear wrote:
> On 01/22/2018 10:16 AM, Eric Dumazet wrote:
>>
>> On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
>>>
>>> My test case is to have 6 processes each create 5000 TCP IPv4 connections
>>> to each other
>>> on a system with 16GB RAM and send sl
Fixes sparse warning about pointer in gen_handle:
net/sched/cls_rsvp.h:392:40: warning: Using plain integer as NULL pointer
Fixes: 8113c095672f6 ("net_sched: use void pointer for filter handle")
Signed-off-by: Josh Hunt
---
net/sched/cls_rsvp.h | 2 +-
1 file changed, 1 insertion(+),
Dumazet.
Signed-off-by: Josh Hunt
Reviewed-by: Jason Baron
Acked-by: Eric Dumazet
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h| 2 ++
arch/m32r/include
number and together with
the RX queue size (obtained via getsockopt(SO_RCVBUF) can be used to
calculate a percentage value on how full the socket buffer is.
---
Seems a lot of overhead, and only UDP would be supported.
I very much prefer Josh Hunt proposal
( https://patchwork.ozlabs.org/patch/738250/ )
On 03/13/2017 07:10 PM, David Miller wrote:
From: Josh Hunt
Date: Mon, 13 Mar 2017 18:34:41 -0500
In this particular case they really do want to know total # of bytes
in the receive queue, not the data bytes they can consume from an
application pov. The kernel currently only exposes this
On 03/13/2017 02:39 PM, David Miller wrote:
From: Josh Hunt
Date: Mon, 13 Mar 2017 12:38:39 -0500
On 03/13/2017 11:12 AM, Eric Dumazet wrote:
On Mon, Mar 13, 2017 at 8:59 AM, Josh Hunt wrote:
Allows application to read the amount of data sitting in the receive
queue.
Signed-off-by: Josh
On 03/13/2017 11:12 AM, Eric Dumazet wrote:
On Mon, Mar 13, 2017 at 8:59 AM, Josh Hunt wrote:
Allows application to read the amount of data sitting in the receive
queue.
Signed-off-by: Josh Hunt
---
A team here is looking for a way to get the amount of data in a UDP socket's
receive
Allows application to read the amount of data sitting in the receive
queue.
Signed-off-by: Josh Hunt
---
A team here is looking for a way to get the amount of data in a UDP socket's
receive queue. It seems like this should be SIOCINQ, but for UDP sockets that
returns the size of the
e over the TCP_NOTSENT_LOWAT
setting.
This patch adds a cap on the amount of data we can add to the send queue
at 50% above the TCP_NOTSENT_LOWAT setting.
Signed-off-by: Josh Hunt
---
include/net/tcp.h | 7 ++-
net/ipv4/tcp.c| 14 ++
2 files changed, 20 insertions(+), 1 deletion(
ong as
the message is not read by the application.
Josh Hunt fixed a similar issue in commit d22e15371811 ("tcp: fix tcp
fin memory accounting")
Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
Signed-off-by: Eric Dumazet
---
net/ipv4/tcp_fastopen.c |
On Tue, Apr 19, 2016 at 9:54 AM, Butler, Peter wrote:
>> -Original Message-
>> From: Rick Jones [mailto:rick.jon...@hpe.com]
>> Sent: April-15-16 6:37 PM
>> To: Butler, Peter ; netdev@vger.kernel.org
>> Subject: Re: Poorer networking performance in later kernels?
>>
>> On 04/15/2016 02:02
On 03/04/2016 04:47 PM, Bill Sommerfeld wrote:
IPv4 interprets a negative return value from a protocol handler as a
request to redispatch to a new protocol. In contrast, IPv6 interprets a
negative value as an error, and interprets a positive value as a request
for redispatch.
UDP for IPv6 was u
On Thu, Oct 29, 2015 at 5:00 AM, Sabrina Dubroca wrote:
> 2015-10-15, 14:25:03 +0200, Sabrina Dubroca wrote:
>> Without this length argument, we can read past the end of the iovec in
>> memcpy_toiovec because we have no way of knowing the total length of the
>> iovec's buffers.
>>
>> This is neede
When sockets are unhashed they are no longer visible through the normal
methods. Provide a way to see all sockets in the system by dumping some
basic socket information in fdinfo.
Signed-off-by: Josh Hunt
---
When trying to debug an application issue which wound up not closing sockets
properly
On 06/11/2015 08:05 AM, Hajime Tazaki wrote:
At Wed, 10 Jun 2015 16:57:25 -0500,
Josh Hunt wrote:
Dave
Can you please revert this change?
commit 0243508edd317ff1fa63b495643a7c192fbfcd92
Author: Josh Hunt
Date: Mon Jun 8 12:00:59 2015 -0400
ipv6: Fix protocol resubmission
Let me
On 06/10/2015 10:16 AM, YOSHIFUJI Hideaki wrote:
Hi,
Josh Hunt wrote:
On 06/09/2015 11:24 PM, Hajime Tazaki wrote:
Hello Josh, Dave,
my mobile ipv6 test on libos failed with this commit.
This commit makes a destination option header handling (i.e.,
ipprot->handler == ipv6_destopt_
On 06/10/2015 10:23 AM, Josh Hunt wrote:
On 06/10/2015 10:16 AM, YOSHIFUJI Hideaki wrote:
Hi,
Josh Hunt wrote:
Hajime
Thanks for the report. I mentioned in an earlier post this might be a
problem.
Dave, what if we restore the old behavior, but add a new label to
handle the case where the
On 06/10/2015 10:16 AM, YOSHIFUJI Hideaki wrote:
Hi,
Josh Hunt wrote:
Hajime
Thanks for the report. I mentioned in an earlier post this might be a problem.
Dave, what if we restore the old behavior, but add a new label to handle the
case where the decapsulating protocol returns the nexthdr
On 06/09/2015 11:24 PM, Hajime Tazaki wrote:
Hello Josh, Dave,
my mobile ipv6 test on libos failed with this commit.
This commit makes a destination option header handling (i.e.,
ipprot->handler == ipv6_destopt_rcv) failed since
ipv6_destopt_rcv() seems to return a positive value to
indicate t
psulating.
Signed-off-by: Josh Hunt
---
v3: Fix formatting issues found by Sergei Shtylyov
v2: Use returned nexthdr value
net/ipv6/ip6_input.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index f2e464e..41a73da 100644
--- a
On 05/29/2015 09:37 PM, Josh Hunt wrote:
On 05/29/2015 04:48 PM, Tom Herbert wrote:
Hi Josh,
Why did you need to move the resubmit label?
Grabbing nhoff out of the skb's cb didn't seem relevant anymore, unless
we're requiring the decapsulating code to update the control
On 05/29/2015 04:48 PM, Tom Herbert wrote:
Hi Josh,
Why did you need to move the resubmit label?
Grabbing nhoff out of the skb's cb didn't seem relevant anymore, unless
we're requiring the decapsulating code to update the control block
before it returns. Also, since we are returning nexthdr
On 05/29/2015 03:27 PM, Sergei Shtylyov wrote:
Hello.
On 05/29/2015 11:04 PM, Josh Hunt wrote:
I came across this problem while trying to use UDP encapsulation with
IPv6. The
change below fixes that, but it was not immediately apparent if there
are any
other protocols relying on this broken
eck and also moves the resubmit label to take advantage
of
the return code identifying the next protocol we want to process.
Signed-off-by: Josh Hunt
---
net/ipv6/ip6_input.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_inpu
On 05/29/2015 02:56 PM, Josh Hunt wrote:
I came across this problem while trying to use UDP encapsulation with IPv6. The
change below fixes that, but it was not immediately apparent if there are any
other protocols relying on this broken behavior. FWIW the behavior below now
matches IPv4.
Josh
ake advantage
of
the return code identifying the next protocol we want to process.
Signed-off-by: Josh Hunt
---
net/ipv6/ip6_input.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index f2e464e..a4c1026 100644
--- a/net/i
On 04/21/2015 07:09 PM, Eric Dumazet wrote:
Note that this patch adds a deadlock possibility in some stress
situations.
If a process owning some tcp socket dies, and tcp_mem[2] is already hit,
all sk_stream_alloc_skb() can return NULL and we loop in tcp_send_fin(),
making no progress because we
80 matches
Mail list logo
