netdev - Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpWUzWyPZyDyVFLhOb5peVMp5Y4OeBxfSzuKY5bnF5Z02Q@mail.gmail.com>
Date:   Mon, 18 May 2020 11:50:05 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Vlad Buslov <vladbu@...lanox.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Davide Caratti <dcaratti@...hat.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump mode

On Mon, May 18, 2020 at 8:38 AM Edward Cree <ecree@...arflare.com> wrote:
>
> On 15/05/2020 12:40, Vlad Buslov wrote:
> > In order to
> > significantly improve filter dump rate this patch sets implement new
> > mode of TC filter dump operation named "terse dump" mode. In this mode
> > only parameters necessary to identify the filter (handle, action cookie,
> > etc.) and data that can change during filter lifecycle (filter flags,
> > action stats, etc.) are preserved in dump output while everything else
> > is omitted.
> I realise I'm a bit late, but isn't this the kind of policy that shouldn't
>  be hard-coded in the kernel?  I.e. if next year it turns out that some
>  user needs one parameter that's been omitted here, but not the whole dump,
>  are they going to want to add another mode to the uapi?
> Should this not instead have been done as a set of flags to specify which
>  pieces of information the caller wanted in the dump, rather than a mode
>  flag selecting a pre-defined set?

Excellent point!

I agree, this is more elegant, although potentially needs more work.

I am not sure whether we can simply pass those flags to cb->args[],
if not, that will need more work at netlink layer.

Thanks.