From: Juha Heljoranta <juha.heljoranta@evtek.fi>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [rfc] ipt_owner.c improvements
Date: Wed, 09 Mar 2005 14:59:06 +0200 [thread overview]
Message-ID: <422EF31A.3060904@evtek.fi> (raw)
In-Reply-To: <4228F0DD.7030307@trash.net>
Patrick McHardy wrote:
> Juha Heljoranta wrote:
>
>> I'd like to make few improvements to ipt_owner.c or perhaps to create
>> something new that is like owner match.
>>
>> First I'd like to improve performance for incoming packet matches. The
>> next thing is to reliably identify sending/receiving process. Last
>> proposal is to improve performance when matching is done several times
>> per packet.
>
>
> As Dave Miller pointed out, the only sensible thing to do is add new
> hooks to the protocols themselves, anything else is racy. The main
> challenges are making sure incoming connections using protocols that
> support sockets aren't confirmed before they survived the socket
> hooks, with all possible module combinations, and possibly hooks for
> outgoing packets, I haven't thought about that very much.
I've been skimming through the code and concluded that the fastest and
most reliable way to find a task receiving packet is to copy
sock_def_readable and modify it to fit into job.
I'm not exactly sure what you mean by adding new hooks to protocols but
I think that the this could be it (the hook for tcp and udp). Right?
I don't expect any race conditions to exist (famous last words) because
all what we are performing is just crippled version of sock_def_readable.
As I stated before sunrpc¸ samba, bluetooth, x25, etc. reassign callback
functions which means that things _might_ not work as expected when
using them. Any way, I think that this is separate issue, we are not
trying to find tasks that use samba but task that use tcp or udp, right?
To get an idea what will happen when modified version of
sock_def_readable is issued (simplified and no locking):
void foo(struct sock *sk)
{
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) {
list_for_each_safe(tmp, next,
&sk->sk_sleep->task_list) {
...
}
}
/* for finding SIGIO targets */
bar(sk->sk_socket->fasync_list)
}
void bar(struct fasync_struct *fa)
{
while (fa) {
baz(&fa->fa_file->f_owner);
fa = fa->fa_next;
}
}
void baz(struct fown_struct *fown)
{
pid = fown->pid;
if (pid > 0) {
p = find_task_by_pid(pid);
if (p)
...
} else {
do_each_task_pid(-pid, PIDTYPE_PGID, p) {
...
} while_each_task_pid(-pid, PIDTYPE_PGID, p);
}
}
There is still case of multicast to deal with (locate all receiving
struck sock *sk and issue foo(sk) for each).
Regards,
Juha Heljoranta
prev parent reply other threads:[~2005-03-09 12:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-04 1:25 [rfc] ipt_owner.c improvements Juha Heljoranta
2005-03-04 23:35 ` Patrick McHardy
2005-03-09 12:59 ` Juha Heljoranta [this message]
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=422EF31A.3060904@evtek.fi \
--to=juha.heljoranta@evtek.fi \
--cc=kaber@trash.net \
--cc=netfilter-devel@lists.netfilter.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.