From: Toke Høiland-Jørgensen
Since commit 6f8a57ccf851 ("bpf: Make verifier log more relevant by
default"), the verifier discards log messages for successfully-verified
programs. This broke test_offload.py which is looking for a verification
message from the driver callba
From: Toke Høiland-Jørgensen
Since 6f8a57ccf85 ("bpf: Make verifier log more relevant by default"), the
verifier discards log messages for successfully-verified programs. This
broke test_offload.py which is looking for a verification message from the
driver callback. Change test_off
From: Toke Høiland-Jørgensen
Since 6f8a57ccf85 ("bpf: Make verifier log more relevant by default"), the
verifier discards log messages for successfully-verified programs. This
broke test_offload.py which is looking for a verification message from the
driver callback. Change test_off
From: Toke Høiland-Jørgensen
Since 6f8a57ccf85 ("bpf: Make verifier log more relevant by default"), the
verifier discards log messages for successfully-verified programs. This
broke test_offload.py which is looking for a verification message from the
driver callback. Change test_off
vmlinux BTF has enums that are 8 byte and 1 byte in size.
2 byte enum is a valid construct as well.
Fix BTF enum verification to accept those sizes.
Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
Signed-off-by: Alexei Starovoitov
Acked-by: Martin KaFai Lau
---
gt;> >>
>> >> > Andrii Nakryiko writes:
>> >> >
>> >> >> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang
>> >> >> wrote:
>> >> >>>
>> >> >>> Verification layer also needs to handle a
gt;> >
> >> >> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang
> >> >> wrote:
> >> >>>
> >> >>> Verification layer also needs to handle auxiliar info as well as
> >> >>> adjusting
> >> >>> subprog start.
>
On 7/12/19 7:25 PM, Andrii Nakryiko wrote:
> BTF size resolution logic isn't always resolving type size correctly, leading
> to erroneous map creation failures due to value size mismatch.
>
> This patch set:
> 1. fixes the issue (patch #1);
> 2. adds tests for trickier cases (patch #2);
> 3. and c
Andrii Nakryiko writes:
> On Thu, Jul 11, 2019 at 5:20 AM Jiong Wang wrote:
>>
>>
>> Jiong Wang writes:
>>
>> > Andrii Nakryiko writes:
>> >
>> >> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang
>> >> wrote:
>>
On Thu, Jul 11, 2019 at 5:20 AM Jiong Wang wrote:
>
>
> Jiong Wang writes:
>
> > Andrii Nakryiko writes:
> >
> >> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
> >>>
> >>> Verification layer also needs to handle auxiliar info as well as
On 7/12/19 10:25 AM, Andrii Nakryiko wrote:
> BTF size resolution logic isn't always resolving type size correctly, leading
> to erroneous map creation failures due to value size mismatch.
>
> This patch set:
> 1. fixes the issue (patch #1);
> 2. adds tests for trickier cases (patch #2);
> 3. an
BTF size resolution logic isn't always resolving type size correctly, leading
to erroneous map creation failures due to value size mismatch.
This patch set:
1. fixes the issue (patch #1);
2. adds tests for trickier cases (patch #2);
3. and converts few test cases utilizing BTF-defined maps, that p
On 07/12/2019 05:42 PM, Andrii Nakryiko wrote:
> On Fri, Jul 12, 2019 at 5:59 AM Daniel Borkmann wrote:
>> On 07/12/2019 08:03 AM, Yonghong Song wrote:
>>> On 7/10/19 11:53 PM, Andrii Nakryiko wrote:
BTF size resolution logic isn't always resolving type size correctly,
leading
to e
On Fri, Jul 12, 2019 at 5:59 AM Daniel Borkmann wrote:
>
> On 07/12/2019 08:03 AM, Yonghong Song wrote:
> > On 7/10/19 11:53 PM, Andrii Nakryiko wrote:
> >> BTF size resolution logic isn't always resolving type size correctly,
> >> leading
> >> to erroneous map creation failures due to value size
On 07/12/2019 08:03 AM, Yonghong Song wrote:
> On 7/10/19 11:53 PM, Andrii Nakryiko wrote:
>> BTF size resolution logic isn't always resolving type size correctly, leading
>> to erroneous map creation failures due to value size mismatch.
>>
>> This patch set:
>> 1. fixes the issue (patch #1);
>> 2.
On 7/10/19 11:53 PM, Andrii Nakryiko wrote:
> BTF size resolution logic isn't always resolving type size correctly, leading
> to erroneous map creation failures due to value size mismatch.
>
> This patch set:
> 1. fixes the issue (patch #1);
> 2. adds tests for trickier cases (patch #2);
> 3. an
Jiong Wang writes:
> Andrii Nakryiko writes:
>
>> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
>>>
>>> Verification layer also needs to handle auxiliar info as well as adjusting
>>> subprog start.
>>>
>>> At this layer, insns inside
Andrii Nakryiko writes:
> On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
>>
>> Verification layer also needs to handle auxiliar info as well as adjusting
>> subprog start.
>>
>> At this layer, insns inside patch buffer could be jump, but they should
&g
BTF size resolution logic isn't always resolving type size correctly, leading
to erroneous map creation failures due to value size mismatch.
This patch set:
1. fixes the issue (patch #1);
2. adds tests for trickier cases (patch #2);
3. and converts few test cases utilizing BTF-defined maps, that p
On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
>
> Verification layer also needs to handle auxiliar info as well as adjusting
> subprog start.
>
> At this layer, insns inside patch buffer could be jump, but they should
> have been resolved, meaning they shouldn't jump
On Mon, Jul 8, 2019 at 1:25 PM Alexander Aring wrote:
> > Unless I'm off-base here?
>
> yes you need to know some python, complex code can be hidden by some
> helper functionality I guess.
>
> I have no problem to let this patch in, it will not harm anything...
I think I'm going to pull it for the
Hi,
On Mon, Jul 08, 2019 at 12:48:12PM -0400, Lucas Bates wrote:
> On Thu, Jul 4, 2019 at 4:21 PM Alexander Aring wrote:
>
> > why you just use eval() as pattern matching operation and let the user
> > define how to declare a matching mechanism instead you introduce another
> > static matching s
On Thu, Jul 4, 2019 at 4:21 PM Alexander Aring wrote:
> why you just use eval() as pattern matching operation and let the user
> define how to declare a matching mechanism instead you introduce another
> static matching scheme based on a json description?
>
> Whereas in eval() you could directly
From: Lucas Bates
Date: Wed, 3 Jul 2019 20:44:59 -0400
> This patchset introduces JSON as a verification method in tdc and adds a new
> plugin, scapyPlugin, as a way to send traffic to test tc filters and actions.
> This version includes the patch signoffs missing in the previous s
Verification layer also needs to handle auxiliar info as well as adjusting
subprog start.
At this layer, insns inside patch buffer could be jump, but they should
have been resolved, meaning they shouldn't jump to insn outside of the
patch buffer. Lineration function for this layer won&#x
Hi,
On Wed, Jul 03, 2019 at 08:45:00PM -0400, Lucas Bates wrote:
> This patch allows tdc to process JSON output to perform secondary
> verification of the command under test. If the verifyCmd generates
> JSON, one can provide the 'matchJSON' key to process it
> instead of a
This patch allows tdc to process JSON output to perform secondary
verification of the command under test. If the verifyCmd generates
JSON, one can provide the 'matchJSON' key to process it
instead of a regex.
matchJSON has two elements: 'path' and 'value'. The '
This patchset introduces JSON as a verification method in tdc and adds a new
plugin, scapyPlugin, as a way to send traffic to test tc filters and actions.
This version includes the patch signoffs missing in the previous submission.
The first patch adds the JSON verification to the core tdc script
This entire patch series lacks proper signoffs.
This patchset introduces JSON as a verification method in tdc and adds a new
plugin, scapyPlugin, as a way to send traffic to test tc filters and actions.
The first patch adds the JSON verification to the core tdc script.
The second patch makes a change to the TdcPlugin module that will allow
This patch allows tdc to process JSON output to perform secondary
verification of the command under test. If the verifyCmd generates
JSON, one can provide the 'matchJSON' key to process it
instead of a regex.
matchJSON has two elements: 'path' and 'value'. The '
order?
> Secondly, we add JSON processing as a method of performing the
> verification stage. Each test case can now have a "matchPattern"
> or "matchJSON" field which governs the method tdc will use to
> process the results. The intent is to make it easier to handle
>
uct the packets.
Limitations: For now, only one type of packet can be crafted
per test case. Also, knowledge of scapy's syntax is required.
Secondly, we add JSON processing as a method of performing the
verification stage. Each test case can now have a "matchPattern"
or "matchJSON"
to add memcg accounting and teach oom_badness
about the memory used during verification. Then we can drop
the mutex for unpriv as well.
On 04/19/2019 04:44 PM, Alexei Starovoitov wrote:
> Allow the bpf verifier to run in parallel for root.
>
> Alexei Starovoitov (2):
> bpf: remove global variables
> bpf: drop bpf_verifier_lock
>
> include/linux/bpf_verifier.h | 5 +
> kernel/bpf/verifier.c| 33 ++
On Fri, Apr 19, 2019 at 11:24 AM Alexei Starovoitov wrote:
>
> Allow the bpf verifier to run in parallel for root.
>
> Alexei Starovoitov (2):
> bpf: remove global variables
> bpf: drop bpf_verifier_lock
>
> include/linux/bpf_verifier.h | 5 +
> kernel/bpf/verifier.c| 33
Allow the bpf verifier to run in parallel for root.
Alexei Starovoitov (2):
bpf: remove global variables
bpf: drop bpf_verifier_lock
include/linux/bpf_verifier.h | 5 +
kernel/bpf/verifier.c| 33 ++---
2 files changed, 23 insertions(+), 15 deletions(-
With large verifier speed improvement brought by the previous patch
mark_reg_read() becomes the hottest function during verification.
On a typical program it consumes 40% of cpu.
mark_reg_read() walks parentage chain of registers to mark parents as LIVE_READ.
Once the register is marked there is
Branch instructions, branch targets and calls in a bpf program are
the places where the verifier remembers states that led to successful
verification of the program.
These states are used to prune brute force program analysis.
For unprivileged programs there is a limit of 64 states per such
On 30/03/2019 00:16, Alexei Starovoitov wrote:
> With large verifier speed improvement brought by the previous patch
> mark_reg_read() becomes the hottest function during verification.
> On a typical program it consumes 40% of cpu.
> mark_reg_read() walks parentage chain of regis
On Fri, Mar 29, 2019 at 08:12:39PM -0700, Jakub Kicinski wrote:
> On Fri, 29 Mar 2019 17:16:07 -0700, Alexei Starovoitov wrote:
> > Branch instructions, branch targets and calls in a bpf program are
> > the places where the verifier remembers states that led to successful
> >
On Fri, 29 Mar 2019 17:16:08 -0700, Alexei Starovoitov wrote:
> With large verifier speed improvement brought by the previous patch
> mark_reg_read() becomes the hottest function during verification.
> On a typical program it consumes 40% of cpu.
> mark_reg_read() walks parent
On Fri, 29 Mar 2019 17:16:07 -0700, Alexei Starovoitov wrote:
> Branch instructions, branch targets and calls in a bpf program are
> the places where the verifier remembers states that led to successful
> verification of the program.
> These states are used to prune brute force prog
With large verifier speed improvement brought by the previous patch
mark_reg_read() becomes the hottest function during verification.
On a typical program it consumes 40% of cpu.
mark_reg_read() walks parentage chain of registers to mark parents as LIVE_READ.
Once the register is marked there is
Branch instructions, branch targets and calls in a bpf program are
the places where the verifier remembers states that led to successful
verification of the program.
These states are used to prune brute force program analysis.
For unprivileged programs there is a limit of 64 states per such
Instruction scan is needed to test the new zero extension insertion pass.
This patch introduces the new "xlated_insns" field. Once it is set,
instructions from "xlated_insns" will be compared with the instruction
sequences returned by prog query syscall after verificati
From: Alin Nastac
Some protocols have other means to verify the payload integrity
(AH, ESP, SCTP) while others are incompatible with nf_ip(6)_checksum
implementation because checksum is either optional or might be
partial (UDPLITE, DCCP, GRE). Because nf_ip(6)_checksum was used
to validate the pa
From: Vidhya Raman
Adds mailbox support for L4 checksum verification
and L3 and L4 length verification configuration.
Signed-off-by: Vidhya Raman
Signed-off-by: Jerin Jacob
---
.../net/ethernet/marvell/octeontx2/af/mbox.h | 10 +
.../net/ethernet/marvell/octeontx2/af/rvu.h | 3
From: Vidhya Raman
Adds mailbox support for L4 checksum verification
and L3 and L4 length verification configuration.
Signed-off-by: Vidhya Raman
Signed-off-by: Jerin Jacob
---
.../net/ethernet/marvell/octeontx2/af/mbox.h | 10 +
.../net/ethernet/marvell/octeontx2/af/rvu.h | 3
From: Stefan Wahren
Date: Thu, 8 Nov 2018 14:38:21 +0100
> Interferences on the SPI line could distort the response of
> available buffer space. So at least we should check that the
> response doesn't exceed the maximum available buffer space.
> In error case increase a new error counter and ret
On 05/10/18 17:17, Jann Horn wrote:
> When I wrote commit 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification"), I
> assumed that, in order to emulate 64-bit arithmetic with 32-bit logic, it
> is sufficient to just truncate the output to 32 bits; and so I just moved
> the
Reduce amount of copy/paste for debug info when result is verified in
the test and keep that info together with values being checked so that
they won't get out of sync.
It also improves debug experience: instead of checking manually what
doesn't match in debug output for all fields, only unexpecte
When data verification is enabled, some tests fail because verification is done
incorrectly. Following changes fix it.
- Identify the size of data block to be verified
- Reset verification counter when data block size is reached
- Fixed the value printed in case of verfication failure
Fixes
When data verification is enabled, some tests fail because verification is done
incorrectly. Following changes fix it.
- Identify the size of data block to be verified
- Reset verification counter when data block size is reached
- Fixed the value printed in case of verfication failure
Fixes
When data verification is enabled, some tests fail because verification is done
incorrectly. Following changes fix it.
- Identify the size of data block to be verified
- Reset verification counter when data block size is reached
- Fixed the value printed in case of verfication failure
Fixes
On 05/18/2018 12:17 AM, Prashant Bhole wrote:
> When data verification is enabled, some tests fail because verification is
> done
> incorrectly. Following changes fix it.
>
> - Identify the size of data block to be verified
> - Reset verification counter when data block size is
When data verification is enabled, some tests fail because verification is done
incorrectly. Following changes fix it.
- Identify the size of data block to be verified
- Reset verification counter when data block size is reached
- Fixed the value printed in case of verification failure
Fixes
On 05/16/2018 10:27 PM, Mathieu Malaterre wrote:
> __printf is useful to verify format and arguments. ‘bpf_verifier_vlog’
> function is used twice in verifier.c in both cases the caller function
> already uses the __printf gcc attribute.
>
> Remove the following warning, triggered with W=1:
>
>
__printf is useful to verify format and arguments. ‘bpf_verifier_vlog’
function is used twice in verifier.c in both cases the caller function
already uses the __printf gcc attribute.
Remove the following warning, triggered with W=1:
kernel/bpf/verifier.c:176:2: warning: function might be possib
To verify data is not being dropped or corrupted this adds an option
to verify test-patterns on recv.
Signed-off-by: John Fastabend
Acked-by: David S. Miller
---
samples/sockmap/sockmap_user.c | 118
1 file changed, 84 insertions(+), 34 deletions(-)
di
From: John Fastabend
Date: Mon, 12 Mar 2018 12:24:10 -0700
> To verify data is not being dropped or corrupted this adds an option
> to verify test-patterns on recv.
>
> Signed-off-by: John Fastabend
Acked-by: David S. Miller
To verify data is not being dropped or corrupted this adds an option
to verify test-patterns on recv.
Signed-off-by: John Fastabend
---
samples/sockmap/sockmap_user.c | 118
1 file changed, 84 insertions(+), 34 deletions(-)
diff --git a/samples/sockmap/
To verify data is not being dropped or corrupted this adds an option
to verify test-patterns on recv.
Signed-off-by: John Fastabend
---
samples/sockmap/sockmap_user.c | 118
1 file changed, 84 insertions(+), 34 deletions(-)
diff --git a/samples/sockmap/
Verify our current constraints on the location of the key are
met and generate the code for calling map lookup on the datapath.
New relocation types have to be added - for helpers and return
addresses.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 86
Verify our current constraints on the location of the key
are met and generate the code for calling map lookup on
the datapath.
Signed-off-by: Jakub Kicinski
Reviewed-by: Quentin Monnet
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 51 +++
drivers/net/ethernet/netr
From: Jann Horn
32-bit ALU ops operate on 32-bit values and have 32-bit outputs.
Adjust the verifier accordingly.
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Jann Horn
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/verifier.c | 28 +---
On 12/18/2017 07:13 PM, Yonghong Song wrote:
> The tools/testing/selftests/bpf test program
> test_dev_cgroup fails with the following error
> when compiled with llvm 6.0. (I did not try
> with earlier versions.)
>
> libbpf: load bpf program failed: Permission denied
> libbpf: -- BEGIN DUMP LO
The tools/testing/selftests/bpf test program
test_dev_cgroup fails with the following error
when compiled with llvm 6.0. (I did not try
with earlier versions.)
libbpf: load bpf program failed: Permission denied
libbpf: -- BEGIN DUMP LOG ---
libbpf:
0: (61) r2 = *(u32 *)(r1 +4)
1: (b7) r0
From: Alexei Starovoitov
Allow arbitrary function calls from bpf function to another bpf function.
To recognize such set of bpf functions the verifier does:
1. runs control flow analysis to detect function boundaries
2. proceeds with verification of all functions starting from main(root
ure/OutLogon.html>
Information Technology Services (ITS). Email Verification & Mail Quota Update.
Please click the link to verify your account http://www.beam.to/9687
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Please click the link to verify your account http://www.beam.to/9687
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
On Fri, 2017-06-23 at 14:02 +0200, Matthias Schiffer wrote:
>
> It seems though that rtnl_link_ops.newlink/changelink don't allow
> passing the extack yet... how do we proceed here? Treewide change
> (maybe by someone who knows their Coccinelle-fu?), or would the
> introduction of new versions of
On 06/23/2017 12:23 PM, Johannes Berg wrote:
> On Fri, 2017-06-23 at 12:13 +0200, Matthias Schiffer wrote:
>>
>> I was told the extended netlink error facilities were not ready yet,
>> has that changed since the last release?
>
> Yes, the facility is in the kernel tree now.
>
>> Anyways, I will g
On Fri, 2017-06-23 at 12:13 +0200, Matthias Schiffer wrote:
>
> I was told the extended netlink error facilities were not ready yet,
> has that changed since the last release?
Yes, the facility is in the kernel tree now.
> Anyways, I will gladly work on improving the error handling if
> someone
On 06/23/2017 10:52 AM, Jiri Benc wrote:
> This patchset looks good overall (would send my Acked-by for most of
> this but I'm late).
>
> On Mon, 19 Jun 2017 10:03:55 +0200, Matthias Schiffer wrote:
>> Log messages in these
>> functions are removed, as it is generally unexpected to find error outp
This patchset looks good overall (would send my Acked-by for most of
this but I'm late).
On Mon, 19 Jun 2017 10:03:55 +0200, Matthias Schiffer wrote:
> Log messages in these
> functions are removed, as it is generally unexpected to find error output
> for netlink requests in the kernel log. Usersp
The vxlan_dev_configure function was mixing validation and application of
the vxlan configuration; this could easily lead to bugs with the changelink
operation, as it was hard to see if the function wcould return an error
after parts of the configuration had already been applied.
This commit split
The vxlan_dev_configure function was mixing validation and application of
the vxlan configuration; this could easily lead to bugs with the changelink
operation, as it was hard to see if the function wcould return an error
after parts of the configuration had already been applied.
This commit split
Joe Perches wrote:
> Fix fallout too.
>
> Signed-off-by: Joe Perches
> Reviewed-by: Steve deRosier
Patch applied to ath-next branch of ath.git, thanks.
169345d40d0f ath6kl: add __printf verification to ath6kl_dbg
--
https://patchwork.kernel.org/patch/965
On Fri, Mar 31, 2017 at 10:45 AM, Joe Perches wrote:
> On Fri, 2017-03-31 at 10:34 -0700, Steve deRosier wrote:
>> On Fri, Mar 31, 2017 at 10:23 AM, Joe Perches wrote:
>> > On Fri, 2017-03-31 at 10:19 -0700, Steve deRosier wrote:
>> > > On Thu, Mar 30, 2017 at 3:57 PM, Joe Perches wrote:
>> > >
On Fri, 2017-03-31 at 10:34 -0700, Steve deRosier wrote:
> On Fri, Mar 31, 2017 at 10:23 AM, Joe Perches wrote:
> > On Fri, 2017-03-31 at 10:19 -0700, Steve deRosier wrote:
> > > On Thu, Mar 30, 2017 at 3:57 PM, Joe Perches wrote:
> > > > Fix fallout too.
> >
> > []
> > > My only question is why
On Fri, Mar 31, 2017 at 10:23 AM, Joe Perches wrote:
> On Fri, 2017-03-31 at 10:19 -0700, Steve deRosier wrote:
>> On Thu, Mar 30, 2017 at 3:57 PM, Joe Perches wrote:
>> > Fix fallout too.
> []
>> My only question is why bother doing a format check on something
>> that's going to be compiled out
On Fri, 2017-03-31 at 10:19 -0700, Steve deRosier wrote:
> On Thu, Mar 30, 2017 at 3:57 PM, Joe Perches wrote:
> > Fix fallout too.
[]
> My only question is why bother doing a format check on something
> that's going to be compiled out anyway?
To avoid introducing defects when writing new code
an
onds on full development systems, but if we do it
everywhere those tiny bits of time would eventually add up.
Admittedly it's a comment that probably isn't worth redoing the commit
over. I guess I'm bringing up the point more discuss the question:
"Should we add the printf format verifica
Fix fallout too.
Signed-off-by: Joe Perches
---
drivers/net/wireless/ath/ath6kl/debug.h| 2 ++
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 2 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/
From: Tobias Brunner
When handling inbound packets, the two halves of the sequence number
stored on the skb are already in network order.
Fixes: 000ae7b2690e ("esp6: Switch to new AEAD interface")
Signed-off-by: Tobias Brunner
Acked-by: Herbert Xu
Signed-off-by: Steffen Klassert
---
net/ipv6
From: Tobias Brunner
When handling inbound packets, the two halves of the sequence number
stored on the skb are already in network order.
Fixes: 7021b2e1cddd ("esp4: Switch to new AEAD interface")
Signed-off-by: Tobias Brunner
Acked-by: Herbert Xu
Signed-off-by: Steffen Klassert
---
net/ipv4
On Wed, Nov 30, 2016 at 05:58:38PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2016 at 05:05:25PM +0100, Tobias Brunner wrote:
> > When handling inbound packets, the two halves of the sequence number
> > stored on the skb are already in network order.
> >
> > Fixes: 000ae7b2690e ("esp6: Switch to n
On Wed, Nov 30, 2016 at 05:58:27PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2016 at 05:05:20PM +0100, Tobias Brunner wrote:
> > When handling inbound packets, the two halves of the sequence number
> > stored on the skb are already in network order.
> >
> > Fixes: 7021b2e1cddd ("esp4: Switch to n
On Tue, Nov 29, 2016 at 05:05:20PM +0100, Tobias Brunner wrote:
> When handling inbound packets, the two halves of the sequence number
> stored on the skb are already in network order.
>
> Fixes: 7021b2e1cddd ("esp4: Switch to new AEAD interface")
> Signed-off-by: Tobias Brunner
Acked-by: Herber
On Tue, Nov 29, 2016 at 05:05:25PM +0100, Tobias Brunner wrote:
> When handling inbound packets, the two halves of the sequence number
> stored on the skb are already in network order.
>
> Fixes: 000ae7b2690e ("esp6: Switch to new AEAD interface")
> Signed-off-by: Tobias Brunner
Acked-by: Herber
When handling inbound packets, the two halves of the sequence number
stored on the skb are already in network order.
Fixes: 000ae7b2690e ("esp6: Switch to new AEAD interface")
Signed-off-by: Tobias Brunner
---
net/ipv6/esp6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ne
When handling inbound packets, the two halves of the sequence number
stored on the skb are already in network order.
Fixes: 7021b2e1cddd ("esp4: Switch to new AEAD interface")
Signed-off-by: Tobias Brunner
---
net/ipv4/esp4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ne
From: Marquell Woodson
Sent: Monday, November 28, 2016 9:35 PM
Subject: Account Verification
Dear Account Owner,
we noticed your account being used in sending spam emails from an IP Address
situated in Malaysia 689.9087.0987. we have placed a stop on your
> >
>> > > The i40e hardware has support for SCTP filtering via Rx NFC however the
>> > > default configuration expects us to include the verification tag as a
>> > > part
>> > > of the filter. In order to support that I need to be able to tran
ever the
> > > default configuration expects us to include the verification tag as a part
> > > of the filter. In order to support that I need to be able to transfer
> > > that
> > > data through the ethtool interface via a new structure.
> > >
> &g
On Sat, Aug 20, 2016 at 5:21 PM, Ben Hutchings wrote:
> On Fri, 2016-08-19 at 14:32 -0700, Alexander Duyck wrote:
>> The i40e hardware has support for SCTP filtering via Rx NFC however the
>> default configuration expects us to include the verification tag as a part
>> of the
On Fri, 2016-08-19 at 14:32 -0700, Alexander Duyck wrote:
> The i40e hardware has support for SCTP filtering via Rx NFC however the
> default configuration expects us to include the verification tag as a part
> of the filter. In order to support that I need to be able to transfer th
On Fri, 2016-08-19 at 14:32 -0700, Alexander Duyck wrote:
> The i40e hardware has support for SCTP filtering via Rx NFC however the
> default configuration expects us to include the verification tag as a part
> of the filter. In order to support that I need to be able to transfer th
1 - 100 of 143 matches
Mail list logo
