From: Michael Berlin <michael.xtreemfs@go...> - 2012-06-29 13:29:59
We recently switched the interruption support in our Fuse client from
the signal handler approach (via -o intr_signal) to calling
fuse_interrupted(). In practice, it was not feasible to deal with
signal handlers in a multi-threaded environment. We even ended up
implementing an own high-level, signal-safe thread-local storage. But
in the end, we abandoned everything for the much simpler
Now fuse_interrupted() is called as part of our retry logic to see if
a retry should be aborted. This retry logic and consequently
fuse_interrupted() gets also called from non-Fuse threads e.g., our
own threads which do periodic tasks. This resulted in segmentation
faults since "fuse_req_interrupted()", called by fuse_interrupted()
, does not check if the passed pointer is NULL. Would you mind
adding a NULL check in fuse_req_interrupted()?
As a work around, we check if fuse_get_context()->fuse is not NULL
before calling fuse_interrupted(). But this approach also fails on
older Fuse versions (e.g., Fuse 2.8.3 shipped with CentOS 6) since
previous versions do not zero the struct fuse_context_i (older
versions call "malloc" at this point ).
Of course, a possible solution is to make sure that our code never
calls fuse_interrupted() in our own threads. However, I was wondering
if the current Fuse API provides any better trick than the stated one
above to find out if one is inside a Fuse thread or not.