From: Max Krasnyansky <maxk@qualcomm.com>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] New module refcounting for net_proto_family
Date: Tue, 21 Jan 2003 11:42:41 -0800 [thread overview]
Message-ID: <5.1.0.14.2.20030121102804.073b3198@mail1.qualcomm.com> (raw)
In-Reply-To: <20030121.030314.41949353.davem@redhat.com>
At 03:03 AM 1/21/2003 -0800, David S. Miller wrote:
> From: Max Krasnyansky <maxk@qualcomm.com>
> Date: Sun, 19 Jan 2003 19:22:44 -0800 (PST)
>
> The only reason to do module refcounting in sk is if protocol
> changes default callbacks (i.e. sk->data_ready, etc).
>
>What about the reference to skb->sk? Are you sure there are
>no cases where:
>
>1) skb->sk will be non-NULL
>2) default callbacks are used
In that case we don't care whether the module is still loaded or not.
Here is the list of sk callbacks
void (*state_change)(struct sock *sk);
void (*data_ready)(struct sock *sk, int bytes);
void (*write_space)(struct sock *sk);
void (*error_report)(struct sock *sk);
int (*backlog_rcv) (struct sock *sk, struct sk_buff *skb);
void (*destruct)(struct sock *sk);
Net core doesn't make any other calls into the protocol module.
In any case if protocol module wants, for some reason, to be around until sk is destroyed
it can call sk_set_owner() right after sk_alloc(), even if it uses default callbacks.
While looking at the net families that we support I realized that there is one more reason
why protocol may have to call sk_set_owner(). Is if protocol uses private slab cache for its
sks. Otherwise cache will be destroyed during module unloading but sk may still be alive.
Here is a little summary about families that I looked at:
Netlink - Global sk cache, replaces sk->destruct() callback.
Must call sk_set_owner()
Unix - Private sk cache, replaces sk->destruct() and sk->write_space() callbacks
Must call sk_set_owner()
IPv4/6 - Private cache, non-default callbacks.
Must call sk_set_owner() (cannot be a module, so we don't really care)
IPX - Global cache, default callbacks.
ATM - Global cache, default callbacks.
IRDA - Global cache, default callbacks.
Bluetooth - Private cache (don't really need it, will change to global), non-default callbacks
Must call sk_set_owner()
AX25 - Global cache, non-default sk->destroy()
Must call sk_set_owner()
Rose - Global cache, default callbacks.
DecNet - Private cache, non-default callbacks.
Must call sk_set_owner()
LLC - Global cache, default callbacks.
Max
next prev parent reply other threads:[~2003-01-21 19:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-26 8:11 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 [this message]
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
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.20030121102804.073b3198@mail1.qualcomm.com \
--to=maxk@qualcomm.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®