From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from orbyte.nwl.cc ([151.80.46.58]:54030 "EHLO orbyte.nwl.cc"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751531AbeBUHp5 (ORCPT <rfc822;netdev@vger.kernel.org>);
        Wed, 21 Feb 2018 02:45:57 -0500
Date: Wed, 21 Feb 2018 08:45:54 +0100
From: Phil Sutter <phil@nwl.cc>
To: Roman Kapl <code@rkapl.cz>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
        Jiri Pirko <jiri@resnulli.us>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Benc <jbenc@redhat.com>
Subject: Re: [PATCH v2] sched: report if filter is too large to dump
Message-ID: <20180221074554.GE4196@orbyte.nwl.cc>
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: <netdev.vger.kernel.org>

Hi Roman,

On Mon, Feb 19, 2018 at 09:32:51PM +0100, Roman Kapl 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

I'm curious, what does it lead to? :)

Thanks, Phil