From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752227AbcAFQu0 (ORCPT ); Wed, 6 Jan 2016 11:50:26 -0500 Received: from vulcan.natalenko.name ([104.207.131.136]:11632 "EHLO vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751572AbcAFQuX (ORCPT ); Wed, 6 Jan 2016 11:50:23 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 vulcan.natalenko.name 563F173F7B Authentication-Results: vulcan.natalenko.name; dmarc=none header.from=natalenko.name User-Agent: K-9 Mail for Android In-Reply-To: References: <26396443.iDTTxgChSj@spock> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [REGRESSION] tcp/ipv4: kernel panic because of (possible) division by zero From: Oleksandr Natalenko Date: Wed, 06 Jan 2016 18:50:24 +0200 To: Yuchung Cheng CC: netdev , "linux-kernel@vger.kernel.org" , Patrick McHardy , Hideaki YOSHIFUJI , James Morris , Alexey Kuznetsov , "David S. Miller" Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Unfortunately, the patch didn't help -- I've got the same stacktrace with slightly different offset (+3) within the function. Now trying to get full stacktrace via netconsole. Need more time. Meanwhile, any other ideas on what went wrong? On December 22, 2015 4:10:32 AM EET, Yuchung Cheng wrote: >On Mon, Dec 21, 2015 at 12:25 PM, Oleksandr Natalenko > wrote: >> Commit 3759824da87b30ce7a35b4873b62b0ba38905ef5 (tcp: PRR uses CRB >mode by >> default and SS mode conditionally) introduced changes to >net/ipv4/tcp_input.c >> tcp_cwnd_reduction() that, possibly, cause division by zero, and >therefore, >> kernel panic in interrupt handler [1]. >> >> Reverting 3759824da87b30ce7a35b4873b62b0ba38905ef5 seems to fix the >issue. >> >> I'm able to reproduce the issue on 4.3.0–4.3.3 once per several day >> (occasionally). >> >> What could be done to help in debugging this issue? >Do you have ECN enabled (i.e. sysctl net.ipv4.tcp_ecn > 0)? > >If so I suspect an ACK carrying ECE during CA_Loss causes entering CWR >state w/o calling tcp_init_cwnd_reduct() to set tp->prior_cwnd. Can >you try this debug / quick-fix patch and send me the error message if >any? > > >> >> Regards, >> Oleksandr. >> >> [1] http://i.piccy.info/ >> >i9/6f5cb187c4ff282d189f78c63f95af43/1450729403/283985/951663/panic.jpg -- Sent from my Android device with K-9 Mail. Please excuse my brevity.