From: Patrick McHardy <kaber@trash.net>
To: Luciano Coelho <luciano.coelho@nokia.com>
Cc: ext Jan Engelhardt <jengelh@medozas.de>,
"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 12:07:16 +0200 [thread overview]
Message-ID: <4C10B954.9080603@trash.net> (raw)
In-Reply-To: <1276108939.11199.23.camel@powerslave>
Luciano Coelho 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.
>
Why don't you simply use a mutex instead of the spinlock? It would be better
to only do the lookup once and store the timer pointer in the target
structure
anyways.
next prev parent reply other threads:[~2010-06-10 10:07 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
2010-06-09 21:05 ` Jan Engelhardt
2010-06-09 21:28 ` Luciano Coelho
2010-06-10 10:07 ` Patrick McHardy [this message]
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=4C10B954.9080603@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=luciano.coelho@nokia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).