Hello,
This issue is with 2.6-dev.11 (don't think it is specific to this version).
It appears that there is a race between mdcache_unexport() and
mdcache_alloc_handle(). If an request comes after the MDC_UNEXPORT is set,
mdcache tries to free the entry by calling these:
/* Map the export before we put this entry into the LRU, but after
it's
* well enough set up to be able to be unrefed by unexport should
there
* be a race.
*/
status = mdc_check_mapping(result);
if (unlikely(FSAL_IS_ERROR(status))) {
/* The current export is in process to be unexported, don't
* create new mdcache entries.
*/
LogDebug(COMPONENT_CACHE_INODE,
"Trying to allocate a new entry %p for export id %"
PRIi16" that is in the process of being
unexported",
result, op_ctx->ctx_export->export_id);
mdcache_put(result);
mdcache_kill_entry(result);
return NULL;
}
At this point, the entry is neither in any LRU queue nor in any partition
(AVL tree).
So _mdcache_kill_entry() will call mdcache_lru_cleanup_push() which will
try to dequeue:
if (!(lru->qid == LRU_ENTRY_CLEANUP)) {
struct lru_q *q;
/* out with the old queue */
q = lru_queue_of(entry); <--- NULL since we haven't
inserted it.
LRU_DQ_SAFE(lru, q); <-- crash here.
I think if we call mdcache_lru_unref() instead of mdcache_kill_entry(), it
will correctly free the entry.
If the idea of calling mdcache_kill_entry() is to insert into the cleanup
queue, then adding a check before LRU_DQ_SAFE() in
mdcache_lru_cleanup_push() should fix it too.
Thanks,
Pradeep
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
