* [PATCH net 0/9] rxrpc: Fix use of skb_cow_data()
From: David Howells @ 2019-08-22 12:22 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Here's a series of patches that fixes the use of skb_cow_data() in rxrpc.
The problem is that skb_cow_data() indirectly requires that the maximum
usage count on an sk_buff be 1, and it may generate an assertion failure in
pskb_expand_head() if not.
This can occur because rxrpc_input_data() may be still holding a ref when
it has just attached the sk_buff to the rx ring and given that attachment
its own ref. If recvmsg happens fast enough, skb_cow_data() can see the
ref still held by the softirq handler.
Further, a packet may contain multiple subpackets, each of which gets its
own attachment to the ring and its own ref - also making skb_cow_data() go
bang.
Fix this by:
(1) The DATA packet is currently parsed for subpackets twice by the input
routines. Parse it just once instead and make notes in the sk_buff
private data.
(2) Use the notes from (1) when attaching the packet to the ring multiple
times. Once the packet is attached to the ring, recvmsg can see it
and cow it and start modifying it, so the softirq handler is not
permitted to look inside it from that point.
(3) Stick a second reference count in the skb private data, in struct
rxrpc_skb_priv, to count the refs held by the ring on the packet. All
these refs together hold one single ref on the sk_buff main ref
counter.
(4) Pass the ref from the input code to the ring rather than getting an
extra ref. rxrpc_input_data() uses a ref on the second refcount to
prevent the packet from evaporating under it.
(5) rxkad currently calls skb_cow_data() once for each subpacket it needs
to decrypt. It should only be calling this once, however, so move
that into recvmsg and only do it when we first see a new packet.
There's also a patch to improve the rxrpc_skb tracepoint to make sure that
Tx-derived buffers are identified separately from Rx-derived buffers in the
trace.
The patches are tagged here:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20190820
and can also be found on the following branch:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
David
---
David Howells (9):
rxrpc: Pass the input handler's data skb reference to the Rx ring
rxrpc: Improve jumbo packet counting
rxrpc: Use info in skbuff instead of reparsing a jumbo packet
rxrpc: Add a private skb flag to indicate transmission-phase skbs
rxrpc: Abstract out rxtx ring cleanup
rxrpc: Use the tx-phase skb flag to simplify tracing
rxrpc: Add a shadow refcount in the skb private data
rxrpc: Use shadow refcount for packets in the RxTx ring
rxrpc: Only call skb_cow_data() once per packet
include/trace/events/rxrpc.h | 62 +++++----
net/rxrpc/ar-internal.h | 18 ++-
net/rxrpc/call_event.c | 8 +
net/rxrpc/call_object.c | 33 ++---
net/rxrpc/conn_event.c | 6 -
net/rxrpc/input.c | 285 ++++++++++++++++++++++--------------------
net/rxrpc/local_event.c | 4 -
net/rxrpc/output.c | 6 -
net/rxrpc/peer_event.c | 10 +
net/rxrpc/protocol.h | 9 +
net/rxrpc/recvmsg.c | 58 +++++----
net/rxrpc/rxkad.c | 32 +----
net/rxrpc/sendmsg.c | 14 +-
net/rxrpc/skbuff.c | 72 +++++++++--
14 files changed, 348 insertions(+), 269 deletions(-)
^ permalink raw reply
* [PATCH][next] mac80211: minstrel_ht: fix infinite loop because supported is not being shifted
From: Colin King @ 2019-08-22 12:20 UTC (permalink / raw)
To: Felix Fietkau, Johannes Berg, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently the for-loop will spin forever if variable supported is
non-zero because supported is never changed. Fix this by adding in
the missing right shift of supported.
Addresses-Coverity: ("Infinite loop")
Fixes: 48cb39522a9d ("mac80211: minstrel_ht: improve rate probing for devices with static fallback")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index a01168514840..0ef2633349b5 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -634,7 +634,7 @@ minstrel_ht_rate_sample_switch(struct minstrel_priv *mp,
u16 supported = mi->supported[g_idx];
supported >>= mi->max_tp_rate[0] % MCS_GROUP_RATES;
- for (i = 0; supported; i++) {
+ for (i = 0; supported; supported >>= 1, i++) {
if (!(supported & 1))
continue;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Jiri Pirko @ 2019-08-22 12:19 UTC (permalink / raw)
To: Parav Pandit
Cc: Alex Williamson, Jiri Pirko, David S . Miller, Kirti Wankhede,
Cornelia Huck, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia, netdev@vger.kernel.org
In-Reply-To: <AM0PR05MB4866144FD76C302D04DA04B9D1A50@AM0PR05MB4866.eurprd05.prod.outlook.com>
Thu, Aug 22, 2019 at 12:04:02PM CEST, parav@mellanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: Thursday, August 22, 2019 3:28 PM
>> To: Parav Pandit <parav@mellanox.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> Wankhede <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
>> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> netdev@vger.kernel.org
>> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>>
>> Thu, Aug 22, 2019 at 11:42:13AM CEST, parav@mellanox.com wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> Sent: Thursday, August 22, 2019 2:59 PM
>> >> To: Parav Pandit <parav@mellanox.com>
>> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
>> <cohuck@redhat.com>;
>> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> >> <cjia@nvidia.com>; netdev@vger.kernel.org
>> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >>
>> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, parav@mellanox.com wrote:
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Alex Williamson <alex.williamson@redhat.com>
>> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
>> >> >> To: Parav Pandit <parav@mellanox.com>
>> >> >> Cc: Jiri Pirko <jiri@mellanox.com>; David S . Miller
>> >> >> <davem@davemloft.net>; Kirti Wankhede <kwankhede@nvidia.com>;
>> >> >> Cornelia Huck <cohuck@redhat.com>; kvm@vger.kernel.org;
>> >> >> linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> >> >> netdev@vger.kernel.org
>> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >> >>
>> >> >> > > > > Just an example of the alias, not proposing how it's set.
>> >> >> > > > > In fact, proposing that the user does not set it,
>> >> >> > > > > mdev-core provides one
>> >> >> > > automatically.
>> >> >> > > > >
>> >> >> > > > > > > Since there seems to be some prefix overhead, as I ask
>> >> >> > > > > > > about above in how many characters we actually have to
>> >> >> > > > > > > work with in IFNAMESZ, maybe we start with 8
>> >> >> > > > > > > characters (matching your "index" namespace) and
>> >> >> > > > > > > expand as necessary for
>> >> disambiguation.
>> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's start with 12.
>> >> >> > > > > > > Thanks,
>> >> >> > > > > > >
>> >> >> > > > > > If user is going to choose the alias, why does it have
>> >> >> > > > > > to be limited to
>> >> >> sha1?
>> >> >> > > > > > Or you just told it as an example?
>> >> >> > > > > >
>> >> >> > > > > > It can be an alpha-numeric string.
>> >> >> > > > >
>> >> >> > > > > No, I'm proposing a different solution where mdev-core
>> >> >> > > > > creates an alias based on an abbreviated sha1. The user
>> >> >> > > > > does not provide the
>> >> >> alias.
>> >> >> > > > >
>> >> >> > > > > > Instead of mdev imposing number of characters on the
>> >> >> > > > > > alias, it should be best
>> >> >> > > > > left to the user.
>> >> >> > > > > > Because in future if netdev improves on the naming
>> >> >> > > > > > scheme, mdev will be
>> >> >> > > > > limiting it, which is not right.
>> >> >> > > > > > So not restricting alias size seems right to me.
>> >> >> > > > > > User configuring mdev for networking devices in a given
>> >> >> > > > > > kernel knows what
>> >> >> > > > > user is doing.
>> >> >> > > > > > So user can choose alias name size as it finds suitable.
>> >> >> > > > >
>> >> >> > > > > That's not what I'm proposing, please read again. Thanks,
>> >> >> > > >
>> >> >> > > > I understood your point. But mdev doesn't know how user is
>> >> >> > > > going to use
>> >> >> > > udev/systemd to name the netdev.
>> >> >> > > > So even if mdev chose to pick 12 characters, it could result in
>> collision.
>> >> >> > > > Hence the proposal to provide the alias by the user, as user
>> >> >> > > > know the best
>> >> >> > > policy for its use case in the environment its using.
>> >> >> > > > So 12 character sha1 method will still work by user.
>> >> >> > >
>> >> >> > > Haven't you already provided examples where certain drivers or
>> >> >> > > subsystems have unique netdev prefixes? If mdev provides a
>> >> >> > > unique alias within the subsystem, couldn't we simply define a
>> >> >> > > netdev prefix for the mdev subsystem and avoid all other
>> >> >> > > collisions? I'm not in favor of the user providing both a
>> >> >> > > uuid and an alias/instance. Thanks,
>> >> >> > >
>> >> >> > For a given prefix, say ens2f0, can two UUID->sha1 first 9
>> >> >> > characters have
>> >> >> collision?
>> >> >>
>> >> >> I think it would be a mistake to waste so many chars on a prefix,
>> >> >> but
>> >> >> 9 characters of sha1 likely wouldn't have a collision before we
>> >> >> have 10s of thousands of devices. Thanks,
>> >> >>
>> >> >> Alex
>> >> >
>> >> >Jiri, Dave,
>> >> >Are you ok with it for devlink/netdev part?
>> >> >Mdev core will create an alias from a UUID.
>> >> >
>> >> >This will be supplied during devlink port attr set such as,
>> >> >
>> >> >devlink_port_attrs_mdev_set(struct devlink_port *port, const char
>> >> >*mdev_alias);
>> >> >
>> >> >This alias is used to generate representor netdev's phys_port_name.
>> >> >This alias from the mdev device's sysfs will be used by the
>> >> >udev/systemd to
>> >> generate predicable netdev's name.
>> >> >Example: enm<mdev_alias_first_12_chars>
>> >>
>> >> What happens in unlikely case of 2 UUIDs collide?
>> >>
>> >Since users sees two devices with same phys_port_name, user should destroy
>> recently created mdev and recreate mdev with different UUID?
>>
>> Driver should make sure phys port name wont collide,
>So when mdev creation is initiated, mdev core calculates the alias and if there is any other mdev with same alias exist, it returns -EEXIST error before progressing further.
>This way user will get to know upfront in event of collision before the mdev device gets created.
>How about that?
Sounds fine to me. Now the question is how many chars do we want to
have.
>
>
>> in this case that it does
>> not provide 2 same attrs for 2 different ports.
>> Hmm, so the order of creation matters. That is not good.
>>
>> >>
>> >> >I took Ethernet mdev as an example.
>> >> >New prefix 'm' stands for mediated device.
>> >> >Remaining 12 characters are first 12 chars of the mdev alias.
>> >>
>> >> Does this resolve the identification of devlink port representor?
>> >Not sure if I understood your question correctly, attemping to answer below.
>> >phys_port_name of devlink port is defined by the first 12 characters of mdev
>> alias.
>> >> I assume you want to use the same 12(or so) chars, don't you?
>> >Mdev's netdev will also use the same mdev alias from the sysfs to rename
>> netdev name from ethX to enm<mdev_alias>, where en=Etherenet, m=mdev.
>> >
>> >So yes, same 12 characters are use for mdev's netdev and mdev devlink port's
>> phys_port_name.
>> >
>> >Is that what are you asking?
>>
>> Yes. Then you have 3 chars to handle the rest of the name (pci, pf)...
^ permalink raw reply
* Re: BUG: MAX_STACK_TRACE_ENTRIES too low in tipc_topsrv_exit_net
From: Andrey Konovalov @ 2019-08-22 12:03 UTC (permalink / raw)
To: syzbot, David S. Miller, jon.maloy, LKML, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
In-Reply-To: <20190822030549.GA6111@zzz.localdomain>
On Thu, Aug 22, 2019 at 5:05 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Mon, Aug 19, 2019 at 05:22:07AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 5181b473 net: phy: realtek: add NBase-T PHY auto-detection
> > git tree: net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=156b731c600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5f97459a05652f579f6c
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5f97459a05652f579f6c@syzkaller.appspotmail.com
> >
> > BUG: MAX_STACK_TRACE_ENTRIES too low!
> > turning off the locking correctness validator.
> > CPU: 0 PID: 2581 Comm: kworker/u4:4 Not tainted 5.3.0-rc3+ #132
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: netns cleanup_net
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > save_trace kernel/locking/lockdep.c:473 [inline]
> > save_trace.isra.0.cold+0x14/0x19 kernel/locking/lockdep.c:458
> > mark_lock+0x3db/0x11e0 kernel/locking/lockdep.c:3583
> > mark_usage kernel/locking/lockdep.c:3517 [inline]
> > __lock_acquire+0x538/0x4c30 kernel/locking/lockdep.c:3834
> > lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4412
> > flush_workqueue+0x126/0x14b0 kernel/workqueue.c:2774
> > drain_workqueue+0x1b4/0x470 kernel/workqueue.c:2939
> > destroy_workqueue+0x21/0x6c0 kernel/workqueue.c:4320
> > tipc_topsrv_work_stop net/tipc/topsrv.c:636 [inline]
> > tipc_topsrv_stop net/tipc/topsrv.c:694 [inline]
> > tipc_topsrv_exit_net+0x3fe/0x5d8 net/tipc/topsrv.c:706
> > ops_exit_list.isra.0+0xaa/0x150 net/core/net_namespace.c:172
> > cleanup_net+0x4e2/0xa70 net/core/net_namespace.c:594
> > process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
> > worker_thread+0x98/0xe40 kernel/workqueue.c:2415
> > kthread+0x361/0x430 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> > kobject: 'rx-0' (000000000e2c91cd): kobject_cleanup, parent 000000002003fefb
> > kobject: 'rx-0' (000000000e2c91cd): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000000e2c91cd): kobject_uevent_env
> > kobject: 'rx-0' (000000000e2c91cd): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000000e2c91cd): auto cleanup kobject_del
> > kobject: 'rx-0' (000000000e2c91cd): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000058b6f726): kobject_cleanup, parent 000000002003fefb
> > kobject: 'tx-0' (0000000058b6f726): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000058b6f726): kobject_uevent_env
> > kobject: 'tx-0' (0000000058b6f726): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000058b6f726): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000058b6f726): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000002003fefb): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000002003fefb): calling ktype release
> > kobject: 'queues' (000000002003fefb): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (0000000018a24d65): kobject_uevent_env
> > kobject: 'ip6gre0' (0000000018a24d65): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000940b22b0): kobject_cleanup, parent 0000000005a1fc3a
> > kobject: 'rx-0' (00000000940b22b0): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000940b22b0): kobject_uevent_env
> > kobject: 'rx-0' (00000000940b22b0): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000940b22b0): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000940b22b0): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000278e85e2): kobject_cleanup, parent 0000000005a1fc3a
> > kobject: 'tx-0' (00000000278e85e2): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000278e85e2): kobject_uevent_env
> > kobject: 'tx-0' (00000000278e85e2): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000278e85e2): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000278e85e2): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000005a1fc3a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000005a1fc3a): calling ktype release
> > kobject: 'queues' (0000000005a1fc3a): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000c78b955b): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000c78b955b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000000fa7c1d1): kobject_cleanup, parent 00000000d264d5b4
> > kobject: 'rx-0' (000000000fa7c1d1): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000000fa7c1d1): kobject_uevent_env
> > kobject: 'rx-0' (000000000fa7c1d1): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000000fa7c1d1): auto cleanup kobject_del
> > kobject: 'rx-0' (000000000fa7c1d1): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000000f66c80c): kobject_cleanup, parent 00000000d264d5b4
> > kobject: 'tx-0' (000000000f66c80c): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000000f66c80c): kobject_uevent_env
> > kobject: 'tx-0' (000000000f66c80c): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000000f66c80c): auto cleanup kobject_del
> > kobject: 'tx-0' (000000000f66c80c): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000d264d5b4): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000d264d5b4): calling ktype release
> > kobject: 'queues' (00000000d264d5b4): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000ef80dc29): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000ef80dc29): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f928d911): kobject_cleanup, parent 000000003c7c9951
> > kobject: 'rx-0' (00000000f928d911): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000f928d911): kobject_uevent_env
> > kobject: 'rx-0' (00000000f928d911): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f928d911): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000f928d911): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000009bf7cc90): kobject_cleanup, parent 000000003c7c9951
> > kobject: 'tx-0' (000000009bf7cc90): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000009bf7cc90): kobject_uevent_env
> > kobject: 'tx-0' (000000009bf7cc90): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000009bf7cc90): auto cleanup kobject_del
> > kobject: 'tx-0' (000000009bf7cc90): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000003c7c9951): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000003c7c9951): calling ktype release
> > kobject: 'queues' (000000003c7c9951): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000acb4e121): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000acb4e121): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000045fca4e1): kobject_cleanup, parent 000000001c9d9e42
> > kobject: 'rx-0' (0000000045fca4e1): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000045fca4e1): kobject_uevent_env
> > kobject: 'rx-0' (0000000045fca4e1): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000045fca4e1): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000045fca4e1): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000a309e805): kobject_cleanup, parent 000000001c9d9e42
> > kobject: 'tx-0' (00000000a309e805): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000a309e805): kobject_uevent_env
> > kobject: 'tx-0' (00000000a309e805): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000a309e805): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000a309e805): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000001c9d9e42): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000001c9d9e42): calling ktype release
> > kobject: 'queues' (000000001c9d9e42): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (0000000094fbf7bb): kobject_uevent_env
> > kobject: 'ip6gre0' (0000000094fbf7bb): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000443242e0): kobject_cleanup, parent 000000009f9df3e8
> > kobject: 'rx-0' (00000000443242e0): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000443242e0): kobject_uevent_env
> > kobject: 'rx-0' (00000000443242e0): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000443242e0): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000443242e0): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000005588ef99): kobject_cleanup, parent 000000009f9df3e8
> > kobject: 'tx-0' (000000005588ef99): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000005588ef99): kobject_uevent_env
> > kobject: 'tx-0' (000000005588ef99): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000005588ef99): auto cleanup kobject_del
> > kobject: 'tx-0' (000000005588ef99): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000009f9df3e8): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000009f9df3e8): calling ktype release
> > kobject: 'queues' (000000009f9df3e8): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (0000000060028093): kobject_uevent_env
> > kobject: 'ip6gre0' (0000000060028093): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000002c2db56): kobject_cleanup, parent 000000000ee23264
> > kobject: 'rx-0' (0000000002c2db56): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000002c2db56): kobject_uevent_env
> > kobject: 'rx-0' (0000000002c2db56): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000002c2db56): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000002c2db56): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000831daf90): kobject_cleanup, parent 000000000ee23264
> > kobject: 'tx-0' (00000000831daf90): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000831daf90): kobject_uevent_env
> > kobject: 'tx-0' (00000000831daf90): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000831daf90): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000831daf90): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000000ee23264): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000000ee23264): calling ktype release
> > kobject: 'queues' (000000000ee23264): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000e217374d): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000e217374d): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f8e7f44b): kobject_cleanup, parent 000000003daaa7c9
> > kobject: 'rx-0' (00000000f8e7f44b): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000f8e7f44b): kobject_uevent_env
> > kobject: 'rx-0' (00000000f8e7f44b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f8e7f44b): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000f8e7f44b): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000001277c9de): kobject_cleanup, parent 000000003daaa7c9
> > kobject: 'tx-0' (000000001277c9de): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000001277c9de): kobject_uevent_env
> > kobject: 'tx-0' (000000001277c9de): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000001277c9de): auto cleanup kobject_del
> > kobject: 'tx-0' (000000001277c9de): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000003daaa7c9): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000003daaa7c9): calling ktype release
> > kobject: 'queues' (000000003daaa7c9): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000597e3c0a): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000597e3c0a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000eb376580): kobject_cleanup, parent 0000000054d719cb
> > kobject: 'rx-0' (00000000eb376580): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000eb376580): kobject_uevent_env
> > kobject: 'rx-0' (00000000eb376580): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000eb376580): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000eb376580): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000040024191): kobject_cleanup, parent 0000000054d719cb
> > kobject: 'tx-0' (0000000040024191): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000040024191): kobject_uevent_env
> > kobject: 'tx-0' (0000000040024191): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000040024191): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000040024191): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000054d719cb): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000054d719cb): calling ktype release
> > kobject: 'queues' (0000000054d719cb): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6gre0' (00000000995a4c19): kobject_uevent_env
> > kobject: 'ip6gre0' (00000000995a4c19): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'ip6gre0' (0000000018a24d65): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (0000000018a24d65): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000c78b955b): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000c78b955b): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000ef80dc29): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000ef80dc29): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000acb4e121): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000acb4e121): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (0000000094fbf7bb): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (0000000094fbf7bb): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (0000000060028093): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (0000000060028093): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000e217374d): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000e217374d): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000597e3c0a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000597e3c0a): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'ip6gre0' (00000000995a4c19): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6gre0' (00000000995a4c19): calling ktype release
> > kobject: 'ip6gre0': free name
> > kobject: 'rx-0' (00000000a530319b): kobject_cleanup, parent 0000000044c197cb
> > kobject: 'rx-0' (00000000a530319b): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000a530319b): kobject_uevent_env
> > kobject: 'rx-0' (00000000a530319b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000a530319b): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000a530319b): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000036817586): kobject_cleanup, parent 0000000044c197cb
> > kobject: 'tx-0' (0000000036817586): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000036817586): kobject_uevent_env
> > kobject: 'tx-0' (0000000036817586): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000036817586): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000036817586): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000044c197cb): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000044c197cb): calling ktype release
> > kobject: 'queues' (0000000044c197cb): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (000000004d7cdca9): kobject_uevent_env
> > kobject: 'ip6tnl0' (000000004d7cdca9): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000009ad0ffcd): kobject_cleanup, parent 000000006632a50a
> > kobject: 'rx-0' (000000009ad0ffcd): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000009ad0ffcd): kobject_uevent_env
> > kobject: 'rx-0' (000000009ad0ffcd): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000009ad0ffcd): auto cleanup kobject_del
> > kobject: 'rx-0' (000000009ad0ffcd): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000cc8f7d89): kobject_cleanup, parent 000000006632a50a
> > kobject: 'tx-0' (00000000cc8f7d89): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000cc8f7d89): kobject_uevent_env
> > kobject: 'tx-0' (00000000cc8f7d89): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000cc8f7d89): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000cc8f7d89): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000006632a50a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000006632a50a): calling ktype release
> > kobject: 'queues' (000000006632a50a): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (00000000af12a50a): kobject_uevent_env
> > kobject: 'ip6tnl0' (00000000af12a50a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000000f3a002b): kobject_cleanup, parent 000000008e667009
> > kobject: 'rx-0' (000000000f3a002b): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000000f3a002b): kobject_uevent_env
> > kobject: 'rx-0' (000000000f3a002b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000000f3a002b): auto cleanup kobject_del
> > kobject: 'rx-0' (000000000f3a002b): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000003dd814d2): kobject_cleanup, parent 000000008e667009
> > kobject: 'tx-0' (000000003dd814d2): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000003dd814d2): kobject_uevent_env
> > kobject: 'tx-0' (000000003dd814d2): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000003dd814d2): auto cleanup kobject_del
> > kobject: 'tx-0' (000000003dd814d2): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000008e667009): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000008e667009): calling ktype release
> > kobject: 'queues' (000000008e667009): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (00000000ad24f481): kobject_uevent_env
> > kobject: 'ip6tnl0' (00000000ad24f481): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000b57b4b94): kobject_cleanup, parent 00000000c8f88c97
> > kobject: 'rx-0' (00000000b57b4b94): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000b57b4b94): kobject_uevent_env
> > kobject: 'rx-0' (00000000b57b4b94): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000b57b4b94): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000b57b4b94): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000035a9b1c): kobject_cleanup, parent 00000000c8f88c97
> > kobject: 'tx-0' (00000000035a9b1c): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000035a9b1c): kobject_uevent_env
> > kobject: 'tx-0' (00000000035a9b1c): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000035a9b1c): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000035a9b1c): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000c8f88c97): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000c8f88c97): calling ktype release
> > kobject: 'queues' (00000000c8f88c97): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (00000000e4871037): kobject_uevent_env
> > kobject: 'ip6tnl0' (00000000e4871037): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000009e5eabee): kobject_cleanup, parent 000000000bef0c44
> > kobject: 'rx-0' (000000009e5eabee): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000009e5eabee): kobject_uevent_env
> > kobject: 'rx-0' (000000009e5eabee): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000009e5eabee): auto cleanup kobject_del
> > kobject: 'rx-0' (000000009e5eabee): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000917837d7): kobject_cleanup, parent 000000000bef0c44
> > kobject: 'tx-0' (00000000917837d7): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000917837d7): kobject_uevent_env
> > kobject: 'tx-0' (00000000917837d7): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000917837d7): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000917837d7): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000000bef0c44): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000000bef0c44): calling ktype release
> > kobject: 'queues' (000000000bef0c44): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (00000000a48d6ad0): kobject_uevent_env
> > kobject: 'ip6tnl0' (00000000a48d6ad0): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000099277526): kobject_cleanup, parent 0000000085f382c3
> > kobject: 'rx-0' (0000000099277526): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000099277526): kobject_uevent_env
> > kobject: 'rx-0' (0000000099277526): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000099277526): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000099277526): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000e28e65a5): kobject_cleanup, parent 0000000085f382c3
> > kobject: 'tx-0' (00000000e28e65a5): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000e28e65a5): kobject_uevent_env
> > kobject: 'tx-0' (00000000e28e65a5): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000e28e65a5): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000e28e65a5): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000085f382c3): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000085f382c3): calling ktype release
> > kobject: 'queues' (0000000085f382c3): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (000000002480b06a): kobject_uevent_env
> > kobject: 'ip6tnl0' (000000002480b06a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000ad1f374e): kobject_cleanup, parent 000000004552107a
> > kobject: 'rx-0' (00000000ad1f374e): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000ad1f374e): kobject_uevent_env
> > kobject: 'rx-0' (00000000ad1f374e): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000ad1f374e): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000ad1f374e): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000a52c4930): kobject_cleanup, parent 000000004552107a
> > kobject: 'tx-0' (00000000a52c4930): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000a52c4930): kobject_uevent_env
> > kobject: 'tx-0' (00000000a52c4930): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000a52c4930): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000a52c4930): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000004552107a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000004552107a): calling ktype release
> > kobject: 'queues' (000000004552107a): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (00000000b5c75a98): kobject_uevent_env
> > kobject: 'ip6tnl0' (00000000b5c75a98): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000069cf2cec): kobject_cleanup, parent 000000000effb6b7
> > kobject: 'rx-0' (0000000069cf2cec): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000069cf2cec): kobject_uevent_env
> > kobject: 'rx-0' (0000000069cf2cec): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000069cf2cec): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000069cf2cec): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000f6dd67a1): kobject_cleanup, parent 000000000effb6b7
> > kobject: 'tx-0' (00000000f6dd67a1): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000f6dd67a1): kobject_uevent_env
> > kobject: 'tx-0' (00000000f6dd67a1): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000f6dd67a1): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000f6dd67a1): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000000effb6b7): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000000effb6b7): calling ktype release
> > kobject: 'queues' (000000000effb6b7): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (0000000017bab338): kobject_uevent_env
> > kobject: 'ip6tnl0' (0000000017bab338): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000005bed9a62): kobject_cleanup, parent 000000002a90c11d
> > kobject: 'rx-0' (000000005bed9a62): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000005bed9a62): kobject_uevent_env
> > kobject: 'rx-0' (000000005bed9a62): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000005bed9a62): auto cleanup kobject_del
> > kobject: 'rx-0' (000000005bed9a62): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000148a89bb): kobject_cleanup, parent 000000002a90c11d
> > kobject: 'tx-0' (00000000148a89bb): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000148a89bb): kobject_uevent_env
> > kobject: 'tx-0' (00000000148a89bb): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000148a89bb): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000148a89bb): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000002a90c11d): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000002a90c11d): calling ktype release
> > kobject: 'queues' (000000002a90c11d): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6tnl0' (000000007855542e): kobject_uevent_env
> > kobject: 'ip6tnl0' (000000007855542e): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'ip6tnl0' (000000004d7cdca9): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (000000004d7cdca9): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (00000000af12a50a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (00000000af12a50a): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (00000000ad24f481): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (00000000ad24f481): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (00000000e4871037): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (00000000e4871037): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (00000000a48d6ad0): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (00000000a48d6ad0): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (000000002480b06a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (000000002480b06a): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (00000000b5c75a98): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (00000000b5c75a98): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (0000000017bab338): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (0000000017bab338): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'ip6tnl0' (000000007855542e): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6tnl0' (000000007855542e): calling ktype release
> > kobject: 'ip6tnl0': free name
> > kobject: 'rx-0' (00000000faff8a75): kobject_cleanup, parent 000000003555e997
> > kobject: 'rx-0' (00000000faff8a75): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000faff8a75): kobject_uevent_env
> > kobject: 'rx-0' (00000000faff8a75): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000faff8a75): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000faff8a75): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000003377944b): kobject_cleanup, parent 000000003555e997
> > kobject: 'tx-0' (000000003377944b): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000003377944b): kobject_uevent_env
> > kobject: 'tx-0' (000000003377944b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000003377944b): auto cleanup kobject_del
> > kobject: 'tx-0' (000000003377944b): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000003555e997): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000003555e997): calling ktype release
> > kobject: 'queues' (000000003555e997): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (00000000ba6470e9): kobject_uevent_env
> > kobject: 'sit0' (00000000ba6470e9): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000003577adaa): kobject_cleanup, parent 00000000c5fbab92
> > kobject: 'rx-0' (000000003577adaa): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000003577adaa): kobject_uevent_env
> > kobject: 'rx-0' (000000003577adaa): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000003577adaa): auto cleanup kobject_del
> > kobject: 'rx-0' (000000003577adaa): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000f519527f): kobject_cleanup, parent 00000000c5fbab92
> > kobject: 'tx-0' (00000000f519527f): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000f519527f): kobject_uevent_env
> > kobject: 'tx-0' (00000000f519527f): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000f519527f): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000f519527f): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000c5fbab92): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000c5fbab92): calling ktype release
> > kobject: 'queues' (00000000c5fbab92): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (000000009f74c826): kobject_uevent_env
> > kobject: 'sit0' (000000009f74c826): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000137dfc9e): kobject_cleanup, parent 00000000e8ee822b
> > kobject: 'rx-0' (00000000137dfc9e): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000137dfc9e): kobject_uevent_env
> > kobject: 'rx-0' (00000000137dfc9e): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000137dfc9e): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000137dfc9e): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000cf51e058): kobject_cleanup, parent 00000000e8ee822b
> > kobject: 'tx-0' (00000000cf51e058): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000cf51e058): kobject_uevent_env
> > kobject: 'tx-0' (00000000cf51e058): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000cf51e058): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000cf51e058): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000e8ee822b): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000e8ee822b): calling ktype release
> > kobject: 'queues' (00000000e8ee822b): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (0000000065e536c8): kobject_uevent_env
> > kobject: 'sit0' (0000000065e536c8): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000265aa8c8): kobject_cleanup, parent 000000001c613bad
> > kobject: 'rx-0' (00000000265aa8c8): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000265aa8c8): kobject_uevent_env
> > kobject: 'rx-0' (00000000265aa8c8): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000265aa8c8): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000265aa8c8): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000669b1a88): kobject_cleanup, parent 000000001c613bad
> > kobject: 'tx-0' (00000000669b1a88): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000669b1a88): kobject_uevent_env
> > kobject: 'tx-0' (00000000669b1a88): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000669b1a88): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000669b1a88): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000001c613bad): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000001c613bad): calling ktype release
> > kobject: 'queues' (000000001c613bad): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (00000000b0b0bf77): kobject_uevent_env
> > kobject: 'sit0' (00000000b0b0bf77): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000c08b3e35): kobject_cleanup, parent 000000004d964cab
> > kobject: 'rx-0' (00000000c08b3e35): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000c08b3e35): kobject_uevent_env
> > kobject: 'rx-0' (00000000c08b3e35): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000c08b3e35): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000c08b3e35): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000006bb20443): kobject_cleanup, parent 000000004d964cab
> > kobject: 'tx-0' (000000006bb20443): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000006bb20443): kobject_uevent_env
> > kobject: 'tx-0' (000000006bb20443): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000006bb20443): auto cleanup kobject_del
> > kobject: 'tx-0' (000000006bb20443): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000004d964cab): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000004d964cab): calling ktype release
> > kobject: 'queues' (000000004d964cab): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (00000000e3a2a337): kobject_uevent_env
> > kobject: 'sit0' (00000000e3a2a337): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000fcf6c2df): kobject_cleanup, parent 000000001f378765
> > kobject: 'rx-0' (00000000fcf6c2df): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000fcf6c2df): kobject_uevent_env
> > kobject: 'rx-0' (00000000fcf6c2df): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000fcf6c2df): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000fcf6c2df): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000306e361a): kobject_cleanup, parent 000000001f378765
> > kobject: 'tx-0' (00000000306e361a): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000306e361a): kobject_uevent_env
> > kobject: 'tx-0' (00000000306e361a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000306e361a): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000306e361a): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000001f378765): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000001f378765): calling ktype release
> > kobject: 'queues' (000000001f378765): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (0000000058d12d0d): kobject_uevent_env
> > kobject: 'sit0' (0000000058d12d0d): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000078d95bd): kobject_cleanup, parent 000000003596feb5
> > kobject: 'rx-0' (00000000078d95bd): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000078d95bd): kobject_uevent_env
> > kobject: 'rx-0' (00000000078d95bd): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000078d95bd): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000078d95bd): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000037709752): kobject_cleanup, parent 000000003596feb5
> > kobject: 'tx-0' (0000000037709752): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000037709752): kobject_uevent_env
> > kobject: 'tx-0' (0000000037709752): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000037709752): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000037709752): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000003596feb5): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000003596feb5): calling ktype release
> > kobject: 'queues' (000000003596feb5): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (000000008276eda5): kobject_uevent_env
> > kobject: 'sit0' (000000008276eda5): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000004d3b044b): kobject_cleanup, parent 000000006b53a9a0
> > kobject: 'rx-0' (000000004d3b044b): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000004d3b044b): kobject_uevent_env
> > kobject: 'rx-0' (000000004d3b044b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000004d3b044b): auto cleanup kobject_del
> > kobject: 'rx-0' (000000004d3b044b): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000273da9ae): kobject_cleanup, parent 000000006b53a9a0
> > kobject: 'tx-0' (00000000273da9ae): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000273da9ae): kobject_uevent_env
> > kobject: 'tx-0' (00000000273da9ae): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000273da9ae): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000273da9ae): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000006b53a9a0): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000006b53a9a0): calling ktype release
> > kobject: 'queues' (000000006b53a9a0): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (000000005ed040cc): kobject_uevent_env
> > kobject: 'sit0' (000000005ed040cc): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f150476e): kobject_cleanup, parent 00000000a0cff6dd
> > kobject: 'rx-0' (00000000f150476e): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000f150476e): kobject_uevent_env
> > kobject: 'rx-0' (00000000f150476e): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000f150476e): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000f150476e): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000c81ff56b): kobject_cleanup, parent 00000000a0cff6dd
> > kobject: 'tx-0' (00000000c81ff56b): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000c81ff56b): kobject_uevent_env
> > kobject: 'tx-0' (00000000c81ff56b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000c81ff56b): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000c81ff56b): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000a0cff6dd): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000a0cff6dd): calling ktype release
> > kobject: 'queues' (00000000a0cff6dd): kset_release
> > kobject: 'queues': free name
> > kobject: 'sit0' (000000009ebda3df): kobject_uevent_env
> > kobject: 'sit0' (000000009ebda3df): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'sit0' (00000000ba6470e9): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (00000000ba6470e9): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (000000009f74c826): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (000000009f74c826): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (0000000065e536c8): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (0000000065e536c8): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (00000000b0b0bf77): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (00000000b0b0bf77): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (00000000e3a2a337): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (00000000e3a2a337): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (0000000058d12d0d): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (0000000058d12d0d): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (000000008276eda5): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (000000008276eda5): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (000000005ed040cc): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (000000005ed040cc): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'sit0' (000000009ebda3df): kobject_cleanup, parent 000000009c061a32
> > kobject: 'sit0' (000000009ebda3df): calling ktype release
> > kobject: 'sit0': free name
> > kobject: 'rx-0' (00000000011781b4): kobject_cleanup, parent 0000000037662b61
> > kobject: 'rx-0' (00000000011781b4): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000011781b4): kobject_uevent_env
> > kobject: 'rx-0' (00000000011781b4): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000011781b4): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000011781b4): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000002bafd647): kobject_cleanup, parent 0000000037662b61
> > kobject: 'tx-0' (000000002bafd647): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000002bafd647): kobject_uevent_env
> > kobject: 'tx-0' (000000002bafd647): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000002bafd647): auto cleanup kobject_del
> > kobject: 'tx-0' (000000002bafd647): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000037662b61): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000037662b61): calling ktype release
> > kobject: 'queues' (0000000037662b61): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (000000000e5b1a5c): kobject_uevent_env
> > kobject: 'ip6_vti0' (000000000e5b1a5c): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000068311350): kobject_cleanup, parent 00000000facffc2f
> > kobject: 'rx-0' (0000000068311350): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000068311350): kobject_uevent_env
> > kobject: 'rx-0' (0000000068311350): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000068311350): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000068311350): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000d6e81326): kobject_cleanup, parent 00000000facffc2f
> > kobject: 'tx-0' (00000000d6e81326): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000d6e81326): kobject_uevent_env
> > kobject: 'tx-0' (00000000d6e81326): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000d6e81326): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000d6e81326): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000facffc2f): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000facffc2f): calling ktype release
> > kobject: 'queues' (00000000facffc2f): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (0000000084bcfa3e): kobject_uevent_env
> > kobject: 'ip6_vti0' (0000000084bcfa3e): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000ce1fbf9a): kobject_cleanup, parent 00000000faad76b9
> > kobject: 'rx-0' (00000000ce1fbf9a): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000ce1fbf9a): kobject_uevent_env
> > kobject: 'rx-0' (00000000ce1fbf9a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000ce1fbf9a): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000ce1fbf9a): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000054a9318d): kobject_cleanup, parent 00000000faad76b9
> > kobject: 'tx-0' (0000000054a9318d): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000054a9318d): kobject_uevent_env
> > kobject: 'tx-0' (0000000054a9318d): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000054a9318d): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000054a9318d): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000faad76b9): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000faad76b9): calling ktype release
> > kobject: 'queues' (00000000faad76b9): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (00000000a17dcb7a): kobject_uevent_env
> > kobject: 'ip6_vti0' (00000000a17dcb7a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000e1ec0489): kobject_cleanup, parent 0000000032133323
> > kobject: 'rx-0' (00000000e1ec0489): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000e1ec0489): kobject_uevent_env
> > kobject: 'rx-0' (00000000e1ec0489): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000e1ec0489): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000e1ec0489): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000c69707b0): kobject_cleanup, parent 0000000032133323
> > kobject: 'tx-0' (00000000c69707b0): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000c69707b0): kobject_uevent_env
> > kobject: 'tx-0' (00000000c69707b0): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000c69707b0): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000c69707b0): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000032133323): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000032133323): calling ktype release
> > kobject: 'queues' (0000000032133323): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (00000000f1a1ebea): kobject_uevent_env
> > kobject: 'ip6_vti0' (00000000f1a1ebea): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000310059d9): kobject_cleanup, parent 000000002f7c701e
> > kobject: 'rx-0' (00000000310059d9): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000310059d9): kobject_uevent_env
> > kobject: 'rx-0' (00000000310059d9): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000310059d9): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000310059d9): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000463fbeb0): kobject_cleanup, parent 000000002f7c701e
> > kobject: 'tx-0' (00000000463fbeb0): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000463fbeb0): kobject_uevent_env
> > kobject: 'tx-0' (00000000463fbeb0): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000463fbeb0): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000463fbeb0): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000002f7c701e): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000002f7c701e): calling ktype release
> > kobject: 'queues' (000000002f7c701e): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (00000000e99a1c16): kobject_uevent_env
> > kobject: 'ip6_vti0' (00000000e99a1c16): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000fc3878f1): kobject_cleanup, parent 0000000039005ce6
> > kobject: 'rx-0' (00000000fc3878f1): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000fc3878f1): kobject_uevent_env
> > kobject: 'rx-0' (00000000fc3878f1): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000fc3878f1): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000fc3878f1): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (000000003da8a217): kobject_cleanup, parent 0000000039005ce6
> > kobject: 'tx-0' (000000003da8a217): auto cleanup 'remove' event
> > kobject: 'tx-0' (000000003da8a217): kobject_uevent_env
> > kobject: 'tx-0' (000000003da8a217): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (000000003da8a217): auto cleanup kobject_del
> > kobject: 'tx-0' (000000003da8a217): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (0000000039005ce6): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (0000000039005ce6): calling ktype release
> > kobject: 'queues' (0000000039005ce6): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (000000003f213163): kobject_uevent_env
> > kobject: 'ip6_vti0' (000000003f213163): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000066dc1b5f): kobject_cleanup, parent 00000000e169d802
> > kobject: 'rx-0' (0000000066dc1b5f): auto cleanup 'remove' event
> > kobject: 'rx-0' (0000000066dc1b5f): kobject_uevent_env
> > kobject: 'rx-0' (0000000066dc1b5f): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (0000000066dc1b5f): auto cleanup kobject_del
> > kobject: 'rx-0' (0000000066dc1b5f): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000b99448c7): kobject_cleanup, parent 00000000e169d802
> > kobject: 'tx-0' (00000000b99448c7): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000b99448c7): kobject_uevent_env
> > kobject: 'tx-0' (00000000b99448c7): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000b99448c7): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000b99448c7): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000e169d802): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000e169d802): calling ktype release
> > kobject: 'queues' (00000000e169d802): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (000000003422603c): kobject_uevent_env
> > kobject: 'ip6_vti0' (000000003422603c): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000b6464399): kobject_cleanup, parent 00000000785ed365
> > kobject: 'rx-0' (00000000b6464399): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000b6464399): kobject_uevent_env
> > kobject: 'rx-0' (00000000b6464399): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000b6464399): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000b6464399): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000c2beb7d2): kobject_cleanup, parent 00000000785ed365
> > kobject: 'tx-0' (00000000c2beb7d2): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000c2beb7d2): kobject_uevent_env
> > kobject: 'tx-0' (00000000c2beb7d2): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000c2beb7d2): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000c2beb7d2): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000785ed365): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000785ed365): calling ktype release
> > kobject: 'queues' (00000000785ed365): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (0000000031ab464d): kobject_uevent_env
> > kobject: 'ip6_vti0' (0000000031ab464d): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000a7d5a6f7): kobject_cleanup, parent 00000000ed628333
> > kobject: 'rx-0' (00000000a7d5a6f7): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000a7d5a6f7): kobject_uevent_env
> > kobject: 'rx-0' (00000000a7d5a6f7): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000a7d5a6f7): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000a7d5a6f7): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000564c497f): kobject_cleanup, parent 00000000ed628333
> > kobject: 'tx-0' (00000000564c497f): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000564c497f): kobject_uevent_env
> > kobject: 'tx-0' (00000000564c497f): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000564c497f): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000564c497f): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000ed628333): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (00000000ed628333): calling ktype release
> > kobject: 'queues' (00000000ed628333): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip6_vti0' (00000000fb053a2a): kobject_uevent_env
> > kobject: 'ip6_vti0' (00000000fb053a2a): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'ip6_vti0' (000000000e5b1a5c): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (000000000e5b1a5c): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (0000000084bcfa3e): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (0000000084bcfa3e): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (00000000a17dcb7a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (00000000a17dcb7a): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (00000000f1a1ebea): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (00000000f1a1ebea): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (00000000e99a1c16): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (00000000e99a1c16): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (000000003f213163): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (000000003f213163): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (000000003422603c): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (000000003422603c): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (0000000031ab464d): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (0000000031ab464d): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'ip6_vti0' (00000000fb053a2a): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'ip6_vti0' (00000000fb053a2a): calling ktype release
> > kobject: 'ip6_vti0': free name
> > kobject: 'rx-0' (00000000c827514b): kobject_cleanup, parent 000000004e70d3ea
> > kobject: 'rx-0' (00000000c827514b): auto cleanup 'remove' event
> > kobject: 'rx-0' (00000000c827514b): kobject_uevent_env
> > kobject: 'rx-0' (00000000c827514b): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (00000000c827514b): auto cleanup kobject_del
> > kobject: 'rx-0' (00000000c827514b): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (00000000e9330ec4): kobject_cleanup, parent 000000004e70d3ea
> > kobject: 'tx-0' (00000000e9330ec4): auto cleanup 'remove' event
> > kobject: 'tx-0' (00000000e9330ec4): kobject_uevent_env
> > kobject: 'tx-0' (00000000e9330ec4): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (00000000e9330ec4): auto cleanup kobject_del
> > kobject: 'tx-0' (00000000e9330ec4): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (000000004e70d3ea): kobject_cleanup, parent
> > 000000009c061a32
> > kobject: 'queues' (000000004e70d3ea): calling ktype release
> > kobject: 'queues' (000000004e70d3ea): kset_release
> > kobject: 'queues': free name
> > kobject: 'ip_vti0' (000000004ee7ad23): kobject_uevent_env
> > kobject: 'ip_vti0' (000000004ee7ad23): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000004dda38d8): kobject_cleanup, parent 00000000025cb3fe
> > kobject: 'rx-0' (000000004dda38d8): auto cleanup 'remove' event
> > kobject: 'rx-0' (000000004dda38d8): kobject_uevent_env
> > kobject: 'rx-0' (000000004dda38d8): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'rx-0' (000000004dda38d8): auto cleanup kobject_del
> > kobject: 'rx-0' (000000004dda38d8): calling ktype release
> > kobject: 'rx-0': free name
> > kobject: 'tx-0' (0000000097fba38d): kobject_cleanup, parent 00000000025cb3fe
> > kobject: 'tx-0' (0000000097fba38d): auto cleanup 'remove' event
> > kobject: 'tx-0' (0000000097fba38d): kobject_uevent_env
> > kobject: 'tx-0' (0000000097fba38d): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> > kobject: 'tx-0' (0000000097fba38d): auto cleanup kobject_del
> > kobject: 'tx-0' (0000000097fba38d): calling ktype release
> > kobject: 'tx-0': free name
> > kobject: 'queues' (00000000025cb3fe): kobject_cleanup, parent
> > 000000009c061a32
> >
> >
> > ---
> > 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.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000071c72c0590776357%40google.com.
>
> Looks to be:
>
> #syz dup: BUG: MAX_STACK_TRACE_ENTRIES too low! (2)
>
> Original thread: https://lkml.kernel.org/lkml/0000000000005ff8b20585395280@google.com/T/#u
>
> The caller isn't really meaningful for "MAX_STACK_TRACE_ENTRIES too low" bugs,
> so I think
> https://github.com/google/syzkaller/pull/1332/commits/ccbd11f30158d198e84953b1bb5eaa33464d9311
> should be reverted...
>
> - Eric
Hm, when I looked at the stack traces of the reports they all seemed
to be coming from only a few particular origins. But looking at the
code it seems there's a global array of stack trace entries that can
only grow, so this can be triggered anywhere. I'll revert the change.
^ permalink raw reply
* Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf
From: Toke Høiland-Jørgensen @ 2019-08-22 12:04 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Hemminger, Alexei Starovoitov
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Jesper Dangaard Brouer, netdev, bpf, andrii.nakryiko
In-Reply-To: <0c3d78eb-d305-9266-b505-c2f9181d5c89@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 8/22/19 12:43 PM, Toke Høiland-Jørgensen wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>>> On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:
>>>> This adds a configure check for libbpf and renames functions to allow
>>>> lib/bpf.c to be compiled with it present. This makes it possible to
>>>> port functionality piecemeal to use libbpf.
>>>>
>>>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>>>> ---
>>>> configure | 16 ++++++++++++++++
>>>> include/bpf_util.h | 6 +++---
>>>> ip/ipvrf.c | 4 ++--
>>>> lib/bpf.c | 33 +++++++++++++++++++--------------
>>>> 4 files changed, 40 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/configure b/configure
>>>> index 45fcffb6..5a89ee9f 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -238,6 +238,19 @@ check_elf()
>>>> fi
>>>> }
>>>>
>>>> +check_libbpf()
>>>> +{
>>>> + if ${PKG_CONFIG} libbpf --exists; then
>>>> + echo "HAVE_LIBBPF:=y" >>$CONFIG
>>>> + echo "yes"
>>>> +
>>>> + echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
>>>> + echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
>>>> + else
>>>> + echo "no"
>>>> + fi
>>>> +}
>>>> +
>>>> check_selinux()
>>>
>>> More of an implementation detail at this point in time, but want to
>>> make sure this doesn't get missed along the way: as discussed at
>>> bpfconf [0] best for iproute2 to handle libbpf support would be the
>>> same way of integration as pahole does, that is, to integrate it via
>>> submodule [1] to allow kernel and libbpf features to be in sync with
>>> iproute2 releases and therefore easily consume extensions we're adding
>>> to libbpf to aide iproute2 integration.
>>
>> I can sorta see the point wrt keeping in sync with kernel features. But
>> how will this work with distros that package libbpf as a regular
>> library? Have you guys given up on regular library symbol versioning for
>> libbpf?
>
> Not at all, and I hope you know that. ;-)
Good! Didn't really expect you had, just checking ;)
> The reason I added lib/bpf.c integration into iproute2 directly back
> then was exactly such that users can start consuming BPF for tc and
> XDP via iproute2 /everywhere/ with only a simple libelf dependency
> which is also available on all distros since pretty much forever. If
> it was an external library, we could have waited till hell freezes
> over and initial distro adoption would have pretty much taken forever:
> to pick one random example here wrt the pace of some downstream
> distros [0]. The main rationale is pretty much the same as with added
> kernel features that land complementary iproute2 patches for that
> kernel release and as libbpf is developed alongside it is reasonable
> to guarantee user expectations that iproute2 released for kernel
> version x can make use of BPF features added to kernel x with same
> loader support from x.
Well, for iproute2 I would expect this to be solved by version
dependencies. I.e. iproute2 version X would depend on libbpf version Y+
(like, I dunno, the version of libbpf included in the same kernel source
tree as the kernel version iproute2 is targeting? :)).
If we vendor libbpf into every project using it, we'll end up with
dozens of different versions statically linked into each binary, kinda
defeating the purpose of having it as a shared library in the first
place...
-Toke
^ permalink raw reply
* Re: [PATCH][net-next] net: drop_monitor: change the stats variable to u64 in net_dm_stats_put
From: Ido Schimmel @ 2019-08-22 11:59 UTC (permalink / raw)
To: Li RongQing; +Cc: netdev, idosch
In-Reply-To: <1566454953-29321-1-git-send-email-lirongqing@baidu.com>
On Thu, Aug 22, 2019 at 02:22:33PM +0800, Li RongQing wrote:
> only the element drop of struct net_dm_stats is used, so simplify it to u64
Thanks for the patch, but I don't really see the value here. The struct
allows for easy extensions in the future. What do you gain from this
change? We merely read stats and report them to user space, so I guess
it's not about performance either.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/core/drop_monitor.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
> index bfc024024aa3..ed10a40cf629 100644
> --- a/net/core/drop_monitor.c
> +++ b/net/core/drop_monitor.c
> @@ -1329,11 +1329,11 @@ static int net_dm_cmd_config_get(struct sk_buff *skb, struct genl_info *info)
> return rc;
> }
>
> -static void net_dm_stats_read(struct net_dm_stats *stats)
> +static void net_dm_stats_read(u64 *stats)
> {
> int cpu;
>
> - memset(stats, 0, sizeof(*stats));
> + *stats = 0;
> for_each_possible_cpu(cpu) {
> struct per_cpu_dm_data *data = &per_cpu(dm_cpu_data, cpu);
> struct net_dm_stats *cpu_stats = &data->stats;
> @@ -1345,14 +1345,14 @@ static void net_dm_stats_read(struct net_dm_stats *stats)
> dropped = cpu_stats->dropped;
> } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, start));
>
> - stats->dropped += dropped;
> + *stats += dropped;
> }
> }
>
> static int net_dm_stats_put(struct sk_buff *msg)
> {
> - struct net_dm_stats stats;
> struct nlattr *attr;
> + u64 stats;
>
> net_dm_stats_read(&stats);
>
> @@ -1361,7 +1361,7 @@ static int net_dm_stats_put(struct sk_buff *msg)
> return -EMSGSIZE;
>
> if (nla_put_u64_64bit(msg, NET_DM_ATTR_STATS_DROPPED,
> - stats.dropped, NET_DM_ATTR_PAD))
> + stats, NET_DM_ATTR_PAD))
> goto nla_put_failure;
>
> nla_nest_end(msg, attr);
> --
> 2.16.2
>
^ permalink raw reply
* Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Toke Høiland-Jørgensen @ 2019-08-22 11:49 UTC (permalink / raw)
To: Daniel Borkmann, Andrii Nakryiko
Cc: Stephen Hemminger, Alexei Starovoitov, Martin KaFai Lau, Song Liu,
Yonghong Song, David Miller, Jesper Dangaard Brouer, Networking,
bpf
In-Reply-To: <87d0gxpgjw.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> Daniel Borkmann <daniel@iogearbox.net> writes:
>
>> On 8/22/19 9:49 AM, Andrii Nakryiko wrote:
>>> On Wed, Aug 21, 2019 at 2:07 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>>> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>>>>> On Tue, Aug 20, 2019 at 4:47 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>>>>>
>>>>>> iproute2 uses its own bpf loader to load eBPF programs, which has
>>>>>> evolved separately from libbpf. Since we are now standardising on
>>>>>> libbpf, this becomes a problem as iproute2 is slowly accumulating
>>>>>> feature incompatibilities with libbpf-based loaders. In particular,
>>>>>> iproute2 has its own (expanded) version of the map definition struct,
>>>>>> which makes it difficult to write programs that can be loaded with both
>>>>>> custom loaders and iproute2.
>>>>>>
>>>>>> This series seeks to address this by converting iproute2 to using libbpf
>>>>>> for all its bpf needs. This version is an early proof-of-concept RFC, to
>>>>>> get some feedback on whether people think this is the right direction.
>>>>>>
>>>>>> What this series does is the following:
>>>>>>
>>>>>> - Updates the libbpf map definition struct to match that of iproute2
>>>>>> (patch 1).
>>>>>
>>>>> Thanks for taking a stab at unifying libbpf and iproute2 loaders. I'm
>>>>> totally in support of making iproute2 use libbpf to load/initialize
>>>>> BPF programs. But I'm against adding iproute2-specific fields to
>>>>> libbpf's bpf_map_def definitions to support this.
>>>>>
>>>>> I've proposed the plan of extending libbpf's supported features so
>>>>> that it can be used to load iproute2-style BPF programs earlier,
>>>>> please see discussions in [0] and [1].
>>>>
>>>> Yeah, I've seen that discussion, and agree that longer term this is
>>>> probably a better way to do map-in-map definitions.
>>>>
>>>> However, I view your proposal as complementary to this series: we'll
>>>> probably also want the BTF-based definition to work with iproute2, and
>>>> that means iproute2 needs to be ported to libbpf. But iproute2 needs to
>>>> be backwards compatible with the format it supports now, and, well, this
>>>> series is the simplest way to achieve that IMO :)
>>>
>>> Ok, I understand that. But I'd still want to avoid adding extra cruft
>>> to libbpf just for backwards-compatibility with *exact* iproute2
>>> format. Libbpf as a whole is trying to move away from relying on
>>> binary bpf_map_def and into using BTF-defined map definitions, and
>>> this patch series is a step backwards in that regard, that adds,
>>> essentially, already outdated stuff that we'll need to support forever
>>> (I mean those extra fields in bpf_map_def, that will stay there
>>> forever).
>>
>> Agree, adding these extensions for libbpf would be a step backwards
>> compared to using BTF defined map defs.
>>
>>> We've discussed one way to deal with it, IMO, in a cleaner way. It can
>>> be done in few steps:
>>>
>>> 1. I originally wanted BTF-defined map definitions to ignore unknown
>>> fields. It shouldn't be a default mode, but it should be supported
>>> (and of course is very easy to add). So let's add that and let libbpf
>>> ignore unknown stuff.
>>>
>>> 2. Then to let iproute2 loader deal with backwards-compatibility for
>>> libbpf-incompatible bpf_elf_map, we need to "pass-through" all those
>>> fields so that users of libbpf (iproute2 loader, in this case) can
>>> make use of it. The easiest and cleanest way to do this is to expose
>>> BTF ID of a type describing each map entry and let iproute2 process
>>> that in whichever way it sees fit.
>>>
>>> Luckily, bpf_elf_map is compatible in `type` field, which will let
>>> libbpf recognize bpf_elf_map as map definition. All the rest setup
>>> will be done by iproute2, by processing BTF of bpf_elf_map, which will
>>> let it set up map sizes, flags and do all of its map-in-map magic.
>>>
>>> The only additions to libbpf in this case would be a new `__u32
>>> bpf_map__btf_id(struct bpf_map* map);` API.
>>>
>>> I haven't written any code and haven't 100% checked that this will
>>> cover everything, but I think we should try. This will allow to let
>>> users of libbpf do custom stuff with map definitions without having to
>>> put all this extra logic into libbpf itself, which I think is
>>> desirable outcome.
>>
>> Sounds reasonable in general, but all this still has the issue that
>> we're assuming that BTF is /always/ present. Existing object files
>> that would load just fine /today/ but do not have BTF attached won't
>> be handled here. Wouldn't it be more straight forward to allow passing
>> callbacks to the libbpf loader such that if the map section is not
>> found to be bpf_map_def compatible, we rely on external user aka
>> callback to parse the ELF section, handle any non-default libbpf
>> behavior like pinning/retrieving from BPF fs, populate related
>> internal libbpf map data structures and pass control back to libbpf
>> loader afterwards. (Similar callback with prog section name handling
>> for the case where tail call maps get automatically populated.)
>
> Thinking about this some more, I think there are two separate issues
> here:
>
> 1. Do we want libbpf to support the features currently in iproute2 and
> bpf_helpers (i.e., map pinning + reuse, map-in-map definitions, and
> NUMA node placement of maps). IMO the answer to this is yes.
>
> 2. What should the data format be for BPF programs to signal that they
> want to use those features? Here, the longer-term answer is BTF-based
> map definitions, but we still want iproute2 to be backwards
> compatible.
>
>
> So how about I revise this patch series to implement the *features* (I
> already implemented map-in-map and numa nodes[0], so that is sorta
> already done), but instead of extending the bpf_map_def struct, I just
> expose callbacks that will allow programs to fill in internal-to-libbpf
> data structures with the required information. Then, once the BTF-based
> map definition does land, that can simply define default callbacks that
> uses the BTF information to fill in those same internal data structures?
>
> This would mean no extending bpf_map_def, and relaxing the current
> libbpf restriction on extending bpf_map_def.
>
> The drawback of this approach is that it does nothing to combat
> fragmentation: People building their own loaders can still reimplement
> different semantics for map defs, leading to programs that are tied to a
> particular loader. So this would only work if we really believe BTF can
> save us from this. I don't feel competent to comment on this just yet,
> but thought I'd mention it :)
>
> -Toke
[0] was supposed to be a reference to
https://github.com/tohojo/libbpf/tree/iproute2-compat
^ permalink raw reply
* Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Toke Høiland-Jørgensen @ 2019-08-22 11:48 UTC (permalink / raw)
To: Daniel Borkmann, Andrii Nakryiko
Cc: Stephen Hemminger, Alexei Starovoitov, Martin KaFai Lau, Song Liu,
Yonghong Song, David Miller, Jesper Dangaard Brouer, Networking,
bpf
In-Reply-To: <43e8c177-cc9c-ca0b-1622-e30a7a1281b7@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 8/22/19 9:49 AM, Andrii Nakryiko wrote:
>> On Wed, Aug 21, 2019 at 2:07 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>>>> On Tue, Aug 20, 2019 at 4:47 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>>>>
>>>>> iproute2 uses its own bpf loader to load eBPF programs, which has
>>>>> evolved separately from libbpf. Since we are now standardising on
>>>>> libbpf, this becomes a problem as iproute2 is slowly accumulating
>>>>> feature incompatibilities with libbpf-based loaders. In particular,
>>>>> iproute2 has its own (expanded) version of the map definition struct,
>>>>> which makes it difficult to write programs that can be loaded with both
>>>>> custom loaders and iproute2.
>>>>>
>>>>> This series seeks to address this by converting iproute2 to using libbpf
>>>>> for all its bpf needs. This version is an early proof-of-concept RFC, to
>>>>> get some feedback on whether people think this is the right direction.
>>>>>
>>>>> What this series does is the following:
>>>>>
>>>>> - Updates the libbpf map definition struct to match that of iproute2
>>>>> (patch 1).
>>>>
>>>> Thanks for taking a stab at unifying libbpf and iproute2 loaders. I'm
>>>> totally in support of making iproute2 use libbpf to load/initialize
>>>> BPF programs. But I'm against adding iproute2-specific fields to
>>>> libbpf's bpf_map_def definitions to support this.
>>>>
>>>> I've proposed the plan of extending libbpf's supported features so
>>>> that it can be used to load iproute2-style BPF programs earlier,
>>>> please see discussions in [0] and [1].
>>>
>>> Yeah, I've seen that discussion, and agree that longer term this is
>>> probably a better way to do map-in-map definitions.
>>>
>>> However, I view your proposal as complementary to this series: we'll
>>> probably also want the BTF-based definition to work with iproute2, and
>>> that means iproute2 needs to be ported to libbpf. But iproute2 needs to
>>> be backwards compatible with the format it supports now, and, well, this
>>> series is the simplest way to achieve that IMO :)
>>
>> Ok, I understand that. But I'd still want to avoid adding extra cruft
>> to libbpf just for backwards-compatibility with *exact* iproute2
>> format. Libbpf as a whole is trying to move away from relying on
>> binary bpf_map_def and into using BTF-defined map definitions, and
>> this patch series is a step backwards in that regard, that adds,
>> essentially, already outdated stuff that we'll need to support forever
>> (I mean those extra fields in bpf_map_def, that will stay there
>> forever).
>
> Agree, adding these extensions for libbpf would be a step backwards
> compared to using BTF defined map defs.
>
>> We've discussed one way to deal with it, IMO, in a cleaner way. It can
>> be done in few steps:
>>
>> 1. I originally wanted BTF-defined map definitions to ignore unknown
>> fields. It shouldn't be a default mode, but it should be supported
>> (and of course is very easy to add). So let's add that and let libbpf
>> ignore unknown stuff.
>>
>> 2. Then to let iproute2 loader deal with backwards-compatibility for
>> libbpf-incompatible bpf_elf_map, we need to "pass-through" all those
>> fields so that users of libbpf (iproute2 loader, in this case) can
>> make use of it. The easiest and cleanest way to do this is to expose
>> BTF ID of a type describing each map entry and let iproute2 process
>> that in whichever way it sees fit.
>>
>> Luckily, bpf_elf_map is compatible in `type` field, which will let
>> libbpf recognize bpf_elf_map as map definition. All the rest setup
>> will be done by iproute2, by processing BTF of bpf_elf_map, which will
>> let it set up map sizes, flags and do all of its map-in-map magic.
>>
>> The only additions to libbpf in this case would be a new `__u32
>> bpf_map__btf_id(struct bpf_map* map);` API.
>>
>> I haven't written any code and haven't 100% checked that this will
>> cover everything, but I think we should try. This will allow to let
>> users of libbpf do custom stuff with map definitions without having to
>> put all this extra logic into libbpf itself, which I think is
>> desirable outcome.
>
> Sounds reasonable in general, but all this still has the issue that
> we're assuming that BTF is /always/ present. Existing object files
> that would load just fine /today/ but do not have BTF attached won't
> be handled here. Wouldn't it be more straight forward to allow passing
> callbacks to the libbpf loader such that if the map section is not
> found to be bpf_map_def compatible, we rely on external user aka
> callback to parse the ELF section, handle any non-default libbpf
> behavior like pinning/retrieving from BPF fs, populate related
> internal libbpf map data structures and pass control back to libbpf
> loader afterwards. (Similar callback with prog section name handling
> for the case where tail call maps get automatically populated.)
Thinking about this some more, I think there are two separate issues
here:
1. Do we want libbpf to support the features currently in iproute2 and
bpf_helpers (i.e., map pinning + reuse, map-in-map definitions, and
NUMA node placement of maps). IMO the answer to this is yes.
2. What should the data format be for BPF programs to signal that they
want to use those features? Here, the longer-term answer is BTF-based
map definitions, but we still want iproute2 to be backwards
compatible.
So how about I revise this patch series to implement the *features* (I
already implemented map-in-map and numa nodes[0], so that is sorta
already done), but instead of extending the bpf_map_def struct, I just
expose callbacks that will allow programs to fill in internal-to-libbpf
data structures with the required information. Then, once the BTF-based
map definition does land, that can simply define default callbacks that
uses the BTF information to fill in those same internal data structures?
This would mean no extending bpf_map_def, and relaxing the current
libbpf restriction on extending bpf_map_def.
The drawback of this approach is that it does nothing to combat
fragmentation: People building their own loaders can still reimplement
different semantics for map defs, leading to programs that are tied to a
particular loader. So this would only work if we really believe BTF can
save us from this. I don't feel competent to comment on this just yet,
but thought I'd mention it :)
-Toke
^ permalink raw reply
* Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf
From: Daniel Borkmann @ 2019-08-22 11:45 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Stephen Hemminger,
Alexei Starovoitov
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Jesper Dangaard Brouer, netdev, bpf, andrii.nakryiko
In-Reply-To: <87imqppjir.fsf@toke.dk>
On 8/22/19 12:43 PM, Toke Høiland-Jørgensen wrote:
> Daniel Borkmann <daniel@iogearbox.net> writes:
>> On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:
>>> This adds a configure check for libbpf and renames functions to allow
>>> lib/bpf.c to be compiled with it present. This makes it possible to
>>> port functionality piecemeal to use libbpf.
>>>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>>> ---
>>> configure | 16 ++++++++++++++++
>>> include/bpf_util.h | 6 +++---
>>> ip/ipvrf.c | 4 ++--
>>> lib/bpf.c | 33 +++++++++++++++++++--------------
>>> 4 files changed, 40 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 45fcffb6..5a89ee9f 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -238,6 +238,19 @@ check_elf()
>>> fi
>>> }
>>>
>>> +check_libbpf()
>>> +{
>>> + if ${PKG_CONFIG} libbpf --exists; then
>>> + echo "HAVE_LIBBPF:=y" >>$CONFIG
>>> + echo "yes"
>>> +
>>> + echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
>>> + echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
>>> + else
>>> + echo "no"
>>> + fi
>>> +}
>>> +
>>> check_selinux()
>>
>> More of an implementation detail at this point in time, but want to
>> make sure this doesn't get missed along the way: as discussed at
>> bpfconf [0] best for iproute2 to handle libbpf support would be the
>> same way of integration as pahole does, that is, to integrate it via
>> submodule [1] to allow kernel and libbpf features to be in sync with
>> iproute2 releases and therefore easily consume extensions we're adding
>> to libbpf to aide iproute2 integration.
>
> I can sorta see the point wrt keeping in sync with kernel features. But
> how will this work with distros that package libbpf as a regular
> library? Have you guys given up on regular library symbol versioning for
> libbpf?
Not at all, and I hope you know that. ;-) The reason I added lib/bpf.c
integration into iproute2 directly back then was exactly such that users
can start consuming BPF for tc and XDP via iproute2 /everywhere/ with
only a simple libelf dependency which is also available on all distros
since pretty much forever. If it was an external library, we could have
waited till hell freezes over and initial distro adoption would have pretty
much taken forever: to pick one random example here wrt the pace of some
downstream distros [0]. The main rationale is pretty much the same as with
added kernel features that land complementary iproute2 patches for that
kernel release and as libbpf is developed alongside it is reasonable to
guarantee user expectations that iproute2 released for kernel version x
can make use of BPF features added to kernel x with same loader support
from x.
[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774815
>> [0] http://vger.kernel.org/bpfconf2019.html#session-4
>
> Thanks for that link! Didn't manage to find any of the previous
> discussions on iproute2 compatibility.
>
> -Toke
>
^ permalink raw reply
* [PATCH] rtw88: remove redundant assignment to pointer debugfs_topdir
From: Colin King @ 2019-08-22 11:37 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Pointer debugfs_topdir is initialized to a value that is never read
and it is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtw88/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
index 383b04c16703..5d235968d475 100644
--- a/drivers/net/wireless/realtek/rtw88/debug.c
+++ b/drivers/net/wireless/realtek/rtw88/debug.c
@@ -672,7 +672,7 @@ static struct rtw_debugfs_priv rtw_debug_priv_rsvd_page = {
void rtw_debugfs_init(struct rtw_dev *rtwdev)
{
- struct dentry *debugfs_topdir = rtwdev->debugfs;
+ struct dentry *debugfs_topdir;
debugfs_topdir = debugfs_create_dir("rtw88",
rtwdev->hw->wiphy->debugfsdir);
--
2.20.1
^ permalink raw reply related
* [PATCH 4.14.y stable] xfrm: policy: remove pcpu policy cache
From: Florian Westphal @ 2019-08-22 11:21 UTC (permalink / raw)
To: stable
Cc: vakul.garg, netdev, Florian Westphal, Kristian Evensen,
Steffen Klassert
In-Reply-To: <DB7PR04MB46208495C3ADCCD58B1131C88BA50@DB7PR04MB4620.eurprd04.prod.outlook.com>
commit e4db5b61c572475bbbcf63e3c8a2606bfccf2c9d upstream.
Kristian Evensen says:
In a project I am involved in, we are running ipsec (Strongswan) on
different mt7621-based routers. Each router is configured as an
initiator and has around ~30 tunnels to different responders (running
on misc. devices). Before the flow cache was removed (kernel 4.9), we
got a combined throughput of around 70Mbit/s for all tunnels on one
router. However, we recently switched to kernel 4.14 (4.14.48), and
the total throughput is somewhere around 57Mbit/s (best-case). I.e., a
drop of around 20%. Reverting the flow cache removal restores, as
expected, performance levels to that of kernel 4.9.
When pcpu xdst exists, it has to be validated first before it can be
used.
A negative hit thus increases cost vs. no-cache.
As number of tunnels increases, hit rate decreases so this pcpu caching
isn't a viable strategy.
Furthermore, the xdst cache also needs to run with BH off, so when
removing this the bh disable/enable pairs can be removed too.
Kristian tested a 4.14.y backport of this change and reported
increased performance:
In our tests, the throughput reduction has been reduced from around -20%
to -5%. We also see that the overall throughput is independent of the
number of tunnels, while before the throughput was reduced as the number
of tunnels increased.
Reported-by: Kristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
Vakul Garg reports traffic going via ipsec tunnels will cause the kernel
to spin in an infinite loop due to xfrm policy reference count
overflowing and becoming 0.
The refcount leak is in the pcpu cache. Instead of fixing this, just
remove the pcpu cache -- its not present in any other stable release.
Vakul reported that this patch fixes the problem.
There are no major deviations from the upstream revert; conflicts
were only due to context.
include/net/xfrm.h | 1 -
net/xfrm/xfrm_device.c | 10 ---
net/xfrm/xfrm_policy.c | 138 +----------------------------------------
net/xfrm/xfrm_state.c | 5 +-
4 files changed, 3 insertions(+), 151 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index db99efb2d1d0..bdf185ae93db 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -323,7 +323,6 @@ int xfrm_policy_register_afinfo(const struct xfrm_policy_afinfo *afinfo, int fam
void xfrm_policy_unregister_afinfo(const struct xfrm_policy_afinfo *afinfo);
void km_policy_notify(struct xfrm_policy *xp, int dir,
const struct km_event *c);
-void xfrm_policy_cache_flush(void);
void km_state_notify(struct xfrm_state *x, const struct km_event *c);
struct xfrm_tmpl;
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 30e5746085b8..4e458fd9236a 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -153,12 +153,6 @@ static int xfrm_dev_register(struct net_device *dev)
return NOTIFY_DONE;
}
-static int xfrm_dev_unregister(struct net_device *dev)
-{
- xfrm_policy_cache_flush();
- return NOTIFY_DONE;
-}
-
static int xfrm_dev_feat_change(struct net_device *dev)
{
if ((dev->features & NETIF_F_HW_ESP) && !dev->xfrmdev_ops)
@@ -178,7 +172,6 @@ static int xfrm_dev_down(struct net_device *dev)
if (dev->features & NETIF_F_HW_ESP)
xfrm_dev_state_flush(dev_net(dev), dev, true);
- xfrm_policy_cache_flush();
return NOTIFY_DONE;
}
@@ -190,9 +183,6 @@ static int xfrm_dev_event(struct notifier_block *this, unsigned long event, void
case NETDEV_REGISTER:
return xfrm_dev_register(dev);
- case NETDEV_UNREGISTER:
- return xfrm_dev_unregister(dev);
-
case NETDEV_FEAT_CHANGE:
return xfrm_dev_feat_change(dev);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 70ec57b887f6..b5006a091fd6 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -45,8 +45,6 @@ struct xfrm_flo {
u8 flags;
};
-static DEFINE_PER_CPU(struct xfrm_dst *, xfrm_last_dst);
-static struct work_struct *xfrm_pcpu_work __read_mostly;
static DEFINE_SPINLOCK(xfrm_policy_afinfo_lock);
static struct xfrm_policy_afinfo const __rcu *xfrm_policy_afinfo[AF_INET6 + 1]
__read_mostly;
@@ -1715,108 +1713,6 @@ static int xfrm_expand_policies(const struct flowi *fl, u16 family,
}
-static void xfrm_last_dst_update(struct xfrm_dst *xdst, struct xfrm_dst *old)
-{
- this_cpu_write(xfrm_last_dst, xdst);
- if (old)
- dst_release(&old->u.dst);
-}
-
-static void __xfrm_pcpu_work_fn(void)
-{
- struct xfrm_dst *old;
-
- old = this_cpu_read(xfrm_last_dst);
- if (old && !xfrm_bundle_ok(old))
- xfrm_last_dst_update(NULL, old);
-}
-
-static void xfrm_pcpu_work_fn(struct work_struct *work)
-{
- local_bh_disable();
- rcu_read_lock();
- __xfrm_pcpu_work_fn();
- rcu_read_unlock();
- local_bh_enable();
-}
-
-void xfrm_policy_cache_flush(void)
-{
- struct xfrm_dst *old;
- bool found = 0;
- int cpu;
-
- might_sleep();
-
- local_bh_disable();
- rcu_read_lock();
- for_each_possible_cpu(cpu) {
- old = per_cpu(xfrm_last_dst, cpu);
- if (old && !xfrm_bundle_ok(old)) {
- if (smp_processor_id() == cpu) {
- __xfrm_pcpu_work_fn();
- continue;
- }
- found = true;
- break;
- }
- }
-
- rcu_read_unlock();
- local_bh_enable();
-
- if (!found)
- return;
-
- get_online_cpus();
-
- for_each_possible_cpu(cpu) {
- bool bundle_release;
-
- rcu_read_lock();
- old = per_cpu(xfrm_last_dst, cpu);
- bundle_release = old && !xfrm_bundle_ok(old);
- rcu_read_unlock();
-
- if (!bundle_release)
- continue;
-
- if (cpu_online(cpu)) {
- schedule_work_on(cpu, &xfrm_pcpu_work[cpu]);
- continue;
- }
-
- rcu_read_lock();
- old = per_cpu(xfrm_last_dst, cpu);
- if (old && !xfrm_bundle_ok(old)) {
- per_cpu(xfrm_last_dst, cpu) = NULL;
- dst_release(&old->u.dst);
- }
- rcu_read_unlock();
- }
-
- put_online_cpus();
-}
-
-static bool xfrm_xdst_can_reuse(struct xfrm_dst *xdst,
- struct xfrm_state * const xfrm[],
- int num)
-{
- const struct dst_entry *dst = &xdst->u.dst;
- int i;
-
- if (xdst->num_xfrms != num)
- return false;
-
- for (i = 0; i < num; i++) {
- if (!dst || dst->xfrm != xfrm[i])
- return false;
- dst = dst->child;
- }
-
- return xfrm_bundle_ok(xdst);
-}
-
static struct xfrm_dst *
xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
const struct flowi *fl, u16 family,
@@ -1824,7 +1720,7 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
{
struct net *net = xp_net(pols[0]);
struct xfrm_state *xfrm[XFRM_MAX_DEPTH];
- struct xfrm_dst *xdst, *old;
+ struct xfrm_dst *xdst;
struct dst_entry *dst;
int err;
@@ -1839,21 +1735,6 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
return ERR_PTR(err);
}
- xdst = this_cpu_read(xfrm_last_dst);
- if (xdst &&
- xdst->u.dst.dev == dst_orig->dev &&
- xdst->num_pols == num_pols &&
- memcmp(xdst->pols, pols,
- sizeof(struct xfrm_policy *) * num_pols) == 0 &&
- xfrm_xdst_can_reuse(xdst, xfrm, err)) {
- dst_hold(&xdst->u.dst);
- while (err > 0)
- xfrm_state_put(xfrm[--err]);
- return xdst;
- }
-
- old = xdst;
-
dst = xfrm_bundle_create(pols[0], xfrm, err, fl, dst_orig);
if (IS_ERR(dst)) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTBUNDLEGENERROR);
@@ -1866,9 +1747,6 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
memcpy(xdst->pols, pols, sizeof(struct xfrm_policy *) * num_pols);
xdst->policy_genid = atomic_read(&pols[0]->genid);
- atomic_set(&xdst->u.dst.__refcnt, 2);
- xfrm_last_dst_update(xdst, old);
-
return xdst;
}
@@ -2069,11 +1947,8 @@ xfrm_bundle_lookup(struct net *net, const struct flowi *fl, u16 family, u8 dir,
if (num_xfrms <= 0)
goto make_dummy_bundle;
- local_bh_disable();
xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family,
xflo->dst_orig);
- local_bh_enable();
-
if (IS_ERR(xdst)) {
err = PTR_ERR(xdst);
if (err != -EAGAIN)
@@ -2160,11 +2035,9 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
goto no_transform;
}
- local_bh_disable();
xdst = xfrm_resolve_and_create_bundle(
pols, num_pols, fl,
family, dst_orig);
- local_bh_enable();
if (IS_ERR(xdst)) {
xfrm_pols_put(pols, num_pols);
@@ -2992,15 +2865,6 @@ static struct pernet_operations __net_initdata xfrm_net_ops = {
void __init xfrm_init(void)
{
- int i;
-
- xfrm_pcpu_work = kmalloc_array(NR_CPUS, sizeof(*xfrm_pcpu_work),
- GFP_KERNEL);
- BUG_ON(!xfrm_pcpu_work);
-
- for (i = 0; i < NR_CPUS; i++)
- INIT_WORK(&xfrm_pcpu_work[i], xfrm_pcpu_work_fn);
-
register_pernet_subsys(&xfrm_net_ops);
seqcount_init(&xfrm_policy_hash_generation);
xfrm_input_init();
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 0cd2bdf3b217..7c093de68780 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -735,10 +735,9 @@ int xfrm_state_flush(struct net *net, u8 proto, bool task_valid)
}
out:
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
- if (cnt) {
+ if (cnt)
err = 0;
- xfrm_policy_cache_flush();
- }
+
return err;
}
EXPORT_SYMBOL(xfrm_state_flush);
--
2.21.0
^ permalink raw reply related
* [iproute2, master 1/2] devlink: Print health reporter's dump time-stamp in a helper function
From: Aya Levin @ 2019-08-22 11:05 UTC (permalink / raw)
To: netdev, Stephen Hemminger, Jiri Pirko; +Cc: Moshe Shemesh, Aya Levin
In-Reply-To: <1566471942-28529-1-git-send-email-ayal@mellanox.com>
Add pr_out_dump_reporter prefix to the helper function's name and
encapsulate the print in it.
Fixes: 2f1242efe9d0 ("devlink: Add devlink health show command")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
devlink/devlink.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 055eca5d4662..f1d9de8e151d 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -6169,8 +6169,11 @@ static const char *health_state_name(uint8_t state)
}
}
-static void format_logtime(uint64_t time_ms, char *ts_date, char *ts_time)
+static void pr_out_dump_reporter_format_logtime(struct dl *dl, const struct nlattr *attr)
{
+ char dump_date[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
+ char dump_time[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
+ uint64_t time_ms = mnl_attr_get_u64(attr);
struct sysinfo s_info;
struct tm *info;
time_t now, sec;
@@ -6188,16 +6191,16 @@ static void format_logtime(uint64_t time_ms, char *ts_date, char *ts_time)
sec = now - s_info.uptime + time_ms / 1000;
info = localtime(&sec);
out:
- strftime(ts_date, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%Y-%m-%d", info);
- strftime(ts_time, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%H:%M:%S", info);
+ strftime(dump_date, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%Y-%m-%d", info);
+ strftime(dump_time, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%H:%M:%S", info);
+ pr_out_str(dl, "last_dump_date", dump_date);
+ pr_out_str(dl, "last_dump_time", dump_time);
}
static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
{
struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
enum devlink_health_reporter_state state;
- const struct nlattr *attr;
- uint64_t time_ms;
int err;
err = mnl_attr_parse_nested(tb_health[DEVLINK_ATTR_HEALTH_REPORTER],
@@ -6225,17 +6228,8 @@ static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT]));
pr_out_u64(dl, "recover",
mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT]));
- if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS]) {
- char dump_date[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
- char dump_time[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
-
- attr = tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS];
- time_ms = mnl_attr_get_u64(attr);
- format_logtime(time_ms, dump_date, dump_time);
-
- pr_out_str(dl, "last_dump_date", dump_date);
- pr_out_str(dl, "last_dump_time", dump_time);
- }
+ if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS])
+ pr_out_dump_reporter_format_logtime(dl, tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS]);
if (tb[DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD])
pr_out_u64(dl, "grace_period",
mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD]));
--
2.14.1
^ permalink raw reply related
* [iproute2, master 0/2] Fix reporter's dump's time-stamp
From: Aya Levin @ 2019-08-22 11:05 UTC (permalink / raw)
To: netdev, Stephen Hemminger, Jiri Pirko; +Cc: Moshe Shemesh, Aya Levin
In-Reply-To: <1566461871-21992-1-git-send-email-ayal@mellanox.com>
This patch set handles the reporter's dump time-stamp display. First
patch refactors the current implementation of helper function which
displays the reporter's dump time-stamp and add the actual print to
the function's body.
The second patch introduces a new attribute which is the time-stamp in
timespec (current time) instead of jiffies. When the new attribute is
present try and translate the time-stamp according to 'current time'.
Aya Levin (2):
devlink: Print health reporter's dump time-stamp in a helper function
devlink: Add a new time-stamp format for health reporter's dump
devlink/devlink.c | 44 ++++++++++++++++++++++++++++----------------
include/uapi/linux/devlink.h | 2 ++
2 files changed, 30 insertions(+), 16 deletions(-)
--
2.14.1
^ permalink raw reply
* [iproute2, master 2/2] devlink: Add a new time-stamp format for health reporter's dump
From: Aya Levin @ 2019-08-22 11:05 UTC (permalink / raw)
To: netdev, Stephen Hemminger, Jiri Pirko; +Cc: Moshe Shemesh, Aya Levin
In-Reply-To: <1566471942-28529-1-git-send-email-ayal@mellanox.com>
Introduce a new attribute representing a new time-stamp format: current
time instead of jiffies. If the new attribute was received, translate
the time-stamp accordingly.
Fixes: 2f1242efe9d0 ("devlink: Add devlink health show command")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
devlink/devlink.c | 20 +++++++++++++++++++-
include/uapi/linux/devlink.h | 2 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index f1d9de8e151d..623d1b52c4ca 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -6197,6 +6197,22 @@ out:
pr_out_str(dl, "last_dump_time", dump_time);
}
+static void pr_out_dump_report_timestamp(struct dl *dl, const struct nlattr *attr)
+{
+ char dump_date[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
+ char dump_time[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
+ struct timespec *ts = mnl_attr_get_payload(attr);
+ struct tm *tm;
+
+ tm = localtime(&ts->tv_sec);
+
+ strftime(dump_date, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%Y-%m-%d", tm);
+ strftime(dump_time, HEALTH_REPORTER_TIMESTAMP_FMT_LEN, "%H:%M:%S", tm);
+
+ pr_out_str(dl, "last_dump_date", dump_date);
+ pr_out_str(dl, "last_dump_time", dump_time);
+}
+
static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
{
struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
@@ -6228,7 +6244,9 @@ static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT]));
pr_out_u64(dl, "recover",
mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT]));
- if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS])
+ if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TSPEC])
+ pr_out_dump_report_timestamp(dl, tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TSPEC]);
+ else if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS])
pr_out_dump_reporter_format_logtime(dl, tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS]);
if (tb[DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD])
pr_out_u64(dl, "grace_period",
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index fc195cbd66f4..3f8532711315 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -348,6 +348,8 @@ enum devlink_attr {
DEVLINK_ATTR_PORT_PCI_PF_NUMBER, /* u16 */
DEVLINK_ATTR_PORT_PCI_VF_NUMBER, /* u16 */
+ DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TSPEC,
+
/* add new attributes above here, update the policy in devlink.c */
__DEVLINK_ATTR_MAX,
--
2.14.1
^ permalink raw reply related
* Re: [PATCH bpf-next v5] libbpf: add xsk_ring_prod__nb_free() function
From: Magnus Karlsson @ 2019-08-22 10:52 UTC (permalink / raw)
To: Eelco Chaudron
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <86245c2d7b596f55d5ff1abeee3c3826b1b4370e.1566467579.git.echaudro@redhat.com>
On Thu, Aug 22, 2019 at 11:54 AM Eelco Chaudron <echaudro@redhat.com> wrote:
>
> When an AF_XDP application received X packets, it does not mean X
> frames can be stuffed into the producer ring. To make it easier for
> AF_XDP applications this API allows them to check how many frames can
> be added into the ring.
>
> The patch below looks like a name change only, but the xsk_prod__
> prefix denotes that this API is exposed to be used by applications.
>
> Besides, if you set the nb value to the size of the ring, you will
> get the exact amount of slots available, at the cost of performance
> (you touch shared state for sure). nb is there to limit the
> touching of the shared state.
>
> Also the example xdpsock application has been modified to use this
> new API, so it's also able to process flows at a 1pps rate on veth
> interfaces.
Still just 1 single packet per second with veth and this optimization ;-)?
Thanks Eelco for working on this.
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>
> ---
> v4 -> v5
> - Rebase on latest bpf-next
>
> v3 -> v4
> - Cleanedup commit message
> - Updated AF_XDP sample application to use this new API
>
> v2 -> v3
> - Removed cache by pass option
>
> v1 -> v2
> - Renamed xsk_ring_prod__free() to xsk_ring_prod__nb_free()
> - Add caching so it will only touch global state when needed
>
> samples/bpf/xdpsock_user.c | 119 ++++++++++++++++++++++++++++---------
> tools/lib/bpf/xsk.h | 4 +-
> 2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
> index da84c760c094..bec0ee463184 100644
> --- a/samples/bpf/xdpsock_user.c
> +++ b/samples/bpf/xdpsock_user.c
> @@ -470,9 +470,13 @@ static void kick_tx(struct xsk_socket_info *xsk)
> static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk,
> struct pollfd *fds)
> {
> - u32 idx_cq = 0, idx_fq = 0;
> - unsigned int rcvd;
> + static u64 free_frames[NUM_FRAMES];
> + static size_t nr_free_frames;
> +
> + u32 idx_cq = 0, idx_fq = 0, free_slots;
> + unsigned int rcvd, i;
> size_t ndescs;
> + int ret;
>
> if (!xsk->outstanding_tx)
> return;
> @@ -485,29 +489,56 @@ static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk,
>
> /* re-add completed Tx buffers */
> rcvd = xsk_ring_cons__peek(&xsk->umem->cq, ndescs, &idx_cq);
> - if (rcvd > 0) {
> - unsigned int i;
> - int ret;
> -
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> - while (ret != rcvd) {
> - if (ret < 0)
> - exit_with_error(-ret);
> - if (xsk_ring_prod__needs_wakeup(&xsk->umem->fq))
> - ret = poll(fds, num_socks, opt_timeout);
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
> - &idx_fq);
> - }
> - for (i = 0; i < rcvd; i++)
> + if (!rcvd)
> + return;
> +
> + /* When xsk_ring_cons__peek() for example returns that 5 packets
> + * have been received, it does not automatically mean that
> + * xsk_ring_prod__reserve() will have 5 slots available. You will
> + * see this, for example, when using a veth interface due to the
> + * RX_BATCH_SIZE used by the generic driver.
> + *
> + * In this example we store unused buffers and try to re-stock
> + * them the next iteration.
> + */
> +
> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd + nr_free_frames);
> + if (free_slots > rcvd + nr_free_frames)
> + free_slots = rcvd + nr_free_frames;
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots, &idx_fq);
> + while (ret != free_slots) {
> + if (ret < 0)
> + exit_with_error(-ret);
> +
> + if (xsk_ring_prod__needs_wakeup(&xsk->umem->fq))
> + ret = poll(fds, num_socks, opt_timeout);
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> + &idx_fq);
> + }
> + for (i = 0; i < rcvd; i++) {
> + u64 addr = *xsk_ring_cons__comp_addr(&xsk->umem->cq, idx_cq++);
> +
> + if (i < free_slots)
> *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> - *xsk_ring_cons__comp_addr(&xsk->umem->cq,
> - idx_cq++);
> + addr;
> + else
> + free_frames[nr_free_frames++] = addr;
> + }
>
> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> - xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> - xsk->outstanding_tx -= rcvd;
> - xsk->tx_npkts += rcvd;
> + if (free_slots > rcvd) {
> + for (i = 0; i < (free_slots - rcvd); i++) {
> + u64 addr = free_frames[--nr_free_frames];
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + }
> }
> +
> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> + xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> + xsk->outstanding_tx -= rcvd;
> + xsk->tx_npkts += rcvd;
> }
>
> static inline void complete_tx_only(struct xsk_socket_info *xsk)
> @@ -531,8 +562,11 @@ static inline void complete_tx_only(struct xsk_socket_info *xsk)
>
> static void rx_drop(struct xsk_socket_info *xsk, struct pollfd *fds)
> {
> + static u64 free_frames[NUM_FRAMES];
> + static size_t nr_free_frames;
> +
> unsigned int rcvd, i;
> - u32 idx_rx = 0, idx_fq = 0;
> + u32 idx_rx = 0, idx_fq = 0, free_slots;
> int ret;
>
> rcvd = xsk_ring_cons__peek(&xsk->rx, BATCH_SIZE, &idx_rx);
> @@ -542,13 +576,30 @@ static void rx_drop(struct xsk_socket_info *xsk, struct pollfd *fds)
> return;
> }
>
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> - while (ret != rcvd) {
> + /* When xsk_ring_cons__peek() for example returns that 5 packets
> + * have been received, it does not automatically mean that
> + * xsk_ring_prod__reserve() will have 5 slots available. You will
> + * see this, for example, when using a veth interface due to the
> + * RX_BATCH_SIZE used by the generic driver.
> + *
> + * In this example we store unused buffers and try to re-stock
> + * them the next iteration.
> + */
> +
> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd + nr_free_frames);
> + if (free_slots > rcvd + nr_free_frames)
> + free_slots = rcvd + nr_free_frames;
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots, &idx_fq);
> + while (ret != free_slots) {
> if (ret < 0)
> exit_with_error(-ret);
> +
> if (xsk_ring_prod__needs_wakeup(&xsk->umem->fq))
> ret = poll(fds, num_socks, opt_timeout);
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> + &idx_fq);
> }
>
> for (i = 0; i < rcvd; i++) {
> @@ -557,10 +608,22 @@ static void rx_drop(struct xsk_socket_info *xsk, struct pollfd *fds)
> char *pkt = xsk_umem__get_data(xsk->umem->buffer, addr);
>
> hex_dump(pkt, len, addr);
> - *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = addr;
> + if (i < free_slots)
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + else
> + free_frames[nr_free_frames++] = addr;
> + }
> +
> + if (free_slots > rcvd) {
> + for (i = 0; i < (free_slots - rcvd); i++) {
> + u64 addr = free_frames[--nr_free_frames];
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + }
> }
>
> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> xsk_ring_cons__release(&xsk->rx, rcvd);
> xsk->rx_npkts += rcvd;
> }
> diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
> index aa1d6122b7db..520a772c882c 100644
> --- a/tools/lib/bpf/xsk.h
> +++ b/tools/lib/bpf/xsk.h
> @@ -82,7 +82,7 @@ static inline int xsk_ring_prod__needs_wakeup(const struct xsk_ring_prod *r)
> return *r->flags & XDP_RING_NEED_WAKEUP;
> }
>
> -static inline __u32 xsk_prod_nb_free(struct xsk_ring_prod *r, __u32 nb)
> +static inline __u32 xsk_prod__nb_free(struct xsk_ring_prod *r, __u32 nb)
> {
> __u32 free_entries = r->cached_cons - r->cached_prod;
>
> @@ -116,7 +116,7 @@ static inline __u32 xsk_cons_nb_avail(struct xsk_ring_cons *r, __u32 nb)
> static inline size_t xsk_ring_prod__reserve(struct xsk_ring_prod *prod,
> size_t nb, __u32 *idx)
> {
> - if (xsk_prod_nb_free(prod, nb) < nb)
> + if (xsk_prod__nb_free(prod, nb) < nb)
> return 0;
>
> *idx = prod->cached_prod;
> --
> 2.18.1
>
^ permalink raw reply
* [PATCH 3/3] netlink: use generic skb_set_owner_r()
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Johannes Berg, David Ahern, Christian Brauner,
Jakub Kicinski, Jason A. Donenfeld, Stephen Hemminger,
Willem de Bruijn, Cong Wang, Eric Dumazet, John Hurley,
Paolo Abeni, Jesper Dangaard Brouer, Sebastian Andrzej Siewior,
Li RongQing, Tetsuo Handa, Patrick Talbert, Taehee Yoo,
Herbert Xu, Thomas Gleixner, Dmitry Safonov,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
In-Reply-To: <1566470851-4694-1-git-send-email-jan.dakinevich@virtuozzo.com>
Since skb destructor is not used for data deallocating,
netlink_skb_set_owner_r() almost completely repeates generic
skb_set_owner_r(). Thus, both netlink_skb_set_owner_r() and
netlink_skb_destructor() are not required anymore.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
net/netlink/af_netlink.c | 23 ++++-------------------
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 04a3457..b0c2eb2 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -358,21 +358,6 @@ static void netlink_rcv_wake(struct sock *sk)
wake_up_interruptible(&nlk->wait);
}
-static void netlink_skb_destructor(struct sk_buff *skb)
-{
- if (skb->sk != NULL)
- sock_rfree(skb);
-}
-
-static void netlink_skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
-{
- WARN_ON(skb->sk != NULL);
- skb->sk = sk;
- skb->destructor = netlink_skb_destructor;
- atomic_add(skb->truesize, &sk->sk_rmem_alloc);
- sk_mem_charge(sk, skb->truesize);
-}
-
static void netlink_sock_destruct(struct sock *sk)
{
struct netlink_sock *nlk = nlk_sk(sk);
@@ -1225,7 +1210,7 @@ int netlink_attachskb(struct sock *sk, struct sk_buff *skb,
}
return 1;
}
- netlink_skb_set_owner_r(skb, sk);
+ skb_set_owner_r(skb, sk);
return 0;
}
@@ -1286,7 +1271,7 @@ static int netlink_unicast_kernel(struct sock *sk, struct sk_buff *skb,
ret = -ECONNREFUSED;
if (nlk->netlink_rcv != NULL) {
ret = skb->len;
- netlink_skb_set_owner_r(skb, sk);
+ skb_set_owner_r(skb, sk);
NETLINK_CB(skb).sk = ssk;
netlink_deliver_tap_kernel(sk, ssk, skb);
nlk->netlink_rcv(skb);
@@ -1367,7 +1352,7 @@ static int netlink_broadcast_deliver(struct sock *sk, struct sk_buff *skb)
if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
!test_bit(NETLINK_S_CONGESTED, &nlk->state)) {
- netlink_skb_set_owner_r(skb, sk);
+ skb_set_owner_r(skb, sk);
__netlink_sendskb(sk, skb);
return atomic_read(&sk->sk_rmem_alloc) > (sk->sk_rcvbuf >> 1);
}
@@ -2227,7 +2212,7 @@ static int netlink_dump(struct sock *sk)
* single netdev. The outcome is MSG_TRUNC error.
*/
skb_reserve(skb, skb_tailroom(skb) - alloc_size);
- netlink_skb_set_owner_r(skb, sk);
+ skb_set_owner_r(skb, sk);
if (nlk->dump_done_errno > 0) {
cb->extack = &extack;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] netlink: always use vmapped memory for skb data
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, David Ahern, Johannes Berg, Christian Brauner,
Jakub Kicinski, Jason A. Donenfeld, Stephen Hemminger,
Willem de Bruijn, Cong Wang, John Hurley, Paolo Abeni,
Jesper Dangaard Brouer, Sebastian Andrzej Siewior, Eric Dumazet,
Li RongQing, Thomas Gleixner, Patrick Talbert, Taehee Yoo,
Herbert Xu, Dmitry Safonov, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org
In-Reply-To: <1566470851-4694-1-git-send-email-jan.dakinevich@virtuozzo.com>
Don't make an exception for broadcast skb and allocate buffer for it in
the same way as for unicast skb.
- this makes needless calling of special destructor to free memory
under ->head,
- ...then, there is no need to reassign this destructor to cloned skb,
- ...then, netlink_skb_clone() become equal to generic skb_clone()
and can be dropped.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
include/linux/netlink.h | 16 ----------------
net/ipv4/fib_frontend.c | 2 +-
net/netfilter/nfnetlink.c | 2 +-
net/netlink/af_netlink.c | 16 +++-------------
4 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 205fa7b..daacffc 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -146,22 +146,6 @@ int netlink_attachskb(struct sock *sk, struct sk_buff *skb,
void netlink_detachskb(struct sock *sk, struct sk_buff *skb);
int netlink_sendskb(struct sock *sk, struct sk_buff *skb);
-static inline struct sk_buff *
-netlink_skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
-{
- struct sk_buff *nskb;
-
- nskb = skb_clone(skb, gfp_mask);
- if (!nskb)
- return NULL;
-
- /* This is a large skb, set destructor callback to release head */
- if (is_vmalloc_addr(skb->head))
- nskb->destructor = skb->destructor;
-
- return nskb;
-}
-
/*
* skb should fit one page. This choice is good for headerless malloc.
* But we should limit to 8K so that userspace does not have to
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index e8bc939..cbbd75d 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1371,7 +1371,7 @@ static void nl_fib_input(struct sk_buff *skb)
nlmsg_len(nlh) < sizeof(*frn))
return;
- skb = netlink_skb_clone(skb, GFP_KERNEL);
+ skb = skb_clone(skb, GFP_KERNEL);
if (!skb)
return;
nlh = nlmsg_hdr(skb);
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 4abbb45..6ae22c9c 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -311,7 +311,7 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
replay:
status = 0;
- skb = netlink_skb_clone(oskb, GFP_KERNEL);
+ skb = skb_clone(oskb, GFP_KERNEL);
if (!skb)
return netlink_ack(oskb, nlh, -ENOMEM, NULL);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 90b2ab9..04a3457 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -360,13 +360,6 @@ static void netlink_rcv_wake(struct sock *sk)
static void netlink_skb_destructor(struct sk_buff *skb)
{
- if (is_vmalloc_addr(skb->head)) {
- if (!skb->cloned ||
- !atomic_dec_return(&(skb_shinfo(skb)->dataref)))
- vfree(skb->head);
-
- skb->head = NULL;
- }
if (skb->sk != NULL)
sock_rfree(skb);
}
@@ -1164,13 +1157,12 @@ struct sock *netlink_getsockbyfilp(struct file *filp)
return sock;
}
-static struct sk_buff *netlink_alloc_large_skb(unsigned int size,
- int broadcast)
+static struct sk_buff *netlink_alloc_large_skb(unsigned int size)
{
struct sk_buff *skb;
void *data;
- if (size <= NLMSG_GOODSIZE || broadcast)
+ if (size <= NLMSG_GOODSIZE)
return alloc_skb(size, GFP_KERNEL);
size = SKB_DATA_ALIGN(size) +
@@ -1183,8 +1175,6 @@ static struct sk_buff *netlink_alloc_large_skb(unsigned int size,
skb = __build_skb(data, size);
if (skb == NULL)
vfree(data);
- else
- skb->destructor = netlink_skb_destructor;
return skb;
}
@@ -1889,7 +1879,7 @@ static int netlink_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
if (len > sk->sk_sndbuf - 32)
goto out;
err = -ENOBUFS;
- skb = netlink_alloc_large_skb(len, dst_group);
+ skb = netlink_alloc_large_skb(len);
if (skb == NULL)
goto out;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/3] skbuff: use kvfree() to deallocate head
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Johannes Berg, David Ahern, Christian Brauner,
Jason A. Donenfeld, Jakub Kicinski, Stephen Hemminger,
Willem de Bruijn, Cong Wang, Simon Horman, John Hurley,
Paolo Abeni, Jesper Dangaard Brouer, Sebastian Andrzej Siewior,
Eric Dumazet, Li RongQing, Thomas Gleixner, Taehee Yoo,
Herbert Xu, Dmitry Safonov, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org
In-Reply-To: <1566470851-4694-1-git-send-email-jan.dakinevich@virtuozzo.com>
If skb buffer was allocated using vmalloc() it will make simple its
further deallocation.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0338820..55eac01 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -588,7 +588,7 @@ static void skb_free_head(struct sk_buff *skb)
if (skb->head_frag)
skb_free_frag(head);
else
- kfree(head);
+ kvfree(head);
}
static void skb_release_data(struct sk_buff *skb)
--
2.1.4
^ permalink raw reply related
* [PATCH 0/3] rework netlink skb allocation
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Johannes Berg, David Ahern, Christian Brauner,
Stephen Hemminger, Jason A. Donenfeld, Jakub Kicinski,
Willem de Bruijn, Cong Wang, Simon Horman, John Hurley,
Paolo Abeni, Jesper Dangaard Brouer, Sebastian Andrzej Siewior,
Eric Dumazet, Li RongQing, Taehee Yoo, Patrick Talbert,
Herbert Xu, Thomas Gleixner, Dmitry Safonov,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
Currently, userspace is able to initiate costly high-order allocation in
kernel sending large broadcast netlink message, which is considered
undesirable. At the same time, unicast message are safe in this regard,
because they uses vmalloc-ed memory.
This series introduces changes, that allow broadcast messages to be
allocated with vmalloc() as well as unicast.
Jan Dakinevich (3):
skbuff: use kvfree() to deallocate head
netlink: always use vmapped memory for skb data
netlink: use generic skb_set_owner_r()
include/linux/netlink.h | 16 ----------------
net/core/skbuff.c | 2 +-
net/ipv4/fib_frontend.c | 2 +-
net/netfilter/nfnetlink.c | 2 +-
net/netlink/af_netlink.c | 39 +++++++--------------------------------
5 files changed, 10 insertions(+), 51 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf
From: Toke Høiland-Jørgensen @ 2019-08-22 10:43 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Hemminger, Alexei Starovoitov
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Jesper Dangaard Brouer, netdev, bpf, andrii.nakryiko
In-Reply-To: <9de36bbf-b70d-9320-c686-3033d0408276@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:
>> This adds a configure check for libbpf and renames functions to allow
>> lib/bpf.c to be compiled with it present. This makes it possible to
>> port functionality piecemeal to use libbpf.
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> ---
>> configure | 16 ++++++++++++++++
>> include/bpf_util.h | 6 +++---
>> ip/ipvrf.c | 4 ++--
>> lib/bpf.c | 33 +++++++++++++++++++--------------
>> 4 files changed, 40 insertions(+), 19 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 45fcffb6..5a89ee9f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -238,6 +238,19 @@ check_elf()
>> fi
>> }
>>
>> +check_libbpf()
>> +{
>> + if ${PKG_CONFIG} libbpf --exists; then
>> + echo "HAVE_LIBBPF:=y" >>$CONFIG
>> + echo "yes"
>> +
>> + echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
>> + echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
>> + else
>> + echo "no"
>> + fi
>> +}
>> +
>> check_selinux()
>
> More of an implementation detail at this point in time, but want to
> make sure this doesn't get missed along the way: as discussed at
> bpfconf [0] best for iproute2 to handle libbpf support would be the
> same way of integration as pahole does, that is, to integrate it via
> submodule [1] to allow kernel and libbpf features to be in sync with
> iproute2 releases and therefore easily consume extensions we're adding
> to libbpf to aide iproute2 integration.
I can sorta see the point wrt keeping in sync with kernel features. But
how will this work with distros that package libbpf as a regular
library? Have you guys given up on regular library symbol versioning for
libbpf?
> [0] http://vger.kernel.org/bpfconf2019.html#session-4
Thanks for that link! Didn't manage to find any of the previous
discussions on iproute2 compatibility.
-Toke
^ permalink raw reply
* [PATCH] af_unix: utilize skb's fragment list for sending large datagrams
From: Jan Dakinevich @ 2019-08-22 10:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, Jan Dakinevich, David S. Miller,
Paolo Abeni, Al Viro, Jens Axboe, Hannes Reinecke, Karsten Graul,
Kyeongdon Kim, Thomas Gleixner, netdev@vger.kernel.org
When somebody tries to send big datagram, kernel makes an attempt to
avoid high-order allocation placing it into both: skb's data buffer
and skb's paged part (->frag).
However, paged part can not exceed MAX_SKB_FRAGS * PAGE_SIZE, and large
datagram causes increasing skb's data buffer. Thus, if any user-space
program sets send buffer (by calling setsockopt(SO_SNDBUF, ...)) to
maximum allowed size (wmem_max) it becomes able to cause any amount
of uncontrolled high-order kernel allocations.
To avoid this, do not pass more then SKB_MAX_ALLOC for skb's data
buffer and make use of fragment list of skb (->frag_list) in addition
to paged part for huge datagrams.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
net/unix/af_unix.c | 38 +++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 67e87db..0c13937 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1580,7 +1580,9 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
struct sk_buff *skb;
long timeo;
struct scm_cookie scm;
- int data_len = 0;
+ unsigned long frag_len;
+ unsigned long paged_len;
+ unsigned long header_len;
int sk_locked;
wait_for_unix_gc();
@@ -1613,27 +1615,41 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
if (len > sk->sk_sndbuf - 32)
goto out;
- if (len > SKB_MAX_ALLOC) {
- data_len = min_t(size_t,
- len - SKB_MAX_ALLOC,
- MAX_SKB_FRAGS * PAGE_SIZE);
- data_len = PAGE_ALIGN(data_len);
+ BUILD_BUG_ON(SKB_MAX_ALLOC < PAGE_SIZE);
- BUILD_BUG_ON(SKB_MAX_ALLOC < PAGE_SIZE);
- }
+ header_len = min(len, SKB_MAX_ALLOC);
+ paged_len = min(len - header_len, MAX_SKB_FRAGS * PAGE_SIZE);
+ frag_len = len - header_len - paged_len;
- skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
+ skb = sock_alloc_send_pskb(sk, header_len, paged_len,
msg->msg_flags & MSG_DONTWAIT, &err,
PAGE_ALLOC_COSTLY_ORDER);
if (skb == NULL)
goto out;
+ while (frag_len) {
+ unsigned long size = min(SKB_MAX_ALLOC, frag_len);
+ struct sk_buff *frag;
+
+ frag = sock_alloc_send_pskb(sk, size, 0,
+ msg->msg_flags & MSG_DONTWAIT,
+ &err, 0);
+ if (!frag)
+ goto out_free;
+
+ skb_put(frag, size);
+ frag->next = skb_shinfo(skb)->frag_list;
+ skb_shinfo(skb)->frag_list = frag;
+
+ frag_len -= size;
+ }
+
err = unix_scm_to_skb(&scm, skb, true);
if (err < 0)
goto out_free;
- skb_put(skb, len - data_len);
- skb->data_len = data_len;
+ skb_put(skb, header_len);
+ skb->data_len = len - header_len;
skb->len = len;
err = skb_copy_datagram_from_iter(skb, 0, &msg->msg_iter, len);
if (err)
--
2.1.4
^ permalink raw reply related
* Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Toke Høiland-Jørgensen @ 2019-08-22 10:38 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Stephen Hemminger, Daniel Borkmann,
Alexei Starovoitov, Martin KaFai Lau, Song Liu, Yonghong Song,
David Miller, Jesper Dangaard Brouer, Networking, bpf
In-Reply-To: <CAEf4BzbR3gdn=82gCmSQ+=81222J0zza9z6JyYs=TkUY=WDXQw@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Wed, Aug 21, 2019 at 4:29 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Tue, Aug 20, 2019 at 01:47:01PM +0200, Toke Høiland-Jørgensen wrote:
>> >> iproute2 uses its own bpf loader to load eBPF programs, which has
>> >> evolved separately from libbpf. Since we are now standardising on
>> >> libbpf, this becomes a problem as iproute2 is slowly accumulating
>> >> feature incompatibilities with libbpf-based loaders. In particular,
>> >> iproute2 has its own (expanded) version of the map definition struct,
>> >> which makes it difficult to write programs that can be loaded with both
>> >> custom loaders and iproute2.
>> >>
>> >> This series seeks to address this by converting iproute2 to using libbpf
>> >> for all its bpf needs. This version is an early proof-of-concept RFC, to
>> >> get some feedback on whether people think this is the right direction.
>> >>
>> >> What this series does is the following:
>> >>
>> >> - Updates the libbpf map definition struct to match that of iproute2
>> >> (patch 1).
>> >> - Adds functionality to libbpf to support automatic pinning of maps when
>> >> loading an eBPF program, while re-using pinned maps if they already
>> >> exist (patches 2-3).
>> >> - Modifies iproute2 to make it possible to compile it against libbpf
>> >> without affecting any existing functionality (patch 4).
>> >> - Changes the iproute2 eBPF loader to use libbpf for loading XDP
>> >> programs (patch 5).
>> >>
>> >>
>> >> As this is an early PoC, there are still a few missing pieces before
>> >> this can be merged. Including (but probably not limited to):
>> >>
>> >> - Consolidate the map definition struct in the bpf_helpers.h file in the
>> >> kernel tree. This contains a different, and incompatible, update to
>> >> the struct. Since the iproute2 version has actually been released for
>> >> use outside the kernel tree (and thus is subject to API stability
>> >> constraints), I think it makes the most sense to keep that, and port
>> >> the selftests to use it.
>> >
>> > It sounds like you're implying that existing libbpf format is not
>> > uapi.
>>
>> No, that's not what I meant... See below.
>>
>> > It is and we cannot break it.
>> > If patch 1 means breakage for existing pre-compiled .o that won't load
>> > with new libbpf then we cannot use this method.
>> > Recompiling .o with new libbpf definition of bpf_map_def isn't an option.
>> > libbpf has to be smart before/after and recognize both old and iproute2 format.
>>
>> The libbpf.h definition of struct bpf_map_def is compatible with the one
>> used in iproute2. In libbpf.h, the struct only contains five fields
>> (type, key_size, value_size, max_entries and flags), and iproute2 adds
>> another 4 (id, pinning, inner_id and inner_idx; these are the ones in
>> patch 1 in this series).
>>
>> The issue I was alluding to above is that the bpf_helpers.h file in the
>> kernel selftests directory *also* extends the bpf_map_def struct, and
>> adds two *different* fields (inner_map_idx and numa_mode). The former is
>> used to implement the same map-in-map definition functionality that
>> iproute2 has, but with different semantics. The latter is additional to
>> that, and I'm planning to add that to this series.
>>
>> Since bpf_helpers.h is *not* part of libbpf (yet), this will make it
>
> We should start considering it as if it was, so if we can avoid adding
> stuff that I'd need to untangle to move it into libbpf, I'd rather
> avoid it.
> We've already prepared this move by relicensing bpf_helpers.h. Moving
> it into libbpf itself is immediate next thing I'll do when I'm back.
Yeah, I figured that with the relicensing, bpf_helpers would probably be
making its way into libbpf soon. Which is why I wanted to start this
discussion before that: If we do move bpf_helpers as-is, that will put
us in the territory of full-on binary incompatibility. So the time to
discuss doing this in a compatible way is now, before any such move is
made.
-Toke
^ permalink raw reply
* Re: [PATCH] vsock: Fix a lockdep warning in __vsock_release()
From: Stefano Garzarella @ 2019-08-22 10:25 UTC (permalink / raw)
To: Dexuan Cui
Cc: jhansen@vmware.com, davem@davemloft.net, stefanha@redhat.com,
netdev@vger.kernel.org, Stephen Hemminger, Sasha Levin,
sashal@kernel.org, Haiyang Zhang, KY Srinivasan, Michael Kelley,
linux-hyperv@vger.kernel.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1566270830-28981-1-git-send-email-decui@microsoft.com>
On Tue, Aug 20, 2019 at 03:14:22AM +0000, Dexuan Cui wrote:
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning by making __vsock_release() non-recursive -- this
> patch is kind of ugly, but it looks to me there is not a better way to
> deal with the problem here.
>
> ============================================
> WARNING: possible recursive locking detected
> 5.2.0+ #6 Not tainted
> --------------------------------------------
> a.out/1020 is trying to acquire lock:
> 0000000074731a98 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
>
> but task is already holding lock:
> 0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(sk_lock-AF_VSOCK);
> lock(sk_lock-AF_VSOCK);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 2 locks held by a.out/1020:
> #0: 00000000f8bceaa7 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0
> #1: 0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> stack backtrace:
> CPU: 7 PID: 1020 Comm: a.out Not tainted 5.2.0+ #6
> Call Trace:
> dump_stack+0x67/0x90
> __lock_acquire.cold.66+0x14d/0x1f8
> lock_acquire+0xb5/0x1c0
> lock_sock_nested+0x6d/0x90
> hvs_release+0x10/0x120 [hv_sock]
> __vsock_release+0x24/0xf0 [vsock]
> __vsock_release+0xa0/0xf0 [vsock]
> vsock_release+0x12/0x30 [vsock]
> __sock_release+0x37/0xa0
> sock_close+0x14/0x20
> __fput+0xc1/0x250
> task_work_run+0x98/0xc0
> do_exit+0x3dd/0xc60
> do_group_exit+0x47/0xc0
> get_signal+0x169/0xc60
> do_signal+0x30/0x710
> exit_to_usermode_loop+0x50/0xa0
> do_syscall_64+0x1fc/0x220
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
> net/vmw_vsock/af_vsock.c | 33 ++++++++++++++++++++++++++++++++-
> net/vmw_vsock/hyperv_transport.c | 2 +-
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index ab47bf3..420f605 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -638,6 +638,37 @@ struct sock *__vsock_create(struct net *net,
> }
> EXPORT_SYMBOL_GPL(__vsock_create);
>
> +static void __vsock_release2(struct sock *sk)
> +{
> + if (sk) {
> + struct sk_buff *skb;
> + struct vsock_sock *vsk;
> +
> + vsk = vsock_sk(sk);
> +
> + /* The release call is supposed to use lock_sock_nested()
> + * rather than lock_sock(), if a lock should be acquired.
> + */
> + transport->release(vsk);
> +
> + /* Use the nested version to avoid the warning
> + * "possible recursive locking detected".
> + */
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
What about using lock_sock_nested() in the __vsock_release() without
define this new function?
> + sock_orphan(sk);
> + sk->sk_shutdown = SHUTDOWN_MASK;
> +
> + while ((skb = skb_dequeue(&sk->sk_receive_queue)))
> + kfree_skb(skb);
> +
> + /* This sk can not be a listener, so it's unnecessary
> + * to call vsock_dequeue_accept().
> + */
> + release_sock(sk);
> + sock_put(sk);
> + }
> +}
> +
> static void __vsock_release(struct sock *sk)
> {
> if (sk) {
> @@ -659,7 +690,7 @@ static void __vsock_release(struct sock *sk)
>
> /* Clean up any sockets that never were accepted. */
> while ((pending = vsock_dequeue_accept(sk)) != NULL) {
> - __vsock_release(pending);
> + __vsock_release2(pending);
> sock_put(pending);
> }
>
> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 9d864eb..4b126b2 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
> struct sock *sk = sk_vsock(vsk);
> bool remove_sock;
>
> - lock_sock(sk);
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
Should we update also other transports?
Thanks,
Stefano
^ permalink raw reply
* RE: Help needed - Kernel lockup while running ipsec
From: Vakul Garg @ 2019-08-22 10:23 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190821161159.GA20113@breakpoint.cc>
> -----Original Message-----
> From: Florian Westphal <fw@strlen.de>
> Sent: Wednesday, August 21, 2019 9:42 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org
> Subject: Re: Help needed - Kernel lockup while running ipsec
>
> Vakul Garg <vakul.garg@nxp.com> wrote:
> > > Policy refcount is decreasing properly on 4.19.
> > > Same should be on the latest kernel too.
> >
> > On kernel-4.14, I find dst_release() is getting called through
> xfrm_output_one().
> > However since dst->__refcnt gets decremented to '1', the
> > call_rcu(&dst->rcu_head, dst_destroy_rcu) is not invoked.
> >
> > On kernel-4.19, dst->__refcnt gets decremented to '0', hence things
> > fall in place and
> > dst_destroy_rcu() eventually executes.
> >
> > Any further help/pointers for kernel-4.14 would be deeply appreciated.
>
> Can you try getting rid of the pcpu dst cache?
>
> I had a look at 4.14-stable and it at least lacks 2950278d2d04ff531.
>
> I've attached an (untested) revert of the pcpu cache (its gone in 4.19 and
> onwards).
>
This patch fixed the refcnt issue. Many thanks for your help.
Would you send this patch for inclusion into 4.14-stable?
^ permalink raw reply
* Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function
From: Eelco Chaudron @ 2019-08-22 10:20 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <CAJ8uoz1kQXgMUydktY3ci=8fjneUDW9B=qOGHzEQY1MvBThu8A@mail.gmail.com>
On 21 Aug 2019, at 16:53, Magnus Karlsson wrote:
> On Wed, Aug 21, 2019 at 4:14 PM Magnus Karlsson
> <magnus.karlsson@gmail.com> wrote:
>>
>> On Wed, Aug 21, 2019 at 3:46 PM Eelco Chaudron <echaudro@redhat.com>
>> wrote:
>>>
>>>
>>>
>>> On 21 Aug 2019, at 15:11, Magnus Karlsson wrote:
>>>
>>>> On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron
>>>> <echaudro@redhat.com>
>>>> wrote:
>>>>>
>>>>> When an AF_XDP application received X packets, it does not mean X
>>>>> frames can be stuffed into the producer ring. To make it easier
>>>>> for
>>>>> AF_XDP applications this API allows them to check how many frames
>>>>> can
>>>>> be added into the ring.
>>>>>
>>>>> The patch below looks like a name change only, but the xsk_prod__
>>>>> prefix denotes that this API is exposed to be used by
>>>>> applications.
>>>>>
>>>>> Besides, if you set the nb value to the size of the ring, you will
>>>>> get the exact amount of slots available, at the cost of
>>>>> performance
>>>>> (you touch shared state for sure). nb is there to limit the
>>>>> touching of the shared state.
>>>>>
>>>>> Also the example xdpsock application has been modified to use this
>>>>> new API, so it's also able to process flows at a 1pps rate on veth
>>>>> interfaces.
>
> 1 pps! That is not that impressive ;-).
>
>>>> My apologies for the late reply and thank you for working on this.
>>>> So
>>>> what kind of performance difference do you see with your modified
>>>> xdpsock application on a regular NIC for txpush and l2fwd? If there
>>>> is
>>>> basically no difference or it is faster, we can go ahead and accept
>>>> this. But if the difference is large, we might consider to have two
>>>> versions of txpush and l2fwd as the regular NICs do not need this.
>>>> Or
>>>> we optimize your code so that it becomes as fast as the previous
>>>> version.
>>>
>>> For both operation modes, I ran 5 test with and without the changes
>>> applied using an iexgb connecting to a XENA tester. The throughput
>>> numbers were within the standard deviation, so no noticeable
>>> performance
>>> gain or drop.
>>
>> Sounds good, but let me take your patches for a run on something
>> faster, just to make sure we are CPU bound. Will get back.
>
> I ran some experiments and with two cores (app on one, softirq on
> another) there is no impact since the application core has cycles to
> spare. But if you run it on a single core the drop is 1- 2% for l2fwd.
> I think this is ok since your version is a better example and more
> correct. Just note that your patch did not apply cleanly to bpf-next,
> so please rebase it, resubmit and I will ack it.
Just sent out a v5 which is a tested rebase on the latest bpf-next.
<SNIP>
^ 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