On Tue, Mar 22, 2016 at 08:46:25PM +0100, Carlos Falgueras García wrote:
> diff --git a/src/rule.c b/src/rule.c
> index 3a32bf6..db96e5b 100644
> --- a/src/rule.c
> +++ b/src/rule.c
> @@ -28,6 +28,7 @@
>  #include <libnftnl/rule.h>
>  #include <libnftnl/set.h>
>  #include <libnftnl/expr.h>
> +#include <libnftnl/udata.h>
>  
>  struct nftnl_rule {
>       struct list_head head;
> @@ -38,10 +39,7 @@ struct nftnl_rule {
>       const char      *chain;
>       uint64_t        handle;
>       uint64_t        position;
> -     struct {
> -                     void            *data;
> -                     uint32_t        len;
> -     } user;
> +     struct nftnl_udata_buf  *userdata;

This change, we don't need it, see below.

> @@ -162,8 +171,14 @@ void nftnl_rule_set_data(struct nftnl_rule *r, uint16_t 
> attr,
>               r->position = *((uint64_t *)data);
>               break;
>       case NFTNL_RULE_USERDATA:
> -             r->user.data = (void *)data;
> -             r->user.len = data_len;
> +             if (r->flags & (1 << NFTNL_RULE_USERDATA))
> +                     nftnl_udata_buf_free(r->userdata);
> +             r->userdata = nftnl_udata_buf_alloc(data_len);
> +             if (!r->userdata) {
> +                     perror("nftnl_rule_set_data - userdata");
> +                     return;
> +             }
> +             nftnl_udata_buf_put(r->userdata, data, data_len);

Think about this: From nft, we allocate the udata_buf, then we add the
attributes. Once we have the TLV area ready, we pass it as a pointer
via nftnl_rule_set_data().

Then, from libnftnl you allocate nftnl_udata_buf_alloc() again, but we
actually don't need this. The reason is that udata_buf is *only*
needed to build the sequence of TLVs. Once we're done with it, we can
just pass the memory blob area that contains this info.

For this reason, I'm entirely keeping back this patch.

Good thing though is that we don't need it to get this working :-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to