ttps://lkml.org/lkml/2021/3/24/1485 ? If that doesn't work I think your
suggestion of reverting nolock makes sense to me. We've moved to using
fq as our default now b/c of this bug.
Josh
er patch fixed the unwinder failure mode to be the above
(harmless) unwinder warning, instead of a disruptive KASAN failure.
This patch fixes the specific underlying crypto unwinding metadata
issue.
I'll definitely be sending both fixes. The improved failure mode patch
will come first because it's more urgent and lower risk.
--
Josh
On Wed, Feb 03, 2021 at 09:44:48PM -0500, Steven Rostedt wrote:
> > > [ 128.441287][C0] RIP: 0010:skcipher_walk_next
> > > (crypto/skcipher.c:322 crypto/skcipher.c:384)
>
> Why do we have an RIP in skcipher_walk_next, if its the unwinder that
> had a bug? Or are they related?
>
> Or did skci
bmit a fix for decode_stacktrace.sh).
> I cannot reproduce this one, and it took 2 days of uptime for it to
> happen. Is there anything I can do to help diagnose it?
Can you run with the same unwind_debug patch+cmdline when you try to
recreate this one? In the meantime I'll look at the available data.
--
Josh
On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > Can you recreate with this patch, and add "unwind_debug" to the cmdline?
> > > > It will spit out a bunch of stack data.
> > >
> > > Here's the three I'm building:
> > >
> > > * https://github.com/bobrik/linux/tree/ivan/static-cal
On Wed, Feb 03, 2021 at 02:41:53PM -0800, Ivan Babrou wrote:
> On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
> >
> > On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > > Can you pretty please not line-wrap console output? It's unreadable.
&
help. Do I
> need to apply the whole series or something else?
Can you recreate with this patch, and add "unwind_debug" to the cmdline?
It will spit out a bunch of stack data.
From: Josh Poimboeuf
Subject: [PATCH] Subject: [PATCH] x86/unwind: Add 'unwind_debug' cmdline
op
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 als
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
nks,
~ Michael
Jonas/Paolo
Do either of you know if there's been any development on a fix for this
issue? If not we can propose something.
Thanks
Josh
I'm worried about, it's all of them. There
are a lot of possibilities, with all the different configs, and arches.
Flags are usually added for a good reason, so one randomly missing flag
could have unforeseen results.
And I don't have any visibility into how GCC decides which flags to
drop, and when. But the docs aren't comforting.
Even if things seem to work now, that could (silently) change at any
point in time. This time objtool warned about the missing frame
pointer, but that's not necessarily going to happen for other flags.
If we go this route, I would much rather do -fno-gcse on a file-wide
basis.
--
Josh
On Wed, May 06, 2020 at 09:45:01AM -0700, Alexei Starovoitov wrote:
> On Wed, May 6, 2020 at 8:53 AM Josh Poimboeuf wrote:
> >
> > On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote:
> > > As far as workaround I prefer t
nd kernel stack
> unwinding can fall back from ORC to FP for that frame.
> wdyt?
It seems dangerous to me. The GCC manual recommends against it.
And how do we know what other flags are getting removed for various
arches (now or in the future)?
--
Josh
On Tue, May 05, 2020 at 12:53:20PM -0700, Alexei Starovoitov wrote:
> On Tue, May 05, 2020 at 01:11:08PM -0500, Josh Poimboeuf wrote:
> > On Tue, May 05, 2020 at 10:43:00AM -0700, Alexei Starovoitov wrote:
> > > > Or, if you want to minimize the patch's impact on other ar
ly real solution is to revert
3193c0836f20 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()")
Once you do that (and disable retpolines) then you should see the
problem described in my other email.
--
Josh
pproach. But DWARF has its own
issues and we can't rely on it for live patching.
As I mentioned we have a plan to use a compiler plugin to annotate jump
tables (including GCC switch tables). But the approach taken by this
patch should be good enough for now.
--
Josh
h yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e73ceacfd8560cc8a...@syzkaller.appspotmail.com
Infinite loop in network code.
#syz dup: BUG: stack guard page was hit in deref_stack_reg
--
Josh
On Fri, May 01, 2020 at 08:06:22PM -0700, Alexei Starovoitov wrote:
> On Fri, May 01, 2020 at 02:56:17PM -0500, Josh Poimboeuf wrote:
> > On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote:
> > > On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote:
>
On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote:
> On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote:
> > On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrot
On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrote:
> > Objtool decodes instructions and follows all potential code branches
> > within a function. But it's not an emulator, so it doesn't
6f20 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()")
Reported-by: Randy Dunlap
Reported-by: Arnd Bergmann
Signed-off-by: Josh Poimboeuf
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler_types.h | 4
kernel/bpf/core.c | 10 +++---
3
rtl_nic/rtl8153b-2.fw | Bin 0 -> 1088 bytes
> 5 files changed, 11 insertions(+)
> create mode 100644 rtl_nic/rtl8153a-2.fw
> create mode 100644 rtl_nic/rtl8153a-3.fw
> create mode 100644 rtl_nic/rtl8153a-4.fw
> create mode 100644 rtl_nic/rtl8153b-2.fw
Applied and pushed out.
josh
ive Project
We were investigating a problem in this area a few months back (it
turned out to be something else), but were wondering if retrans_out,
lost_out, and sacked_out should be cleared in tcp_rtx_queue_purge()? I
meant to get back to it, but it got buried and this just thread jogged
my memory...
--
Josh
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
up tar and flag it as a script.
Hi Aaron
It looks like the netdev archive has the file. Can you try grabbing it
from here?
https://lore.kernel.org/netdev/0e0e706c-4ce9-c27a-af55-339b4eb6d...@akamai.com/2-udpgso_bench.sh
If that doesn't work I can try your tar workaround.
Thanks
Josh
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
and fix
the WHENCE file because we merged a commit that changes how symlinks
are handled. All applied and pushed out.
josh
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
pt to update the man page to reflect this, but
it was rejected? I couldn't find any discussion on this.
Thanks
Josh
On Fri, Aug 30, 2019 at 11:56 AM Hau wrote:
>
> > On 27.08.2019 14:08, Josh Boyer wrote:
> > > On Mon, Aug 26, 2019 at 6:23 PM Heiner Kallweit
> > wrote:
> > >>
> > >> This adds firmware rtl8125a-3 for Realtek's 2.5Gbps chip
someone at Realtek then?
josh
> The related extension to r8169 driver will be submitted in the next days.
> ---
> WHENCE| 3 +++
> rtl_nic/rtl8125a-3.fw | Bin 0 -> 3456 bytes
> 2 files changed, 3 insertions(+)
> create mode 100644 rtl_nic/rtl8125a-3.fw
>
ased on the previous discussion this sounds fine to me.
Willem
Are you OK to ACK this? If not, is there something else you'd rather see
here?
Thanks
Josh
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
On Jul 1, 2019, at 6:51 PM, David Miller wrote:
> I just tried to apply this with "git am" to the current v4.19 -stable
> branch and it failed.
This is only needed for the v4.9 stable kernel, ndo_busy_poll (and this NPE)
went away in kernel 4.11.
Sorry, I probably should have called that out m
7fff47b7b ("net: remove support for per driver ndo_busy_poll()")
indirectly fixed this upstream in linux-4.11 by removing the offending
pointer usage. No other users of napi->dev touch its netdev_ops.
Fixes: 8b80cda536ea ("net: rename include/net/ll_poll.h to
include/net/busy_pol
7fff47b7b ("net: remove support for per driver ndo_busy_poll()")
indirectly fixed this upstream in linux-4.11 by removing the offending
pointer usage. No other users of napi->dev touch its netdev_ops.
Fixes: ce6aea93f751 ("net: network drivers no longer need to implement
ndo_busy_pol
In preparation for using R12 indexing instructions in BPF JIT code, add
support for generating the x86 SIB byte.
Signed-off-by: Josh Poimboeuf
---
arch/x86/net/bpf_jit_comp.c | 69 +
1 file changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/x86/net
.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
NFIG_RETPOLINE?
[0]: https://lore.kernel.org/patchwork/patch/1044863/
[1]: https://lore.kernel.org/patchwork/patch/1054472/
If nothing else the commit message no longer seems accurate.
Regards,
-- Josh
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
after sending inner IP fragmented traffic.
> - Issues in the following FW flows:
> SD VLAN update, TX packet drop, packet padding flow, vlan add/remove.
>
> Signed-off-by: Sudarsana Reddy Kalluru
> Signed-off-by: Ariel Elior
> Signed-off-by: Rahul Verma
Applied and pushed out.
josh
us on napi_id
instead of socket")
Signed-off-by: Josh Elsasser
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 82f20022259d..d1043d49979c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8712,7 +8712,9 @@ int init_dummy_net
On Jan 23, 2019, at 7:40 PM, Josh Elsasser wrote:
> On Jan 23, 2019, at 7:08 PM, Herbert Xu wrote:
>
>> Thanks for catching this!
>>
>> Although I think we should fix this in a different way. The problem
>> here is that the shrink cannot proceed because there wa
oversight the hashtable dodged the
reschedule loop.
- Josh
can actually be non-NULL and make forward progress when the
hashtable needs to shrink.
Fixes: da20420f83ea ("rhashtable: Add nested tables")
Signed-off-by: Josh Elsasser
---
lib/rhashtable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rh
On Thu, Dec 13, 2018 at 3:45 PM Shalom Toledo wrote:
>
> This new firmware contains: * New packet traps for discarded packets * Secure
> firmware flash bug fix * Fence mechanism bug fix * TCAM RMA bug fix
> Signed-off-by: Shalom Toledo
Applied and pushed out.
josh
Jeff Kirsher wrote:
> No need to re-spin the patch, just reply with the additional "Fixes"
> tag and if patchwork does not pick it up, I will add it to the patch I
> have in my tree for validation and review.
Thanks, let’s try that.
Fixes: e23f33367882 ("ixgbe: Fix 1G and 10G link stability for
for X550EM_x SFP+")
Looks like you’re right. Want me to respin with an additional “Fixes” tag?
- Josh
quot;)
Signed-off-by: Josh Elsasser
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 10dbaf4f6e80..9c42f741ed5e 100644
--- a/
The "send an email to i...@cavium.com" offer may
> (or may not) be sufficient for the letter of the law. But it seems
> both fragile and prone to subjective frustrations and delays for
> users to obtain the sources at some future date.
I agree with John here, but I also believe the patch is better than
the current text in the upstream repo. I've committed it and pushed
it out. If there are improvements to be made on source availability,
we can take those in a different patch.
Thank you for taking this seriously and responding quickly.
josh
I see it reusing SAs, so I'm good.
Joshua Coombs
On Wed, Oct 17, 2018 at 9:45 AM Josh Coombs wrote:
>
> I've got wpa_supplicant working with macsec on Fedora, my test bed has
> shuffled 16 billion packets so far without interruption. I am a bit
> concerned that I'
and RX, it appears to negotiate a new pair every 3 to 3.5
billion packets. It doesn't appear to be ripping down old SAs. What
happens when available SA slots run out?
Joshua Coombs
GWI
office 207-494-2140
www.gwi.net
On Mon, Oct 15, 2018 at 11:45 AM Josh Coombs wrote:
>
> And confi
ven't tested Gentoo's ebuilds yet to see if they do.
Josh Coombs
On Sun, Oct 14, 2018 at 4:52 PM Josh Coombs wrote:
>
> On Sun, Oct 14, 2018 at 4:24 PM Sabrina Dubroca wrote:
> >
> > 2018-10-14, 10:59:31 -0400, Josh Coombs wrote:
> > > I initially mistook t
On Sun, Oct 14, 2018 at 4:24 PM Sabrina Dubroca wrote:
>
> 2018-10-14, 10:59:31 -0400, Josh Coombs wrote:
> > I initially mistook this for a traffic control issue, but after
> > stripping the test beds down to just the MACSec component, I can still
> > replicate the iss
port 1 sa 0 pn 1 on key 01 "$rxkey"
ip link set "$eif" type macsec encrypt on
# Bring up the interfaces:
echo "* Light tunnel NICS"
ip link set "$dif" up
ip link set "$eif" up
# Set IP
ifconfig $eif 192.168.211.1/30
Once you can ping across th
set "$dif" up
ip link set "$eif" up
# Set IP
ifconfig $eif 192.168.211.1/30
echo " --=[ MACSec Up ]=--"
On Thu, Oct 11, 2018 at 10:05 AM Josh Coombs wrote:
>
> I'm actually leaning towards macsec now. I'm at 6TB transferred in a
> double hop, no ma
trip the issue there.That should determine if it's macsec
itself, or an interaction between macsec and traffic control.
Joshua Coombs
GWI
office 207-494-2140
www.gwi.net
On Wed, Oct 10, 2018 at 12:39 PM Cong Wang wrote:
>
> On Wed, Oct 10, 2018 at 8:54 AM Josh Coombs wrote:
u32 to matchall didn't change the performance. Going
back to the four machine test bed, again removing macsec and just
bridging through radically decreased the throughput to around 8Mbits.
Flip on macsec for the bridge and 1.3Gbits?
On Tue, Oct 9, 2018 at 11:58 AM Josh Coombs wrote:
>
>
ll \
u32 match u8 0 0 \
action mirred egress mirror dev "$eif"
# eif to sif
tc qdisc add dev "$eif" ingress
tc filter add dev "$eif" parent : \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev "$sif"
# Bring up the interfaces:
echo "* Light tunnel NICS"
ip link set "$sif" up
ip link set "$dif" up
ip link set "$eif" up
echo " --=[ MACSec Up ]=--"
---
Josh Coombs
frags and consume all frag memory (default high thresh is
4M) pretty easily and I believe also evict other frags which may have been
pending? I am guessing this is what Florian's min MTU patches are trying to
help with.
--
Josh
Applied and pushed out.
josh
On Sun, Jul 22, 2018 at 7:43 AM Nir Dotan wrote:
>
> This new firmware contains: - Support for new types of cables - Support for
> flashing future firmware without reboot - Support for Router ARP BC and UC
> traps Signed-off-by: Nir Dotan --
insertion(+), 1 deletion(-)
>
> Hello Maintainers of linux-firmware.git,
>
> Any feedback about this submission? We sent it two weeks ago, but we
> haven't heard anything.
Thanks for the ping. I missed this one and then confused it with an
older pull request with a similar subject line. I've pulled and
pushed out now.
josh
1 - 100 of 232 matches
Mail list logo
