[Ocfs2-users] ocfs or configfs bug ?

[Joel Becker]

On Tue, Apr 19, 2011 at 04:54:32PM +0200, Welterlen Benoit wrote:
> I have a bug with OCFS through configfs : to illustrate this, try :
> 
> while true ; do ls -l /sys/kernel/config/cluster/ocfs2/heartbeat ; done&
> 
> while true ; do echo 31>  /sys/kernel/config/cluster/ocfs2/heartbeat/dead_threshold ; done&

	Interesting!

> RIP  [<ffffffffa01fd214>] configfs_readdir+0xf4/0x230 [configfs]
<snip>
>   #8 [ffff880c6c8b3ee0] vfs_readdir at ffffffff8116c120
>   #9 [ffff880c6c8b3f30] sys_getdents at ffffffff8116c2a9

	I presume this is in the process that is ls(1)ing the directory?

> I've looked into the source code, but I found that a lock is useless :
> /* Only sets a new threshold if there are no active regions.
>   *
>   * No locking or otherwise interesting code is required for reading
>   * o2hb_dead_threshold as it can't change once regions are active and
>   * it's not interesting to anyone until then anyway. */
> static void o2hb_dead_threshold_set(unsigned int threshold)
> {
>          if (threshold > O2HB_MIN_DEAD_THRESHOLD) {
>                  spin_lock(&o2hb_live_lock);
>                  if (list_empty(&o2hb_all_regions))
>                          o2hb_dead_threshold = threshold;
>                  spin_unlock(&o2hb_live_lock);
>          }
> }

	You're too late here.  This is in the echo process (bash,
really).  getdents() isn't happening.
	The problem is almost certainly in configfs.  It's a race
between setup and teardown of the virtual attribute files.  If anyone
else has a cycle to look at it, great, otherwise I'll try to get to it
later this week.

Joel
-- 

"In a crisis, don't hide behind anything or anybody. They're going
 to find you anyway."
	- Paul "Bear" Bryant

			http://www.jlbec.org/
			jlbec at evilplan.org