From: Patrick McHardy <kaber@trash.net>
To: Changli Gao <xiaosuo@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 3/3] nfnetlink_queue: use hash table to speed up entry finding.
Date: Thu, 15 Apr 2010 16:40:50 +0200 [thread overview]
Message-ID: <4BC72572.1050507@trash.net> (raw)
In-Reply-To: <t2t412e6f7f1004150735l54619e32t3e7fcdce7b118bd9@mail.gmail.com>
Changli Gao wrote:
> On Thu, Apr 15, 2010 at 6:36 PM, Patrick McHardy <kaber@trash.net> wrote:
>> Changli Gao wrote:
>>> On Tue, Apr 13, 2010 at 9:25 PM, Patrick McHardy <kaber@trash.net> wrote:
>>>>> Yes, that is why vmalloc() is perfect for this case. No extra memory for
>>>>> management, but one pointer for each page of memory.
>>>> I agree, if it works for conntrack, it certainly also works for
>>>> nfnetlink_queue.
>>>>
>>> I need to allocate memory in atomic section, so vmalloc() can't be used. :(
>> Why?
>>
>
> instance_create() is called in rcu read-side critical section, and the
> whole body of this function is protected by the spinlock
> instances_lock. All these make memory allocation for queue instances
> should be atomic.
That should be easily fixable. For the lookup we can add a reference
counter so we don't need the rcu read side critical section.
For creation the lock actually looks unnecessary since all nfnetlink
handlers run under nfnl_mutex, so we can't have concurrent creation
and removal of queuing instances. Well, we need it for list insertion
to avoid races with the seq file handlers, but we don't need it
before that.
next prev parent reply other threads:[~2010-04-15 14:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 4:13 [PATCH 3/3] nfnetlink_queue: use hash table to speed up entry finding Changli Gao
2010-04-09 4:50 ` Eric Dumazet
2010-04-13 10:09 ` Patrick McHardy
2010-04-13 11:06 ` Changli Gao
2010-04-13 12:44 ` Eric Dumazet
2010-04-13 13:02 ` Changli Gao
2010-04-13 13:09 ` Changli Gao
2010-04-13 13:23 ` Eric Dumazet
2010-04-13 13:25 ` Patrick McHardy
2010-04-15 6:53 ` Changli Gao
2010-04-15 8:23 ` Eric Dumazet
2010-04-15 8:30 ` Changli Gao
2010-04-15 10:36 ` Patrick McHardy
2010-04-15 14:35 ` Changli Gao
2010-04-15 14:40 ` Patrick McHardy [this message]
2010-04-15 14:46 ` Patrick McHardy
2010-04-15 15:01 ` Changli Gao
2010-04-15 15:05 ` Patrick McHardy
2010-04-15 15:11 ` Changli Gao
2010-04-15 15:35 ` Patrick McHardy
2010-04-16 13:50 ` Changli Gao
2010-04-16 15:30 ` Patrick McHardy
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=4BC72572.1050507@trash.net \
--to=kaber@trash.net \
--cc=eric.dumazet@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=xiaosuo@gmail.com \
/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).