From: Max Krasnyansky <maxk@qualcomm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: "David S. Miller" <davem@redhat.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Jean Tourrilhes <jt@bougret.hpl.hp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] New module refcounting for net_proto_family
Date: Wed, 19 Feb 2003 09:45:59 -0800 [thread overview]
Message-ID: <5.1.0.14.2.20030219092611.0d0d00c8@mail1.qualcomm.com> (raw)
In-Reply-To: <20030219035559.7527A2C079@lists.samba.org>
At 07:54 PM 2/18/2003, Rusty Russell wrote:
>In message <5.1.0.14.2.20030218101309.048d4288@mail1.qualcomm.com> you write:
>> At 07:46 PM 2/17/2003, David S. Miller wrote:
>>
>> >After talking to Alexey, I don't like this patch.
>> >
>> >The new module subsystem was supposed to deal with things
>> >like this cleanly, and this patch is merely a hack to cover
>> >up for it's shortcomings.
>
>I don't quite understand.
>
>There are some issue with this patch, however.
>
>Firstly, the owner field should probably be in struct proto_ops not
>struct socket, where the function pointers are.
struct proto_ops doesn't exists on its own without struct socket.
I think it make sense to simply keep track of the sockets but I don't
see any problem with putting it in proto_ops.
struct sock is different though. callbacks are inside.
>The sk thing looks reasonable at first glance. Getting a reference to
>npf->owner, then holding it for the socket is a little confusing, but
>an obvious optimization over a naive "get, use, drop, get".
That was an optimization indeed. There is no point in dropping reference
there.
>In sys_accept:
>
>> @@ -1196,9 +1198,13 @@
>> if (!(newsock = sock_alloc()))
>> goto out_put;
>>
>> - newsock->type = sock->type;
>> - newsock->ops = sock->ops;
>> + newsock->type = sock->type;
>> + newsock->ops = sock->ops;
>> + newsock->owner = sock->owner;
>>
>> + try_module_get(sock->owner);
>> + newsock->owner = sock->owner;
>> +
>> err = sock->ops->accept(sock, newsock, sock->file->f_flags);
>> if (err < 0)
>> goto out_release;
>
>You still need to check the result of try_module_get, and fail if it
>fails. The *only* time this will fail is when someone is doing an
>"rmmod --wait" on the module, which presumably means they really do
>not want you to increase the reference count furthur.
Ohh, I see. My assumption here was that we know for sure
that module is alive at this point since we already hold a reference to the
first socket. Actually I was going to send another email and ask for unconditional
module_get() specifically for the cases like that.
Even after your explanation I still think we need unconditional module_get() there.
Because in this case 'rmmod --wait' will simply brake accept() logic. I mean it'll
keep waiting until listening socket is destroyed (i.e. until socket app is killed)
but accept() will mysteriously fail for no good reason.
Comments ?
Max
next prev parent reply other threads:[~2003-02-19 17:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-26 8:11 [PATCH/RFC] New module refcounting for net_proto_family Max Krasnyansky
2003-01-02 11:43 ` Max Krasnyansky
2003-01-03 8:24 ` David S. Miller
2003-01-20 3:22 ` Max Krasnyansky
2003-01-21 11:03 ` David S. Miller
2003-01-21 19:42 ` Max Krasnyansky
2003-01-21 19:36 ` David S. Miller
2003-02-07 9:48 ` David S. Miller
2003-02-07 23:34 ` Max Krasnyansky
2003-02-08 8:44 ` David S. Miller
2003-02-18 3:46 ` David S. Miller
2003-02-18 18:50 ` Max Krasnyansky
2003-02-18 21:09 ` Jean Tourrilhes
2003-02-19 3:54 ` Rusty Russell
2003-02-19 7:04 ` David S. Miller
2003-02-19 18:03 ` Max Krasnyansky
2003-02-19 20:31 ` Roman Zippel
2003-02-19 17:45 ` Max Krasnyansky [this message]
2003-02-20 1:21 ` Rusty Russell
2003-02-20 17:38 ` Max Krasnyansky
2003-02-21 0:30 ` Rusty Russell
2003-02-21 1:17 ` Max Krasnyansky
2003-02-21 8:45 ` Christoph Hellwig
2003-02-21 17:44 ` Max Krasnyansky
2003-02-24 1:01 ` Rusty Russell
2003-02-24 19:35 ` Max Krasnyansky
2003-02-25 5:02 ` Rusty Russell
2003-02-26 20:21 ` Max Krasnyansky
2003-01-07 9:21 ` David S. Miller
2003-01-09 20:45 ` Max Krasnyansky
2003-01-09 23:53 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2003-02-20 17:52 Max Krasnyansky
2002-12-19 23:08 Jean Tourrilhes
2002-12-19 23:23 ` Max Krasnyansky
2002-12-18 15:25 Max Krasnyansky
2002-12-19 16:05 ` Max Krasnyansky
2002-12-19 19:28 ` Alan Cox
2002-12-19 19:12 ` David S. Miller
2002-12-19 22:17 ` Max Krasnyansky
2002-12-21 6:54 ` David S. Miller
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=5.1.0.14.2.20030219092611.0d0d00c8@mail1.qualcomm.com \
--to=maxk@qualcomm.com \
--cc=davem@redhat.com \
--cc=jt@bougret.hpl.hp.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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).