2018-04-30 3:03 GMT+09:00 Florian Westphal <fw@xxxxxxxxx>:
> Taehee Yoo <ap420073@xxxxxxxxx> wrote:
>> This patch adds the new release callback to release resources
>> allocated in nft_expr_type->select_ops.
>> This release callback can be used by error path in the
>> nf_tables_newrule routine.
>> Only the select_ops of the nft_compat.c allocates memory and holds
>> modules so far.
>
> Wouldn't it be simpler to just add the missing nft_xt_put()
> in nft_target_init()?
>
Thank you for your review!
I think the putting nft_xt_put() into the nft_{target/match}_init() can't solve
the below problem scenario.
Below is what I experienced scenario.
Before:
$rmmod nft_counter
Steps to reproduce:
$iptables-compat -I OUTPUT -m cpu --cpu 0
When above command is given, a netlink message has two
experssions that are the cpu compat and the nft_counter.
The nft_expr_type_get() in the nf_tables_expr_parse() successes
first expression then, calls select_ops callback.
(allocates memory and holds module)
But, second nft_expr_type_get() in the nf_tables_expr_parse()
returns -EAGAIN because of request_module().
In that point, by the 'goto err1',
the 'module_put(info[i].ops->type->owner)' is called.
There is no release routine.
If the nft_xt_put() is added into the nft_{target/match}_init(),
above scenario still can't be solved.
In order to reproduce above scenario, the nft_counter should be unloaded.
In the second patch, you said that you can't reproduce this problem.
If the nft_counter is unloaded, you can reproduce this problem.
Could you please test this?
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
