From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
laijs@cn.fujitsu.com
Subject: Re: [RFC, PATCH] kernel/rcu: add kfree_rcu
Date: Sat, 3 Jan 2009 15:46:37 -0800 [thread overview]
Message-ID: <20090103234637.GD6958@linux.vnet.ibm.com> (raw)
In-Reply-To: <495F7D5C.3060905@colorfullife.com>
On Sat, Jan 03, 2009 at 03:59:40PM +0100, Manfred Spraul wrote:
> Paul E. McKenney wrote:
>> I would suggest instead using the bottom bit to differentiate between
>> these two cases, especially given that your approach makes it impossible
>> for callback processing to notice a NULL function pointer. In addition,
>> this approach would allow different types of allocators to be specified
>> should this later prove to be helpful. You should not have to shift the
>> offset because the rcu_head offset should always be a multiple of four
>> (or eight on 64-bit architectures).
>>
> We must be careful: rcu_head might be always aligned, but are function
> pointers always aligned?
> The x86 hardware allows arbitrary function pointers, I'm not sure what gcc
> would do if '--falign-functions=0' is used.
> Are there other codepaths that assume that the lowest bit of a function
> pointer is never set?
Good point. I guess that we will have to worry about expandability when
and if the need arises. I see a couple of ways of doing it, but they
are pretty ugly...
>> And we really are running into bugs that are detected by RCU's seeing a
>> null function pointer in the rcu_head structure at callback-invocation
>> time. So, whatever encoding you choose, please leave a function-pointer
>> value of zero as an invalid value!
>>
> Ok.
>
>>> --- a/kernel/rcutree.c
>>> +++ b/kernel/rcutree.c
>>> @@ -901,7 +901,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
>>> while (list) {
>>> next = list->next;
>>> prefetch(next);
>>> - list->func(list);
>>> + rcu_docallback(list);
>>>
>>
>> Good, you got all three of them! ;-)
>>
>>
> The patch was tested against rcutree ;-)
;-)
Thanx, Paul
next prev parent reply other threads:[~2009-01-03 23:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-02 11:25 [RFC, PATCH] kernel/rcu: add kfree_rcu Manfred Spraul
2009-01-02 18:55 ` Paul E. McKenney
2009-01-03 14:59 ` Manfred Spraul
2009-01-03 23:46 ` Paul E. McKenney [this message]
2009-01-04 5:50 ` Lai Jiangshan
2009-01-04 19:48 ` Paul E. McKenney
2009-01-05 2:48 ` Lai Jiangshan
2009-01-05 4:40 ` Paul E. McKenney
2009-01-06 22:17 ` Paul E. McKenney
2009-01-05 7:15 ` Manfred Spraul
2009-01-04 5:39 ` Lai Jiangshan
2009-01-04 7:07 ` Manfred Spraul
2009-01-04 8:30 ` Lai Jiangshan
2009-01-04 12:22 ` Manfred Spraul
2009-01-04 20:06 ` Paul E. McKenney
2009-01-12 17:43 ` Paul E. McKenney
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=20090103234637.GD6958@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--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.