* Re: [PATCH bpf-next 6/9] selftests/bpf: abstract away test log output
From: Andrii Nakryiko @ 2019-07-26 21:51 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <20190726213104.GD24397@mini-arch>
On Fri, Jul 26, 2019 at 2:31 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/26, Andrii Nakryiko wrote:
> > This patch changes how test output is printed out. By default, if test
> > had no errors, the only output will be a single line with test number,
> > name, and verdict at the end, e.g.:
> >
> > #31 xdp:OK
> >
> > If test had any errors, all log output captured during test execution
> > will be output after test completes.
> >
> > It's possible to force output of log with `-v` (`--verbose`) option, in
> > which case output won't be buffered and will be output immediately.
> >
> > To support this, individual tests are required to use helper methods for
> > logging: `test__printf()` and `test__vprintf()`.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > .../selftests/bpf/prog_tests/bpf_obj_id.c | 6 +-
> > .../bpf/prog_tests/bpf_verif_scale.c | 31 ++--
> > .../bpf/prog_tests/get_stack_raw_tp.c | 4 +-
> > .../selftests/bpf/prog_tests/l4lb_all.c | 2 +-
> > .../selftests/bpf/prog_tests/map_lock.c | 10 +-
> > .../selftests/bpf/prog_tests/send_signal.c | 8 +-
> > .../selftests/bpf/prog_tests/spinlock.c | 2 +-
> > .../bpf/prog_tests/stacktrace_build_id.c | 4 +-
> > .../bpf/prog_tests/stacktrace_build_id_nmi.c | 4 +-
> > .../selftests/bpf/prog_tests/xdp_noinline.c | 3 +-
> > tools/testing/selftests/bpf/test_progs.c | 135 +++++++++++++-----
> > tools/testing/selftests/bpf/test_progs.h | 37 ++++-
> > 12 files changed, 173 insertions(+), 73 deletions(-)
> >
[...]
> > error_cnt++;
> > - printf("test_l4lb:FAIL:stats %lld %lld\n", bytes, pkts);
> > + test__printf("test_l4lb:FAIL:stats %lld %lld\n", bytes, pkts);
> #define printf(...) test__printf(...) in tests.h?
>
> A bit ugly, but no need to retrain everyone to use new printf wrappers.
I try to reduce amount of magic and surprising things, not add new
ones :) I also led by example and converted all current instances of
printf usage to test__printf, so anyone new will just copy/paste good
example, hopefully. Even if not, this non-buffered output will be
immediately obvious to anyone who just runs `sudo ./test_progs`. And
author of new test with this problem should hopefully be the first and
the only one to catch and fix this.
>
> > }
> > out:
> > bpf_object__close(obj);
> > diff --git a/tools/testing/selftests/bpf/prog_tests/map_lock.c b/tools/testing/selftests/bpf/prog_tests/map_lock.c
> > index ee99368c595c..2e78217ed3fd 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/map_lock.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/map_lock.c
> > @@ -9,12 +9,12 @@ static void *parallel_map_access(void *arg)
[...]
^ permalink raw reply
* Re: [PATCH bpf-next 4/9] libbpf: add libbpf_swap_print to get previous print func
From: Andrii Nakryiko @ 2019-07-26 21:47 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <20190726212818.GC24397@mini-arch>
On Fri, Jul 26, 2019 at 2:28 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/26, Andrii Nakryiko wrote:
> > libbpf_swap_print allows to restore previously set print function.
> > This is useful when running many independent test with one default print
> > function, but overriding log verbosity for particular subset of tests.
> Can we change the return type of libbpf_set_print instead and return
> the old function from it? Will it break ABI?
Yeah, thought about that, but I wasn't sure about ABI breakage. It
seems like it shouldn't, so I'll just change libbpf_set_print
signature instead.
>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 8 ++++++++
> > tools/lib/bpf/libbpf.h | 1 +
> > tools/lib/bpf/libbpf.map | 5 +++++
> > 3 files changed, 14 insertions(+)
> >
[...]
^ permalink raw reply
* Re: [PATCH bpf-next 3/9] selftests/bpf: add test selectors by number and name to test_progs
From: Andrii Nakryiko @ 2019-07-26 21:45 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <20190726212547.GB24397@mini-arch>
On Fri, Jul 26, 2019 at 2:25 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/26, Andrii Nakryiko wrote:
> > Add ability to specify either test number or test name substring to
> > narrow down a set of test to run.
> >
> > Usage:
> > sudo ./test_progs -n 1
> > sudo ./test_progs -t attach_probe
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/testing/selftests/bpf/test_progs.c | 43 +++++++++++++++++++++---
> > 1 file changed, 39 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> > index eea88ba59225..6e04b9f83777 100644
> > --- a/tools/testing/selftests/bpf/test_progs.c
> > +++ b/tools/testing/selftests/bpf/test_progs.c
> > @@ -4,6 +4,7 @@
[...]
> >
> > static error_t parse_arg(int key, char *arg, struct argp_state *state)
> > {
> > struct test_env *env = state->input;
> >
> > switch (key) {
> [..]
> > + case ARG_TEST_NUM: {
> > + int test_num;
> > +
> > + errno = 0;
> > + test_num = strtol(arg, NULL, 10);
> > + if (errno)
> > + return -errno;
> > + env->test_num_selector = test_num;
> > + break;
> > + }
> Do you think it's really useful? I agree about running by name (I
Special request from Alexei :) But in one of the follow up patches, I
extended this to allow to specify arbitrary subset of tests, e.g.:
1,2,5-10,7-8. So in that regard, it's more powerful than selecting by
name and gives you ultimate freedom.
> usually used grep -v in the Makefile :-), but I'm not sure about running
> by number.
>
> Or is the idea is that you can just copy-paste this number from the
> test_progs output to rerun the tests? In this case, why not copy-paste
> the name instead?
Both were simple to support, I didn't want to dictate one right way to
do this :)
>
> > + case ARG_TEST_NAME:
> > + env->test_name_selector = arg;
> > + break;
> > case ARG_VERIFIER_STATS:
> > env->verifier_stats = true;
> > break;
> > @@ -223,7 +248,7 @@ int main(int argc, char **argv)
> > .parser = parse_arg,
> > .doc = argp_program_doc,
> > };
> > - const struct prog_test_def *def;
> > + struct prog_test_def *test;
> > int err, i;
> >
> > err = argp_parse(&argp, argc, argv, 0, NULL, &env);
> > @@ -237,8 +262,18 @@ int main(int argc, char **argv)
> > verifier_stats = env.verifier_stats;
> >
> > for (i = 0; i < ARRAY_SIZE(prog_test_defs); i++) {
> > - def = &prog_test_defs[i];
> > - def->run_test();
> > + test = &prog_test_defs[i];
> > +
> > + test->test_num = i + 1;
> > +
> > + if (env.test_num_selector >= 0 &&
> > + test->test_num != env.test_num_selector)
> > + continue;
> > + if (env.test_name_selector &&
> > + !strstr(test->test_name, env.test_name_selector))
> > + continue;
> > +
> > + test->run_test();
> > }
> >
> > printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH bpf-next 1/9] selftests/bpf: prevent headers to be compiled as C code
From: Andrii Nakryiko @ 2019-07-26 21:42 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <20190726212152.GA24397@mini-arch>
On Fri, Jul 26, 2019 at 2:21 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/26, Andrii Nakryiko wrote:
> > Apprently listing header as a normal dependency for a binary output
> > makes it go through compilation as if it was C code. This currently
> > works without a problem, but in subsequent commits causes problems for
> > differently generated test.h for test_progs. Marking those headers as
> > order-only dependency solves the issue.
> Are you sure it will not result in a situation where
> test_progs/test_maps is not regenerated if tests.h is updated.
>
> If I read the following doc correctly, order deps make sense for
> directories only:
> https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
>
> Can you maybe double check it with:
> * make
> * add new prog_tests/test_something.c
> * make
> to see if the binary is regenerated with test_something.c?
Yeah, tested that, it triggers test_progs rebuild.
Ordering is still preserved, because test.h is dependency of
test_progs.c, which is dependency of test_progs binary, so that's why
it works.
As to why .h file is compiled as C file, I have no idea and ideally
that should be fixed somehow.
I also started with just removing header as dependency completely
(because it's indirect dependency of test_progs.c), but that broke the
build logic. Dunno, too much magic... This works, tested many-many
times, so I was satisfied enough :)
>
> Maybe fix the problem of header compilation by having '#ifndef
> DECLARE_TEST #define DECLARE_TEST() #endif' in tests.h instead?
That's ugly, I'd like to avoid doing that.
>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/testing/selftests/bpf/Makefile | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> > index 11c9c62c3362..bb66cc4a7f34 100644
> > --- a/tools/testing/selftests/bpf/Makefile
> > +++ b/tools/testing/selftests/bpf/Makefile
> > @@ -235,7 +235,7 @@ PROG_TESTS_H := $(PROG_TESTS_DIR)/tests.h
> > PROG_TESTS_FILES := $(wildcard prog_tests/*.c)
> > test_progs.c: $(PROG_TESTS_H)
> > $(OUTPUT)/test_progs: CFLAGS += $(TEST_PROGS_CFLAGS)
> > -$(OUTPUT)/test_progs: test_progs.c $(PROG_TESTS_H) $(PROG_TESTS_FILES)
> > +$(OUTPUT)/test_progs: test_progs.c $(PROG_TESTS_FILES) | $(PROG_TESTS_H)
> > $(PROG_TESTS_H): $(PROG_TESTS_FILES) | $(PROG_TESTS_DIR)
> > $(shell ( cd prog_tests/; \
> > echo '/* Generated header, do not edit */'; \
> > @@ -256,7 +256,7 @@ MAP_TESTS_H := $(MAP_TESTS_DIR)/tests.h
> > MAP_TESTS_FILES := $(wildcard map_tests/*.c)
> > test_maps.c: $(MAP_TESTS_H)
> > $(OUTPUT)/test_maps: CFLAGS += $(TEST_MAPS_CFLAGS)
> > -$(OUTPUT)/test_maps: test_maps.c $(MAP_TESTS_H) $(MAP_TESTS_FILES)
> > +$(OUTPUT)/test_maps: test_maps.c $(MAP_TESTS_FILES) | $(MAP_TESTS_H)
> > $(MAP_TESTS_H): $(MAP_TESTS_FILES) | $(MAP_TESTS_DIR)
> > $(shell ( cd map_tests/; \
> > echo '/* Generated header, do not edit */'; \
> > @@ -277,7 +277,7 @@ VERIFIER_TESTS_H := $(VERIFIER_TESTS_DIR)/tests.h
> > VERIFIER_TEST_FILES := $(wildcard verifier/*.c)
> > test_verifier.c: $(VERIFIER_TESTS_H)
> > $(OUTPUT)/test_verifier: CFLAGS += $(TEST_VERIFIER_CFLAGS)
> > -$(OUTPUT)/test_verifier: test_verifier.c $(VERIFIER_TESTS_H)
> > +$(OUTPUT)/test_verifier: test_verifier.c | $(VERIFIER_TEST_FILES) $(VERIFIER_TESTS_H)
> > $(VERIFIER_TESTS_H): $(VERIFIER_TEST_FILES) | $(VERIFIER_TESTS_DIR)
> > $(shell ( cd verifier/; \
> > echo '/* Generated header, do not edit */'; \
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [net 7/9] net/mlx5e: kTLS, Call WARN_ONCE on netdev mismatch
From: Saeed Mahameed @ 2019-07-26 21:41 UTC (permalink / raw)
To: jakub.kicinski@netronome.com
Cc: davem@davemloft.net, netdev@vger.kernel.org, Tariq Toukan
In-Reply-To: <20190725134950.74733e62@cakuba.netronome.com>
On Thu, 2019-07-25 at 13:49 -0700, Jakub Kicinski wrote:
> On Thu, 25 Jul 2019 20:36:48 +0000, Saeed Mahameed wrote:
> > From: Tariq Toukan <tariqt@mellanox.com>
> >
> > A netdev mismatch in the processed TLS SKB should not occur,
> > and indicates a kernel bug.
> > Add WARN_ONCE to spot such cases.
> >
> > Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
> > Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> > index ea032f54197e..3766545ce259 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> > @@ -412,7 +412,7 @@ struct sk_buff *mlx5e_ktls_handle_tx_skb(struct
> > net_device *netdev,
> > goto out;
> >
> > tls_ctx = tls_get_ctx(skb->sk);
> > - if (unlikely(tls_ctx->netdev != netdev))
> > + if (unlikely(WARN_ON_ONCE(tls_ctx->netdev != netdev)))
>
> Ah, nit: the unlikely is probably unnecessary but that's no big deal.
>
> #define WARN_ON_ONCE(condition) ({ \
> static int __warned; \
> int __ret_warn_once = !!(condition); \
> \
> if (unlikely(__ret_warn_once && !__warned)) { \
> __warned = true; \
> WARN_ON(1); \
> } \
> unlikely(__ret_warn_once); \
> })
>
indeed, i see Dave already accepted this, will fix in net-next.
Thanks Jakub !
^ permalink raw reply
* Re: [PATCH] sis900: add support for ethtool's EEPROM dump
From: Saeed Mahameed @ 2019-07-26 21:39 UTC (permalink / raw)
To: venza@brownhat.org, netdev@vger.kernel.org,
sergej.benilov@googlemail.com, andrew@lunn.ch
In-Reply-To: <20190725194806.17964-1-sergej.benilov@googlemail.com>
On Thu, 2019-07-25 at 21:48 +0200, Sergej Benilov wrote:
> Implement ethtool's EEPROM dump command (ethtool -e|--eeprom-dump).
>
> Thx to Andrew Lunn for comments.
>
> Signed-off-by: Sergej Benilov <sergej.benilov@googlemail.com>
> ---
> drivers/net/ethernet/sis/sis900.c | 68
> +++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/net/ethernet/sis/sis900.c
> b/drivers/net/ethernet/sis/sis900.c
> index 6e07f5ebacfc..85eaccbbbac1 100644
> --- a/drivers/net/ethernet/sis/sis900.c
> +++ b/drivers/net/ethernet/sis/sis900.c
> @@ -191,6 +191,8 @@ struct sis900_private {
> unsigned int tx_full; /* The Tx queue is full. */
> u8 host_bridge_rev;
> u8 chipset_rev;
> + /* EEPROM data */
> + int eeprom_size;
> };
>
> MODULE_AUTHOR("Jim Huang <cmhuang@sis.com.tw>, Ollie Lho <
> ollie@sis.com.tw>");
> @@ -475,6 +477,8 @@ static int sis900_probe(struct pci_dev *pci_dev,
> sis_priv->pci_dev = pci_dev;
> spin_lock_init(&sis_priv->lock);
>
> + sis_priv->eeprom_size = 24;
> +
this value isn't changing across this patch,
why do you need to store a constant value in private data ?
Just make a #define ..
> pci_set_drvdata(pci_dev, net_dev);
>
> ring_space = pci_alloc_consistent(pci_dev, TX_TOTAL_SIZE,
> &ring_dma);
> @@ -2122,6 +2126,68 @@ static void sis900_get_wol(struct net_device
> *net_dev, struct ethtool_wolinfo *w
> wol->supported = (WAKE_PHY | WAKE_MAGIC);
> }
>
> +static int sis900_get_eeprom_len(struct net_device *dev)
> +{
> + struct sis900_private *sis_priv = netdev_priv(dev);
> +
> + return sis_priv->eeprom_size;
> +}
> +
> +static int sis900_read_eeprom(struct net_device *net_dev, u8 *buf)
> +{
> + struct sis900_private *sis_priv = netdev_priv(net_dev);
> + void __iomem *ioaddr = sis_priv->ioaddr;
> + int wait, ret = -EAGAIN;
> + u16 signature;
> + u16 *ebuf = (u16 *)buf;
reverse xmas tree.
> + int i;
> +
> + if (sis_priv->chipset_rev == SIS96x_900_REV) {
> + sw32(mear, EEREQ);
> + for (wait = 0; wait < 2000; wait++) {
> + if (sr32(mear) & EEGNT) {
> + /* read 16 bits, and index by 16 bits
> */
> + for (i = 0; i < sis_priv->eeprom_size /
> 2; i++)
> + ebuf[i] =
> (u16)read_eeprom(ioaddr, i);
> + ret = 0;
> + break;
> + }
> + udelay(1);
> + }
cosmetic comment, too much indentations to my taste,
two ways to avoid this,
1) if !SIS96x_900_REV execute the else statement and early return
2) "do while" to wait for (sr32(mear) & EEGNT) and then execute the for
loop which reads the eeprom outs side the wait loop.
> + sw32(mear, EEDONE);
> + } else {
> + signature = (u16)read_eeprom(ioaddr, EEPROMSignature);
> + if (signature != 0xffff && signature != 0x0000) {
> + /* read 16 bits, and index by 16 bits */
> + for (i = 0; i < sis_priv->eeprom_size / 2; i++)
> + ebuf[i] = (u16)read_eeprom(ioaddr, i);
> + ret = 0;
> + }
> + }
> + return ret;
> +}
> +
> +#define SIS900_EEPROM_MAGIC 0xBABE
> +static int sis900_get_eeprom(struct net_device *dev, struct
> ethtool_eeprom *eeprom, u8 *data)
> +{
> + struct sis900_private *sis_priv = netdev_priv(dev);
> + u8 *eebuf;
> + int res;
> +
> + eebuf = kmalloc(sis_priv->eeprom_size, GFP_KERNEL);
> + if (!eebuf)
> + return -ENOMEM;
> +
> + eeprom->magic = SIS900_EEPROM_MAGIC;
> + spin_lock_irq(&sis_priv->lock);
> + res = sis900_read_eeprom(dev, eebuf);
> + spin_unlock_irq(&sis_priv->lock);
> + if (!res)
> + memcpy(data, eebuf + eeprom->offset, eeprom->len);
> + kfree(eebuf);
> + return res;
> +}
> +
> static const struct ethtool_ops sis900_ethtool_ops = {
> .get_drvinfo = sis900_get_drvinfo,
> .get_msglevel = sis900_get_msglevel,
> @@ -2132,6 +2198,8 @@ static const struct ethtool_ops
> sis900_ethtool_ops = {
> .set_wol = sis900_set_wol,
> .get_link_ksettings = sis900_get_link_ksettings,
> .set_link_ksettings = sis900_set_link_ksettings,
> + .get_eeprom_len = sis900_get_eeprom_len,
> + .get_eeprom = sis900_get_eeprom,
> };
>
> /**
^ permalink raw reply
* Re: [patch iproute2 2/2] tc: batch: fix line/line_next processing in batch
From: Stephen Hemminger @ 2019-07-26 21:35 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, sthemmin, dsahern, alexanderk, mlxsw
In-Reply-To: <20190723112538.10977-2-jiri@resnulli.us>
On Tue, 23 Jul 2019 13:25:38 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> When getcmdline fails, there is no valid string in line_next.
> So change the flow and don't process it. Alongside with that,
> free the previous line buffer and prevent memory leak.
>
> Fixes: 485d0c6001c4 ("tc: Add batchsize feature for filter and actions")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
This is not sufficient to avoid valgrind detected uninitialized memory.
The following changes to your patch (#2 alone) is enough to fix
the issue.
The logic here is still a mess and needs to be cleaned up to avoid
future related bugs.
From bbcc22899566556ced9692e4811aea2a38817834 Mon Sep 17 00:00:00 2001
From: Jiri Pirko <jiri@mellanox.com>
Date: Tue, 23 Jul 2019 13:25:38 +0200
Subject: [PATCH] tc: batch: fix line/line_next processing in batch
When getcmdline fails, there is no valid string in line_next.
So change the flow and don't process it. Alongside with that,
free the previous line buffer and prevent memory leak.
Also, avoid passing uninitialized memory to filters.
Fixes: 485d0c6001c4 ("tc: Add batchsize feature for filter and actions")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
tc/tc.c | 84 +++++++++++++++++++++++++++++----------------------------
1 file changed, 43 insertions(+), 41 deletions(-)
diff --git a/tc/tc.c b/tc/tc.c
index 64e342dd85bf..95e5481955ad 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -325,11 +325,10 @@ static int batch(const char *name)
{
struct batch_buf *head = NULL, *tail = NULL, *buf_pool = NULL;
char *largv[100], *largv_next[100];
- char *line, *line_next = NULL;
+ char *line = NULL, *line_next = NULL;
bool bs_enabled = false;
bool lastline = false;
int largc, largc_next;
- bool bs_enabled_saved;
bool bs_enabled_next;
int batchsize = 0;
size_t len = 0;
@@ -360,47 +359,40 @@ static int batch(const char *name)
largc = makeargs(line, largv, 100);
bs_enabled = batchsize_enabled(largc, largv);
do {
- if (getcmdline(&line_next, &len, stdin) == -1)
+ if (getcmdline(&line_next, &len, stdin) == -1) {
lastline = true;
-
- largc_next = makeargs(line_next, largv_next, 100);
- bs_enabled_next = batchsize_enabled(largc_next, largv_next);
- if (bs_enabled) {
- struct batch_buf *buf;
-
- buf = get_batch_buf(&buf_pool, &head, &tail);
- if (!buf) {
- fprintf(stderr,
- "failed to allocate batch_buf\n");
- return -1;
- }
- ++batchsize;
- }
-
- /*
- * In batch mode, if we haven't accumulated enough commands
- * and this is not the last command and this command & next
- * command both support the batchsize feature, don't send the
- * message immediately.
- */
- if (!lastline && bs_enabled && bs_enabled_next
- && batchsize != MSG_IOV_MAX)
- send = false;
- else
send = true;
+ } else {
+ largc_next = makeargs(line_next, largv_next, 100);
+ bs_enabled_next = batchsize_enabled(largc_next, largv_next);
+ if (bs_enabled) {
+ struct batch_buf *buf;
+
+ buf = get_batch_buf(&buf_pool, &head, &tail);
+ if (!buf) {
+ fprintf(stderr,
+ "failed to allocate batch_buf\n");
+ return -1;
+ }
+ ++batchsize;
+ }
- line = line_next;
- line_next = NULL;
- len = 0;
- bs_enabled_saved = bs_enabled;
- bs_enabled = bs_enabled_next;
-
- if (largc == 0) {
- largc = largc_next;
- memcpy(largv, largv_next, largc * sizeof(char *));
- continue; /* blank line */
+ /*
+ * In batch mode, if we haven't accumulated enough
+ * commands and this is not the last command and this
+ * command & next command both support the batchsize
+ * feature, don't send the message immediately.
+ */
+ if (bs_enabled && bs_enabled_next
+ && batchsize != MSG_IOV_MAX)
+ send = false;
+ else
+ send = true;
}
+ if (largc == 0)
+ goto to_next_line; /* blank line */
+
err = do_cmd(largc, largv, tail == NULL ? NULL : tail->buf,
tail == NULL ? 0 : sizeof(tail->buf));
fflush(stdout);
@@ -411,10 +403,8 @@ static int batch(const char *name)
if (!force)
break;
}
- largc = largc_next;
- memcpy(largv, largv_next, largc * sizeof(char *));
- if (send && bs_enabled_saved) {
+ if (send && bs_enabled) {
struct iovec *iov, *iovs;
struct batch_buf *buf;
struct nlmsghdr *n;
@@ -438,6 +428,18 @@ static int batch(const char *name)
}
batchsize = 0;
}
+
+to_next_line:
+ if (lastline)
+ continue;
+ free(line);
+ line = line_next;
+ line_next = NULL;
+ len = 0;
+ bs_enabled = bs_enabled_next;
+ largc = largc_next;
+ memcpy(largv, largv_next, largc * sizeof(char *));
+
} while (!lastline);
free_batch_bufs(&buf_pool);
--
2.20.1
^ permalink raw reply related
* Re: INFO: rcu detected stall in vhost_worker
From: Linus Torvalds @ 2019-07-26 21:35 UTC (permalink / raw)
To: syzbot
Cc: Jason Wang, KVM list, Linux Kbuild mailing list,
Linux List Kernel Mailing, michal.lkml, Michael S. Tsirkin,
Netdev, syzkaller-bugs, virtualization, Masahiro Yamada
In-Reply-To: <000000000000e87d14058e9728d7@google.com>
On Fri, Jul 26, 2019 at 8:26 AM syzbot
<syzbot+36e93b425cd6eb54fcc1@syzkaller.appspotmail.com> wrote:
>
> syzbot has bisected this bug to:
>
> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun Jul 7 22:41:56 2019 +0000
>
> Linux 5.2
That seems very unlikely. That commit literally just changes the
EXTRAVERSION part of the version string.
So even if something actually depended on the version number, even
that wouldn't have triggered any semantic change.
Linus
^ permalink raw reply
* Re: [pull request][net 0/9] Mellanox, mlx5 fixes 2019-07-25
From: David Miller @ 2019-07-26 21:34 UTC (permalink / raw)
To: saeedm; +Cc: netdev, jakub.kicinski
In-Reply-To: <20190725203618.11011-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 25 Jul 2019 20:36:32 +0000
> This series introduces some fixes to mlx5 driver.
>
> 1) Ariel is addressing an issue with enacp flow counter race condition
> 2) Aya fixes ethtool speed handling
> 3) Edward fixes modify_cq hw bits alignment
> 4) Maor fixes RDMA_RX capabilities handling
> 5) Mark reverses unregister devices order to address an issue with LAG
> 6) From Tariq,
> - wrong max num channels indication regression
> - TLS counters naming and documentation as suggested by Jakub
> - kTLS, Call WARN_ONCE on netdev mismatch
>
> There is one patch in this series that touches nfp driver to align
> TLS statistics names with latest documentation, Jakub is CC'ed.
>
> Please pull and let me know if there is any problem.
Pulled.
> For -stable v4.9:
> ('net/mlx5: Use reversed order when unregister devices')
>
> For -stable v4.20
> ('net/mlx5e: Prevent encap flow counter update async to user query')
> ('net/mlx5: Fix modify_cq_in alignment')
>
> For -stable v5.1
> ('net/mlx5e: Fix matching of speed to PRM link modes')
>
> For -stable v5.2
> ('net/mlx5: Add missing RDMA_RX capabilities')
Queued up.
^ permalink raw reply
* Re: [PATCH bpf-next 6/9] selftests/bpf: abstract away test log output
From: Stanislav Fomichev @ 2019-07-26 21:31 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team
In-Reply-To: <20190726203747.1124677-7-andriin@fb.com>
On 07/26, Andrii Nakryiko wrote:
> This patch changes how test output is printed out. By default, if test
> had no errors, the only output will be a single line with test number,
> name, and verdict at the end, e.g.:
>
> #31 xdp:OK
>
> If test had any errors, all log output captured during test execution
> will be output after test completes.
>
> It's possible to force output of log with `-v` (`--verbose`) option, in
> which case output won't be buffered and will be output immediately.
>
> To support this, individual tests are required to use helper methods for
> logging: `test__printf()` and `test__vprintf()`.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> .../selftests/bpf/prog_tests/bpf_obj_id.c | 6 +-
> .../bpf/prog_tests/bpf_verif_scale.c | 31 ++--
> .../bpf/prog_tests/get_stack_raw_tp.c | 4 +-
> .../selftests/bpf/prog_tests/l4lb_all.c | 2 +-
> .../selftests/bpf/prog_tests/map_lock.c | 10 +-
> .../selftests/bpf/prog_tests/send_signal.c | 8 +-
> .../selftests/bpf/prog_tests/spinlock.c | 2 +-
> .../bpf/prog_tests/stacktrace_build_id.c | 4 +-
> .../bpf/prog_tests/stacktrace_build_id_nmi.c | 4 +-
> .../selftests/bpf/prog_tests/xdp_noinline.c | 3 +-
> tools/testing/selftests/bpf/test_progs.c | 135 +++++++++++++-----
> tools/testing/selftests/bpf/test_progs.h | 37 ++++-
> 12 files changed, 173 insertions(+), 73 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c b/tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c
> index cb827383db4d..fb5840a62548 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c
> @@ -106,8 +106,8 @@ void test_bpf_obj_id(void)
> if (CHECK(err ||
> prog_infos[i].type != BPF_PROG_TYPE_SOCKET_FILTER ||
> info_len != sizeof(struct bpf_prog_info) ||
> - (jit_enabled && !prog_infos[i].jited_prog_len) ||
> - (jit_enabled &&
> + (env.jit_enabled && !prog_infos[i].jited_prog_len) ||
> + (env.jit_enabled &&
> !memcmp(jited_insns, zeros, sizeof(zeros))) ||
> !prog_infos[i].xlated_prog_len ||
> !memcmp(xlated_insns, zeros, sizeof(zeros)) ||
> @@ -121,7 +121,7 @@ void test_bpf_obj_id(void)
> err, errno, i,
> prog_infos[i].type, BPF_PROG_TYPE_SOCKET_FILTER,
> info_len, sizeof(struct bpf_prog_info),
> - jit_enabled,
> + env.jit_enabled,
> prog_infos[i].jited_prog_len,
> prog_infos[i].xlated_prog_len,
> !!memcmp(jited_insns, zeros, sizeof(zeros)),
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> index 2c4d9ef099b4..95f012c417fe 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> @@ -4,12 +4,15 @@
> static int libbpf_debug_print(enum libbpf_print_level level,
> const char *format, va_list args)
> {
> - if (level != LIBBPF_DEBUG)
> - return vfprintf(stderr, format, args);
> + if (level != LIBBPF_DEBUG) {
> + test__vprintf(format, args);
> + return 0;
> + }
>
> if (!strstr(format, "verifier log"))
> return 0;
> - return vfprintf(stderr, "%s", args);
> + test__vprintf("%s", args);
> + return 0;
> }
>
> static int check_load(const char *file, enum bpf_prog_type type)
> @@ -73,32 +76,38 @@ void test_bpf_verif_scale(void)
> libbpf_print_fn_t old_print_fn = NULL;
> int err, i;
>
> - if (verifier_stats)
> + if (env.verifier_stats) {
> + test__force_log();
> old_print_fn = libbpf_swap_print(libbpf_debug_print);
> + }
>
> err = check_load("./loop3.o", BPF_PROG_TYPE_RAW_TRACEPOINT);
> - printf("test_scale:loop3:%s\n", err ? (error_cnt--, "OK") : "FAIL");
> + test__printf("test_scale:loop3:%s\n",
> + err ? (error_cnt--, "OK") : "FAIL");
>
> for (i = 0; i < ARRAY_SIZE(sched_cls); i++) {
> err = check_load(sched_cls[i], BPF_PROG_TYPE_SCHED_CLS);
> - printf("test_scale:%s:%s\n", sched_cls[i], err ? "FAIL" : "OK");
> + test__printf("test_scale:%s:%s\n", sched_cls[i],
> + err ? "FAIL" : "OK");
> }
>
> for (i = 0; i < ARRAY_SIZE(raw_tp); i++) {
> err = check_load(raw_tp[i], BPF_PROG_TYPE_RAW_TRACEPOINT);
> - printf("test_scale:%s:%s\n", raw_tp[i], err ? "FAIL" : "OK");
> + test__printf("test_scale:%s:%s\n", raw_tp[i],
> + err ? "FAIL" : "OK");
> }
>
> for (i = 0; i < ARRAY_SIZE(cg_sysctl); i++) {
> err = check_load(cg_sysctl[i], BPF_PROG_TYPE_CGROUP_SYSCTL);
> - printf("test_scale:%s:%s\n", cg_sysctl[i], err ? "FAIL" : "OK");
> + test__printf("test_scale:%s:%s\n", cg_sysctl[i],
> + err ? "FAIL" : "OK");
> }
> err = check_load("./test_xdp_loop.o", BPF_PROG_TYPE_XDP);
> - printf("test_scale:test_xdp_loop:%s\n", err ? "FAIL" : "OK");
> + test__printf("test_scale:test_xdp_loop:%s\n", err ? "FAIL" : "OK");
>
> err = check_load("./test_seg6_loop.o", BPF_PROG_TYPE_LWT_SEG6LOCAL);
> - printf("test_scale:test_seg6_loop:%s\n", err ? "FAIL" : "OK");
> + test__printf("test_scale:test_seg6_loop:%s\n", err ? "FAIL" : "OK");
>
> - if (verifier_stats)
> + if (env.verifier_stats)
> libbpf_set_print(old_print_fn);
> }
> diff --git a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> index 9d73a8f932ac..3d59b3c841fe 100644
> --- a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> +++ b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> @@ -41,7 +41,7 @@ static void get_stack_print_output(void *ctx, int cpu, void *data, __u32 size)
> * just assume it is good if the stack is not empty.
> * This could be improved in the future.
> */
> - if (jit_enabled) {
> + if (env.jit_enabled) {
> found = num_stack > 0;
> } else {
> for (i = 0; i < num_stack; i++) {
> @@ -58,7 +58,7 @@ static void get_stack_print_output(void *ctx, int cpu, void *data, __u32 size)
> }
> } else {
> num_stack = e->kern_stack_size / sizeof(__u64);
> - if (jit_enabled) {
> + if (env.jit_enabled) {
> good_kern_stack = num_stack > 0;
> } else {
> for (i = 0; i < num_stack; i++) {
> diff --git a/tools/testing/selftests/bpf/prog_tests/l4lb_all.c b/tools/testing/selftests/bpf/prog_tests/l4lb_all.c
> index 20ddca830e68..5ce572c03a5f 100644
> --- a/tools/testing/selftests/bpf/prog_tests/l4lb_all.c
> +++ b/tools/testing/selftests/bpf/prog_tests/l4lb_all.c
> @@ -74,7 +74,7 @@ static void test_l4lb(const char *file)
> }
> if (bytes != MAGIC_BYTES * NUM_ITER * 2 || pkts != NUM_ITER * 2) {
> error_cnt++;
> - printf("test_l4lb:FAIL:stats %lld %lld\n", bytes, pkts);
> + test__printf("test_l4lb:FAIL:stats %lld %lld\n", bytes, pkts);
#define printf(...) test__printf(...) in tests.h?
A bit ugly, but no need to retrain everyone to use new printf wrappers.
> }
> out:
> bpf_object__close(obj);
> diff --git a/tools/testing/selftests/bpf/prog_tests/map_lock.c b/tools/testing/selftests/bpf/prog_tests/map_lock.c
> index ee99368c595c..2e78217ed3fd 100644
> --- a/tools/testing/selftests/bpf/prog_tests/map_lock.c
> +++ b/tools/testing/selftests/bpf/prog_tests/map_lock.c
> @@ -9,12 +9,12 @@ static void *parallel_map_access(void *arg)
> for (i = 0; i < 10000; i++) {
> err = bpf_map_lookup_elem_flags(map_fd, &key, vars, BPF_F_LOCK);
> if (err) {
> - printf("lookup failed\n");
> + test__printf("lookup failed\n");
> error_cnt++;
> goto out;
> }
> if (vars[0] != 0) {
> - printf("lookup #%d var[0]=%d\n", i, vars[0]);
> + test__printf("lookup #%d var[0]=%d\n", i, vars[0]);
> error_cnt++;
> goto out;
> }
> @@ -22,8 +22,8 @@ static void *parallel_map_access(void *arg)
> for (j = 2; j < 17; j++) {
> if (vars[j] == rnd)
> continue;
> - printf("lookup #%d var[1]=%d var[%d]=%d\n",
> - i, rnd, j, vars[j]);
> + test__printf("lookup #%d var[1]=%d var[%d]=%d\n",
> + i, rnd, j, vars[j]);
> error_cnt++;
> goto out;
> }
> @@ -43,7 +43,7 @@ void test_map_lock(void)
>
> err = bpf_prog_load(file, BPF_PROG_TYPE_CGROUP_SKB, &obj, &prog_fd);
> if (err) {
> - printf("test_map_lock:bpf_prog_load errno %d\n", errno);
> + test__printf("test_map_lock:bpf_prog_load errno %d\n", errno);
> goto close_prog;
> }
> map_fd[0] = bpf_find_map(__func__, obj, "hash_map");
> diff --git a/tools/testing/selftests/bpf/prog_tests/send_signal.c b/tools/testing/selftests/bpf/prog_tests/send_signal.c
> index 54218ee3c004..d950f4558897 100644
> --- a/tools/testing/selftests/bpf/prog_tests/send_signal.c
> +++ b/tools/testing/selftests/bpf/prog_tests/send_signal.c
> @@ -202,8 +202,8 @@ static int test_send_signal_nmi(void)
> -1 /* cpu */, -1 /* group_fd */, 0 /* flags */);
> if (pmu_fd == -1) {
> if (errno == ENOENT) {
> - printf("%s:SKIP:no PERF_COUNT_HW_CPU_CYCLES\n",
> - __func__);
> + test__printf("%s:SKIP:no PERF_COUNT_HW_CPU_CYCLES\n",
> + __func__);
> return 0;
> }
> /* Let the test fail with a more informative message */
> @@ -222,8 +222,4 @@ void test_send_signal(void)
> ret |= test_send_signal_tracepoint();
> ret |= test_send_signal_perf();
> ret |= test_send_signal_nmi();
> - if (!ret)
> - printf("test_send_signal:OK\n");
> - else
> - printf("test_send_signal:FAIL\n");
> }
> diff --git a/tools/testing/selftests/bpf/prog_tests/spinlock.c b/tools/testing/selftests/bpf/prog_tests/spinlock.c
> index 114ebe6a438e..deb2db5b85b0 100644
> --- a/tools/testing/selftests/bpf/prog_tests/spinlock.c
> +++ b/tools/testing/selftests/bpf/prog_tests/spinlock.c
> @@ -12,7 +12,7 @@ void test_spinlock(void)
>
> err = bpf_prog_load(file, BPF_PROG_TYPE_CGROUP_SKB, &obj, &prog_fd);
> if (err) {
> - printf("test_spin_lock:bpf_prog_load errno %d\n", errno);
> + test__printf("test_spin_lock:bpf_prog_load errno %d\n", errno);
> goto close_prog;
> }
> for (i = 0; i < 4; i++)
> diff --git a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id.c b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id.c
> index ac44fda84833..356d2c017a9c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id.c
> +++ b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id.c
> @@ -109,8 +109,8 @@ void test_stacktrace_build_id(void)
> if (build_id_matches < 1 && retry--) {
> bpf_link__destroy(link);
> bpf_object__close(obj);
> - printf("%s:WARN:Didn't find expected build ID from the map, retrying\n",
> - __func__);
> + test__printf("%s:WARN:Didn't find expected build ID from the map, retrying\n",
> + __func__);
> goto retry;
> }
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
> index 9557b7dfb782..f44f2c159714 100644
> --- a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
> +++ b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
> @@ -140,8 +140,8 @@ void test_stacktrace_build_id_nmi(void)
> if (build_id_matches < 1 && retry--) {
> bpf_link__destroy(link);
> bpf_object__close(obj);
> - printf("%s:WARN:Didn't find expected build ID from the map, retrying\n",
> - __func__);
> + test__printf("%s:WARN:Didn't find expected build ID from the map, retrying\n",
> + __func__);
> goto retry;
> }
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_noinline.c b/tools/testing/selftests/bpf/prog_tests/xdp_noinline.c
> index 09e6b46f5515..b5404494b8aa 100644
> --- a/tools/testing/selftests/bpf/prog_tests/xdp_noinline.c
> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_noinline.c
> @@ -75,7 +75,8 @@ void test_xdp_noinline(void)
> }
> if (bytes != MAGIC_BYTES * NUM_ITER * 2 || pkts != NUM_ITER * 2) {
> error_cnt++;
> - printf("test_xdp_noinline:FAIL:stats %lld %lld\n", bytes, pkts);
> + test__printf("test_xdp_noinline:FAIL:stats %lld %lld\n",
> + bytes, pkts);
> }
> out:
> bpf_object__close(obj);
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index 94b6951b90b3..3cf3ebda1d31 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -6,9 +6,75 @@
> #include <argp.h>
> #include <string.h>
>
> +/* defined in test_progs.h */
> +struct test_env env = {
> + .test_num_selector = -1,
> +};
> int error_cnt, pass_cnt;
> -bool jit_enabled;
> -bool verifier_stats = false;
> +
> +struct prog_test_def {
> + const char *test_name;
> + int test_num;
> + void (*run_test)(void);
> + bool force_log;
> + int pass_cnt;
> + int error_cnt;
> + bool tested;
> +};
> +
> +void test__force_log() {
> + env.test->force_log = true;
> +}
> +
> +void test__vprintf(const char *fmt, va_list args)
> +{
> + size_t rem_sz;
> + int ret;
> +
> + if (env.verbose || (env.test && env.test->force_log)) {
> + vfprintf(stderr, fmt, args);
> + return;
> + }
> +
> +try_again:
> + rem_sz = env.log_cap - env.log_cnt;
> + if (rem_sz) {
> + ret = vsnprintf(env.log_buf + env.log_cnt, rem_sz, fmt, args);
> + if (ret < 0) {
> + fprintf(stderr, "failed to log message w/ fmt '%s'\n", fmt);
> + return;
> + }
> + }
> +
> + if (ret >= rem_sz) {
> + size_t new_sz = env.log_cap * 3 / 2;
> + char *new_buf;
> +
> + if (new_sz < 4096)
> + new_sz = 4096;
> +
> + new_buf = realloc(env.log_buf, new_sz);
> + if (!new_buf) {
> + fprintf(stderr, "failed to realloc log buffer: %d\n",
> + errno);
> + return;
> + }
> + env.log_buf = new_buf;
> + env.log_cap = new_sz;
> + goto try_again;
> + }
> +
> + env.log_cnt += ret + 1;
> +}
> +
> +void test__printf(const char *fmt, ...)
> +{
> + va_list args;
> +
> + va_start(args, fmt);
> + test__vprintf(fmt, args);
> + va_end(args);
> +}
>
> struct ipv4_packet pkt_v4 = {
> .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> @@ -163,20 +229,15 @@ void *spin_lock_thread(void *arg)
> #include <prog_tests/tests.h>
> #undef DEFINE_TEST
>
> -struct prog_test_def {
> - const char *test_name;
> - int test_num;
> - void (*run_test)(void);
> -};
> -
> static struct prog_test_def prog_test_defs[] = {
> -#define DEFINE_TEST(name) { \
> - .test_name = #name, \
> - .run_test = &test_##name, \
> +#define DEFINE_TEST(name) { \
> + .test_name = #name, \
> + .run_test = &test_##name, \
> },
> #include <prog_tests/tests.h>
> #undef DEFINE_TEST
> };
> +const int prog_test_cnt = ARRAY_SIZE(prog_test_defs);
>
> const char *argp_program_version = "test_progs 0.1";
> const char *argp_program_bug_address = "<bpf@vger.kernel.org>";
> @@ -186,7 +247,6 @@ enum ARG_KEYS {
> ARG_TEST_NUM = 'n',
> ARG_TEST_NAME = 't',
> ARG_VERIFIER_STATS = 's',
> -
> ARG_VERBOSE = 'v',
> };
>
> @@ -202,24 +262,13 @@ static const struct argp_option opts[] = {
> {},
> };
>
> -struct test_env {
> - int test_num_selector;
> - const char *test_name_selector;
> - bool verifier_stats;
> - bool verbose;
> - bool very_verbose;
> -};
> -
> -static struct test_env env = {
> - .test_num_selector = -1,
> -};
> -
> static int libbpf_print_fn(enum libbpf_print_level level,
> const char *format, va_list args)
> {
> if (!env.very_verbose && level == LIBBPF_DEBUG)
> return 0;
> - return vfprintf(stderr, format, args);
> + test__vprintf(format, args);
> + return 0;
> }
>
> static error_t parse_arg(int key, char *arg, struct argp_state *state)
> @@ -267,7 +316,6 @@ static error_t parse_arg(int key, char *arg, struct argp_state *state)
> return 0;
> }
>
> -
> int main(int argc, char **argv)
> {
> static const struct argp argp = {
> @@ -275,7 +323,6 @@ int main(int argc, char **argv)
> .parser = parse_arg,
> .doc = argp_program_doc,
> };
> - struct prog_test_def *test;
> int err, i;
>
> err = argp_parse(&argp, argc, argv, 0, NULL, &env);
> @@ -286,13 +333,14 @@ int main(int argc, char **argv)
>
> srand(time(NULL));
>
> - jit_enabled = is_jit_enabled();
> + env.jit_enabled = is_jit_enabled();
>
> - verifier_stats = env.verifier_stats;
> -
> - for (i = 0; i < ARRAY_SIZE(prog_test_defs); i++) {
> - test = &prog_test_defs[i];
> + for (i = 0; i < prog_test_cnt; i++) {
> + struct prog_test_def *test = &prog_test_defs[i];
> + int old_pass_cnt = pass_cnt;
> + int old_error_cnt = error_cnt;
>
> + env.test = test;
> test->test_num = i + 1;
>
> if (env.test_num_selector >= 0 &&
> @@ -303,8 +351,29 @@ int main(int argc, char **argv)
> continue;
>
> test->run_test();
> + test->tested = true;
> + test->pass_cnt = pass_cnt - old_pass_cnt;
> + test->error_cnt = error_cnt - old_error_cnt;
> + if (test->error_cnt)
> + env.fail_cnt++;
> + else
> + env.succ_cnt++;
> +
> + if (env.verbose || test->force_log || test->error_cnt) {
> + if (env.log_cnt) {
> + fprintf(stdout, "%s", env.log_buf);
> + if (env.log_buf[env.log_cnt - 1] != '\n')
> + fprintf(stdout, "\n");
> + }
> + }
> + env.log_cnt = 0;
> +
> + printf("#%d %s:%s\n", test->test_num, test->test_name,
> + test->error_cnt ? "FAIL" : "OK");
> }
> + printf("Summary: %d PASSED, %d FAILED\n", env.succ_cnt, env.fail_cnt);
> +
> + free(env.log_buf);
>
> - printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
> return error_cnt ? EXIT_FAILURE : EXIT_SUCCESS;
> }
> diff --git a/tools/testing/selftests/bpf/test_progs.h b/tools/testing/selftests/bpf/test_progs.h
> index 49e0f7d85643..62f55a4231e9 100644
> --- a/tools/testing/selftests/bpf/test_progs.h
> +++ b/tools/testing/selftests/bpf/test_progs.h
> @@ -38,9 +38,33 @@ typedef __u16 __sum16;
> #include "trace_helpers.h"
> #include "flow_dissector_load.h"
>
> -extern int error_cnt, pass_cnt;
> -extern bool jit_enabled;
> -extern bool verifier_stats;
> +struct prog_test_def;
> +
> +struct test_env {
> + int test_num_selector;
> + const char *test_name_selector;
> + bool verifier_stats;
> + bool verbose;
> + bool very_verbose;
> +
> + bool jit_enabled;
> +
> + struct prog_test_def *test;
> + char *log_buf;
> + size_t log_cnt;
> + size_t log_cap;
> +
> + int succ_cnt;
> + int fail_cnt;
> +};
> +
> +extern int error_cnt;
> +extern int pass_cnt;
> +extern struct test_env env;
> +
> +extern void test__printf(const char *fmt, ...);
> +extern void test__vprintf(const char *fmt, va_list args);
> +extern void test__force_log();
>
> #define MAGIC_BYTES 123
>
> @@ -64,11 +88,12 @@ extern struct ipv6_packet pkt_v6;
> int __ret = !!(condition); \
> if (__ret) { \
> error_cnt++; \
> - printf("%s:FAIL:%s ", __func__, tag); \
> - printf(format); \
> + test__printf("%s:FAIL:%s ", __func__, tag); \
> + test__printf(format); \
> } else { \
> pass_cnt++; \
> - printf("%s:PASS:%s %d nsec\n", __func__, tag, duration);\
> + test__printf("%s:PASS:%s %d nsec\n", \
> + __func__, tag, duration); \
> } \
> __ret; \
> })
> --
> 2.17.1
>
^ permalink raw reply
* Re: phylink: flow control on fixed-link not working.
From: Russell King - ARM Linux admin @ 2019-07-26 21:28 UTC (permalink / raw)
To: René van Dorst; +Cc: netdev
In-Reply-To: <20190719195226.Horde.MpIE5TFL_P5-pUU6V-K6R9J@www.vdorst.com>
On Fri, Jul 19, 2019 at 07:52:26PM +0000, René van Dorst wrote:
> Hi Russel,
>
> If I use this patch below:
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 5d0af041b8f9..a6aebaa14338 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -216,6 +216,8 @@ static int phylink_parse_fixedlink(struct phylink *pl,
> pl->supported, true);
> linkmode_zero(pl->supported);
> phylink_set(pl->supported, MII);
> + phylink_set(pl->supported, Pause);
> + phylink_set(pl->supported, Asym_Pause);
> if (s) {
> __set_bit(s->bit, pl->supported);
> } else {
>
> Which is similar thing also done in phylink_parse_mode().
Yep, that's what should be there - please submit as a fix patch, thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH bpf-next 4/9] libbpf: add libbpf_swap_print to get previous print func
From: Stanislav Fomichev @ 2019-07-26 21:28 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team
In-Reply-To: <20190726203747.1124677-5-andriin@fb.com>
On 07/26, Andrii Nakryiko wrote:
> libbpf_swap_print allows to restore previously set print function.
> This is useful when running many independent test with one default print
> function, but overriding log verbosity for particular subset of tests.
Can we change the return type of libbpf_set_print instead and return
the old function from it? Will it break ABI?
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 8 ++++++++
> tools/lib/bpf/libbpf.h | 1 +
> tools/lib/bpf/libbpf.map | 5 +++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 8741c39adb1c..0c254b6c9685 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -79,6 +79,14 @@ void libbpf_set_print(libbpf_print_fn_t fn)
> __libbpf_pr = fn;
> }
>
> +libbpf_print_fn_t libbpf_swap_print(libbpf_print_fn_t fn)
> +{
> + libbpf_print_fn_t old_print_fn = __libbpf_pr;
> +
> + __libbpf_pr = fn;
> + return old_print_fn;
> +}
> +
> __printf(2, 3)
> void libbpf_print(enum libbpf_print_level level, const char *format, ...)
> {
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 5cbf459ece0b..4e0aa893571f 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -58,6 +58,7 @@ typedef int (*libbpf_print_fn_t)(enum libbpf_print_level level,
> const char *, va_list ap);
>
> LIBBPF_API void libbpf_set_print(libbpf_print_fn_t fn);
> +LIBBPF_API libbpf_print_fn_t libbpf_swap_print(libbpf_print_fn_t fn);
>
> /* Hide internal to user */
> struct bpf_object;
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index f9d316e873d8..e211c38ddc43 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -184,3 +184,8 @@ LIBBPF_0.0.4 {
> perf_buffer__new_raw;
> perf_buffer__poll;
> } LIBBPF_0.0.3;
> +
> +LIBBPF_0.0.5 {
> + global:
> + libbpf_swap_print;
> +} LIBBPF_0.0.4;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] sis900: add support for ethtool's EEPROM dump
From: David Miller @ 2019-07-26 21:27 UTC (permalink / raw)
To: sergej.benilov; +Cc: venza, netdev, andrew
In-Reply-To: <20190725194806.17964-1-sergej.benilov@googlemail.com>
From: Sergej Benilov <sergej.benilov@googlemail.com>
Date: Thu, 25 Jul 2019 21:48:06 +0200
> Implement ethtool's EEPROM dump command (ethtool -e|--eeprom-dump).
>
> Thx to Andrew Lunn for comments.
>
> Signed-off-by: Sergej Benilov <sergej.benilov@googlemail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH bpf-next 3/9] selftests/bpf: add test selectors by number and name to test_progs
From: Stanislav Fomichev @ 2019-07-26 21:25 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team
In-Reply-To: <20190726203747.1124677-4-andriin@fb.com>
On 07/26, Andrii Nakryiko wrote:
> Add ability to specify either test number or test name substring to
> narrow down a set of test to run.
>
> Usage:
> sudo ./test_progs -n 1
> sudo ./test_progs -t attach_probe
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/testing/selftests/bpf/test_progs.c | 43 +++++++++++++++++++++---
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index eea88ba59225..6e04b9f83777 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -4,6 +4,7 @@
> #include "test_progs.h"
> #include "bpf_rlimit.h"
> #include <argp.h>
> +#include <string.h>
>
> int error_cnt, pass_cnt;
> bool jit_enabled;
> @@ -164,6 +165,7 @@ void *spin_lock_thread(void *arg)
>
> struct prog_test_def {
> const char *test_name;
> + int test_num;
> void (*run_test)(void);
> };
>
> @@ -181,26 +183,49 @@ const char *argp_program_bug_address = "<bpf@vger.kernel.org>";
> const char argp_program_doc[] = "BPF selftests test runner";
>
> enum ARG_KEYS {
> + ARG_TEST_NUM = 'n',
> + ARG_TEST_NAME = 't',
> ARG_VERIFIER_STATS = 's',
> };
>
> static const struct argp_option opts[] = {
> + { "num", ARG_TEST_NUM, "NUM", 0,
> + "Run test number NUM only " },
> + { "name", ARG_TEST_NAME, "NAME", 0,
> + "Run tests with names containing NAME" },
> { "verifier-stats", ARG_VERIFIER_STATS, NULL, 0,
> "Output verifier statistics", },
> {},
> };
>
> struct test_env {
> + int test_num_selector;
> + const char *test_name_selector;
> bool verifier_stats;
> };
>
> -static struct test_env env = {};
> +static struct test_env env = {
> + .test_num_selector = -1,
> +};
>
> static error_t parse_arg(int key, char *arg, struct argp_state *state)
> {
> struct test_env *env = state->input;
>
> switch (key) {
[..]
> + case ARG_TEST_NUM: {
> + int test_num;
> +
> + errno = 0;
> + test_num = strtol(arg, NULL, 10);
> + if (errno)
> + return -errno;
> + env->test_num_selector = test_num;
> + break;
> + }
Do you think it's really useful? I agree about running by name (I
usually used grep -v in the Makefile :-), but I'm not sure about running
by number.
Or is the idea is that you can just copy-paste this number from the
test_progs output to rerun the tests? In this case, why not copy-paste
the name instead?
> + case ARG_TEST_NAME:
> + env->test_name_selector = arg;
> + break;
> case ARG_VERIFIER_STATS:
> env->verifier_stats = true;
> break;
> @@ -223,7 +248,7 @@ int main(int argc, char **argv)
> .parser = parse_arg,
> .doc = argp_program_doc,
> };
> - const struct prog_test_def *def;
> + struct prog_test_def *test;
> int err, i;
>
> err = argp_parse(&argp, argc, argv, 0, NULL, &env);
> @@ -237,8 +262,18 @@ int main(int argc, char **argv)
> verifier_stats = env.verifier_stats;
>
> for (i = 0; i < ARRAY_SIZE(prog_test_defs); i++) {
> - def = &prog_test_defs[i];
> - def->run_test();
> + test = &prog_test_defs[i];
> +
> + test->test_num = i + 1;
> +
> + if (env.test_num_selector >= 0 &&
> + test->test_num != env.test_num_selector)
> + continue;
> + if (env.test_name_selector &&
> + !strstr(test->test_name, env.test_name_selector))
> + continue;
> +
> + test->run_test();
> }
>
> printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH bpf] libbpf: fix erroneous multi-closing of BTF FD
From: Andrii Nakryiko @ 2019-07-26 21:24 UTC (permalink / raw)
To: bpf, netdev, ast, daniel, rdna, yhs
Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko
Libbpf stores associated BTF FD per each instance of bpf_program. When
program is unloaded, that FD is closed. This is wrong, because leads to
a race and possibly closing of unrelated files, if application
simultaneously opens new files while bpf_programs are unloaded.
It's also unnecessary, because struct btf "owns" that FD, and
btf__free(), called from bpf_object__close() will close it. Thus the fix
is to never have per-program BTF FD and fetch it from obj->btf, when
necessary.
Fixes: 2993e0515bb4 ("tools/bpf: add support to read .BTF.ext sections")
Reported-by: Andrey Ignatov <rdna@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/libbpf.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 8741c39adb1c..44a428378d48 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -181,7 +181,6 @@ struct bpf_program {
bpf_program_clear_priv_t clear_priv;
enum bpf_attach_type expected_attach_type;
- int btf_fd;
void *func_info;
__u32 func_info_rec_size;
__u32 func_info_cnt;
@@ -312,7 +311,6 @@ void bpf_program__unload(struct bpf_program *prog)
prog->instances.nr = -1;
zfree(&prog->instances.fds);
- zclose(prog->btf_fd);
zfree(&prog->func_info);
zfree(&prog->line_info);
}
@@ -391,7 +389,6 @@ bpf_program__init(void *data, size_t size, char *section_name, int idx,
prog->instances.fds = NULL;
prog->instances.nr = -1;
prog->type = BPF_PROG_TYPE_UNSPEC;
- prog->btf_fd = -1;
return 0;
errout:
@@ -2283,9 +2280,6 @@ bpf_program_reloc_btf_ext(struct bpf_program *prog, struct bpf_object *obj,
prog->line_info_rec_size = btf_ext__line_info_rec_size(obj->btf_ext);
}
- if (!insn_offset)
- prog->btf_fd = btf__fd(obj->btf);
-
return 0;
}
@@ -2458,7 +2452,7 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
char *cp, errmsg[STRERR_BUFSIZE];
int log_buf_size = BPF_LOG_BUF_SIZE;
char *log_buf;
- int ret;
+ int btf_fd, ret;
if (!insns || !insns_cnt)
return -EINVAL;
@@ -2473,7 +2467,8 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
load_attr.license = license;
load_attr.kern_version = kern_version;
load_attr.prog_ifindex = prog->prog_ifindex;
- load_attr.prog_btf_fd = prog->btf_fd >= 0 ? prog->btf_fd : 0;
+ btf_fd = bpf_object__btf_fd(prog->obj);
+ load_attr.prog_btf_fd = btf_fd >= 0 ? btf_fd : 0;
load_attr.func_info = prog->func_info;
load_attr.func_info_rec_size = prog->func_info_rec_size;
load_attr.func_info_cnt = prog->func_info_cnt;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 11/14] NFC: nxp-nci: Remove unused macro pr_fmt()
From: David Miller @ 2019-07-26 21:23 UTC (permalink / raw)
To: andriy.shevchenko
Cc: clement.perrochaud, charles.gorand, netdev, sedat.dilek,
sedat.dilek
In-Reply-To: <20190725193511.64274-11-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu, 25 Jul 2019 22:35:08 +0300
> The macro had never been used.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
...
> @@ -12,8 +12,6 @@
> * Copyright (C) 2012 Intel Corporation. All rights reserved.
> */
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
If there are any kernel log messages generated, which is the case in
this file, this is used.
Also, please resubmit this series with a proper header posting containing
a high level description of what this patch series does, how it is doing it,
and why it is doing it that way. Also include a changelog.
Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next 1/9] selftests/bpf: prevent headers to be compiled as C code
From: Stanislav Fomichev @ 2019-07-26 21:21 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team
In-Reply-To: <20190726203747.1124677-2-andriin@fb.com>
On 07/26, Andrii Nakryiko wrote:
> Apprently listing header as a normal dependency for a binary output
> makes it go through compilation as if it was C code. This currently
> works without a problem, but in subsequent commits causes problems for
> differently generated test.h for test_progs. Marking those headers as
> order-only dependency solves the issue.
Are you sure it will not result in a situation where
test_progs/test_maps is not regenerated if tests.h is updated.
If I read the following doc correctly, order deps make sense for
directories only:
https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
Can you maybe double check it with:
* make
* add new prog_tests/test_something.c
* make
to see if the binary is regenerated with test_something.c?
Maybe fix the problem of header compilation by having '#ifndef
DECLARE_TEST #define DECLARE_TEST() #endif' in tests.h instead?
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/testing/selftests/bpf/Makefile | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 11c9c62c3362..bb66cc4a7f34 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -235,7 +235,7 @@ PROG_TESTS_H := $(PROG_TESTS_DIR)/tests.h
> PROG_TESTS_FILES := $(wildcard prog_tests/*.c)
> test_progs.c: $(PROG_TESTS_H)
> $(OUTPUT)/test_progs: CFLAGS += $(TEST_PROGS_CFLAGS)
> -$(OUTPUT)/test_progs: test_progs.c $(PROG_TESTS_H) $(PROG_TESTS_FILES)
> +$(OUTPUT)/test_progs: test_progs.c $(PROG_TESTS_FILES) | $(PROG_TESTS_H)
> $(PROG_TESTS_H): $(PROG_TESTS_FILES) | $(PROG_TESTS_DIR)
> $(shell ( cd prog_tests/; \
> echo '/* Generated header, do not edit */'; \
> @@ -256,7 +256,7 @@ MAP_TESTS_H := $(MAP_TESTS_DIR)/tests.h
> MAP_TESTS_FILES := $(wildcard map_tests/*.c)
> test_maps.c: $(MAP_TESTS_H)
> $(OUTPUT)/test_maps: CFLAGS += $(TEST_MAPS_CFLAGS)
> -$(OUTPUT)/test_maps: test_maps.c $(MAP_TESTS_H) $(MAP_TESTS_FILES)
> +$(OUTPUT)/test_maps: test_maps.c $(MAP_TESTS_FILES) | $(MAP_TESTS_H)
> $(MAP_TESTS_H): $(MAP_TESTS_FILES) | $(MAP_TESTS_DIR)
> $(shell ( cd map_tests/; \
> echo '/* Generated header, do not edit */'; \
> @@ -277,7 +277,7 @@ VERIFIER_TESTS_H := $(VERIFIER_TESTS_DIR)/tests.h
> VERIFIER_TEST_FILES := $(wildcard verifier/*.c)
> test_verifier.c: $(VERIFIER_TESTS_H)
> $(OUTPUT)/test_verifier: CFLAGS += $(TEST_VERIFIER_CFLAGS)
> -$(OUTPUT)/test_verifier: test_verifier.c $(VERIFIER_TESTS_H)
> +$(OUTPUT)/test_verifier: test_verifier.c | $(VERIFIER_TEST_FILES) $(VERIFIER_TESTS_H)
> $(VERIFIER_TESTS_H): $(VERIFIER_TEST_FILES) | $(VERIFIER_TESTS_DIR)
> $(shell ( cd verifier/; \
> echo '/* Generated header, do not edit */'; \
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net] net: qualcomm: rmnet: Fix incorrect UL checksum offload logic
From: David Miller @ 2019-07-26 21:20 UTC (permalink / raw)
To: subashab; +Cc: netdev, stranche
In-Reply-To: <1564078032-8754-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Thu, 25 Jul 2019 12:07:12 -0600
> The udp_ip4_ind bit is set only for IPv4 UDP non-fragmented packets
> so that the hardware can flip the checksum to 0xFFFF if the computed
> checksum is 0 per RFC768.
>
> However, this bit had to be set for IPv6 UDP non fragmented packets
> as well per hardware requirements. Otherwise, IPv6 UDP packets
> with computed checksum as 0 were transmitted by hardware and were
> dropped in the network.
>
> In addition to setting this bit for IPv6 UDP, the field is also
> appropriately renamed to udp_ind as part of this change.
>
> Fixes: 5eb5f8608ef1 ("net: qualcomm: rmnet: Add support for TX checksum offload")
> Cc: Sean Tranchetti <stranche@codeaurora.org>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Applied and queued up for -stable.
^ permalink raw reply
* Re: next-20190723: bpf/seccomp - systemd/journald issue?
From: Sedat Dilek @ 2019-07-26 21:19 UTC (permalink / raw)
To: Yonghong Song
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu,
netdev@vger.kernel.org, bpf@vger.kernel.org, Clang-Built-Linux ML,
Kees Cook, Nick Desaulniers, Nathan Chancellor
In-Reply-To: <295d2acd-0844-9a40-3f94-5bcbb13871d2@fb.com>
On Fri, Jul 26, 2019 at 11:10 PM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 7/26/19 2:02 PM, Sedat Dilek wrote:
> > On Fri, Jul 26, 2019 at 10:38 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >>
> >> Hi Yonghong Song,
> >>
> >> On Fri, Jul 26, 2019 at 5:45 PM Yonghong Song <yhs@fb.com> wrote:
> >>>
> >>>
> >>>
> >>> On 7/26/19 1:26 AM, Sedat Dilek wrote:
> >>>> Hi,
> >>>>
> >>>> I have opened a new issue in the ClangBuiltLinux issue tracker.
> >>>
> >>> Glad to know clang 9 has asm goto support and now It can compile
> >>> kernel again.
> >>>
> >>
> >> Yupp.
> >>
> >>>>
> >>>> I am seeing a problem in the area bpf/seccomp causing
> >>>> systemd/journald/udevd services to fail.
> >>>>
> >>>> [Fri Jul 26 08:08:43 2019] systemd[453]: systemd-udevd.service: Failed
> >>>> to connect stdout to the journal socket, ignoring: Connection refused
> >>>>
> >>>> This happens when I use the (LLVM) LLD ld.lld-9 linker but not with
> >>>> BFD linker ld.bfd on Debian/buster AMD64.
> >>>> In both cases I use clang-9 (prerelease).
> >>>
> >>> Looks like it is a lld bug.
> >>>
> >>> I see the stack trace has __bpf_prog_run32() which is used by
> >>> kernel bpf interpreter. Could you try to enable bpf jit
> >>> sysctl net.core.bpf_jit_enable = 1
> >>> If this passed, it will prove it is interpreter related.
> >>>
> >>
> >> After...
> >>
> >> sysctl -w net.core.bpf_jit_enable=1
> >>
> >> I can start all failed systemd services.
> >>
> >> systemd-journald.service
> >> systemd-udevd.service
> >> haveged.service
> >>
> >> This is in maintenance mode.
> >>
> >> What is next: Do set a permanent sysctl setting for net.core.bpf_jit_enable?
> >>
> >
> > This is what I did:
>
> I probably won't have cycles to debug this potential lld issue.
> Maybe you already did, I suggest you put enough reproducible
> details in the bug you filed against lld so they can take a look.
>
I understand and will put the journalctl-log into the CBL issue
tracker and update informations.
Thanks for your help understanding the BPF correlations.
Is setting 'net.core.bpf_jit_enable = 2' helpful here?
Values :
0 - disable the JIT (default value)
1 - enable the JIT
2 - enable the JIT and ask the compiler to emit traces on kernel log.
Which files should LLD folks look at?
cd linux
find ./ -name '*bpf*.o' | grep jit
./arch/x86/net/bpf_jit_comp.o
Compare the objdumps?
I have archived the full build-dirs of clang9+ld.bfd and clang9+ld.lld-9.
Thanks for your help!
- sed@ -
[1] https://sysctl-explorer.net/net/core/bpf_jit_enable/
> >
> > Jul 26 22:43:06 iniza kernel: BUG: unable to handle page fault for
> > address: ffffffffa8203370
> > Jul 26 22:43:06 iniza kernel: #PF: supervisor read access in kernel mode
> > Jul 26 22:43:06 iniza kernel: #PF: error_code(0x0000) - not-present page
> > Jul 26 22:43:06 iniza kernel: PGD 2cfa0e067 P4D 2cfa0e067 PUD
> > 2cfa0f063 PMD 450829063 PTE 800ffffd30bfc062
> > Jul 26 22:43:06 iniza kernel: Oops: 0000 [#3] SMP PTI
> > Jul 26 22:43:06 iniza kernel: CPU: 3 PID: 436 Comm: systemd-udevd
> > Tainted: G D 5.3.0-rc1-7-amd64-cbl-asmgoto
> > #7~buster+dileks1
> > Jul 26 22:43:06 iniza kernel: Hardware name: LENOVO
> > 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
> > Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> > Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> > 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> > c3 48 83 c3 08 0f b6
> > 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48 83 f8 1e 0f 8f c8 00
> > Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec0327a88 EFLAGS: 00010246
> > Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec0327b30 RBX:
> > ffffb3cec00d1038 RCX: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec0327b10 RSI:
> > 00000000000000ac RDI: ffffb3cec0327ab0
> > Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec0327aa0 R08:
> > ffff9b33c94c0a00 R09: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R10: ffff9b33cfe14e00 R11:
> > ffffffffa77b8210 R12: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R13: ffffb3cec00d1000 R14:
> > 0000000000000000 R15: ffffb3cec0327ab0
> > Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> > GS:ffff9b33d2580000(0000) knlGS:0000000000000000
> > Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> > 000000044f3ea006 CR4: 00000000003606e0
> > Jul 26 22:43:06 iniza kernel: Call Trace:
> > Jul 26 22:43:06 iniza kernel: __bpf_prog_run32+0x44/0x70
> > Jul 26 22:43:06 iniza kernel: ? security_sock_rcv_skb+0x3f/0x60
> > Jul 26 22:43:06 iniza kernel: sk_filter_trim_cap+0xe4/0x220
> > Jul 26 22:43:06 iniza kernel: ? __skb_clone+0x2e/0x100
> > Jul 26 22:43:06 iniza kernel: netlink_broadcast_filtered+0x2df/0x4f0
> > Jul 26 22:43:06 iniza kernel: netlink_sendmsg+0x34f/0x3c0
> > Jul 26 22:43:06 iniza kernel: ___sys_sendmsg+0x315/0x330
> > Jul 26 22:43:06 iniza kernel: ? seccomp_run_filters+0x54/0x110
> > Jul 26 22:43:06 iniza kernel: ? filename_parentat+0x210/0x490
> > Jul 26 22:43:06 iniza kernel: ? __seccomp_filter+0xf7/0x6e0
> > Jul 26 22:43:06 iniza kernel: ? __d_alloc+0x159/0x1c0
> > Jul 26 22:43:06 iniza kernel: ? kmem_cache_free+0x1e/0x5c0
> > Jul 26 22:43:06 iniza kernel: ? fast_dput+0x73/0xb0
> > Jul 26 22:43:06 iniza kernel: __x64_sys_sendmsg+0x97/0xe0
> > Jul 26 22:43:06 iniza kernel: do_syscall_64+0x59/0x90
> > Jul 26 22:43:06 iniza kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > Jul 26 22:43:06 iniza kernel: RIP: 0033:0x7f7ac3519914
> > Jul 26 22:43:06 iniza kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff
> > ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75
> > 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41
> > 89 d4 55 48 89 f5 53
> > Jul 26 22:43:06 iniza kernel: RSP: 002b:00007ffcfb66a478 EFLAGS:
> > 00000246 ORIG_RAX: 000000000000002e
> > Jul 26 22:43:06 iniza kernel: RAX: ffffffffffffffda RBX:
> > 0000561e28ac9390 RCX: 00007f7ac3519914
> > Jul 26 22:43:06 iniza kernel: RDX: 0000000000000000 RSI:
> > 00007ffcfb66a4a0 RDI: 000000000000000d
> > Jul 26 22:43:06 iniza kernel: RBP: 0000561e28acd210 R08:
> > 0000561e28990140 R09: 0000000000000002
> > Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> > 0000000000000246 R12: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R13: 0000000000000000 R14:
> > 000000000000005e R15: 00007ffcfb66a490
> > Jul 26 22:43:06 iniza kernel: Modules linked in: nfsd auth_rpcgss
> > nfs_acl lockd grace i2c_dev parport_pc ppdev lp parport sunrpc
> > efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic mbcache crc16
> > jbd2 btrfs zstd_decompress zstd_compress algif_skcipher af_alg sd_mod
> > uas usb_storage scsi_mod hid_generic usbhid hid dm_crypt dm_mod raid10
> > raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> > raid6_pq libcrc32c raid1 raid0 multipath linear md_mod
> > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
> > aesni_intel i915 intel_lpss_pci nvme aes_x86_64 glue_helper
> > i2c_algo_bit crypto_simd cryptd xhci_pci psmouse e1000e drm_kms_helper
> > xhci_hcd i2c_i801 nvme_core intel_lpss drm usbcore thermal wmi video
> > button
> > Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370
> > Jul 26 22:43:06 iniza kernel: ---[ end trace 312670b063bd0391 ]---
> > Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> > Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> > 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> > c3 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48
> > 83 f8 1e 0f 8f c8 00
> > Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec0253cb8 EFLAGS: 00010246
> > Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec0253d60 RBX:
> > ffffb3cec00e9038 RCX: 0000000000000002
> > Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec0253d40 RSI:
> > 00000000000000ac RDI: ffffb3cec0253ce0
> > Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec0253cd0 R08:
> > 0000000000000000 R09: ffffb3cec0253f58
> > Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> > ffffffffa77b8210 R12: 000000007fff0000
> > Jul 26 22:43:06 iniza kernel: R13: ffffb3cec0253eb8 R14:
> > 0000000000000000 R15: ffffb3cec0253ce0
> > Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> > GS:ffff9b33d2580000(0000) knlGS:0000000000000000
> > Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> > 000000044f3ea006 CR4: 00000000003606e0
> > Jul 26 22:43:06 iniza kernel: BUG: unable to handle page fault for
> > address: ffffffffa8203370
> > Jul 26 22:43:06 iniza kernel: #PF: supervisor read access in kernel mode
> > Jul 26 22:43:06 iniza kernel: #PF: error_code(0x0000) - not-present page
> > Jul 26 22:43:06 iniza kernel: PGD 2cfa0e067 P4D 2cfa0e067 PUD
> > 2cfa0f063 PMD 450829063 PTE 800ffffd30bfc062
> > Jul 26 22:43:06 iniza kernel: Oops: 0000 [#4] SMP PTI
> > Jul 26 22:43:06 iniza kernel: CPU: 0 PID: 437 Comm: systemd-udevd
> > Tainted: G D 5.3.0-rc1-7-amd64-cbl-asmgoto
> > #7~buster+dileks1
> > Jul 26 22:43:06 iniza kernel: Hardware name: LENOVO
> > 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
> > Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> > Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> > 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> > c3 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48
> > 83 f8 1e 0f 8f c8 00
> > Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec032fa88 EFLAGS: 00010246
> > Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec032fb30 RBX:
> > ffffb3cec00d1038 RCX: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec032fb10 RSI:
> > 00000000000000ac RDI: ffffb3cec032fab0
> > Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec032faa0 R08:
> > ffff9b33cf34b000 R09: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R10: ffff9b33cf3a3400 R11:
> > ffffffffa77b8210 R12: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R13: ffffb3cec00d1000 R14:
> > 0000000000000000 R15: ffffb3cec032fab0
> > Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> > GS:ffff9b33d2400000(0000) knlGS:0000000000000000
> > Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> > 000000044724a001 CR4: 00000000003606f0
> > Jul 26 22:43:06 iniza kernel: Call Trace:
> > Jul 26 22:43:06 iniza kernel: __bpf_prog_run32+0x44/0x70
> > Jul 26 22:43:06 iniza kernel: ? prep_new_page+0x47/0x1a0
> > Jul 26 22:43:06 iniza kernel: ? security_sock_rcv_skb+0x3f/0x60
> > Jul 26 22:43:06 iniza kernel: sk_filter_trim_cap+0xe4/0x220
> > Jul 26 22:43:06 iniza kernel: ? __skb_clone+0x2e/0x100
> > Jul 26 22:43:06 iniza kernel: netlink_broadcast_filtered+0x2df/0x4f0
> > Jul 26 22:43:06 iniza kernel: netlink_sendmsg+0x34f/0x3c0
> > Jul 26 22:43:06 iniza kernel: ___sys_sendmsg+0x315/0x330
> > Jul 26 22:43:06 iniza kernel: ? seccomp_run_filters+0x54/0x110
> > Jul 26 22:43:06 iniza kernel: ? filename_parentat+0x210/0x490
> > Jul 26 22:43:06 iniza kernel: ? __seccomp_filter+0xf7/0x6e0
> > Jul 26 22:43:06 iniza kernel: ? __d_alloc+0x159/0x1c0
> > Jul 26 22:43:06 iniza kernel: ? kmem_cache_free+0x1e/0x5c0
> > Jul 26 22:43:06 iniza kernel: ? fast_dput+0x73/0xb0
> > Jul 26 22:43:06 iniza kernel: __x64_sys_sendmsg+0x97/0xe0
> > Jul 26 22:43:06 iniza kernel: do_syscall_64+0x59/0x90
> > Jul 26 22:43:06 iniza kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > Jul 26 22:43:06 iniza kernel: RIP: 0033:0x7f7ac3519914
> > Jul 26 22:43:06 iniza kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff
> > ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75
> > 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41
> > 89 d4 55 48 89 f5 53
> > Jul 26 22:43:06 iniza kernel: RSP: 002b:00007ffcfb66a478 EFLAGS:
> > 00000246 ORIG_RAX: 000000000000002e
> > Jul 26 22:43:06 iniza kernel: RAX: ffffffffffffffda RBX:
> > 0000561e28aaa600 RCX: 00007f7ac3519914
> > Jul 26 22:43:06 iniza kernel: RDX: 0000000000000000 RSI:
> > 00007ffcfb66a4a0 RDI: 000000000000000e
> > Jul 26 22:43:06 iniza kernel: RBP: 0000561e28aaaac0 R08:
> > 0000561e28990140 R09: 0000000000000002
> > Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> > 0000000000000246 R12: 0000000000000000
> > Jul 26 22:43:06 iniza kernel: R13: 0000000000000000 R14:
> > 000000000000005d R15: 00007ffcfb66a490
> > Jul 26 22:43:06 iniza kernel: Modules linked in: nfsd auth_rpcgss
> > nfs_acl lockd grace i2c_dev parport_pc ppdev lp parport sunrpc
> > efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic mbcache crc16
> > jbd2 btrfs zstd_decompress zstd_compress algif_skcipher af_alg sd_mod
> > uas usb_storage scsi_mod hid_generic usbhid hid dm_crypt dm_mod raid10
> > raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> > raid6_pq libcrc32c raid1 raid0 multipath linear md_mod
> > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
> > aesni_intel i915 intel_lpss_pci nvme aes_x86_64 glue_helper
> > i2c_algo_bit crypto_simd cryptd xhci_pci psmouse e1000e drm_kms_helper
> > xhci_hcd i2c_i801 nvme_core intel_lpss drm usbcore thermal wmi video
> > button
> > Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370
> > Jul 26 22:43:06 iniza kernel: ---[ end trace 312670b063bd0392 ]---
> >
> > Full `journalctl -xb` attached.
> >
> > - Sedat -
> >
^ permalink raw reply
* Re: [PATCH] ip6_tunnel: fix possible use-after-free on xmit
From: David Miller @ 2019-07-26 21:18 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, netdev, linux-kernel
In-Reply-To: <1564072817-13240-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 26 Jul 2019 00:40:17 +0800
> ip4ip6/ip6ip6 tunnels run iptunnel_handle_offloads on xmit which
> can cause a possible use-after-free accessing iph/ipv6h pointer
> since the packet will be 'uncloned' running pskb_expand_head if
> it is a cloned gso skb.
>
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets")
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ocelot: Cancel delayed work before wq destruction
From: David Miller @ 2019-07-26 21:11 UTC (permalink / raw)
To: claudiu.manoil; +Cc: alexandre.belloni, netdev, UNGLinuxDriver
In-Reply-To: <1564061598-4440-1-git-send-email-claudiu.manoil@nxp.com>
From: Claudiu Manoil <claudiu.manoil@nxp.com>
Date: Thu, 25 Jul 2019 16:33:18 +0300
> Make sure the delayed work for stats update is not pending before
> wq destruction.
> This fixes the module unload path.
> The issue is there since day 1.
>
> Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Applied, thanks.
^ permalink raw reply
* Re: next-20190723: bpf/seccomp - systemd/journald issue?
From: Yonghong Song @ 2019-07-26 21:10 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu,
netdev@vger.kernel.org, bpf@vger.kernel.org, Clang-Built-Linux ML,
Kees Cook, Nick Desaulniers, Nathan Chancellor
In-Reply-To: <CA+icZUXsPRWmH3i-9=TK-=2HviubRqpAeDJGriWHgK1fkFhgUg@mail.gmail.com>
On 7/26/19 2:02 PM, Sedat Dilek wrote:
> On Fri, Jul 26, 2019 at 10:38 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>
>> Hi Yonghong Song,
>>
>> On Fri, Jul 26, 2019 at 5:45 PM Yonghong Song <yhs@fb.com> wrote:
>>>
>>>
>>>
>>> On 7/26/19 1:26 AM, Sedat Dilek wrote:
>>>> Hi,
>>>>
>>>> I have opened a new issue in the ClangBuiltLinux issue tracker.
>>>
>>> Glad to know clang 9 has asm goto support and now It can compile
>>> kernel again.
>>>
>>
>> Yupp.
>>
>>>>
>>>> I am seeing a problem in the area bpf/seccomp causing
>>>> systemd/journald/udevd services to fail.
>>>>
>>>> [Fri Jul 26 08:08:43 2019] systemd[453]: systemd-udevd.service: Failed
>>>> to connect stdout to the journal socket, ignoring: Connection refused
>>>>
>>>> This happens when I use the (LLVM) LLD ld.lld-9 linker but not with
>>>> BFD linker ld.bfd on Debian/buster AMD64.
>>>> In both cases I use clang-9 (prerelease).
>>>
>>> Looks like it is a lld bug.
>>>
>>> I see the stack trace has __bpf_prog_run32() which is used by
>>> kernel bpf interpreter. Could you try to enable bpf jit
>>> sysctl net.core.bpf_jit_enable = 1
>>> If this passed, it will prove it is interpreter related.
>>>
>>
>> After...
>>
>> sysctl -w net.core.bpf_jit_enable=1
>>
>> I can start all failed systemd services.
>>
>> systemd-journald.service
>> systemd-udevd.service
>> haveged.service
>>
>> This is in maintenance mode.
>>
>> What is next: Do set a permanent sysctl setting for net.core.bpf_jit_enable?
>>
>
> This is what I did:
I probably won't have cycles to debug this potential lld issue.
Maybe you already did, I suggest you put enough reproducible
details in the bug you filed against lld so they can take a look.
>
> Jul 26 22:43:06 iniza kernel: BUG: unable to handle page fault for
> address: ffffffffa8203370
> Jul 26 22:43:06 iniza kernel: #PF: supervisor read access in kernel mode
> Jul 26 22:43:06 iniza kernel: #PF: error_code(0x0000) - not-present page
> Jul 26 22:43:06 iniza kernel: PGD 2cfa0e067 P4D 2cfa0e067 PUD
> 2cfa0f063 PMD 450829063 PTE 800ffffd30bfc062
> Jul 26 22:43:06 iniza kernel: Oops: 0000 [#3] SMP PTI
> Jul 26 22:43:06 iniza kernel: CPU: 3 PID: 436 Comm: systemd-udevd
> Tainted: G D 5.3.0-rc1-7-amd64-cbl-asmgoto
> #7~buster+dileks1
> Jul 26 22:43:06 iniza kernel: Hardware name: LENOVO
> 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
> Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> c3 48 83 c3 08 0f b6
> 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48 83 f8 1e 0f 8f c8 00
> Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec0327a88 EFLAGS: 00010246
> Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec0327b30 RBX:
> ffffb3cec00d1038 RCX: 0000000000000000
> Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec0327b10 RSI:
> 00000000000000ac RDI: ffffb3cec0327ab0
> Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec0327aa0 R08:
> ffff9b33c94c0a00 R09: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R10: ffff9b33cfe14e00 R11:
> ffffffffa77b8210 R12: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R13: ffffb3cec00d1000 R14:
> 0000000000000000 R15: ffffb3cec0327ab0
> Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> GS:ffff9b33d2580000(0000) knlGS:0000000000000000
> Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> 000000044f3ea006 CR4: 00000000003606e0
> Jul 26 22:43:06 iniza kernel: Call Trace:
> Jul 26 22:43:06 iniza kernel: __bpf_prog_run32+0x44/0x70
> Jul 26 22:43:06 iniza kernel: ? security_sock_rcv_skb+0x3f/0x60
> Jul 26 22:43:06 iniza kernel: sk_filter_trim_cap+0xe4/0x220
> Jul 26 22:43:06 iniza kernel: ? __skb_clone+0x2e/0x100
> Jul 26 22:43:06 iniza kernel: netlink_broadcast_filtered+0x2df/0x4f0
> Jul 26 22:43:06 iniza kernel: netlink_sendmsg+0x34f/0x3c0
> Jul 26 22:43:06 iniza kernel: ___sys_sendmsg+0x315/0x330
> Jul 26 22:43:06 iniza kernel: ? seccomp_run_filters+0x54/0x110
> Jul 26 22:43:06 iniza kernel: ? filename_parentat+0x210/0x490
> Jul 26 22:43:06 iniza kernel: ? __seccomp_filter+0xf7/0x6e0
> Jul 26 22:43:06 iniza kernel: ? __d_alloc+0x159/0x1c0
> Jul 26 22:43:06 iniza kernel: ? kmem_cache_free+0x1e/0x5c0
> Jul 26 22:43:06 iniza kernel: ? fast_dput+0x73/0xb0
> Jul 26 22:43:06 iniza kernel: __x64_sys_sendmsg+0x97/0xe0
> Jul 26 22:43:06 iniza kernel: do_syscall_64+0x59/0x90
> Jul 26 22:43:06 iniza kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Jul 26 22:43:06 iniza kernel: RIP: 0033:0x7f7ac3519914
> Jul 26 22:43:06 iniza kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff
> ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75
> 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41
> 89 d4 55 48 89 f5 53
> Jul 26 22:43:06 iniza kernel: RSP: 002b:00007ffcfb66a478 EFLAGS:
> 00000246 ORIG_RAX: 000000000000002e
> Jul 26 22:43:06 iniza kernel: RAX: ffffffffffffffda RBX:
> 0000561e28ac9390 RCX: 00007f7ac3519914
> Jul 26 22:43:06 iniza kernel: RDX: 0000000000000000 RSI:
> 00007ffcfb66a4a0 RDI: 000000000000000d
> Jul 26 22:43:06 iniza kernel: RBP: 0000561e28acd210 R08:
> 0000561e28990140 R09: 0000000000000002
> Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> 0000000000000246 R12: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R13: 0000000000000000 R14:
> 000000000000005e R15: 00007ffcfb66a490
> Jul 26 22:43:06 iniza kernel: Modules linked in: nfsd auth_rpcgss
> nfs_acl lockd grace i2c_dev parport_pc ppdev lp parport sunrpc
> efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic mbcache crc16
> jbd2 btrfs zstd_decompress zstd_compress algif_skcipher af_alg sd_mod
> uas usb_storage scsi_mod hid_generic usbhid hid dm_crypt dm_mod raid10
> raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> raid6_pq libcrc32c raid1 raid0 multipath linear md_mod
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
> aesni_intel i915 intel_lpss_pci nvme aes_x86_64 glue_helper
> i2c_algo_bit crypto_simd cryptd xhci_pci psmouse e1000e drm_kms_helper
> xhci_hcd i2c_i801 nvme_core intel_lpss drm usbcore thermal wmi video
> button
> Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370
> Jul 26 22:43:06 iniza kernel: ---[ end trace 312670b063bd0391 ]---
> Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> c3 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48
> 83 f8 1e 0f 8f c8 00
> Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec0253cb8 EFLAGS: 00010246
> Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec0253d60 RBX:
> ffffb3cec00e9038 RCX: 0000000000000002
> Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec0253d40 RSI:
> 00000000000000ac RDI: ffffb3cec0253ce0
> Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec0253cd0 R08:
> 0000000000000000 R09: ffffb3cec0253f58
> Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> ffffffffa77b8210 R12: 000000007fff0000
> Jul 26 22:43:06 iniza kernel: R13: ffffb3cec0253eb8 R14:
> 0000000000000000 R15: ffffb3cec0253ce0
> Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> GS:ffff9b33d2580000(0000) knlGS:0000000000000000
> Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> 000000044f3ea006 CR4: 00000000003606e0
> Jul 26 22:43:06 iniza kernel: BUG: unable to handle page fault for
> address: ffffffffa8203370
> Jul 26 22:43:06 iniza kernel: #PF: supervisor read access in kernel mode
> Jul 26 22:43:06 iniza kernel: #PF: error_code(0x0000) - not-present page
> Jul 26 22:43:06 iniza kernel: PGD 2cfa0e067 P4D 2cfa0e067 PUD
> 2cfa0f063 PMD 450829063 PTE 800ffffd30bfc062
> Jul 26 22:43:06 iniza kernel: Oops: 0000 [#4] SMP PTI
> Jul 26 22:43:06 iniza kernel: CPU: 0 PID: 437 Comm: systemd-udevd
> Tainted: G D 5.3.0-rc1-7-amd64-cbl-asmgoto
> #7~buster+dileks1
> Jul 26 22:43:06 iniza kernel: Hardware name: LENOVO
> 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
> Jul 26 22:43:06 iniza kernel: RIP: 0010:___bpf_prog_run+0x40/0x14f0
> Jul 26 22:43:06 iniza kernel: Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c
> 00 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c
> c3 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 20 a8 48 83 f8 3b 7f 62 48
> 83 f8 1e 0f 8f c8 00
> Jul 26 22:43:06 iniza kernel: RSP: 0018:ffffb3cec032fa88 EFLAGS: 00010246
> Jul 26 22:43:06 iniza kernel: RAX: ffffb3cec032fb30 RBX:
> ffffb3cec00d1038 RCX: 0000000000000000
> Jul 26 22:43:06 iniza kernel: RDX: ffffb3cec032fb10 RSI:
> 00000000000000ac RDI: ffffb3cec032fab0
> Jul 26 22:43:06 iniza kernel: RBP: ffffb3cec032faa0 R08:
> ffff9b33cf34b000 R09: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R10: ffff9b33cf3a3400 R11:
> ffffffffa77b8210 R12: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R13: ffffb3cec00d1000 R14:
> 0000000000000000 R15: ffffb3cec032fab0
> Jul 26 22:43:06 iniza kernel: FS: 00007f7ac2d28d40(0000)
> GS:ffff9b33d2400000(0000) knlGS:0000000000000000
> Jul 26 22:43:06 iniza kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370 CR3:
> 000000044724a001 CR4: 00000000003606f0
> Jul 26 22:43:06 iniza kernel: Call Trace:
> Jul 26 22:43:06 iniza kernel: __bpf_prog_run32+0x44/0x70
> Jul 26 22:43:06 iniza kernel: ? prep_new_page+0x47/0x1a0
> Jul 26 22:43:06 iniza kernel: ? security_sock_rcv_skb+0x3f/0x60
> Jul 26 22:43:06 iniza kernel: sk_filter_trim_cap+0xe4/0x220
> Jul 26 22:43:06 iniza kernel: ? __skb_clone+0x2e/0x100
> Jul 26 22:43:06 iniza kernel: netlink_broadcast_filtered+0x2df/0x4f0
> Jul 26 22:43:06 iniza kernel: netlink_sendmsg+0x34f/0x3c0
> Jul 26 22:43:06 iniza kernel: ___sys_sendmsg+0x315/0x330
> Jul 26 22:43:06 iniza kernel: ? seccomp_run_filters+0x54/0x110
> Jul 26 22:43:06 iniza kernel: ? filename_parentat+0x210/0x490
> Jul 26 22:43:06 iniza kernel: ? __seccomp_filter+0xf7/0x6e0
> Jul 26 22:43:06 iniza kernel: ? __d_alloc+0x159/0x1c0
> Jul 26 22:43:06 iniza kernel: ? kmem_cache_free+0x1e/0x5c0
> Jul 26 22:43:06 iniza kernel: ? fast_dput+0x73/0xb0
> Jul 26 22:43:06 iniza kernel: __x64_sys_sendmsg+0x97/0xe0
> Jul 26 22:43:06 iniza kernel: do_syscall_64+0x59/0x90
> Jul 26 22:43:06 iniza kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Jul 26 22:43:06 iniza kernel: RIP: 0033:0x7f7ac3519914
> Jul 26 22:43:06 iniza kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff
> ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75
> 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41
> 89 d4 55 48 89 f5 53
> Jul 26 22:43:06 iniza kernel: RSP: 002b:00007ffcfb66a478 EFLAGS:
> 00000246 ORIG_RAX: 000000000000002e
> Jul 26 22:43:06 iniza kernel: RAX: ffffffffffffffda RBX:
> 0000561e28aaa600 RCX: 00007f7ac3519914
> Jul 26 22:43:06 iniza kernel: RDX: 0000000000000000 RSI:
> 00007ffcfb66a4a0 RDI: 000000000000000e
> Jul 26 22:43:06 iniza kernel: RBP: 0000561e28aaaac0 R08:
> 0000561e28990140 R09: 0000000000000002
> Jul 26 22:43:06 iniza kernel: R10: 0000000000000000 R11:
> 0000000000000246 R12: 0000000000000000
> Jul 26 22:43:06 iniza kernel: R13: 0000000000000000 R14:
> 000000000000005d R15: 00007ffcfb66a490
> Jul 26 22:43:06 iniza kernel: Modules linked in: nfsd auth_rpcgss
> nfs_acl lockd grace i2c_dev parport_pc ppdev lp parport sunrpc
> efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic mbcache crc16
> jbd2 btrfs zstd_decompress zstd_compress algif_skcipher af_alg sd_mod
> uas usb_storage scsi_mod hid_generic usbhid hid dm_crypt dm_mod raid10
> raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> raid6_pq libcrc32c raid1 raid0 multipath linear md_mod
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
> aesni_intel i915 intel_lpss_pci nvme aes_x86_64 glue_helper
> i2c_algo_bit crypto_simd cryptd xhci_pci psmouse e1000e drm_kms_helper
> xhci_hcd i2c_i801 nvme_core intel_lpss drm usbcore thermal wmi video
> button
> Jul 26 22:43:06 iniza kernel: CR2: ffffffffa8203370
> Jul 26 22:43:06 iniza kernel: ---[ end trace 312670b063bd0392 ]---
>
> Full `journalctl -xb` attached.
>
> - Sedat -
>
^ permalink raw reply
* Re: [PATCH] Build fixes for skb_frag_size conversion
From: David Miller @ 2019-07-26 21:10 UTC (permalink / raw)
To: arnd; +Cc: willy, netdev
In-Reply-To: <CAK8P3a1Ae3r=dOa-LSWxUEWH5qY4c8HfnGuT0y5BEL51tUCDOQ@mail.gmail.com>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 25 Jul 2019 13:08:18 +0200
> On Wed, Jul 24, 2019 at 1:37 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>>
>> I missed a few places. One is in some ifdeffed code which will probably
>> never be re-enabled; the others are in drivers which can't currently be
>> compiled on x86.
>>
>> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>
>> diff --git a/drivers/staging/octeon/ethernet-tx.c b/drivers/staging/octeon/ethernet-tx.c
>> index cc12c78f73f1..46a6fcf1414d 100644
>> --- a/drivers/staging/octeon/ethernet-tx.c
>> +++ b/drivers/staging/octeon/ethernet-tx.c
>> @@ -284,7 +284,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
>>
>> hw_buffer.s.addr =
>> XKPHYS_TO_PHYS((u64)skb_frag_address(fs));
>> - hw_buffer.s.size = fs->size;
>> + hw_buffer.s.size = skb_drag_size(fs);
>> CVM_OCT_SKB_CB(skb)[i + 1] = hw_buffer.u64;
>> }
>> hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)CVM_OCT_SKB_CB(skb));
>
> Kernelci noticed a build failure from a typo here:
> https://kernelci.org/build/id/5d3943f859b514103f688918/logs/
I just checked this into net-next:
====================
From 1fbf400b58fa70c35bf671ff640b83799e45388d Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Fri, 26 Jul 2019 14:10:30 -0700
Subject: [PATCH] staging: octeon: Fix build failure due to typo.
drivers/staging/octeon/ethernet-tx.c:287:23: error: implicit declaration of function 'skb_drag_size'; did you mean 'skb_frag_size'? [-Werror=implicit-function-declaration]
From kernelci report:
https://kernelci.org/build/id/5d3943f859b514103f688918/logs/
Fixes: 92493a2f8a8d ("Build fixes for skb_frag_size conversion")
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/staging/octeon/ethernet-tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon/ethernet-tx.c b/drivers/staging/octeon/ethernet-tx.c
index 46a6fcf1414d..44f79cd32750 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -284,7 +284,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
hw_buffer.s.addr =
XKPHYS_TO_PHYS((u64)skb_frag_address(fs));
- hw_buffer.s.size = skb_drag_size(fs);
+ hw_buffer.s.size = skb_frag_size(fs);
CVM_OCT_SKB_CB(skb)[i + 1] = hw_buffer.u64;
}
hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)CVM_OCT_SKB_CB(skb));
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 2/2] mlx4/en_netdev: call notifiers when hw_enc_features change
From: Saeed Mahameed @ 2019-07-26 21:10 UTC (permalink / raw)
To: dcaratti@redhat.com, davem@davemloft.net, Tariq Toukan,
netdev@vger.kernel.org
Cc: Eran Ben Elisha
In-Reply-To: <7ec40c37b843ebd3fd2ff5998bb382e13e45d816.camel@redhat.com>
On Fri, 2019-07-26 at 12:39 +0200, Davide Caratti wrote:
> On Thu, 2019-07-25 at 21:27 +0000, Saeed Mahameed wrote:
> > On Thu, 2019-07-25 at 14:25 +0200, Davide Caratti wrote:
> > > On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > > > On Wed, 2019-07-24 at 16:02 +0200, Davide Caratti wrote:
> > > > > ensure to call netdev_features_change() when the driver flips
> > > > > its
> > > > > hw_enc_features bits.
> > > > >
> > > > > Signed-off-by: Davide Caratti <dcaratti@redhat.com>
> > > >
> > > > The patch is correct,
> > >
> > > hello Saeed, and thanks for looking at this!
> > >
> > > > but can you explain how did you come to this ?
> > > > did you encounter any issue with the current code ?
> > > >
> > > > I am asking just because i think the whole dynamic changing of
> > > > dev-
> > > > > hw_enc_features is redundant since mlx4 has the
> > > > > featutres_check
> > > > callback.
> > >
> > > we need it to ensure that vlan_transfer_features() updates
> > > the (new) value of hw_enc_features in the overlying vlan:
> > > otherwise,
> > > segmentation will happen anyway when skb passes from vxlan to
> > > vlan,
> > > if the
> > > vxlan is added after the vlan device has been created (see:
> > > 7dad9937e064
> > > ("net: vlan: add support for tunnel offload") ).
> > >
> >
> > but in previous patch you made sure that the vlan always sees the
> > correct hw_enc_features on driver load, we don't need to have this
> > dynamic update mechanism,
>
> ok, but the mlx4 driver flips the value of hw_enc_features when VXLAN
> tunnels are added or removed. So, assume eth0 is a Cx3-pro, and I do:
>
> # ip link add name vlan5 link eth0 type vlan id 5
> # ip link add dev vxlan6 type vxlan id 6 [...] dev vlan5
>
> the value of dev->hw_enc_features is 0 for vlan5, and as a
> consequence
> VXLAN over VLAN traffic becomes segmented by the VLAN, even if eth0,
> at
> the end of this sequence, has the "right" features bits.
>
your patch handled this issue already, no need for flipping and
updating features if features check ndo will cover the cases we don't
support.
> > features_check ndo should take care of
> > protocols we don't support.
>
> I just had a look at mlx4_en_features_check(), I see it checks if the
> packet is tunneled in VXLAN and the destination port matches the
> configured value of priv->vxlan_port (when that value is not zero).
> Now:
>
> On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > I am asking just because i think the whole dynamic changing of
> > dev-> hw_enc_features is redundant since mlx4 has the
> > featutres_check
> > callback.
>
> I read your initial proposal again. Would it be correct if I just use
> patch 1/2, where I add an assignment of
>
> dev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \
> NETIF_F_RXCSUM | \
> NETIF_F_TSO | NETIF_F_TSO6 | \
> NETIF_F_GSO_UDP_TUNNEL | \
> NETIF_F_GSO_UDP_TUNNEL_CSUM | \
> NETIF_F_GSO_PARTIAL;
>
> in mlx4_en_init_netdev(), and then remove the code that flips
> dev->hw_enc_features in mlx4_en_add_vxlan_offloads() and
> mlx4_en_del_vxlan_offloads() ?
>
yes, this is exactly what I meant.
Thanks,
Saeed.
^ permalink raw reply
* Re: next-20190723: bpf/seccomp - systemd/journald issue?
From: Yonghong Song @ 2019-07-26 21:05 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu,
netdev@vger.kernel.org, bpf@vger.kernel.org, Clang-Built-Linux ML,
Kees Cook, Nick Desaulniers, Nathan Chancellor
In-Reply-To: <CA+icZUXYp=Jx+8aGrZmkCbSFp-cSPcoRzRdRJsPj4yYNs_mJQw@mail.gmail.com>
On 7/26/19 1:38 PM, Sedat Dilek wrote:
> Hi Yonghong Song,
>
> On Fri, Jul 26, 2019 at 5:45 PM Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> On 7/26/19 1:26 AM, Sedat Dilek wrote:
>>> Hi,
>>>
>>> I have opened a new issue in the ClangBuiltLinux issue tracker.
>>
>> Glad to know clang 9 has asm goto support and now It can compile
>> kernel again.
>>
>
> Yupp.
>
>>>
>>> I am seeing a problem in the area bpf/seccomp causing
>>> systemd/journald/udevd services to fail.
>>>
>>> [Fri Jul 26 08:08:43 2019] systemd[453]: systemd-udevd.service: Failed
>>> to connect stdout to the journal socket, ignoring: Connection refused
>>>
>>> This happens when I use the (LLVM) LLD ld.lld-9 linker but not with
>>> BFD linker ld.bfd on Debian/buster AMD64.
>>> In both cases I use clang-9 (prerelease).
>>
>> Looks like it is a lld bug.
>>
>> I see the stack trace has __bpf_prog_run32() which is used by
>> kernel bpf interpreter. Could you try to enable bpf jit
>> sysctl net.core.bpf_jit_enable = 1
>> If this passed, it will prove it is interpreter related.
>>
>
> After...
>
> sysctl -w net.core.bpf_jit_enable=1
>
> I can start all failed systemd services.
>
> systemd-journald.service
> systemd-udevd.service
> haveged.service
>
> This is in maintenance mode.
>
> What is next: Do set a permanent sysctl setting for net.core.bpf_jit_enable?
I do think you should set net.core.bpf_jit_enable by default. This is
more tested in production and you get better performance as well.
>
> Regards,
> - Sedat -
>
>>>
>>> Base for testing: next-20190723.
>>>
>>> The call-trace looks like this:
>>>
>>> [Fri Jul 26 08:08:42 2019] BUG: unable to handle page fault for
>>> address: ffffffff85403370
>>> [Fri Jul 26 08:08:42 2019] #PF: supervisor read access in kernel mode
>>> [Fri Jul 26 08:08:42 2019] #PF: error_code(0x0000) - not-present page
>>> [Fri Jul 26 08:08:42 2019] PGD 7620e067 P4D 7620e067 PUD 7620f063 PMD
>>> 44fe85063 PTE 800fffff8a3fc062
>>> [Fri Jul 26 08:08:42 2019] Oops: 0000 [#1] SMP PTI
>>> [Fri Jul 26 08:08:42 2019] CPU: 2 PID: 417 Comm: (journald) Not
>>> tainted 5.3.0-rc1-5-amd64-cbl-asmgoto #5~buster+dileks1
>>> [Fri Jul 26 08:08:42 2019] Hardware name: LENOVO
>>> 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
>>> [Fri Jul 26 08:08:42 2019] RIP: 0010:___bpf_prog_run+0x40/0x14f0
>>> [Fri Jul 26 08:08:42 2019] Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c 00
>>> 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c c3
>>> 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 40 85 48 83 f8 3b 7f 62 48 83
>>> f8 1e 0f 8f c8 00
>>> [Fri Jul 26 08:08:42 2019] RSP: 0018:ffff992ec028fcb8 EFLAGS: 00010246
>>> [Fri Jul 26 08:08:42 2019] RAX: ffff992ec028fd60 RBX: ffff992ec00e9038
>>> RCX: 0000000000000002
>>> [Fri Jul 26 08:08:42 2019] RDX: ffff992ec028fd40 RSI: 00000000000000ac
>>> RDI: ffff992ec028fce0
>>> [Fri Jul 26 08:08:42 2019] RBP: ffff992ec028fcd0 R08: 0000000000000000
>>> R09: ffff992ec028ff58
>>> [Fri Jul 26 08:08:42 2019] R10: 0000000000000000 R11: ffffffff849b8210
>>> R12: 000000007fff0000
>>> [Fri Jul 26 08:08:42 2019] R13: ffff992ec028feb8 R14: 0000000000000000
>>> R15: ffff992ec028fce0
>>> [Fri Jul 26 08:08:42 2019] FS: 00007f5d20f1d940(0000)
>>> GS:ffff8ba3d2500000(0000) knlGS:0000000000000000
>>> [Fri Jul 26 08:08:42 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370 CR3: 0000000445b3e001
>>> CR4: 00000000003606e0
>>> [Fri Jul 26 08:08:42 2019] Call Trace:
>>> [Fri Jul 26 08:08:42 2019] __bpf_prog_run32+0x44/0x70
>>> [Fri Jul 26 08:08:42 2019] ? flush_tlb_func_common+0xd8/0x230
>>> [Fri Jul 26 08:08:42 2019] ? mem_cgroup_commit_charge+0x8c/0x120
>>> [Fri Jul 26 08:08:42 2019] ? wp_page_copy+0x464/0x7a0
>>> [Fri Jul 26 08:08:42 2019] seccomp_run_filters+0x54/0x110
>>> [Fri Jul 26 08:08:42 2019] __seccomp_filter+0xf7/0x6e0
>>> [Fri Jul 26 08:08:42 2019] ? do_wp_page+0x32b/0x5d0
>>> [Fri Jul 26 08:08:42 2019] ? handle_mm_fault+0x90d/0xbf0
>>> [Fri Jul 26 08:08:42 2019] syscall_trace_enter+0x182/0x290
>>> [Fri Jul 26 08:08:42 2019] do_syscall_64+0x30/0x90
>>> [Fri Jul 26 08:08:42 2019] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [Fri Jul 26 08:08:42 2019] RIP: 0033:0x7f5d220d7f59
>>> [Fri Jul 26 08:08:42 2019] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00
>>> 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8
>>> 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00
>>> f7 d8 64 89 01 48
>>> [Fri Jul 26 08:08:42 2019] RSP: 002b:00007ffd11332b48 EFLAGS: 00000246
>>> ORIG_RAX: 000000000000013d
>>> [Fri Jul 26 08:08:42 2019] RAX: ffffffffffffffda RBX: 000055bf8ab34010
>>> RCX: 00007f5d220d7f59
>>> [Fri Jul 26 08:08:42 2019] RDX: 000055bf8ab34010 RSI: 0000000000000000
>>> RDI: 0000000000000001
>>> [Fri Jul 26 08:08:42 2019] RBP: 000055bf8ab97fb0 R08: 000055bf8abbe180
>>> R09: 00000000c000003e
>>> [Fri Jul 26 08:08:42 2019] R10: 000055bf8abbe1e0 R11: 0000000000000246
>>> R12: 00007ffd11332ba0
>>> [Fri Jul 26 08:08:42 2019] R13: 00007ffd11332b98 R14: 00007f5d21f087f8
>>> R15: 000000000000002c
>>> [Fri Jul 26 08:08:42 2019] Modules linked in: i2c_dev parport_pc
>>> sunrpc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4
>>> crc32c_generic mbcache crc16 jbd2 btrfs zstd_decompress zstd_compress
>>> algif_skcipher af_alg sd_mod dm_crypt dm_mod raid10 raid456
>>> async_raid6_recov async_memcpy async_pq async_xor async_tx xor
>>> raid6_pq libcrc32c raid1 uas raid0 usb_storage multipath linear
>>> scsi_mod md_mod hid_cherry hid_generic usbhid hid crct10dif_pclmul
>>> crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64
>>> i915 glue_helper crypto_simd nvme i2c_algo_bit cryptd psmouse xhci_pci
>>> drm_kms_helper e1000e i2c_i801 xhci_hcd intel_lpss_pci nvme_core
>>> intel_lpss drm usbcore thermal wmi video button
>>> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370
>>> [Fri Jul 26 08:08:42 2019] ---[ end trace 867b35c7d6c6705a ]---
>>> [Fri Jul 26 08:08:42 2019] RIP: 0010:___bpf_prog_run+0x40/0x14f0
>>> [Fri Jul 26 08:08:42 2019] Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c 00
>>> 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c c3
>>> 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 40 85 48 83 f8 3b 7f 62 48 83
>>> f8 1e 0f 8f c8 00
>>> [Fri Jul 26 08:08:42 2019] RSP: 0018:ffff992ec028fcb8 EFLAGS: 00010246
>>> [Fri Jul 26 08:08:42 2019] RAX: ffff992ec028fd60 RBX: ffff992ec00e9038
>>> RCX: 0000000000000002
>>> [Fri Jul 26 08:08:42 2019] RDX: ffff992ec028fd40 RSI: 00000000000000ac
>>> RDI: ffff992ec028fce0
>>> [Fri Jul 26 08:08:42 2019] RBP: ffff992ec028fcd0 R08: 0000000000000000
>>> R09: ffff992ec028ff58
>>> [Fri Jul 26 08:08:42 2019] R10: 0000000000000000 R11: ffffffff849b8210
>>> R12: 000000007fff0000
>>> [Fri Jul 26 08:08:42 2019] R13: ffff992ec028feb8 R14: 0000000000000000
>>> R15: ffff992ec028fce0
>>> [Fri Jul 26 08:08:42 2019] FS: 00007f5d20f1d940(0000)
>>> GS:ffff8ba3d2500000(0000) knlGS:0000000000000000
>>> [Fri Jul 26 08:08:42 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370 CR3: 0000000445b3e001
>>> CR4: 00000000003606e0
>>>
>>> More details in [1] and what I tried (for example CONFIG_SECCOMP=n)
>>>
>>> I have no clue about BPF or SECCOMP.
>>>
>>> Can you comment on this?
>>>
>>> If this touches BPF: Can you give me some hints and instructions in debugging?
>>>
>>> My kernel-config and dmesg-log are attached.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> [1] https://github.com/ClangBuiltLinux/linux/issues/619
>>>
^ 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