VFS connection data cleanup with multiple modules

[Jeremy Allison]

On Tue, Sep 30, 2008 at 04:39:44PM -0400, Constantine Vetoshev wrote:
> I'm trying to use a stack of VFS modules, and I see strange behavior
> with reclaiming connection-specific data at disconnect time.
> Specifically, it seems that the function which releases
> connection-specific data only runs for the first VFS module loaded.
> 
> Simplified example follows. Here's a snippet of the smb.conf which
> loads the modules:
> 
> [share]
>   path = /my/path
>   vfs objects = vfs_object_1 vfs_object_2
> 
> I'm using release_data_X function pointers when I set the connection
> data in connect callbacks as follows:
> 
> In vfs_object_1:
>    SMB_VFS_HANDLE_SET_DATA(
>       handle, data, release_data_1, conn_data_1, return -1);
> 
> In vfs_object_2:
>    SMB_VFS_HANDLE_SET_DATA(
>       handle, data, release_data_2, conn_data_2, return -1);
> 
> and so on, where release_data_1 is a pointer to a function which
> releases the memory and resources in the conn_data_1 struct, and
> release_data_2 releases memory and resources in the conn_data_2
> struct.
> 
> When I disconnect from the share, I expect that release_data_1 and
> release_data_2 both run, but logging shows that only release_data_1
> runs. I can force release_data_2 to run by putting an explicit call to
> it from a disconnect callback for vfs_object_2, but that doesn't seem
> right.
> 
> Am I missing something about how the release functions should work?
> 
> I'm currently using Samba 3.0.28a.

It should get called from conn_free_internal() when the
connection struct is removed. See this code :

        /* Free vfs_connection_struct */
        handle = conn->vfs_handles;
        while(handle) {
                DLIST_REMOVE(conn->vfs_handles, handle);
                thandle = handle->next;
                if (handle->free_data)
                        handle->free_data(&handle->data);
                handle = thandle;
        }

which should call all the handle release functions in
reverse order of registration.

Jeremy.