* Re: [PATCH net-next 0/3] Implement delete for BPF LPM trie
From: Daniel Mack @ 2017-09-19 21:31 UTC (permalink / raw)
To: David Miller, kraigatgoog; +Cc: ast, daniel, netdev
In-Reply-To: <20170919.142935.72220924483937276.davem@davemloft.net>
On 09/19/2017 11:29 PM, David Miller wrote:
> From: Craig Gallek <kraigatgoog@gmail.com>
> Date: Tue, 19 Sep 2017 17:16:13 -0400
>
>> On Tue, Sep 19, 2017 at 5:13 PM, Daniel Mack <daniel@zonque.org> wrote:
>>> On 09/19/2017 10:55 PM, David Miller wrote:
>>>> From: Craig Gallek <kraigatgoog@gmail.com>
>>>> Date: Mon, 18 Sep 2017 15:30:54 -0400
>>>>
>>>>> This was previously left as a TODO. Add the implementation and
>>>>> extend the test to cover it.
>>>>
>>>> Series applied, thanks.
>>>>
>>>
>>> Hmm, I think these patches need some more discussion regarding the IM
>>> nodes handling, see the reply I sent an hour ago. Could you wait for
>>> that before pushing your tree?
>>
>> I can follow up with a patch to implement your suggestion. It's
>> really just an efficiency improvement, though, so I think it's ok to
>> handle independently. (Sorry, I haven't had a chance to play with the
>> implementation details yet).
>
> Sorry, I thought the core implementation had been agreed upon and the
> series was OK. All that was asked for were simplifications and/or
> optimization which could be done via follow-up patches.
>
> It's already pushed out to my tree, so I would need to do a real
> revert.
>
> I hope that won't be necessary.
>
Nah, it's okay I guess. I trust Craig to send follow-up patches. After
all, efficiency is what this whole exercise is all about, so I think it
should be done correctly :)
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/3][v2] selftests: actually run the various net selftests
From: Shuah Khan @ 2017-09-19 21:31 UTC (permalink / raw)
To: josef, davem, netdev, linux-kselftest; +Cc: Josef Bacik, Shuah Khan
In-Reply-To: <1505829088-1823-2-git-send-email-jbacik@fb.com>
On 09/19/2017 07:51 AM, josef@toxicpanda.com wrote:
> From: Josef Bacik <jbacik@fb.com>
>
> These self tests are just self contained binaries, they are not run by
> any of the scripts in the directory. This means they need to be marked
> with TEST_GEN_PROGS to actually be run, not TEST_GEN_FILES.
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> ---
> v1->v2:
> - Moved msg_zerocopy to TEST_GEN_FILES since it's not runnable in it's current
> state
>
I usually don't sent new tests however, since it is a test for a
regression, applied to linux-kselftest fixes for 4.14-rc2
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 1/3][v2] selftest: add a reuseaddr test
From: Shuah Khan @ 2017-09-19 21:30 UTC (permalink / raw)
To: josef, davem, netdev, linux-kselftest; +Cc: Josef Bacik, Shuah Khan, Shuah Khan
In-Reply-To: <1505829088-1823-1-git-send-email-jbacik@fb.com>
On 09/19/2017 07:51 AM, josef@toxicpanda.com wrote:
> From: Josef Bacik <jbacik@fb.com>
>
> This is to test for a regression introduced by
>
> b9470c27607b ("inet: kill smallest_size and smallest_port")
>
> which introduced a problem with reuseaddr and bind conflicts.
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
I usually don't sent new tests however, since it is a test for a
regression, applied to linux-kselftest fixes for 4.14-rc2
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH net-next 0/3] Implement delete for BPF LPM trie
From: David Miller @ 2017-09-19 21:29 UTC (permalink / raw)
To: kraigatgoog; +Cc: daniel, ast, daniel, netdev
In-Reply-To: <CAEfhGiybHecYsJ+3eXMFfohh_Jp_yyDfr8ZkydGaQyZJbVQXwA@mail.gmail.com>
From: Craig Gallek <kraigatgoog@gmail.com>
Date: Tue, 19 Sep 2017 17:16:13 -0400
> On Tue, Sep 19, 2017 at 5:13 PM, Daniel Mack <daniel@zonque.org> wrote:
>> On 09/19/2017 10:55 PM, David Miller wrote:
>>> From: Craig Gallek <kraigatgoog@gmail.com>
>>> Date: Mon, 18 Sep 2017 15:30:54 -0400
>>>
>>>> This was previously left as a TODO. Add the implementation and
>>>> extend the test to cover it.
>>>
>>> Series applied, thanks.
>>>
>>
>> Hmm, I think these patches need some more discussion regarding the IM
>> nodes handling, see the reply I sent an hour ago. Could you wait for
>> that before pushing your tree?
>
> I can follow up with a patch to implement your suggestion. It's
> really just an efficiency improvement, though, so I think it's ok to
> handle independently. (Sorry, I haven't had a chance to play with the
> implementation details yet).
Sorry, I thought the core implementation had been agreed upon and the
series was OK. All that was asked for were simplifications and/or
optimization which could be done via follow-up patches.
It's already pushed out to my tree, so I would need to do a real
revert.
I hope that won't be necessary.
^ permalink raw reply
* Re: [PATCH net-next] net_sched: no need to free qdisc in RCU callback
From: Eric Dumazet @ 2017-09-19 21:26 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Jamal Hadi Salim, Eric Dumazet
In-Reply-To: <20170919201542.14890-1-xiyou.wangcong@gmail.com>
On Tue, 2017-09-19 at 13:15 -0700, Cong Wang wrote:
> gen estimator has been rewritten in commit 1c0d32fde5bd
> ("net_sched: gen_estimator: complete rewrite of rate estimators"),
> the caller no longer needs to wait for a grace period. So this
> patch gets rid of it.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [patch net-next 00/13] mlxsw: Prepare for multicast router offload
From: David Miller @ 2017-09-19 21:24 UTC (permalink / raw)
To: jiri; +Cc: netdev, yotamg, idosch, mlxsw
In-Reply-To: <20170919080020.5870-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 19 Sep 2017 10:00:07 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Yotam says:
>
> This patch-set makes various preparations needed for the multicast router
> offloading, which include:
> - Add the needed registers.
> - Add needed ACL actions.
> - Add new traps and trap groups.
> - Exporting needed private structs and enums.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/3] Implement delete for BPF LPM trie
From: Craig Gallek @ 2017-09-19 21:16 UTC (permalink / raw)
To: Daniel Mack; +Cc: David Miller, Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <94373907-6cf5-22af-54e6-7625f31447e0@zonque.org>
On Tue, Sep 19, 2017 at 5:13 PM, Daniel Mack <daniel@zonque.org> wrote:
> On 09/19/2017 10:55 PM, David Miller wrote:
>> From: Craig Gallek <kraigatgoog@gmail.com>
>> Date: Mon, 18 Sep 2017 15:30:54 -0400
>>
>>> This was previously left as a TODO. Add the implementation and
>>> extend the test to cover it.
>>
>> Series applied, thanks.
>>
>
> Hmm, I think these patches need some more discussion regarding the IM
> nodes handling, see the reply I sent an hour ago. Could you wait for
> that before pushing your tree?
I can follow up with a patch to implement your suggestion. It's
really just an efficiency improvement, though, so I think it's ok to
handle independently. (Sorry, I haven't had a chance to play with the
implementation details yet).
Craig
^ permalink raw reply
* Re: [PATCH net-next 0/3] Implement delete for BPF LPM trie
From: Daniel Mack @ 2017-09-19 21:13 UTC (permalink / raw)
To: David Miller, kraigatgoog; +Cc: ast, daniel, netdev
In-Reply-To: <20170919.135530.717500199880384307.davem@davemloft.net>
On 09/19/2017 10:55 PM, David Miller wrote:
> From: Craig Gallek <kraigatgoog@gmail.com>
> Date: Mon, 18 Sep 2017 15:30:54 -0400
>
>> This was previously left as a TODO. Add the implementation and
>> extend the test to cover it.
>
> Series applied, thanks.
>
Hmm, I think these patches need some more discussion regarding the IM
nodes handling, see the reply I sent an hour ago. Could you wait for
that before pushing your tree?
Thanks,
Daniel
^ permalink raw reply
* [PATCH] mwifiex: make const array tos_to_ac static, reduces object code size
From: Colin King @ 2017-09-19 21:05 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the read-only const array tos_to_ac on the stack,
instead make it static. Makes the object code smaller by 250 bytes:
Before:
text data bss dec hex filename
26104 2720 128 28952 7118 wmm.o
After:
text data bss dec hex filename
25758 2816 128 28702 701e wmm.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/mwifiex/wmm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 0edd26881321..936a0a841af8 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -359,7 +359,8 @@ static enum mwifiex_wmm_ac_e
mwifiex_wmm_convert_tos_to_ac(struct mwifiex_adapter *adapter, u32 tos)
{
/* Map of TOS UP values to WMM AC */
- const enum mwifiex_wmm_ac_e tos_to_ac[] = { WMM_AC_BE,
+ static const enum mwifiex_wmm_ac_e tos_to_ac[] = {
+ WMM_AC_BE,
WMM_AC_BK,
WMM_AC_BK,
WMM_AC_BE,
--
2.14.1
^ permalink raw reply related
* Re: [PATCH net-next 0/4] test_rhashtable: add test case for rhl table
From: David Miller @ 2017-09-19 21:03 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170918210711.10202-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 18 Sep 2017 23:07:07 +0200
> Add a test case for the rhlist interface.
>
> While at it, cleanup current rhashtable test a bit and add a check
> for max_size support.
The kbuild test robot complained about a very large on-stack allocation
added by these changes, please address that.
Thanks.
^ permalink raw reply
* Re: [PATCH] tcp: avoid bogus warning in tcp_clean_rtx_queue
From: David Miller @ 2017-09-19 21:02 UTC (permalink / raw)
To: arnd
Cc: kuznet, yoshfuji, edumazet, ncardwell, ycheng, soheil, fw, netdev,
linux-kernel
In-Reply-To: <20170918204855.170920-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 18 Sep 2017 22:48:47 +0200
> gcc-4.9 warns that it cannot trace the state of the 'last_ackt'
> variable since the change to the TCP timestamping code, when
> CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
>
> net/ipv4/tcp_input.c: In function 'tcp_clean_rtx_queue':
> include/net/tcp.h:757:23: error: 'last_ackt' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> Other gcc versions, both older and newer do now show this
> warning. Removing the 'likely' annotation makes it go away,
> and has no effect on the object code without
> CONFIG_PROFILE_ANNOTATED_BRANCHES, as tested with gcc-4.9
> and gcc-7.1.1, so this seems to be a safe workaround.
>
> Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This reaches the limits at which I am willing to work around compiler
stuff.
What cpu did you test the object code generation upon and does that
cpu have branch prediction hints in the target you are building for?
^ permalink raw reply
* Re: cross namespace interface notification for tun devices
From: Jason A. Donenfeld @ 2017-09-19 21:02 UTC (permalink / raw)
To: Cong Wang; +Cc: Netdev, Mathias
In-Reply-To: <CAM_iQpVvDNRbtj_47_3XXa_ezyrT=a_VzDtK5SCR9a4_2Gqw9w@mail.gmail.com>
On Tue, Sep 19, 2017 at 10:40 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> By "notification" I assume you mean netlink notification.
Yes, netlink notification.
> The question is why does the process in A still care about
> the device sitting in B?
>
> Also, the process should be able to receive a last notification
> on IFF_UP|IFF_RUNNING before device is finally moved to B.
> After this point, it should not have any relation to netns A
> any more, like the device were completely gone.
That's very clearly not the case with a tun device. Tun devices work
by letting a userspace process control the inputs (ndo_start_xmit) and
outputs (netif_rx) of the actual network device. This controlling
userspace process needs to know when its own interface that it
controls goes up and down. In the kernel, we can do this by just
checking dev->flags&IFF_UP, and receive notifications on ndo_open and
ndo_stop. In userspace, the controlling process looses the ability to
receive notifications like ndo_open/ndo_stop when the interface is
moved to a new namespace. After the interface is moved to a namespace,
the process will still control inputs and ouputs (ndo_start_xmit and
netif_rx), but it will no longer receive netlink notifications for the
equivalent of ndo_open and ndo_stop. This is problematic.
^ permalink raw reply
* Re: [PATCH net-next 0/3] Implement delete for BPF LPM trie
From: David Miller @ 2017-09-19 20:55 UTC (permalink / raw)
To: kraigatgoog; +Cc: daniel, ast, daniel, netdev
In-Reply-To: <20170918193057.37644-1-kraigatgoog@gmail.com>
From: Craig Gallek <kraigatgoog@gmail.com>
Date: Mon, 18 Sep 2017 15:30:54 -0400
> This was previously left as a TODO. Add the implementation and
> extend the test to cover it.
Series applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()
From: Doug Anderson @ 2017-09-19 20:53 UTC (permalink / raw)
To: Oliver Neukum
Cc: Guenter Roeck, Grant Grundler, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, netdev
In-Reply-To: <1505853476.15836.9.camel@suse.com>
Hi,
On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum <oneukum@suse.com> wrote:
> Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
>> In general when you've got a flag communicating that "something needs
>> to be done" you want to clear that flag _before_ doing the task. If
>> you clear the flag _after_ doing the task you end up with the risk
>> that this will happen:
>>
>> 1. Requester sets flag saying task A needs to be done.
>> 2. Worker comes and stars doing task A.
>> 3. Worker finishes task A but hasn't yet cleared the flag.
>> 4. Requester wants to set flag saying task A needs to be done again.
>> 5. Worker clears the flag without doing anything.
>>
>> Let's make the usbnet codebase consistently clear the flag _before_ it
>> does the requested work. That way if there's another request to do
>> the work while the work is already in progress it won't be lost.
>>
>> NOTES:
>> - No known bugs are fixed by this; it's just found by code inspection.
>
> Hi,
>
> unfortunately the patch is wrong. The flags must be cleared only
> in case the handler is successful. That is not guaranteed.
>
> Regards
> Oliver
>
> NACK
OK, thanks for reviewing! I definitely wasn't super confident about
the patch (hence the RFC).
Do you think that the races I identified are possible to hit? In
other words: should I try to rework the patch somehow or just drop it?
Originally I had the patch setting the flags back to true in the
failure cases, but then I convinced myself that wasn't needed. I can
certainly go back and try it that way...
-Doug
^ permalink raw reply
* Re: [PATCH net-next 2/7] kobject: copy env blob in one go
From: Cong Wang @ 2017-09-19 20:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S . Miller, netdev, Eric W . Biederman, Eric Dumazet
In-Reply-To: <20170918190733.26272-3-edumazet@google.com>
On Mon, Sep 18, 2017 at 12:07 PM, Eric Dumazet <edumazet@google.com> wrote:
> + scratch = skb_put(skb, env->buflen);
> + memcpy(scratch, env->buf, env->buflen);
skb_put_data()
^ permalink raw reply
* Re: [PATCH] vsock: vmci: Remove unneeded linux/miscdevice.h include
From: David Miller @ 2017-09-19 20:52 UTC (permalink / raw)
To: clabbe.montjoie; +Cc: netdev, linux-kernel
In-Reply-To: <20170918181855.32211-1-clabbe.montjoie@gmail.com>
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: Mon, 18 Sep 2017 20:18:55 +0200
> net/vmw_vsock/vmci_transport.c does not use any miscdevice so this patch
> remove this unnecessary inclusion.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()
From: Guenter Roeck @ 2017-09-19 20:51 UTC (permalink / raw)
To: Oliver Neukum
Cc: Douglas Anderson, Guenter Roeck, Grant Grundler, linux-kernel,
linux-usb, netdev
In-Reply-To: <1505853476.15836.9.camel@suse.com>
On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum <oneukum@suse.com> wrote:
> Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
>> In general when you've got a flag communicating that "something needs
>> to be done" you want to clear that flag _before_ doing the task. If
>> you clear the flag _after_ doing the task you end up with the risk
>> that this will happen:
>>
>> 1. Requester sets flag saying task A needs to be done.
>> 2. Worker comes and stars doing task A.
>> 3. Worker finishes task A but hasn't yet cleared the flag.
>> 4. Requester wants to set flag saying task A needs to be done again.
>> 5. Worker clears the flag without doing anything.
>>
>> Let's make the usbnet codebase consistently clear the flag _before_ it
>> does the requested work. That way if there's another request to do
>> the work while the work is already in progress it won't be lost.
>>
>> NOTES:
>> - No known bugs are fixed by this; it's just found by code inspection.
>
> Hi,
>
> unfortunately the patch is wrong. The flags must be cleared only
> in case the handler is successful. That is not guaranteed.
>
Just out of curiosity, what is the retry mechanism ? Whenever a new,
possibly unrelated, event is scheduled ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH net] bpf: do not disable/enable BH in bpf_map_free_id()
From: Daniel Borkmann @ 2017-09-19 20:51 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: Martin KaFai Lau, Alexei Starovoitov, netdev
In-Reply-To: <1505837759.29839.64.camel@edumazet-glaptop3.roam.corp.google.com>
On 09/19/2017 06:15 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller reported following splat [1]
>
> Since hard irq are disabled by the caller, bpf_map_free_id()
> should not try to enable/disable BH.
>
> Another solution would be to change htab_map_delete_elem() to
> defer the free_htab_elem() call after
> raw_spin_unlock_irqrestore(&b->lock, flags), but this might be not
> enough to cover other code paths.
>
> [1]
> WARNING: CPU: 1 PID: 8052 at kernel/softirq.c:161 __local_bh_enable_ip
> +0x1e/0x160 kernel/softirq.c:161
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 8052 Comm: syz-executor1 Not tainted 4.13.0-next-20170915+
> #23
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:52
> panic+0x1e4/0x417 kernel/panic.c:181
> __warn+0x1c4/0x1d9 kernel/panic.c:542
> report_bug+0x211/0x2d0 lib/bug.c:183
> fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> RIP: 0010:__local_bh_enable_ip+0x1e/0x160 kernel/softirq.c:161
> RSP: 0018:ffff8801cdcd7748 EFLAGS: 00010046
> RAX: 0000000000000082 RBX: 0000000000000201 RCX: 0000000000000000
> RDX: 1ffffffff0b5933c RSI: 0000000000000201 RDI: ffffffff85ac99e0
> RBP: ffff8801cdcd7758 R08: ffffffff85b87158 R09: 1ffff10039b9aec6
> R10: ffff8801c99f24c0 R11: 0000000000000002 R12: ffffffff817b0b47
> R13: dffffc0000000000 R14: ffff8801cdcd77e8 R15: 0000000000000001
> __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:176 [inline]
> _raw_spin_unlock_bh+0x30/0x40 kernel/locking/spinlock.c:207
> spin_unlock_bh include/linux/spinlock.h:361 [inline]
> bpf_map_free_id kernel/bpf/syscall.c:197 [inline]
> __bpf_map_put+0x267/0x320 kernel/bpf/syscall.c:227
> bpf_map_put+0x1a/0x20 kernel/bpf/syscall.c:235
> bpf_map_fd_put_ptr+0x15/0x20 kernel/bpf/map_in_map.c:96
> free_htab_elem+0xc3/0x1b0 kernel/bpf/hashtab.c:658
> htab_map_delete_elem+0x74d/0x970 kernel/bpf/hashtab.c:1063
> map_delete_elem kernel/bpf/syscall.c:633 [inline]
> SYSC_bpf kernel/bpf/syscall.c:1479 [inline]
> SyS_bpf+0x2188/0x46a0 kernel/bpf/syscall.c:1451
> entry_SYSCALL_64_fastpath+0x1f/0xbe
>
> Fixes: f3f1c054c288 ("bpf: Introduce bpf_map ID")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
Thanks for the fix, Eric!
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH 0/3] fix reuseaddr regression
From: David Miller @ 2017-09-19 20:50 UTC (permalink / raw)
To: josef; +Cc: netdev, linux-kernel, crobinso, labbott, kernel-team
In-Reply-To: <1505752137-15522-1-git-send-email-jbacik@fb.com>
From: josef@toxicpanda.com
Date: Mon, 18 Sep 2017 12:28:54 -0400
> I introduced a regression when reworking the fastreuse port stuff that allows
> bind conflicts to occur once a reuseaddr socket successfully opens on an
> existing tb. The root cause is I reversed an if statement which caused us to
> set the tb as if there were no owners on the socket if there were, which
> obviously is not correct.
>
> Dave I have follow up patches that will add a selftest for this case and I ran
> the other reuseport related tests as well. These need to go in pretty quickly
> as it breaks kvm, I've marked them for stable. Sorry for the regression,
First, please fix your "From: " field so that it actually has your full
name rather than just your email address. This matter when I apply
your patches.
Second, remove the stable CC:. For networking changes, you simply ask
me to queue the changes up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: mvpp2: remove useless goto
From: David Miller @ 2017-09-19 20:49 UTC (permalink / raw)
To: antoine.tenart
Cc: andrew, gregory.clement, thomas.petazzoni, miquel.raynal, nadavh,
linux, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170918133651.29556-1-antoine.tenart@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Mon, 18 Sep 2017 15:36:51 +0200
> Remove a goto in the PPv2 tx function which jumps to the next line
> anyway. This is a cosmetic commit.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: phy: Kconfig: Fix PHY infrastructure menu in menuconfig
From: David Miller @ 2017-09-19 20:47 UTC (permalink / raw)
To: jbrunet; +Cc: andrew, f.fainelli, netdev, linux-kernel, rmk+kernel
In-Reply-To: <20170918125920.10298-1-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Mon, 18 Sep 2017 14:59:20 +0200
> Since the integration of PHYLINK, the configuration option which
> used to be under the PHY infrastructure menu in menuconfig ended
> up one level up (the network device driver section)
>
> By placing PHYLINK option right after PHYLIB entry, it broke the
> way Kconfig used to build the menu. See kconfig-language.txt, section
> "Menu structure", 2nd method.
>
> This is fixed by placing the PHYLINK option just before PHYLIB.
>
> Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Applied, thank you.
^ permalink raw reply
* Re: cross namespace interface notification for tun devices
From: Cong Wang @ 2017-09-19 20:40 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Netdev, Mathias
In-Reply-To: <CAHmME9pD_kees+xrjTeWXgi26UdhbMVgvoddbCyueTZkbguvAg@mail.gmail.com>
On Mon, Sep 18, 2017 at 11:47 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hey guys,
>
> It's possible to create a tun device in a process in namespace A and
> then move that interface to namespace B. The controlling process in A
> needs to receive notifications on when the interface is brought up or
> down. It can receive these notifications via netlink while the
> interface lives in A but not when it moves to B.
By "notification" I assume you mean netlink notification.
>
> Any tricks or APIs to get around this?
The question is why does the process in A still care about
the device sitting in B?
Also, the process should be able to receive a last notification
on IFF_UP|IFF_RUNNING before device is finally moved to B.
After this point, it should not have any relation to netns A
any more, like the device were completely gone.
^ permalink raw reply
* Re: [PATCH net-next v4 3/4] bpf: add helper bpf_perf_prog_read_value
From: Daniel Borkmann @ 2017-09-19 20:40 UTC (permalink / raw)
To: Yonghong Song, peterz, rostedt, ast, netdev; +Cc: kernel-team
In-Reply-To: <20170919070413.3838201-4-yhs@fb.com>
On 09/19/2017 09:04 AM, Yonghong Song wrote:
[...]
> #ifdef CONFIG_CGROUP_PERF
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 2c68b9e..ba77022 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -590,6 +590,13 @@ union bpf_attr {
> * @buf: buf to fill
> * @buf_size: size of the buf
> * Return: 0 on success or negative error code
> + *
> + * int bpf_perf_prog_read_value(ctx, buf, buf_size)
> + * read perf prog attached perf event counter and enabled/running time
> + * @ctx: pointer to ctx
> + * @buf: buf to fill
> + * @buf_size: size of the buf
> + * Return : 0 on success or negative error code
> */
> #define __BPF_FUNC_MAPPER(FN) \
> FN(unspec), \
> @@ -647,6 +654,7 @@ union bpf_attr {
> FN(sk_redirect_map), \
> FN(sock_map_update), \
> FN(perf_event_read_value), \
> + FN(perf_prog_read_value), \
(Same here.)
>
> /* integer value in 'imm' field of BPF_CALL instruction selects which helper
> * function eBPF program intends to call
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 2d5bbe5..d039086 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -8081,6 +8081,7 @@ static void bpf_overflow_handler(struct perf_event *event,
> struct bpf_perf_event_data_kern ctx = {
> .data = data,
> .regs = regs,
> + .event = event,
> };
> int ret = 0;
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 39ce5d9..596b5c9 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -603,6 +603,18 @@ BPF_CALL_3(bpf_get_stackid_tp, void *, tp_buff, struct bpf_map *, map,
> flags, 0, 0);
> }
>
> +BPF_CALL_3(bpf_perf_prog_read_value_tp, void *, ctx, struct bpf_perf_event_value *,
> + buf, u32, size)
Nit: indent
> +{
> + struct bpf_perf_event_data_kern *kctx = (struct bpf_perf_event_data_kern *)ctx;
Why having the arg as void * and have this detour instead of having
struct bpf_perf_event_data_kern * right in the helper signature as
argument?
> + if (size != sizeof(struct bpf_perf_event_value))
unlikely()
> + return -EINVAL;
> +
> + return perf_event_read_local(kctx->event, &buf->counter, &buf->enabled,
> + &buf->running);
> +}
bpf_perf_prog_read_value_proto_tp would go right underneath here,
and bpf_get_stackid_proto_tp below the previous helper above.
> static const struct bpf_func_proto bpf_get_stackid_proto_tp = {
> .func = bpf_get_stackid_tp,
> .gpl_only = true,
> @@ -612,6 +624,15 @@ static const struct bpf_func_proto bpf_get_stackid_proto_tp = {
> .arg3_type = ARG_ANYTHING,
> };
>
> +static const struct bpf_func_proto bpf_perf_prog_read_value_proto_tp = {
> + .func = bpf_perf_prog_read_value_tp,
> + .gpl_only = true,
> + .ret_type = RET_INTEGER,
> + .arg1_type = ARG_PTR_TO_CTX,
> + .arg2_type = ARG_PTR_TO_UNINIT_MEM,
Same on error path.
> + .arg3_type = ARG_CONST_SIZE,
> +};
> +
> static const struct bpf_func_proto *tp_prog_func_proto(enum bpf_func_id func_id)
> {
> switch (func_id) {
> @@ -619,6 +640,8 @@ static const struct bpf_func_proto *tp_prog_func_proto(enum bpf_func_id func_id)
> return &bpf_perf_event_output_proto_tp;
> case BPF_FUNC_get_stackid:
> return &bpf_get_stackid_proto_tp;
> + case BPF_FUNC_perf_prog_read_value:
> + return &bpf_perf_prog_read_value_proto_tp;
> default:
> return tracing_func_proto(func_id);
> }
>
^ permalink raw reply
* [PATCH] ath9k: make const array reg_hole_list static, reduces object code size
From: Colin King @ 2017-09-19 20:40 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the read-only array reg_hole_list on the stack, instead make
it static. Makes the object code smaller by over 200 bytes:
Before:
text data bss dec hex filename
57518 15248 0 72766 11c3e debug.o
After:
text data bss dec hex filename
57218 15344 0 72562 11b72 debug.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 01fa30117288..5a0a05abd51a 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -916,7 +916,7 @@ static int open_file_regdump(struct inode *inode, struct file *file)
u8 *buf;
int i, j = 0;
unsigned long num_regs, regdump_len, max_reg_offset;
- const struct reg_hole {
+ static const struct reg_hole {
u32 start;
u32 end;
} reg_hole_list[] = {
--
2.14.1
^ permalink raw reply related
* Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()
From: Oliver Neukum @ 2017-09-19 20:37 UTC (permalink / raw)
To: Douglas Anderson; +Cc: groeck, grundler, linux-kernel, linux-usb, netdev
In-Reply-To: <20170919161522.995-2-dianders@chromium.org>
Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
> In general when you've got a flag communicating that "something needs
> to be done" you want to clear that flag _before_ doing the task. If
> you clear the flag _after_ doing the task you end up with the risk
> that this will happen:
>
> 1. Requester sets flag saying task A needs to be done.
> 2. Worker comes and stars doing task A.
> 3. Worker finishes task A but hasn't yet cleared the flag.
> 4. Requester wants to set flag saying task A needs to be done again.
> 5. Worker clears the flag without doing anything.
>
> Let's make the usbnet codebase consistently clear the flag _before_ it
> does the requested work. That way if there's another request to do
> the work while the work is already in progress it won't be lost.
>
> NOTES:
> - No known bugs are fixed by this; it's just found by code inspection.
Hi,
unfortunately the patch is wrong. The flags must be cleared only
in case the handler is successful. That is not guaranteed.
Regards
Oliver
NACK
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox