netdev - Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.

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: <4857A58E.6080304@trash.net>
Date:	Tue, 17 Jun 2008 13:52:46 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Julius Volz <juliusv@...gle.com>
CC:	Simon Horman <horms@...ge.net.au>, Vince Busam <vbusam@...gle.com>,
	Ben Greear <greearb@...delatech.com>,
	lvs-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.

Julius Volz wrote:
> On Mon, Jun 16, 2008 at 1:47 PM, Patrick McHardy <kaber@...sh.net> wrote:
>>> Option c) looks reasonable to me and also seems easy to handle in
>>> general. Is this the way to go? Or do we want the interface to look
>>> completely different this time?
>> b) or c) both look fine.
> 
> A couple of other Netlink questions came up while reading some code:
> 
> 1) There are many examples of the following two cases in the kernel:
> 
> nla_nest_start(skb, SOME_ATTR_TYPE | NLA_F_NESTED);
> nla_nest_start(skb, SOME_ATTR_TYPE);
> 
> Why don't all cases have NLA_F_NESTED? Then again, this bit is never
> ever read out again (at least not in the kernel), so I guess people
> are just using their implicit knowledge that a specific attribute type
> is always nested and never check the bit?
>
> Btw., couldn't we change nla_nest_start() to always add NLA_F_NESTED
> to the type?

The NLA_F_NESTED bit originated in nfnetlink, but was moved
to netlink so the new netlink parsing helpers could also be
used for nfnetlink. It can't be added to existing attributes
since userspace needs to mask it out again to get the real
attribute value and the non-nfnetlink userspace code doesn't
expect it.

> 2) To send an array of attributes of the same type, you just add them
> serially? I was just confused at first that nla_parse() will save only
> one attribute of each type (the last one) in the destination array, so
> when dealing with arrays, it doesn't help. So I just iterate over the
> array with nla_for_each_attr() and parse each element manually, right?

Exactly, net/8021q/vlan_netlink.c has two examples of this (the
QoS mapping attributes).
--
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