* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 2:46 UTC (permalink / raw)
To: Wangnan (F); +Cc: Joe Stringer, LKML, netdev, ast, daniel, acme
In-Reply-To: <582D11B0.80208@huawei.com>
On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
> I'm also working on improving bpf.c. Please have a look at:
>
> https://lkml.org/lkml/2016/11/14/1078
>
> Since bpf.c is simple, I think we can add more functions and fixes
> gradually, instead of a full copy.
>
> See my inline comment below.
Ah, I missed this, my apologies. It looks like it will provide much of
what I need, I can reassess this patch with your series in mind.
One comment though for your patch (I don't have the original thread to
respond to unfortunately): The map_pin and map_get functions in your
patch series can be used to pin progs too, so maybe there is a better
name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
wouldn't want those to be confused with the libbpf.c objects so maybe
there's a clearer name that could be used.
I also have some patches to rework the samples/bpf/* code to use
libbpf instead of the sample code that is there, is it worth me
submitting that? It will need to wait for your patch to go in, plus a
merge with davem's tree.
>
> On 2016/11/17 1:43, Joe Stringer wrote:
>>
>> Extend the tools/ version of libbpf to include all of the functionality
>> provided in the samples/bpf version.
>>
>> Signed-off-by: Joe Stringer <joe@ovn.org>
>> ---
>> v2: Don't shift non-bpf changes across.
>> Various type cleanups, removal of extraneous declarations
>> ---
>> tools/lib/bpf/bpf.c | 107 ++++++++++++++++++++------
>> tools/lib/bpf/bpf.h | 202
>> +++++++++++++++++++++++++++++++++++++++++++++++--
>> tools/lib/bpf/libbpf.c | 3 +-
>> 3 files changed, 279 insertions(+), 33 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 4212ed62235b..5e061851ac00 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -20,10 +20,17 @@
>> */
>> #include <stdlib.h>
>> -#include <memory.h>
>> +#include <stdio.h>
>> #include <unistd.h>
>> #include <asm/unistd.h>
>> +#include <string.h>
>> +#include <linux/netlink.h>
>> #include <linux/bpf.h>
>> +#include <errno.h>
>> +#include <net/ethernet.h>
>> +#include <net/if.h>
>> +#include <linux/if_packet.h>
>> +#include <arpa/inet.h>
>> #include "bpf.h"
>>
>
>
> Why we need these network related headers?
I started with a copy/paste, assuming that the headers were all in use
but I guess that assumption was wrong.
>> /*
>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>> *attr,
>> return syscall(__NR_bpf, cmd, attr, size);
>> }
>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>> - int value_size, int max_entries)
>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> + int max_entries, int map_flags)
>> {
>> - union bpf_attr attr;
>> + union bpf_attr attr = {
>> + .map_type = map_type,
>> + .key_size = key_size,
>> + .value_size = value_size,
>> + .max_entries = max_entries,
>> + .map_flags = map_flags,
>> + };
>> - memset(&attr, '\0', sizeof(attr));
>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>> +}
>>
>
>
> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
> useful
> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
> case.
Do you want me to resubmit this piece as a separate patch or will you
address this?
> Although it is okay in samples, I still prefer a explicit bzero() or
> memset(),
> because kernel checks if unused field in this union is zero. However I'll
> check
> c standard to see how unused field would be initialized.
OK.
>> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
>> index e8ba54087497..4dba36995771 100644
>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -23,16 +23,202 @@
>> #include <linux/bpf.h>
>> +struct bpf_insn;
>> +
>> int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> - int max_entries);
>> + int max_entries, int map_flags);
>> +int bpf_update_elem(int fd, void *key, void *value, unsigned long long
>> flags);
>> +int bpf_lookup_elem(int fd, void *key, void *value);
>> +int bpf_delete_elem(int fd, void *key);
>> +int bpf_get_next_key(int fd, void *key, void *next_key);
>> +
>> +int bpf_load_program(enum bpf_prog_type prog_type,
>> + const struct bpf_insn *insns, int insn_len,
>> + const char *license, int kern_version,
>> + char *log_buf, size_t log_buf_sz);
>> +
>> +int bpf_obj_pin(int fd, const char *pathname);
>> +int bpf_obj_get(const char *pathname);
>> -/* Recommend log buffer size */
>> #define BPF_LOG_BUF_SIZE 65536
>> -int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
>> - size_t insns_cnt, char *license,
>> - u32 kern_version, char *log_buf,
>> - size_t log_buf_sz);
>> -int bpf_map_update_elem(int fd, void *key, void *value,
>> - u64 flags);
>> +/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
>> +
>> +#define BPF_ALU64_REG(OP, DST, SRC) \
>> + ((struct bpf_insn) { \
>> + .code = BPF_ALU64 | BPF_OP(OP) | BPF_X, \
>> + .dst_reg = DST, \
>> + .src_reg = SRC, \
>> + .off = 0, \
>> + .imm = 0 })
>> +
>
>
> Should we define these macros here? They are in include/linux/filter.h
> and duplicated in tools/include/linux/filter.h. Redefining them here
> would cause conflict.
Probably not; including the correct header file would be sufficient.
^ permalink raw reply
* linux-next: manual merge of the tip tree with the net-next tree
From: Stephen Rothwell @ 2016-11-17 3:04 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
David Miller, Networking
Cc: linux-next, linux-kernel, Nicolas Pitre, Thomas Lendacky
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/net/ethernet/amd/Kconfig
between commits:
e78332b2285d ("amd-xgbe: Add ECC status support for the device memory")
abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
from the net-next tree and commit:
d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/amd/Kconfig
index 7ab6efbe4189,713ea7ad22c3..000000000000
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@@ -173,13 -173,11 +173,13 @@@ config SUNLANC
config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
- depends on ((OF_NET && OF_ADDRESS) || ACPI) && HAS_IOMEM && HAS_DMA
- depends on ARM64 || COMPILE_TEST
+ depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && HAS_DMA
+ depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
- select PTP_1588_CLOCK
+ select PHYLIB
+ select AMD_XGBE_HAVE_ECC if X86
+ imply PTP_1588_CLOCK
---help---
This driver supports the AMD 10GbE Ethernet device found on an
AMD SoC.
^ permalink raw reply
* RE: [PATCH net 2/2] r8152: rx descriptor check
From: Hayes Wang @ 2016-11-17 3:05 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, mlord@pobox.com
In-Reply-To: <20161115011044.GA13220@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, November 15, 2016 9:11 AM
[...]
> If it was possible to get it wrong once, it should be possible to
> get it wrong twice, especially if some part of the hardware design
> is recycled. I don't mean anything else.
I agree with you. However, I have to let it could be reproduced
for confirming it.
Besides, the behavior is different for PCIe and USB device. There
is no action of DMA for USB device. It is done by the USB host
controller. And, the USB host controller wouldn't allow the device
sends a data which is more than the size of the buffer.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Wangnan (F) @ 2016-11-17 3:21 UTC (permalink / raw)
To: Joe Stringer; +Cc: LKML, netdev, ast, daniel, acme
In-Reply-To: <CAOftzPhXk0LKCt8wQKuqeBnDrj6a4p0YL7P80jhK78eFSAz8WQ@mail.gmail.com>
On 2016/11/17 10:46, Joe Stringer wrote:
> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>> I'm also working on improving bpf.c. Please have a look at:
>>
>> https://lkml.org/lkml/2016/11/14/1078
>>
>> Since bpf.c is simple, I think we can add more functions and fixes
>> gradually, instead of a full copy.
>>
>> See my inline comment below.
> Ah, I missed this, my apologies. It looks like it will provide much of
> what I need, I can reassess this patch with your series in mind.
>
> One comment though for your patch (I don't have the original thread to
> respond to unfortunately): The map_pin and map_get functions in your
> patch series can be used to pin progs too, so maybe there is a better
> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
> wouldn't want those to be confused with the libbpf.c objects so maybe
> there's a clearer name that could be used.
The full thread can be found:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html
(lkml.kernel.org is not working for me, sorry)
In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
can pin a map to sysfs. I think this feature would be useful, but I don't
have an example to show how to use it. I didn't provide program pinning/get
interface because in perf hook they are not useful. After rethinking your
suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
and export bpf_map_pin to perf hook. I'll adjust my own patch.
> I also have some patches to rework the samples/bpf/* code to use
> libbpf instead of the sample code that is there, is it worth me
> submitting that? It will need to wait for your patch to go in, plus a
> merge with davem's tree.
>
>> On 2016/11/17 1:43, Joe Stringer wrote:
[SNIP]
>>> /*
>>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>>> *attr,
>>> return syscall(__NR_bpf, cmd, attr, size);
>>> }
>>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>>> - int value_size, int max_entries)
>>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>>> value_size,
>>> + int max_entries, int map_flags)
>>> {
>>> - union bpf_attr attr;
>>> + union bpf_attr attr = {
>>> + .map_type = map_type,
>>> + .key_size = key_size,
>>> + .value_size = value_size,
>>> + .max_entries = max_entries,
>>> + .map_flags = map_flags,
>>> + };
>>> - memset(&attr, '\0', sizeof(attr));
>>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>>> +}
>>>
>>
>> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
>> useful
>> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
>> case.
> Do you want me to resubmit this piece as a separate patch or will you
> address this?
Please send it.
Thank you.
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2016-11-17 3:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
David Miller, Networking
Cc: linux-next, linux-kernel, Christian Borntraeger, Eric Dumazet
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
net/core/dev.c: In function 'sk_busy_loop':
net/core/dev.c:5065:3: error: implicit declaration of function 'cpu_relax_lowlatency' [-Werror=implicit-function-declaration]
cpu_relax_lowlatency();
^
Caused by commit
5bd0b85ba8bb ("locking/core, arch: Remove cpu_relax_lowlatency()")
interacting with commit
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
from the net-next tree.
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 17 Nov 2016 14:13:05 +1100
Subject: [PATCH] net: busy-poll: fix up for cpu_relax_lowlatency() removal
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d29d538ec5ad..6b9f8eb55b62 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5062,7 +5062,7 @@ bool sk_busy_loop(struct sock *sk, int nonblock)
return rc;
goto restart;
}
- cpu_relax_lowlatency();
+ cpu_relax();
}
if (napi_poll)
busy_poll_stop(napi, have_poll_lock);
--
2.10.2
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: [PATCH] net: dsa: mv88e6xxx: Respect SPEED_UNFORCED, don't set force bit
From: Vivien Didelot @ 2016-11-17 3:25 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1479266808-10957-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> The SPEED_UNFORCED indicates the MAC & PHY should perform
> auto-negotiation to determine a speed which works. If this is called
> for, don't set the force bit. If it is set, the MAC actually does
> 10Gbps, why the internal PHYs don't support.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 96a2b40c7bd3 ("net: dsa: mv88e6xxx: add port's MAC speed setter")
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
David, this is for net-next.
Thanks!
Vivien
^ permalink raw reply
* RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang @ 2016-11-17 3:36 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
mlord@pobox.com
In-Reply-To: <1394712342-15778-227-Taiwan-albertk@realtek.com>
[...]
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
>
> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Excuse me. If I want to re-send this one patch, should I let
RTL_VER_02 use rx hw checksum?
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Wangnan (F) @ 2016-11-17 3:39 UTC (permalink / raw)
To: Joe Stringer; +Cc: LKML, netdev, ast, daniel, acme
In-Reply-To: <CAOftzPhXk0LKCt8wQKuqeBnDrj6a4p0YL7P80jhK78eFSAz8WQ@mail.gmail.com>
On 2016/11/17 10:46, Joe Stringer wrote:
> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>> I'm also working on improving bpf.c. Please have a look at:
>>
>> https://lkml.org/lkml/2016/11/14/1078
>>
>> Since bpf.c is simple, I think we can add more functions and fixes
>> gradually, instead of a full copy.
>>
>> See my inline comment below.
> Ah, I missed this, my apologies. It looks like it will provide much of
> what I need, I can reassess this patch with your series in mind.
>
> One comment though for your patch (I don't have the original thread to
> respond to unfortunately): The map_pin and map_get functions in your
> patch series can be used to pin progs too, so maybe there is a better
> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
> wouldn't want those to be confused with the libbpf.c objects so maybe
> there's a clearer name that could be used.
>
> I also have some patches to rework the samples/bpf/* code to use
> libbpf instead of the sample code that is there, is it worth me
> submitting that? It will need to wait for your patch to go in, plus a
> merge with davem's tree.
>
I'm happy to see you are trying to replace samples/bpf 's own
libbpf with tools/lib/bpf. I think you can submit your work
on libbpf and patches on samples together if they are ready.
Arnaldo can pick up patches good for him, and you can improve
other patches based on his newest branch.
Thank you.
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 3:40 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, netdev, ast, Daniel Borkmann, Arnaldo Carvalho de Melo
In-Reply-To: <582D2222.4060309@huawei.com>
On 16 November 2016 at 19:21, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>>>
>>> I'm also working on improving bpf.c. Please have a look at:
>>>
>>> https://lkml.org/lkml/2016/11/14/1078
>>>
>>> Since bpf.c is simple, I think we can add more functions and fixes
>>> gradually, instead of a full copy.
>>>
>>> See my inline comment below.
>>
>> Ah, I missed this, my apologies. It looks like it will provide much of
>> what I need, I can reassess this patch with your series in mind.
>>
>> One comment though for your patch (I don't have the original thread to
>> respond to unfortunately): The map_pin and map_get functions in your
>> patch series can be used to pin progs too, so maybe there is a better
>> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
>> wouldn't want those to be confused with the libbpf.c objects so maybe
>> there's a clearer name that could be used.
>
>
> The full thread can be found:
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html
>
> (lkml.kernel.org is not working for me, sorry)
>
> In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
> can pin a map to sysfs. I think this feature would be useful, but I don't
> have an example to show how to use it. I didn't provide program pinning/get
> interface because in perf hook they are not useful. After rethinking your
> suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
> and export bpf_map_pin to perf hook. I'll adjust my own patch.
OK. For what it's worth, I also have a slightly higher level user of
this interface with a patch series for libbpf.[ch] that allows to you
pin a bpf_object * to the filesystem; The idea is that you pass it a
subpath, then it will make sure the BPF FS is mounted, then put your
programs and maps under, for example,
/sys/fs/bpf/$subpath/{maps,progs}/foo (where 'foo' is a symbol name
from your eBPF ELF). I also plan to post this soon, but it depends on
bpf_obj_pin() so will need your patch to go in first. I will submit it
when I can.
>>>> /*
>>>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>>>> *attr,
>>>> return syscall(__NR_bpf, cmd, attr, size);
>>>> }
>>>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>>>> - int value_size, int max_entries)
>>>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>>>> value_size,
>>>> + int max_entries, int map_flags)
>>>> {
>>>> - union bpf_attr attr;
>>>> + union bpf_attr attr = {
>>>> + .map_type = map_type,
>>>> + .key_size = key_size,
>>>> + .value_size = value_size,
>>>> + .max_entries = max_entries,
>>>> + .map_flags = map_flags,
>>>> + };
>>>> - memset(&attr, '\0', sizeof(attr));
>>>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>>>> +}
>>>>
>>>
>>> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
>>> useful
>>> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in
>>> this
>>> case.
>>
>> Do you want me to resubmit this piece as a separate patch or will you
>> address this?
>
>
> Please send it.
OK.
^ permalink raw reply
* Re: CPU port VLAN configuration [Was: Re: [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port]
From: Vivien Didelot @ 2016-11-17 3:51 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, andrew, knaack.h
In-Reply-To: <b5a41c19-b0a4-e5f8-23db-211c2d754f74@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
>> We currently have a fundamental problem in how we treat the CPU port and
>> its VLAN membership. As soon as a second VLAN is configured to be
>> untagged, the CPU automatically becomes untagged for that VLAN as well,
>> and yet, we don't gracefully make sure that the CPU becomes tagged in
>> the other VLANs it could be a member of. This results in only one VLAN
>> being effectively usable from the CPU's perspective.
>>
>> Instead of having some pretty complex logic which tries to maintain the
>> CPU port's default VLAN and its untagged properties, just do something
>> very simple which consists in neither altering the CPU port's PVID
>> settings, nor its untagged settings:
>>
>> - whenever a VLAN is added, the CPU is automatically a member of this
>> VLAN group, as a tagged member
mv88e6xxx currently does that.
>> - PVID settings for downstream ports do not alter the CPU port's PVID
>> since it now is part of all VLANs in the system
If I'm not mistaken, the CPU port's PVID defaults to 0, since no other
value really makes sense...
>> This means that a typical example where e.g: LAN ports are in VLAN1, and
>> WAN port is in VLAN2, now require having two VLAN interfaces for the
>> host to properly terminate and send traffic from/to.
>
> Do you know how mv88e6xxx deals with this case? In the use case
> mentioned, what we have is this:
>
> - Ports0-3 -> VLAN1 (LAN segment)
> - Port4 -> WAN (WAN segment)
>
> With OpenWrt/swconfig you would typically have eth0.1 and eth0.2
> interfaces that would take care of terminating VLAN tags, this is the
> behavior that I am bringing back here because it is the only way you can
> have the downstream ports configured as untagged, and yet have proper
> segregation appear from the CPU port's perspective (unless you use
> Marvell/Broadcom/QCA tags, which we don't do yet here, but still).
>
> A more general issue that I am still working on is having the ability to
> control the CPU port's VLAN properties by configuring the master bridge
> device, since it is inherently "a view" (if multiple bridges, multiple
> views) of the CPU port of an Ethernet switch. The general idea would be
> that if you do:
>
> bridge vlan add vid 2 dev br0 self
>
> this calls down into the switch driver to actually configure VLAN ID 2
> on the CPU port to be tagged.
This is the good approach IMO.
As a side note, a good first thing to do here would be to fix the actual
behavior of switchdev calls from iproute2 commands. It doesn't respect
what the bridge's manpage describes in the VLAN section:
self the vlan is configured on the specified physical device.
Required if the device is the bridge device.
master the vlan is configured on the software bridge (default).
If I'm not mistaken, "bridge vlan add vid 2 dev lan2 [master]" currently
programs the hardware.
> I have a prototype of this that nearly works [1], except upon the
> initial bridge master device creation, since we have not had the ability
> to enslave port members yet, we are not able to propagate the bridge's
> default VLAN to the CPU port. More to come in the next weeks!
For this case, maybe the way to go would be to let DSA query the bridge
VLAN membership when enslaving a port and configure the CPU port
accordingly if needed.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 3:53 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, netdev, ast, Daniel Borkmann, Arnaldo Carvalho de Melo
In-Reply-To: <582D265B.4000102@huawei.com>
On 16 November 2016 at 19:39, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>>>
>>> I'm also working on improving bpf.c. Please have a look at:
>>>
>>> https://lkml.org/lkml/2016/11/14/1078
>>>
>>> Since bpf.c is simple, I think we can add more functions and fixes
>>> gradually, instead of a full copy.
>>>
>>> See my inline comment below.
>>
>> Ah, I missed this, my apologies. It looks like it will provide much of
>> what I need, I can reassess this patch with your series in mind.
>>
>> One comment though for your patch (I don't have the original thread to
>> respond to unfortunately): The map_pin and map_get functions in your
>> patch series can be used to pin progs too, so maybe there is a better
>> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
>> wouldn't want those to be confused with the libbpf.c objects so maybe
>> there's a clearer name that could be used.
>>
>> I also have some patches to rework the samples/bpf/* code to use
>> libbpf instead of the sample code that is there, is it worth me
>> submitting that? It will need to wait for your patch to go in, plus a
>> merge with davem's tree.
>>
> I'm happy to see you are trying to replace samples/bpf 's own
> libbpf with tools/lib/bpf. I think you can submit your work
> on libbpf and patches on samples together if they are ready.
> Arnaldo can pick up patches good for him, and you can improve
> other patches based on his newest branch.
I'll look into it.
^ permalink raw reply
* Re: [PATCH net-next 0/4] bnxt_en: Updates.
From: David Miller @ 2016-11-17 4:11 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Wed, 16 Nov 2016 21:13:06 -0500
> New firmware spec. update, autoneg update, and UDP RSS support.
Looks good, series applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: David Miller @ 2016-11-17 4:17 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: nicolas.dichtel, avagin, netdev
In-Reply-To: <CAM_iQpXzp54gOyiRu4PUcJhLEB3T+TTEL+JLE2PL+oB31ZuCJw@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 16 Nov 2016 09:29:29 -0800
> On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index f61c0e02a413..63f65387f4e1 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
>> max = reqid + 1;
>> }
>>
>> + if (!atomic_read(&net->count) || !atomic_read(&peer->count))
>> + return -EINVAL;
>> +
>> return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
>> }
>
>
> There is already a check in peernet2id_alloc(), so why not just the following?
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index f61c0e0..7001da9 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
> bool alloc;
> int id;
>
> + if (atomic_read(&net->count) == 0)
> + return NETNSA_NSID_NOT_ASSIGNED;
> spin_lock_irqsave(&net->nsid_lock, flags);
> alloc = atomic_read(&peer->count) == 0 ? false : true;
> id = __peernet2id_alloc(net, peer, &alloc);
Indeed, this looks cleaner, Nicolas?
^ permalink raw reply
* Re: [PATCH net] sctp: use new rhlist interface on sctp transport rhashtable
From: David Miller @ 2016-11-17 4:22 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich, herbert,
phil
In-Reply-To: <0a89ef8506db3bba6a37010bd5622cd145183ab4.1479223391.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 15 Nov 2016 23:23:11 +0800
> Now sctp transport rhashtable uses hash(lport, dport, daddr) as the key
> to hash a node to one chain. If in one host thousands of assocs connect
> to one server with the same lport and different laddrs (although it's
> not a normal case), all the transports would be hashed into the same
> chain.
>
> It may cause to keep returning -EBUSY when inserting a new node, as the
> chain is too long and sctp inserts a transport node in a loop, which
> could even lead to system hangs there.
>
> The new rhlist interface works for this case that there are many nodes
> with the same key in one chain. It puts them into a list then makes this
> list be as a node of the chain.
>
> This patch is to replace rhashtable_ interface with rhltable_ interface.
> Since a chain would not be too long and it would not return -EBUSY with
> this fix when inserting a node, the reinsert loop is also removed here.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port
From: David Miller @ 2016-11-17 4:26 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, knaack.h
In-Reply-To: <20161115235815.25641-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 Nov 2016 15:58:15 -0800
> We currently have a fundamental problem in how we treat the CPU port and
> its VLAN membership. As soon as a second VLAN is configured to be
> untagged, the CPU automatically becomes untagged for that VLAN as well,
> and yet, we don't gracefully make sure that the CPU becomes tagged in
> the other VLANs it could be a member of. This results in only one VLAN
> being effectively usable from the CPU's perspective.
>
> Instead of having some pretty complex logic which tries to maintain the
> CPU port's default VLAN and its untagged properties, just do something
> very simple which consists in neither altering the CPU port's PVID
> settings, nor its untagged settings:
>
> - whenever a VLAN is added, the CPU is automatically a member of this
> VLAN group, as a tagged member
> - PVID settings for downstream ports do not alter the CPU port's PVID
> since it now is part of all VLANs in the system
>
> This means that a typical example where e.g: LAN ports are in VLAN1, and
> WAN port is in VLAN2, now require having two VLAN interfaces for the
> host to properly terminate and send traffic from/to.
>
> Fixes: Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
> Reported-by: Hartmut Knaack <knaack.h@gmx.de>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David,
>
> Can you queue this for -stable so it makes it into 4.8.4?
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: netcp: replace IS_ERR_OR_NULL by IS_ERR
From: David Miller @ 2016-11-17 4:27 UTC (permalink / raw)
To: Julia.Lawall
Cc: w-kwok2, kernel-janitors, m-karicheri2, netdev, linux-kernel,
christophe.jaillet
In-Reply-To: <1479293014-18811-2-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Wed, 16 Nov 2016 11:43:33 +0100
> knav_queue_open always returns an ERR_PTR value, never NULL. This can be
> confirmed by unfolding the function calls and conforms to the function's
> documentation. Thus, replace IS_ERR_OR_NULL by IS_ERR in error checks.
>
> The change is made using the following semantic patch:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [patch net-next 0/4] mlxsw: Introduce support for I2C bus
From: David Miller @ 2016-11-17 4:29 UTC (permalink / raw)
To: jiri; +Cc: netdev, vadimp, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1479306046-13324-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 16 Nov 2016 15:20:42 +0100
> Vadim says:
>
> This patchset adds I2C access support for SwitchX, SwitchX2, SwitchIB,
> SwitchIB2 and Spectrum silicones.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] : add a missing rcu synchronization
From: David Miller @ 2016-11-17 4:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, michael.chan
In-Reply-To: <1479306712.8455.185.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Nov 2016 06:31:52 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Add a missing synchronize_net() call to avoid potential use after free,
> since we explicitly call napi_hash_del() to factorize the RCU grace
> period.
>
> Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] : add a missing rcu synchronization
From: Eric Dumazet @ 2016-11-17 4:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, michael.chan
In-Reply-To: <20161116.233106.2234599506618839323.davem@davemloft.net>
On Wed, 2016-11-16 at 23:31 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 16 Nov 2016 06:31:52 -0800
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Add a missing synchronize_net() call to avoid potential use after free,
> > since we explicitly call napi_hash_del() to factorize the RCU grace
> > period.
> >
> > Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Michael Chan <michael.chan@broadcom.com>
>
> Applied.
Thanks David for the title fix ;)
^ permalink raw reply
* Philanthropic Gesture
From: Susanne Hanna Ursula Klattent @ 2016-11-17 5:23 UTC (permalink / raw)
To: Recipients
Hello
I want to donate a token of my Wealth as part of my Philanthropic Gesture to the world . Interested individuals or groups should contact me.
Regards
Susanne Hanna Ursula Klatten
Email: sussanklattenh1@gmail.com
^ permalink raw reply
* Problems with item delivery, n.000859529
From: FedEx 2Day A.M. @ 2016-11-17 6:12 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
Dear Customer,
Your parcel has arrived at November 14. Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.
Regards,
Alvin Mccarthy,
Sr. Operation Manager.
[-- Attachment #2: Delivery_Notification_000859529.zip --]
[-- Type: application/zip, Size: 7477 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Cong Wang @ 2016-11-17 6:32 UTC (permalink / raw)
To: David Miller
Cc: Nicolas Dichtel, Andrey Wagin, Linux Kernel Network Developers
In-Reply-To: <20161116.231722.2198167385156796830.davem@davemloft.net>
On Wed, Nov 16, 2016 at 8:17 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Wed, 16 Nov 2016 09:29:29 -0800
>
>> On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
>> <nicolas.dichtel@6wind.com> wrote:
>>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>>> index f61c0e02a413..63f65387f4e1 100644
>>> --- a/net/core/net_namespace.c
>>> +++ b/net/core/net_namespace.c
>>> @@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
>>> max = reqid + 1;
>>> }
>>>
>>> + if (!atomic_read(&net->count) || !atomic_read(&peer->count))
>>> + return -EINVAL;
>>> +
>>> return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
>>> }
>>
>>
>> There is already a check in peernet2id_alloc(), so why not just the following?
>>
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index f61c0e0..7001da9 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
>> bool alloc;
>> int id;
>>
>> + if (atomic_read(&net->count) == 0)
>> + return NETNSA_NSID_NOT_ASSIGNED;
>> spin_lock_irqsave(&net->nsid_lock, flags);
>> alloc = atomic_read(&peer->count) == 0 ? false : true;
>> id = __peernet2id_alloc(net, peer, &alloc);
>
> Indeed, this looks cleaner, Nicolas?
Yeah, I already sent a formal patch:
https://patchwork.ozlabs.org/patch/695747/
since Nicolas' patch doesn't even compile...
^ permalink raw reply
* Re: [v3] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-11-17 6:41 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1475613462-93384-1-git-send-email-rajatja@google.com>
Rajat Jain <rajatja@google.com> wrote:
> Register the WLAN device as a wakeup source since it can
> wake the system via wake-on-wireless-lan. In an actual wowlan
> event, notify the PM core that we are the current wakeup source.
> This allows the PM core to update the wakeup attributes in /sys.
>
> This was causing wakeup issues on chromeos as the system was
> apparently confused about the wakeup source.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
df566a481ee8 mwifiex: report wakeup for wowlan
--
https://patchwork.kernel.org/patch/9362275/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wlcore: Allow scans when in AP mode
From: Kalle Valo @ 2016-11-17 6:43 UTC (permalink / raw)
To: Xander Huff
Cc: linux-wireless, netdev, James Minor, linux-kernel, xander.huff
In-Reply-To: <1475855157-21271-1-git-send-email-xander.huff@ni.com>
Xander Huff <xander.huff@ni.com> wrote:
> From: James Minor <james.minor@ni.com>
>
> When in AP mode, scans can be done without changing firmware to
> the multi-role firmware. Allow the interface to scan if forced
> in the scan request.
>
> Signed-off-by: James Minor <james.minor@ni.com>
> Signed-off-by: Xander Huff <xander.huff@ni.com>
> Reviewed-by: Ben Shelton <ben.shelton@ni.com>
> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
Patch applied to wireless-drivers-next.git, thanks.
87016f5eb1a3 wlcore: Allow scans when in AP mode
--
https://patchwork.kernel.org/patch/9366467/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: print name of connect status event
From: Kalle Valo @ 2016-11-17 6:45 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20161014074559.22962-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This simplifies debugging. Format %s (%u) comes from similar debugging
> message in brcmf_fweh_event_worker.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
e1c122d55f9e brcmfmac: print name of connect status event
--
https://patchwork.kernel.org/patch/9376147/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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