lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c857c5c7-9d65-dda1-cfba-6f4f66251cd9@virtuozzo.com>
Date:   Sat, 4 Sep 2021 20:23:22 +0300
From:   Vasily Averin <vvs@...tuozzo.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Hao Sun <sunhao.th@...il.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: WARNING in sk_stream_kill_queues

On 9/4/21 8:14 PM, Eric Dumazet wrote:
> 
> 
> On 9/4/21 7:48 AM, Vasily Averin wrote:
> 
>> Eric,
>> this problem is not related to my patches.
>> I've reproduced the problem locally on orignal kernel with original config,
>> then I've applied last version of my patch -- but it did not help, issue was reproduced again,
>> then I've reverted all my patches, see lest below -- and reproduced the problem once again
>>
>> Thank you,
>> 	Vasily Averin
>>
>> b8a0bb68ac30 (HEAD -> net-next-5.15) Revert "ipv6: allocate enough headroom in ip6_finish_output2()"
>> 1bc2de674a1b Revert "ipv6: ip6_finish_output2: set sk into newly allocated nskb"
>> 780e2f7d9b93 Revert "skbuff: introduce skb_expand_head()"
>> 782eaeed9de7 Revert "ipv6: use skb_expand_head in ip6_finish_output2"
>> 639e9842fc1f Revert "ipv6: use skb_expand_head in ip6_xmit"
>> 3b16ee164bcd Revert "ipv4: use skb_expand_head in ip_finish_output2"
>> ab48caf0e632 Revert "vrf: use skb_expand_head in vrf_finish_output"
>> 4da67a72ceef Revert "ax25: use skb_expand_head"
>> 9b113a8a62f0 Revert "bpf: use skb_expand_head in bpf_out_neigh_v4/6"
>> fc4ab503ce8f Revert "vrf: fix NULL dereference in vrf_finish_output()"
>>
> 
> OK, thanks for checking.
> 
> The repro on my host does not trigger the issue, I can not really investigate/bisect.

I"ve recompiled kernel with original config,
It was booted very slowly, ~10 minutes,
then reproducer worked a quite long time,
node was crashed in 3000-4000 seconds uptime.

Thank you,
	Vasily Averin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ