linux-kernel - Re: WARNING in sk_stream_kill

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]

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