On Thu, 12 Feb 2015 12:52:02 +0100
Florian Westphal <fw@xxxxxxxxx> wrote:
> Florian Westphal <fw@xxxxxxxxx> wrote:
> > I'll see if we can fix this in a better way.
>
> What about this, it will transparently grow the table as needed,
> we simply have to take the lock and make sure we zap all existing
> entries (needed since those entries don't have enough room for
> the larger nstamp_mask entry count)?
>
> diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
> --- a/net/netfilter/xt_recent.c
> +++ b/net/netfilter/xt_recent.c
> @@ -378,12 +378,11 @@ static int recent_mt_check(const struct
> xt_mtchk_param *par, mutex_lock(&recent_mutex);
> t = recent_table_lookup(recent_net, info->name);
> if (t != NULL) {
> - if (info->hit_count > t->nstamps_max_mask) {
> - pr_info("hitcount (%u) is larger than packets to be remembered (%u) for table %s\n",
> - info->hit_count, t->nstamps_max_mask + 1,
> - info->name);
> - ret = -EINVAL;
> - goto out;
> + if (nstamp_mask > t->nstamps_max_mask) {
> + spin_lock_bh(&recent_lock);
> + recent_table_flush(t);
> + t->nstamps_max_mask = nstamp_mask;
> + spin_unlock_bh(&recent_lock);
> }
>
> t->refcnt++;
I don't know your code but forgive me for asking one thing. The
previous versions of this code (both in the 3.18 and 3.19 kernels)
checked the value of hit_count for sanity. This patch seems to be doing
something different, and I note that nstamps_max_mask is
unconditionally set later in recent_mt_check() anyway.
Can the check for the value of hit_count simply be omitted? In what
circumstances can it be anything other than true?
Chris
--
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
