From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E96C83B29E for ; Tue, 8 Jan 2019 16:30:56 -0500 (EST) Received: from localhost (unknown [66.187.232.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id DAD3814CCA989; Tue, 8 Jan 2019 13:30:54 -0800 (PST) Date: Tue, 08 Jan 2019 13:30:53 -0800 (PST) Message-Id: <20190108.133053.2049686690825668341.davem@davemloft.net> To: toke@toke.dk Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net From: David Miller In-Reply-To: <20190107194733.31138-1-toke@toke.dk> References: <20190107194733.31138-1-toke@toke.dk> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 08 Jan 2019 13:30:55 -0800 (PST) Subject: Re: [Cake] [PATCH 0/4] sched: Fix qdisc interactions exposed by using sch_cake as a leaf qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 08 Jan 2019 21:30:57 -0000 From: Toke H=F8iland-J=F8rgensen Date: Mon, 7 Jan 2019 20:47:29 +0100 > This series fixes a couple of issues exposed by running sch_cake as a= > leaf qdisc in an HFSC tree, which were discovered and reported by Pet= e > Heist. The interaction between CAKE's GSO splitting and the parent > qdisc's notion of its own queue length could cause queue stalls. Whil= e > investigating the report, I also noticed that several qdiscs would > dereference the skb pointer after dequeue, which is potentially > problematic since the GSO splitting code also frees the original skb.= > = > See the individual patches in the series for details. Toke, can you please resubmit this without patch #3. If you want to push for patch #3 still, it is much easier to submit it separately.