* [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning
From: Nikolay Aleksandrov @ 2018-11-24 2:34 UTC (permalink / raw)
To: netdev; +Cc: roopa, andrew, davem, bridge, Nikolay Aleksandrov
Hi,
This set adds a new bridge option which can control learning from
link-local packets, by default learning is on to be consistent and avoid
breaking users expectations. If the new no_linklocal_learn option is
enabled then the bridge will stop learning from link-local packets.
In order to save space for future boolean options, patch 01 adds a new
bool option API that uses a bitmask to control boolean options. The
bridge is by far the largest netlink attr user and we keep adding simple
boolean options which waste nl attr ids and space. We're not directly
mapping these to the in-kernel bridge flags because some might require
more complex configuration changes (e.g. if we were to add the per port
vlan stats now, it'd require multiple checks before changing value).
Any new bool option needs to be handled by both br_boolopt_toggle and get
in order to be able to retrieve its state later. All such options are
automatically exported via netlink. The behaviour of setting such
options is consistent with netlink option handling when a missing
option is being set (silently ignored), e.g. when a newer iproute2 is used
on older kernel. All supported options are exported via bm's optmask
when dumping the new attribute.
v2: address Andrew Lunn's comments, squash a minor change into patch 01,
export all supported options via optmask when dumping, add patch 03,
pass down extack so options can return meaningful errors, add
WARN_ON on unsupported options (should not happen)
Thanks,
Nik
Nikolay Aleksandrov (3):
net: bridge: add support for user-controlled bool options
net: bridge: add no_linklocal_learn bool option
net: bridge: export supported boolopts
include/uapi/linux/if_bridge.h | 21 ++++++++++
include/uapi/linux/if_link.h | 1 +
net/bridge/br.c | 76 ++++++++++++++++++++++++++++++++++
net/bridge/br_input.c | 4 +-
net/bridge/br_netlink.c | 17 +++++++-
net/bridge/br_private.h | 9 ++++
net/bridge/br_sysfs_br.c | 22 ++++++++++
net/core/rtnetlink.c | 2 +-
8 files changed, 149 insertions(+), 3 deletions(-)
--
2.17.2
^ permalink raw reply
* [PATCH 6/8] socket: Add struct sock_timeval
From: Deepa Dinamani @ 2018-11-24 2:20 UTC (permalink / raw)
To: davem, linux-kernel; +Cc: netdev, viro, arnd, y2038
In-Reply-To: <20181124022035.17519-1-deepa.kernel@gmail.com>
The new type is meant to be used as a y2038 safe structure
to be used as part of cmsg data.
Presently the SO_TIMESTAMP socket option uses struct timeval
for timestamps. This is not y2038 safe.
Subsequent patches in the series add new y2038 safe socket
option to be used in the place of SO_TIMESTAMP_OLD.
struct sock_timeval will be used as the timestamp format
at that time.
struct sock_timeval also maintains the same layout across
32 bit and 64 bit ABIs.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
include/uapi/linux/time.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
index 04d5587f30d3..106f9398c285 100644
--- a/include/uapi/linux/time.h
+++ b/include/uapi/linux/time.h
@@ -70,6 +70,11 @@ struct __kernel_old_timeval {
};
#endif
+struct sock_timeval {
+ long long tv_sec;
+ long long tv_usec;
+};
+
/*
* The IDs of the various system clocks (for POSIX.1b interval timers):
*/
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 2/4] qede: Simplify the usage of qede-flags.
From: David Miller @ 2018-11-24 2:07 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20181123064451.3781-3-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Thu, 22 Nov 2018 22:44:49 -0800
> - edev->flags |= QEDE_FLAG_IS_VF;
> + set_bit(QEDE_FLAGS_IS_VF, &edev->flags);
...
> - edev->flags |= QEDE_TX_TIMESTAMPING_EN;
> + set_bit(QEDE_FLAGS_TX_TIMESTAMPING_EN, &edev->flags);
...
> - edev->flags &= ~QEDE_TX_TIMESTAMPING_EN;
> + clear_bit(QEDE_FLAGS_TX_TIMESTAMPING_EN, &edev->flags);
Unless these operations need to be atomic, use __set_bit and __clear_bit.
^ permalink raw reply
* Re: [PATCH] net: bridge: check for a null p->dev before dereferencing it
From: Nikolay Aleksandrov @ 2018-11-24 12:21 UTC (permalink / raw)
To: Colin King, Roopa Prabhu, David S . Miller, bridge, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20181124121551.6942-1-colin.king@canonical.com>
On 24/11/2018 14:15, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> A recent change added a null check on p->dev after p->dev was being
> dereferenced by the ns_capable check on p->dev. Fix this by performing
> the p->dev sanity check before it is dereferenced.
>
> Detected by CoverityScan, CID#751490 ("Dereference before null check")
>
> Fixes: a5f3ea54f3cc ("net: bridge: add support for raw sysfs port options")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/bridge/br_sysfs_if.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
> index 7c87a2fe5248..aab8aa17cccf 100644
> --- a/net/bridge/br_sysfs_if.c
> +++ b/net/bridge/br_sysfs_if.c
> @@ -314,15 +314,15 @@ static ssize_t brport_store(struct kobject *kobj,
> unsigned long val;
> char *endp;
>
> + if (!p->dev || !p->br)
> + return -EINVAL;
> +
> if (!ns_capable(dev_net(p->dev)->user_ns, CAP_NET_ADMIN))
> return -EPERM;
>
> if (!rtnl_trylock())
> return restart_syscall();
>
> - if (!p->dev || !p->br)
> - goto out_unlock;
> -
> if (brport_attr->store_raw) {
> char *buf_copy;
>
>
Hi,
I was contacted recently about this privately and this was my reply:
"Checking new_nbp() and del_nbp() it should not be possible to reach that code
with p->dev or p->br as NULL. The cap check code has always been there, I just
shuffled the rest of the function to obtain rtnl lock and kept it as close to
the original as possible, thus the checks remained.
In order to avoid future reports like this I'll send a cleanup once net-next
opens up.
My reasoning of why it shouldn't be possible:
- On port add new_nbp() sets both p->dev and p->br before creating kobj/sysfs
- On port del (trickier) del_nbp() calls kobject_del() before call_rcu() to destroy
the port which in turn calls sysfs_remove_dir() which uses kernfs_remove() which
deactivates (shouldn't be able to open new files) and calls kernfs_drain() to drain
current open/mmaped files in the respective dir before continuing, thus making it
impossible to open a bridge port sysfs file with p->dev and p->br equal to NULL.
"
So I think it's safe to remove those checks altogether. It'd be nice to get a second
look over my reasoning as I might be missing something in sysfs/kernfs call path.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net-next 0/5] r8169: some functional improvements
From: David Miller @ 2018-11-24 1:32 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <79f821cf-2ad4-98f0-558d-eda3148cec38@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 22 Nov 2018 21:54:36 +0100
> This series includes a few functional improvements.
Series applied.
^ permalink raw reply
* [PATCH] net: bridge: check for a null p->dev before dereferencing it
From: Colin King @ 2018-11-24 12:15 UTC (permalink / raw)
To: Roopa Prabhu, Nikolay Aleksandrov, David S . Miller, bridge,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
A recent change added a null check on p->dev after p->dev was being
dereferenced by the ns_capable check on p->dev. Fix this by performing
the p->dev sanity check before it is dereferenced.
Detected by CoverityScan, CID#751490 ("Dereference before null check")
Fixes: a5f3ea54f3cc ("net: bridge: add support for raw sysfs port options")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/bridge/br_sysfs_if.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index 7c87a2fe5248..aab8aa17cccf 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -314,15 +314,15 @@ static ssize_t brport_store(struct kobject *kobj,
unsigned long val;
char *endp;
+ if (!p->dev || !p->br)
+ return -EINVAL;
+
if (!ns_capable(dev_net(p->dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
if (!rtnl_trylock())
return restart_syscall();
- if (!p->dev || !p->br)
- goto out_unlock;
-
if (brport_attr->store_raw) {
char *buf_copy;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next 0/4] octeontx2-af: CGX LMAC link bringup and cleanups
From: David Miller @ 2018-11-24 1:23 UTC (permalink / raw)
To: linuc.decode; +Cc: netdev, Sunil.Goutham, lcherian
In-Reply-To: <20181122114837.1030-1-linuc.decode@gmail.com>
From: Linu Cherian <linuc.decode@gmail.com>
Date: Thu, 22 Nov 2018 17:18:33 +0530
> From: Linu Cherian <lcherian@marvell.com>
>
> Patch 1: Code cleanup
> Patch 2: Adds support for an unhandled hardware configuration
> Patch 3: Preparatory patch for enabling cgx lmac links
> Patch 4: Support for enabling cgx lmac links
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net/smc: patches 2018-11-22
From: David Miller @ 2018-11-24 1:20 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20181122092643.26820-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Thu, 22 Nov 2018 10:26:33 +0100
> here are more patches for SMC:
> * patches 1-3 and 7 are cleanups without functional change
> * patches 4-6 and 8 are optimizations of existing code
> * patches 9 and 10 introduce and exploit LLC message DELETE RKEY
Series applied.
^ permalink raw reply
* Re: [PATCH net] team: no need to do team_notify_peers or team_mcast_rejoin when disabling port
From: David Miller @ 2018-11-24 1:18 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, jiri, lucien.xin
In-Reply-To: <1542874528-13438-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu, 22 Nov 2018 16:15:28 +0800
> team_notify_peers() will send ARP and NA to notify peers. team_mcast_rejoin()
> will send multicast join group message to notify peers. We should do this when
> enabling/changed to a new port. But it doesn't make sense to do it when a port
> is disabled.
>
> On the other hand, when we set mcast_rejoin_count to 2, and do a failover,
> team_port_disable() will increase mcast_rejoin.count_pending to 2 and then
> team_port_enable() will increase mcast_rejoin.count_pending to 4. We will send
> 4 mcast rejoin messages at latest, which will make user confused. The same
> with notify_peers.count.
>
> Fix it by deleting team_notify_peers() and team_mcast_rejoin() in
> team_port_disable().
>
> Reported-by: Liang Li <liali@redhat.com>
> Fixes: fc423ff00df3a ("team: add peer notification")
> Fixes: 492b200efdd20 ("team: add support for sending multicast rejoins")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied.
^ permalink raw reply
* [PATCH bpf-next v2 4/4] libbpf: Document API and ABI conventions
From: Andrey Ignatov @ 2018-11-24 0:44 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, yhs, kafai, kernel-team
In-Reply-To: <cover.1543019933.git.rdna@fb.com>
Document API and ABI for libbpf: naming convention, symbol visibility,
ABI versioning.
This is just a starting point. Documentation can be significantly
extended in the future to cover more topics.
ABI versioning section touches only a few basic points with a link to
more comprehensive documentation from Ulrich Drepper. This section can
be extended in the future when there is better understanding what works
well and what not so well in libbpf development process and production
usage.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/README.rst | 139 +++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
create mode 100644 tools/lib/bpf/README.rst
diff --git a/tools/lib/bpf/README.rst b/tools/lib/bpf/README.rst
new file mode 100644
index 000000000000..2ced9e061c4b
--- /dev/null
+++ b/tools/lib/bpf/README.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+libbpf API naming convention
+============================
+
+libbpf API provides access to a few logically separated groups of
+functions and types. Every group has its own naming convention
+described here. It's recommended to follow these conventions whenever a
+new function or type is added to keep libbpf API clean and consistent.
+
+All types and functions provided by libbpf API should have one of the
+following prefixes: ``bpf_``, ``btf_``, ``libbpf_``.
+
+System call wrappers
+--------------------
+
+System call wrappers are simple wrappers for commands supported by
+sys_bpf system call. These wrappers should go to ``bpf.h`` header file
+and map one-on-one to corresponding commands.
+
+For example ``bpf_map_lookup_elem`` wraps ``BPF_MAP_LOOKUP_ELEM``
+command of sys_bpf, ``bpf_prog_attach`` wraps ``BPF_PROG_ATTACH``, etc.
+
+Objects
+-------
+
+Another class of types and functions provided by libbpf API is "objects"
+and functions to work with them. Objects are high-level abstractions
+such as BPF program or BPF map. They're represented by corresponding
+structures such as ``struct bpf_object``, ``struct bpf_program``,
+``struct bpf_map``, etc.
+
+Structures are forward declared and access to their fields should be
+provided via corresponding getters and setters rather than directly.
+
+These objects are associated with corresponding parts of ELF object that
+contains compiled BPF programs.
+
+For example ``struct bpf_object`` represents ELF object itself created
+from an ELF file or from a buffer, ``struct bpf_program`` represents a
+program in ELF object and ``struct bpf_map`` is a map.
+
+Functions that work with an object have names built from object name,
+double underscore and part that describes function purpose.
+
+For example ``bpf_object__open`` consists of the name of corresponding
+object, ``bpf_object``, double underscore and ``open`` that defines the
+purpose of the function to open ELF file and create ``bpf_object`` from
+it.
+
+Another example: ``bpf_program__load`` is named for corresponding
+object, ``bpf_program``, that is separated from other part of the name
+by double underscore.
+
+All objects and corresponding functions other than BTF related should go
+to ``libbpf.h``. BTF types and functions should go to ``btf.h``.
+
+Auxiliary functions
+-------------------
+
+Auxiliary functions and types that don't fit well in any of categories
+described above should have ``libbpf_`` prefix, e.g.
+``libbpf_get_error`` or ``libbpf_prog_type_by_name``.
+
+libbpf ABI
+==========
+
+libbpf can be both linked statically or used as DSO. To avoid possible
+conflicts with other libraries an application is linked with, all
+non-static libbpf symbols should have one of the prefixes mentioned in
+API documentation above. See API naming convention to choose the right
+name for a new symbol.
+
+Symbol visibility
+-----------------
+
+libbpf follow the model when all global symbols have visibility "hidden"
+by default and to make a symbol visible it has to be explicitly
+attributed with ``LIBBPF_API`` macro. For example:
+
+.. code-block:: c
+
+ LIBBPF_API int bpf_prog_get_fd_by_id(__u32 id);
+
+This prevents from accidentally exporting a symbol, that is not supposed
+to be a part of ABI what, in turn, improves both libbpf developer- and
+user-experiences.
+
+ABI versionning
+---------------
+
+To make future ABI extensions possible libbpf ABI is versioned.
+Versioning is implemented by ``libbpf.map`` version script that is
+passed to linker.
+
+Version name is ``LIBBPF_`` prefix + three-component numeric version,
+starting from ``0.0.1``.
+
+Every time ABI is being changed, e.g. because a new symbol is added or
+semantic of existing symbol is changed, ABI version should be bumped.
+
+For example, if current state of ``libbpf.map`` is:
+
+.. code-block::
+ LIBBPF_0.0.1 {
+ global:
+ bpf_func_a;
+ bpf_func_b;
+ local:
+ \*;
+ };
+
+, and a new symbol ``bpf_func_c`` is being introduced, then
+``libbpf.map`` should be changed like this:
+
+.. code-block::
+ LIBBPF_0.0.1 {
+ global:
+ bpf_func_a;
+ bpf_func_b;
+ local:
+ \*;
+ };
+ LIBBPF_0.0.2 {
+ global:
+ bpf_func_c;
+ } LIBBPF_0.0.1;
+
+, where new version ``LIBBPF_0.0.2`` depends on the previous
+``LIBBPF_0.0.1``.
+
+Format of version script and ways to handle ABI changes, including
+incompatible ones, described in details in [1].
+
+Links
+=====
+
+[1] https://www.akkadia.org/drepper/dsohowto.pdf
+ (Chapter 3. Maintaining APIs and ABIs).
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v2 1/4] libbpf: Name changing for btf_get_from_id
From: Andrey Ignatov @ 2018-11-24 0:44 UTC (permalink / raw)
To: netdev; +Cc: Martin KaFai Lau, ast, daniel, yhs, kernel-team, Andrey Ignatov
In-Reply-To: <cover.1543019933.git.rdna@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
s/btf_get_from_id/btf__get_from_id/ to restore the API naming convention.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/bpf/bpftool/map.c | 4 ++--
tools/bpf/bpftool/prog.c | 2 +-
tools/lib/bpf/btf.c | 2 +-
tools/lib/bpf/btf.h | 2 +-
tools/testing/selftests/bpf/test_btf.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index a1ae2a3e9fef..96be42f288f5 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -711,7 +711,7 @@ static int do_dump(int argc, char **argv)
prev_key = NULL;
- err = btf_get_from_id(info.btf_id, &btf);
+ err = btf__get_from_id(info.btf_id, &btf);
if (err) {
p_err("failed to get btf");
goto exit_free;
@@ -855,7 +855,7 @@ static int do_lookup(int argc, char **argv)
}
/* here means bpf_map_lookup_elem() succeeded */
- err = btf_get_from_id(info.btf_id, &btf);
+ err = btf__get_from_id(info.btf_id, &btf);
if (err) {
p_err("failed to get btf");
goto exit_free;
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 37b1daf19da6..521a1073d1b4 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -622,7 +622,7 @@ static int do_dump(int argc, char **argv)
goto err_free;
}
- if (info.btf_id && btf_get_from_id(info.btf_id, &btf)) {
+ if (info.btf_id && btf__get_from_id(info.btf_id, &btf)) {
p_err("failed to get btf");
goto err_free;
}
diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index 13ddc4bd24ee..eadcf8dfd295 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -415,7 +415,7 @@ const char *btf__name_by_offset(const struct btf *btf, __u32 offset)
return NULL;
}
-int btf_get_from_id(__u32 id, struct btf **btf)
+int btf__get_from_id(__u32 id, struct btf **btf)
{
struct bpf_btf_info btf_info = { 0 };
__u32 len = sizeof(btf_info);
diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
index 701ad2b6c41f..5336b2f37293 100644
--- a/tools/lib/bpf/btf.h
+++ b/tools/lib/bpf/btf.h
@@ -73,7 +73,7 @@ LIBBPF_API __s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
LIBBPF_API int btf__resolve_type(const struct btf *btf, __u32 type_id);
LIBBPF_API int btf__fd(const struct btf *btf);
LIBBPF_API const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
-LIBBPF_API int btf_get_from_id(__u32 id, struct btf **btf);
+LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
struct btf_ext *btf_ext__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
void btf_ext__free(struct btf_ext *btf_ext);
diff --git a/tools/testing/selftests/bpf/test_btf.c b/tools/testing/selftests/bpf/test_btf.c
index bcbda7037840..dff755a7940b 100644
--- a/tools/testing/selftests/bpf/test_btf.c
+++ b/tools/testing/selftests/bpf/test_btf.c
@@ -2604,7 +2604,7 @@ static int do_test_file(unsigned int test_num)
goto done;
}
- err = btf_get_from_id(info.btf_id, &btf);
+ err = btf__get_from_id(info.btf_id, &btf);
if (CHECK(err, "cannot get btf from kernel, err: %d", err))
goto done;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v2 3/4] libbpf: Verify versioned symbols
From: Andrey Ignatov @ 2018-11-24 0:44 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, yhs, kafai, kernel-team
In-Reply-To: <cover.1543019933.git.rdna@fb.com>
Since ABI versioning info is kept separately from the code it's easy to
forget to update it while adding a new API.
Add simple verification that all global symbols exported with LIBBPF_API
are versioned in libbpf.map version script.
The idea is to check that number of global symbols in libbpf-in.o, that
is the input to the linker, matches with number of unique versioned
symbols in libbpf.so, that is the output of the linker. If these numbers
don't match, it may mean some symbol was not versioned and make will
fail.
"Unique" means that if a symbol is present in more than one version of
ABI due to ABI changes, it'll be counted once.
Another option to calculate number of global symbols in the "input"
could be to count number of LIBBPF_ABI entries in C headers but it seems
to be fragile.
Example of output when a symbol is missing in version script:
...
LD libbpf-in.o
LINK libbpf.a
LINK libbpf.so
Warning: Num of global symbols in libbpf-in.o (115) does NOT match
with num of versioned symbols in libbpf.so (114). Please make sure all
LIBBPF_API symbols are versioned in libbpf.map.
make: *** [check_abi] Error 1
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/Makefile | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 22c5ffe22825..34d9c3619c96 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -147,6 +147,11 @@ BPF_IN := $(OUTPUT)libbpf-in.o
LIB_FILE := $(addprefix $(OUTPUT),$(LIB_FILE))
VERSION_SCRIPT := libbpf.map
+GLOBAL_SYM_COUNT = $(shell readelf -s $(BPF_IN) | \
+ awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {s++} END{print s}')
+VERSIONED_SYM_COUNT = $(shell readelf -s $(OUTPUT)libbpf.so | \
+ grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort -u | wc -l)
+
CMD_TARGETS = $(LIB_FILE)
CXX_TEST_TARGET = $(OUTPUT)test_libbpf
@@ -159,7 +164,7 @@ TARGETS = $(CMD_TARGETS)
all: fixdep all_cmd
-all_cmd: $(CMD_TARGETS)
+all_cmd: $(CMD_TARGETS) check
$(BPF_IN): force elfdep bpfdep
@(test -f ../../include/uapi/linux/bpf.h -a -f ../../../include/uapi/linux/bpf.h && ( \
@@ -186,6 +191,18 @@ $(OUTPUT)libbpf.a: $(BPF_IN)
$(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
$(QUIET_LINK)$(CXX) $^ -lelf -o $@
+check: check_abi
+
+check_abi: $(OUTPUT)libbpf.so
+ @if [ "$(GLOBAL_SYM_COUNT)" != "$(VERSIONED_SYM_COUNT)" ]; then \
+ echo "Warning: Num of global symbols in $(BPF_IN)" \
+ "($(GLOBAL_SYM_COUNT)) does NOT match with num of" \
+ "versioned symbols in $^ ($(VERSIONED_SYM_COUNT))." \
+ "Please make sure all LIBBPF_API symbols are" \
+ "versioned in $(VERSION_SCRIPT)." >&2; \
+ exit 1; \
+ fi
+
define do_install
if [ ! -d '$(DESTDIR_SQ)$2' ]; then \
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$2'; \
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v2 2/4] libbpf: Add version script for DSO
From: Andrey Ignatov @ 2018-11-24 0:44 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, yhs, kafai, kernel-team
In-Reply-To: <cover.1543019933.git.rdna@fb.com>
More and more projects use libbpf and one day it'll likely be packaged
and distributed as DSO and that requires ABI versioning so that both
compatible and incompatible changes to ABI can be introduced in a safe
way in the future without breaking executables dynamically linked with a
previous version of the library.
Usual way to do ABI versioning is version script for the linker. Add
such a script for libbpf. All global symbols currently exported via
LIBBPF_API macro are added to the version script libbpf.map.
The version name LIBBPF_0.0.1 is constructed from the name of the
library + version specified by $(LIBBPF_VERSION) in Makefile.
Version script does not duplicate the work done by LIBBPF_API macro, it
rather complements it. The macro is used at compile time and can be used
by compiler to do optimization that can't be done at link time, it is
purely about global symbol visibility. The version script, in turn, is
used at link time and takes care of ABI versioning. Both techniques are
described in details in [1].
Whenever ABI is changed in the future, version script should be changed
appropriately.
[1] https://www.akkadia.org/drepper/dsohowto.pdf
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/Makefile | 4 +-
tools/lib/bpf/libbpf.map | 121 +++++++++++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+), 1 deletion(-)
create mode 100644 tools/lib/bpf/libbpf.map
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 1b4a683a00fc..22c5ffe22825 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -145,6 +145,7 @@ include $(srctree)/tools/build/Makefile.include
BPF_IN := $(OUTPUT)libbpf-in.o
LIB_FILE := $(addprefix $(OUTPUT),$(LIB_FILE))
+VERSION_SCRIPT := libbpf.map
CMD_TARGETS = $(LIB_FILE)
@@ -176,7 +177,8 @@ $(BPF_IN): force elfdep bpfdep
$(Q)$(MAKE) $(build)=libbpf
$(OUTPUT)libbpf.so: $(BPF_IN)
- $(QUIET_LINK)$(CC) --shared $^ -o $@
+ $(QUIET_LINK)$(CC) --shared -Wl,--version-script=$(VERSION_SCRIPT) \
+ $^ -o $@
$(OUTPUT)libbpf.a: $(BPF_IN)
$(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
new file mode 100644
index 000000000000..4fb29f6d7a80
--- /dev/null
+++ b/tools/lib/bpf/libbpf.map
@@ -0,0 +1,121 @@
+LIBBPF_0.0.1 {
+ global:
+ bpf_btf_get_fd_by_id;
+ bpf_create_map;
+ bpf_create_map_in_map;
+ bpf_create_map_in_map_node;
+ bpf_create_map_name;
+ bpf_create_map_node;
+ bpf_create_map_xattr;
+ bpf_load_btf;
+ bpf_load_program;
+ bpf_load_program_xattr;
+ bpf_map__btf_key_type_id;
+ bpf_map__btf_value_type_id;
+ bpf_map__def;
+ bpf_map__fd;
+ bpf_map__is_offload_neutral;
+ bpf_map__name;
+ bpf_map__next;
+ bpf_map__pin;
+ bpf_map__prev;
+ bpf_map__priv;
+ bpf_map__reuse_fd;
+ bpf_map__set_ifindex;
+ bpf_map__set_inner_map_fd;
+ bpf_map__set_priv;
+ bpf_map__unpin;
+ bpf_map_delete_elem;
+ bpf_map_get_fd_by_id;
+ bpf_map_get_next_id;
+ bpf_map_get_next_key;
+ bpf_map_lookup_and_delete_elem;
+ bpf_map_lookup_elem;
+ bpf_map_update_elem;
+ bpf_obj_get;
+ bpf_obj_get_info_by_fd;
+ bpf_obj_pin;
+ bpf_object__btf_fd;
+ bpf_object__close;
+ bpf_object__find_map_by_name;
+ bpf_object__find_map_by_offset;
+ bpf_object__find_program_by_title;
+ bpf_object__kversion;
+ bpf_object__load;
+ bpf_object__name;
+ bpf_object__next;
+ bpf_object__open;
+ bpf_object__open_buffer;
+ bpf_object__open_xattr;
+ bpf_object__pin;
+ bpf_object__pin_maps;
+ bpf_object__pin_programs;
+ bpf_object__priv;
+ bpf_object__set_priv;
+ bpf_object__unload;
+ bpf_object__unpin_maps;
+ bpf_object__unpin_programs;
+ bpf_perf_event_read_simple;
+ bpf_prog_attach;
+ bpf_prog_detach;
+ bpf_prog_detach2;
+ bpf_prog_get_fd_by_id;
+ bpf_prog_get_next_id;
+ bpf_prog_load;
+ bpf_prog_load_xattr;
+ bpf_prog_query;
+ bpf_prog_test_run;
+ bpf_program__fd;
+ bpf_program__is_kprobe;
+ bpf_program__is_perf_event;
+ bpf_program__is_raw_tracepoint;
+ bpf_program__is_sched_act;
+ bpf_program__is_sched_cls;
+ bpf_program__is_socket_filter;
+ bpf_program__is_tracepoint;
+ bpf_program__is_xdp;
+ bpf_program__load;
+ bpf_program__next;
+ bpf_program__nth_fd;
+ bpf_program__pin;
+ bpf_program__pin_instance;
+ bpf_program__prev;
+ bpf_program__priv;
+ bpf_program__set_expected_attach_type;
+ bpf_program__set_ifindex;
+ bpf_program__set_kprobe;
+ bpf_program__set_perf_event;
+ bpf_program__set_prep;
+ bpf_program__set_priv;
+ bpf_program__set_raw_tracepoint;
+ bpf_program__set_sched_act;
+ bpf_program__set_sched_cls;
+ bpf_program__set_socket_filter;
+ bpf_program__set_tracepoint;
+ bpf_program__set_type;
+ bpf_program__set_xdp;
+ bpf_program__title;
+ bpf_program__unload;
+ bpf_program__unpin;
+ bpf_program__unpin_instance;
+ bpf_raw_tracepoint_open;
+ bpf_set_link_xdp_fd;
+ bpf_task_fd_query;
+ bpf_verify_program;
+ btf__fd;
+ btf__find_by_name;
+ btf__free;
+ btf__get_from_id;
+ btf__name_by_offset;
+ btf__new;
+ btf__resolve_size;
+ btf__resolve_type;
+ btf__type_by_id;
+ libbpf_attach_type_by_name;
+ libbpf_get_error;
+ libbpf_prog_type_by_name;
+ libbpf_set_print;
+ libbpf_strerror;
+ local:
+ *;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation
From: Andrey Ignatov @ 2018-11-24 0:44 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, yhs, kafai, kernel-team
This patch set adds ABI versioning and documentation to libbpf.
Patch 1 renames btf_get_from_id to btf__get_from_id to follow naming
convention.
Patch 2 adds version script and has more details on ABI versioning.
Patch 3 adds simple check that all global symbols are versioned.
Patch 4 documents a few aspects of libbpf API and ABI in dev process.
v1->v2:
* add patch from Martin KaFai Lau <kafai@fb.com> to rename btf_get_from_id;
* add documentation for libbpf API and ABI.
Andrey Ignatov (3):
libbpf: Add version script for DSO
libbpf: Verify versioned symbols
libbpf: Document API and ABI conventions
Martin KaFai Lau (1):
libbpf: Name changing for btf_get_from_id
tools/bpf/bpftool/map.c | 4 +-
tools/bpf/bpftool/prog.c | 2 +-
tools/lib/bpf/Makefile | 23 +++-
tools/lib/bpf/README.rst | 139 +++++++++++++++++++++++++
tools/lib/bpf/btf.c | 2 +-
tools/lib/bpf/btf.h | 2 +-
tools/lib/bpf/libbpf.map | 121 +++++++++++++++++++++
tools/testing/selftests/bpf/test_btf.c | 2 +-
8 files changed, 287 insertions(+), 8 deletions(-)
create mode 100644 tools/lib/bpf/README.rst
create mode 100644 tools/lib/bpf/libbpf.map
--
2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] libbpf: Add version script for DSO
From: Andrey Ignatov @ 2018-11-24 0:35 UTC (permalink / raw)
To: Alexei Starovoitov, Yonghong Song, Daniel Borkmann
Cc: netdev@vger.kernel.org, ast@kernel.org, Kernel Team
In-Reply-To: <2c7cdce3-8add-c506-5ceb-24fbdf02b8fb@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> [Thu, 2018-11-22 02:28 -0800]:
> On 11/21/2018 11:22 PM, Alexei Starovoitov wrote:
> > On 11/21/18 12:18 PM, Yonghong Song wrote:
> >> On 11/21/18 9:40 AM, Andrey Ignatov wrote:
> >>> More and more projects use libbpf and one day it'll likely be packaged
> >>> and distributed as DSO and that requires ABI versioning so that both
> >>> compatible and incompatible changes to ABI can be introduced in a safe
> >>> way in the future without breaking executables dynamically linked with a
> >>> previous version of the library.
> >>>
> >>> Usual way to do ABI versioning is version script for the linker. Add
> >>> such a script for libbpf. All global symbols currently exported via
> >>> LIBBPF_API macro are added to the version script libbpf.map.
> >>>
> >>> The version name LIBBPF_0.0.1 is constructed from the name of the
> >>> library + version specified by $(LIBBPF_VERSION) in Makefile.
> >>>
> >>> Version script does not duplicate the work done by LIBBPF_API macro, it
> >>> rather complements it. The macro is used at compile time and can be used
> >>> by compiler to do optimization that can't be done at link time, it is
> >>> purely about global symbol visibility. The version script, in turn, is
> >>> used at link time and takes care of ABI versioning. Both techniques are
> >>> described in details in [1].
> >>>
> >>> Whenever ABI is changed in the future, version script should be changed
> >>> appropriately.
> >>
> >> Maybe we should clarify the policy of how version numbers should be
> >> change? Each commit which changes default global symbol ABI? Each kernel
> >> release?
>
> +1, could you add a documentation file into tools/lib/bpf/ where we
> keep note on this process?
That makes sense. I'll add documentation.
I think it'll take time to figure out a policy to maintain ABI that
works well (like when to bump version, etc). I'll describe what is
reasonable from my point of view so that we have a starting point and we
can refine / adjust it to reality later.
> >>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.akkadia.org_drepper_dsohowto.pdf&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=3jAokpHyGuCuJ834j-tttQ&m=DaYaGCQXLC7Lqf82VhtHjSPrf6R4RdDMKrDDR2T9XPA&s=nN4Sz6re4n-pP50ICk8s0M-nu_535bblSiVPeEdGiFk&e=
> >>>
> >>> Signed-off-by: Andrey Ignatov <rdna@fb.com>
> >>> ---
> >>> tools/lib/bpf/Makefile | 4 +-
> >>> tools/lib/bpf/libbpf.map | 120 +++++++++++++++++++++++++++++++++++++++
> >>> 2 files changed, 123 insertions(+), 1 deletion(-)
> >>> create mode 100644 tools/lib/bpf/libbpf.map
> >>>
> >>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> >>> index 425b480bda75..d76c41fa2d39 100644
> >>> --- a/tools/lib/bpf/Makefile
> >>> +++ b/tools/lib/bpf/Makefile
> >>> @@ -145,6 +145,7 @@ include $(srctree)/tools/build/Makefile.include
> >>>
> >>> BPF_IN := $(OUTPUT)libbpf-in.o
> >>> LIB_FILE := $(addprefix $(OUTPUT),$(LIB_FILE))
> >>> +VERSION_SCRIPT := libbpf.map
> >>>
> >>> CMD_TARGETS = $(LIB_FILE)
> >>>
> >>> @@ -170,7 +171,8 @@ $(BPF_IN): force elfdep bpfdep
> >>> $(Q)$(MAKE) $(build)=libbpf
> >>>
> >>> $(OUTPUT)libbpf.so: $(BPF_IN)
> >>> - $(QUIET_LINK)$(CC) --shared $^ -o $@
> >>> + $(QUIET_LINK)$(CC) --shared -Wl,--version-script=$(VERSION_SCRIPT) \
> >>> + $^ -o $@
> >>>
> >>> $(OUTPUT)libbpf.a: $(BPF_IN)
> >>> $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
> >>> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> >>> new file mode 100644
> >>> index 000000000000..9fe416b68c7d
> >>> --- /dev/null
> >>> +++ b/tools/lib/bpf/libbpf.map
> >>> @@ -0,0 +1,120 @@
> >>> +LIBBPF_0.0.1 {
> >>> + global:
> >>> + bpf_btf_get_fd_by_id;
> >>
> >> Do you think we could use this opportunities to
> >> make naming more consistent? For example,
> >> bpf_btf_get_fd_by_id => btf__get_fd_by_id?
> >
> > I think this one is fine since it matches
> > bpf_[map|prog]_get_fd_by_id()
> > and it's a wrapper.
> >
> >>> + bpf_create_map;
> >>> + bpf_create_map_in_map;
> >>> + bpf_create_map_in_map_node;
> >>> + bpf_create_map_name;
> >>> + bpf_create_map_node;
> >>> + bpf_create_map_xattr;
> >>> + bpf_load_btf;
> >>> + bpf_load_program;
> >>> + bpf_load_program_xattr;
> >>> + bpf_map__btf_key_type_id;
> >>> + bpf_map__btf_value_type_id;
> >>> + bpf_map__def;
> >>> + bpf_map_delete_elem; > + bpf_map__fd;
> >>> + bpf_map_get_fd_by_id;
> >>> + bpf_map_get_next_id;
> >>> + bpf_map_get_next_key; > + bpf_map__is_offload_neutral;
> >>> + bpf_map_lookup_and_delete_elem;
> >>> + bpf_map_lookup_elem;
> >>> + bpf_map__name;
> >>> + bpf_map__next;
> >>> + bpf_map__pin;
> >>> + bpf_map__prev;
> >>> + bpf_map__priv;
> >>> + bpf_map__reuse_fd;
> >>> + bpf_map__set_ifindex;
> >>> + bpf_map__set_priv;
> >>> + bpf_map__unpin;
> >>> + bpf_map_update_elem;
> >>> + bpf_object__btf_fd;
> >>> + bpf_object__close;
> >>> + bpf_object__find_map_by_name;
> >>> + bpf_object__find_map_by_offset;
> >>> + bpf_object__find_program_by_title;
> >>> + bpf_object__kversion;
> >>> + bpf_object__load;
> >>> + bpf_object__name;
> >>> + bpf_object__next;
> >>> + bpf_object__open;
> >>> + bpf_object__open_buffer;
> >>> + bpf_object__open_xattr;
> >>> + bpf_object__pin;
> >>> + bpf_object__pin_maps;
> >>> + bpf_object__pin_programs;
> >>> + bpf_object__priv;
> >>> + bpf_object__set_priv;
> >>> + bpf_object__unload;
> >>> + bpf_object__unpin_maps;
> >>> + bpf_object__unpin_programs;
> >>> + bpf_obj_get;
> >>> + bpf_obj_get_info_by_fd;
> >>> + bpf_obj_pin;
> >>> + bpf_perf_event_read_simple;
> >>> + bpf_prog_attach;
> >>> + bpf_prog_detach;
> >>> + bpf_prog_detach2;
> >>> + bpf_prog_get_fd_by_id;
> >>> + bpf_prog_get_next_id;
> >>> + bpf_prog_load;
> >>> + bpf_prog_load_xattr;
> >>> + bpf_prog_query;
> >>> + bpf_program__fd;
> >>> + bpf_program__is_kprobe;
> >>> + bpf_program__is_perf_event;
> >>> + bpf_program__is_raw_tracepoint;
> >>> + bpf_program__is_sched_act;
> >>> + bpf_program__is_sched_cls;
> >>> + bpf_program__is_socket_filter;
> >>> + bpf_program__is_tracepoint;
> >>> + bpf_program__is_xdp;
> >>> + bpf_program__load;
> >>> + bpf_program__next;
> >>> + bpf_program__nth_fd;
> >>> + bpf_program__pin;
> >>> + bpf_program__pin_instance;
> >>> + bpf_program__prev;
> >>> + bpf_program__priv;
> >>> + bpf_program__set_expected_attach_type;
> >>> + bpf_program__set_ifindex;
> >>> + bpf_program__set_kprobe;
> >>> + bpf_program__set_perf_event;
> >>> + bpf_program__set_prep;
> >>> + bpf_program__set_priv;
> >>> + bpf_program__set_raw_tracepoint;
> >>> + bpf_program__set_sched_act;
> >>> + bpf_program__set_sched_cls;
> >>> + bpf_program__set_socket_filter;
> >>> + bpf_program__set_tracepoint;
> >>> + bpf_program__set_type;
> >>> + bpf_program__set_xdp;
> >>> + bpf_program__title;
> >>> + bpf_program__unload;
> >>> + bpf_program__unpin;
> >>> + bpf_program__unpin_instance;
> >>> + bpf_prog_test_run;
> >>> + bpf_raw_tracepoint_open;
> >>> + bpf_set_link_xdp_fd;
> >>> + bpf_task_fd_query;
> >>> + bpf_verify_program;
> >>> + btf__fd;
> >>> + btf__find_by_name;
> >>> + btf__free;
> >>> + btf_get_from_id;
> >> btf_get_from_id => btf__get_from_id?
> >
> > this one makes sense indeed. Martin, thoughts?
> >
> >>> + btf__name_by_offset;
> >>> + btf__new;
> >>> + btf__resolve_size;
> >>> + btf__resolve_type;
> >>> + btf__type_by_id;
> >>> + libbpf_attach_type_by_name;
> >>> + libbpf_get_error;
> >>> + libbpf_prog_type_by_name;
> >>> + libbpf_set_print;
> >>> + libbpf_strerror;
> >>
> >> Anything else? We have btf__, bpf_program__ prefixes with double "_"
> >> while with libbpf_, bpf_<wrapper> as single "_". Not sure whether they
> >> need change or not.
> >
> > the convention is that syscall wrappers like bpf_map_lookup_elem()
> > have single _ and map one-to-one to syscall commands.
> > Double _ is for objects. That's a coding style of perf.
> > Today btf, bpf_program, bpf_map, bpf_objects are objects.
> > libbpf_ is a prefix for auxiliary funcs.
>
> With that in mind, should we also change prototype for things like
> bpf_set_link_xdp_fd() and bpf_perf_event_read_simple()? It's not a
> syscall wrapper mapping one-to-one either.
>
> Would libbpf_ prefix be a better fit in here, or some new bpf_misc__
> prefix for everything else which is not directly related to libbpf
> internals and neither to the existing objects? (bpf_misc__ would
> probably be my slight preference fwiw.)
>
> > We need to document it in a readme file.
>
> Fully agree, this should probably go to that same document so that
> this convention is clear to everyone extending libbpf.
These both are good points.
I'll try to document API naming convetion to the extent I have context
on this and combine it with ABI documentation.
As for bpf_set_link_xdp_fd() and bpf_perf_event_read_simple() I'm not
really sure since I hardly ever use. I can rename things that we're
sure about (like Martin's s/btf_get_from_id/btf__get_from_id/ above,
that I'll include in v2).
>
> Thanks,
> Daniel
--
Andrey Ignatov
^ permalink raw reply
* Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE
From: Anshuman Khandual @ 2018-11-24 11:13 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-kernel, ocfs2-devel, linux-fbdev, dri-devel,
netdev, intel-wired-lan, linux-media, iommu, linux-rdma,
dmaengine, linux-block, sparclinux, linuxppc-dev, linux-ia64,
linux-alpha, jiangqi903, hverkuil
In-Reply-To: <20181123154415.42898a42e28a31488749738a@linux-foundation.org>
On 11/24/2018 05:14 AM, Andrew Morton wrote:
> On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> ...
>>
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc, powerpc64le etc with their default config which might
>> not have compiled tested all driver related changes. I will appreciate
>> folks giving this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
>>
>> 1. git grep "nid == -1"
>> 2. git grep "node == -1"
>> 3. git grep "nid = -1"
>> 4. git grep "node = -1"
>
> The build testing is good, but I worry that some of the affected files
> don't clearly have numa.h in their include paths, for the NUMA_NO_NODE
> definition.
>
> The first thing I looked it is arch/powerpc/include/asm/pci-bridge.h.
> Maybe it somehow manages to include numa.h via some nested include, but
> if so, is that reliable across all config combinations and as code
> evolves?
>
> So I think that the patch should have added an explicit include of
> numa.h, especially in cases where the affected file previously had no
> references to any of the things which numa.h defines.
Fair enough. Will include numa.h in those particular files.
^ permalink raw reply
* [PATCH bpf-next] bpf: align map type names formatting.
From: David Calavera @ 2018-11-23 23:58 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, netdev
Make the formatting for map_type_name array consistent.
Signed-off-by: David Calavera <david.calavera@gmail.com>
---
tools/bpf/bpftool/map.c | 46 ++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index b0ebbed7d1a6..cbd3080e72c7 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -52,30 +52,30 @@
#include "main.h"
static const char * const map_type_name[] = {
- [BPF_MAP_TYPE_UNSPEC] = "unspec",
- [BPF_MAP_TYPE_HASH] = "hash",
- [BPF_MAP_TYPE_ARRAY] = "array",
- [BPF_MAP_TYPE_PROG_ARRAY] = "prog_array",
- [BPF_MAP_TYPE_PERF_EVENT_ARRAY] = "perf_event_array",
- [BPF_MAP_TYPE_PERCPU_HASH] = "percpu_hash",
- [BPF_MAP_TYPE_PERCPU_ARRAY] = "percpu_array",
- [BPF_MAP_TYPE_STACK_TRACE] = "stack_trace",
- [BPF_MAP_TYPE_CGROUP_ARRAY] = "cgroup_array",
- [BPF_MAP_TYPE_LRU_HASH] = "lru_hash",
- [BPF_MAP_TYPE_LRU_PERCPU_HASH] = "lru_percpu_hash",
- [BPF_MAP_TYPE_LPM_TRIE] = "lpm_trie",
- [BPF_MAP_TYPE_ARRAY_OF_MAPS] = "array_of_maps",
- [BPF_MAP_TYPE_HASH_OF_MAPS] = "hash_of_maps",
- [BPF_MAP_TYPE_DEVMAP] = "devmap",
- [BPF_MAP_TYPE_SOCKMAP] = "sockmap",
- [BPF_MAP_TYPE_CPUMAP] = "cpumap",
- [BPF_MAP_TYPE_XSKMAP] = "xskmap",
- [BPF_MAP_TYPE_SOCKHASH] = "sockhash",
- [BPF_MAP_TYPE_CGROUP_STORAGE] = "cgroup_storage",
- [BPF_MAP_TYPE_REUSEPORT_SOCKARRAY] = "reuseport_sockarray",
+ [BPF_MAP_TYPE_UNSPEC] = "unspec",
+ [BPF_MAP_TYPE_HASH] = "hash",
+ [BPF_MAP_TYPE_ARRAY] = "array",
+ [BPF_MAP_TYPE_PROG_ARRAY] = "prog_array",
+ [BPF_MAP_TYPE_PERF_EVENT_ARRAY] = "perf_event_array",
+ [BPF_MAP_TYPE_PERCPU_HASH] = "percpu_hash",
+ [BPF_MAP_TYPE_PERCPU_ARRAY] = "percpu_array",
+ [BPF_MAP_TYPE_STACK_TRACE] = "stack_trace",
+ [BPF_MAP_TYPE_CGROUP_ARRAY] = "cgroup_array",
+ [BPF_MAP_TYPE_LRU_HASH] = "lru_hash",
+ [BPF_MAP_TYPE_LRU_PERCPU_HASH] = "lru_percpu_hash",
+ [BPF_MAP_TYPE_LPM_TRIE] = "lpm_trie",
+ [BPF_MAP_TYPE_ARRAY_OF_MAPS] = "array_of_maps",
+ [BPF_MAP_TYPE_HASH_OF_MAPS] = "hash_of_maps",
+ [BPF_MAP_TYPE_DEVMAP] = "devmap",
+ [BPF_MAP_TYPE_SOCKMAP] = "sockmap",
+ [BPF_MAP_TYPE_CPUMAP] = "cpumap",
+ [BPF_MAP_TYPE_XSKMAP] = "xskmap",
+ [BPF_MAP_TYPE_SOCKHASH] = "sockhash",
+ [BPF_MAP_TYPE_CGROUP_STORAGE] = "cgroup_storage",
+ [BPF_MAP_TYPE_REUSEPORT_SOCKARRAY] = "reuseport_sockarray",
[BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE] = "percpu_cgroup_storage",
- [BPF_MAP_TYPE_QUEUE] = "queue",
- [BPF_MAP_TYPE_STACK] = "stack",
+ [BPF_MAP_TYPE_QUEUE] = "queue",
+ [BPF_MAP_TYPE_STACK] = "stack",
};
static bool map_is_per_cpu(__u32 type)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] cxgb4: remove set but not used variables 'multitrc, speed'
From: YueHaibing @ 2018-11-24 10:36 UTC (permalink / raw)
To: davem, ganeshgr; +Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:5883:6:
warning: variable 'multitrc' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:8585:32:
warning: variable 'speed' set but not used [-Wunused-but-set-variable]
'multitrc' never used since introduction in
commit 8e3d04fd7d70 ("cxgb4: Add MPS tracing support")
'speed' never used since introduction in
commit c3168cabe1af ("cxgb4/cxgbvf: Handle 32-bit fw port capabilities")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 4cb261d..e8c3429 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -5880,7 +5880,6 @@ int t4_set_trace_filter(struct adapter *adap, const struct trace_params *tp,
{
int i, ofst = idx * 4;
u32 data_reg, mask_reg, cfg;
- u32 multitrc = TRCMULTIFILTER_F;
if (!enable) {
t4_write_reg(adap, MPS_TRC_FILTER_MATCH_CTL_A_A + ofst, 0);
@@ -5900,7 +5899,6 @@ int t4_set_trace_filter(struct adapter *adap, const struct trace_params *tp,
* maximum packet capture size of 9600 bytes is recommended.
* Also in this mode, only trace0 can be enabled and running.
*/
- multitrc = 0;
if (tp->snap_len > 9600 || idx)
return -EINVAL;
}
@@ -8606,7 +8604,7 @@ int t4_get_link_params(struct port_info *pi, unsigned int *link_okp,
{
unsigned int fw_caps = pi->adapter->params.fw_caps_support;
struct fw_port_cmd port_cmd;
- unsigned int action, link_ok, speed, mtu;
+ unsigned int action, link_ok, mtu;
fw_port_cap32_t linkattr;
int ret;
@@ -8640,7 +8638,6 @@ int t4_get_link_params(struct port_info *pi, unsigned int *link_okp,
mtu = FW_PORT_CMD_MTU32_G(
be32_to_cpu(port_cmd.u.info32.auxlinfo32_mtu32));
}
- speed = fwcap_to_speed(linkattr);
*link_okp = link_ok;
*speedp = fwcap_to_speed(linkattr);
--
2.7.0
^ permalink raw reply related
* [PATCH] tags: Fix DEFINE_PER_CPU expansion
From: Rustam Kovhaev @ 2018-11-23 23:48 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, Rustam Kovhaev
Building tags produces warning:
ctags: Warning: kernel/bpf/local_storage.c:10: null expansion of name pattern "\1"
Let's use the same fix as in commit <25528213fe9f75f4>, even though it
violates the usual code style.
Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
---
kernel/bpf/local_storage.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
index c97a8f968638..9e94b1cc6cf2 100644
--- a/kernel/bpf/local_storage.c
+++ b/kernel/bpf/local_storage.c
@@ -7,8 +7,7 @@
#include <linux/rbtree.h>
#include <linux/slab.h>
-DEFINE_PER_CPU(struct bpf_cgroup_storage*,
- bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
+DEFINE_PER_CPU(struct bpf_cgroup_storage*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
#ifdef CONFIG_CGROUP_BPF
--
2.19.1
^ permalink raw reply related
* Re: [RFC v2 00/19] batman-adv: netlink restructuring, part 2
From: Jiri Pirko @ 2018-11-24 10:23 UTC (permalink / raw)
To: Sven Eckelmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <2704410.j1Xe82xyVQ@sven-edge>
Sat, Nov 24, 2018 at 10:44:18AM CET, sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org wrote:
>On Samstag, 24. November 2018 10:29:55 CET Jiri Pirko wrote:
>[...]
>> This looks great. Nice job!
>>
>> Do you have a userspace app to communicate with this? Would be nice to
>> play with it or at least to see examples of usage.
>
>I have only published the the mcast parsing portion [1] because the
>application would first need to get a more complex compatibility layer to
>support netlink and sysfs at the same time.
>
>And I will definitely not spend the time in implementing this kind of stuff
>when the kernel part is potentially rejected again. But you can get some infos
>about functionality of the sysfs implementation in the manpage [2].
Okay.
>
>Kind regards,
> Sven
>
>[1] https://patchwork.open-mesh.org/patch/17659/
>[2] https://manpages.debian.org/stretch/batctl/batctl.8.en.html
^ permalink raw reply
* [PATCH net-next] net: aquantia: return 'err' if set MPI_DEINIT state fails
From: YueHaibing @ 2018-11-24 10:16 UTC (permalink / raw)
To: davem, igor.russkikh, nikita.danilov, yana.esina
Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:260:7:
warning: variable 'err' set but not used [-Wunused-but-set-variable]
'err' should be returned while set MPI_DEINIT state fails
in hw_atl_utils_soft_reset.
Fixes: cce96d1883da ("net: aquantia: Regression on reset with 1.x firmware")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 1af6606..9b74a31 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -263,6 +263,8 @@ int hw_atl_utils_soft_reset(struct aq_hw_s *self)
AQ_HW_WAIT_FOR((aq_hw_read_reg(self, HW_ATL_MPI_STATE_ADR) &
HW_ATL_MPI_STATE_MSK) == MPI_DEINIT,
10, 1000U);
+ if (err)
+ return err;
}
if (self->rbl_enabled)
--
2.7.0
^ permalink raw reply related
* [PATCH] net: gemini: Fix copy/paste error
From: Linus Walleij @ 2018-11-23 23:16 UTC (permalink / raw)
To: netdev, David S . Miller; +Cc: Hans Ulli Kroll, Andreas Fiedler, Linus Walleij
From: Andreas Fiedler <andreas.fiedler@gmx.net>
The TX stats should be started with the tx_stats_syncp,
there seems to be a copy/paste error in the driver.
Signed-off-by: Andreas Fiedler <andreas.fiedler@gmx.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/net/ethernet/cortina/gemini.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index ceec467f590d..949103db8a8a 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -660,7 +660,7 @@ static void gmac_clean_txq(struct net_device *netdev, struct gmac_txq *txq,
u64_stats_update_begin(&port->tx_stats_syncp);
port->tx_frag_stats[nfrags]++;
- u64_stats_update_end(&port->ir_stats_syncp);
+ u64_stats_update_end(&port->tx_stats_syncp);
}
}
--
2.19.1
^ permalink raw reply related
* Re: [RFC v2 00/19] batman-adv: netlink restructuring, part 2
From: Sven Eckelmann @ 2018-11-24 9:44 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20181124092955.GA2511-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On Samstag, 24. November 2018 10:29:55 CET Jiri Pirko wrote:
[...]
> This looks great. Nice job!
>
> Do you have a userspace app to communicate with this? Would be nice to
> play with it or at least to see examples of usage.
I have only published the the mcast parsing portion [1] because the
application would first need to get a more complex compatibility layer to
support netlink and sysfs at the same time.
And I will definitely not spend the time in implementing this kind of stuff
when the kernel part is potentially rejected again. But you can get some infos
about functionality of the sysfs implementation in the manpage [2].
Kind regards,
Sven
[1] https://patchwork.open-mesh.org/patch/17659/
[2] https://manpages.debian.org/stretch/batctl/batctl.8.en.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC v2 00/19] batman-adv: netlink restructuring, part 2
From: Jiri Pirko @ 2018-11-24 9:29 UTC (permalink / raw)
To: Sven Eckelmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20181123161359.13342-1-sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Fri, Nov 23, 2018 at 05:13:40PM CET, sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org wrote:
>Hi,
>
>Jiri Pirko called the batman-adv configuration interface a while back "a
>huge mistake" [1] and suggested genl as alternative. The first
>reimplementation [2] (based on the team/devlink design) was rejected. This
>second implementation is now using a nl80211-like design. The objects
>which can now be modified/queried are:
>
>* mesh/soft-interface (BATADV_CMD_GET_MESH/BATADV_CMD_SET_MESH)
>* slave/hard-interface (BATADV_CMD_GET_HARDIF/BATADV_CMD_SET_HARDIF)
>* vlan (BATADV_CMD_GET_VLAN/BATADV_CMD_SET_VLAN)
>
>Such a set messages automatically triggers a *_SET_* "reply" via the config
>multicast group. The same behavior was also added to the sysfs interface.
>
>Luckily, Jiri Pirko told us that he will have a look at patches. I would
>also like to ask the other developers to check whether their configuration
>values are represented correctly. And please also check whether the current
>implementation might collide with some other features which you might have
>in your pipeline.
>
>v2:
>* rewrite everything in a more nl80211-like message/attribute format.
>
>Kind regards,
> Sven
This looks great. Nice job!
Do you have a userspace app to communicate with this? Would be nice to
play with it or at least to see examples of usage.
Thanks!
^ permalink raw reply
* Re: [PATCH net] packet: copy user buffers before orphan or clone
From: Willem de Bruijn @ 2018-11-23 22:32 UTC (permalink / raw)
To: David Miller
Cc: Network Development, johann.baudy, Anand H. Krishnan,
Willem de Bruijn
In-Reply-To: <20181123.110906.251155276613004036.davem@davemloft.net>
On Fri, Nov 23, 2018 at 2:09 PM David Miller <davem@davemloft.net> wrote:
>
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Tue, 20 Nov 2018 13:00:18 -0500
>
> > From: Willem de Bruijn <willemb@google.com>
> >
> > tpacket_snd sends packets with user pages linked into skb frags. It
> > notifies that pages can be reused when the skb is released by setting
> > skb->destructor to tpacket_destruct_skb.
> >
> > This can cause data corruption if the skb is orphaned (e.g., on
> > transmit through veth) or cloned (e.g., on mirror to another psock).
> >
> > Create a kernel-private copy of data in these cases, same as tun/tap
> > zerocopy transmission. Reuse that infrastructure: mark the skb as
> > SKBTX_ZEROCOPY_FRAG, which will trigger copy in skb_orphan_frags(_rx).
> >
> > Unlike other zerocopy packets, do not set shinfo destructor_arg to
> > struct ubuf_info. tpacket_destruct_skb already uses that ptr to notify
> > when the original skb is released and a timestamp is recorded. Do not
> > change this timestamp behavior. The ubuf_info->callback is not needed
> > anyway, as no zerocopy notification is expected.
> >
> > Mark destructor_arg as not-a-uarg by setting the lower bit to 1. The
> > resulting value is not a valid ubuf_info pointer, nor a valid
> > tpacket_snd frame address. Add skb_zcopy_.._nouarg helpers for this.
> >
> > The fix relies on features introduced in commit 52267790ef52 ("sock:
> > add MSG_ZEROCOPY"), so can be backported as is only to 4.14.
> >
> > Tested with from `./in_netns.sh ./txring_overwrite` from
> > http://github.com/wdebruij/kerneltools/tests
> >
> > Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
> > Reported-by: Anand H. Krishnan <anandhkrishnan@gmail.com>
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> Applied, and queued up for -stable. Thanks for the backporting notes.
>
> Any chance those tests from your kerneltools repo can make their way
> into selftests?
Absolutely. I'll send it to net-next once it has the fix.
^ 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