From: Luciano Coelho <luciano.coelho@nokia.com>
To: ext Jan Engelhardt <jengelh@medozas.de>
Cc: ext Patrick McHardy <kaber@trash.net>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Timo Teras <timo.teras@iki.fi>
Subject: Re: [PATCH v3] netfilter: Xtables: idletimer target implementation
Date: Thu, 10 Jun 2010 00:00:12 +0300 [thread overview]
Message-ID: <1276117212.11199.25.camel@powerslave> (raw)
In-Reply-To: <1276108939.11199.23.camel@powerslave>
On Wed, 2010-06-09 at 20:42 +0200, Coelho Luciano (Nokia-D/Helsinki)
wrote:
> On Wed, 2010-06-09 at 19:48 +0200, Coelho Luciano (Nokia-D/Helsinki)
> wrote:
> > On Wed, 2010-06-09 at 17:18 +0200, ext Jan Engelhardt wrote:
> > > >> > + timer = __idletimer_tg_find_by_label(info->label);
> > > >> > + if (!timer) {
> > > >> > + spin_unlock(&list_lock);
> > > >> > + timer = idletimer_tg_create(info);
> > > >> >
> > > >>
> > > >> How does this prevent creating the same timer twice?
> > > >
> > > >The timer will only be created if __idletimer_tg_find_by_label() returns
> > > >NULL, which means that no timer with that label has been found. "info"
> > > >won't be the same if info->label is different, right? Or can it change
> > > >on the fly?
> > >
> > > One thing to be generally aware about is that things could potentially
> > > be instantiated by another entity between the time a label was looked up
> > > with negative result and the time one tries to add it.
> > > It may thus be required to extend keeping the lock until after
> > > idletimer_tg_create, in other words, lookup and create must be atomic
> > > to the rest of the world.
> >
> > Ahh, sure! I missed the actual point of Patrick's question. I had the
> > idletimer_tg_create() inside the lock, but when I added the
> > sysfs_create_file() there (which can sleep), I screwed up with the
> > locking.
> >
> > I'll move the sysfs file creation to outside that function so I can keep
> > the lock until after the timer is added to the list. Thanks for
> > clarifying!
>
> Hmmm... after struggling with this for a while, I think it's not really
> possible to simply create the sysfs file outside of the lock, because if
> the sysfs creation fails, we will again risk a race condition.
>
> I think the only way is to delay the sysfs file creation and do it in a
> workqueue.
Okay, I think I found a way to do it without using an extra workqueue.
The patch is ready, but I still want to run some tests before sending it
out.
--
Cheers,
Luca.
next prev parent reply other threads:[~2010-06-09 21:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-03 19:14 [PATCH v3] netfilter: Xtables: idletimer target implementation luciano.coelho
2010-06-09 13:00 ` Luciano Coelho
2010-06-09 13:45 ` Patrick McHardy
2010-06-09 15:11 ` Luciano Coelho
2010-06-09 15:18 ` Jan Engelhardt
2010-06-09 17:48 ` Luciano Coelho
2010-06-09 18:42 ` Luciano Coelho
2010-06-09 21:00 ` Luciano Coelho [this message]
2010-06-09 21:05 ` Jan Engelhardt
2010-06-09 21:28 ` Luciano Coelho
2010-06-10 10:07 ` Patrick McHardy
2010-06-10 12:42 ` Luciano Coelho
2010-06-10 13:32 ` Luciano Coelho
2010-06-10 15:55 ` Jan Engelhardt
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=1276117212.11199.25.camel@powerslave \
--to=luciano.coelho@nokia.com \
--cc=jengelh@medozas.de \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=timo.teras@iki.fi \
/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.