netdev - Re: [PATCH net-next 1/4] rtnetlink: Link address family API

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: <20101117.113035.229752488.davem@davemloft.net>
Date:	Wed, 17 Nov 2010 11:30:35 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	tgraf@...radead.org
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/4] rtnetlink: Link address family API

From: Thomas Graf <tgraf@...radead.org>
Date: Tue, 16 Nov 2010 09:30:14 -0500

> Each net_device contains address family specific data such as
> per device settings and statistics. We already expose this data
> via procfs/sysfs and partially netlink.
> 
> The netlink method requires the requester to send one RTM_GETLINK
> request for each address family it wishes to receive data of
> and then merge this data itself.
> 
> This patch implements a new API which combines all address family
> specific link data in a new netlink attribute IFLA_AF_SPEC.
> IFLA_AF_SPEC contains a sequence of nested attributes, one for each
> address family which in turn defines the structure of its own
> attribute. Example:
> 
>    [IFLA_AF_SPEC] = {
>        [AF_INET] = {
>            [IFLA_INET_CONF] = ...,
>        },
>        [AF_INET6] = {
>            [IFLA_INET6_FLAGS] = ...,
>            [IFLA_INET6_CONF] = ...,
>        }
>    }
> 
> The API also allows for address families to implement a function
> which parses the IFLA_AF_SPEC attribute sent by userspace to
> implement address family specific link options.
> 
> Signed-off-by: Thomas Graf <tgraf@...radead.org>

Applied, but note that as-implemented it has the "partial update"
problem.  When we can't get the af-specific ops for a "parse"
operation, we just skip that AF yet we let the modifications of
the other AF's succeed and make it appear to the user that
everything got updated and all the attributes were consumed.

I don't know what we can do about this with how things work
right now.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html