From: Andrew Morton <akpm@digeo.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: cmm@us.ibm.com, manfred@colorfullife.com,
linux-kernel@vger.kernel.org, dipankar@in.ibm.com,
lse-tech@lists.sourceforge.net
Subject: Re: [PATCH]updated ipc lock patch
Date: Thu, 24 Oct 2002 16:30:32 -0700 [thread overview]
Message-ID: <3DB88298.735FD044@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44.0210242342460.1169-100000@localhost.localdomain
Hugh Dickins wrote:
>
> ...
> Manfred and I have both reviewed the patch (or the 2.5.44 version)
> and we both recommend it highly (well, let Manfred speak for himself).
>
OK, thanks.
So I took a look. Wish I hadn't :( The locking rules in there
are outrageously uncommented. You must be brave people.
What about this code?
void ipc_rcu_free(void* ptr, int size)
{
struct rcu_ipc_free* arg;
arg = (struct rcu_ipc_free *) kmalloc(sizeof(*arg), GFP_KERNEL);
if (arg == NULL)
return;
arg->ptr = ptr;
arg->size = size;
call_rcu(&arg->rcu_head, ipc_free_callback, arg);
}
Are we sure that it's never called under locks?
And it seems that if the kmalloc fails, we decide to leak some
memory, yes?
If so it would be better to use GFP_ATOMIC there. Avoids any
locking problems and also increases the chance of the allocation
succeeding. (With an explanatory comment, naturally :)).
Even better: is it possible to embed the rcu_ipc_free inside the
object-to-be-freed? Perhaps not?
Stylistically, it is best to not typecast the return value
from kmalloc, btw. You should never typecast the return
value of anything which returns a void *, because it weakens
your compile-time checking. Example:
foo *bar = (foo *)zot();
The compiler will swallow that, regardless of what zot() returns.
Someone could go and change zot() to return a reiserfs_inode *
and you would never know about it. Whereas:
foo *bar = zot();
Says to the compiler "zot() must return a bar * or a void *",
which is much tighter checking, yes?
There is an insane amount of inlining in the ipc code. I
couldn't keep my paws off it.
Before:
mnm:/usr/src/25> size ipc/*.o
text data bss dec hex filename
28346 224 192 28762 705a ipc/built-in.o
7390 20 64 7474 1d32 ipc/msg.o
11236 16 64 11316 2c34 ipc/sem.o
8136 160 64 8360 20a8 ipc/shm.o
1584 0 0 1584 630 ipc/util.o
After:
mnm:/usr/src/25> size ipc/*.o
text data bss dec hex filename
19274 224 192 19690 4cea ipc/built-in.o
4846 20 64 4930 1342 ipc/msg.o
7636 16 64 7716 1e24 ipc/sem.o
4808 160 64 5032 13a8 ipc/shm.o
1984 0 0 1984 7c0 ipc/util.o
--- 25/ipc/util.h~ipc-akpm Thu Oct 24 16:03:32 2002
+++ 25-akpm/ipc/util.h Thu Oct 24 16:08:25 2002
@@ -54,63 +54,11 @@ void* ipc_alloc(int size);
void ipc_free(void* ptr, int size);
void ipc_rcu_free(void* arg, int size);
-extern inline struct kern_ipc_perm* ipc_get(struct ipc_ids* ids, int id)
-{
- struct kern_ipc_perm* out;
- int lid = id % SEQ_MULTIPLIER;
- if(lid >= ids->size)
- return NULL;
- rmb();
- out = ids->entries[lid].p;
- return out;
-}
-
-extern inline struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id)
-{
- struct kern_ipc_perm* out;
- int lid = id % SEQ_MULTIPLIER;
-
- rcu_read_lock();
- if(lid >= ids->size) {
- rcu_read_unlock();
- return NULL;
- }
- rmb();
- out = ids->entries[lid].p;
- if(out == NULL) {
- rcu_read_unlock();
- return NULL;
- }
- spin_lock(&out->lock);
-
- /* ipc_rmid() may have already freed the ID while ipc_lock
- * was spinning: here verify that the structure is still valid
- */
- if (out->deleted) {
- spin_unlock(&out->lock);
- rcu_read_unlock();
- return NULL;
- }
- return out;
-}
-
-extern inline void ipc_unlock(struct kern_ipc_perm* perm)
-{
- spin_unlock(&perm->lock);
- rcu_read_unlock();
-}
-
-extern inline int ipc_buildid(struct ipc_ids* ids, int id, int seq)
-{
- return SEQ_MULTIPLIER*seq + id;
-}
-
-extern inline int ipc_checkid(struct ipc_ids* ids, struct kern_ipc_perm* ipcp, int uid)
-{
- if(uid/SEQ_MULTIPLIER != ipcp->seq)
- return 1;
- return 0;
-}
+struct kern_ipc_perm* ipc_get(struct ipc_ids* ids, int id);
+struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id);
+void ipc_unlock(struct kern_ipc_perm* perm);
+int ipc_buildid(struct ipc_ids* ids, int id, int seq);
+int ipc_checkid(struct ipc_ids* ids, struct kern_ipc_perm* ipcp, int uid);
void kernel_to_ipc64_perm(struct kern_ipc_perm *in, struct ipc64_perm *out);
void ipc64_perm_to_ipc_perm(struct ipc64_perm *in, struct ipc_perm *out);
--- 25/ipc/util.c~ipc-akpm Thu Oct 24 16:07:07 2002
+++ 25-akpm/ipc/util.c Thu Oct 24 16:07:51 2002
@@ -359,6 +359,61 @@ void ipc64_perm_to_ipc_perm (struct ipc6
out->seq = in->seq;
}
+struct kern_ipc_perm* ipc_get(struct ipc_ids* ids, int id)
+{
+ struct kern_ipc_perm* out;
+ int lid = id % SEQ_MULTIPLIER;
+ if(lid >= ids->size)
+ return NULL;
+ rmb();
+ out = ids->entries[lid].p;
+ return out;
+}
+
+struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id)
+{
+ struct kern_ipc_perm* out;
+ int lid = id % SEQ_MULTIPLIER;
+
+ rcu_read_lock();
+ if(lid >= ids->size)
+ goto fail;
+ rmb();
+ out = ids->entries[lid].p;
+ if (out == NULL)
+ goto fail;
+ spin_lock(&out->lock);
+
+ /* ipc_rmid() may have already freed the ID while ipc_lock
+ * was spinning: here verify that the structure is still valid
+ */
+ if (!out->deleted)
+ return out;
+
+ spin_unlock(&out->lock);
+fail:
+ rcu_read_unlock();
+ return NULL;
+}
+
+void ipc_unlock(struct kern_ipc_perm* perm)
+{
+ spin_unlock(&perm->lock);
+ rcu_read_unlock();
+}
+
+int ipc_buildid(struct ipc_ids* ids, int id, int seq)
+{
+ return SEQ_MULTIPLIER*seq + id;
+}
+
+int ipc_checkid(struct ipc_ids* ids, struct kern_ipc_perm* ipcp, int uid)
+{
+ if(uid/SEQ_MULTIPLIER != ipcp->seq)
+ return 1;
+ return 0;
+}
+
#ifndef __ia64__
/**
.
next prev parent reply other threads:[~2002-10-24 23:24 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-18 0:14 [PATCH]IPC locks breaking down with RCU mingming cao
2002-10-20 13:14 ` Hugh Dickins
2002-10-20 17:27 ` Hugh Dickins
2002-10-21 18:11 ` mingming cao
2002-10-21 19:00 ` Hugh Dickins
2002-10-24 21:49 ` [PATCH]updated ipc lock patch mingming cao
2002-10-24 22:29 ` Andrew Morton
2002-10-24 22:56 ` Hugh Dickins
2002-10-24 23:30 ` Andrew Morton [this message]
2002-10-24 23:59 ` Hugh Dickins
2002-10-25 0:35 ` [Lse-tech] " Rick Lindsley
2002-10-25 1:07 ` Robert Love
2002-10-25 0:07 ` mingming cao
2002-10-25 0:24 ` Andrew Morton
2002-10-25 4:18 ` Rusty Russell
2002-10-25 5:53 ` mingming cao
2002-10-25 7:27 ` Rusty Russell
2002-10-25 5:36 ` Manfred Spraul
2002-10-25 16:53 ` Rik van Riel
2002-10-24 23:23 ` mingming cao
2002-10-25 14:21 ` [Lse-tech] " Paul Larson
2002-10-25 17:17 ` mingming cao
2002-10-25 18:20 ` Paul Larson
2002-10-25 18:51 ` mingming cao
2002-10-25 19:06 ` Paul Larson
2002-10-25 20:14 ` mingming cao
2002-10-25 20:23 ` Manfred Spraul
2002-10-25 0:38 ` Cliff White
2002-10-31 17:52 ` [Lse-tech] Re: [PATCH]updated ipc lock patch [PERFORMANCE RESULTS] Bill Hartner
2002-10-21 19:18 ` [PATCH]IPC locks breaking down with RCU Dipankar Sarma
2002-10-21 19:36 ` Hugh Dickins
2002-10-21 19:41 ` mingming cao
2002-10-21 20:14 ` Dipankar Sarma
2002-10-21 18:07 ` mingming cao
-- strict thread matches above, loose matches on Subject: below --
2002-10-25 17:20 [PATCH]updated ipc lock patch Cliff White
[not found] <Pine.LNX.4.44.0210270748560.1704-100000@localhost.localdomain>
2002-10-28 1:06 ` Rusty Russell
2002-10-28 14:21 ` Hugh Dickins
2002-10-28 21:47 ` Rusty Russell
2002-10-29 0:26 ` Hugh Dickins
2002-10-29 2:51 ` Rusty Russell
2002-10-28 20:00 ` Dipankar Sarma
2002-10-28 21:41 ` Rusty Russell
2002-10-29 6:11 ` Dipankar Sarma
2002-10-28 22:07 ` mingming cao
2002-10-29 1:06 ` Rusty Russell
2002-10-28 1:15 Rusty Russell
2002-10-28 1:35 ` Davide Libenzi
2002-10-28 4:10 ` Rusty Russell
2002-10-28 17:08 ` Davide Libenzi
2002-10-28 22:39 ` Rusty Russell
2002-10-28 23:52 ` Davide Libenzi
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=3DB88298.735FD044@digeo.com \
--to=akpm@digeo.com \
--cc=cmm@us.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=manfred@colorfullife.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 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.