use nla_strlcpy() to avoid copying data beyond the length of TCA_DEF_DATA
netlink attribute, in case it is less than SIMP_MAX_DATA and it does not
end with '\0' character.
v2: fix errors in the commit message, thanks Hangbin Liu
Fixes: fa1b1cff3d06 ("net_cls_act: Make act_simple use of netlink
On Fri, 2018-06-08 at 10:07 +0800, Hangbin Liu wrote:
> On Thu, Jun 07, 2018 at 03:46:43PM +0200, Davide Caratti wrote:
> > use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
>
> s/TCA_DEFDATA/TCA_DEF_DATA/, incase someone search the commit history but
> could not find it.
>
On Mon, Jun 4, 2018 at 8:51 AM 吉藤英明 wrote:
>
> > + if (ipv6_get_lladdr(dev, , IFA_F_TENTATIVE))
> > + get_random_bytes(eui, 8);
>
> Please be aware of I/G bit and G/L bit.
Actually, I think this is fine. RFC 7136 clarified this, and says:
==
Thus, we can conclude
On Thu, Jun 07, 2018 at 03:46:43PM +0200, Davide Caratti wrote:
> use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
s/TCA_DEFDATA/TCA_DEF_DATA/, incase someone search the commit history but
could not find it.
Thanks
Hangbin
--
Good day,
i know you do not know me personally but i have checked your profile
and i see generosity in you, There's an urgent offer attach
to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of
the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and
head of
On 6/7/18 5:07 PM, Jakub Kicinski wrote:
>> After recompiling the 4.16.7 kernel with gcc 8.1, UBSAN reports the
>> following:
>>
>> [ 25.427424]
>>
>> [ 25.429680] UBSAN: Undefined behaviour in
CC: Andrey
On Thu, 7 Jun 2018 17:53:35 -0700, David Ahern wrote:
> On 6/7/18 5:49 PM, Jakub Kicinski wrote:
> > On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
> >> On 06/07/2018 05:11 PM, David Miller wrote:
> >>> From: Jakub Kicinski
> >>> Date: Thu, 7 Jun 2018 17:06:23 -0700
> >>>
On 6/7/18 5:49 PM, Jakub Kicinski wrote:
> On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
>> On 06/07/2018 05:11 PM, David Miller wrote:
>>> From: Jakub Kicinski
>>> Date: Thu, 7 Jun 2018 17:06:23 -0700
>>>
[ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
>>>
>>> This calls
On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
> On 06/07/2018 05:11 PM, David Miller wrote:
> > From: Jakub Kicinski
> > Date: Thu, 7 Jun 2018 17:06:23 -0700
> >
> >> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
> >
> > This calls ip_setup_cork() which can NULL out the 'rt'
On 06/07/2018 05:11 PM, David Miller wrote:
> From: Jakub Kicinski
> Date: Thu, 7 Jun 2018 17:06:23 -0700
>
>> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
>
> This calls ip_setup_cork() which can NULL out the 'rt' route
> pointer. Hmmm... :-/
>
UBSAN seems unhappy with dst being
On Thu, Jun 7, 2018 at 4:48 PM, wrote:
> From: Ben Greear
>
> While testing an ath10k firmware that often crashed under load,
> I was seeing kernel crashes as well. One of them appeared to
> be a dereference of a NULL flow object in fq_tin_dequeue.
>
> I have since fixed the firmware flaw, but
From: Jakub Kicinski
Date: Thu, 7 Jun 2018 17:06:23 -0700
> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
This calls ip_setup_cork() which can NULL out the 'rt' route
pointer. Hmmm... :-/
On Mon, 7 May 2018 10:33:45 -0700, Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Mon, 07 May 2018 16:07:24 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 199637] New: UBSAN: Undefined behaviour in
> net/ipv4/fib_trie.c:503:6
>
From: Alexei Starovoitov
Date: Thu, 7 Jun 2018 15:31:14 -0700
> syzbot reported the following crash
> [ 338.293946] bpfilter: read fail -512
> [ 338.304515] kasan: GPF could be caused by NULL-ptr deref or user memory
> access
> [ 338.311863] general protection fault: [#1] SMP KASAN
> [
From: Daniel Borkmann
Date: Fri, 8 Jun 2018 01:30:00 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks
On Tue, 8 May 2018 08:52:35 -0600, David Ahern wrote:
> On 5/7/18 10:12 PM, David Miller wrote:
> > From: Stephen Hemminger
> > Date: Mon, 7 May 2018 10:34:00 -0700
> >
> >> Subject: [Bug 199643] New: UBSAN: Undefined behaviour in
> >> ./include/net/route.h:240:2
> >
> > That's an empty
On Thu, Jun 7, 2018 at 4:48 PM, wrote:
> diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
> index be7c0fa..cb911f0 100644
> --- a/include/net/fq_impl.h
> +++ b/include/net/fq_impl.h
> @@ -78,7 +78,10 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>
From: Ben Greear
While testing an ath10k firmware that often crashed under load,
I was seeing kernel crashes as well. One of them appeared to
be a dereference of a NULL flow object in fq_tin_dequeue.
I have since fixed the firmware flaw, but I think it would be
worth adding the WARN_ON in case
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix in the BPF verifier to reject modified ctx pointers on helper
functions, from Daniel.
2) Fix in BPF kselftests for get_cgroup_id_user() helper to only
record the cgroup id for a
Hi Toke,
On 06/06/2018 07:58 PM, Toke Høiland-Jørgensen wrote:
> Add two new helper functions to trace_helpers that supports polling
> multiple perf file descriptors for events. These are used to the XDP
> perf_event_output example, which needs to work with one perf fd per CPU.
>
> Reviewed-by:
On Fri, Jun 08, 2018 at 12:06:01AM +0200, Daniel Borkmann wrote:
> syzkaller was able to trigger the following panic for AF_XDP:
>
> BUG: KASAN: null-ptr-deref in atomic64_sub
> include/asm-generic/atomic-instrumented.h:144 [inline]
> BUG: KASAN: null-ptr-deref in atomic_long_sub
>
On Thu, Jun 07, 2018 at 03:15:15PM -0700, Cong Wang wrote:
> > You do realize that the same ->setattr() can be called by way of
> > chown() on /proc/self/fd/, right? What would you do there -
> > bump refcount on that struct file when traversing that symlink and
> > hold it past the end of
syzbot reported the following crash
[ 338.293946] bpfilter: read fail -512
[ 338.304515] kasan: GPF could be caused by NULL-ptr deref or user memory
access
[ 338.311863] general protection fault: [#1] SMP KASAN
[ 338.344360] RIP: 0010:__vfs_write+0x4a6/0x960
[ 338.426363] Call Trace:
[
On 06/06/2018 06:12 PM, Yonghong Song wrote:
> Commit f269099a7e7a ("tools/bpf: add a selftest for
> bpf_get_current_cgroup_id() helper") added a test
> for bpf_get_current_cgroup_id() helper. The bpf program
> is attached to tracepoint syscalls/sys_enter_nanosleep
> and will record the cgroup id
On Thu, Jun 7, 2018 at 3:04 PM, Al Viro wrote:
> On Thu, Jun 07, 2018 at 02:45:58PM -0700, Cong Wang wrote:
>> On Thu, Jun 7, 2018 at 2:26 PM, Al Viro wrote:
>> > On Thu, Jun 07, 2018 at 01:39:49PM -0700, Cong Wang wrote:
>> >> fchownat() doesn't even hold refcnt of fd until it figures out
>> >>
Hello Fellow
Charles Koch here, ceo charles koch foundation worldwide (the largest charity
foundation in the world).
This year under our motto of "Give while living", i and the foundation have
decided to award $500,000.00
to a few selected lucky individuals and on receipt of this email kindly
On 06/07/2018 02:52 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 2:41 PM, Ben Greear wrote:
On 06/07/2018 02:29 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 9:06 AM, wrote:
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
@@ -80,6 +80,9 @@ static struct sk_buff
syzkaller was able to trigger the following panic for AF_XDP:
BUG: KASAN: null-ptr-deref in atomic64_sub
include/asm-generic/atomic-instrumented.h:144 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_sub
include/asm-generic/atomic-long.h:199 [inline]
BUG: KASAN: null-ptr-deref in
On Thu, Jun 07, 2018 at 02:45:58PM -0700, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 2:26 PM, Al Viro wrote:
> > On Thu, Jun 07, 2018 at 01:39:49PM -0700, Cong Wang wrote:
> >> fchownat() doesn't even hold refcnt of fd until it figures out
> >> fd is really needed (otherwise is ignored) and
From: Colin Ian King
From: Colin Ian King
This was originally mistakenly submitted to net-next. Resubmitting to net.
The comparison of numvecs < 0 is always false because numvecs is a u32
and hence the error return from a failed call to pci_alloc_irq_vectores
is never detected. Fix this by
On Thu, Jun 7, 2018 at 2:41 PM, Ben Greear wrote:
> On 06/07/2018 02:29 PM, Cong Wang wrote:
>>
>> On Thu, Jun 7, 2018 at 9:06 AM, wrote:
>>>
>>> --- a/include/net/fq_impl.h
>>> +++ b/include/net/fq_impl.h
>>> @@ -80,6 +80,9 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>>>
>>>
On Thu, Jun 7, 2018 at 2:26 PM, Al Viro wrote:
> On Thu, Jun 07, 2018 at 01:39:49PM -0700, Cong Wang wrote:
>> fchownat() doesn't even hold refcnt of fd until it figures out
>> fd is really needed (otherwise is ignored) and releases it after
>> it resolves the path. This means sock_close() could
On 06/07/2018 02:29 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 9:06 AM, wrote:
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
@@ -80,6 +80,9 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
flow = list_first_entry(head, struct fq_flow, flowchain);
+ if
On Thu, Jun 7, 2018 at 9:06 AM, wrote:
> --- a/include/net/fq_impl.h
> +++ b/include/net/fq_impl.h
> @@ -80,6 +80,9 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>
> flow = list_first_entry(head, struct fq_flow, flowchain);
>
> + if (WARN_ON_ONCE(!flow))
> +
On Thu, Jun 07, 2018 at 01:39:49PM -0700, Cong Wang wrote:
> fchownat() doesn't even hold refcnt of fd until it figures out
> fd is really needed (otherwise is ignored) and releases it after
> it resolves the path. This means sock_close() could race with
> sockfs_setattr(), which leads to a NULL
From: Alexei Starovoitov
Date: Thu, 7 Jun 2018 10:29:29 -0700
> From: Alexei Starovoitov
>
> CONFIG_OUTPUT_FORMAT is x86 only macro.
> Used objdump to extract elf file format.
>
> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
> Reported-by: David S. Miller
>
From: Xiangning Yu
Date: Thu, 7 Jun 2018 13:39:59 +0800
> From: Xiangning Yu
>
> There is a timing issue under active-standy mode, when bond_enslave() is
> called, bond->params.primary might not be initialized yet.
>
> Any time the primary slave string changes, bond->force_primary should be
>
fchownat() doesn't even hold refcnt of fd until it figures out
fd is really needed (otherwise is ignored) and releases it after
it resolves the path. This means sock_close() could race with
sockfs_setattr(), which leads to a NULL pointer dereference
since typically we set sock->sk to NULL in
From: Sultan Alsawaf
Date: Wed, 6 Jun 2018 15:56:54 -0700
> By passing a limit of 2 bytes to strncat, strncat is limited to writing
> fewer bytes than what it's supposed to append to the name here.
>
> Since the bounds are checked on the line above this, just remove the string
> bounds checks
Em Thu, Jun 07, 2018 at 01:07:01PM -0700, Martin KaFai Lau escreveu:
> On Thu, Jun 07, 2018 at 04:30:29PM -0300, Arnaldo Carvalho de Melo wrote:
> > So this must be available in a newer llvm version? Which one?
> I should have put in the details in my last email or
> in the commit message, my
From: Willem de Bruijn
Date: Wed, 6 Jun 2018 11:23:01 -0400
> From: Willem de Bruijn
>
> Tun, tap, virtio, packet and uml vector all use struct virtio_net_hdr
> to communicate packet metadata to userspace.
>
> For skbuffs with vlan, the first two return the packet as it may have
> existed on
On Thu, Jun 07, 2018 at 04:30:29PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 07, 2018 at 12:05:10PM -0700, Martin KaFai Lau escreveu:
> > On Thu, Jun 07, 2018 at 11:03:37AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jun 07, 2018 at 10:54:01AM -0300, Arnaldo Carvalho de Melo
>
On Thu, Jun 07, 2018 at 05:40:03PM +0200, Daniel Borkmann wrote:
> As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
> context pointer") already describes, f1174f77b50c ("bpf/verifier:
> rework value tracking") removed the specific white-listed cases
> we had previously where we
Em Thu, Jun 07, 2018 at 12:05:10PM -0700, Martin KaFai Lau escreveu:
> On Thu, Jun 07, 2018 at 11:03:37AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jun 07, 2018 at 10:54:01AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau
On Thu, Jun 07, 2018 at 11:03:37AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 07, 2018 at 10:54:01AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau escreveu:
> > > [ btw, the latest commit (1 commit) should be 94a11b59e592 ].
>
>
On 07/06/18 16:40, Daniel Borkmann wrote:
> As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
> context pointer") already describes, f1174f77b50c ("bpf/verifier:
> rework value tracking") removed the specific white-listed cases
> we had previously where we would allow for pointer
On Thu, Jun 7, 2018 at 8:40 AM, Daniel Borkmann wrote:
> As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
> context pointer") already describes, f1174f77b50c ("bpf/verifier:
> rework value tracking") removed the specific white-listed cases
> we had previously where we would allow
From: Alexei Starovoitov
CONFIG_OUTPUT_FORMAT is x86 only macro.
Used objdump to extract elf file format.
Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
Reported-by: David S. Miller
Signed-off-by: Alexei Starovoitov
---
net/bpfilter/Makefile | 2 +-
1 file changed, 1
Hello,
syzbot found the following crash on:
HEAD commit:c6a6aed994b6 kmsan: remove dead code to trigger syzbot build
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=17bde74f80
kernel config:
On Thu, Jun 07, 2018 at 09:17:42AM -0700, Stephen Hemminger wrote:
> On Thu, 7 Jun 2018 18:41:31 +0300
> "Michael S. Tsirkin" wrote:
>
> > > > Why would DPDK care what we do in the kernel? Isn't it just slapping
> > > > vfio-pci on the netdevs it sees?
> > >
> > > Alex, you are correct for
Hi Nicolas,
On 06/04/2018 10:13 AM, Nicolas Ferre wrote:
On 25/05/2018 at 23:44, Jennifer Dahm wrote:
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 3e93df5..a5d564b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++
On 06/07/2018 09:17 AM, Eric Dumazet wrote:
On 06/07/2018 09:06 AM, gree...@candelatech.com wrote:
From: Ben Greear
While testing an ath10k firmware that often crashed under load,
I was seeing kernel crashes as well. One of them appeared to
be a dereference of a NULL flow object in
On Thu, Jun 7, 2018 at 12:22 PM, Alexander Aring wrote:
> Hi,
>
> On Wed, Jun 06, 2018 at 04:26:19PM -0400, Willem de Bruijn wrote:
>> On Wed, Jun 6, 2018 at 2:11 PM, David Miller wrote:
>> > From: Alexander Aring
>> > Date: Wed, 6 Jun 2018 14:09:20 -0400
>> >
>> >> okay, then you want to have
On Thu, 2018-06-07 at 07:39 -0700, Stephen Hemminger wrote:
>
> Begin forwarded message:
>
> Date: Thu, 07 Jun 2018 13:21:23 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 199963] New: UDP rx_queue incorrect calculation in /proc/net/udp
>
>
>
Hi,
On Wed, Jun 06, 2018 at 04:26:19PM -0400, Willem de Bruijn wrote:
> On Wed, Jun 6, 2018 at 2:11 PM, David Miller wrote:
> > From: Alexander Aring
> > Date: Wed, 6 Jun 2018 14:09:20 -0400
> >
> >> okay, then you want to have this patch for net-next? As an optimization?
> >>
> >> Of course,
On Thu, 7 Jun 2018 18:41:31 +0300
"Michael S. Tsirkin" wrote:
> > > Why would DPDK care what we do in the kernel? Isn't it just slapping
> > > vfio-pci on the netdevs it sees?
> >
> > Alex, you are correct for Intel devices; but DPDK on Azure is not Intel
> > based.,.
> > The DPDK support
On 06/07/2018 09:06 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> While testing an ath10k firmware that often crashed under load,
> I was seeing kernel crashes as well. One of them appeared to
> be a dereference of a NULL flow object in fq_tin_dequeue.
>
> I have since fixed the
From: Ben Greear
While testing an ath10k firmware that often crashed under load,
I was seeing kernel crashes as well. One of them appeared to
be a dereference of a NULL flow object in fq_tin_dequeue.
I have since fixed the firmware flaw, but I think it would be
worth adding the WARN_ON in case
Begin forwarded message:
Date: Thu, 07 Jun 2018 13:21:23 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 199963] New: UDP rx_queue incorrect calculation in /proc/net/udp
https://bugzilla.kernel.org/show_bug.cgi?id=199963
Bug ID:
On Thu, Jun 07, 2018 at 07:51:12AM -0700, Stephen Hemminger wrote:
> On Thu, 7 Jun 2018 07:17:51 -0700
> Alexander Duyck wrote:
>
> > On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
> > wrote:
> > > On Wed, 6 Jun 2018 14:54:04 -0700
> > > "Samudrala, Sridhar" wrote:
> > >
> > >> On
As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
context pointer") already describes, f1174f77b50c ("bpf/verifier:
rework value tracking") removed the specific white-listed cases
we had previously where we would allow for pointer arithmetic in
order to further generalize it, and
On Thu, 7 Jun 2018 17:57:50 +0300
"Michael S. Tsirkin" wrote:
> On Wed, Jun 06, 2018 at 03:24:08PM -0700, Stephen Hemminger wrote:
> > On Thu, 7 Jun 2018 00:47:52 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Jun 06, 2018 at 02:24:47PM -0700, Stephen Hemminger wrote:
> > > > On
On Wed, Jun 06, 2018 at 03:24:08PM -0700, Stephen Hemminger wrote:
> On Thu, 7 Jun 2018 00:47:52 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Jun 06, 2018 at 02:24:47PM -0700, Stephen Hemminger wrote:
> > > On Wed, 6 Jun 2018 15:30:27 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > >
On Thu, 7 Jun 2018 07:17:51 -0700
Alexander Duyck wrote:
> On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
> wrote:
> > On Wed, 6 Jun 2018 14:54:04 -0700
> > "Samudrala, Sridhar" wrote:
> >
> >> On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
> >> > On Wed, 6 Jun 2018 15:30:27 +0300
> >> >
On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
wrote:
> On Wed, 6 Jun 2018 14:54:04 -0700
> "Samudrala, Sridhar" wrote:
>
>> On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
>> > On Wed, 6 Jun 2018 15:30:27 +0300
>> > "Michael S. Tsirkin" wrote:
>> >
>> >> On Wed, Jun 06, 2018 at 09:25:12AM
Em Thu, Jun 07, 2018 at 10:54:01AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau escreveu:
> > [ btw, the latest commit (1 commit) should be 94a11b59e592 ].
So, the commit log message for the pahole patch is non-existent:
Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau escreveu:
> On Thu, Apr 19, 2018 at 04:40:34PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Apr 18, 2018 at 03:55:56PM -0700, Martin KaFai Lau escreveu:
> > > This patch introduces BPF Type Format (BTF).
> > >
> > > BTF (BPF Type
use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
netlink attribute, in case it is less than SIMP_MAX_DATA and it does not
end with '\0' character.
Fixes: 0eff683f737b ("net/sched: potential data corruption")
Signed-off-by: Davide Caratti
---
net/sched/act_simple.c | 15
On Thu, Jun 07, 2018 at 02:35:39PM +0200, Phil Sutter wrote:
> Yes, I agree with Michal. IIRC, flushing a specific primary along with
> all it's secondaries from an interface is not even supported by
> iproute2, so no need to optimize for that I guess. OTOH, if your
> solution allowed to get rid
Hi Jakub,
On Thu, Jun 07, 2018 at 02:17:50PM +0200, Jakub Sitnicki wrote:
> On Thu, 7 Jun 2018 13:00:29 +0200
> Michal Kubecek wrote:
>
> > On Thu, Jun 07, 2018 at 12:13:01PM +0200, Jakub Sitnicki wrote:
> > > Promoting secondary addresses on address removal makes flushing all
> > > addresses
On Thu, 7 Jun 2018 13:00:29 +0200
Michal Kubecek wrote:
> On Thu, Jun 07, 2018 at 12:13:01PM +0200, Jakub Sitnicki wrote:
> > Promoting secondary addresses on address removal makes flushing all
> > addresses from a device with 1000's of them slow. This is because we
> > cannot take down the
On Thu, Jun 07, 2018 at 12:13:01PM +0200, Jakub Sitnicki wrote:
> Promoting secondary addresses on address removal makes flushing all
> addresses from a device with 1000's of them slow. This is because we
> cannot take down the secondary addresses when we are removing the
> primary one, which
Promoting secondary addresses on address removal makes flushing all
addresses from a device with 1000's of them slow. This is because we
cannot take down the secondary addresses when we are removing the
primary one, which would make it faster.
However, the userspace, when performing a flush, will
Den mån 4 juni 2018 kl 22:35 skrev Alexander Duyck :
>
> On Mon, Jun 4, 2018 at 5:05 AM, Björn Töpel wrote:
> > From: Björn Töpel
> >
> > This commit adds initial AF_XDP zero-copy support for i40e-based
> > NICs. First we add support for the new XDP_QUERY_XSK_UMEM and
> > XDP_SETUP_XSK_UMEM
When setting the skb->dst before doing the MTU check, the route PMTU
caching and reporting is done on the new dst which is about to be
released.
Instead, PMTU handling should be done using the original dst.
This is aligned with IPv4 VTI.
Signed-off-by: Eyal Birger
Fixes: ccd740cbc6 ("vti6: Add
75 matches
Mail list logo
