[ ssic-linux-Bugs-2396996 ] Hitting SSI_ASSERT_LOCKED_SHR_RW_LOCK(&rmtfb_clitbl_lock)

Bugs item #2396996, was opened at 2008-12-06 18:52
Message generated for change (Comment added) made by hughesj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2396996&group_id=32541

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v2.0.0pre2
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: John Hughes (hughesj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hitting  SSI_ASSERT_LOCKED_SHR_RW_LOCK(&rmtfb_clitbl_lock)

Initial Comment:
Having turned on the SSI log debugging I think I'm hitting  SSI_ASSERT_LOCKED_SHR_RW_LOCK(&rmtfb_clitbl_lock); in 

static inline struct rmtfb_cli *
rmtfb_getcli_id_lckd(unsigned long id)

File cluster/ssi/util/rmtfb.c around line 687


----------------------------------------------------------------------

>Comment By: John Hughes (hughesj)
Date: 2009-01-13 15:01

Message:
Yup, SSI_ASSERT_LOCKED_SHR_RW_LOCK is being used to test for shared OR
exclusive.  

----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2008-12-06 19:31

Message:
I'm guessing that it's a bug in my "improvement" to
SSI_ASSERT_LOCKED_SHR_RW_LOCK, it should be read as meaning "assert shared
OR exclusive lock" rather than "assert shared and NOT exclusive lock".

----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2008-12-06 19:23

Message:
rmtfb_getcli_id calls rmtfb_newcli, which does:

repeat:
        LOCK_EXCL_RW_LOCK(&rmtfb_clitbl_lock);
        SSI_ASSERT(!ftocli(file));
        if (import) {
                /* make sure another import didn't make one already */
                rfb = rmtfb_getcli_id_lckd(id);

So it has the lock held exclusively.

In rmtfb_getcli_id_lckd we have:

        SSI_ASSERT_LOCKED_SHR_RW_LOCK(&rmtfb_clitbl_lock);

So it wants a shared lock.

The original lock debugging code couldn't tell the difference between a
shared lock and  an exclusive lock, so this assert wouldn't trigger, but in
my version I've "fixed" it.

Now the question is whether we need a shared lock or an exclusive lock
here?  Is this a bug in the code or in the debugging.


----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2008-12-06 19:05

Message:
Here's the call chain:

rmtfb_newcli + 0x467
rmtfb_getcli_id
reop_import_file
reopen_unload_msg
common_data_unload_msg
rexecve_pproc_unload_msg
rexecve_server
rexecve_server_setup
kernel_helper

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2396996&group_id=32541

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword