* Reminder,
From: Juliet Muhammad @ 2018-09-27 0:45 UTC (permalink / raw)
To: Recipients
Hello
Please i still await your response regarding my previous email.
^ permalink raw reply
* Re: [PATCH bpf-next] flow_dissector: lookup netns by skb->sk if skb->dev is NULL
From: Eric Dumazet @ 2018-09-27 0:49 UTC (permalink / raw)
To: Daniel Borkmann, Willem de Bruijn, netdev; +Cc: ast, davem, Willem de Bruijn
In-Reply-To: <1cc82769-d4c4-2976-d341-0537d2d2eb24@iogearbox.net>
On 09/25/2018 08:38 AM, Daniel Borkmann wrote:
> On 09/24/2018 10:49 PM, Willem de Bruijn wrote:
>> From: Willem de Bruijn <willemb@google.com>
>>
>> BPF flow dissectors are configured per network namespace.
>> __skb_flow_dissect looks up the netns through dev_net(skb->dev).
>>
>> In some dissector paths skb->dev is NULL, such as for Unix sockets.
>> In these cases fall back to looking up the netns by socket.
>>
>> Analyzing the codepaths leading to __skb_flow_dissect I did not find
>> a case where both skb->dev and skb->sk are NULL. Warn and fall back to
>> standard flow dissector if one is found.
>>
>> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
>> Reported-by: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> Applied to bpf-next, thanks Willem!
>
Sadly lib/test_bpf should still cause crashes, because populate_skb()
populates an skb attached to a fake device, for which net pointer is NULL.
^ permalink raw reply
* [PATCH net] net/ipv6: Remove extra call to ip6_convert_metrics for multipath case
From: dsahern @ 2018-09-27 0:35 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
From: David Ahern <dsahern@gmail.com>
The change to move metrics from the dst to rt6_info moved the call
to ip6_convert_metrics from ip6_route_add to ip6_route_info_create. In
doing so it makes the call in ip6_route_info_append redundant and
actually leaks the metrics installed as part of the ip6_route_info_create.
Remove the now unnecessary call.
Fixes: d4ead6b34b67f ("net/ipv6: move metrics from dst to rt6_info")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv6/route.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index d28f83e01593..570f158253b9 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4293,11 +4293,6 @@ static int ip6_route_info_append(struct net *net,
if (!nh)
return -ENOMEM;
nh->fib6_info = rt;
- err = ip6_convert_metrics(net, rt, r_cfg);
- if (err) {
- kfree(nh);
- return err;
- }
memcpy(&nh->r_cfg, r_cfg, sizeof(*r_cfg));
list_add_tail(&nh->next, rt6_nh_list);
--
2.11.0
^ permalink raw reply related
* Reminder,
From: Juliet Muhammad @ 2018-09-27 0:16 UTC (permalink / raw)
To: Recipients
Hello
Please i still await your response regarding my previous email.
^ permalink raw reply
* Re: WARN_ON in TLP causing RT throttling
From: Eric Dumazet @ 2018-09-27 0:09 UTC (permalink / raw)
To: stranche, eric.dumazet; +Cc: soheil@google.com
In-Reply-To: <7aa9932a59aad7a21c7f8a8146dd0542@codeaurora.org>
On 09/26/2018 04:46 PM, stranche@codeaurora.org wrote:
> Hi Eric,
>
> Someone recently reported a crash to us on the 4.14.62 kernel where excessive
> WARNING prints were spamming the logs and causing watchdog bites. The kernel
> does have the following commit by Soheil:
> bffd168c3fc5 "tcp: clear tp->packets_out when purging write queue"
>
> Before this bug we see over 1 second of continuous WARN_ON prints from
> tcp_send_loss_probe() like so:
>
> 7795.530450: <2> tcp_send_loss_probe+0x194/0x1b8
> 7795.534833: <2> tcp_write_timer_handler+0xf8/0x1c4
> 7795.539492: <2> tcp_write_timer+0x4c/0x74
> 7795.543348: <2> call_timer_fn+0xc0/0x1b4
> 7795.547113: <2> run_timer_softirq+0x248/0x81c
>
> Specifically, the prints come from the following check:
>
> /* Retransmit last segment. */
> if (WARN_ON(!skb))
> goto rearm_timer;
>
> Since skb is always NULL, we know there's nothing on the write queue or the
> retransmit queue, so we just keep resetting the timer, waiting for more data
> to be queued. However, we were able to determine that the TCP socket is in the
> TCP_FIN_WAIT1 state, so we will no longer be sending any data and these queues
> remain empty.
>
> Would it be appropriate to stop resetting the TLP timer if we detect that the
> connection is starting to close and we have no more data to send the probe with,
> or is there some way that this scenario should already be handled?
>
> Unfortunately, we don't have a reproducer for this crash.
>
Something is fishy.
If there is no skb in the queues, then tp->packets_out should be 0,
therefore tcp_rearm_rto() should simply call inet_csk_clear_xmit_timer(sk, ICSK_TIME_RETRANS);
I have never seen this report before.
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] Introduce libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-09-26 23:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
Kernel Team
In-Reply-To: <20180926162007.37a4b873@cakuba.netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> [Wed, 2018-09-26 16:20 -0700]:
> On Wed, 26 Sep 2018 15:24:52 -0700, Andrey Ignatov wrote:
> > This patch set introduces libbpf_attach_type_by_name function in libbpf to
> > identify attach type by section name.
> >
> > This is useful to avoid writing same logic over and over again in user
> > space applications that leverage libbpf.
> >
> > Patch 1 has more details on the new function and problem being solved.
> > Patches 2 and 3 add support for new section names.
> > Patch 4 uses new function in a selftest.
> > Patch 5 adds selftest for libbpf_{prog,attach}_type_by_name.
> >
> > As a side note there are a lot of inconsistencies now between names used by
> > libbpf and bpftool (e.g. cgroup/skb vs cgroup_skb, cgroup_device and device
> > vs cgroup/dev, sockops vs sock_ops, etc). This patch set does not address
> > it but it tries not to make it harder to address it in the future.
>
> I was wondering a few times whether I should point it out to people
> during review, but thought it would be nit picking. Maybe we should be
> more strict.
>
> Your series LGTM!
Thanks for review!
IMO having it consistent would be great, e.g. one writes a program with
section name X and bpftool shows/accepts it in exactly same way in all
its sub-commands (w/o maybe custom suffix added by program writer).
But I doubt that keeping a few places in sync manually will work long
term since it's easy to miss such a thing.
What do you think of having one source of truth in libbpf so that a
string for prog_type or attach_type is defined once and all other places
(e.g. bpftool prog show, bpftool cgroup show) use only corresponding
enum-s to get those strings, but don't introduce any new strings?
Keeping already existing names in a backward compatible way is a pain
though.
Another thing, I was wondering, is if there is a way to bypass strings
completely (at least in libbpf, since bpftool still has to print
human-readable names) and keep actual bpf_prog_type and bpf_attach_type
as metadata for a program in ELF file. Maybe some compiler magic ..
--
Andrey Ignatov
^ permalink raw reply
* WARN_ON in TLP causing RT throttling
From: stranche @ 2018-09-26 23:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: soheil@google.com
Hi Eric,
Someone recently reported a crash to us on the 4.14.62 kernel where
excessive
WARNING prints were spamming the logs and causing watchdog bites. The
kernel
does have the following commit by Soheil:
bffd168c3fc5 "tcp: clear tp->packets_out when purging write queue"
Before this bug we see over 1 second of continuous WARN_ON prints from
tcp_send_loss_probe() like so:
7795.530450: <2> tcp_send_loss_probe+0x194/0x1b8
7795.534833: <2> tcp_write_timer_handler+0xf8/0x1c4
7795.539492: <2> tcp_write_timer+0x4c/0x74
7795.543348: <2> call_timer_fn+0xc0/0x1b4
7795.547113: <2> run_timer_softirq+0x248/0x81c
Specifically, the prints come from the following check:
/* Retransmit last segment. */
if (WARN_ON(!skb))
goto rearm_timer;
Since skb is always NULL, we know there's nothing on the write queue or
the
retransmit queue, so we just keep resetting the timer, waiting for more
data
to be queued. However, we were able to determine that the TCP socket is
in the
TCP_FIN_WAIT1 state, so we will no longer be sending any data and these
queues
remain empty.
Would it be appropriate to stop resetting the TLP timer if we detect
that the
connection is starting to close and we have no more data to send the
probe with,
or is there some way that this scenario should already be handled?
Unfortunately, we don't have a reproducer for this crash.
Thanks,
Sean
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: John Johansen @ 2018-09-26 23:35 UTC (permalink / raw)
To: Daniel Borkmann, Tetsuo Handa, Alexei Starovoitov
Cc: Network Development, David S. Miller, Dmitry Vyukov,
Andrew Morton, Michal Hocko
In-Reply-To: <037d9772-63fe-203a-edb7-4af65016f6ff@iogearbox.net>
On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
>> Hello, Alexei and Daniel.
>>
>> Can you show us how to run testcases you are testing?
>
> Sorry for the delay; currently quite backlogged but will definitely take a look
> at these reports. Regarding your question: majority of test cases are in the
> kernel tree under selftests, see tools/testing/selftests/bpf/ .
>
Its unlikely to be apparmor. I went through the reports and saw nothing that
would indicate apparmor involvement, but the primary reason is what is being tested
in upstream apparmor atm.
The current upstream code does nothing directly with skbuffs. Its
possible that the audit code paths (kernel audit does grab skbuffs)
could, but there are only a couple cases that would be triggered in
the current fuzzing so this seems to be an unlikely source for such a
large leak.
>> On 2018/09/22 22:25, Tetsuo Handa wrote:
>>> Hello.
>>>
>>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>>
>>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>>
>>> INFO: rcu detected stall in tun_chr_close
>>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>>
>>> INFO: rcu detected stall in discover_timer
>>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>>
>>> INFO: rcu detected stall in ret_from_fork (2)
>>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>>
>>> INFO: rcu detected stall in addrconf_rs_timer
>>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>>
>>> INFO: rcu detected stall in kthread (2)
>>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>>
>>> INFO: rcu detected stall in ext4_filemap_fault
>>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>>
>>> INFO: rcu detected stall in run_timer_softirq (2)
>>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>>
>>> INFO: rcu detected stall in bpf_prog_ADDR
>>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>>
>>> INFO: rcu detected stall in __run_timers (2)
>>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>>
>>> The cause of lockup seems to be flood of printk() messages from memory allocation
>>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>>> usage is huge enough to suspect in-kernel memory leaks.
>>>
>>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>>
>>> Unfortunately, we cannot find from logs what syzbot is trying to do
>>> because constant printk() messages is flooding away syzkaller messages.
>>> Can you try running your testcases with kmemleak enabled?
>>>
>>
>> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>>> Now the instances that use SELinux and Smack explicitly contain that
>>> in the name, but the rest are Apparmor.
>>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>>> some Apparmor hook leaks a reference to skbs?
>>
>> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
>> this problem is not occurring on linux-next.git when this problem is occurring
>> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
>> different testcases depending on which git tree is targeted?
>>
>
this is another reason that it is doubtful that its apparmor.
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] Introduce libbpf_attach_type_by_name
From: Jakub Kicinski @ 2018-09-26 23:20 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
On Wed, 26 Sep 2018 15:24:52 -0700, Andrey Ignatov wrote:
> This patch set introduces libbpf_attach_type_by_name function in libbpf to
> identify attach type by section name.
>
> This is useful to avoid writing same logic over and over again in user
> space applications that leverage libbpf.
>
> Patch 1 has more details on the new function and problem being solved.
> Patches 2 and 3 add support for new section names.
> Patch 4 uses new function in a selftest.
> Patch 5 adds selftest for libbpf_{prog,attach}_type_by_name.
>
> As a side note there are a lot of inconsistencies now between names used by
> libbpf and bpftool (e.g. cgroup/skb vs cgroup_skb, cgroup_device and device
> vs cgroup/dev, sockops vs sock_ops, etc). This patch set does not address
> it but it tries not to make it harder to address it in the future.
I was wondering a few times whether I should point it out to people
during review, but thought it would be nit picking. Maybe we should be
more strict.
Your series LGTM!
^ permalink raw reply
* Re: [PATCH v2 2/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: LABBE Corentin @ 2018-09-27 5:35 UTC (permalink / raw)
To: Christophe LEROY
Cc: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens,
netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <4a63152f-9eca-f7d9-8fe6-59caaab33666@c-s.fr>
On Tue, Sep 25, 2018 at 07:05:00AM +0200, Christophe LEROY wrote:
>
>
> Le 24/09/2018 à 21:04, Corentin Labbe a écrit :
> > This patch adds setbits32/clrbits32/clrsetbits32 and
> > setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
>
> Fix the patch subject and description.
>
> >
> > Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> > ---
> > include/linux/setbits.h | 88 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 88 insertions(+)
> > create mode 100644 include/linux/setbits.h
> >
> > diff --git a/include/linux/setbits.h b/include/linux/setbits.h
> > new file mode 100644
> > index 000000000000..6e7e257134ae
> > --- /dev/null
> > +++ b/include/linux/setbits.h
> > @@ -0,0 +1,88 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef __LINUX_SETBITS_H
> > +#define __LINUX_SETBITS_H
> > +
> > +#include <linux/io.h>
> > +
> > +#define __setbits(readfunction, writefunction, addr, set) \
> > + writefunction((readfunction(addr) | (set)), addr)
>
> You don't need so long names for parameters in a 2 lines macro (See
> Linux Kernel Codying style §4 Naming).
>
> A single line macro would be feasible with only 3 chars names:
>
> #define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr)
>
Thanks I will fix all reported problem.
> > +#define __clrbits(readfunction, writefunction, addr, mask) \
> > + writefunction((readfunction(addr) & ~(mask)), addr)
> > +#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
> > + writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
> > +#define __setclrbits(readfunction, writefunction, addr, mask, set) \
> > + writefunction(((readfunction(addr) | (set)) & ~(mask)), addr)
> > +
> > +#ifndef setbits_le32
> > +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
> > +#endif
> > +#ifndef setbits_le32_relaxed
> > +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
> > + addr, set)
> > +#endif
> > +
> > +#ifndef clrbits_le32
> > +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
> > +#endif
> > +#ifndef clrbits_le32_relaxed
> > +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
> > + addr, mask)
> > +#endif
> > +
> > +#ifndef clrsetbits_le32
> > +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
> > +#endif
> > +#ifndef clrsetbits_le32_relaxed
> > +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
> > + writel_relaxed, \
> > + addr, mask, set)
> > +#endif
> > +
> > +#ifndef setclrbits_le32
> > +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
> > +#endif
> > +#ifndef setclrbits_le32_relaxed
> > +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
> > + writel_relaxed, \
> > + addr, mask, set)
> > +#endif
> > +
> > +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
> > +#if defined(writeq) && defined(readq)
>
> Take care. At least Alpha Arch defines it as a static inline without
> redefining it as a #define. (see arch/alpha/kernel/io.c)
In fact, it does in arch/alpha/include/asm/io.h along with a gentle comment.
But fixing their comment will be another interesting patch serie.
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH v2 1/7] powerpc: rename setbits32/clrbits32 to setbits32_be/clrbits32_be
From: LABBE Corentin @ 2018-09-27 5:30 UTC (permalink / raw)
To: Christophe LEROY
Cc: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens,
netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <eeaeff10-dcc9-ab50-5d54-4d727f12d584@c-s.fr>
On Tue, Sep 25, 2018 at 06:56:23AM +0200, Christophe LEROY wrote:
> Fix the patch title.
>
>
> Le 24/09/2018 à 21:04, Corentin Labbe a écrit :
> > Since setbits32/clrbits32 work on be32, it's better to remove ambiguity on
> > the used data type.
> >
> > Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> > ---
> > arch/powerpc/include/asm/fsl_lbc.h | 2 +-
> > arch/powerpc/include/asm/io.h | 5 +-
> > arch/powerpc/platforms/44x/canyonlands.c | 4 +-
> > arch/powerpc/platforms/4xx/gpio.c | 28 ++++-----
> > arch/powerpc/platforms/512x/pdm360ng.c | 6 +-
> > arch/powerpc/platforms/52xx/mpc52xx_common.c | 6 +-
> > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 10 ++--
> > arch/powerpc/platforms/82xx/ep8248e.c | 2 +-
> > arch/powerpc/platforms/82xx/km82xx.c | 6 +-
> > arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 ++--
> > arch/powerpc/platforms/82xx/pq2.c | 2 +-
> > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 4 +-
> > arch/powerpc/platforms/82xx/pq2fads.c | 10 ++--
> > arch/powerpc/platforms/83xx/km83xx.c | 6 +-
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
> > arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 +-
> > arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
> > arch/powerpc/platforms/85xx/p1022_ds.c | 4 +-
> > arch/powerpc/platforms/85xx/p1022_rdk.c | 4 +-
> > arch/powerpc/platforms/85xx/t1042rdb_diu.c | 4 +-
> > arch/powerpc/platforms/85xx/twr_p102x.c | 2 +-
> > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4 +-
> > arch/powerpc/platforms/8xx/adder875.c | 2 +-
> > arch/powerpc/platforms/8xx/m8xx_setup.c | 4 +-
> > arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 +-
> > arch/powerpc/platforms/8xx/mpc885ads_setup.c | 28 ++++-----
> > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 6 +-
> > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 +--
> > arch/powerpc/platforms/embedded6xx/wii.c | 10 ++--
> > arch/powerpc/sysdev/cpm1.c | 26 ++++-----
> > arch/powerpc/sysdev/cpm2.c | 16 ++---
> > arch/powerpc/sysdev/cpm_common.c | 4 +-
> > arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 8 +--
> > arch/powerpc/sysdev/fsl_lbc.c | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 8 +--
> > arch/powerpc/sysdev/fsl_pmc.c | 2 +-
> > arch/powerpc/sysdev/fsl_rcpm.c | 74 ++++++++++++------------
> > arch/powerpc/sysdev/fsl_rio.c | 4 +-
> > arch/powerpc/sysdev/fsl_rmu.c | 8 +--
> > arch/powerpc/sysdev/mpic_timer.c | 12 ++--
> > 41 files changed, 178 insertions(+), 177 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
> > index c7240a024b96..4d6a56b48a28 100644
> > --- a/arch/powerpc/include/asm/fsl_lbc.h
> > +++ b/arch/powerpc/include/asm/fsl_lbc.h
> > @@ -276,7 +276,7 @@ static inline void fsl_upm_start_pattern(struct fsl_upm *upm, u8 pat_offset)
> > */
> > static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
> > {
> > - clrbits32(upm->mxmr, MxMR_OP_RP);
> > + clrbits_be32(upm->mxmr, MxMR_OP_RP);
> >
> > while (in_be32(upm->mxmr) & MxMR_OP_RP)
> > cpu_relax();
> > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> > index e0331e754568..57486a1b9992 100644
> > --- a/arch/powerpc/include/asm/io.h
> > +++ b/arch/powerpc/include/asm/io.h
> > @@ -873,8 +873,8 @@ static inline void * bus_to_virt(unsigned long address)
> > #endif /* CONFIG_PPC32 */
> >
> > /* access ports */
> > -#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) | (_v))
> > -#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
> > +#define setbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) | (_v))
> > +#define clrbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
> >
> > #define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) | (_v))
> > #define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
> > @@ -904,6 +904,7 @@ static inline void * bus_to_virt(unsigned long address)
> > #define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
> >
> > #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
> > +#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
>
> This one already exists a few lines above.
>
> >
> > #endif /* __KERNEL__ */
> >
> > diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
> > index 157f4ce46386..6aeb4ca64d09 100644
> > --- a/arch/powerpc/platforms/44x/canyonlands.c
> > +++ b/arch/powerpc/platforms/44x/canyonlands.c
> > @@ -113,8 +113,8 @@ static int __init ppc460ex_canyonlands_fixup(void)
> > * USB2HStop and gpio19 will be USB2DStop. For more details refer to
> > * table 34-7 of PPC460EX user manual.
> > */
> > - setbits32((vaddr + GPIO0_OSRH), 0x42000000);
> > - setbits32((vaddr + GPIO0_TSRH), 0x42000000);
> > + setbits_be32((vaddr + GPIO0_OSRH), 0x42000000);
> > + setbits_be32((vaddr + GPIO0_TSRH), 0x42000000);
> > err_gpio:
> > iounmap(vaddr);
> > err_bcsr:
> > diff --git a/arch/powerpc/platforms/4xx/gpio.c b/arch/powerpc/platforms/4xx/gpio.c
> > index 2238e369cde4..8436da0617fd 100644
> > --- a/arch/powerpc/platforms/4xx/gpio.c
> > +++ b/arch/powerpc/platforms/4xx/gpio.c
> > @@ -82,9 +82,9 @@ __ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > struct ppc4xx_gpio __iomem *regs = mm_gc->regs;
> >
> > if (val)
> > - setbits32(®s->or, GPIO_MASK(gpio));
> > + setbits_be32(®s->or, GPIO_MASK(gpio));
> > else
> > - clrbits32(®s->or, GPIO_MASK(gpio));
> > + clrbits_be32(®s->or, GPIO_MASK(gpio));
> > }
> >
> > static void
> > @@ -112,18 +112,18 @@ static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> > spin_lock_irqsave(&chip->lock, flags);
> >
> > /* Disable open-drain function */
> > - clrbits32(®s->odr, GPIO_MASK(gpio));
> > + clrbits_be32(®s->odr, GPIO_MASK(gpio));
> >
> > /* Float the pin */
> > - clrbits32(®s->tcr, GPIO_MASK(gpio));
> > + clrbits_be32(®s->tcr, GPIO_MASK(gpio));
> >
> > /* Bits 0-15 use TSRL/OSRL, bits 16-31 use TSRH/OSRH */
> > if (gpio < 16) {
> > - clrbits32(®s->osrl, GPIO_MASK2(gpio));
> > - clrbits32(®s->tsrl, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->osrl, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->tsrl, GPIO_MASK2(gpio));
> > } else {
> > - clrbits32(®s->osrh, GPIO_MASK2(gpio));
> > - clrbits32(®s->tsrh, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->osrh, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->tsrh, GPIO_MASK2(gpio));
> > }
> >
> > spin_unlock_irqrestore(&chip->lock, flags);
> > @@ -145,18 +145,18 @@ ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> > __ppc4xx_gpio_set(gc, gpio, val);
> >
> > /* Disable open-drain function */
> > - clrbits32(®s->odr, GPIO_MASK(gpio));
> > + clrbits_be32(®s->odr, GPIO_MASK(gpio));
> >
> > /* Drive the pin */
> > - setbits32(®s->tcr, GPIO_MASK(gpio));
> > + setbits_be32(®s->tcr, GPIO_MASK(gpio));
> >
> > /* Bits 0-15 use TSRL, bits 16-31 use TSRH */
> > if (gpio < 16) {
> > - clrbits32(®s->osrl, GPIO_MASK2(gpio));
> > - clrbits32(®s->tsrl, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->osrl, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->tsrl, GPIO_MASK2(gpio));
> > } else {
> > - clrbits32(®s->osrh, GPIO_MASK2(gpio));
> > - clrbits32(®s->tsrh, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->osrh, GPIO_MASK2(gpio));
> > + clrbits_be32(®s->tsrh, GPIO_MASK2(gpio));
> > }
> >
> > spin_unlock_irqrestore(&chip->lock, flags);
> > diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
> > index dc81f05e0bce..06b95795267a 100644
> > --- a/arch/powerpc/platforms/512x/pdm360ng.c
> > +++ b/arch/powerpc/platforms/512x/pdm360ng.c
> > @@ -38,7 +38,7 @@ static int pdm360ng_get_pendown_state(void)
> >
> > reg = in_be32(pdm360ng_gpio_base + 0xc);
> > if (reg & 0x40)
> > - setbits32(pdm360ng_gpio_base + 0xc, 0x40);
> > + setbits_be32(pdm360ng_gpio_base + 0xc, 0x40);
> >
> > reg = in_be32(pdm360ng_gpio_base + 0x8);
> >
> > @@ -69,8 +69,8 @@ static int __init pdm360ng_penirq_init(void)
> > return -ENODEV;
> > }
> > out_be32(pdm360ng_gpio_base + 0xc, 0xffffffff);
> > - setbits32(pdm360ng_gpio_base + 0x18, 0x2000);
> > - setbits32(pdm360ng_gpio_base + 0x10, 0x40);
> > + setbits_be32(pdm360ng_gpio_base + 0x18, 0x2000);
> > + setbits_be32(pdm360ng_gpio_base + 0x10, 0x40);
> >
> > return 0;
> > }
> > diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> > index 565e3a83dc9e..edfe619d67bf 100644
> > --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> > +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> > @@ -314,13 +314,13 @@ int mpc5200_psc_ac97_gpio_reset(int psc_number)
> >
> > /* enable gpio pins for output */
> > setbits8(&wkup_gpio->wkup_gpioe, reset);
> > - setbits32(&simple_gpio->simple_gpioe, sync | out);
> > + setbits_be32(&simple_gpio->simple_gpioe, sync | out);
> >
> > setbits8(&wkup_gpio->wkup_ddr, reset);
> > - setbits32(&simple_gpio->simple_ddr, sync | out);
> > + setbits_be32(&simple_gpio->simple_ddr, sync | out);
> >
> > /* Assert cold reset */
> > - clrbits32(&simple_gpio->simple_dvo, sync | out);
> > + clrbits_be32(&simple_gpio->simple_dvo, sync | out);
> > clrbits8(&wkup_gpio->wkup_dvo, reset);
> >
> > /* wait for 1 us */
> > diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> > index 17cf249b18ee..e9f4dec06077 100644
> > --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> > +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> > @@ -142,7 +142,7 @@ static void mpc52xx_gpt_irq_unmask(struct irq_data *d)
> > unsigned long flags;
> >
> > raw_spin_lock_irqsave(&gpt->lock, flags);
> > - setbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_IRQ_EN);
> > + setbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_IRQ_EN);
> > raw_spin_unlock_irqrestore(&gpt->lock, flags);
> > }
> >
> > @@ -152,7 +152,7 @@ static void mpc52xx_gpt_irq_mask(struct irq_data *d)
> > unsigned long flags;
> >
> > raw_spin_lock_irqsave(&gpt->lock, flags);
> > - clrbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_IRQ_EN);
> > + clrbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_IRQ_EN);
> > raw_spin_unlock_irqrestore(&gpt->lock, flags);
> > }
> >
> > @@ -308,7 +308,7 @@ static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> > dev_dbg(gpt->dev, "%s: gpio:%d\n", __func__, gpio);
> >
> > raw_spin_lock_irqsave(&gpt->lock, flags);
> > - clrbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_GPIO_MASK);
> > + clrbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_GPIO_MASK);
> > raw_spin_unlock_irqrestore(&gpt->lock, flags);
> >
> > return 0;
> > @@ -482,7 +482,7 @@ int mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt)
> > return -EBUSY;
> > }
> >
> > - clrbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_COUNTER_ENABLE);
> > + clrbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_COUNTER_ENABLE);
> > raw_spin_unlock_irqrestore(&gpt->lock, flags);
> > return 0;
> > }
> > @@ -639,7 +639,7 @@ static int mpc52xx_wdt_release(struct inode *inode, struct file *file)
> > unsigned long flags;
> >
> > raw_spin_lock_irqsave(&gpt_wdt->lock, flags);
> > - clrbits32(&gpt_wdt->regs->mode,
> > + clrbits_be32(&gpt_wdt->regs->mode,
> > MPC52xx_GPT_MODE_COUNTER_ENABLE | MPC52xx_GPT_MODE_WDT_EN);
>
> The alignment needs to be fixed here (and all other places). The second
> line should start under the &
> Eventually use checkpatch to locate all places that need to be fixed.
> (checkpatch may even fix it for you)
>
Thanks, I will fix all reported problem
^ permalink raw reply
* [PATCH net-next] nfp: warn on experimental TLV types
From: Jakub Kicinski @ 2018-09-26 22:35 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Reserve two TLV types for feature development, and warn in the driver
if they ever leak into production.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c | 7 +++++++
drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h | 8 ++++++++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c
index 1f9149bb2ae6..2190836eaa1d 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c
@@ -113,6 +113,13 @@ int nfp_net_tlv_caps_parse(struct device *dev, u8 __iomem *ctrl_mem,
caps->mbox_len = length;
}
break;
+ case NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL0:
+ case NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL1:
+ dev_warn(dev,
+ "experimental TLV type:%u offset:%u len:%u\n",
+ FIELD_GET(NFP_NET_CFG_TLV_HEADER_TYPE, hdr),
+ offset, length);
+ break;
default:
if (!FIELD_GET(NFP_NET_CFG_TLV_HEADER_REQUIRED, hdr))
break;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
index 44d3ea75d043..a51490747689 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
@@ -489,12 +489,20 @@
* %NFP_NET_CFG_TLV_TYPE_MBOX:
* Variable, mailbox area. Overwrites the default location which is
* %NFP_NET_CFG_MBOX_BASE and length %NFP_NET_CFG_MBOX_VAL_MAX_SZ.
+ *
+ * %NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL0:
+ * %NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL1:
+ * Variable, experimental IDs. IDs designated for internal development and
+ * experiments before a stable TLV ID has been allocated to a feature. Should
+ * never be present in production firmware.
*/
#define NFP_NET_CFG_TLV_TYPE_UNKNOWN 0
#define NFP_NET_CFG_TLV_TYPE_RESERVED 1
#define NFP_NET_CFG_TLV_TYPE_END 2
#define NFP_NET_CFG_TLV_TYPE_ME_FREQ 3
#define NFP_NET_CFG_TLV_TYPE_MBOX 4
+#define NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL0 5
+#define NFP_NET_CFG_TLV_TYPE_EXPERIMENTAL1 6
struct device;
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv2 bpf-next 08/11] selftests/bpf: Add tests for reference tracking
From: Joe Stringer @ 2018-09-26 22:31 UTC (permalink / raw)
To: daniel
Cc: Joe Stringer, ast, netdev, john fastabend, tgraf,
Martin KaFai Lau, Nitin Hande, mauricio.vasquez
In-Reply-To: <3bdb6449-41ce-ef1a-b845-c55f6d44775d@iogearbox.net>
On Mon, 24 Sep 2018 at 05:22, Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 09/21/2018 07:10 PM, Joe Stringer wrote:
> > reference tracking: leak potential reference
> > reference tracking: leak potential reference on stack
> > reference tracking: leak potential reference on stack 2
> > reference tracking: zero potential reference
> > reference tracking: copy and zero potential references
> > reference tracking: release reference without check
> > reference tracking: release reference
> > reference tracking: release reference twice
> > reference tracking: release reference twice inside branch
> > reference tracking: alloc, check, free in one subbranch
> > reference tracking: alloc, check, free in both subbranches
> > reference tracking in call: free reference in subprog
> > reference tracking in call: free reference in subprog and outside
> > reference tracking in call: alloc & leak reference in subprog
> > reference tracking in call: alloc in subprog, release outside
> > reference tracking in call: sk_ptr leak into caller stack
> > reference tracking in call: sk_ptr spill into caller stack
> >
> > Signed-off-by: Joe Stringer <joe@wand.net.nz>
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> > ---
> > tools/testing/selftests/bpf/test_verifier.c | 359 ++++++++++++++++++++
> > 1 file changed, 359 insertions(+)
>
> I think this here needs to have some more test cases that we current do not track but
> should in order to have better coverage. At minimum what comes to mind additionally:
>
> - verifier interaction with LD_ABS, LD_IND
> - verifier interaction with tail calls (e.g. try to leak socket, socket_or_null, etc,
> but should also have a positive test where we drop ref before tail call to show it
> works in combination)
> - Try to mangle a socket and socket_or_null pointer with ALU ops and pass it to helper
> - Try to access the socket data fields after we released its reference
> - Access socket member fields in general (I think not present right now)
> - Use direct packet access in combination with lookup helper (it's enabled
> via pkt_access = true in the helper, so we should also test for it here to make
> sure future changes don't break it)
Great suggestions, I think that the LD_ABS/LD_IND ones are good
candidates for the assembly-level tests here. For the remainder, I
plan to add them to the C cases. That'll be easier to review and
easier to understand if they ever get broken.
Regarding the direct packet access with lookup, that's already in this
series in the C verifier tests patch.
^ permalink raw reply
* [PATCH bpf-next 4/5] selftests/bpf: Use libbpf_attach_type_by_name in test_socket_cookie
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Use newly introduced libbpf_attach_type_by_name in test_socket_cookie
selftest.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/testing/selftests/bpf/test_socket_cookie.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_socket_cookie.c b/tools/testing/selftests/bpf/test_socket_cookie.c
index 68e108e4687a..b6c2c605d8c0 100644
--- a/tools/testing/selftests/bpf/test_socket_cookie.c
+++ b/tools/testing/selftests/bpf/test_socket_cookie.c
@@ -158,11 +158,7 @@ static int run_test(int cgfd)
bpf_object__for_each_program(prog, pobj) {
prog_name = bpf_program__title(prog, /*needs_copy*/ false);
- if (strcmp(prog_name, "cgroup/connect6") == 0) {
- attach_type = BPF_CGROUP_INET6_CONNECT;
- } else if (strcmp(prog_name, "sockops") == 0) {
- attach_type = BPF_CGROUP_SOCK_OPS;
- } else {
+ if (libbpf_attach_type_by_name(prog_name, &attach_type)) {
log_err("Unexpected prog: %s", prog_name);
goto err;
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 5/5] selftests/bpf: Test libbpf_{prog,attach}_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add selftest for libbpf functions libbpf_prog_type_by_name and
libbpf_attach_type_by_name.
Example of output:
% ./tools/testing/selftests/bpf/test_section_names
Summary: 35 PASSED, 0 FAILED
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/test_section_names.c | 208 ++++++++++++++++++
2 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/test_section_names.c
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index fd3851d5c079..059d64a0f897 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -23,7 +23,7 @@ $(TEST_CUSTOM_PROGS): $(OUTPUT)/%: %.c
TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
test_sock test_btf test_sockmap test_lirc_mode2_user get_cgroup_id_user \
- test_socket_cookie test_cgroup_storage test_select_reuseport
+ test_socket_cookie test_cgroup_storage test_select_reuseport test_section_names
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
test_pkt_md_access.o test_xdp_redirect.o test_xdp_meta.o sockmap_parse_prog.o \
diff --git a/tools/testing/selftests/bpf/test_section_names.c b/tools/testing/selftests/bpf/test_section_names.c
new file mode 100644
index 000000000000..7c4f41572b1c
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_section_names.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 Facebook
+
+#include <err.h>
+#include <bpf/libbpf.h>
+
+#include "bpf_util.h"
+
+struct sec_name_test {
+ const char sec_name[32];
+ struct {
+ int rc;
+ enum bpf_prog_type prog_type;
+ enum bpf_attach_type expected_attach_type;
+ } expected_load;
+ struct {
+ int rc;
+ enum bpf_attach_type attach_type;
+ } expected_attach;
+};
+
+static struct sec_name_test tests[] = {
+ {"InvAliD", {-EINVAL, 0, 0}, {-EINVAL, 0} },
+ {"cgroup", {-EINVAL, 0, 0}, {-EINVAL, 0} },
+ {"socket", {0, BPF_PROG_TYPE_SOCKET_FILTER, 0}, {-EINVAL, 0} },
+ {"kprobe/", {0, BPF_PROG_TYPE_KPROBE, 0}, {-EINVAL, 0} },
+ {"kretprobe/", {0, BPF_PROG_TYPE_KPROBE, 0}, {-EINVAL, 0} },
+ {"classifier", {0, BPF_PROG_TYPE_SCHED_CLS, 0}, {-EINVAL, 0} },
+ {"action", {0, BPF_PROG_TYPE_SCHED_ACT, 0}, {-EINVAL, 0} },
+ {"tracepoint/", {0, BPF_PROG_TYPE_TRACEPOINT, 0}, {-EINVAL, 0} },
+ {
+ "raw_tracepoint/",
+ {0, BPF_PROG_TYPE_RAW_TRACEPOINT, 0},
+ {-EINVAL, 0},
+ },
+ {"xdp", {0, BPF_PROG_TYPE_XDP, 0}, {-EINVAL, 0} },
+ {"perf_event", {0, BPF_PROG_TYPE_PERF_EVENT, 0}, {-EINVAL, 0} },
+ {"lwt_in", {0, BPF_PROG_TYPE_LWT_IN, 0}, {-EINVAL, 0} },
+ {"lwt_out", {0, BPF_PROG_TYPE_LWT_OUT, 0}, {-EINVAL, 0} },
+ {"lwt_xmit", {0, BPF_PROG_TYPE_LWT_XMIT, 0}, {-EINVAL, 0} },
+ {"lwt_seg6local", {0, BPF_PROG_TYPE_LWT_SEG6LOCAL, 0}, {-EINVAL, 0} },
+ {
+ "cgroup_skb/ingress",
+ {0, BPF_PROG_TYPE_CGROUP_SKB, 0},
+ {0, BPF_CGROUP_INET_INGRESS},
+ },
+ {
+ "cgroup_skb/egress",
+ {0, BPF_PROG_TYPE_CGROUP_SKB, 0},
+ {0, BPF_CGROUP_INET_EGRESS},
+ },
+ {"cgroup/skb", {0, BPF_PROG_TYPE_CGROUP_SKB, 0}, {-EINVAL, 0} },
+ {
+ "cgroup/sock",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, 0},
+ {0, BPF_CGROUP_INET_SOCK_CREATE},
+ },
+ {
+ "cgroup/post_bind4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, BPF_CGROUP_INET4_POST_BIND},
+ {0, BPF_CGROUP_INET4_POST_BIND},
+ },
+ {
+ "cgroup/post_bind6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, BPF_CGROUP_INET6_POST_BIND},
+ {0, BPF_CGROUP_INET6_POST_BIND},
+ },
+ {
+ "cgroup/dev",
+ {0, BPF_PROG_TYPE_CGROUP_DEVICE, 0},
+ {0, BPF_CGROUP_DEVICE},
+ },
+ {"sockops", {0, BPF_PROG_TYPE_SOCK_OPS, 0}, {0, BPF_CGROUP_SOCK_OPS} },
+ {
+ "sk_skb/stream_parser",
+ {0, BPF_PROG_TYPE_SK_SKB, 0},
+ {0, BPF_SK_SKB_STREAM_PARSER},
+ },
+ {
+ "sk_skb/stream_verdict",
+ {0, BPF_PROG_TYPE_SK_SKB, 0},
+ {0, BPF_SK_SKB_STREAM_VERDICT},
+ },
+ {"sk_skb", {0, BPF_PROG_TYPE_SK_SKB, 0}, {-EINVAL, 0} },
+ {"sk_msg", {0, BPF_PROG_TYPE_SK_MSG, 0}, {0, BPF_SK_MSG_VERDICT} },
+ {"lirc_mode2", {0, BPF_PROG_TYPE_LIRC_MODE2, 0}, {0, BPF_LIRC_MODE2} },
+ {
+ "flow_dissector",
+ {0, BPF_PROG_TYPE_FLOW_DISSECTOR, 0},
+ {0, BPF_FLOW_DISSECTOR},
+ },
+ {
+ "cgroup/bind4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET4_BIND},
+ {0, BPF_CGROUP_INET4_BIND},
+ },
+ {
+ "cgroup/bind6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET6_BIND},
+ {0, BPF_CGROUP_INET6_BIND},
+ },
+ {
+ "cgroup/connect4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET4_CONNECT},
+ {0, BPF_CGROUP_INET4_CONNECT},
+ },
+ {
+ "cgroup/connect6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET6_CONNECT},
+ {0, BPF_CGROUP_INET6_CONNECT},
+ },
+ {
+ "cgroup/sendmsg4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_UDP4_SENDMSG},
+ {0, BPF_CGROUP_UDP4_SENDMSG},
+ },
+ {
+ "cgroup/sendmsg6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_UDP6_SENDMSG},
+ {0, BPF_CGROUP_UDP6_SENDMSG},
+ },
+};
+
+static int test_prog_type_by_name(const struct sec_name_test *test)
+{
+ enum bpf_attach_type expected_attach_type;
+ enum bpf_prog_type prog_type;
+ int rc;
+
+ rc = libbpf_prog_type_by_name(test->sec_name, &prog_type,
+ &expected_attach_type);
+
+ if (rc != test->expected_load.rc) {
+ warnx("prog: unexpected rc=%d for %s", rc, test->sec_name);
+ return -1;
+ }
+
+ if (rc)
+ return 0;
+
+ if (prog_type != test->expected_load.prog_type) {
+ warnx("prog: unexpected prog_type=%d for %s", prog_type,
+ test->sec_name);
+ return -1;
+ }
+
+ if (expected_attach_type != test->expected_load.expected_attach_type) {
+ warnx("prog: unexpected expected_attach_type=%d for %s",
+ expected_attach_type, test->sec_name);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int test_attach_type_by_name(const struct sec_name_test *test)
+{
+ enum bpf_attach_type attach_type;
+ int rc;
+
+ rc = libbpf_attach_type_by_name(test->sec_name, &attach_type);
+
+ if (rc != test->expected_attach.rc) {
+ warnx("attach: unexpected rc=%d for %s", rc, test->sec_name);
+ return -1;
+ }
+
+ if (rc)
+ return 0;
+
+ if (attach_type != test->expected_attach.attach_type) {
+ warnx("attach: unexpected attach_type=%d for %s", attach_type,
+ test->sec_name);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int run_test_case(const struct sec_name_test *test)
+{
+ if (test_prog_type_by_name(test))
+ return -1;
+ if (test_attach_type_by_name(test))
+ return -1;
+ return 0;
+}
+
+static int run_tests(void)
+{
+ int passes = 0;
+ int fails = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(tests); ++i) {
+ if (run_test_case(&tests[i]))
+ ++fails;
+ else
+ ++passes;
+ }
+ printf("Summary: %d PASSED, %d FAILED\n", passes, fails);
+ return fails ? -1 : 0;
+}
+
+int main(int argc, char **argv)
+{
+ return run_tests();
+}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/5] libbpf: Introduce libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
There is a common use-case when ELF object contains multiple BPF
programs and every program has its own section name. If it's cgroup-bpf
then programs have to be 1) loaded and 2) attached to a cgroup.
It's convenient to have information necessary to load BPF program
together with program itself. This is where section name works fine in
conjunction with libbpf_prog_type_by_name that identifies prog_type and
expected_attach_type and these can be used with BPF_PROG_LOAD.
But there is currently no way to identify attach_type by section name
and it leads to messy code in user space that reinvents guessing logic
every time it has to identify attach type to use with BPF_PROG_ATTACH.
The patch introduces libbpf_attach_type_by_name that guesses attach type
by section name if a program can be attached.
The difference between expected_attach_type provided by
libbpf_prog_type_by_name and attach_type provided by
libbpf_attach_type_by_name is the former is used at BPF_PROG_LOAD time
and can be zero if a program of prog_type X has only one corresponding
attach type Y whether the latter provides specific attach type to use
with BPF_PROG_ATTACH.
No new section names were added to section_names array. Only existing
ones were reorganized and attach_type was added where appropriate.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 121 ++++++++++++++++++++++++++++-------------
tools/lib/bpf/libbpf.h | 2 +
2 files changed, 84 insertions(+), 39 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4f8d43ae20d2..59e589a64d5c 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2085,58 +2085,82 @@ void bpf_program__set_expected_attach_type(struct bpf_program *prog,
prog->expected_attach_type = type;
}
-#define BPF_PROG_SEC_FULL(string, ptype, atype) \
- { string, sizeof(string) - 1, ptype, atype }
+#define BPF_PROG_SEC_IMPL(string, ptype, eatype, atype) \
+ { string, sizeof(string) - 1, ptype, eatype, atype }
-#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_FULL(string, ptype, 0)
+/* Programs that can NOT be attached. */
+#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, -EINVAL)
-#define BPF_S_PROG_SEC(string, ptype) \
- BPF_PROG_SEC_FULL(string, BPF_PROG_TYPE_CGROUP_SOCK, ptype)
+/* Programs that can be attached. */
+#define BPF_APROG_SEC(string, ptype, atype) \
+ BPF_PROG_SEC_IMPL(string, ptype, 0, atype)
-#define BPF_SA_PROG_SEC(string, ptype) \
- BPF_PROG_SEC_FULL(string, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, ptype)
+/* Programs that must specify expected attach type at load time. */
+#define BPF_EAPROG_SEC(string, ptype, eatype) \
+ BPF_PROG_SEC_IMPL(string, ptype, eatype, eatype)
+
+/* Programs that can be attached but attach type can't be identified by section
+ * name. Kept for backward compatibility.
+ */
+#define BPF_APROG_COMPAT(string, ptype) BPF_PROG_SEC(string, ptype)
static const struct {
const char *sec;
size_t len;
enum bpf_prog_type prog_type;
enum bpf_attach_type expected_attach_type;
+ enum bpf_attach_type attach_type;
} section_names[] = {
- BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
- BPF_PROG_SEC("kprobe/", BPF_PROG_TYPE_KPROBE),
- BPF_PROG_SEC("kretprobe/", BPF_PROG_TYPE_KPROBE),
- BPF_PROG_SEC("classifier", BPF_PROG_TYPE_SCHED_CLS),
- BPF_PROG_SEC("action", BPF_PROG_TYPE_SCHED_ACT),
- BPF_PROG_SEC("tracepoint/", BPF_PROG_TYPE_TRACEPOINT),
- BPF_PROG_SEC("raw_tracepoint/", BPF_PROG_TYPE_RAW_TRACEPOINT),
- BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP),
- BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT),
- BPF_PROG_SEC("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
- BPF_PROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK),
- BPF_PROG_SEC("cgroup/dev", BPF_PROG_TYPE_CGROUP_DEVICE),
- BPF_PROG_SEC("lwt_in", BPF_PROG_TYPE_LWT_IN),
- BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
- BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
- BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
- BPF_PROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS),
- BPF_PROG_SEC("sk_skb", BPF_PROG_TYPE_SK_SKB),
- BPF_PROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG),
- BPF_PROG_SEC("lirc_mode2", BPF_PROG_TYPE_LIRC_MODE2),
- BPF_PROG_SEC("flow_dissector", BPF_PROG_TYPE_FLOW_DISSECTOR),
- BPF_SA_PROG_SEC("cgroup/bind4", BPF_CGROUP_INET4_BIND),
- BPF_SA_PROG_SEC("cgroup/bind6", BPF_CGROUP_INET6_BIND),
- BPF_SA_PROG_SEC("cgroup/connect4", BPF_CGROUP_INET4_CONNECT),
- BPF_SA_PROG_SEC("cgroup/connect6", BPF_CGROUP_INET6_CONNECT),
- BPF_SA_PROG_SEC("cgroup/sendmsg4", BPF_CGROUP_UDP4_SENDMSG),
- BPF_SA_PROG_SEC("cgroup/sendmsg6", BPF_CGROUP_UDP6_SENDMSG),
- BPF_S_PROG_SEC("cgroup/post_bind4", BPF_CGROUP_INET4_POST_BIND),
- BPF_S_PROG_SEC("cgroup/post_bind6", BPF_CGROUP_INET6_POST_BIND),
+ BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
+ BPF_PROG_SEC("kprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("kretprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("classifier", BPF_PROG_TYPE_SCHED_CLS),
+ BPF_PROG_SEC("action", BPF_PROG_TYPE_SCHED_ACT),
+ BPF_PROG_SEC("tracepoint/", BPF_PROG_TYPE_TRACEPOINT),
+ BPF_PROG_SEC("raw_tracepoint/", BPF_PROG_TYPE_RAW_TRACEPOINT),
+ BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP),
+ BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT),
+ BPF_PROG_SEC("lwt_in", BPF_PROG_TYPE_LWT_IN),
+ BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
+ BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
+ BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
+ BPF_APROG_COMPAT("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
+ BPF_APROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET_SOCK_CREATE),
+ BPF_EAPROG_SEC("cgroup/post_bind4", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET4_POST_BIND),
+ BPF_EAPROG_SEC("cgroup/post_bind6", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET6_POST_BIND),
+ BPF_APROG_SEC("cgroup/dev", BPF_PROG_TYPE_CGROUP_DEVICE,
+ BPF_CGROUP_DEVICE),
+ BPF_APROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS,
+ BPF_CGROUP_SOCK_OPS),
+ BPF_APROG_COMPAT("sk_skb", BPF_PROG_TYPE_SK_SKB),
+ BPF_APROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG,
+ BPF_SK_MSG_VERDICT),
+ BPF_APROG_SEC("lirc_mode2", BPF_PROG_TYPE_LIRC_MODE2,
+ BPF_LIRC_MODE2),
+ BPF_APROG_SEC("flow_dissector", BPF_PROG_TYPE_FLOW_DISSECTOR,
+ BPF_FLOW_DISSECTOR),
+ BPF_EAPROG_SEC("cgroup/bind4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET4_BIND),
+ BPF_EAPROG_SEC("cgroup/bind6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET6_BIND),
+ BPF_EAPROG_SEC("cgroup/connect4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET4_CONNECT),
+ BPF_EAPROG_SEC("cgroup/connect6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET6_CONNECT),
+ BPF_EAPROG_SEC("cgroup/sendmsg4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_UDP4_SENDMSG),
+ BPF_EAPROG_SEC("cgroup/sendmsg6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_UDP6_SENDMSG),
};
+#undef BPF_PROG_SEC_IMPL
#undef BPF_PROG_SEC
-#undef BPF_PROG_SEC_FULL
-#undef BPF_S_PROG_SEC
-#undef BPF_SA_PROG_SEC
+#undef BPF_APROG_SEC
+#undef BPF_EAPROG_SEC
+#undef BPF_APROG_COMPAT
int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
enum bpf_attach_type *expected_attach_type)
@@ -2156,6 +2180,25 @@ int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
return -EINVAL;
}
+int libbpf_attach_type_by_name(const char *name,
+ enum bpf_attach_type *attach_type)
+{
+ int i;
+
+ if (!name)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(section_names); i++) {
+ if (strncmp(name, section_names[i].sec, section_names[i].len))
+ continue;
+ if (section_names[i].attach_type == -EINVAL)
+ return -EINVAL;
+ *attach_type = section_names[i].attach_type;
+ return 0;
+ }
+ return -EINVAL;
+}
+
static int
bpf_program__identify_section(struct bpf_program *prog,
enum bpf_prog_type *prog_type,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e3b00e23e181..511c1294dcbf 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -104,6 +104,8 @@ void *bpf_object__priv(struct bpf_object *prog);
int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
enum bpf_attach_type *expected_attach_type);
+int libbpf_attach_type_by_name(const char *name,
+ enum bpf_attach_type *attach_type);
/* Accessors of bpf_program */
struct bpf_program;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 3/5] libbpf: Support sk_skb/stream_{parser,verdict} section names
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add section names for BPF_SK_SKB_STREAM_PARSER and
BPF_SK_SKB_STREAM_VERDICT attach types to be able to identify them in
libbpf_attach_type_by_name.
"stream_parser" and "stream_verdict" are used instead of simple "parser"
and "verdict" just to avoid possible confusion in a place where attach
type is used alone (e.g. in bpftool's show sub-commands) since there is
another attach point that can be named as "verdict": BPF_SK_MSG_VERDICT.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 51edf6cd390e..425d5ca45c97 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2139,6 +2139,10 @@ static const struct {
BPF_CGROUP_DEVICE),
BPF_APROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS,
BPF_CGROUP_SOCK_OPS),
+ BPF_APROG_SEC("sk_skb/stream_parser", BPF_PROG_TYPE_SK_SKB,
+ BPF_SK_SKB_STREAM_PARSER),
+ BPF_APROG_SEC("sk_skb/stream_verdict", BPF_PROG_TYPE_SK_SKB,
+ BPF_SK_SKB_STREAM_VERDICT),
BPF_APROG_COMPAT("sk_skb", BPF_PROG_TYPE_SK_SKB),
BPF_APROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG,
BPF_SK_MSG_VERDICT),
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 0/5] Introduce libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
This patch set introduces libbpf_attach_type_by_name function in libbpf to
identify attach type by section name.
This is useful to avoid writing same logic over and over again in user
space applications that leverage libbpf.
Patch 1 has more details on the new function and problem being solved.
Patches 2 and 3 add support for new section names.
Patch 4 uses new function in a selftest.
Patch 5 adds selftest for libbpf_{prog,attach}_type_by_name.
As a side note there are a lot of inconsistencies now between names used by
libbpf and bpftool (e.g. cgroup/skb vs cgroup_skb, cgroup_device and device
vs cgroup/dev, sockops vs sock_ops, etc). This patch set does not address
it but it tries not to make it harder to address it in the future.
Andrey Ignatov (5):
libbpf: Introduce libbpf_attach_type_by_name
libbpf: Support cgroup_skb/{e,in}gress section names
libbpf: Support sk_skb/stream_{parser,verdict} section names
selftests/bpf: Use libbpf_attach_type_by_name in test_socket_cookie
selftests/bpf: Test libbpf_{prog,attach}_type_by_name
tools/lib/bpf/libbpf.c | 129 +++++++----
tools/lib/bpf/libbpf.h | 2 +
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/test_section_names.c | 208 ++++++++++++++++++
.../selftests/bpf/test_socket_cookie.c | 6 +-
5 files changed, 302 insertions(+), 45 deletions(-)
create mode 100644 tools/testing/selftests/bpf/test_section_names.c
--
2.17.1
^ permalink raw reply
* [PATCH bpf-next 2/5] libbpf: Support cgroup_skb/{e,in}gress section names
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add section names for BPF_CGROUP_INET_INGRESS and BPF_CGROUP_INET_EGRESS
attach types to be able to identify them in libbpf_attach_type_by_name.
"cgroup_skb" is used instead of "cgroup/skb" mostly to easy possible
unifying of how libbpf and bpftool works with section names:
* bpftool uses "cgroup_skb" to in "prog list" sub-command;
* bpftool uses "ingress" and "egress" in "cgroup list" sub-command;
* having two parts instead of three in a string like "cgroup_skb/ingress"
can be leveraged to split it to prog_type part and attach_type part,
or vise versa: use two parts to make a section name.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 59e589a64d5c..51edf6cd390e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2124,6 +2124,10 @@ static const struct {
BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
+ BPF_APROG_SEC("cgroup_skb/ingress", BPF_PROG_TYPE_CGROUP_SKB,
+ BPF_CGROUP_INET_INGRESS),
+ BPF_APROG_SEC("cgroup_skb/egress", BPF_PROG_TYPE_CGROUP_SKB,
+ BPF_CGROUP_INET_EGRESS),
BPF_APROG_COMPAT("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
BPF_APROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK,
BPF_CGROUP_INET_SOCK_CREATE),
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v2] wireless-drivers: rtnetlink wifi simulation device
From: Kalle Valo @ 2018-09-27 4:34 UTC (permalink / raw)
To: Cody Schuffelen
Cc: Johannes Berg, David S . Miller, linux-kernel, linux-wireless,
netdev, kernel-team
In-Reply-To: <20180926194324.71290-1-schuffelen@google.com>
Cody Schuffelen <schuffelen@google.com> writes:
> This device takes over an existing network device and produces a
> new one that appears like a wireless connection, returning enough canned
> responses to nl80211 to satisfy a standard network manager. If
> necessary, it can also be set up one step removed from an existing
> network device, such as through a vlan/80211Q or macvlan connection to
> not disrupt the existing network interface.
>
> To use it to wrap a bare ethernet connection:
>
> ip link set eth0 down
> ip link set eth0 name buried_eth0
> ip link set buried_eth0 up
> ip link add link buried_eth0 name wlan0 type virt_wifi
>
> eth0 is renamed to buried_eth0 to avoid a network manager trying to
> manage it, as the original network link will become unusuable and only
> the wireless wrapper will be functional. This can also be combined with
> vlan or macvlan links on top of eth0 to share the network between
> distinct links, but that requires support outside the machine for
> accepting vlan-tagged packets or packets from multiple MAC addresses.
>
> This is being used for Google's Remote Android Virtual Device project,
> which runs Android devices in virtual machines. The standard network
> interfaces provided inside the virtual machines are all ethernet.
> However, Android is not interested in ethernet devices and would rather
> connect to a wireless interface. This patch allows the virtual machine
> guest to treat one of its network connections as wireless rather than
> ethernet, satisfying Android's network connection requirements.
>
> We believe this is a generally useful driver for simulating wireless
> network connections in other environments where a wireless connection is
> desired by some userspace process but is not available. Future work can
> also include exporting the wireless control plane to userspace, so the
> device can configure the behavior of the simulated wireless network
> itself.
>
> This is distinct from other testing efforts such as mac80211_hwsim by
> being a cfg80211 device instead of mac80211 device, allowing straight
> pass-through on the data plane instead of forcing packaging of ethernet
> data into mac80211 frames.
>
> Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
> Acked-by: Alistair Strachan <astrachan@google.com>
> Acked-by: Greg Hartman <ghartman@google.com>
> Signed-off-by: Cody Schuffelen <schuffelen@google.com>
[...]
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
> @@ -114,4 +114,11 @@ config USB_NET_RNDIS_WLAN
>
> If you choose to build a module, it'll be called rndis_wlan.
>
> +config VIRT_WIFI
> + tristate "Wifi wrapper for ethernet drivers"
> + default n
Isn't 'n' the default so you don't need to explicitly set that?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next v2] wireless-drivers: rtnetlink wifi simulation device
From: Kalle Valo @ 2018-09-27 4:33 UTC (permalink / raw)
To: Cody Schuffelen
Cc: Johannes Berg, David S . Miller, linux-kernel, linux-wireless,
netdev, kernel-team
In-Reply-To: <20180926194324.71290-1-schuffelen@google.com>
Cody Schuffelen <schuffelen@google.com> writes:
> This device takes over an existing network device and produces a
> new one that appears like a wireless connection, returning enough canned
> responses to nl80211 to satisfy a standard network manager. If
> necessary, it can also be set up one step removed from an existing
> network device, such as through a vlan/80211Q or macvlan connection to
> not disrupt the existing network interface.
>
> To use it to wrap a bare ethernet connection:
>
> ip link set eth0 down
> ip link set eth0 name buried_eth0
> ip link set buried_eth0 up
> ip link add link buried_eth0 name wlan0 type virt_wifi
>
> eth0 is renamed to buried_eth0 to avoid a network manager trying to
> manage it, as the original network link will become unusuable and only
> the wireless wrapper will be functional. This can also be combined with
> vlan or macvlan links on top of eth0 to share the network between
> distinct links, but that requires support outside the machine for
> accepting vlan-tagged packets or packets from multiple MAC addresses.
>
> This is being used for Google's Remote Android Virtual Device project,
> which runs Android devices in virtual machines. The standard network
> interfaces provided inside the virtual machines are all ethernet.
> However, Android is not interested in ethernet devices and would rather
> connect to a wireless interface. This patch allows the virtual machine
> guest to treat one of its network connections as wireless rather than
> ethernet, satisfying Android's network connection requirements.
>
> We believe this is a generally useful driver for simulating wireless
> network connections in other environments where a wireless connection is
> desired by some userspace process but is not available. Future work can
> also include exporting the wireless control plane to userspace, so the
> device can configure the behavior of the simulated wireless network
> itself.
>
> This is distinct from other testing efforts such as mac80211_hwsim by
> being a cfg80211 device instead of mac80211 device, allowing straight
> pass-through on the data plane instead of forcing packaging of ethernet
> data into mac80211 frames.
>
> Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
> Acked-by: Alistair Strachan <astrachan@google.com>
> Acked-by: Greg Hartman <ghartman@google.com>
> Signed-off-by: Cody Schuffelen <schuffelen@google.com>
> ---
> Original change: https://lore.kernel.org/lkml/5b5b8e09.1c69fb81.c693c.0acd@mx.google.com/
> First review: https://lore.kernel.org/lkml/1535460343.5895.56.camel@sipsolutions.net/
>
> Thanks for the detailed review! I believe I've addressed all comments.
BTW, this will likely go through mac80211-next, so don't add net-next to
the subject to avoid Dave getting confused. But no need to resend
because of this.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH v2 bpf-next 0/2] verifier liveness simplification
From: Jiong Wang @ 2018-09-26 22:16 UTC (permalink / raw)
To: Edward Cree, ast, daniel; +Cc: netdev
In-Reply-To: <d16ea072-61a0-8f8a-aca1-13cac09d3d14@solarflare.com>
On 22/08/2018 20:00, Edward Cree wrote:
> The first patch is a simplification of register liveness tracking by using
> a separate parentage chain for each register and stack slot, thus avoiding
> the need for logic to handle callee-saved registers when applying read
> marks. In the future this idea may be extended to form use-def chains.
Interesting.
This could potentially help efficient code-gen for 32-bit architectures and I
had been thinking some implementations along this line and would like to have
a discussion.
Program description
===
It will be good if we could know one instruction is safe to operate on low
32-bit sub-register only. If this is true:
- 32-bit arches could save some code-gen.
- 64-bit arches could utilize 32-bit sub-register instructions.
Algorithm
===
Based on the current verifier code-path-walker, it looks to me we could get
32-bit safety information using the following algorithm:
1. assume all instructions operate on 32-bit sub-register initially.
2. link each insn to insns which define its use.
3. for a register use, if it is a 64-bit write back to memory, or if it is
a comparison-then-jump based on 64-bit value, or if it is a right shift,
then consider the use is a 64-bit use, then all its define insns and their
parents define insns should be marked as need full 64-bit operation.
4. currently, register read (REG_LIVE_READ) will be propagated to parent
state when path prune happened, and REG_LIVE_WRITTEN would screen off such
propagation. We need to propagate 64-bit mark in similar way, but
REG_LIVE_WRITTEN shouldn't screen off backward 64-bit mark propagation if
the written reg also used as source reg (this has raised REG_LIVE_READ
propagation but it is not necessarily indicating 64-bit read) in the same
instruction.
Implementation
===
And it seems there could be an implementation based on current liveness tracking
infrastructure without dramatic change.
1. instruction level use->def chain
- new active_defs array for each call frame to record which insn the active
define of one register comes from. callee copies active_defs from caller
for argument registers only, and copies active_def of R0 to caller when
exit.
struct bpf_func_state {
...
s16 active_defs[__MAX_BPF_REG];
- new use->def chains for each instruction. one eBPF insn could have two
uses at maximum. also one new boolean "full_ref_def" added to keep the
final 32-bit safety information. it will be true if this instruction
needs to operate on full 64-bit.
bpf_insn_aux_data {
...
struct {
s16 def[2];
bool full_ref_def;
};
2. Inside mark_reg_read, split SRC_OP to SRC0_OP/SRC1_OP/SRC_OP_64/SRC1_OP_64
to indicate one register read if from the first or second use slot of this
instruction, and to indicate whether the read is on full 64-bit which will
only be true if the read is for 64-bit write back to memory, or 64-bit
comparison-then-jump, or bit right shift means 64-bit.
Build use->def chain for any read, but do 64-bit backward propagation
for 64-bit read only. The propagation is to set full_ref_def to true for
def and parent defs of the 64-bit read.
3. Need new bpf_reg_liveness enum, REG_LIVE_READ64 to indicate there is
64-bit access to one register in the pruned path, and need
REG_LIVE_WRITTEN64 to indicate a write that is REG_LIVE_WRITTEN but should
not screen backward propagate 64-bit read info.
#define REG_LIVE_NONE 0
#define REG_LIVE_READ BIT(0)
#define REG_LIVE_READ64 BIT(1)
#define REG_LIVE_WRITTEN BIT(2)
#define REG_LIVE_WRITTEN64 BIT(3)
I might have missed something in above thoughts, would appreciate reviews and
suggestions. I will also send out some concrete patches later.
Regards,
Jiong
^ permalink raw reply
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Andrew Lunn @ 2018-09-26 21:58 UTC (permalink / raw)
To: Neil Horman
Cc: Chris Preimesberger, linville@tuxdriver.com,
netdev@vger.kernel.org
In-Reply-To: <20180926213436.GA4116@hmswarspite.think-freely.org>
> When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> to determine the length of the eeprom, and that value will be either 256 or 512
> bytes.
So it sounds like QSFP modules using 8636 are not supported. You would
expect a size to be one of 256, 384, 512 or 640.
> Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> from hardware, again, passing in 256 as the size for the first call (theres a
> loop, but it will only get executed once in this scenario)
>
> mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
> return data is of type mlx4_mad_ifc, which has some front matter information and
> a data buffer that is 192 bytes long!
Which suggests all SFP dumps are broken as well, not just QSFP.
Oh dear.
Andrew
^ permalink raw reply
* [PATCH net] r8169: Enable MSI-X on RTL8106e
From: Jian-Hong Pan @ 2018-09-27 4:09 UTC (permalink / raw)
To: David S . Miller, Heiner Kallweit
Cc: Realtek linux nic maintainers, netdev, linux-kernel,
kai.heng.feng, linux, Jian-Hong Pan
Originally, we have an issue where r8169 MSI-X interrupt is broken after
S3 suspend/resume on RTL8106e of ASUS X441UAR.
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
(rev 07)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast
Ethernet controller [1043:200f]
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at e000 [size=256]
Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
Memory at e0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-36-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
Kernel modules: r8169
We found the all of the values in PCI BAR=4 of the ethernet adapter
become 0xFF after system resumes. That breaks the MSI-X interrupt.
Therefore, we can only fall back to MSI interrupt to fix the issue at
that time.
However, there is a commit which resolves the drivers getting nothing in
PCI BAR=4 after system resumes. It is 04cb3ae895d7 "PCI: Reprogram
bridge prefetch registers on resume" by Daniel Drake.
After apply the patch, the ethernet adapter works fine before suspend
and after resume. So, we can revert the workaround after the commit
"PCI: Reprogram bridge prefetch registers on resume" is merged into main
tree.
This patch reverts commit 7bb05b85bc2d1a1b647b91424b2ed4a18e6ecd81
"r8169: don't use MSI-X on RTL8106e".
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=201181
Fixes: 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e")
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
---
drivers/net/ethernet/realtek/r8169.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bb529ff2ca81..445508c7e067 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7084,20 +7084,17 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
{
unsigned int flags;
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_01 ... RTL_GIGA_MAC_VER_06:
+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06) {
RTL_W8(tp, Cfg9346, Cfg9346_Unlock);
RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~MSIEnable);
RTL_W8(tp, Cfg9346, Cfg9346_Lock);
flags = PCI_IRQ_LEGACY;
- break;
- case RTL_GIGA_MAC_VER_39 ... RTL_GIGA_MAC_VER_40:
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_40) {
/* This version was reported to have issues with resume
* from suspend when using MSI-X
*/
flags = PCI_IRQ_LEGACY | PCI_IRQ_MSI;
- break;
- default:
+ } else {
flags = PCI_IRQ_ALL_TYPES;
}
--
2.11.0
^ permalink raw reply related
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Andrew Lunn @ 2018-09-26 21:46 UTC (permalink / raw)
To: Chris Preimesberger; +Cc: linville@tuxdriver.com, netdev@vger.kernel.org
In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F64838C@CSI-MAILSRV.csicompanies.internal>
On Wed, Sep 26, 2018 at 08:47:34PM +0000, Chris Preimesberger wrote:
> Hello Andrew,
>
> Thank you for the quick response!!
> Apologies in advance for my use of outlook and top-posting, etc...
>
> I've run the raw option and the hex option, and pasted the results below.
> Since the raw option printed strange characters on the CLI, I re-ran it,
> Sending the output to a file (raw.txt) and attached that file as well.
>
> Pasted from Ubuntu CLI:
>
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$ sudo ethtool -m enp1s0 raw on
> \x11UU$��pA`?�@�G\x10#
> �\x12v\x01\x11��\x03�\x02@TRANSITION ��TNQSFP100GCWDM4 1AfX%\x1cF?\x06?�TN02000301 180919
> h�\x02I��_��'\x16��Ri=\x02`��Zntech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$ sudo ethtool -m enp1s0 hex on
> Offset Values
> ------ ------
> 0x0000: 11 00 00 0f 00 00 00 00 00 55 55 00 00 00 00 00
> 0x0010: 00 00 00 00 00 00 24 e2 00 00 81 68 00 00 00 00
> 0x0020: 00 00 00 00 00 00 00 00 00 00 41 60 3f e0 40 e0
> 0x0030: 47 00 1f 10 0e 1e 0b f7 12 76 00 00 00 00 00 00
> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> 0x0060: 00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00
> 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0080: 11 fc 07 80 00 00 00 00 00 00 00 03 ff 00 02 00
> 0x0090: 00 00 00 40 54 52 41 4e 53 49 54 49 4f 4e 20 20
> 0x00a0: 20 20 20 20 00 00 c0 f2 54 4e 51 53 46 50 31 30
> 0x00b0: 30 47 43 57 44 4d 34 20 31 41 66 58 25 1c 46 3f
> 0x00c0: 06 00 3f d6 54 4e 30 32 30 30 30 33 30 31 20 20
> 0x00d0: 20 20 20 20 31 38 30 39 31 39 20 20 0c 00 68 f3
> 0x00e0: 00 00 02 49 80 a0 5f 1f de c9 27 16 f8 ae 52 69
> 0x00f0: 3d 02 60 00 00 00 00 00 00 00 00 00 83 f4 5a 6e
Hi Chris
I've only recently got involved with SFP modules. ethtool says this is
a SFF-8636 SFP. So a QSFP. It has multiple pages, each 128 bytes in
length, which should be returned in a concatenated form. Here we see
256 bytes, meaning there are two pages. There can be up to 5 pages.
ethtool is looking for the temperature alarms at offset 0x200. So that
does not exist in this hex dump. But the raw dump you provided has
more bytes, 0x400 of them.
So i would say the first bug is that ethtool dumps different amounts
of data in hex than raw.
The fact you get different alarm thresholds on different runs suggests
to me we might only be getting two pages from the kernel?
Can you build ethtool from source and run it inside a debugger?
ethtool makes two IOCTL calls. The first is ETHTOOL_GMODULEINFO.
Could you print out the modinfo which is returned. It then does a
ETHTOOL_GMODULEEEPROM. Can you print out eeprom after the second
IOCTL.
Thanks
Andrew
^ 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