mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®