linux-kernel - Re: linux-next: build failure after merge of the ida tree

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] [day] [month] [year] [list]

Message-ID: <20180718142500.5ltqff7ajwmwidhp@salvia>
Date:   Wed, 18 Jul 2018 16:25:00 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        NetFilter <netfilter-devel@...r.kernel.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Varsha Rao <rvarsha016@...il.com>
Subject: Re: linux-next: build failure after merge of the ida tree

On Wed, Jul 18, 2018 at 06:31:26AM -0700, Matthew Wilcox wrote:
> On Wed, Jul 18, 2018 at 03:27:46PM +0200, Pablo Neira Ayuso wrote:
> > On Wed, Jul 18, 2018 at 06:14:46AM -0700, Matthew Wilcox wrote:
> > > So Varsha, if you would like to take a look at transforming table->sets
> > > from a LIST_HEAD to an IDR, I think that would be a great use of your
> > > time.
> > 
> > Please, don't do so, we don't need a radix tree datastructure, it's
> > just more complexity.
> 
> It's no more complex to use than the list_* macros.

Problem is that some of the sets that we place in that list may have
no ID.

We basically have two type of sets:

* Sets with names, they have no IDs as the user provides a meaningful
  name from the control plane that can be used to add/delete elements,
  eg. IP addresses.

* Anonymous sets, these are built-in into rules, eg.

  ip saddr { 1.1.1.1, 2.2.2.2 }

  so we generate an ID that we can use to refer to the set.

For our usecase, I'm thinking, if we don't have a simple way to
allocate IDs through this API, we could just simplify our existing
codebase by using an u64 and use incremental id, we don't need to
recycle IDs, so that's one posibility I stop bothering you ;-)

BTW, the anti-pattern we have in our codebase is the same logic that we
have to allocate identifiers with netdevice name, see __dev_alloc_name()
in net/core/dev.c. *Someone* copied + pasted + mangled that original code
to make it fit into netfilter. I guess that code may benefit from a
simple way to allocate IDs without locking dependencies. Just an idea,
not that this is a priority.

Thanks!