cocalele
commented
2 years ago 在决定以FSAL_MEM为基础渐进开发ViveNAS的适配后，死锁问题再次出现。
通过在common_utils.h的加锁，解锁代码里面增加log，发现死锁的位置在这里：
mem_handle.c:998
/* Check if this context already holds the lock on
* this directory.
*/
if (op_ctx->fsal_private != parent) {
PTHREAD_RWLOCK_rdlock(&parent->obj_lock); ===== rdlocked here
lock_applyed = 1;
}
else
LogFullDebug(COMPONENT_FSAL,
"Skipping lock for %s",
myself->m_name);
status = mem_int_lookup(myself, path, &hdl); =====acqrie wrlock again during alloc_handle => mem_insert_obj
if (FSAL_IS_ERROR(status)) {
goto out;
}
*handle = &hdl->obj_handle;
mem_int_get_ref(hdl);
out:
if (lock_applyed && op_ctx->fsal_private == parent){
S5LOG_ERROR("Lock applied but not released!");
}
if (op_ctx->fsal_private != parent)
PTHREAD_RWLOCK_unlock(&parent->obj_lock);vivenas在lookup的时候发现找不到某个child，就会从rocksdb里找，找到后又试图插入到FSAL_MEM的avl tree里面。 原始的FSAL_MEM并没有从底层存储查找然后插入到avl tree的环节，因此不会死锁。
在open2函数调用后，发现报告
RW LOCK :CRIT :Error 35, write locking， 而且这个错误是从MDCache代码里报告的，此时所有代码的调用栈都已出了vivenas的代码。当前已进行了如下的尝试：ganesha v4换到v3， 并模仿fsal ceph的代码实现open2
发现ganesha v3自带的FSAL_MEM模块无法正常启动，感觉问题发散了，决定仍切换会ganesha v4.
ganesha v4的FSAL_MEM模块能正常使用
拿mem fsal的代码过来，只做最细微的调整 上面的方法都调不通。因此决定下面的方法
在ganesha的工程里进行改造，基础版本可以运行，只要加上vivenas链接，nfs mount就卡住了，任何错误信息都不出。 很多次尝试后发现问题在于vivenas.so文件本身是一个fsal plugin， 里面有fsal注册的代码。把fsal代码去掉重新编译so文件。这样FSAL_MEM就可以正常响应mount