From: Rusty Russell <rusty@rustcorp.com.au>
To: Max Krasnyansky <maxk@qualcomm.com>
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, jgarzik@redhat.com
Subject: Re: [PATCH/RFC] New module refcounting for net_proto_family
Date: Mon, 24 Feb 2003 12:01:01 +1100 [thread overview]
Message-ID: <20030224025907.A238F2C091@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 20 Feb 2003 17:17:52 -0800." <5.1.0.14.2.20030220165016.0d47c688@mail1.qualcomm.com>
In message <5.1.0.14.2.20030220165016.0d47c688@mail1.qualcomm.com> you write:
> At 04:30 PM 2/20/2003, Rusty Russell wrote:
> >Yes, but in practical terms it's probably going to fork a child with
> >that socket.
> But it will also be killed.
Once they track it down 8).
> >> >I think it can be argued both ways, honestly.
> >> Yep. And I'd argue in for of module_get() :)
> >
> >My only real insistence in this is that such an interface be called
> >__try_module_get(), because the "__" warn people that it's a "you'd
> >better know *exactly* what you are doing", even though the "try" is a
> >bit of a misnomer.
> Yeah, I think 'try' is definitely be a misnomer in this case.
> How about something like this ?
No, I definitely want the name __try_module_get. Sure, it's a
misnomer in one sense, which will hopefully scare off people looking
for an easy way out. OTOH, it accurately reflects "you should be
using try_module_get but you have special circumstances" more
eloquently than any comment ever would. Especially since there are
only a handful of places where it is appropriate.
I think a CONFIG option for checking is overkill: better is to grep
each kernel for __try_module_get() being added and make sure the damn
thing doesn't spread 8)
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: __try_module_get
Author: Rusty Russell
Status: Trivial
Depends:
D: Introduces __try_module_get for places where we know we already hold
D: a reference and ignoring the fact that the module is being "rmmod --wait"ed
D: is simpler.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .12219-linux-2.5.62-bk3/include/linux/module.h .12219-linux-2.5.62-bk3.updated/include/linux/module.h
--- .12219-linux-2.5.62-bk3/include/linux/module.h 2003-02-21 10:32:28.000000000 +1100
+++ .12219-linux-2.5.62-bk3.updated/include/linux/module.h 2003-02-24 11:46:13.000000000 +1100
@@ -292,17 +292,23 @@ void symbol_put_addr(void *addr);
#define local_dec(x) atomic_dec(x)
#endif
+/* Sometimes we know we already have a refcount, and it's easier not
+ to handle the error case (which only happens with rmmod --wait). */
+static inline void __try_module_get(struct module *module)
+{
+ local_inc(&module->ref[get_cpu()].count);
+ put_cpu();
+}
+
static inline int try_module_get(struct module *module)
{
int ret = 1;
if (module) {
- unsigned int cpu = get_cpu();
if (likely(module_is_live(module)))
- local_inc(&module->ref[cpu].count);
+ __try_module_get(module);
else
ret = 0;
- put_cpu();
}
return ret;
}
@@ -327,6 +332,9 @@ static inline int try_module_get(struct
static inline void module_put(struct module *module)
{
}
+static inline void __try_module_get(struct module *module)
+{
+}
#define symbol_put(x) do { } while(0)
#define symbol_put_addr(p) do { } while(0)
@@ -381,6 +389,10 @@ static inline int module_text_address(un
#define symbol_put(x) do { } while(0)
#define symbol_put_addr(x) do { } while(0)
+static inline void __try_module_get(struct module *module)
+{
+}
+
static inline int try_module_get(struct module *module)
{
return 1;
next prev parent reply other threads:[~2003-02-24 2:48 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
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 [this message]
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=20030224025907.A238F2C091@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=davem@redhat.com \
--cc=jgarzik@redhat.com \
--cc=jt@bougret.hpl.hp.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
/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®