xfs
[Top] [All Lists]

[Bug 221] reload xfs/dmapi module crash

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 221] reload xfs/dmapi module crash
From: bugzilla-daemon@xxxxxxxxxxx
Date: Fri, 14 Feb 2003 09:15:56 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx
http://oss.sgi.com/bugzilla/show_bug.cgi?id=221





------- Additional Comments From joshhelmer@xxxxxxx  2003-02-14 09:15 -------
Yes, I am pretty sure that the dm_tokdata cache is the only one with data left
in it.  I added some debugging code to mm/slab.c to dump the contents of the
cache in the case where it does not clean up properly and the only one that ever
has issues is the "dm_tokdata" cache.

After doing some more testing I think that I MIGHT have found the problem.  In
dm_send_namesp_event(), token data is being allocated - even if the PREUNMOUNT
event is not being handled.  When the check against DM_FLAGS_UNWANTED occurs a
return is called without ever freeing up that memory...  I applied the following
patch:

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

--- dmapi_event.c.orig  Fri Feb 14 09:23:08 2003
+++ dmapi_event.c       Fri Feb 14 09:24:56 2003
@@ -654,6 +654,10 @@
                 *      vp1_right is the filesystem right.
                 *      vp2_right is the root inode right.
                 */
+               if (flags & DM_FLAGS_UNWANTED) {
+                       dm_change_fsys_entry(sidvfsp, DM_STATE_UNMOUNTING);
+                       return(0);
+               }
 
                tdp1 = dm_vfs_data(sidvfsp, vp1, vp1_right);
                if (tdp1 == NULL)
@@ -664,10 +668,6 @@
                        return ENOMEM;
                }
 
-               if (flags & DM_FLAGS_UNWANTED) {
-                       dm_change_fsys_entry(sidvfsp, DM_STATE_UNMOUNTING);
-                       return(0);
-               }
                break;
 
        case DM_EVENT_NOSPACE:

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

to my local machine and all issues seem to have cleared up.  I can't guarantee
that this is 100% correct though because if, instead of moving the check against
DM_FLAGS_UNWANTED up, I just release tdp1 and tdp2 a whole slew of other
problems show up.

I am also a little uncomfortable with this solution because when I dump out the
dm_tokdata cache I only see a single entry in the slabs_partial list.  This
solution skips the allocation of 2 entries.  So, while it seems to work locally,
I suspect that I am overlooking something still.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


<Prev in Thread] Current Thread [Next in Thread>