From: Max Krasnyansky <maxk@qualcomm.com>
To: linux-kernel@vger.kernel.org
Cc: davem@redhat.com
Subject: Re: [PATCH/RFC] New module refcounting for net_proto_family
Date: 19 Dec 2002 08:05:28 -0800 [thread overview]
Message-ID: <1040313919.2650.31.camel@localhost> (raw)
In-Reply-To: <1040225146.1873.21.camel@localhost>
Hmm, no replies. Nobody is interested in this or what ?
I want to get this fixed otherwise I can't fix Bluetooth module
refcounting.
Max
On Wed, 2002-12-18 at 07:25, Max Krasnyansky wrote:
> Hi Folks,
>
> It seems that new module code is going to stay with us at least for a
> while :).
> So it's probably time to start fixing old interfaces to use new
> refcounting scheme.
>
> Here is a patch for sock_create() and stuff that uses net_proto_family
> interface. Tested with modified af_bluetooth.c and seems to work fine.
> Other families are unaffected for now because their owner field == NULL.
>
> If people are ok with this aproach I will also fix af_unix and other
> families and push all fixes into my BK tree.
>
> (URL in case if my mailer messed up spaces
> http://bluez.sourceforge.net/patches/npf_refcnt_patch-2.5.52.gz)
>
>
> # This is a BitKeeper generated patch for the following project:
> # Project Name: Linux kernel tree
> # This patch format is intended for GNU patch command version 2.5 or
> higher.
> # This patch includes the following deltas:
> # ChangeSet 1.888 -> 1.889
> # net/socket.c 1.39 -> 1.40
> # include/linux/net.h 1.7 -> 1.8
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 02/12/17 maxk@qualcomm.com 1.889
> # Convert generic socket code to new module refcounting.
> # --------------------------------------------
> #
> diff -Nru a/include/linux/net.h b/include/linux/net.h
> --- a/include/linux/net.h Tue Dec 17 20:02:04 2002
> +++ b/include/linux/net.h Tue Dec 17 20:02:04 2002
> @@ -76,6 +76,8 @@
>
> short type;
> unsigned char passcred;
> +
> + struct module *owner;
> };
>
> struct scm_cookie;
> @@ -124,6 +126,8 @@
> short authentication;
> short encryption;
> short encrypt_net;
> +
> + struct module *owner;
> };
>
> struct net_proto
> diff -Nru a/net/socket.c b/net/socket.c
> --- a/net/socket.c Tue Dec 17 20:02:04 2002
> +++ b/net/socket.c Tue Dec 17 20:02:04 2002
> @@ -470,6 +470,8 @@
>
> sock = SOCKET_I(inode);
>
> + sock->owner = NULL;
> +
> inode->i_mode = S_IFSOCK|S_IRWXUGO;
> inode->i_sock = 1;
> inode->i_uid = current->fsuid;
> @@ -517,6 +519,8 @@
> return;
> }
> sock->file=NULL;
> +
> + module_put(sock->owner);
> }
>
> static int __sock_sendmsg(struct kiocb *iocb, struct socket *sock,
> struct msghdr *msg, int size)
> @@ -964,8 +968,9 @@
>
> int sock_create(int family, int type, int protocol, struct socket
> **res)
> {
> - int i;
> + struct net_proto_family *npf;
> struct socket *sock;
> + int err;
>
> /*
> * Check protocol is in range
> @@ -990,14 +995,8 @@
> }
>
> #if defined(CONFIG_KMOD) && defined(CONFIG_NET)
> - /* Attempt to load a protocol module if the find failed.
> - *
> - * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
> - * requested real, full-featured networking support upon
> configuration.
> - * Otherwise module support will break!
> - */
> - if (net_families[family]==NULL)
> - {
> + /* Attempt to load a protocol module if the find failed. */
> + if (net_families[family]==NULL) {
> char module_name[30];
> sprintf(module_name,"net-pf-%d",family);
> request_module(module_name);
> @@ -1005,29 +1004,31 @@
> #endif
>
> net_family_read_lock();
> - if (net_families[family] == NULL) {
> - i = -EAFNOSUPPORT;
> +
> + npf = net_families[family];
> + if (!npf || !try_module_get(npf->owner)) {
> + err = -EAFNOSUPPORT;
> goto out;
> }
> +
> + /*
> + * Allocate the socket and allow the family to set things up. if
> + * the protocol is 0, the family is instructed to select an
> appropriate
> + * default.
> + */
>
> -/*
> - * Allocate the socket and allow the family to set things up. if
> - * the protocol is 0, the family is instructed to select an appropriate
> - * default.
> - */
> -
> - if (!(sock = sock_alloc()))
> - {
> + sock = sock_alloc();
> + if (!sock) {
> printk(KERN_WARNING "socket: no more sockets\n");
> - i = -ENFILE; /* Not exactly a match, but its the
> + err = -ENFILE; /* Not exactly a match, but its the
> closest posix thing */
> goto out;
> }
>
> sock->type = type;
> + sock->owner = npf->owner;
>
> - if ((i = net_families[family]->create(sock, protocol)) < 0)
> - {
> + if ((err = npf->create(sock, protocol)) < 0) {
> sock_release(sock);
> goto out;
> }
> @@ -1036,7 +1037,7 @@
>
> out:
> net_family_read_unlock();
> - return i;
> + return err;
> }
>
> asmlinkage long sys_socket(int family, int type, int protocol)
> @@ -1201,6 +1202,9 @@
> newsock->type = sock->type;
> newsock->ops = sock->ops;
>
> + 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;
--
Max Krasnyansky <maxk@qualcomm.com>
Qualcomm
next prev parent reply other threads:[~2002-12-19 18:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-18 15:25 [PATCH/RFC] New module refcounting for net_proto_family Max Krasnyansky
2002-12-19 16:05 ` Max Krasnyansky [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2002-12-19 23:08 Jean Tourrilhes
2002-12-19 23:23 ` Max Krasnyansky
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
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
2003-02-20 17:52 Max Krasnyansky
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=1040313919.2650.31.camel@localhost \
--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 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.