From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7906821F4E3 for ; Tue, 3 Nov 2015 03:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446551150; bh=NMN4wiJLbwpSwlHj3+X/w3ZNI19zvpFhTYtQp1WVnpg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=gzpKw2mSjteE+JvZzAAVQJPKNPUsVWthY07OPmqquE13GEH6EDUU3uzgu8kPh8NUK XRsT0X+PzAp1u6suxTotNz+NPIgaarUoknC72yezmZ1sAhZo4wsJw2Fo8tyDhOBNQC gcE47SR4Yy8oNgybryCxLmk+VrDLHb/m046/2TgQ= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 85CDCC402A1; Tue, 3 Nov 2015 12:45:49 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87pozspckj.fsf@toke.dk> <6A2609D9-7747-487B-9484-ECC69C50DE96@gmx.de> <56388CA4.7000308@darbyshire-bryant.me.uk> <355718FB-BE85-4C53-BE85-48367A62B923@gmx.de> Date: Tue, 03 Nov 2015 12:45:49 +0100 In-Reply-To: <355718FB-BE85-4C53-BE85-48367A62B923@gmx.de> (Sebastian Moeller's message of "Tue, 3 Nov 2015 12:08:15 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878u6fpaqa.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Long-RTT broken again X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 11:46:16 -0000 Sebastian Moeller writes: >> BUG_ON I put in the category of "Never test for a condition you don't >> know how to handle" ;-) Now that the off-by-one has been stomped on I'm >> going to stick my neck out and say that bin_cnt > 8 implies something >> has stomped on our config structure and we really shouldn't be trusting >> anything in it. Goodness knows what our skb queues are like...and err, >> help! Also note that the correctly written BUG_ON didn't explode for >> many months. > > Well, not my call, but I have seen discussions on LKML about > this topic with the general gist that a BUG_ON needs to be > justified, and only be there is the situation is not > salvageable. After all we take down a whole machine that might > be doing something really really important... The right thing to do would be to reject the netlink request and not change anything. -Toke