From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com ([209.85.128.193]:43681 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228AbeBTKtm (ORCPT ); Tue, 20 Feb 2018 05:49:42 -0500 Received: by mail-wr0-f193.google.com with SMTP id u49so8356529wrc.10 for ; Tue, 20 Feb 2018 02:49:41 -0800 (PST) Date: Tue, 20 Feb 2018 11:49:40 +0100 From: Jiri Pirko To: Roman Kapl Cc: netdev@vger.kernel.org, "David S . Miller" , Cong Wang , Jiri Benc Subject: Re: [PATCH v2] sched: report if filter is too large to dump Message-ID: <20180220104940.GB2031@nanopsycho> References: <20180219203251.30273-1-code@rkapl.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180219203251.30273-1-code@rkapl.cz> Sender: netdev-owner@vger.kernel.org List-ID: Mon, Feb 19, 2018 at 09:32:51PM CET, code@rkapl.cz wrote: >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 Acked-by: Jiri Pirko