From: Jeremy Sowden <jeremy@azazel.net>
To: Jan Engelhardt <jengelh@inai.de>
Cc: "Grzegorz Kuczyński" <grzegorz.kuczynski@interia.eu>,
netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] xtables-addons 3.18 condition - Improved network namespace support
Date: Sun, 22 Aug 2021 12:50:41 +0100 [thread overview]
Message-ID: <YSI6ESSy9ScNsuWE@azazel.net> (raw)
In-Reply-To: <7q54s2p2-7o57-3rq-9012-np5o3sr1s416@vanv.qr>
[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]
On 2021-08-22, at 13:19:46 +0200, Jan Engelhardt wrote:
> On Friday 2021-08-20 20:24, Grzegorz Kuczyński wrote:
> > A few years ago I add network namespace to extension condition.
> > I review this changes again and make changes again.
> > This is better version.
>
> It does not apply. Your mail software mangled the patch.
>
> I would also wish for a more precise description what causes
> these lines to need removal.
>
> >- if (cnet->after_clear)
> >- return;
>
> >- if (--var->refcount == 0) {
> >+ if (--var->refcount == 0 && !list_empty_careful(&cnet->conditions_list)) {
I've been looking at this, and I don't think it works.
The idea is to do away with a separate flag whose purpose is to indicate
that condition_mt_destroy is being called during the tear-down of a
name-space.
Currently we have:
static void __net_exit condition_net_exit(struct net *net)
{
struct condition_net *condition_net = condition_pernet(net);
struct list_head *pos, *q;
struct condition_variable *var = NULL;
remove_proc_subtree(dir_name, net->proc_net);
mutex_lock(&proc_lock);
list_for_each_safe(pos, q, &condition_net->conditions_list) {
var = list_entry(pos, struct condition_variable, list);
list_del(pos);
kfree(var);
}
mutex_unlock(&proc_lock);
condition_net->after_clear = true;
}
and:
static void condition_mt_destroy(const struct xt_mtdtor_param *par)
{
const struct xt_condition_mtinfo *info = par->matchinfo;
struct condition_variable *var = info->condvar;
struct condition_net *cnet = condition_pernet(par->net);
if (cnet->after_clear)
return;
mutex_lock(&proc_lock);
if (--var->refcount == 0) {
list_del(&var->list);
remove_proc_entry(var->name, cnet->proc_net_condition);
mutex_unlock(&proc_lock);
kfree(var);
return;
}
mutex_unlock(&proc_lock);
}
Since pernet_operations destructors are called in the reverse of the
order in which they are registered, the destructor for xt_condition will
be called before the destructor for the table which deletes all the
rules. The `after_clear` flag serves to indicate during the call of
condition_mt_destroy that condition_net_exit has already been called and
freed all the variables. Replacing it with a check whether list of
variables is empty could work, but not after we've checked the ref-count
of a variable that we have already freed. Based on what I've seen in
other modules, I'd be more inclined to do something like this:
static void __net_exit condition_net_exit(struct net *net)
{
struct condition_net *condition_net = condition_pernet(net);
remove_proc_subtree(dir_name, net->proc_net);
condition_net->proc_net_condition = NULL;
}
and:
static void condition_mt_destroy(const struct xt_mtdtor_param *par)
{
const struct xt_condition_mtinfo *info = par->matchinfo;
struct condition_variable *var = info->condvar;
struct condition_net *cnet = condition_pernet(par->net);
mutex_lock(&proc_lock);
if (--var->refcount == 0) {
list_del(&var->list);
if (condition_net->proc_net_condition)
remove_proc_entry(var->name, cnet->proc_net_condition);
kfree(var);
}
mutex_unlock(&proc_lock);
}
J.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-08-22 11:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 18:24 [PATCH] xtables-addons 3.18 condition - Improved network namespace support Grzegorz Kuczyński
2021-08-22 11:19 ` Jan Engelhardt
2021-08-22 11:50 ` Jeremy Sowden [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-08-22 16:14 Grzegorz Kuczyński
2021-08-22 16:34 ` Jeremy Sowden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YSI6ESSy9ScNsuWE@azazel.net \
--to=jeremy@azazel.net \
--cc=grzegorz.kuczynski@interia.eu \
--cc=jengelh@inai.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.