* Re: [PATCH 2/6 bpf-next] Clean up xsk reuseq API
From: Jonathan Lemon @ 2019-06-28 2:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, bjorn.topel, magnus.karlsson, saeedm, maximmi, brouer,
kernel-team
In-Reply-To: <20190627153856.1f4d4709@cakuba.netronome.com>
On 27 Jun 2019, at 15:38, Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 15:08:32 -0700, Jonathan Lemon wrote:
>> The reuseq is actually a recycle stack, only accessed from the kernel
>> side.
>> Also, the implementation details of the stack should belong to the
>> umem
>> object, and not exposed to the caller.
>>
>> Clean up and rename for consistency in preparation for the next
>> patch.
>>
>> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> Prepare/swap is to cater to how drivers should be written - being able
> to allocate resources independently of those currently used. Allowing
> for changing ring sizes and counts on the fly. This patch makes it
> harder to write drivers in the way we are encouraging people to.
>
> IOW no, please don't do this.
The main reason I rewrote this was to provide the same type
of functionality as realloc() - no need to allocate/initialize a new
array if the old one would still end up being used. This would seem
to be a win for the typical case of having the interface go up/down.
Perhaps I should have named the function differently?
--
Jonathan
^ permalink raw reply
* Re: [PATCH 4/6 bfp-next] Simplify AF_XDP umem allocation path for Intel drivers.
From: Jonathan Lemon @ 2019-06-28 2:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, bjorn.topel, magnus.karlsson, saeedm, maximmi, brouer,
kernel-team
In-Reply-To: <20190627154206.5d458e94@cakuba.netronome.com>
On 27 Jun 2019, at 15:42, Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 15:08:34 -0700, Jonathan Lemon wrote:
>> Now that the recycle stack is always used for the driver umem path, the
>> driver code path can be simplified.
>>
>> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> I guess it's a question to Bjorn and Magnus whether they want Intel
> drivers to always go through the reuse queue..
I did pass this by them earlier.
> Could you be more explicit on the motivation? I'd call this patch set
> "make all drivers use reuse queue" rather than "clean up".
The motivation is to have packets which were received on a zero-copy
AF_XDP socket, and which returned a TX verdict from the bpf program,
queued directly on the TX ring (if they're in the same napi context).
When these TX packets are completed, they are placed back onto the
reuse queue, as there isn't really any other place to handle them.
It also addresses Maxim's concern about having buffers end up sitting
on the rq after a ring resize.
I was going to send the TX change out as part of this patch, but
figured it would be better split unto its own series.
> Also when you're changing code please make sure you CC the author.
Who did I miss?
--
Jonathan
^ permalink raw reply
* [PATCH net-next] net/ipv6: Fix misuse of proc_dointvec "flowlabel_reflect"
From: Eiichi Tsukata @ 2019-06-28 2:37 UTC (permalink / raw)
To: davem, edumazet, kuznet, yoshfuji, netdev, linux-kernel; +Cc: Eiichi Tsukata
/proc/sys/net/ipv6/flowlabel_reflect assumes written value to be in the
range of 0 to 3. Use proc_dointvec_minmax instead of proc_dointvec.
Fixes: 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets")
Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
---
net/ipv6/sysctl_net_ipv6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 6d86fac472e7..831573461e19 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -114,7 +114,7 @@ static struct ctl_table ipv6_table_template[] = {
.data = &init_net.ipv6.sysctl.flowlabel_reflect,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
.extra1 = &zero,
.extra2 = &three,
},
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 1/5] net: dsa: microchip: Replace ad-hoc polling with regmap
From: Florian Fainelli @ 2019-06-28 2:43 UTC (permalink / raw)
To: Marek Vasut, netdev; +Cc: Andrew Lunn, Tristram Ha, Woojung Huh
In-Reply-To: <20190627215556.23768-2-marex@denx.de>
On 6/27/2019 2:55 PM, Marek Vasut wrote:
> Regmap provides polling function to poll for bits in a register,
> use in instead of reimplementing it.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 2/5] net: dsa: microchip: Replace ksz9477_wait_vlan_ctrl_ready polling with regmap
From: Florian Fainelli @ 2019-06-28 2:44 UTC (permalink / raw)
To: Marek Vasut, netdev; +Cc: Andrew Lunn, Tristram Ha, Woojung Huh
In-Reply-To: <20190627215556.23768-3-marex@denx.de>
On 6/27/2019 2:55 PM, Marek Vasut wrote:
> Regmap provides polling function to poll for bits in a register. This
> function is another reimplementation of polling for bit being clear in
> a register. Replace this with regmap polling function. Moreover, inline
> the function parameters, as the function is never called with any other
> parameter values than this one.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH v2 03/27] atm: idt77252: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-28 2:46 UTC (permalink / raw)
Cc: Fuqian Huang, Chas Williams, linux-atm-general, netdev,
linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/atm/idt77252.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 43a14579e80e..df51680e8931 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -1379,7 +1379,6 @@ init_tsq(struct idt77252_dev *card)
printk("%s: can't allocate TSQ.\n", card->name);
return -1;
}
- memset(card->tsq.base, 0, TSQSIZE);
card->tsq.last = card->tsq.base + TSQ_NUM_ENTRIES - 1;
card->tsq.next = card->tsq.last;
--
2.11.0
^ permalink raw reply related
* kernel BUG at net/rxrpc/local_object.c:LINE!
From: syzbot @ 2019-06-28 2:47 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14fabe45a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7c31a94f66cc0aa
dashboard link: https://syzkaller.appspot.com/bug?extid=1e0edc4b8b7494c28450
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13e2738da00000
The bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152fabe3a00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=172fabe3a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=132fabe3a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com
Fixes: 46894a13599a ("rxrpc: Use IPv4 addresses throught the IPv6")
rxrpc: Assertion failed
------------[ cut here ]------------
kernel BUG at net/rxrpc/local_object.c:468!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.2.0-rc6+ #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:ffff8880a9917c98 EFLAGS: 00010286
RAX: 0000000000000017 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815ad926 RDI: ffffed1015322f85
RBP: ffff8880a9917ca8 R08: 0000000000000017 R09: ffffed1015d260a1
R10: ffffed1015d260a0 R11: ffff8880ae930507 R12: ffff888099033b40
R13: ffff888099033b40 R14: ffffffff867b8f10 R15: ffff8880a9917d28
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f380ebda000 CR3: 000000007ad50000 CR4: 00000000001406e0
Call Trace:
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2092 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline]
rcu_core+0xba5/0x1500 kernel/rcu/tree.c:2291
__do_softirq+0x25c/0x94c kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:603 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595
smpboot_thread_fn+0x6a3/0xa30 kernel/smpboot.c:165
kthread+0x354/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 0e784d6285151217 ]---
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:ffff8880a9917c98 EFLAGS: 00010286
RAX: 0000000000000017 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815ad926 RDI: ffffed1015322f85
RBP: ffff8880a9917ca8 R08: 0000000000000017 R09: ffffed1015d260a1
R10: ffffed1015d260a0 R11: ffff8880ae930507 R12: ffff888099033b40
R13: ffff888099033b40 R14: ffffffff867b8f10 R15: ffff8880a9917d28
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f380ebda000 CR3: 000000007ad50000 CR4: 00000000001406e0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next 0/5] nfp: extend flower capabilities for GRE tunnel offload
From: David Miller @ 2019-06-28 2:47 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20190627231243.8323-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 27 Jun 2019 16:12:38 -0700
> Pieter says:
>
> This set extends the flower match and action components to offload
> GRE decapsulation with classification and encapsulation actions. The
> first 3 patches are refactor and cleanup patches for improving
> readability and reusability. Patch 4 and 5 implement GRE decap and
> encap functionality respectively.
Series applied.
^ permalink raw reply
* [PATCH v2 15/27] net: use zeroing allocator rather than allocator followed by memset zero
From: Fuqian Huang @ 2019-06-28 2:48 UTC (permalink / raw)
Cc: Fuqian Huang, David S. Miller, Derek Chickles, Satanand Burla,
Felix Manlunas, Tariq Toukan, netdev, linux-kernel, linux-rdma
Replace allocator followed by memset with 0 with zeroing allocator.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/eql.c | 3 +--
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 4 +---
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index 74263f8efe1a..2f101a6036e6 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -419,14 +419,13 @@ static int eql_enslave(struct net_device *master_dev, slaving_request_t __user *
if ((master_dev->flags & IFF_UP) == IFF_UP) {
/* slave is not a master & not already a slave: */
if (!eql_is_master(slave_dev) && !eql_is_slave(slave_dev)) {
- slave_t *s = kmalloc(sizeof(*s), GFP_KERNEL);
+ slave_t *s = kzalloc(sizeof(*s), GFP_KERNEL);
equalizer_t *eql = netdev_priv(master_dev);
int ret;
if (!s)
return -ENOMEM;
- memset(s, 0, sizeof(*s));
s->dev = slave_dev;
s->priority = srq.priority;
s->priority_bps = srq.priority;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 43d11c38b38a..cf3835da32c8 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -719,12 +719,10 @@ static int cn23xx_setup_pf_mbox(struct octeon_device *oct)
for (i = 0; i < oct->sriov_info.max_vfs; i++) {
q_no = i * oct->sriov_info.rings_per_vf;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
goto free_mbox;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(&mbox->lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index fda49404968c..b3bd2767d3dd 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -279,12 +279,10 @@ static int cn23xx_setup_vf_mbox(struct octeon_device *oct)
{
struct octeon_mbox *mbox = NULL;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
return 1;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(&mbox->lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314e87b0..f1dff5c47676 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1062,7 +1062,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
struct mlx4_qp_context *context;
int err = 0;
- context = kmalloc(sizeof(*context), GFP_KERNEL);
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
if (!context)
return -ENOMEM;
@@ -1073,7 +1073,6 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
}
qp->event = mlx4_en_sqp_event;
- memset(context, 0, sizeof(*context));
mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
qpn, ring->cqn, -1, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the txtime
From: Brown, Aaron F @ 2019-06-28 3:01 UTC (permalink / raw)
To: Patel, Vedang, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, davem@davemloft.net, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us,
intel-wired-lan@lists.osuosl.org, Gomes, Vinicius, l@dorileo.org,
jakub.kicinski@netronome.com, m-karicheri2@ti.com,
sergei.shtylyov@cogentembedded.com, eric.dumazet@gmail.com
In-Reply-To: <1561500439-30276-2-git-send-email-vedang.patel@intel.com>
> From: Patel, Vedang
> Sent: Tuesday, June 25, 2019 3:07 PM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> jhs@mojatatu.com; xiyou.wangcong@gmail.com; jiri@resnulli.us; intel-wired-
> lan@lists.osuosl.org; Gomes, Vinicius <vinicius.gomes@intel.com>;
> l@dorileo.org; jakub.kicinski@netronome.com; m-karicheri2@ti.com;
> sergei.shtylyov@cogentembedded.com; eric.dumazet@gmail.com; Brown,
> Aaron F <aaron.f.brown@intel.com>; Patel, Vedang <vedang.patel@intel.com>
> Subject: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the
> txtime
>
> If a packet which is utilizing the launchtime feature (via SO_TXTIME socket
> option) also requests the hardware transmit timestamp, the hardware
> timestamp is not delivered to the userspace. This is because the value in
> skb->tstamp is mistaken as the software timestamp.
>
> Applications, like ptp4l, request a hardware timestamp by setting the
> SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new
> timestamp is
> detected by the driver (this work is done in igb_ptp_tx_work() which calls
> igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp in the
> ERR_QUEUE for the userspace to read. When the userspace is ready, it will
> issue a recvmsg() call to collect this timestamp. The problem is in this
> recvmsg() call. If the skb->tstamp is not cleared out, it will be
> interpreted as a software timestamp and the hardware tx timestamp will not
> be successfully sent to the userspace. Look at skb_is_swtx_tstamp() and the
> callee function __sock_recv_timestamp() in net/socket.c for more details.
>
> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [PATCH v3] e1000e: Make watchdog use delayed work
From: Brown, Aaron F @ 2019-06-28 3:21 UTC (permalink / raw)
To: Detlev Casanova, Kirsher, Jeffrey T, David S. Miller,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190623031437.19716-1-detlev.casanova@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Detlev Casanova
> Sent: Saturday, June 22, 2019 8:15 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; David S. Miller
> <davem@davemloft.net>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Detlev Casanova <detlev.casanova@gmail.com>
> Subject: [PATCH v3] e1000e: Make watchdog use delayed work
>
> Use delayed work instead of timers to run the watchdog of the e1000e
> driver.
>
> Simplify the code with one less middle function.
>
> Signed-off-by: Detlev Casanova <detlev.casanova@gmail.com>
> ---
> drivers/net/ethernet/intel/e1000e/e1000.h | 5 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 54 ++++++++++++----------
> 2 files changed, 32 insertions(+), 27 deletions(-)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
From: wenxu @ 2019-06-28 3:37 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal; +Cc: netfilter-devel, netdev
In-Reply-To: <20190627125839.t56fnptdeqixt7wd@salvia>
On 6/27/2019 8:58 PM, Pablo Neira Ayuso wrote:
> On Thu, Jun 27, 2019 at 02:22:36PM +0800, wenxu wrote:
>> On 6/27/2019 3:19 AM, Florian Westphal wrote:
>>> Florian Westphal <fw@strlen.de> wrote:
> [...]
>>>> Whats the idea with this patch?
>>>>
>>>> Do you see a performance improvement when bypassing bridge layer? If so,
>>>> how much?
>>>>
>>>> I just wonder if its really cheaper than not using bridge conntrack in
>>>> the first place :-)
>> This patch is based on the conntrack function in bridge. It will
>> bypass the fdb lookup and conntrack lookup to get the performance
>> improvement. The more important things for hardware offload in the
>> future with nf_tables add hardware offload support
> Florian would like to see numbers / benchmark.
I just did a simple performace test with following test.
p netns add ns21
ip netns add ns22
ip l add dev veth21 type veth peer name eth0 netns ns21
ip l add dev veth22 type veth peer name eth0 netns ns22
ifconfig veth21 up
ifconfig veth22 up
ip netns exec ns21 ip a a dev eth0 10.0.0.7/24
ip netns exec ns22 ip a a dev eth0 10.0.0.8/24
ip netns exec ns21 ifconfig eth0 up
ip netns exec ns22 ifconfig eth0 up
ip l add dev br0 type bridge vlan_filtering 1
brctl addif br0 veth21
brctl addif br0 veth22
ifconfig br0 up
bridge vlan add dev veth21 vid 200 pvid untagged
bridge vlan add dev veth22 vid 200 pvid untagged
nft add table bridge firewall
nft add chain bridge firewall zones { type filter hook prerouting priority - 300 \; }
nft add rule bridge firewall zones counter ct zone set iif map { "veth21" : 2, "veth22" : 2 }
nft add chain bridge firewall rule-200-ingress
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-ingress ct zone 2 tcp dport 23 ct state new counter accept
nft add rule bridge firewall rule-200-ingress counter drop
nft add chain bridge firewall rule-200-egress
nft add rule bridge firewall rule-200-egress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-egress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-egress ct zone 2 tcp dport 23 ct state new counter drop
nft add rule bridge firewall rule-200-egress counter accept
nft add chain bridge firewall rules-all { type filter hook prerouting priority - 150 \; }
nft add rule bridge firewall rules-all counter meta protocol ip iif vmap { "veth22" : jump rule-200-ingress, "veth21" : jump rule-200-egress }
netns21 communication with ns22
ns21 iperf to 10.0.0.8 with dport 22 in ns22
first time with OFFLOAD enable
nft add flowtable bridge firewall fb2 { hook ingress priority 0 \; devices = { veth21, veth22 } \; }
nft add chain bridge firewall ftb-all {type filter hook forward priority 0 \; policy accept \; }
nft add rule bridge firewall ftb-all counter ct zone 2 ip protocol tcp flow offload @fb2
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60014 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 10.8 GBytes 46.5 Gbits/sec
[ 3] 2.0- 4.0 sec 10.9 GBytes 46.7 Gbits/sec
[ 3] 4.0- 6.0 sec 10.9 GBytes 46.8 Gbits/sec
[ 3] 6.0- 8.0 sec 11.0 GBytes 47.2 Gbits/sec
[ 3] 8.0-10.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 10.0-12.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 12.0-14.0 sec 11.7 GBytes 50.4 Gbits/sec
[ 3] 14.0-16.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 16.0-18.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 18.0-20.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 20.0-22.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 22.0-24.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 24.0-26.0 sec 12.0 GBytes 51.3 Gbits/sec
[ 3] 26.0-28.0 sec 12.0 GBytes 51.7 Gbits/sec
[ 3] 28.0-30.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 30.0-32.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 32.0-34.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 34.0-36.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 36.0-38.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 38.0-40.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 40.0-42.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 42.0-44.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 44.0-46.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 46.0-48.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 48.0-50.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 50.0-52.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 52.0-54.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 54.0-56.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 56.0-58.0 sec 11.9 GBytes 51.2 Gbits/sec
[ 3] 58.0-60.0 sec 11.8 GBytes 50.7 Gbits/sec
[ 3] 0.0-60.0 sec 353 GBytes 50.5 Gbits/sec
The second time on any offload:
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60536 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 8.88 GBytes 38.1 Gbits/sec
[ 3] 2.0- 4.0 sec 9.02 GBytes 38.7 Gbits/sec
[ 3] 4.0- 6.0 sec 9.02 GBytes 38.8 Gbits/sec
[ 3] 6.0- 8.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 8.0-10.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 10.0-12.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 12.0-14.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 14.0-16.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 16.0-18.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 18.0-20.0 sec 9.07 GBytes 39.0 Gbits/sec
[ 3] 20.0-22.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 22.0-24.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 24.0-26.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 26.0-28.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 28.0-30.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 30.0-32.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 32.0-34.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 34.0-36.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 36.0-38.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 38.0-40.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 40.0-42.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 42.0-44.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 44.0-46.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 46.0-48.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 48.0-50.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 50.0-52.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 52.0-54.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 54.0-56.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 56.0-58.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 58.0-60.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 0.0-60.0 sec 271 GBytes 38.8 Gbits/sec
>
^ permalink raw reply
* Re: [PATCH net v2] vxlan: do not destroy fdb if register_netdevice() is failed
From: Taehee Yoo @ 2019-06-28 3:51 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: David Miller, netdev, Petr Machata
In-Reply-To: <CAJieiUjuRFgxC+YCNUfQFQa-FXjAmfMnTwLw-SOithEQt5QQyw@mail.gmail.com>
On Fri, 28 Jun 2019 at 03:33, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
> On Thu, Jun 27, 2019 at 7:50 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > __vxlan_dev_create() destroys FDB using specific pointer which indicates
> > a fdb when error occurs.
> > But that pointer should not be used when register_netdevice() fails because
> > register_netdevice() internally destroys fdb when error occurs.
> >
> > This patch makes vxlan_fdb_create() to do not link fdb entry to vxlan dev
> > internally.
> > Instead, a new function vxlan_fdb_link() is added to link fdb to vxlan dev.
> >
> > vxlan_fdb_link() is called after calling register_netdevice().
> > This routine can avoid situation that ->ndo_uninit() destroys fdb entry
> > in error path of register_netdevice().
> > Hence, error path of __vxlan_dev_create() routine can have an opportunity
> > to destroy default fdb entry by hand.
> >
> > Test command
> > ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
> > dev enp0s9 dstport 4789
> >
> > Splat looks like:
> > [ 213.392816] kasan: GPF could be caused by NULL-ptr deref or user memory access
> > [ 213.401257] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
> > [ 213.402178] CPU: 0 PID: 1414 Comm: ip Not tainted 5.2.0-rc5+ #256
> > [ 213.402178] RIP: 0010:vxlan_fdb_destroy+0x120/0x220 [vxlan]
> > [ 213.402178] Code: df 48 8b 2b 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 06 01 00 00 4c 8b 63 08 48 b8 00 00 00 00 00 fc d
> > [ 213.402178] RSP: 0018:ffff88810cb9f0a0 EFLAGS: 00010202
> > [ 213.402178] RAX: dffffc0000000000 RBX: ffff888101d4a8c8 RCX: 0000000000000000
> > [ 213.402178] RDX: 1bd5a00000000040 RSI: ffff888101d4a8c8 RDI: ffff888101d4a8d0
> > [ 213.402178] RBP: 0000000000000000 R08: fffffbfff22b72d9 R09: 0000000000000000
> > [ 213.402178] R10: 00000000ffffffef R11: 0000000000000000 R12: dead000000000200
> > [ 213.402178] R13: ffff88810cb9f1f8 R14: ffff88810efccda0 R15: ffff88810efccda0
> > [ 213.402178] FS: 00007f7f6621a0c0(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
> > [ 213.402178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 213.402178] CR2: 000055746f0807d0 CR3: 00000001123e0000 CR4: 00000000001006f0
> > [ 213.402178] Call Trace:
> > [ 213.402178] __vxlan_dev_create+0x3a9/0x7d0 [vxlan]
> > [ 213.402178] ? vxlan_changelink+0x740/0x740 [vxlan]
> > [ 213.402178] ? rcu_read_unlock+0x60/0x60 [vxlan]
> > [ 213.402178] ? __kasan_kmalloc.constprop.3+0xa0/0xd0
> > [ 213.402178] vxlan_newlink+0x8d/0xc0 [vxlan]
> > [ 213.402178] ? __vxlan_dev_create+0x7d0/0x7d0 [vxlan]
> > [ 213.554119] ? __netlink_ns_capable+0xc3/0xf0
> > [ 213.554119] __rtnl_newlink+0xb75/0x1180
> > [ 213.554119] ? rtnl_link_unregister+0x230/0x230
> > [ ... ]
> >
> > Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
> > Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> > Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> > ---
> >
> > v1 -> v2 :
> > - Add a new function vxlan_fdb_link().
> > - Fix fdb entry leak.
> > - Update description.
> >
>
> thanks for v2!. a few comments inline below ...
>
Thank you for review!
> > drivers/net/vxlan.c | 27 +++++++++++++++++++--------
> > 1 file changed, 19 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> > index 083f3f0bf37f..4066346d6f41 100644
> > --- a/drivers/net/vxlan.c
> > +++ b/drivers/net/vxlan.c
> > @@ -804,6 +804,14 @@ static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan,
> > return f;
> > }
> >
> > +static void vxlan_fdb_link(struct vxlan_dev *vxlan, const u8 *mac,
> > + __be32 src_vni, struct vxlan_fdb *f)
>
> I would prefer vxlan_fdb_insert or something along those lines.
>
> > +{
> > + ++vxlan->addrcnt;
> > + hlist_add_head_rcu(&f->hlist,
> > + vxlan_fdb_head(vxlan, mac, src_vni));
> > +}
> > +
> > static int vxlan_fdb_create(struct vxlan_dev *vxlan,
> > const u8 *mac, union vxlan_addr *ip,
> > __u16 state, __be16 port, __be32 src_vni,
> > @@ -829,10 +837,6 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
> > return rc;
> > }
> >
> > - ++vxlan->addrcnt;
> > - hlist_add_head_rcu(&f->hlist,
> > - vxlan_fdb_head(vxlan, mac, src_vni));
> > -
> > *fdb = f;
> >
> > return 0;
> > @@ -977,6 +981,7 @@ static int vxlan_fdb_update_create(struct vxlan_dev *vxlan,
> > if (rc < 0)
> > return rc;
> >
> > + vxlan_fdb_link(vxlan, mac, src_vni, f);
> > rc = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH,
> > swdev_notify, extack);
> > if (rc)
> > @@ -3571,12 +3576,17 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
> > if (err)
> > goto errout;
> >
> > - /* notify default fdb entry */
> > if (f) {
> > + vxlan_fdb_link(vxlan, all_zeros_mac,
> > + vxlan->default_dst.remote_vni, f);
> > +
> > + /* notify default fdb entry */
> > err = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f),
> > RTM_NEWNEIGH, true, extack);
> > - if (err)
> > - goto errout;
> > + if (err) {
> > + vxlan_fdb_destroy(vxlan, f, false, false);
> > + goto unregister;
> > + }
> > }
> >
> > list_add(&vxlan->next, &vn->vxlan_list);
> > @@ -3588,7 +3598,8 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
> > * destroy the entry by hand here.
> > */
> > if (f)
> > - vxlan_fdb_destroy(vxlan, f, false, false);
> > + call_rcu(&f->rcu, vxlan_fdb_free);
>
> f is local to this function and not inserted at this point, so maybe
> we dont need to call_rcu here ?
>
I totally agree with your comments.
So, I will send a new patch.
Thank you!
> > +unregister:
> > if (unregister)
> > unregister_netdevice(dev);
> > return err;
> > --
> > 2.17.1
> >
^ permalink raw reply
* [PATCH v3] bpf: fix uapi bpf_prog_info fields alignment
From: Baruch Siach @ 2019-06-28 4:08 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, netdev, bpf,
Dmitry V . Levin, Arnd Bergmann, linux-arch, Baruch Siach,
Jiri Olsa, Geert Uytterhoeven, Linus Torvalds
Merge commit 1c8c5a9d38f60 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next") undid the
fix from commit 36f9814a494 ("bpf: fix uapi hole for 32 bit compat
applications") by taking the gpl_compatible 1-bit field definition from
commit b85fab0e67b162 ("bpf: Add gpl_compatible flag to struct
bpf_prog_info") as is. That breaks architectures with 16-bit alignment
like m68k. Add 31-bit pad after gpl_compatible to restore alignment of
following fields.
Thanks to Dmitry V. Levin his analysis of this bug history.
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3:
Use alignment pad as Alexei Starovoitov suggested
v2:
Use anonymous union with pad to make it less likely to break again in
the future.
---
include/uapi/linux/bpf.h | 1 +
tools/include/uapi/linux/bpf.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a8b823c30b43..29a5bc3d5c66 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3143,6 +3143,7 @@ struct bpf_prog_info {
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
__u32 gpl_compatible:1;
+ __u32 :31; /* alignment pad */
__u64 netns_dev;
__u64 netns_ino;
__u32 nr_jited_ksyms;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index a8b823c30b43..29a5bc3d5c66 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -3143,6 +3143,7 @@ struct bpf_prog_info {
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
__u32 gpl_compatible:1;
+ __u32 :31; /* alignment pad */
__u64 netns_dev;
__u64 netns_ino;
__u32 nr_jited_ksyms;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
From: Martin Blumenstingl @ 2019-06-28 4:15 UTC (permalink / raw)
To: Colin Ian King
Cc: alexandre.torgue, davem, joabreu, kernel-janitors,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, peppe.cavallaro
In-Reply-To: <c46d2d17-c35b-46f0-0674-0c55bea3a272@canonical.com>
On Tue, Jun 25, 2019 at 9:58 AM Colin Ian King <colin.king@canonical.com> wrote:
>
> On 25/06/2019 05:44, Martin Blumenstingl wrote:
> > Hi Colin,
> >
> > On Thu, Jun 20, 2019 at 3:34 AM Martin Blumenstingl
> > <martin.blumenstingl@googlemail.com> wrote:
> >>
> >> Hi Colin,
> >>
> >> On Wed, Jun 19, 2019 at 8:55 AM Colin Ian King <colin.king@canonical.com> wrote:
> >>>
> >>> On 19/06/2019 06:13, Martin Blumenstingl wrote:
> >>>> Hi Colin,
> >>>>
> >>>>> Currently the call to device_property_read_u32_array is not error checked
> >>>>> leading to potential garbage values in the delays array that are then used
> >>>>> in msleep delays. Add a sanity check to the property fetching.
> >>>>>
> >>>>> Addresses-Coverity: ("Uninitialized scalar variable")
> >>>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> >>>> I have also sent a patch [0] to fix initialize the array.
> >>>> can you please look at my patch so we can work out which one to use?
> >>>>
> >>>> my concern is that the "snps,reset-delays-us" property is optional,
> >>>> the current dt-bindings documentation states that it's a required
> >>>> property. in reality it isn't, there are boards (two examples are
> >>>> mentioned in my patch: [0]) without it.
> >>>>
> >>>> so I believe that the resulting behavior has to be:
> >>>> 1. don't delay if this property is missing (instead of delaying for
> >>>> <garbage value> ms)
> >>>> 2. don't error out if this property is missing
> >>>>
> >>>> your patch covers #1, can you please check whether #2 is also covered?
> >>>> I tested case #2 when submitting my patch and it worked fine (even
> >>>> though I could not reproduce the garbage values which are being read
> >>>> on some boards)
> > in the meantime I have tested your patch.
> > when I don't set the "snps,reset-delays-us" property then I get the
> > following error:
> > invalid property snps,reset-delays-us
> >
> > my patch has landed in the meantime: [0]
> > how should we proceed with your patch?
>
> I'm out of the office today. I'll get back to you on this tomorrow.
gentle ping
(I will be away for the weekend but I can reply on Monday)
^ permalink raw reply
* linux-next: manual merge of the devicetree tree with the net-next tree
From: Stephen Rothwell @ 2019-06-28 4:56 UTC (permalink / raw)
To: Rob Herring, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Heiner Kallweit, Maxime Ripard
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/net/ethernet.txt
between commit:
79b647a0c0d5 ("dt-bindings: net: document new usxgmii phy mode")
from the net-next tree and commit:
4e7a33bff7d7 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options")
from the devicetree tree.
I fixed it up (the latter seems to include the change made by the former,
so I just used the latter) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] Compile-test UAPI and kernel headers
From: Masahiro Yamada @ 2019-06-28 4:57 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Song Liu, Jakub Kicinski, open list:DOCUMENTATION, Palmer Dabbelt,
Alexei Starovoitov, linux-riscv, Sam Ravnborg, Kees Cook,
xdp-newbies, Daniel Borkmann, Jonathan Corbet, Anton Vorontsov,
John Fastabend, Yonghong Song, Albert Ou, Jesper Dangaard Brouer,
Jani Nikula, Michal Marek,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
linux-arm-kernel, Tony Luck, Networking,
Linux Kernel Mailing List, David S. Miller, Colin Cross, bpf,
Martin KaFai Lau
In-Reply-To: <20190627163903.28398-1-yamada.masahiro@socionext.com>
On Fri, Jun 28, 2019 at 1:41 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> 1/4: Compile-test exported headers (reworked in v2)
>
> 2/4: fix a flaw I noticed when I was working on this series.
> Avoid generating intermediate wrappers.
>
> 3/4: maybe useful for 4/4 and in some other places.
> Add header-test-pattern-y syntax.
>
> 4/4: Compile-test kernel-space headers in include/.
> v2: compile as many headers as possible.
> v3: exclude more headers causing build errors
I push this series to
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
header-test-v3
for somebody who wants to test it.
>
> Masahiro Yamada (4):
> kbuild: compile-test UAPI headers to ensure they are self-contained
> kbuild: do not create wrappers for header-test-y
> kbuild: support header-test-pattern-y
> kbuild: compile-test kernel headers to ensure they are self-contained
>
> .gitignore | 1 -
> Documentation/dontdiff | 1 -
> Documentation/kbuild/makefiles.txt | 13 +-
> Makefile | 4 +-
> include/Kbuild | 1250 ++++++++++++++++++++++++++++
> init/Kconfig | 22 +
> scripts/Makefile.build | 10 +-
> scripts/Makefile.lib | 13 +-
> scripts/cc-system-headers.sh | 8 +
> usr/.gitignore | 1 -
> usr/Makefile | 2 +
> usr/include/.gitignore | 3 +
> usr/include/Makefile | 134 +++
> 13 files changed, 1449 insertions(+), 13 deletions(-)
> create mode 100644 include/Kbuild
> create mode 100755 scripts/cc-system-headers.sh
> create mode 100644 usr/include/.gitignore
> create mode 100644 usr/include/Makefile
>
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH net v3] vxlan: do not destroy fdb if register_netdevice() is failed
From: Taehee Yoo @ 2019-06-28 5:07 UTC (permalink / raw)
To: davem, roopa, petrm, netdev; +Cc: ap420073
__vxlan_dev_create() destroys FDB using specific pointer which indicates
a fdb when error occurs.
But that pointer should not be used when register_netdevice() fails because
register_netdevice() internally destroys fdb when error occurs.
This patch makes vxlan_fdb_create() to do not link fdb entry to vxlan dev
internally.
Instead, a new function vxlan_fdb_insert() is added to link fdb to vxlan
dev.
vxlan_fdb_insert() is called after calling register_netdevice().
This routine can avoid situation that ->ndo_uninit() destroys fdb entry
in error path of register_netdevice().
Hence, error path of __vxlan_dev_create() routine can have an opportunity
to destroy default fdb entry by hand.
Test command
ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
dev enp0s9 dstport 4789
Splat looks like:
[ 213.392816] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 213.401257] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 213.402178] CPU: 0 PID: 1414 Comm: ip Not tainted 5.2.0-rc5+ #256
[ 213.402178] RIP: 0010:vxlan_fdb_destroy+0x120/0x220 [vxlan]
[ 213.402178] Code: df 48 8b 2b 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 06 01 00 00 4c 8b 63 08 48 b8 00 00 00 00 00 fc d
[ 213.402178] RSP: 0018:ffff88810cb9f0a0 EFLAGS: 00010202
[ 213.402178] RAX: dffffc0000000000 RBX: ffff888101d4a8c8 RCX: 0000000000000000
[ 213.402178] RDX: 1bd5a00000000040 RSI: ffff888101d4a8c8 RDI: ffff888101d4a8d0
[ 213.402178] RBP: 0000000000000000 R08: fffffbfff22b72d9 R09: 0000000000000000
[ 213.402178] R10: 00000000ffffffef R11: 0000000000000000 R12: dead000000000200
[ 213.402178] R13: ffff88810cb9f1f8 R14: ffff88810efccda0 R15: ffff88810efccda0
[ 213.402178] FS: 00007f7f6621a0c0(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
[ 213.402178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 213.402178] CR2: 000055746f0807d0 CR3: 00000001123e0000 CR4: 00000000001006f0
[ 213.402178] Call Trace:
[ 213.402178] __vxlan_dev_create+0x3a9/0x7d0 [vxlan]
[ 213.402178] ? vxlan_changelink+0x740/0x740 [vxlan]
[ 213.402178] ? rcu_read_unlock+0x60/0x60 [vxlan]
[ 213.402178] ? __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 213.402178] vxlan_newlink+0x8d/0xc0 [vxlan]
[ 213.402178] ? __vxlan_dev_create+0x7d0/0x7d0 [vxlan]
[ 213.554119] ? __netlink_ns_capable+0xc3/0xf0
[ 213.554119] __rtnl_newlink+0xb75/0x1180
[ 213.554119] ? rtnl_link_unregister+0x230/0x230
[ ... ]
Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
v2 -> v3 :
- Use function name vxlan_fdb_insert() instead of vxlan_fdb_link()
- Add and use __vxlan_fdb_free() instead of call_rcu()
v1 -> v2 :
- Add a new function vxlan_fdb_link().
- Fix fdb entry leak.
- Update description.
drivers/net/vxlan.c | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 083f3f0bf37f..b4283f52a09d 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -804,6 +804,14 @@ static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan,
return f;
}
+static void vxlan_fdb_insert(struct vxlan_dev *vxlan, const u8 *mac,
+ __be32 src_vni, struct vxlan_fdb *f)
+{
+ ++vxlan->addrcnt;
+ hlist_add_head_rcu(&f->hlist,
+ vxlan_fdb_head(vxlan, mac, src_vni));
+}
+
static int vxlan_fdb_create(struct vxlan_dev *vxlan,
const u8 *mac, union vxlan_addr *ip,
__u16 state, __be16 port, __be32 src_vni,
@@ -829,18 +837,13 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
return rc;
}
- ++vxlan->addrcnt;
- hlist_add_head_rcu(&f->hlist,
- vxlan_fdb_head(vxlan, mac, src_vni));
-
*fdb = f;
return 0;
}
-static void vxlan_fdb_free(struct rcu_head *head)
+static void __vxlan_fdb_free(struct vxlan_fdb *f)
{
- struct vxlan_fdb *f = container_of(head, struct vxlan_fdb, rcu);
struct vxlan_rdst *rd, *nd;
list_for_each_entry_safe(rd, nd, &f->remotes, list) {
@@ -850,6 +853,13 @@ static void vxlan_fdb_free(struct rcu_head *head)
kfree(f);
}
+static void vxlan_fdb_free(struct rcu_head *head)
+{
+ struct vxlan_fdb *f = container_of(head, struct vxlan_fdb, rcu);
+
+ __vxlan_fdb_free(f);
+}
+
static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
bool do_notify, bool swdev_notify)
{
@@ -977,6 +987,7 @@ static int vxlan_fdb_update_create(struct vxlan_dev *vxlan,
if (rc < 0)
return rc;
+ vxlan_fdb_insert(vxlan, mac, src_vni, f);
rc = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH,
swdev_notify, extack);
if (rc)
@@ -3571,12 +3582,17 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
if (err)
goto errout;
- /* notify default fdb entry */
if (f) {
+ vxlan_fdb_insert(vxlan, all_zeros_mac,
+ vxlan->default_dst.remote_vni, f);
+
+ /* notify default fdb entry */
err = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f),
RTM_NEWNEIGH, true, extack);
- if (err)
- goto errout;
+ if (err) {
+ vxlan_fdb_destroy(vxlan, f, false, false);
+ goto unregister;
+ }
}
list_add(&vxlan->next, &vn->vxlan_list);
@@ -3588,7 +3604,8 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
* destroy the entry by hand here.
*/
if (f)
- vxlan_fdb_destroy(vxlan, f, false, false);
+ __vxlan_fdb_free(f);
+unregister:
if (unregister)
unregister_netdevice(dev);
return err;
--
2.17.1
^ permalink raw reply related
* RE: [EXT] [PATCH V4] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Sudarsana Reddy Kalluru @ 2019-06-28 5:22 UTC (permalink / raw)
To: Guilherme G. Piccoli, GR-everest-linux-l2, netdev@vger.kernel.org
Cc: Ariel Elior, jay.vosburgh@canonical.com
In-Reply-To: <20190627163133.5990-1-gpiccoli@canonical.com>
> -----Original Message-----
> From: Guilherme G. Piccoli <gpiccoli@canonical.com>
> Sent: Thursday, June 27, 2019 10:02 PM
> To: GR-everest-linux-l2 <GR-everest-linux-l2@marvell.com>;
> netdev@vger.kernel.org; Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: Ariel Elior <aelior@marvell.com>; gpiccoli@canonical.com;
> jay.vosburgh@canonical.com
> Subject: [EXT] [PATCH V4] bnx2x: Prevent ptp_task to be rescheduled
> indefinitely
>
> External Email
>
> ----------------------------------------------------------------------
> Currently bnx2x ptp worker tries to read a register with timestamp
> information in case of TX packet timestamping and in case it fails, the routine
> reschedules itself indefinitely. This was reported as a kworker always at 100%
> of CPU usage, which was narrowed down to be bnx2x ptp_task.
>
> By following the ioctl handler, we could narrow down the problem to an NTP
> tool (chrony) requesting HW timestamping from bnx2x NIC with RX filter
> zeroed; this isn't reproducible for example with ptp4l (from linuxptp) since
> this tool requests a supported RX filter.
> It seems NIC FW timestamp mechanism cannot work well with
> RX_FILTER_NONE - driver's PTP filter init routine skips a register write to the
> adapter if there's not a supported filter request.
>
> This patch addresses the problem of bnx2x ptp thread's everlasting
> reschedule by retrying the register read 10 times; between the read
> attempts the thread sleeps for an increasing amount of time starting in 1ms
> to give FW some time to perform the timestamping. If it still fails after all
> retries, we bail out in order to prevent an unbound resource consumption
> from bnx2x.
>
> The patch also adds an ethtool statistic for accounting the skipped TX
> timestamp packets and it reduces the priority of timestamping error
> messages to prevent log flooding. The code was tested using both linuxptp
> and chrony.
>
> Reported-and-tested-by: Przemyslaw Hausman
> <przemyslaw.hausman@canonical.com>
> Suggested-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
> ---
>
> Thanks again for your review Sudarsana. I've addressed in this V4 your
> suggestions about removing some debug messages[0].
>
> [0] https://marc.info/?l=linux-netdev&m=156165243804760
>
> .../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 ++-
> .../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 4 ++-
> .../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 33 ++++++++++++++----
> - .../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++
> 4 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> index 008ad0ca89ba..c12c1bab0fe4 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -3857,9 +3857,12 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff
> *skb, struct net_device *dev)
>
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
> if (!(bp->flags & TX_TIMESTAMPING_EN)) {
> + bp->eth_stats.ptp_skip_tx_ts++;
> BNX2X_ERR("Tx timestamping was not enabled, this
> packet will not be timestamped\n");
> } else if (bp->ptp_tx_skb) {
> - BNX2X_ERR("The device supports only a single
> outstanding packet to timestamp, this packet will not be timestamped\n");
> + bp->eth_stats.ptp_skip_tx_ts++;
> + netdev_err_once(bp->dev,
> + "Device supports only a single
> outstanding packet to timestamp,
> +this packet won't be timestamped\n");
> } else {
> skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> /* schedule check for Tx timestamp */ diff --git
> a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> index 51fc845de31a..4a0ba6801c9e 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> @@ -182,7 +182,9 @@ static const struct {
> { STATS_OFFSET32(driver_filtered_tx_pkt),
> 4, false, "driver_filtered_tx_pkt" },
> { STATS_OFFSET32(eee_tx_lpi),
> - 4, true, "Tx LPI entry count"}
> + 4, true, "Tx LPI entry count"},
> + { STATS_OFFSET32(ptp_skip_tx_ts),
> + 4, false, "ptp_skipped_tx_tstamp" },
> };
>
> #define BNX2X_NUM_STATS ARRAY_SIZE(bnx2x_stats_arr)
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> index 03ac10b1cd1e..2cc14db8f0ec 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -15214,11 +15214,24 @@ static void bnx2x_ptp_task(struct work_struct
> *work)
> u32 val_seq;
> u64 timestamp, ns;
> struct skb_shared_hwtstamps shhwtstamps;
> + bool bail = true;
> + int i;
>
> - /* Read Tx timestamp registers */
> - val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
> - NIG_REG_P0_TLLH_PTP_BUF_SEQID);
> - if (val_seq & 0x10000) {
> + /* FW may take a while to complete timestamping; try a bit and if it's
> + * still not complete, may indicate an error state - bail out then.
> + */
> + for (i = 0; i < 10; i++) {
> + /* Read Tx timestamp registers */
> + val_seq = REG_RD(bp, port ?
> NIG_REG_P1_TLLH_PTP_BUF_SEQID :
> + NIG_REG_P0_TLLH_PTP_BUF_SEQID);
> + if (val_seq & 0x10000) {
> + bail = false;
> + break;
> + }
> + msleep(1 << i);
> + }
> +
> + if (!bail) {
> /* There is a valid timestamp value */
> timestamp = REG_RD(bp, port ?
> NIG_REG_P1_TLLH_PTP_BUF_TS_MSB :
> NIG_REG_P0_TLLH_PTP_BUF_TS_MSB);
> @@ -15233,16 +15246,18 @@ static void bnx2x_ptp_task(struct work_struct
> *work)
> memset(&shhwtstamps, 0, sizeof(shhwtstamps));
> shhwtstamps.hwtstamp = ns_to_ktime(ns);
> skb_tstamp_tx(bp->ptp_tx_skb, &shhwtstamps);
> - dev_kfree_skb_any(bp->ptp_tx_skb);
> - bp->ptp_tx_skb = NULL;
>
> DP(BNX2X_MSG_PTP, "Tx timestamp, timestamp cycles =
> %llu, ns = %llu\n",
> timestamp, ns);
> } else {
> - DP(BNX2X_MSG_PTP, "There is no valid Tx timestamp
> yet\n");
> - /* Reschedule to keep checking for a valid timestamp value
> */
> - schedule_work(&bp->ptp_task);
> + DP(BNX2X_MSG_PTP,
> + "Tx timestamp is not recorded (register read=%u)\n",
> + val_seq);
> + bp->eth_stats.ptp_skip_tx_ts++;
> }
> +
> + dev_kfree_skb_any(bp->ptp_tx_skb);
> + bp->ptp_tx_skb = NULL;
> }
>
> void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb) diff --git
> a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
> index b2644ed13d06..d55e63692cf3 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
> @@ -207,6 +207,9 @@ struct bnx2x_eth_stats {
> u32 driver_filtered_tx_pkt;
> /* src: Clear-on-Read register; Will not survive PMF Migration */
> u32 eee_tx_lpi;
> +
> + /* PTP */
> + u32 ptp_skip_tx_ts;
> };
>
> struct bnx2x_eth_q_stats {
> --
> 2.22.0
Thanks for the changes.
Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
^ permalink raw reply
* Re: [PATCH net] tipc: add dst_cache support for udp media
From: David Miller @ 2019-06-28 5:37 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jon.maloy, ying.xue, tipc-discussion, pabeni
In-Reply-To: <0ea2e8519f14d5c9e7bb7ba82a5be371bd4cb9ab.1561028621.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Thu, 20 Jun 2019 19:03:41 +0800
> As other udp/ip tunnels do, tipc udp media should also have a
> lockless dst_cache supported on its tx path.
>
> Here we add dst_cache into udp_replicast to support dst cache
> for both rmcast and rcast, and rmcast uses ub->rcast and each
> rcast uses its own node in ub->rcast.list.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] sis900: remove TxIDLE
From: David Miller @ 2019-06-28 5:38 UTC (permalink / raw)
To: sergej.benilov; +Cc: venza, netdev
In-Reply-To: <20190624212102.15844-1-sergej.benilov@googlemail.com>
From: Sergej Benilov <sergej.benilov@googlemail.com>
Date: Mon, 24 Jun 2019 23:21:02 +0200
> Before "sis900: fix TX completion" patch, TX completion was done on TxIDLE interrupt.
> TX completion also was the only thing done on TxIDLE interrupt.
> Since "sis900: fix TX completion", TX completion is done on TxDESC interrupt.
> So it is not necessary any more to set and to check for TxIDLE.
>
> Eliminate TxIDLE from sis900.
> Correct some typos, too.
>
> Signed-off-by: Sergej Benilov <sergej.benilov@googlemail.com>
Applied to net-next.
^ permalink raw reply
* [PATCH v3 bpf-next 0/9] libbpf: add bpf_link and tracing attach APIs
From: Andrii Nakryiko @ 2019-06-28 5:52 UTC (permalink / raw)
To: andrii.nakryiko, ast, daniel, netdev, bpf, sdf, kernel-team
Cc: Andrii Nakryiko
This patchset adds the following APIs to allow attaching BPF programs to
tracing entities:
- bpf_program__attach_perf_event for attaching to any opened perf event FD,
allowing users full control;
- bpf_program__attach_kprobe for attaching to kernel probes (both entry and
return probes);
- bpf_program__attach_uprobe for attaching to user probes (both entry/return);
- bpf_program__attach_tracepoint for attaching to kernel tracepoints;
- bpf_program__attach_raw_tracepoint for attaching to raw kernel tracepoint
(wrapper around bpf_raw_tracepoint_open);
This set of APIs makes libbpf more useful for tracing applications.
All attach APIs return abstract struct bpf_link that encapsulates logic of
detaching BPF program. See patch #2 for details. bpf_assoc was considered as
an alternative name for this opaque "handle", but bpf_link seems to be
appropriate semantically and is nice and short.
Pre-patch #1 makes internal libbpf_strerror_r helper function work w/ negative
error codes, lifting the burder off callers to keep track of error sign.
Patch #2 adds bpf_link abstraction.
Patch #3 adds attach_perf_event, which is the base for all other APIs.
Patch #4 adds kprobe/uprobe APIs.
Patch #5 adds tracepoint API.
Patch #6 adds raw_tracepoint API.
Patch #7 converts one existing test to use attach_perf_event.
Patch #8 adds new kprobe/uprobe tests.
Patch #9 converts some selftests currently using tracepoint to new APIs.
v2->v3:
- added bpf_link concept (Daniel);
- didn't add generic bpf_link__attach_program for reasons described in [0];
- dropped Stanislav's Reviewed-by from patches #2-#6, in case he doesn't like
the change;
v1->v2:
- preserve errno before close() call (Stanislav);
- use libbpf_perf_event_disable_and_close in selftest (Stanislav);
- remove unnecessary memset (Stanislav);
[0] https://lore.kernel.org/bpf/CAEf4BzZ7EM5eP2eaZn7T2Yb5QgVRiwAs+epeLR1g01TTx-6m6Q@mail.gmail.com/
Andrii Nakryiko (9):
libbpf: make libbpf_strerror_r agnostic to sign of error
libbpf: introduce concept of bpf_link
libbpf: add ability to attach/detach BPF program to perf event
libbpf: add kprobe/uprobe attach API
libbpf: add tracepoint attach API
libbpf: add raw tracepoint attach API
selftests/bpf: switch test to new attach_perf_event API
selftests/bpf: add kprobe/uprobe selftests
selftests/bpf: convert existing tracepoint tests to new APIs
tools/lib/bpf/libbpf.c | 402 ++++++++++++++++++
tools/lib/bpf/libbpf.h | 21 +
tools/lib/bpf/libbpf.map | 8 +-
tools/lib/bpf/str_error.c | 2 +-
.../selftests/bpf/prog_tests/attach_probe.c | 155 +++++++
.../bpf/prog_tests/stacktrace_build_id.c | 50 +--
.../bpf/prog_tests/stacktrace_build_id_nmi.c | 31 +-
.../selftests/bpf/prog_tests/stacktrace_map.c | 43 +-
.../bpf/prog_tests/stacktrace_map_raw_tp.c | 15 +-
.../selftests/bpf/progs/test_attach_probe.c | 55 +++
10 files changed, 687 insertions(+), 95 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/attach_probe.c
create mode 100644 tools/testing/selftests/bpf/progs/test_attach_probe.c
--
2.17.1
^ permalink raw reply
* [PATCH v3 bpf-next 1/9] libbpf: make libbpf_strerror_r agnostic to sign of error
From: Andrii Nakryiko @ 2019-06-28 5:52 UTC (permalink / raw)
To: andrii.nakryiko, ast, daniel, netdev, bpf, sdf, kernel-team
Cc: Andrii Nakryiko
In-Reply-To: <20190628055303.1249758-1-andriin@fb.com>
It's often inconvenient to switch sign of error when passing it into
libbpf_strerror_r. It's better for it to handle that automatically.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
---
tools/lib/bpf/str_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/str_error.c b/tools/lib/bpf/str_error.c
index 00e48ac5b806..b8064eedc177 100644
--- a/tools/lib/bpf/str_error.c
+++ b/tools/lib/bpf/str_error.c
@@ -11,7 +11,7 @@
*/
char *libbpf_strerror_r(int err, char *dst, int len)
{
- int ret = strerror_r(err, dst, len);
+ int ret = strerror_r(err < 0 ? -err : err, dst, len);
if (ret)
snprintf(dst, len, "ERROR: strerror_r(%d)=%d", err, ret);
return dst;
--
2.17.1
^ permalink raw reply related
* [PATCH v3 bpf-next 2/9] libbpf: introduce concept of bpf_link
From: Andrii Nakryiko @ 2019-06-28 5:52 UTC (permalink / raw)
To: andrii.nakryiko, ast, daniel, netdev, bpf, sdf, kernel-team
Cc: Andrii Nakryiko
In-Reply-To: <20190628055303.1249758-1-andriin@fb.com>
bpf_link is and abstraction of an association of a BPF program and one
of many possible BPF attachment points (hooks). This allows to have
uniform interface for detaching BPF programs regardless of the nature of
link and how it was created. Details of creation and setting up of
a specific bpf_link is handled by corresponding attachment methods
(bpf_program__attach_xxx) added in subsequent commits. Once successfully
created, bpf_link has to be eventually destroyed with
bpf_link__destroy(), at which point BPF program is disassociated from
a hook and all the relevant resources are freed.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/libbpf.c | 17 +++++++++++++++++
tools/lib/bpf/libbpf.h | 4 ++++
tools/lib/bpf/libbpf.map | 3 ++-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 6e6ebef11ba3..455795e6f8af 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -3941,6 +3941,23 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
return 0;
}
+struct bpf_link {
+ int (*destroy)(struct bpf_link *link);
+};
+
+int bpf_link__destroy(struct bpf_link *link)
+{
+ int err;
+
+ if (!link)
+ return 0;
+
+ err = link->destroy(link);
+ free(link);
+
+ return err;
+}
+
enum bpf_perf_event_ret
bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
void **copy_mem, size_t *copy_size,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index d639f47e3110..5082a5ebb0c2 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -165,6 +165,10 @@ LIBBPF_API int bpf_program__pin(struct bpf_program *prog, const char *path);
LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
+struct bpf_link;
+
+LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
+
struct bpf_insn;
/*
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index 2c6d835620d2..3cde850fc8da 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -167,10 +167,11 @@ LIBBPF_0.0.3 {
LIBBPF_0.0.4 {
global:
+ bpf_link__destroy;
+ bpf_object__load_xattr;
btf_dump__dump_type;
btf_dump__free;
btf_dump__new;
btf__parse_elf;
- bpf_object__load_xattr;
libbpf_num_possible_cpus;
} LIBBPF_0.0.3;
--
2.17.1
^ permalink raw reply related
* [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Andrii Nakryiko @ 2019-06-28 5:52 UTC (permalink / raw)
To: andrii.nakryiko, ast, daniel, netdev, bpf, sdf, kernel-team
Cc: Andrii Nakryiko
In-Reply-To: <20190628055303.1249758-1-andriin@fb.com>
bpf_program__attach_perf_event allows to attach BPF program to existing
perf event hook, providing most generic and most low-level way to attach BPF
programs. It returns struct bpf_link, which should be passed to
bpf_link__destroy to detach and free resources, associated with a link.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
tools/lib/bpf/libbpf.h | 3 +++
tools/lib/bpf/libbpf.map | 1 +
3 files changed, 62 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 455795e6f8af..606705f878ba 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -32,6 +32,7 @@
#include <linux/limits.h>
#include <linux/perf_event.h>
#include <linux/ring_buffer.h>
+#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/vfs.h>
@@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
return err;
}
+struct bpf_link_fd {
+ struct bpf_link link; /* has to be at the top of struct */
+ int fd; /* hook FD */
+};
+
+static int bpf_link__destroy_perf_event(struct bpf_link *link)
+{
+ struct bpf_link_fd *l = (void *)link;
+ int err;
+
+ if (l->fd < 0)
+ return 0;
+
+ err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
+ close(l->fd);
+ return err;
+}
+
+struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
+ int pfd)
+{
+ char errmsg[STRERR_BUFSIZE];
+ struct bpf_link_fd *link;
+ int bpf_fd, err;
+
+ bpf_fd = bpf_program__fd(prog);
+ if (bpf_fd < 0) {
+ pr_warning("program '%s': can't attach before loaded\n",
+ bpf_program__title(prog, false));
+ return ERR_PTR(-EINVAL);
+ }
+
+ link = malloc(sizeof(*link));
+ if (!link)
+ return ERR_PTR(-ENOMEM);
+ link->link.destroy = &bpf_link__destroy_perf_event;
+ link->fd = pfd;
+
+ if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
+ err = -errno;
+ free(link);
+ pr_warning("program '%s': failed to attach to pfd %d: %s\n",
+ bpf_program__title(prog, false), pfd,
+ libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
+ return ERR_PTR(err);
+ }
+ if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
+ err = -errno;
+ free(link);
+ pr_warning("program '%s': failed to enable pfd %d: %s\n",
+ bpf_program__title(prog, false), pfd,
+ libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
+ return ERR_PTR(err);
+ }
+ return (struct bpf_link *)link;
+}
+
enum bpf_perf_event_ret
bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
void **copy_mem, size_t *copy_size,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 5082a5ebb0c2..1bf66c4a9330 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -169,6 +169,9 @@ struct bpf_link;
LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
+LIBBPF_API struct bpf_link *
+bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
+
struct bpf_insn;
/*
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index 3cde850fc8da..756f5aa802e9 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
global:
bpf_link__destroy;
bpf_object__load_xattr;
+ bpf_program__attach_perf_event;
btf_dump__dump_type;
btf_dump__free;
btf_dump__new;
--
2.17.1
^ permalink raw reply related
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