es the regression for me.
Reported-by: Ayham Masood
Tested-by: Ilan Tayari
Thanks, Florian!
Hi Florian,
I debugged a little the regression I told you about the other day...
Steps and Symptoms:
1. Set up a host-to-host IPSec tunnel (or transport, doesn't matter)
2. Ping over IPSec, or do something to populate the pcpu cache
3. Join a MC group, then leave MC group
4. Try to ping again usi
. Values are now generated correctly.
Sorry for the mixup.
Thank you Arnd!
Reviewed-by: Ilan Tayari
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
>
> The new IPSec offload code introduced a build error:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> Subject: RE: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache
>
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> > Subject: [RF
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] [net-next] net/mlx5: include wq.o in non-ethernet build
> for FPGA
>
> Both the ethernet and FPGA portions of MLX5 now require the wq functions,
> and we get a link error when CONFIG_MLX5_CORE_EN is disabl
if (index < 0)
> return index;
>
> - mlx5_core_dbg(dev, "Allodating reserved GID %u\n", index);
> + mlx5_core_dbg(dev, "Allocating reserved GID %u\n", index);
> *gid_index = index;
> return 0;
> }
> --
> 2.11.0
Thank you Colin for the fix.
Reviewed-by: Ilan Tayari
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> Subject: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache
>
> retain last used xfrm_dst in a pcpu cache.
> On next request, reuse this dst if the policies are the same.
>
> The cache does
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> > > This keep getting more ugly :(
> > >
> > > What about security? What if user space sends some raw packets to the
> > >
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Sun, Jun 04, 2017 at 07:51:24AM +0000, Ilan Tayari wrote:
> > > From: Jason G
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Mon, May 29, 2017 at 04:09:06PM +0000, Ilan Tayari wrote:
>
> > > For IPSec, this is alrea
t for Innova
> >
> > On Mon, May 29, 2017 at 03:58:33PM +, Ilan Tayari wrote:
> > > > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > > > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for
> > Innova
> &
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Mon, May 29, 2017 at 03:58:33PM +0000, Ilan Tayari wrote:
> > > From: Jason G
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Sun, May 28, 2017 at 07:22:27AM +0000, Ilan Tayari wrote:
>
> > This is neither PCI-bar map
> -Original Message-
> From: Jes Sorensen [mailto:jsoren...@fb.com]
>
> On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
> > On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
> >> On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
> > Hi Jes,
> >
> > No, It is clearly stated in the commit mes
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
>
> On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote:
>
> > > for that feature which is the originating place, before defining
> > > APIs/infrastructures,
> > > until the feature is com
> -Original Message-
> From: Alexei Starovoitov [mailto:alexei.starovoi...@gmail.com]
>
> On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote:
> > From: Ilan Tayari
> >
> > Mellanox Innova is a NIC with ConnectX and an FPGA on the same
> > b
> -Original Message-
> From: Steffen Klassert [mailto:steffen.klass...@secunet.com]
>
> On Sun, Apr 30, 2017 at 04:34:38PM +0300, il...@mellanox.com wrote:
> > From: Ilan Tayari
> >
> > Both esp_output and esp_xmit take a pointer to the ESP header
>
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> Subject: [PATCH 07/16] esp4: Reorganize esp_output
>
> We need a fallback for ESP at layer 2, so split esp_output into generic
> functions that can be used at layer 3 and layer 2 and use them
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
>
> > From: Ilan Tayari
> >
> > Commit 07b26c9454a2 ("gso: Support partial splitting at the frag_list
> > pointer") assumes that all SKBs in a frag_list (except maybe the l
uot;xfrm: Clone states properly on migration")
without resolving this leak.
This patch adds a kfree() call for the aead algorithm name.
Fixes: 1a6509d99122 ("[IPSEC]: Add support for combined mode algorithms")
Signed-off-by: Ilan Tayari
---
net/xfrm/xfrm_state.c | 1 +
1 file chang
> Add the following traps:
>
> 1) MTU Error: Trap packets whose size is bigger than the egress RIF's MTU. If
> DF
> bit isn't set, traffic will continue to be routed in slow path.
>
> 2) TTL Error: Trap packets whose TTL expired. This allows traceroute to work
> properly.
>
> 3) OSPF packets.
> Node 1: fd01:1b10:1000::1 is running 4.6.4
> 14:21:50.737092 IP6 fd01:1b10:1000::3 > ff0e::1:
> ESP(spi=0x0001,seq=0x100), length 136
> 14:21:51.737155 IP6 fd01:1b10:1000::3 > ff0e::1:
> ESP(spi=0x0001,seq=0x101), length 136
...
> ip -s xfrm state
> src fd01:1b10:1000::1 dst ff0e::1
>
> On the receiving side (e.g. fd01:1b10:1000::1) I see the decrypted packets
> with
> the 2.6.23 kernel:
> but NOT with the newer kernel:
Hi Joerg,
First steps to debug this would be:
cat /proc/net/xfrm_stat
ip -s xfrm state
ip -s xfrm policy
First command will show some error accounting, whi
Hi Jiri,
> Thoughts?
One general thought comes to mind, regardless of your proposed solutions:
You'll need to take care to propagate the error properly in case of routes
created by the kernel, such as local routes.
Local routes are created when an IP address is added to an interface, so in
suc
25 matches
Mail list logo
