From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:53428 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbeBUC6N (ORCPT ); Tue, 20 Feb 2018 21:58:13 -0500 Date: Tue, 20 Feb 2018 21:58:09 -0500 (EST) Message-Id: <20180220.215809.1929486406284619867.davem@davemloft.net> To: code@rkapl.cz Cc: netdev@vger.kernel.org, jiri@resnulli.us, xiyou.wangcong@gmail.com, jbenc@redhat.com Subject: Re: [PATCH v2] sched: report if filter is too large to dump From: David Miller In-Reply-To: <20180219203251.30273-1-code@rkapl.cz> References: <20180219203251.30273-1-code@rkapl.cz> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Roman Kapl Date: Mon, 19 Feb 2018 21:32:51 +0100 > So far, if the filter was too large to fit in the allocated skb, the > kernel did not return any error and stopped dumping. Modify the dumper > so that it returns -EMSGSIZE when a filter fails to dump and it is the > first filter in the skb. If we are not first, we will get a next chance > with more room. > > I understand this is pretty near to being an API change, but the > original design (silent truncation) can be considered a bug. > > Note: The error case can happen pretty easily if you create a filter > with 32 actions and have 4kb pages. Also recent versions of iproute try > to be clever with their buffer allocation size, which in turn leads to > > Signed-off-by: Roman Kapl Applied and queued up for -stable, thanks Roman.