* Re: [PATCH] net:ethernet:aquantia:atlantic: Fix driver name reported by ethtool
From: David Miller @ 2017-05-03 18:10 UTC (permalink / raw)
To: Pavel.Belous; +Cc: netdev, darcari
In-Reply-To: <06ae22333f8b032e21628389a0c5e33075e5082e.1493829200.git.pavel.belous@aquantia.com>
From: Pavel Belous <Pavel.Belous@aquantia.com>
Date: Wed, 3 May 2017 21:06:04 +0300
> From: Pavel Belous <pavel.belous@aquantia.com>
>
> The command "ethtool -i ethX" should display driver name (driver: atlantic)
> instead vendor name (driver: aquantia).
>
> Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
I'd like to ask you to please use a more appropriate subsystem prefix
in your patches.
First of all, if there are mutliple subsystem tags, separate them with spaces.
But in this case, purely "aquantia: " is sufficient.
Please resubmit this with that fixed up, thank you.
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: David Ahern @ 2017-05-03 18:14 UTC (permalink / raw)
To: Алексей Болдырев,
netdev
In-Reply-To: <149211493832787@web33j.yandex.ru>
On 5/3/17 11:33 AM, Алексей Болдырев wrote:
> I watched one forum, there is listed in the properties of one license for Cisco, it says:
>
> Layer 3 VPN • Multi-VRF CE (VRF-lite); requires IP Services Feature license
> • MPLS VPN; requires Advanced IP Feature license
> • 26 VRFs
There is no direct limit on the number of VRFs the kernel allows you to
create. There are indirect ones -- total memory in the system and limits
such as /proc/sys/net/ipv6/route/max_size. By increasing the latter I
have created 4k VRFs in a system.
> • 8192 MPLS labels
>
> Especially interested in the figure 8192 MPLS Labels.
8192 labels added in one pass is absurd. There is no reason to support
such a number. With the latest version of the MPLS stack in the kernel
you can add up to 30 labels in a single route. If you want more you have
to either recirculate the packet using routes or recompile the kernel
and increase the memory limit and the number of labels limit.
>
> As I understand it, is it either a limit on the number of labels on the stack or the total number of labels?
>
> In Linux, for example, you can specify a common col- lection of labels through /proc/sys/net/mpls/platforms_labels
that just allocates the size of an array which dictates the max label
number for that namespace. The array needs to be converted to a hash
table at some point.
>
> Also I would like to know if the openvswitch has a limit of 3 tags in the stack or the total number of MPLS labels that can send?
>
someone familiar with OVS needs to answer that.
^ permalink raw reply
* [PATCH v2] aquantia: Fix driver name reported by ethtool
From: Pavel Belous @ 2017-05-03 18:17 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari
From: Pavel Belous <pavel.belous@aquantia.com>
V2: using "aquantia" subsystem tag.
The command "ethtool -i ethX" should display driver name (driver: atlantic)
instead vendor name (driver: aquantia).
Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_cfg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h b/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
index 5f99237..2149864 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
@@ -68,7 +68,7 @@
#define AQ_CFG_DRV_AUTHOR "aQuantia"
#define AQ_CFG_DRV_DESC "aQuantia Corporation(R) Network Driver"
-#define AQ_CFG_DRV_NAME "aquantia"
+#define AQ_CFG_DRV_NAME "atlantic"
#define AQ_CFG_DRV_VERSION __stringify(NIC_MAJOR_DRIVER_VERSION)"."\
__stringify(NIC_MINOR_DRIVER_VERSION)"."\
__stringify(NIC_BUILD_DRIVER_VERSION)"."\
--
2.7.4
^ permalink raw reply related
* Re: net/ipv6: GPF in rt6_device_match
From: David Ahern @ 2017-05-03 18:22 UTC (permalink / raw)
To: Cong Wang, Andrey Konovalov
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <CAM_iQpUtVZiKTxnUBYEPLQzJSK+G_=Be-uzwuqph6g2VPsZijw@mail.gmail.com>
On 5/3/17 11:02 AM, Cong Wang wrote:
> A quick glance shows we need to simply check local->rt6i_idev
> since we do the same check for sprt right above.
As I recall, rt6i_idev is set for all routes except null_entry and it is
not set on null_entry only because of initialization order.
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a1bf426..61ec3c8 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -511,7 +511,7 @@ static inline struct rt6_info
> *rt6_device_match(struct net *net,
> sprt->rt6i_idev->dev->ifindex != oif) {
> if (flags & RT6_LOOKUP_F_IFACE)
> continue;
> - if (local &&
> + if (local && local->rt6i_idev &&
>
> local->rt6i_idev->dev->ifindex == oif)
> continue;
> }
>
Or don't consider null_entry at all:
@@ -515,7 +528,8 @@ static inline struct rt6_info
*rt6_device_match(struct net *net,
local->rt6i_idev->dev->ifindex == oif)
continue;
}
- local = sprt;
+ if (sprt != net->ipv6.ip6_null_entry)
+ local = sprt;
}
^ permalink raw reply
* Re: [PATCH] net: ipv6: Fix warning of freeing alive inet6 address
From: Mike Manning @ 2017-05-03 18:24 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVNqU7zJhOe2Qqn5Og+qer4RKhFwh4bdvRcAnt82zyj3A@mail.gmail.com>
On 03/05/17 18:58, Cong Wang wrote:
> On Tue, May 2, 2017 at 11:30 AM, Mike Manning <mmanning@brocade.com> wrote:
>> While this is not reproducible manually, Andrey's syzkaller program hit
>> the warning "IPv6: Freeing alive inet6 address" with this part trace:
>>
>> inet6_ifa_finish_destroy+0x12e/0x190 c:894
>> in6_ifa_put ./include/net/addrconf.h:330
>> addrconf_dad_work+0x4e9/0x1040 net/ipv6/addrconf.c:3963
>>
>> The fix is to call in6_ifa_put() for the inet6_ifaddr before rather
>> than after calling addrconf_ifdown(), as the latter may remove it from
>> the address hash table.
>>
>> Fixes: 85b51b12115c ("net: ipv6: Remove addresses for failures with strict DAD")
>> Reported-by: Andrey Konovalov <andreyknvl@google.com>
>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>> ---
>> net/ipv6/addrconf.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 80ce478..361993a 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -3902,8 +3902,11 @@ static void addrconf_dad_work(struct work_struct *w)
>> } else if (action == DAD_ABORT) {
>> in6_ifa_hold(ifp);
>> addrconf_dad_stop(ifp, 1);
>> - if (disable_ipv6)
>> + if (disable_ipv6) {
>> + in6_ifa_put(ifp);
>> addrconf_ifdown(idev->dev, 0);
>> + goto unlock;
>> + }
>
>
> But addrconf_dad_stop() calls ipv6_del_addr() which could unhash
> the addr too...
>
Agreed, and in the mean time Andrey has confirmed that this v1 patch
does not resolve the issue. The problem is not specific to my change
for removing addresses. It seems that generally here the in6_ifa_hold()
and matching in6_ifa_put() are surplus to requirement, as the address
refcnt is 2 even without the hold before calling DAD stop.
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-05-03 19:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Pavel Machek, Daniel Wagner, Tom Gundersen
Cc: Pali Rohár, Ming Lei, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Tony Lindgren, Sebastian Reichel,
Ivaylo Dimitrov, Aaro Koskinen, Takashi Iwai, David Woodhouse,
Bjorn Andersson, Grazvydas Ignotas, linux-kernel, linux-wireless,
netdev
In-Reply-To: <20170103175924.GC13946@wotan.suse.de>
On 3-1-2017 18:59, Luis R. Rodriguez wrote:
> On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote:
>>
>> Right question is "should we solve it without user-space help"?
>>
>> Answer is no, too. Way too complex. Yes, it would be nice if hardware
>> was designed in such a way that getting calibration data from kernel
>> is easy, and if you design hardware, please design it like that. But
>> N900 is not designed like that and getting the calibration through
>> userspace looks like only reasonable solution.
>
> Arend seems to have a better alternative in mind possible for other
> devices which *can* probably pull of doing this easily and nicely,
> given the nasty history of the usermode helper crap we should not
> in any way discourage such efforts.
>
> Arend -- please look at the firmware cache, it not a hash but a hash
> table for an O(1) lookups would be a welcomed change, then it could
> be repurposed for what you describe, I think the only difference is
> you'd perhaps want a custom driver hook to fetch the calibration data
> so the driver does whatever it needs.
Hi Luis,
I let my idea catch dust on the shelf for a while. Actually had a couple
of patches ready, but did get around testing them. So I wanted to rebase
them on your linux-next tree. I bumped into the umh lock thing and was
wondering why direct filesystem access was under that lock as well. In
your tree I noticed a fix for that. The more reason to base my work on
top of your firmware_class changes. Now my question is what is the best
branch to choose, because you have a "few" in that repo to choose from ;-)
Regards,
Arend
^ permalink raw reply
* 55214 netdev
From: nmckenna @ 2017-05-03 19:24 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 770.zip --]
[-- Type: application/zip, Size: 3257 bytes --]
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Lars Erik Storbukås @ 2017-05-03 19:47 UTC (permalink / raw)
To: Andreas Petlund; +Cc: Neal Cardwell, LKML, Netdev
In-Reply-To: <8D257A7F-6045-46C5-AEED-A4630D10CD5A@simula.no>
2017-04-25 0:20 GMT+02:00 Andreas Petlund <apetlund@simula.no>:
>
>> On 24 Apr 2017, at 23:31, Lars Erik Storbukås <storbukas.dev@gmail.com> wrote:
>>
>> 2017-04-24 23:00 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>>> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
>>> <storbukas.dev@gmail.com> wrote:
>>>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>>>>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>>>>> <storbukas.dev@gmail.com> wrote:
>>>>>> I'm trying to get amount of congestion events in TCP caused by
>>>>>> DUPACK's (fast retransmissions), and can't seem to find any variable
>>>>>> in the TCP info struct which hold that value. There are three
>>>>>> variables in the TCP info struct that seem to hold similar congestion
>>>>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>>>>>> tcpi_total_retrans;
>>>>>>
>>>>>> Does anyone have any pointers on how to find this value in the TCP code?
>>>>>>
>>>>>> Please CC me personally if answering this question. Any help is
>>>>>> greatly appreciated.
>>>>>
>>>>> [I'm cc-ing the netdev list.]
>>>>>
>>>>> Do you need this per-socket? On a per-socket basis, I do not think
>>>>> there are separate totals for fast retransmits and timeout
>>>>> retransmits.
>>>>>
>>>>> If a global number is good enough, then you can get that number from
>>>>> the global network statistics. In "nstat" output they look like:
>>>>>
>>>>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>>>>>
>>>>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>>>>>
>>>>> It sounds like TcpExtTCPFastRetrans is what you are after.
>>>>>
>>>>> Hope that helps,
>>>>> neal
>>>>
>>>> Thanks for your answer Neal.
>>>>
>>>> Yes, I need this information per-socket. What would be the most
>>>> appropriate place to update this value?
>>>
>>> Is this for a custom kernel you are building? Or are you proposing
>>> this for upstream?
>>
>> This is currently for a custom kernel.
>>
>>> IMHO the best place to add this for your custom kernel would be in
>>> _tcp_retransmit_skb() around the spot with the comment "Update global
>>> and local TCP statistics". Something like:
>>>
>>> /* Update global and local TCP statistics. */
>>> ...
>>> tp->total_retrans += segs;
>>> if (icsk->icsk_ca_state == TCP_CA_Loss)
>>> tp->slow_retrans += segs;
>>> else
>>> tp->fast_retrans += segs;
>>>
>>
>> Excellent. That seems like a logical place.
>>
>>>> If none of the variables (mentioned above) contain any value in
>>>> regards to fast retransmits, what does the different values represent?
>>>
>>> tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet
>>>
>>> tcpi_retrans: retransmitted packets estimated to be in-flight in the network now
>>>
>>> tcpi_total_retrans: total number of retransmitted packets over the
>>> life of the connection
>>>
>>> Can you sketch out why you need to have separate counts for fast
>>> retransmits and timeout/slow-start retransmits?
>>>
>>> neal
>>
>> I'm working on the implementation of a Deadline Aware, Less than Best
>> Effort framework proposed by David A. Hayes, David Ros, Andreas
>> Petlund. A framework for adding both LBE behaviour and awareness of
>> “soft” delivery deadlines to any congestion control (CC) algorithm,
>> whether loss-based, delay- based or explicit signaling-based. This
>> effectively allows it to turn an arbitrary CC protocol into a
>> scavenger protocol that dynamically adapts its sending rate to network
>> conditions and remaining time before the deadline, to balance
>> timeliness and transmission aggressiveness.
>>
>
> Just for the record, the paper is not publicly available yet, so it’s a bit hard to find:)
> It will be published in IFIP Networking in June.
> We will make it available as soon as the conference regulations allows.
> You can find the abstract here:
> https://www.simula.no/publications/framework-less-best-effort-congestion-control-soft-deadlines
>
> Cheers,
> Andreas Petlund
I also want to count the amount of ECN signals received. Do anyone
have any input on where to place an ECN signal count?
Is any of these locations a logical place to increase the ECN counter
(which I've created in tcp_sock)? Both locations are in the
tcp_input.c.
/* In tcp_fastretrans_alert() */
if (flag & FLAG_ECE) {
tp->prior_ssthresh = 0;
tp->ecn_count += 1; // ECN counter
}
or
/* In tcp_enter_recovery() */
if (!tcp_in_cwnd_reduction(sk)) {
if (!ece_ack)
tp->prior_ssthresh = tcp_current_ssthresh(sk);
else
tp->ecn_count += 1; // ECN counter
tcp_init_cwnd_reduction(sk);
}
tcp_set_ca_state(sk, TCP_CA_Recovery);
/Lars Erik
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Neal Cardwell @ 2017-05-03 20:01 UTC (permalink / raw)
To: Lars Erik Storbukås; +Cc: Andreas Petlund, LKML, Netdev
In-Reply-To: <CAF0XkCD_US9yVxsU8GDpEqoH3y3LLOGQF0K8fu5cNbjTewXuNw@mail.gmail.com>
On Wed, May 3, 2017 at 3:47 PM, Lars Erik Storbukås
<storbukas.dev@gmail.com> wrote:
> I also want to count the amount of ECN signals received. Do anyone
> have any input on where to place an ECN signal count?
>
> Is any of these locations a logical place to increase the ECN counter
> (which I've created in tcp_sock)? Both locations are in the
> tcp_input.c.
>
> /* In tcp_fastretrans_alert() */
> if (flag & FLAG_ECE) {
> tp->prior_ssthresh = 0;
> tp->ecn_count += 1; // ECN counter
> }
This approach sounds good to me.
> or
>
> /* In tcp_enter_recovery() */
> if (!tcp_in_cwnd_reduction(sk)) {
> if (!ece_ack)
> tp->prior_ssthresh = tcp_current_ssthresh(sk);
> else
> tp->ecn_count += 1; // ECN counter
> tcp_init_cwnd_reduction(sk);
> }
> tcp_set_ca_state(sk, TCP_CA_Recovery);
This location would only count ECE marks we happened to get at the
moment we enter loss recovery.
neal
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: Joe Stringer @ 2017-05-03 20:21 UTC (permalink / raw)
To: David Ahern
Cc: Алексей Болдырев,
netdev
In-Reply-To: <5a408c23-d3e2-aa3e-4574-82521b2255b0@gmail.com>
On 3 May 2017 at 11:14, David Ahern <dsahern@gmail.com> wrote:
> On 5/3/17 11:33 AM, Алексей Болдырев wrote:
>> I watched one forum, there is listed in the properties of one license for Cisco, it says:
>>
>> Layer 3 VPN • Multi-VRF CE (VRF-lite); requires IP Services Feature license
>> • MPLS VPN; requires Advanced IP Feature license
>> • 26 VRFs
>
> There is no direct limit on the number of VRFs the kernel allows you to
> create. There are indirect ones -- total memory in the system and limits
> such as /proc/sys/net/ipv6/route/max_size. By increasing the latter I
> have created 4k VRFs in a system.
>
>
>> • 8192 MPLS labels
>>
>> Especially interested in the figure 8192 MPLS Labels.
>
> 8192 labels added in one pass is absurd. There is no reason to support
> such a number. With the latest version of the MPLS stack in the kernel
> you can add up to 30 labels in a single route. If you want more you have
> to either recirculate the packet using routes or recompile the kernel
> and increase the memory limit and the number of labels limit.
>
>>
>> As I understand it, is it either a limit on the number of labels on the stack or the total number of labels?
>>
>> In Linux, for example, you can specify a common col- lection of labels through /proc/sys/net/mpls/platforms_labels
>
> that just allocates the size of an array which dictates the max label
> number for that namespace. The array needs to be converted to a hash
> table at some point.
>
>>
>> Also I would like to know if the openvswitch has a limit of 3 tags in the stack or the total number of MPLS labels that can send?
>>
>
> someone familiar with OVS needs to answer that.
That would be 3 tags in a stack. When we spoke to people involved in
the design and usage of MPLS in practice, we got the impression that
it's very rare for anyone to configure a setup where more than that is
used concurrently on a packet. If you believe the contrary, then I
imagine it's not hard to bump that limit.
There is no limit on which labels can be used from OVS, it's just a
number in an action attached to a flow.
^ permalink raw reply
* Re: [PATCH 0/9] net: thunderx: Adds XDP support
From: Rami Rosen @ 2017-05-03 20:39 UTC (permalink / raw)
To: Sunil Kovvuri; +Cc: Sunil Goutham, linux-arm-kernel, Netdev, LKML, David Miller
In-Reply-To: <CA+sq2CfW89EbiZmp6byc3y3cbATmmyVB=avzrUXG51-x3yxckg@mail.gmail.com>
Thanks, Sunil.
>with network stack: 0.32 Mpps
>with XDP (XDP_TX): 3 Mpps
>and XDP_DROP: 3.8 Mpps
Interesting; May I ask - which packet size did you use ?
Regards,
Rami Rosen
^ permalink raw reply
* Re: [PATCH v4 net-next 05/10] net/ncsi: Ethtool operation to get NCSI channel info
From: kbuild test robot @ 2017-05-03 20:53 UTC (permalink / raw)
To: Gavin Shan
Cc: kbuild-all, netdev, joe, kubakici, f.fainelli, davem, Gavin Shan
In-Reply-To: <1493786681-27468-6-git-send-email-gwshan@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6155 bytes --]
Hi Gavin,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Gavin-Shan/net-ncsi-Add-debugging-functionality/20170503-185932
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from include/linux/string.h:18:0,
from include/linux/bitmap.h:8,
from include/linux/nodemask.h:94,
from include/linux/mmzone.h:16,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from net/ncsi/ncsi-ethtool.c:10:
net/ncsi/ncsi-ethtool.c: In function 'ncsi_get_channel_info':
>> arch/alpha/include/asm/string.h:21:16: warning: 'dest' may be used uninitialized in this function [-Wmaybe-uninitialized]
#define memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
net/ncsi/ncsi-ethtool.c:106:9: note: 'dest' was declared here
void *dest;
^~~~
net/ncsi/ncsi-ethtool.c:105:26: warning: 'd_idx' may be used uninitialized in this function [-Wmaybe-uninitialized]
int entry_size, s_idx, d_idx;
^~~~~
net/ncsi/ncsi-ethtool.c:148:18: warning: 'p_valid_bits' may be used uninitialized in this function [-Wmaybe-uninitialized]
*p_valid_bits |= (1 << d_idx);
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
--
In file included from include/linux/string.h:18:0,
from include/linux/bitmap.h:8,
from include/linux/nodemask.h:94,
from include/linux/mmzone.h:16,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from net//ncsi/ncsi-ethtool.c:10:
net//ncsi/ncsi-ethtool.c: In function 'ncsi_get_channel_info':
>> arch/alpha/include/asm/string.h:21:16: warning: 'dest' may be used uninitialized in this function [-Wmaybe-uninitialized]
#define memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
net//ncsi/ncsi-ethtool.c:106:9: note: 'dest' was declared here
void *dest;
^~~~
net//ncsi/ncsi-ethtool.c:105:26: warning: 'd_idx' may be used uninitialized in this function [-Wmaybe-uninitialized]
int entry_size, s_idx, d_idx;
^~~~~
net//ncsi/ncsi-ethtool.c:148:18: warning: 'p_valid_bits' may be used uninitialized in this function [-Wmaybe-uninitialized]
*p_valid_bits |= (1 << d_idx);
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
vim +/dest +21 arch/alpha/include/asm/string.h
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 5
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 6 /*
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 7 * GCC of any recent vintage doesn't do stupid things with bcopy.
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 8 * EGCS 1.1 knows all about expanding memcpy inline, others don't.
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 9 *
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 10 * Similarly for a memset with data = 0.
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 11 */
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 12
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 13 #define __HAVE_ARCH_MEMCPY
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 14 extern void * memcpy(void *, const void *, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 15 #define __HAVE_ARCH_MEMMOVE
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 16 extern void * memmove(void *, const void *, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 17
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 18 /* For backward compatibility with modules. Unused otherwise. */
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 19 extern void * __memcpy(void *, const void *, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 20
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 @21 #define memcpy __builtin_memcpy
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 22
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 23 #define __HAVE_ARCH_MEMSET
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 24 extern void * __constant_c_memset(void *, unsigned long, size_t);
a47e5bb5 arch/alpha/include/asm/string.h Richard Henderson 2013-07-11 25 extern void * ___memset(void *, int, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 26 extern void * __memset(void *, int, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 27 extern void * memset(void *, int, size_t);
^1da177e include/asm-alpha/string.h Linus Torvalds 2005-04-16 28
a47e5bb5 arch/alpha/include/asm/string.h Richard Henderson 2013-07-11 29 /* For gcc 3.x, we cannot have the inline function named "memset" because
:::::: The code at line 21 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49744 bytes --]
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: Joe Stringer @ 2017-05-03 21:22 UTC (permalink / raw)
To: Алексей Болдырев
Cc: David Ahern, netdev
In-Reply-To: <443301493846392@web51g.yandex.ru>
On 3 May 2017 at 14:19, Алексей Болдырев
<devel-net-ne-vlezay80@yandex.ru> wrote:
> Is it possible to increase this limit in OpenVswitch?
Yes.
^ permalink raw reply
* Re: [PATCH net] net: ipv6: Do not duplicate DAD on link up
From: Cong Wang @ 2017-05-03 21:22 UTC (permalink / raw)
To: David Ahern
Cc: Linux Kernel Network Developers, Dmitry Vyukov, Andrey Konovalov
In-Reply-To: <1493761424-17407-1-git-send-email-dsahern@gmail.com>
On Tue, May 2, 2017 at 2:43 PM, David Ahern <dsahern@gmail.com> wrote:
> Andrey reported a warning triggered by the rcu code:
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289
> debug_print_object+0x175/0x210
> ODEBUG: activate active (active state 1) object type: rcu_head hint:
> (null)
> Modules linked in:
> CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x192/0x22d lib/dump_stack.c:52
> __warn+0x19f/0x1e0 kernel/panic.c:549
> warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564
> debug_print_object+0x175/0x210 lib/debugobjects.c:286
> debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442
> debug_rcu_head_queue kernel/rcu/rcu.h:75
> __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229
> call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
> rt6_rcu_free net/ipv6/ip6_fib.c:158
> rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188
> fib6_del_route net/ipv6/ip6_fib.c:1461
> fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500
> __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174
> ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187
> __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520
> addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672
> ...
>
> Andrey's reproducer program runs in a very tight loop, calling
> 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl
> calls. The relevant networking sequence:
>
> 1. New network namespace created via unshare -n
> - ip6tnl0 device is created in down state
>
> 2. address added to ip6tnl0
> - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1
> - DAD is started on the address and when it completes the host
> route is inserted into the FIB
>
> 3. ip6tnl0 is brought up
> - the new fixup_permanent_addr function restarts DAD on the address
>
> 4. exit namespace
> - teardown / cleanup sequence starts
> - once in a blue moon, lo teardown appears to happen BEFORE teardown
> of ip6tunl0
Why is this possible? Loopback device should be always the first one to
register therefore the last one to unregister.
> + down on 'lo' removes the host route from the FIB since the dst->dev
> for the route is loobback
> + host route added to rcu callback list
> * rcu callback has not run yet, so rt is NOT on the gc list so it has
> NOT been marked obsolete
>
> 5. in parallel to 4. worker_thread runs addrconf_dad_completed
> - DAD on the address on ip6tnl0 completes
> - calls ipv6_ifa_notify which inserts the host route
>
> All of that happens very quickly. The result is that a host route that
> has been deleted from the IPv6 FIB and added to the RCU list is re-inserted
> into the FIB.
>
> The exit namespace eventually gets to cleaning up ip6tnl0 which removes the
> host route from the FIB again, calls the rcu function for cleanup -- and
> triggers the double rcu trace.
>
> The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably,
> DAD should not be started in step 2. The interface is in the down state,
> so it can not really send out requests for the address which makes starting
> DAD pointless.
>
> Since the second DAD was introduced by a recent change, seems appropriate
> to use it for the Fixes tag and have the fixup function only start DAD for
> addresses in the PREDAD state which occurs in addrconf_ifdown if the
> address is retained.
Hmm? But addrconf_ifdown() is called when the device is going from UP
to down, how does your patch prevent a duplicated DAD for a device which
is going from DOWN to UP in step 3? This is very confusing.
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: Алексей Болдырев @ 2017-05-03 21:19 UTC (permalink / raw)
To: Joe Stringer, David Ahern; +Cc: netdev
In-Reply-To: <CAPWQB7FFwBFL9h7JoJMF4FuK7JXLrHfo5yg4aHJ4iczSdNU_bg@mail.gmail.com>
Is it possible to increase this limit in OpenVswitch?
03.05.2017, 23:21, "Joe Stringer" <joe@ovn.org>:
> On 3 May 2017 at 11:14, David Ahern <dsahern@gmail.com> wrote:
>> On 5/3/17 11:33 AM, Алексей Болдырев wrote:
>>> I watched one forum, there is listed in the properties of one license for Cisco, it says:
>>>
>>> Layer 3 VPN • Multi-VRF CE (VRF-lite); requires IP Services Feature license
>>> • MPLS VPN; requires Advanced IP Feature license
>>> • 26 VRFs
>>
>> There is no direct limit on the number of VRFs the kernel allows you to
>> create. There are indirect ones -- total memory in the system and limits
>> such as /proc/sys/net/ipv6/route/max_size. By increasing the latter I
>> have created 4k VRFs in a system.
>>
>>> • 8192 MPLS labels
>>>
>>> Especially interested in the figure 8192 MPLS Labels.
>>
>> 8192 labels added in one pass is absurd. There is no reason to support
>> such a number. With the latest version of the MPLS stack in the kernel
>> you can add up to 30 labels in a single route. If you want more you have
>> to either recirculate the packet using routes or recompile the kernel
>> and increase the memory limit and the number of labels limit.
>>
>>> As I understand it, is it either a limit on the number of labels on the stack or the total number of labels?
>>>
>>> In Linux, for example, you can specify a common col- lection of labels through /proc/sys/net/mpls/platforms_labels
>>
>> that just allocates the size of an array which dictates the max label
>> number for that namespace. The array needs to be converted to a hash
>> table at some point.
>>
>>> Also I would like to know if the openvswitch has a limit of 3 tags in the stack or the total number of MPLS labels that can send?
>>
>> someone familiar with OVS needs to answer that.
>
> That would be 3 tags in a stack. When we spoke to people involved in
> the design and usage of MPLS in practice, we got the impression that
> it's very rare for anyone to configure a setup where more than that is
> used concurrently on a packet. If you believe the contrary, then I
> imagine it's not hard to bump that limit.
>
> There is no limit on which labels can be used from OVS, it's just a
> number in an action attached to a flow.
^ permalink raw reply
* Re: [PATCH net] net: ipv6: Do not duplicate DAD on link up
From: David Ahern @ 2017-05-03 21:29 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Dmitry Vyukov, Andrey Konovalov
In-Reply-To: <CAM_iQpVJZRzYmWqhYBhoAnv71GkM=0HQW7yUvzUQgVT-5hy_3g@mail.gmail.com>
On 5/3/17 3:22 PM, Cong Wang wrote:
>> Andrey's reproducer program runs in a very tight loop, calling
>> 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl
>> calls. The relevant networking sequence:
>>
>> 1. New network namespace created via unshare -n
>> - ip6tnl0 device is created in down state
>>
>> 2. address added to ip6tnl0
>> - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1
>> - DAD is started on the address and when it completes the host
>> route is inserted into the FIB
>>
>> 3. ip6tnl0 is brought up
>> - the new fixup_permanent_addr function restarts DAD on the address
>>
>> 4. exit namespace
>> - teardown / cleanup sequence starts
>> - once in a blue moon, lo teardown appears to happen BEFORE teardown
>> of ip6tunl0
>
> Why is this possible? Loopback device should be always the first one to
> register therefore the last one to unregister.
Andrey's config builds in all of the devices. Once in a blue moon I
would see the host route get deleted b/c 'lo' was taken down.
>
> Hmm? But addrconf_ifdown() is called when the device is going from UP
> to down, how does your patch prevent a duplicated DAD for a device which
> is going from DOWN to UP in step 3? This is very confusing.
>
read the sequence:
1. ip6tnl0 is in the down state
2. address is added to ip6tnl0
DAD starts, completes, inserts host route into FIB
3. ip6tnl0 is brought up
DAD starts, completes, inserts host route into FIB
Between 2. and 3. lo is taken down.
Since DAD is done for an address in 2, it does not need to be repeated in 3.
The DAD in 3. was meant for addresses kept on an admin down. This patch
does that.
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: Алексей Болдырев @ 2017-05-03 21:29 UTC (permalink / raw)
To: Joe Stringer; +Cc: David Ahern, netdev
In-Reply-To: <CAPWQB7HrbCVLEjaR0hObPTxrDg8qyfZo-3iYLe=NVzuPTOLxCQ@mail.gmail.com>
As I understand it, it's enough to just set the variable in the source
#define FLOW_MAX_MPLS_LABELS 3
on
#define FLOW_MAX_MPLS_LABELS 7
Or is there somehow still pitfalls?
04.05.2017, 00:22, "Joe Stringer" <joe@ovn.org>:
> On 3 May 2017 at 14:19, Алексей Болдырев
> <devel-net-ne-vlezay80@yandex.ru> wrote:
>> Is it possible to increase this limit in OpenVswitch?
>
> Yes.
^ permalink raw reply
* 52982 netdev
From: chacoma4018 @ 2017-05-03 21:43 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 182505210954719.zip --]
[-- Type: application/zip, Size: 3233 bytes --]
^ permalink raw reply
* Re: Maximum MPLS labels on Linux network stack
From: Joe Stringer @ 2017-05-03 21:46 UTC (permalink / raw)
To: Алексей Болдырев
Cc: David Ahern, netdev
In-Reply-To: <454271493846945@web51g.yandex.ru>
On 3 May 2017 at 14:29, Алексей Болдырев
<devel-net-ne-vlezay80@yandex.ru> wrote:
> As I understand it, it's enough to just set the variable in the source
> #define FLOW_MAX_MPLS_LABELS 3
> on
> #define FLOW_MAX_MPLS_LABELS 7
> Or is there somehow still pitfalls?
You'll probably need to update the BUILD_ASSERT_DECL for the offset of
igmp_group_ip4, and for extra safety increment FLOW_WC_SEQ and inspect
each other place that has BUILD_ASSERT_DECL statements relying on that
FLOW_WC_SEQ. Changing FLOW_WC_SEQ will introduce compiler
warnings/failures so you can step through each location, take a look
if it's relevant and update the BUILD_ASSERT_DECL.
At a glance it seems like even with that bump, OVS userspace is only
detecting support for 3 labels so you might need to update something
kernel-side as well.
^ permalink raw reply
* Re: net/ipv6: GPF in rt6_device_match
From: Cong Wang @ 2017-05-03 22:02 UTC (permalink / raw)
To: David Ahern
Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <4ef76406-8e05-ccdf-fefb-dc47d56c71c9@gmail.com>
On Wed, May 3, 2017 at 11:22 AM, David Ahern <dsahern@gmail.com> wrote:
> On 5/3/17 11:02 AM, Cong Wang wrote:
>> A quick glance shows we need to simply check local->rt6i_idev
>> since we do the same check for sprt right above.
>
> As I recall, rt6i_idev is set for all routes except null_entry and it is
> not set on null_entry only because of initialization order.
Are you sure?
if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK)) {
net->ipv6.ip6_null_entry->dst.dev = dev;
net->ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(dev);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
net->ipv6.ip6_prohibit_entry->dst.dev = dev;
net->ipv6.ip6_prohibit_entry->rt6i_idev = in6_dev_get(dev);
net->ipv6.ip6_blk_hole_entry->dst.dev = dev;
net->ipv6.ip6_blk_hole_entry->rt6i_idev = in6_dev_get(dev);
#endif
}
Loopback is the first one to register, so null entry is set to
loopback dev initially. Similar for init_net.
^ permalink raw reply
* Re: net/ipv6: GPF in rt6_device_match
From: David Ahern @ 2017-05-03 22:09 UTC (permalink / raw)
To: Cong Wang
Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <CAM_iQpVwBp=11c_SQgNxdONefHfZQiyzRwb2pOGgJVECytOzgg@mail.gmail.com>
On 5/3/17 4:02 PM, Cong Wang wrote:
> On Wed, May 3, 2017 at 11:22 AM, David Ahern <dsahern@gmail.com> wrote:
>> On 5/3/17 11:02 AM, Cong Wang wrote:
>>> A quick glance shows we need to simply check local->rt6i_idev
>>> since we do the same check for sprt right above.
>>
>> As I recall, rt6i_idev is set for all routes except null_entry and it is
>> not set on null_entry only because of initialization order.
>
> Are you sure?
>
> if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK)) {
> net->ipv6.ip6_null_entry->dst.dev = dev;
> net->ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(dev);
> #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> net->ipv6.ip6_prohibit_entry->dst.dev = dev;
> net->ipv6.ip6_prohibit_entry->rt6i_idev = in6_dev_get(dev);
> net->ipv6.ip6_blk_hole_entry->dst.dev = dev;
> net->ipv6.ip6_blk_hole_entry->rt6i_idev = in6_dev_get(dev);
> #endif
> }
>
> Loopback is the first one to register, so null entry is set to
> loopback dev initially. Similar for init_net.
>
Why don't you add a printk and see ;-)
^ permalink raw reply
* Re: [PATCH net] net: ipv6: Do not duplicate DAD on link up
From: Cong Wang @ 2017-05-03 22:17 UTC (permalink / raw)
To: David Ahern
Cc: Linux Kernel Network Developers, Dmitry Vyukov, Andrey Konovalov
In-Reply-To: <e8477d7d-3adb-500c-cca1-783cf90872f1@gmail.com>
On Wed, May 3, 2017 at 2:29 PM, David Ahern <dsahern@gmail.com> wrote:
> On 5/3/17 3:22 PM, Cong Wang wrote:
>>> Andrey's reproducer program runs in a very tight loop, calling
>>> 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl
>>> calls. The relevant networking sequence:
>>>
>>> 1. New network namespace created via unshare -n
>>> - ip6tnl0 device is created in down state
>>>
>>> 2. address added to ip6tnl0
>>> - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1
>>> - DAD is started on the address and when it completes the host
>>> route is inserted into the FIB
>>>
>>> 3. ip6tnl0 is brought up
>>> - the new fixup_permanent_addr function restarts DAD on the address
>>>
>>> 4. exit namespace
>>> - teardown / cleanup sequence starts
>>> - once in a blue moon, lo teardown appears to happen BEFORE teardown
>>> of ip6tunl0
>>
>> Why is this possible? Loopback device should be always the first one to
>> register therefore the last one to unregister.
>
> Andrey's config builds in all of the devices. Once in a blue moon I
> would see the host route get deleted b/c 'lo' was taken down.
I am not asking for why ip6tunl0 is there, I am asking about the
order you claimed above, why the teardown of lo is BEFORE ip6tunl0?
Again, lo is the first to register and last to unregister, so any other device
should be teared down before lo.
If you don't trust me, read net/core/dev.c:
/* The loopback device is special if any other network devices
* is present in a network namespace the loopback device must
* be present. Since we now dynamically allocate and free the
* loopback device ensure this invariant is maintained by
* keeping the loopback device as the first device on the
* list of network devices. Ensuring the loopback devices
* is the first device that appears and the last network device
* that disappears.
*/
>>
>> Hmm? But addrconf_ifdown() is called when the device is going from UP
>> to down, how does your patch prevent a duplicated DAD for a device which
>> is going from DOWN to UP in step 3? This is very confusing.
>>
>
> read the sequence:
> 1. ip6tnl0 is in the down state
>
> 2. address is added to ip6tnl0
> DAD starts, completes, inserts host route into FIB
>
> 3. ip6tnl0 is brought up
> DAD starts, completes, inserts host route into FIB
>
> Between 2. and 3. lo is taken down.
By taken down, you mean ifdown, not unregister (aka tear down), right?
But you didn't mention this at all in your original changelog.
If you mean unregister, that means we have a much more serious
problem as I mentioned above.
>
> Since DAD is done for an address in 2, it does not need to be repeated in 3.
>
> The DAD in 3. was meant for addresses kept on an admin down. This patch
> does that.
Again, if you mean unregister above, ip6tunl0 should be unregistered before
lo, therefore 3 is impossible to happen.
^ permalink raw reply
* Fw: [Bug 195647] New: Slab corruption with network packet poison data
From: Stephen Hemminger @ 2017-05-03 22:54 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 03 May 2017 13:37:39 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195647] New: Slab corruption with network packet poison data
https://bugzilla.kernel.org/show_bug.cgi?id=195647
Bug ID: 195647
Summary: Slab corruption with network packet poison data
Product: Networking
Version: 2.5
Kernel Version: 4.11.0-rc8+
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: imre.deak@intel.com
Regression: No
Created attachment 256177
--> https://bugzilla.kernel.org/attachment.cgi?id=256177&action=edit
dmesg
During CI testing on a KBL machine we got the slab corruption below. Not sure
if it's really a network problem or which part of the network stack it would
originate from.
I attached the full dmesg. The poison data without the first 4 bytes looks like
an Ethernet packet containing a DHCP ACK message shown as such by WireShark if
imported as a hex dump.
[ 536.637685]
=============================================================================
[ 536.637703] BUG kmalloc-4096 (Tainted: G U W ): Poison overwritten
[ 536.637714]
-----------------------------------------------------------------------------
[ 536.637730] Disabling lock debugging due to kernel taint
[ 536.637731] INFO: 0xffff880264921198-0xffff8802649212f1. First byte 0x56
instead of 0x6b
[ 536.637740] INFO: Allocated in kernfs_iop_get_link+0x3e/0x1e0 age=4142 cpu=2
pid=9676
[ 536.637748] ___slab_alloc.constprop.28+0x38f/0x3d0
[ 536.637753] __slab_alloc.isra.22.constprop.27+0x43/0x80
[ 536.637758] kmem_cache_alloc_trace+0x237/0x2e0
[ 536.637762] kernfs_iop_get_link+0x3e/0x1e0
[ 536.637768] trailing_symlink+0x1e5/0x230
[ 536.637772] path_lookupat+0x5b/0x100
[ 536.637776] filename_lookup+0xa0/0x120
[ 536.637781] user_path_at_empty+0x31/0x40
[ 536.637785] SyS_faccessat+0xa6/0x210
[ 536.637789] SyS_access+0x13/0x20
[ 536.637793] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 536.637799] INFO: Freed in kfree_link+0x9/0x10 age=4142 cpu=2 pid=9676
[ 536.637804] __slab_free+0x3cb/0x580
[ 536.637808] kfree+0x266/0x2e0
[ 536.637812] kfree_link+0x9/0x10
[ 536.637816] walk_component+0xc4/0x2d0
[ 536.637820] path_lookupat+0x4f/0x100
[ 536.637824] filename_lookup+0xa0/0x120
[ 536.637828] user_path_at_empty+0x31/0x40
[ 536.637833] SyS_faccessat+0xa6/0x210
[ 536.637836] SyS_access+0x13/0x20
[ 536.637840] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 536.637846] INFO: Slab 0xffffea0009924800 objects=7 used=7 fp=0x
(null) flags=0x8000000000008100
[ 536.637854] INFO: Object 0xffff880264921158 @offset=4440
fp=0xffff8802649267e8
[ 536.637863] Redzone ffff880264921150: bb bb bb bb bb bb bb bb
........
[ 536.637870] Object ffff880264921158: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.637877] Object ffff880264921168: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.637885] Object ffff880264921178: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.637892] Object ffff880264921188: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.637899] Object ffff880264921198: 56 01 a9 fe 00 10 60 31 d6 53 68 05 ca
2f 15 dd V.....`1.Sh../..
[ 536.637907] Object ffff8802649211a8: 08 00 45 10 01 48 00 00 00 00 80 11 b6
29 c0 a8 ..E..H.......)..
[ 536.637914] Object ffff8802649211b8: 01 01 c0 a8 01 1a 00 43 00 44 01 34 2d
a0 02 01 .......C.D.4-...
[ 536.637921] Object ffff8802649211c8: 06 00 bf be 60 1b 00 00 00 00 00 00 00
00 c0 a8 ....`...........
[ 536.637929] Object ffff8802649211d8: 01 1a 00 00 00 00 00 00 00 00 00 10 60
31 d6 53 ............`1.S
[ 536.637936] Object ffff8802649211e8: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637943] Object ffff8802649211f8: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637951] Object ffff880264921208: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637958] Object ffff880264921218: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637965] Object ffff880264921228: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637973] Object ffff880264921238: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637980] Object ffff880264921248: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637987] Object ffff880264921258: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.637995] Object ffff880264921268: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.638002] Object ffff880264921278: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.638009] Object ffff880264921288: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.638017] Object ffff880264921298: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 ................
[ 536.638024] Object ffff8802649212a8: 00 00 00 00 00 00 00 00 00 00 63 82 53
63 35 01 ..........c.Sc5.
[ 536.638031] Object ffff8802649212b8: 05 36 04 c0 a8 01 01 33 04 00 00 0e 10
01 04 ff .6.....3........
[ 536.638039] Object ffff8802649212c8: ff ff 00 03 04 c0 a8 01 01 0f 0c 66 69
2e 69 6e ...........fi.in
[ 536.638046] Object ffff8802649212d8: 74 65 6c 2e 63 6f 6d 06 0c 0a f8 02 01
a3 21 fd tel.com.......!.
[ 536.638053] Object ffff8802649212e8: 4c 0a b8 09 09 ff 00 00 00 00 6b 6b 6b
6b 6b 6b L.........kkkkkk
[ 536.638061] Object ffff8802649212f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638068] Object ffff880264921308: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638075] Object ffff880264921318: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638083] Object ffff880264921328: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638090] Object ffff880264921338: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638097] Object ffff880264921348: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638105] Object ffff880264921358: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638112] Object ffff880264921368: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638119] Object ffff880264921378: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638127] Object ffff880264921388: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638134] Object ffff880264921398: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638141] Object ffff8802649213a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638149] Object ffff8802649213b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638156] Object ffff8802649213c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638163] Object ffff8802649213d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638171] Object ffff8802649213e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638178] Object ffff8802649213f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638186] Object ffff880264921408: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638193] Object ffff880264921418: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638200] Object ffff880264921428: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638208] Object ffff880264921438: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638215] Object ffff880264921448: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638222] Object ffff880264921458: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638229] Object ffff880264921468: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638237] Object ffff880264921478: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638244] Object ffff880264921488: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638252] Object ffff880264921498: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638259] Object ffff8802649214a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638266] Object ffff8802649214b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638274] Object ffff8802649214c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638281] Object ffff8802649214d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638288] Object ffff8802649214e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638296] Object ffff8802649214f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638303] Object ffff880264921508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638310] Object ffff880264921518: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638318] Object ffff880264921528: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638325] Object ffff880264921538: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638332] Object ffff880264921548: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638340] Object ffff880264921558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638347] Object ffff880264921568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638354] Object ffff880264921578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638362] Object ffff880264921588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638369] Object ffff880264921598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638376] Object ffff8802649215a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638384] Object ffff8802649215b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638391] Object ffff8802649215c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638398] Object ffff8802649215d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638406] Object ffff8802649215e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638413] Object ffff8802649215f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638420] Object ffff880264921608: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638428] Object ffff880264921618: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638435] Object ffff880264921628: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638443] Object ffff880264921638: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638450] Object ffff880264921648: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638457] Object ffff880264921658: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638465] Object ffff880264921668: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638472] Object ffff880264921678: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638479] Object ffff880264921688: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638487] Object ffff880264921698: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638494] Object ffff8802649216a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638501] Object ffff8802649216b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638509] Object ffff8802649216c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638516] Object ffff8802649216d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638523] Object ffff8802649216e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638531] Object ffff8802649216f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638538] Object ffff880264921708: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638545] Object ffff880264921718: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638553] Object ffff880264921728: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638560] Object ffff880264921738: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638567] Object ffff880264921748: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638574] Object ffff880264921758: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638582] Object ffff880264921768: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638589] Object ffff880264921778: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638597] Object ffff880264921788: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638604] Object ffff880264921798: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638611] Object ffff8802649217a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638619] Object ffff8802649217b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638626] Object ffff8802649217c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638633] Object ffff8802649217d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638640] Object ffff8802649217e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638648] Object ffff8802649217f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638655] Object ffff880264921808: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638662] Object ffff880264921818: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638670] Object ffff880264921828: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638677] Object ffff880264921838: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638684] Object ffff880264921848: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638692] Object ffff880264921858: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638699] Object ffff880264921868: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638707] Object ffff880264921878: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638714] Object ffff880264921888: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638721] Object ffff880264921898: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638729] Object ffff8802649218a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638736] Object ffff8802649218b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638760] Object ffff8802649218c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638768] Object ffff8802649218d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638775] Object ffff8802649218e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638783] Object ffff8802649218f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638790] Object ffff880264921908: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638798] Object ffff880264921918: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638820] Object ffff880264921928: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638827] Object ffff880264921938: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638834] Object ffff880264921948: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638842] Object ffff880264921958: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638849] Object ffff880264921968: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638857] Object ffff880264921978: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638864] Object ffff880264921988: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638871] Object ffff880264921998: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638879] Object ffff8802649219a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638886] Object ffff8802649219b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638893] Object ffff8802649219c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638901] Object ffff8802649219d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638908] Object ffff8802649219e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638915] Object ffff8802649219f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638923] Object ffff880264921a08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638930] Object ffff880264921a18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638937] Object ffff880264921a28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638945] Object ffff880264921a38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638952] Object ffff880264921a48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638959] Object ffff880264921a58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638967] Object ffff880264921a68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638974] Object ffff880264921a78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638981] Object ffff880264921a88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638988] Object ffff880264921a98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.638996] Object ffff880264921aa8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639003] Object ffff880264921ab8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639010] Object ffff880264921ac8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639018] Object ffff880264921ad8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639025] Object ffff880264921ae8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639032] Object ffff880264921af8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639040] Object ffff880264921b08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639047] Object ffff880264921b18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639054] Object ffff880264921b28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639062] Object ffff880264921b38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639069] Object ffff880264921b48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639076] Object ffff880264921b58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639084] Object ffff880264921b68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639091] Object ffff880264921b78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639098] Object ffff880264921b88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639106] Object ffff880264921b98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639113] Object ffff880264921ba8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639120] Object ffff880264921bb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639128] Object ffff880264921bc8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639135] Object ffff880264921bd8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639142] Object ffff880264921be8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639150] Object ffff880264921bf8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639157] Object ffff880264921c08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639164] Object ffff880264921c18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639172] Object ffff880264921c28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639179] Object ffff880264921c38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639186] Object ffff880264921c48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639194] Object ffff880264921c58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639201] Object ffff880264921c68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639208] Object ffff880264921c78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639216] Object ffff880264921c88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639223] Object ffff880264921c98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639230] Object ffff880264921ca8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639238] Object ffff880264921cb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639245] Object ffff880264921cc8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639252] Object ffff880264921cd8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639259] Object ffff880264921ce8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639267] Object ffff880264921cf8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639274] Object ffff880264921d08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639282] Object ffff880264921d18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639289] Object ffff880264921d28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639296] Object ffff880264921d38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639304] Object ffff880264921d48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639311] Object ffff880264921d58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639318] Object ffff880264921d68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639325] Object ffff880264921d78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639333] Object ffff880264921d88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639340] Object ffff880264921d98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639347] Object ffff880264921da8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639355] Object ffff880264921db8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639362] Object ffff880264921dc8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639369] Object ffff880264921dd8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639377] Object ffff880264921de8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639384] Object ffff880264921df8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639391] Object ffff880264921e08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639399] Object ffff880264921e18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639406] Object ffff880264921e28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639413] Object ffff880264921e38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639421] Object ffff880264921e48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639428] Object ffff880264921e58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639435] Object ffff880264921e68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639443] Object ffff880264921e78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639450] Object ffff880264921e88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639457] Object ffff880264921e98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639465] Object ffff880264921ea8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639472] Object ffff880264921eb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639479] Object ffff880264921ec8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639487] Object ffff880264921ed8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639494] Object ffff880264921ee8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639501] Object ffff880264921ef8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639509] Object ffff880264921f08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639516] Object ffff880264921f18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639523] Object ffff880264921f28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639531] Object ffff880264921f38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639538] Object ffff880264921f48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639545] Object ffff880264921f58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639553] Object ffff880264921f68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639560] Object ffff880264921f78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639567] Object ffff880264921f88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639575] Object ffff880264921f98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639582] Object ffff880264921fa8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639589] Object ffff880264921fb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639597] Object ffff880264921fc8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639604] Object ffff880264921fd8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639611] Object ffff880264921fe8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639619] Object ffff880264921ff8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639626] Object ffff880264922008: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639633] Object ffff880264922018: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639641] Object ffff880264922028: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639648] Object ffff880264922038: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639655] Object ffff880264922048: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639663] Object ffff880264922058: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639670] Object ffff880264922068: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639677] Object ffff880264922078: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639685] Object ffff880264922088: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639692] Object ffff880264922098: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639699] Object ffff8802649220a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639707] Object ffff8802649220b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639714] Object ffff8802649220c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639721] Object ffff8802649220d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639729] Object ffff8802649220e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639736] Object ffff8802649220f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639760] Object ffff880264922108: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639768] Object ffff880264922118: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639790] Object ffff880264922128: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639797] Object ffff880264922138: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b kkkkkkkkkkkkkkkk
[ 536.639804] Object ffff880264922148: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b a5 kkkkkkkkkkkkkkk.
[ 536.639812] Redzone ffff880264922158: bb bb bb bb bb bb bb bb
........
[ 536.639819] Padding ffff880264922298: 5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ
[ 536.639826] CPU: 1 PID: 9693 Comm: kms_setmode Tainted: G BU W
4.11.0-rc8-CI-Patchwork_4598+ #1
[ 536.639827] Hardware name: Dell Inc. XPS 13 9360/093TW6, BIOS 1.3.2
01/18/2017
[ 536.639828] Call Trace:
[ 536.639831] dump_stack+0x67/0x92
[ 536.639832] print_trailer+0x14b/0x230
[ 536.639834] check_bytes_and_report+0xc0/0x100
[ 536.639835] check_object+0x261/0x2b0
[ 536.639855] ? __pdp_init.isra.4+0x44/0x90 [i915]
[ 536.639857] alloc_debug_processing+0x199/0x1b0
[ 536.639858] ___slab_alloc.constprop.28+0x38f/0x3d0
[ 536.639871] ? __pdp_init.isra.4+0x44/0x90 [i915]
[ 536.639872] ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[ 536.639874] ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[ 536.639885] ? alloc_pdp+0x3a/0xd0 [i915]
[ 536.639887] ? save_stack.isra.2+0x53/0xa0
[ 536.639899] ? __pdp_init.isra.4+0x44/0x90 [i915]
[ 536.639900] __slab_alloc.isra.22.constprop.27+0x43/0x80
[ 536.639902] ? __slab_alloc.isra.22.constprop.27+0x43/0x80
[ 536.639903] __kmalloc+0x288/0x330
[ 536.639914] __pdp_init.isra.4+0x44/0x90 [i915]
[ 536.639925] alloc_pdp+0x62/0xd0 [i915]
[ 536.639935] gen8_ppgtt_alloc_4lvl+0xba/0x150 [i915]
[ 536.639946] ppgtt_bind_vma+0x2c/0x80 [i915]
[ 536.639959] i915_vma_bind+0xb9/0x240 [i915]
[ 536.639972] __i915_vma_do_pin+0x404/0x6b0 [i915]
[ 536.639983] i915_gem_execbuffer_reserve_vma.isra.9+0xc3/0x240 [i915]
[ 536.639994] i915_gem_execbuffer_reserve.isra.10+0x43e/0x470 [i915]
[ 536.640005] i915_gem_do_execbuffer.isra.16+0x639/0x1b80 [i915]
[ 536.640007] ? __lock_acquire+0x484/0x1ac0
[ 536.640019] i915_gem_execbuffer2+0xb5/0x220 [i915]
[ 536.640021] drm_ioctl+0x1f4/0x480
[ 536.640031] ? i915_gem_execbuffer+0x330/0x330 [i915]
[ 536.640034] do_vfs_ioctl+0x90/0x6e0
[ 536.640035] ? entry_SYSCALL_64_fastpath+0x5/0xb1
[ 536.640038] ? __this_cpu_preempt_check+0x13/0x20
[ 536.640039] ? trace_hardirqs_on_caller+0xe7/0x200
[ 536.640041] SyS_ioctl+0x3c/0x70
[ 536.640042] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 536.640044] RIP: 0033:0x7f002a137357
[ 536.640045] RSP: 002b:00007fffb9318468 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 536.640046] RAX: ffffffffffffffda RBX: ffffffff8147cea3 RCX:
00007f002a137357
[ 536.640047] RDX: 00007fffb9318500 RSI: 0000000040406469 RDI:
0000000000000004
[ 536.640047] RBP: ffffc900003d7f88 R08: 0000000000000008 R09:
0000000000000000
[ 536.640048] R10: 000000000000001f R11: 0000000000000246 R12:
0000000000000000
[ 536.640049] R13: 0000000000000004 R14: 0000000040406469 R15:
0000000000000001
[ 536.640051] ? __this_cpu_preempt_check+0x13/0x20
[ 536.640052] FIX kmalloc-4096: Restoring
0xffff880264921198-0xffff8802649212f1=0x6b
[ 536.640061] FIX kmalloc-4096: Marking all objects used
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH] rtlwifi: fix spelling mistake: "Pairwiase" -> "Pairwise"
From: Colin King @ 2017-05-03 22:55 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo, Joe Perches, Ping-Ke Shih,
linux-wireless
Cc: netdev
From: Colin Ian King <colin.king@canonical.com>
trivial fixes to spelling mistakes in RT_TRACE messages.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
index 6f5098a18655..11d97fa0e921 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
@@ -2506,7 +2506,7 @@ void rtl92ee_set_key(struct ieee80211_hw *hw, u32 key_index,
"add one entry\n");
if (is_pairwise) {
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "set Pairwiase key\n");
+ "set Pairwise key\n");
rtl_cam_add_one_entry(hw, macaddr, key_index,
entry_id, enc_algo,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index 859c045bd37c..513c27be3868 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -2264,7 +2264,7 @@ void rtl8723e_set_key(struct ieee80211_hw *hw, u32 key_index,
"add one entry\n");
if (is_pairwise) {
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "set Pairwiase key\n");
+ "set Pairwise key\n");
rtl_cam_add_one_entry(hw, macaddr, key_index,
entry_id, enc_algo,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 1acbfb86472c..a79f936bb394 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -2637,7 +2637,7 @@ void rtl8723be_set_key(struct ieee80211_hw *hw, u32 key_index,
"add one entry\n");
if (is_pairwise) {
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "set Pairwiase key\n");
+ "set Pairwise key\n");
rtl_cam_add_one_entry(hw, macaddr, key_index,
entry_id, enc_algo,
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 00/15] netvsc: misc patches
From: Stephen Hemminger @ 2017-05-03 23:01 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
Mostly these are performance related. There is also one bug fix for
incorrect handling of NAPI on device removal
Stephen Hemminger (15):
vmbus: simplify hv_ringbuffer_read
vmbus: fix unnecessary signal events as result of NAPI
netvsc: make sure napi enabled before vmbus_open
netvsc: don't reacquire rtnl on device removal
netvsc: optimize avail percent calculation
netvsc: prefetch the first incoming ring element
netvsc: convert ring_size to unsigned
netvsc: allow overriding send/recv buffer size
netvsc: optimize netvsc_send_pkt
netvsc: replace modulus with mask for alignment
netvsc: reduce unnecessary memset
netvsc: size receive completion ring based on receive area
netvsc: convert open count from atomic to refcount
netvsc: optimize receive completions
netvsc: use vzalloc_node for receive completion data
drivers/hv/ring_buffer.c | 179 +++++++++---------------
drivers/net/hyperv/hyperv_net.h | 32 +++--
drivers/net/hyperv/netvsc.c | 282 +++++++++++++++++---------------------
drivers/net/hyperv/netvsc_drv.c | 56 ++++++--
drivers/net/hyperv/rndis_filter.c | 20 +--
include/linux/hyperv.h | 70 +---------
6 files changed, 266 insertions(+), 373 deletions(-)
--
2.11.0
^ 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