On 10/26/2011 05:36 AM, Stefan Berger wrote:
> Use the previously introduced chain priorities to sort the chains for access
> from an interface's 'root' table and have them created in the proper order.
> This gets rid of a lot of code that was previously creating the chains in a
> more hardcoded way.
>
> To determine what protocol a filter is used for evaluation do prefix-
> matching, i.e., the filter 'arp' is used to filter for the 'arp' protocol,
> 'ipv4' for the 'ipv4' protocol and 'arp-xyz' will also be used to filter
> for the 'arp' protocol following the prefix 'arp' in its name.
>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx>
>
> ---
> src/nwfilter/nwfilter_ebiptables_driver.c | 130 ++++++++++++++++++++++--------
> 1 file changed, 98 insertions(+), 32 deletions(-)
>
>
> +static int
> +ebiptablesFilterOrderSort(const virHashKeyValuePairPtr a,
> + const virHashKeyValuePairPtr b)
> +{
> + return *(virNWFilterChainPriority *)a->value -
> + *(virNWFilterChainPriority *)b->value;
> +}
I tend to worry about someone passing INT_MAX and INT_MIN to a qsort
algorithm, then getting the wrong comparison sense because of integer
overflow when it uses straight subtraction; so I like to add a comment
explaining why I know that the valid input was capped and overflow is
impossible.
>
> static void
> iptablesCheckBridgeNFCallEnabled(bool isIPv6)
> @@ -3327,6 +3336,56 @@ iptablesCheckBridgeNFCallEnabled(bool is
> }
> }
>
> +/*
> + * Given a filtername determine the protocol it is used for evaluating
> + * We do prefix-matching to determine the protocol.
> + */
> +static enum l3_proto_idx
> +ebtablesGetProtoIdxByFiltername(const char *filtername)
> +{
> + enum l3_proto_idx idx;
> +
> + for (idx = 0; idx < L3_PROTO_LAST_IDX; idx++) {
> + if (STRPREFIX(filtername, l3_protocols[idx].val)) {
> + return idx;
> + }
> + }
This works as long as none of the entries in l3_protocols are a prefix
of any other entry; is it worth a comment at the declaration of
l3_protocols warning about this assumption for when new protocol names
are added to the table?
> +
> + return -1;
> +}
> +
> +static int
> +ebtablesCreateTmpRootAndSubChains(virBufferPtr buf,
> + const char *ifname,
> + virHashTablePtr chains, int direction)
> +{
> + int rc = 0, i;
> +
> + if (virHashSize(chains) != 0) {
> + char **filter_names;
> +
> + ebtablesCreateTmpRootChain(buf, direction, ifname, 1);
> + filter_names = (char **)virHashGetKeys(chains,
> + ebiptablesFilterOrderSort);
This area of code will be impacted by my comments on 1/10.
> + if (filter_names == NULL) {
> + virReportOOMError();
Your implementation of virHashGetKeys already reported OOM error for all
error paths except for numElems < 0; but that means that this call to
virReportOOMError() is either redundant (a second report), or misleading
(if numElems < 0, you are not OOM, but have a programming bug on hand
for passing in an invalid hash table in the first place).
> + rc = 1;
Can we get this updated to use -1 for failures, so that there's less to
clean up later when we fix this file to match libvirt conventions?
> + goto err_exit;
> + }
> + for (i = 0; filter_names[i]; i++) {
> + enum l3_proto_idx idx = ebtablesGetProtoIdxByFiltername(
> + filter_names[i]);
> + if ((int)idx < 0)
> + continue;
> + ebtablesCreateTmpSubChain(buf, direction, ifname, idx,
> + filter_names[i], 1);
> + }
> + virHashFreeKeys(chains, (void **)filter_names);
Oh, this reminds me of some additional feedback I meant to give on 1/10
- as part of the documentation you add, be sure to mention that the
returned array is only valid as long as the underlying hash table is not
modified (especially if you alter things to return in-hash pointers
rather than cloning keys) - adding or removing elements, or deleting the
hash table, will invalidate the returned key array.
> @@ -3337,24 +3396,43 @@ ebiptablesApplyNewRules(virConnectPtr co
> int i;
> int cli_status;
> ebiptablesRuleInstPtr *inst = (ebiptablesRuleInstPtr *)_inst;
> - int chains_in = 0, chains_out = 0;
> virBuffer buf = VIR_BUFFER_INITIALIZER;
> + virHashTablePtr chains_in_set = virHashCreate(10, NULL),
> + chains_out_set = virHashCreate(10, NULL);
Style-wise, I would list this as two declarations separated by ';',
rather than one declaration of two variables separated by ','. That is,
I find it slightly hard to read stacked declarations that involve
multi-argument function calls as the initializers.
If patch 1/10 were used as-is, then this patch looks good except for a
few easy-to-fix nits. But more likely, this will also need a v5 due to
rebasing on top of changes to how you grab a sorted list of hash keys
(or key-value pairs).
--
Eric Blake eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list