From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] markers: bit-field is not thread-safe nor smp-safe
Date: Fri, 10 Oct 2008 03:31:36 -0400 [thread overview]
Message-ID: <20081010073136.GC23247@Krystal> (raw)
In-Reply-To: <48EEF9AD.9040401@cn.fujitsu.com>
* Lai Jiangshan (laijs@cn.fujitsu.com) wrote:
>
> bit-field is not thread-safe nor smp-safe.
>
> struct marker_entry.rcu_pending is not protected by any lock
> in rcu-callback free_old_closure().
> so we must turn it into a safe type.
>
hrm, yes, you are right. I first test for
if (entry->rcu_pending)
rcu_barrier_sched();
To check if I must execute the rcu callback, and _this_ races against
the entry->rcu_pending = 0; within the callback.
Your fix is therefore needed.
Thanks !
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> detail:
>
> I suppose rcu_pending and ptype are store in struct marker_entry.tmp1
>
> free_old_closure() side: change ptype side:
>
> | load struct marker_entry.tmp1
> --------------------------------|--------------------------------
> | change ptype bit in tmp1
> load struct marker_entry.tmp1 |
> change rcu_pending bit in tmp1 |
> store tmp1 |
> --------------------------------|--------------------------------
> | store tmp1
>
> now this result equals that free_old_closure() do not change rcu_pending
> bit, bug! This bug will cause redundant rcu_barrier_sched() called.
> not too harmful.
>
> ----- corresponding:
>
> free_old_closure() side: change ptype side:
>
> load struct marker_entry.tmp1 |
> --------------------------------|--------------------------------
> | load struct marker_entry.tmp1
> change rcu_pending bit in tmp1 |
> | change ptype bit in tmp1
> | store tmp1
> --------------------------------|--------------------------------
> store tmp1 |
>
> now this result equals that change ptype side do not change ptype
> bit, bug! this bug cause marker_probe_cb() access to invalid memory.
> oops!
>
> see also: http://en.wikipedia.org/wiki/Bit_field
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
> diff --git a/kernel/marker.c b/kernel/marker.c
> index 7d1faec..95c62da 100644
> --- a/kernel/marker.c
> +++ b/kernel/marker.c
> @@ -62,7 +62,7 @@ struct marker_entry {
> int refcount; /* Number of times armed. 0 if disarmed. */
> struct rcu_head rcu;
> void *oldptr;
> - unsigned char rcu_pending:1;
> + int rcu_pending;
> unsigned char ptype:1;
> char name[0]; /* Contains name'\0'format'\0' */
> };
>
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-10-10 7:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-10 6:43 [PATCH] markers: bit-field is not thread-safe nor smp-safe Lai Jiangshan
2008-10-10 7:31 ` Mathieu Desnoyers [this message]
2008-10-10 7:35 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2008-10-10 3:06 Lai Jiangshan
2008-10-10 4:26 ` KOSAKI Motohiro
2008-10-10 5:30 ` Lai Jiangshan
2008-10-10 5:42 ` Mathieu Desnoyers
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=20081010073136.GC23247@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.