* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Andrii Nakryiko @ 2019-07-02 19:22 UTC (permalink / raw)
To: Song Liu
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Lorenz Bauer, Jann Horn, gregkh
In-Reply-To: <20190627201923.2589391-2-songliubraving@fb.com>
On Thu, Jun 27, 2019 at 1:20 PM Song Liu <songliubraving@fb.com> wrote:
>
> This patch introduce unprivileged BPF access. The access control is
> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
> to call sys_bpf().
>
> Two ioctl command are added to /dev/bpf:
>
> The two commands enable/disable permission to call sys_bpf() for current
> task. This permission is noted by bpf_permitted in task_struct. This
> permission is inherited during clone(CLONE_THREAD).
>
> Helper function bpf_capable() is added to check whether the task has got
> permission via /dev/bpf.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/linux/bpf.h | 11 +++++
> include/linux/sched.h | 3 ++
> include/uapi/linux/bpf.h | 6 +++
> kernel/bpf/arraymap.c | 2 +-
> kernel/bpf/cgroup.c | 2 +-
> kernel/bpf/core.c | 4 +-
> kernel/bpf/cpumap.c | 2 +-
> kernel/bpf/devmap.c | 2 +-
> kernel/bpf/hashtab.c | 4 +-
> kernel/bpf/lpm_trie.c | 2 +-
> kernel/bpf/offload.c | 2 +-
> kernel/bpf/queue_stack_maps.c | 2 +-
> kernel/bpf/reuseport_array.c | 2 +-
> kernel/bpf/stackmap.c | 2 +-
> kernel/bpf/syscall.c | 71 +++++++++++++++++++++-------
> kernel/bpf/verifier.c | 2 +-
> kernel/bpf/xskmap.c | 2 +-
> kernel/fork.c | 5 ++
> net/core/filter.c | 6 +--
> 20 files changed, 99 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
> index c9558146ac58..19998b99d603 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -327,6 +327,7 @@ Code Seq#(hex) Include File Comments
> 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
> 0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
> 0xB6 all linux/fpga-dfl.h
> +0xBP 01-02 uapi/linux/bpf.h <mailto:bpf@vger.kernel.org>
should this be 0xBF?
> 0xC0 00-0F linux/usb/iowarrior.h
> 0xCA 00-0F uapi/misc/cxl.h
> 0xCA 10-2F uapi/misc/ocxl.h
<snip>
^ permalink raw reply
* Re: veth pair ping fail if one of them enslaved into a VRF
From: Ido Schimmel @ 2019-07-02 19:21 UTC (permalink / raw)
To: Zoltán Elek; +Cc: netdev, dsa
In-Reply-To: <CANsP1a4HCthstZP16k-ABajni1m75+VKT+mgLPF=4yGJ-H_ONQ@mail.gmail.com>
On Tue, Jul 02, 2019 at 08:42:15PM +0200, Zoltán Elek wrote:
> Hi!
>
> I have a simple scenario, with a veth pair, IP addresses assigned from
> the same subnet. They can ping eachother. But when I put one of them
> into a VRF (in the example below, I put veth in-vrf into the test-vrf
> VRF) the ping fails. My first question: that is the expected behavior?
> And my second question: is there any way to overcome this?
>
> Here are my test commands:
> ip link add out-of-vrf type veth peer name in-vrf
> ip link set dev out-of-vrf up
> ip link set dev in-vrf up
> ip link add test-vrf type vrf table 10
> ip link set dev test-vrf up
> ip -4 addr add 100.127.253.2/24 dev in-vrf
> ip -4 addr add 100.127.253.1/24 dev out-of-vrf
>
> Then ping works as expected:
> ping -c1 -I 100.127.253.1 100.127.253.2
>
> After I put the in-vrf into test-vrf, ping fails:
> ip link set in-vrf vrf test-vrf up
You need to re-order the FIB rules so that lookup for 100.127.253.1
happens in table 10 and not in the local table:
# ip -4 rule add pref 32765 table local
# ip -4 rule del pref 0
# ip -4 rule show
1000: from all lookup [l3mdev-table]
32765: from all lookup local
32766: from all lookup main
32767: from all lookup default
Bad:
ping 16735 [001] 13726.398115: fib:fib_table_lookup: table 255 oif 0 iif
9 proto 0 100.127.253.2/0 -> 100.127.253.1/0 tos 0 scope 0 flags 4 ==>
dev out-of-vrf gw 0.0.0.0 src 100.127.253.1 err 0
Good:
ping 16665 [001] 13500.937145: fib:fib_table_lookup: table 10 oif 0 iif
9 proto 0 100.127.253.2/0 -> 100.127.253.1/0 tos 0 scope 0 flags 4 ==>
dev in-vrf gw 0.0.0.0 src 100.127.253.2 err 0
>
> Thanks,
> Zoltan Elek,
> VI1
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] libbpf: capture value in BTF type info for BTF-defined map defs
From: Y Song @ 2019-07-02 19:18 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: andrii.nakryiko, Alexei Starovoitov, Daniel Borkmann, bpf, netdev,
Song Liu
In-Reply-To: <20190628152539.3014719-2-andriin@fb.com>
On Fri, Jun 28, 2019 at 8:26 AM Andrii Nakryiko <andriin@fb.com> wrote:
>
> Change BTF-defined map definitions to capture compile-time integer
> values as part of BTF type definition, to avoid split of key/value type
> information and actual type/size/flags initialization for maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++----------------------
> 1 file changed, 28 insertions(+), 30 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 6e6ebef11ba3..9e099ecb2c2b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1028,40 +1028,40 @@ static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
> }
> }
>
> -static bool get_map_field_int(const char *map_name,
> - const struct btf *btf,
> +/*
> + * Fetch integer attribute of BTF map definition. Such attributes are
> + * represented using a pointer to an array, in which dimensionality of array
> + * encodes specified integer value. E.g., int (*type)[BPF_MAP_TYPE_ARRAY];
> + * encodes `type => BPF_MAP_TYPE_ARRAY` key/value pair completely using BTF
> + * type definition, while using only sizeof(void *) space in ELF data section.
> + */
> +static bool get_map_field_int(const char *map_name, const struct btf *btf,
> const struct btf_type *def,
> - const struct btf_member *m,
> - const void *data, __u32 *res) {
> + const struct btf_member *m, __u32 *res) {
> const struct btf_type *t = skip_mods_and_typedefs(btf, m->type);
> const char *name = btf__name_by_offset(btf, m->name_off);
> - __u32 int_info = *(const __u32 *)(const void *)(t + 1);
> + const struct btf_array *arr_info;
> + const struct btf_type *arr_t;
>
> - if (BTF_INFO_KIND(t->info) != BTF_KIND_INT) {
> - pr_warning("map '%s': attr '%s': expected INT, got %u.\n",
> + if (BTF_INFO_KIND(t->info) != BTF_KIND_PTR) {
> + pr_warning("map '%s': attr '%s': expected PTR, got %u.\n",
> map_name, name, BTF_INFO_KIND(t->info));
> return false;
> }
> - if (t->size != 4 || BTF_INT_BITS(int_info) != 32 ||
> - BTF_INT_OFFSET(int_info)) {
> - pr_warning("map '%s': attr '%s': expected 32-bit non-bitfield integer, "
> - "got %u-byte (%d-bit) one with bit offset %d.\n",
> - map_name, name, t->size, BTF_INT_BITS(int_info),
> - BTF_INT_OFFSET(int_info));
> - return false;
> - }
> - if (BTF_INFO_KFLAG(def->info) && BTF_MEMBER_BITFIELD_SIZE(m->offset)) {
> - pr_warning("map '%s': attr '%s': bitfield is not supported.\n",
> - map_name, name);
> +
> + arr_t = btf__type_by_id(btf, t->type);
> + if (!arr_t) {
> + pr_warning("map '%s': attr '%s': type [%u] not found.\n",
> + map_name, name, t->type);
> return false;
> }
> - if (m->offset % 32) {
> - pr_warning("map '%s': attr '%s': unaligned fields are not supported.\n",
> - map_name, name);
> + if (BTF_INFO_KIND(arr_t->info) != BTF_KIND_ARRAY) {
> + pr_warning("map '%s': attr '%s': expected ARRAY, got %u.\n",
> + map_name, name, BTF_INFO_KIND(arr_t->info));
> return false;
> }
> -
> - *res = *(const __u32 *)(data + m->offset / 8);
> + arr_info = (const void *)(arr_t + 1);
> + *res = arr_info->nelems;
Here, we use number of array elements (__u32 type) as the value.
But we have
#define __int(name, val) int (*name)[val]
which suggests that "val" have type "int".
Do you think using __uint(name, val) may be more consistent?
If this is something to be enforced, it may be worthwhile to check
array element type should be __uint, just in case that in the
future we have different array element type (e.g., int)
for different purpose.
> return true;
> }
>
> @@ -1074,7 +1074,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> const struct btf_var_secinfo *vi;
> const struct btf_var *var_extra;
> const struct btf_member *m;
> - const void *def_data;
> const char *map_name;
> struct bpf_map *map;
> int vlen, i;
> @@ -1131,7 +1130,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> pr_debug("map '%s': at sec_idx %d, offset %zu.\n",
> map_name, map->sec_idx, map->sec_offset);
>
> - def_data = data->d_buf + vi->offset;
> vlen = BTF_INFO_VLEN(def->info);
> m = (const void *)(def + 1);
> for (i = 0; i < vlen; i++, m++) {
> @@ -1144,19 +1142,19 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> }
> if (strcmp(name, "type") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.type))
> + &map->def.type))
> return -EINVAL;
> pr_debug("map '%s': found type = %u.\n",
> map_name, map->def.type);
> } else if (strcmp(name, "max_entries") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.max_entries))
> + &map->def.max_entries))
> return -EINVAL;
> pr_debug("map '%s': found max_entries = %u.\n",
> map_name, map->def.max_entries);
> } else if (strcmp(name, "map_flags") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.map_flags))
> + &map->def.map_flags))
> return -EINVAL;
> pr_debug("map '%s': found map_flags = %u.\n",
> map_name, map->def.map_flags);
> @@ -1164,7 +1162,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found key_size = %u.\n",
> map_name, sz);
> @@ -1207,7 +1205,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found value_size = %u.\n",
> map_name, sz);
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix send on a connected, but unbound socket
From: David Miller @ 2019-07-02 19:16 UTC (permalink / raw)
To: dhowells
Cc: netdev, syzbot+7966f2a0b2c7da8939b4, marc.dionne, linux-afs,
linux-kernel
In-Reply-To: <156207955265.1655.13658692984261290810.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 02 Jul 2019 15:59:12 +0100
> If sendmsg() or sendmmsg() is called on a connected socket that hasn't had
> bind() called on it, then an oops will occur when the kernel tries to
> connect the call because no local endpoint has been allocated.
>
> Fix this by implicitly binding the socket if it is in the
> RXRPC_CLIENT_UNBOUND state, just like it does for the RXRPC_UNBOUND state.
>
> Further, the state should be transitioned to RXRPC_CLIENT_BOUND after this
> to prevent further attempts to bind it.
>
> This can be tested with:
...
> Leading to the following oops:
...
> Fixes: 2341e0775747 ("rxrpc: Simplify connect() implementation and simplify sendmsg() op")
> Reported-by: syzbot+7966f2a0b2c7da8939b4@syzkaller.appspotmail.com
> Signed-off-by: David Howells <dhowells@redhat.com>
> Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 07/12] net: use tcf_block_setup() infrastructure
From: Marcelo Ricardo Leitner @ 2019-07-02 19:16 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, santosh, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
jakub.kicinski, peppe.cavallaro, grygorii.strashko, andrew,
vivien.didelot, alexandre.torgue, joabreu, linux-net-drivers,
ganeshgr, ogerlitz, Manish.Chopra, mkubecek, venkatkumar.duvvuru,
cphealy
In-Reply-To: <20190620194917.2298-8-pablo@netfilter.org>
On Thu, Jun 20, 2019 at 09:49:12PM +0200, Pablo Neira Ayuso wrote:
...
> @@ -1173,8 +1191,10 @@ static int tcf_block_offload_cmd(struct tcf_block *block,
> struct tc_block_offload bo = {};
> int err;
>
> + bo.net = dev_net(dev);
> bo.command = command;
> bo.binder_type = ei->binder_type;
> + bo.net = dev_net(dev),
^
And it's assigning the same thing twice in this chunk.
> bo.block = block;
> bo.extack = extack;
> INIT_LIST_HEAD(&bo.cb_list);
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH net-next 02/12] net: sched: add tcf_block_cb_alloc()
From: Marcelo Ricardo Leitner @ 2019-07-02 19:14 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, santosh, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
jakub.kicinski, peppe.cavallaro, grygorii.strashko, andrew,
vivien.didelot, alexandre.torgue, joabreu, linux-net-drivers,
ganeshgr, ogerlitz, Manish.Chopra, mkubecek, venkatkumar.duvvuru,
cphealy
In-Reply-To: <20190620194917.2298-3-pablo@netfilter.org>
On Thu, Jun 20, 2019 at 09:49:07PM +0200, Pablo Neira Ayuso wrote:
> Add a new helper function to allocate tcf_block_cb objects.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> include/net/pkt_cls.h | 8 ++++++++
> net/sched/cls_api.c | 23 +++++++++++++++++++----
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> index 720f2b32fc2f..276a17a3547b 100644
> --- a/include/net/pkt_cls.h
> +++ b/include/net/pkt_cls.h
> @@ -72,6 +72,8 @@ static inline struct Qdisc *tcf_block_q(struct tcf_block *block)
> return block->q;
> }
>
> +struct tcf_block_cb *tcf_block_cb_alloc(tc_setup_cb_t *cb,
> + void *cb_ident, void *cb_priv);
> void *tcf_block_cb_priv(struct tcf_block_cb *block_cb);
> struct tcf_block_cb *tcf_block_cb_lookup(struct tcf_block *block,
> tc_setup_cb_t *cb, void *cb_ident);
> @@ -150,6 +152,12 @@ void tc_setup_cb_block_unregister(struct tcf_block *block, tc_setup_cb_t *cb,
> {
> }
>
> +static inline struct tcf_block_cb *
> +tcf_block_cb_alloc(tc_setup_cb_t *cb, void *cb_ident, void *cb_priv)
> +{
> + return NULL;
[A] This...
> +}
> +
> static inline
> void *tcf_block_cb_priv(struct tcf_block_cb *block_cb)
> {
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index b2417fda26ec..c01d825edab5 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -746,6 +746,23 @@ unsigned int tcf_block_cb_decref(struct tcf_block_cb *block_cb)
> }
> EXPORT_SYMBOL(tcf_block_cb_decref);
>
> +struct tcf_block_cb *tcf_block_cb_alloc(tc_setup_cb_t *cb,
> + void *cb_ident, void *cb_priv)
> +{
> + struct tcf_block_cb *block_cb;
> +
> + block_cb = kzalloc(sizeof(*block_cb), GFP_KERNEL);
> + if (!block_cb)
> + return NULL;
> +
> + block_cb->cb = cb;
> + block_cb->cb_ident = cb_ident;
> + block_cb->cb_priv = cb_priv;
> +
> + return block_cb;
> +}
> +EXPORT_SYMBOL(tcf_block_cb_alloc);
> +
> struct tcf_block_cb *__tcf_block_cb_register(struct tcf_block *block,
> tc_setup_cb_t *cb, void *cb_ident,
> void *cb_priv,
> @@ -761,12 +778,10 @@ struct tcf_block_cb *__tcf_block_cb_register(struct tcf_block *block,
> if (err)
> return ERR_PTR(err);
>
> - block_cb = kzalloc(sizeof(*block_cb), GFP_KERNEL);
> + block_cb = tcf_block_cb_alloc(cb, cb_ident, cb_priv);
> if (!block_cb)
> return ERR_PTR(-ENOMEM);
... will be translated into -ENOMEM here.
Would be nice to in [A] return ERR_PTR(-EOPNOTSUPP) instead and adjust
the actual implementation as well.
With patch 11, this will be visible to the user then.
> - block_cb->cb = cb;
> - block_cb->cb_ident = cb_ident;
> - block_cb->cb_priv = cb_priv;
> +
> list_add(&block_cb->list, &block->cb_list);
> return block_cb;
> }
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH net-next] rxrpc: Fix uninitialized error code in rxrpc_send_data_packet()
From: David Miller @ 2019-07-02 19:09 UTC (permalink / raw)
To: dhowells; +Cc: netdev, geert, linux-afs, linux-kernel
In-Reply-To: <156207932870.853.14700731055154895417.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 02 Jul 2019 15:55:28 +0100
> With gcc 4.1:
>
> net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’:
> net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function
>
> Indeed, if the first jump to the send_fragmentable label is made, and
> the address family is not handled in the switch() statement, ret will be
> used uninitialized.
>
> Fix this by BUG()'ing as is done in other places in rxrpc where internal
> support for future address families will need adding. It should not be
> possible to reach this normally as the address families are checked
> up-front.
>
> Fixes: 5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs")
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCHv2] selftests/net: skip psock_tpacket test if KALLSYMS was not enabled
From: shuah @ 2019-07-02 19:09 UTC (permalink / raw)
To: Po-Hsu Lin, davem, linux-kselftest; +Cc: netdev, linux-kernel, shuah
In-Reply-To: <20190701044031.19451-1-po-hsu.lin@canonical.com>
On 6/30/19 10:40 PM, Po-Hsu Lin wrote:
> The psock_tpacket test will need to access /proc/kallsyms, this would
> require the kernel config CONFIG_KALLSYMS to be enabled first.
>
> Apart from adding CONFIG_KALLSYMS to the net/config file here, check the
> file existence to determine if we can run this test will be helpful to
> avoid a false-positive test result when testing it directly with the
> following commad against a kernel that have CONFIG_KALLSYMS disabled:
> make -C tools/testing/selftests TARGETS=net run_tests
>
> Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
> ---
> tools/testing/selftests/net/config | 1 +
> tools/testing/selftests/net/run_afpackettests | 14 +++++++++-----
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config
> index 4740404..3dea2cb 100644
> --- a/tools/testing/selftests/net/config
> +++ b/tools/testing/selftests/net/config
> @@ -25,3 +25,4 @@ CONFIG_NF_TABLES_IPV6=y
> CONFIG_NF_TABLES_IPV4=y
> CONFIG_NFT_CHAIN_NAT_IPV6=m
> CONFIG_NFT_CHAIN_NAT_IPV4=m
> +CONFIG_KALLSYMS=y
> diff --git a/tools/testing/selftests/net/run_afpackettests b/tools/testing/selftests/net/run_afpackettests
> index ea5938e..8b42e8b 100755
> --- a/tools/testing/selftests/net/run_afpackettests
> +++ b/tools/testing/selftests/net/run_afpackettests
> @@ -21,12 +21,16 @@ fi
> echo "--------------------"
> echo "running psock_tpacket test"
> echo "--------------------"
> -./in_netns.sh ./psock_tpacket
> -if [ $? -ne 0 ]; then
> - echo "[FAIL]"
> - ret=1
> +if [ -f /proc/kallsyms ]; then
> + ./in_netns.sh ./psock_tpacket
> + if [ $? -ne 0 ]; then
> + echo "[FAIL]"
> + ret=1
> + else
> + echo "[PASS]"
> + fi
> else
> - echo "[PASS]"
> + echo "[SKIP] CONFIG_KALLSYMS not enabled"
> fi
>
> echo "--------------------"
>
Looks good to me. Thanks for the patch.
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply
* [PATCH net-next] mlxsw: spectrum_ptp: Fix validation in mlxsw_sp1_ptp_packet_finish()
From: Petr Machata @ 2019-07-02 19:06 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Petr Machata, Colin Ian King, Ido Schimmel
Before mlxsw_sp1_ptp_packet_finish() sends the packet back, it validates
whether the corresponding port is still valid. However the condition is
incorrect: when mlxsw_sp_port == NULL, the code dereferences the port to
compare it to skb->dev.
The condition needs to check whether the port is present and skb->dev still
refers to that port (or else is NULL). If that does not hold, bail out.
Add a pair of parentheses to fix the condition.
Fixes: d92e4e6e33c8 ("mlxsw: spectrum: PTP: Support timestamping on Spectrum-1")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
index 7d42f86237cd..437023d67a3b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
@@ -425,7 +425,7 @@ static void mlxsw_sp1_ptp_packet_finish(struct mlxsw_sp *mlxsw_sp,
* split). Also make sure the SKB device reference is still valid.
*/
mlxsw_sp_port = mlxsw_sp->ports[local_port];
- if (!mlxsw_sp_port && (!skb->dev || skb->dev == mlxsw_sp_port->dev)) {
+ if (!(mlxsw_sp_port && (!skb->dev || skb->dev == mlxsw_sp_port->dev))) {
dev_kfree_skb_any(skb);
return;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] nfc: st-nci: remove redundant assignment to variable r
From: David Miller @ 2019-07-02 19:02 UTC (permalink / raw)
To: colin.king; +Cc: tglx, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190702131642.9865-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 2 Jul 2019 14:16:42 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable r is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: core: page_pool: add user refcnt and reintroduce page_pool_destroy
From: Ivan Khoronzhuk @ 2019-07-02 18:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Ilias Apalodimas, grygorii.strashko, jakub.kicinski,
daniel, john.fastabend, ast, linux-kernel, linux-omap
In-Reply-To: <20190702202907.15fb30ce@carbon>
On Tue, Jul 02, 2019 at 08:29:07PM +0200, Jesper Dangaard Brouer wrote:
>On Tue, 2 Jul 2019 18:21:13 +0300
>Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>
>> On Tue, Jul 02, 2019 at 05:10:29PM +0200, Jesper Dangaard Brouer wrote:
>> >On Tue, 2 Jul 2019 17:56:13 +0300
>> >Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>> >
>> >> On Tue, Jul 02, 2019 at 04:52:30PM +0200, Jesper Dangaard Brouer wrote:
>> >> >On Tue, 2 Jul 2019 17:44:27 +0300
>> >> >Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>> >> >
>> >> >> On Tue, Jul 02, 2019 at 04:31:39PM +0200, Jesper Dangaard Brouer wrote:
>> >> >> >From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> >> >> >
>> >> >> >Jesper recently removed page_pool_destroy() (from driver invocation) and
>> >> >> >moved shutdown and free of page_pool into xdp_rxq_info_unreg(), in-order to
>> >> >> >handle in-flight packets/pages. This created an asymmetry in drivers
>> >> >> >create/destroy pairs.
>> >> >> >
>> >> >> >This patch add page_pool user refcnt and reintroduce page_pool_destroy.
>> >> >> >This serves two purposes, (1) simplify drivers error handling as driver now
>> >> >> >drivers always calls page_pool_destroy() and don't need to track if
>> >> >> >xdp_rxq_info_reg_mem_model() was unsuccessful. (2) allow special cases
>> >> >> >where a single RX-queue (with a single page_pool) provides packets for two
>> >> >> >net_device'es, and thus needs to register the same page_pool twice with two
>> >> >> >xdp_rxq_info structures.
>> >> >>
>> >> >> As I tend to use xdp level patch there is no more reason to mention (2) case
>> >> >> here. XDP patch serves it better and can prevent not only obj deletion but also
>> >> >> pool flush, so, this one patch I could better leave only for (1) case.
>> >> >
>> >> >I don't understand what you are saying.
>> >> >
>> >> >Do you approve this patch, or do you reject this patch?
>> >> >
>> >> It's not reject, it's proposition to use both, XDP and page pool patches,
>> >> each having its goal.
>> >
>> >Just to be clear, if you want this patch to get accepted you have to
>> >reply with your Signed-off-by (as I wrote).
>> >
>> >Maybe we should discuss it in another thread, about why you want two
>> >solutions to the same problem.
>>
>> If it solves same problem I propose to reject this one and use this:
>> https://lkml.org/lkml/2019/7/2/651
>
>No, I propose using this one, and rejecting the other one.
There is at least several arguments against this one (related (2) purpose)
It allows:
- avoid changes to page_pool/mlx5/netsec
- save not only allocator obj but allocator "page/buffer flush"
- buffer flush can be present not only in page_pool but for other allocators
that can behave differently and not so simple solution.
- to not limit cpsw/(potentially others) to use "page_pool" allocator only
....
This patch better leave also, as it simplifies error path for page_pool and
have more error prone usage comparing with existent one.
Please, don't limit cpsw and potentially other drivers to use only
page_pool it can be zca or etc... I don't won't to modify each allocator.
I propose to add both as by fact they solve different problems with common
solution.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH net 0/4] net: bridge: fix possible stale skb pointers
From: David Miller @ 2019-07-02 18:54 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, martin, bridge, yoshfuji
In-Reply-To: <20190702120021.13096-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 2 Jul 2019 15:00:17 +0300
> In the bridge driver we have a couple of places which call pskb_may_pull
> but we've cached skb pointers before that and use them after which can
> lead to out-of-bounds/stale pointer use. I've had these in my "to fix"
> list for some time and now we got a report (patch 01) so here they are.
> Patches 02-04 are fixes based on code inspection. Also patch 01 was
> tested by Martin Weinelt, Martin if you don't mind please add your
> tested-by tag to it by replying with Tested-by: name <email>.
> I've also briefly tested the set by trying to exercise those code paths.
Series applied, thanks.
^ permalink raw reply
* RE: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and port attribute
From: Parav Pandit @ 2019-07-02 18:50 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev@vger.kernel.org, Saeed Mahameed
In-Reply-To: <20190702104711.77618f6a@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Tuesday, July 2, 2019 11:17 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>; netdev@vger.kernel.org; Saeed
> Mahameed <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and
> port attribute
>
> On Tue, 2 Jul 2019 04:26:47 +0000, Parav Pandit wrote:
> > > On Mon, 1 Jul 2019 07:27:32 -0500, Parav Pandit wrote:
> > > > In an eswitch, PCI PF may have port which is normally represented
> > > > using a representor netdevice.
> > > > To have better visibility of eswitch port, its association with
> > > > PF, a representor netdevice and port number, introduce a PCI PF
> > > > port flavour and port attriute.
> > > >
> > > > When devlink port flavour is PCI PF, fill up PCI PF attributes of
> > > > the port.
> > > >
> > > > Extend port name creation using PCI PF number on best effort basis.
> > > > So that vendor drivers can skip defining their own scheme.
> > > >
> > > > $ devlink port show
> > > > pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
> > > >
> > > > Acked-by: Jiri Pirko <jiri@mellanox.com>
> > > > Signed-off-by: Parav Pandit <parav@mellanox.com> diff --git
> > > > a/include/net/devlink.h b/include/net/devlink.h index
> > > > 6625ea068d5e..8db9c0e83fb5 100644
> > > > --- a/include/net/devlink.h
> > > > +++ b/include/net/devlink.h
> > > > @@ -38,6 +38,10 @@ struct devlink {
> > > > char priv[0] __aligned(NETDEV_ALIGN); };
> > > >
> > > > +struct devlink_port_pci_pf_attrs {
> > >
> > > Why the named structure? Anonymous one should be just fine?
> > >
> > No specific reason for this patch. But named structure allows to
> > extend it more easily with code readability.
>
> I'd argue the readability - I hove to scroll up/look up the structure just to see
> it has a single member. But no big deal :)
>
Ok. :-)
> > Such as subsequently we want to add the peer_mac etc port attributes.
> > Named structure to store those attributes are helpful.
>
> It remains to be seen if peer attributes are flavour specific 🤔
> I'd imagine most port types would have some form of a peer (other than a
> network port, perhaps). But perhaps different peer attributes.
>
Few attributes may be common and few will be port specific.
So as it evolves, data structure will evolve.
Common attribute I can think of is - mac address.
> > > > diff --git a/net/core/devlink.c b/net/core/devlink.c index
> > > > 89c533778135..001f9e2c96f0 100644
> > > > --- a/net/core/devlink.c
> > > > +++ b/net/core/devlink.c
> > > > @@ -517,6 +517,11 @@ static int devlink_nl_port_attrs_put(struct
> sk_buff *msg,
> > > > return -EMSGSIZE;
> > > > if (nla_put_u32(msg, DEVLINK_ATTR_PORT_NUMBER, attrs-
> >port_number))
> > > > return -EMSGSIZE;
> > >
> > > Why would we report network port information for PF and VF port
> > > flavours?
> >
> > I didn't see any immediate need to report, at the same time didn't
> > find any reason to treat such port flavours differently than existing
> > one. It just gives a clear view of the device's eswitch. Might find it
> > useful during debugging while inspecting device internal tables..
>
> PFs and VFs ports are not tied to network ports in switchdev mode.
> You have only one network port under a devlink instance AFAIR, anyway.
>
I am not sure what do you mean by network port.
Do you intent to see a physical port that connects to physical network?
As I described in the comment of the PF and VF flavour, it is an eswitch port.
I have shown the diagram also of the eswitch in the cover letter.
Port_number doesn't have to a physical port. Flavour describe what port type is and number says what is the eswitch port number.
Hope it clarifies.
> > > > + if (devlink_port->attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_PF) {
> > > > + if (nla_put_u16(msg, DEVLINK_ATTR_PORT_PCI_PF_NUMBER,
> > > > + attrs->pci_pf.pf))
> > > > + return -EMSGSIZE;
> > > > + }
> > > > if (!attrs->split)
> > > > return 0;
> > > > if (nla_put_u32(msg, DEVLINK_ATTR_PORT_SPLIT_GROUP,
> > > > attrs->port_number))
^ permalink raw reply
* [PATCH v2 net-next] r8169: add random MAC address fallback
From: Heiner Kallweit @ 2019-07-02 18:46 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
It was reported that the GPD MicroPC is broken in a way that no valid
MAC address can be read from the network chip. The vendor driver deals
with this by assigning a random MAC address as fallback. So let's do
the same.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- fix broken commit message
---
drivers/net/ethernet/realtek/r8169_main.c | 40 +++++++++++++++--------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 450c74dc1..d6c137b7f 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -6651,13 +6651,36 @@ static int rtl_get_ether_clk(struct rtl8169_private *tp)
return rc;
}
+static void rtl_init_mac_address(struct rtl8169_private *tp)
+{
+ struct net_device *dev = tp->dev;
+ u8 *mac_addr = dev->dev_addr;
+ int rc, i;
+
+ rc = eth_platform_get_mac_address(tp_to_dev(tp), mac_addr);
+ if (!rc)
+ goto done;
+
+ rtl_read_mac_address(tp, mac_addr);
+ if (is_valid_ether_addr(mac_addr))
+ goto done;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ mac_addr[i] = RTL_R8(tp, MAC0 + i);
+ if (is_valid_ether_addr(mac_addr))
+ goto done;
+
+ eth_hw_addr_random(dev);
+ dev_warn(tp_to_dev(tp), "can't read MAC address, setting random one\n");
+done:
+ rtl_rar_set(tp, mac_addr);
+}
+
static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
- /* align to u16 for is_valid_ether_addr() */
- u8 mac_addr[ETH_ALEN] __aligned(2) = {};
struct rtl8169_private *tp;
struct net_device *dev;
- int chipset, region, i;
+ int chipset, region;
int jumbo_max, rc;
dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
@@ -6749,16 +6772,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
- /* get MAC address */
- rc = eth_platform_get_mac_address(&pdev->dev, mac_addr);
- if (rc)
- rtl_read_mac_address(tp, mac_addr);
-
- if (is_valid_ether_addr(mac_addr))
- rtl_rar_set(tp, mac_addr);
-
- for (i = 0; i < ETH_ALEN; i++)
- dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
+ rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
--
2.22.0
^ permalink raw reply related
* veth pair ping fail if one of them enslaved into a VRF
From: Zoltán Elek @ 2019-07-02 18:42 UTC (permalink / raw)
To: netdev, dsa
Hi!
I have a simple scenario, with a veth pair, IP addresses assigned from
the same subnet. They can ping eachother. But when I put one of them
into a VRF (in the example below, I put veth in-vrf into the test-vrf
VRF) the ping fails. My first question: that is the expected behavior?
And my second question: is there any way to overcome this?
Here are my test commands:
ip link add out-of-vrf type veth peer name in-vrf
ip link set dev out-of-vrf up
ip link set dev in-vrf up
ip link add test-vrf type vrf table 10
ip link set dev test-vrf up
ip -4 addr add 100.127.253.2/24 dev in-vrf
ip -4 addr add 100.127.253.1/24 dev out-of-vrf
Then ping works as expected:
ping -c1 -I 100.127.253.1 100.127.253.2
After I put the in-vrf into test-vrf, ping fails:
ip link set in-vrf vrf test-vrf up
Thanks,
Zoltan Elek,
VI1
^ permalink raw reply
* Re: [PATCH] net: core: page_pool: add user refcnt and reintroduce page_pool_destroy
From: Jesper Dangaard Brouer @ 2019-07-02 18:29 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: netdev, Ilias Apalodimas, grygorii.strashko, jakub.kicinski,
daniel, john.fastabend, ast, linux-kernel, linux-omap, brouer
In-Reply-To: <20190702152112.GG4510@khorivan>
On Tue, 2 Jul 2019 18:21:13 +0300
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> On Tue, Jul 02, 2019 at 05:10:29PM +0200, Jesper Dangaard Brouer wrote:
> >On Tue, 2 Jul 2019 17:56:13 +0300
> >Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> >
> >> On Tue, Jul 02, 2019 at 04:52:30PM +0200, Jesper Dangaard Brouer wrote:
> >> >On Tue, 2 Jul 2019 17:44:27 +0300
> >> >Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> >> >
> >> >> On Tue, Jul 02, 2019 at 04:31:39PM +0200, Jesper Dangaard Brouer wrote:
> >> >> >From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> >> >> >
> >> >> >Jesper recently removed page_pool_destroy() (from driver invocation) and
> >> >> >moved shutdown and free of page_pool into xdp_rxq_info_unreg(), in-order to
> >> >> >handle in-flight packets/pages. This created an asymmetry in drivers
> >> >> >create/destroy pairs.
> >> >> >
> >> >> >This patch add page_pool user refcnt and reintroduce page_pool_destroy.
> >> >> >This serves two purposes, (1) simplify drivers error handling as driver now
> >> >> >drivers always calls page_pool_destroy() and don't need to track if
> >> >> >xdp_rxq_info_reg_mem_model() was unsuccessful. (2) allow special cases
> >> >> >where a single RX-queue (with a single page_pool) provides packets for two
> >> >> >net_device'es, and thus needs to register the same page_pool twice with two
> >> >> >xdp_rxq_info structures.
> >> >>
> >> >> As I tend to use xdp level patch there is no more reason to mention (2) case
> >> >> here. XDP patch serves it better and can prevent not only obj deletion but also
> >> >> pool flush, so, this one patch I could better leave only for (1) case.
> >> >
> >> >I don't understand what you are saying.
> >> >
> >> >Do you approve this patch, or do you reject this patch?
> >> >
> >> It's not reject, it's proposition to use both, XDP and page pool patches,
> >> each having its goal.
> >
> >Just to be clear, if you want this patch to get accepted you have to
> >reply with your Signed-off-by (as I wrote).
> >
> >Maybe we should discuss it in another thread, about why you want two
> >solutions to the same problem.
>
> If it solves same problem I propose to reject this one and use this:
> https://lkml.org/lkml/2019/7/2/651
No, I propose using this one, and rejecting the other one.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH bpf-next] selftests: bpf: standardize to static __always_inline
From: Jiri Benc @ 2019-07-02 18:26 UTC (permalink / raw)
To: netdev, bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Song Liu, Y Song
The progs for bpf selftests use several different notations to force
function inlining. Standardize to what most of them use,
static __always_inline.
Suggested-by: Song Liu <liu.song.a23@gmail.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
tools/testing/selftests/bpf/progs/pyperf.h | 9 +++--
.../testing/selftests/bpf/progs/strobemeta.h | 36 ++++++++++---------
.../testing/selftests/bpf/progs/test_jhash.h | 3 +-
.../selftests/bpf/progs/test_seg6_loop.c | 23 ++++++------
.../selftests/bpf/progs/test_verif_scale2.c | 2 +-
5 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/pyperf.h b/tools/testing/selftests/bpf/progs/pyperf.h
index 6b0781391be5..abf6224649be 100644
--- a/tools/testing/selftests/bpf/progs/pyperf.h
+++ b/tools/testing/selftests/bpf/progs/pyperf.h
@@ -75,8 +75,7 @@ typedef struct {
void* co_name; // PyCodeObject.co_name
} FrameData;
-static inline __attribute__((__always_inline__)) void*
-get_thread_state(void* tls_base, PidData* pidData)
+static __always_inline void *get_thread_state(void *tls_base, PidData *pidData)
{
void* thread_state;
int key;
@@ -87,8 +86,8 @@ get_thread_state(void* tls_base, PidData* pidData)
return thread_state;
}
-static inline __attribute__((__always_inline__)) bool
-get_frame_data(void* frame_ptr, PidData* pidData, FrameData* frame, Symbol* symbol)
+static __always_inline bool get_frame_data(void *frame_ptr, PidData *pidData,
+ FrameData *frame, Symbol *symbol)
{
// read data from PyFrameObject
bpf_probe_read(&frame->f_back,
@@ -161,7 +160,7 @@ struct bpf_elf_map SEC("maps") stackmap = {
.max_elem = 1000,
};
-static inline __attribute__((__always_inline__)) int __on_event(struct pt_regs *ctx)
+static __always_inline int __on_event(struct pt_regs *ctx)
{
uint64_t pid_tgid = bpf_get_current_pid_tgid();
pid_t pid = (pid_t)(pid_tgid >> 32);
diff --git a/tools/testing/selftests/bpf/progs/strobemeta.h b/tools/testing/selftests/bpf/progs/strobemeta.h
index 1ff73f60a3e4..553bc3b62e89 100644
--- a/tools/testing/selftests/bpf/progs/strobemeta.h
+++ b/tools/testing/selftests/bpf/progs/strobemeta.h
@@ -266,8 +266,8 @@ struct tls_index {
uint64_t offset;
};
-static inline __attribute__((always_inline))
-void *calc_location(struct strobe_value_loc *loc, void *tls_base)
+static __always_inline void *calc_location(struct strobe_value_loc *loc,
+ void *tls_base)
{
/*
* tls_mode value is:
@@ -327,10 +327,10 @@ void *calc_location(struct strobe_value_loc *loc, void *tls_base)
: NULL;
}
-static inline __attribute__((always_inline))
-void read_int_var(struct strobemeta_cfg *cfg, size_t idx, void *tls_base,
- struct strobe_value_generic *value,
- struct strobemeta_payload *data)
+static __always_inline void read_int_var(struct strobemeta_cfg *cfg,
+ size_t idx, void *tls_base,
+ struct strobe_value_generic *value,
+ struct strobemeta_payload *data)
{
void *location = calc_location(&cfg->int_locs[idx], tls_base);
if (!location)
@@ -342,10 +342,11 @@ void read_int_var(struct strobemeta_cfg *cfg, size_t idx, void *tls_base,
data->int_vals_set_mask |= (1 << idx);
}
-static inline __attribute__((always_inline))
-uint64_t read_str_var(struct strobemeta_cfg* cfg, size_t idx, void *tls_base,
- struct strobe_value_generic *value,
- struct strobemeta_payload *data, void *payload)
+static __always_inline uint64_t read_str_var(struct strobemeta_cfg *cfg,
+ size_t idx, void *tls_base,
+ struct strobe_value_generic *value,
+ struct strobemeta_payload *data,
+ void *payload)
{
void *location;
uint32_t len;
@@ -371,10 +372,11 @@ uint64_t read_str_var(struct strobemeta_cfg* cfg, size_t idx, void *tls_base,
return len;
}
-static inline __attribute__((always_inline))
-void *read_map_var(struct strobemeta_cfg *cfg, size_t idx, void *tls_base,
- struct strobe_value_generic *value,
- struct strobemeta_payload* data, void *payload)
+static __always_inline void *read_map_var(struct strobemeta_cfg *cfg,
+ size_t idx, void *tls_base,
+ struct strobe_value_generic *value,
+ struct strobemeta_payload *data,
+ void *payload)
{
struct strobe_map_descr* descr = &data->map_descrs[idx];
struct strobe_map_raw map;
@@ -435,9 +437,9 @@ void *read_map_var(struct strobemeta_cfg *cfg, size_t idx, void *tls_base,
* read_strobe_meta returns NULL, if no metadata was read; otherwise returns
* pointer to *right after* payload ends
*/
-static inline __attribute__((always_inline))
-void *read_strobe_meta(struct task_struct* task,
- struct strobemeta_payload* data) {
+static __always_inline void *read_strobe_meta(struct task_struct *task,
+ struct strobemeta_payload *data)
+{
pid_t pid = bpf_get_current_pid_tgid() >> 32;
struct strobe_value_generic value = {0};
struct strobemeta_cfg *cfg;
diff --git a/tools/testing/selftests/bpf/progs/test_jhash.h b/tools/testing/selftests/bpf/progs/test_jhash.h
index 3d12c11a8d47..c300734d26f6 100644
--- a/tools/testing/selftests/bpf/progs/test_jhash.h
+++ b/tools/testing/selftests/bpf/progs/test_jhash.h
@@ -1,9 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2019 Facebook
+#include <features.h>
typedef unsigned int u32;
-static __attribute__((always_inline)) u32 rol32(u32 word, unsigned int shift)
+static __always_inline u32 rol32(u32 word, unsigned int shift)
{
return (word << shift) | (word >> ((-shift) & 31));
}
diff --git a/tools/testing/selftests/bpf/progs/test_seg6_loop.c b/tools/testing/selftests/bpf/progs/test_seg6_loop.c
index 463964d79f73..1dbe1d4d467e 100644
--- a/tools/testing/selftests/bpf/progs/test_seg6_loop.c
+++ b/tools/testing/selftests/bpf/progs/test_seg6_loop.c
@@ -54,7 +54,7 @@ struct sr6_tlv_t {
unsigned char value[0];
} BPF_PACKET_HEADER;
-static __attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
+static __always_inline struct ip6_srh_t *get_srh(struct __sk_buff *skb)
{
void *cursor, *data_end;
struct ip6_srh_t *srh;
@@ -88,9 +88,9 @@ static __attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff
return srh;
}
-static __attribute__((always_inline))
-int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
- uint32_t old_pad, uint32_t pad_off)
+static __always_inline int update_tlv_pad(struct __sk_buff *skb,
+ uint32_t new_pad, uint32_t old_pad,
+ uint32_t pad_off)
{
int err;
@@ -118,10 +118,11 @@ int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
return 0;
}
-static __attribute__((always_inline))
-int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
- uint32_t *tlv_off, uint32_t *pad_size,
- uint32_t *pad_off)
+static __always_inline int is_valid_tlv_boundary(struct __sk_buff *skb,
+ struct ip6_srh_t *srh,
+ uint32_t *tlv_off,
+ uint32_t *pad_size,
+ uint32_t *pad_off)
{
uint32_t srh_off, cur_off;
int offset_valid = 0;
@@ -177,9 +178,9 @@ int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
return 0;
}
-static __attribute__((always_inline))
-int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
- struct sr6_tlv_t *itlv, uint8_t tlv_size)
+static __always_inline int add_tlv(struct __sk_buff *skb,
+ struct ip6_srh_t *srh, uint32_t tlv_off,
+ struct sr6_tlv_t *itlv, uint8_t tlv_size)
{
uint32_t srh_off = (char *)srh - (char *)(long)skb->data;
uint8_t len_remaining, new_pad;
diff --git a/tools/testing/selftests/bpf/progs/test_verif_scale2.c b/tools/testing/selftests/bpf/progs/test_verif_scale2.c
index 77830693eccb..9897150ed516 100644
--- a/tools/testing/selftests/bpf/progs/test_verif_scale2.c
+++ b/tools/testing/selftests/bpf/progs/test_verif_scale2.c
@@ -2,7 +2,7 @@
// Copyright (c) 2019 Facebook
#include <linux/bpf.h>
#include "bpf_helpers.h"
-#define ATTR __attribute__((always_inline))
+#define ATTR __always_inline
#include "test_jhash.h"
SEC("scale90_inline")
--
2.18.1
^ permalink raw reply related
* -Wsometimes-uninitialized warning after 8b97b055dc9db09b48d5a9a37d847900dd00d3cc
From: Nathan Chancellor @ 2019-07-02 18:18 UTC (permalink / raw)
To: Miaoqing Pan, Kalle Valo
Cc: ath10k, linux-wireless, netdev, linux-kernel, clang-built-linux
Hi all,
After commit 8b97b055dc9d ("ath10k: fix failure to set multiple fixed
rate") in -next, clang warns:
../drivers/net/wireless/ath/ath10k/mac.c:7528:7: warning: variable 'vht_pfr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7551:20: note: uninitialized use occurs here
arvif->vht_pfr = vht_pfr;
^~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7528:3: note: remove the 'if' if its condition is always true
if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7483:12: note: initialize the variable 'vht_pfr' to silence this warning
u8 vht_pfr;
^
= '\0'
1 warning generated.
This definitely seems legitimate as the call to
ath10k_mac_can_set_bitrate_mask might fail and vht_pfr
won't be initialized. I would fix this myself but I assume
there is a sane default value for vht_pfr other than just
0 that should be used?
Please look into this when you get a chance. Thanks,
Nathan
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Re-word Kconfig entry
From: David Miller @ 2019-07-02 18:13 UTC (permalink / raw)
To: Jose.Abreu
Cc: linux-kernel, netdev, Joao.Pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <eac9ac857255993581bec265fb5ce7e3bdd20c78.1562058669.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 2 Jul 2019 11:12:10 +0200
> We support many speeds and it doesn't make much sense to list them all
> in the Kconfig. Let's just call it Multi-Gigabit.
>
> Suggested-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] hinic: remove standard netdev stats
From: David Miller @ 2019-07-02 18:12 UTC (permalink / raw)
To: xuechaojing
Cc: linux-kernel, netdev, luoshaokai, cloud.wangxiaoyun, chiqijun,
wulike1
In-Reply-To: <20190701234000.31738-1-xuechaojing@huawei.com>
From: Xue Chaojing <xuechaojing@huawei.com>
Date: Mon, 1 Jul 2019 23:40:00 +0000
> This patch removes standard netdev stats in ethtool -S.
>
> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
Applied, thanks for following up on this.
^ permalink raw reply
* [PATCH] netfilter: nf_log: Replace a seq_printf() call by seq_puts() in seq_show()
From: Markus Elfring @ 2019-07-02 18:11 UTC (permalink / raw)
To: netfilter-devel, coreteam, netdev, David S. Miller,
Florian Westphal, Jozsef Kadlecsik, Pablo Neira Ayuso
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 2 Jul 2019 20:06:30 +0200
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function “seq_puts”.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/netfilter/nf_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index 3574a212bdc2..bb25d4c794c7 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -374,7 +374,7 @@ static int seq_show(struct seq_file *s, void *v)
continue;
logger = nft_log_dereference(loggers[*pos][i]);
- seq_printf(s, "%s", logger->name);
+ seq_puts(s, logger->name);
if (i == 0 && loggers[*pos][i + 1] != NULL)
seq_puts(s, ",");
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net-next] iavf: remove unused debug function iavf_debug_d
From: David Miller @ 2019-07-02 18:06 UTC (permalink / raw)
To: yuehaibing; +Cc: jeffrey.t.kirsher, intel-wired-lan, linux-kernel, netdev
In-Reply-To: <20190702062021.41524-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 2 Jul 2019 14:20:21 +0800
> There is no caller of function iavf_debug_d() in tree since
> commit 75051ce4c5d8 ("iavf: Fix up debug print macro"),
> so it can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Jeff, please queue this up or handle however is otherwise appropriate.
Thanks.
^ permalink raw reply
* Re: [PATCH] bpf: Replace a seq_printf() call by seq_puts() in btf_enum_seq_show()
From: Yonghong Song @ 2019-07-02 18:02 UTC (permalink / raw)
To: Markus Elfring, bpf@vger.kernel.org, netdev@vger.kernel.org,
Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu
Cc: LKML, kernel-janitors@vger.kernel.org
In-Reply-To: <93898abe-9a7d-0c64-0856-094b62e07ba2@web.de>
On 7/2/19 10:13 AM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 2 Jul 2019 19:04:08 +0200
>
> A string which did not contain a data format specification should be put
> into a sequence. Thus use the corresponding function “seq_puts”.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> kernel/bpf/btf.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 546ebee39e2a..679a19968f29 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2426,9 +2426,8 @@ static void btf_enum_seq_show(const struct btf *btf, const struct btf_type *t,
>
> for (i = 0; i < nr_enums; i++) {
> if (v == enums[i].val) {
> - seq_printf(m, "%s",
> - __btf_name_by_offset(btf,
> - enums[i].name_off));
> + seq_puts(m,
> + __btf_name_by_offset(btf, enums[i].name_off));
> return;
> }
> }
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH bpf v2] selftests: bpf: fix inlines in test_lwt_seg6local
From: Y Song @ 2019-07-02 17:58 UTC (permalink / raw)
To: Jiri Benc
Cc: netdev, bpf, Alexei Starovoitov, Daniel Borkmann,
Mathieu Xhonneux, Song Liu
In-Reply-To: <bf60860191c7d4ab0f50fe3143f3d175bd6ee112.1562089104.git.jbenc@redhat.com>
On Tue, Jul 2, 2019 at 10:41 AM Jiri Benc <jbenc@redhat.com> wrote:
>
> Selftests are reporting this failure in test_lwt_seg6local.sh:
>
> + ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.o sec encap_srh dev veth2
> Error fetching program/map!
> Failed to parse eBPF program: Operation not permitted
>
> The problem is __attribute__((always_inline)) alone is not enough to prevent
> clang from inserting those functions in .text. In that case, .text is not
> marked as relocateable.
>
> See the output of objdump -h test_lwt_seg6local.o:
>
> Idx Name Size VMA LMA File off Algn
> 0 .text 00003530 0000000000000000 0000000000000000 00000040 2**3
> CONTENTS, ALLOC, LOAD, READONLY, CODE
>
> This causes the iproute bpf loader to fail in bpf_fetch_prog_sec:
> bpf_has_call_data returns true but bpf_fetch_prog_relo fails as there's no
> relocateable .text section in the file.
>
> To fix this, convert to 'static __always_inline'.
>
> v2: Use 'static __always_inline' instead of 'static inline
> __attribute__((always_inline))'
>
> Fixes: c99a84eac026 ("selftests/bpf: test for seg6local End.BPF action")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> .../testing/selftests/bpf/progs/test_lwt_seg6local.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
> index 0575751bc1bc..e2f6ed0a583d 100644
> --- a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
> +++ b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
> @@ -61,7 +61,7 @@ struct sr6_tlv_t {
> unsigned char value[0];
> } BPF_PACKET_HEADER;
>
> -__attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
> +static __always_inline struct ip6_srh_t *get_srh(struct __sk_buff *skb)
> {
> void *cursor, *data_end;
> struct ip6_srh_t *srh;
> @@ -95,7 +95,7 @@ __attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
> return srh;
> }
>
> -__attribute__((always_inline))
> +static __always_inline
> int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
> uint32_t old_pad, uint32_t pad_off)
> {
> @@ -125,7 +125,7 @@ int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
> return 0;
> }
>
> -__attribute__((always_inline))
> +static __always_inline
> int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
> uint32_t *tlv_off, uint32_t *pad_size,
> uint32_t *pad_off)
> @@ -184,7 +184,7 @@ int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
> return 0;
> }
>
> -__attribute__((always_inline))
> +static __always_inline
> int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
> struct sr6_tlv_t *itlv, uint8_t tlv_size)
> {
> @@ -228,7 +228,7 @@ int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
> return update_tlv_pad(skb, new_pad, pad_size, pad_off);
> }
>
> -__attribute__((always_inline))
> +static __always_inline
> int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
> uint32_t tlv_off)
> {
> @@ -266,7 +266,7 @@ int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
> return update_tlv_pad(skb, new_pad, pad_size, pad_off);
> }
>
> -__attribute__((always_inline))
> +static __always_inline
> int has_egr_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh)
> {
> int tlv_offset = sizeof(struct ip6_t) + sizeof(struct ip6_srh_t) +
> --
> 2.18.1
>
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/8] bpf: TCP RTT sock_ops bpf callback
From: Y Song @ 2019-07-02 17:55 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, Priyaranjan Jha, Yuchung Cheng,
Soheil Hassas Yeganeh
In-Reply-To: <20190702161403.191066-1-sdf@google.com>
On Tue, Jul 2, 2019 at 9:14 AM Stanislav Fomichev <sdf@google.com> wrote:
>
> Congestion control team would like to have a periodic callback to
> track some TCP statistics. Let's add a sock_ops callback that can be
> selectively enabled on a socket by socket basis and is executed for
> every RTT. BPF program frequency can be further controlled by calling
> bpf_ktime_get_ns and bailing out early.
>
> I run neper tcp_stream and tcp_rr tests with the sample program
> from the last patch and didn't observe any noticeable performance
> difference.
>
> v2:
> * add a comment about second accept() in selftest (Yonghong Song)
> * refer to tcp_bpf.readme in sample program (Yonghong Song)
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Priyaranjan Jha <priyarjha@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
Ack for the whole series.
Acked-by: Yonghong Song <yhs@fb.com>
>
> Stanislav Fomichev (8):
> bpf: add BPF_CGROUP_SOCK_OPS callback that is executed on every RTT
> bpf: split shared bpf_tcp_sock and bpf_sock_ops implementation
> bpf: add dsack_dups/delivered{,_ce} to bpf_tcp_sock
> bpf: add icsk_retransmits to bpf_tcp_sock
> bpf/tools: sync bpf.h
> selftests/bpf: test BPF_SOCK_OPS_RTT_CB
> samples/bpf: add sample program that periodically dumps TCP stats
> samples/bpf: fix tcp_bpf.readme detach command
>
> include/net/tcp.h | 8 +
> include/uapi/linux/bpf.h | 12 +-
> net/core/filter.c | 207 +++++++++++-----
> net/ipv4/tcp_input.c | 4 +
> samples/bpf/Makefile | 1 +
> samples/bpf/tcp_bpf.readme | 2 +-
> samples/bpf/tcp_dumpstats_kern.c | 68 ++++++
> tools/include/uapi/linux/bpf.h | 12 +-
> tools/testing/selftests/bpf/Makefile | 3 +-
> tools/testing/selftests/bpf/progs/tcp_rtt.c | 61 +++++
> tools/testing/selftests/bpf/test_tcp_rtt.c | 254 ++++++++++++++++++++
> 11 files changed, 574 insertions(+), 58 deletions(-)
> create mode 100644 samples/bpf/tcp_dumpstats_kern.c
> create mode 100644 tools/testing/selftests/bpf/progs/tcp_rtt.c
> create mode 100644 tools/testing/selftests/bpf/test_tcp_rtt.c
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
^ 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