[PR #1151] [MERGED] fix deadlock in clean up cache #1852

New issue

Closed

opened 2026-03-04 02:02:28 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 02:02:28 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/1151
Author: @liuyongqing
Created: 9/11/2019
Status: ✅ Merged
Merged: 1/30/2020
Merged by: @ggtakec

Base: master ← Head: master

📝 Commits (1)

b762a0a fix deadlock due to fdmanager_lock and fdent_data_lock

📊 Changes

5 files changed (+49 additions, -29 deletions)

View changed files

📝 src/fdcache.cpp (+6 -25)
📝 src/fdcache.h (+0 -2)
📝 test/integration-test-main.sh (+29 -0)
📝 test/small-integration-test.sh (+9 -2)
📝 test/test-utils.sh (+5 -0)

📄 Description

@gaul ，the previous pull request is：https://github.com/s3fs-fuse/s3fs-fuse/pull/1146, still have some situations not fully considered, so I closed the previous pull request.

Deadlocks will appear in the following situations also：
thread A call s3fs_write, already get the fdent_data_lock and cache_cleanup_lock（for clean up cache dir）, after cleaning one file, and trying to get fd_manager_lock for Close the FdEntity.
thread B call s3fs_open for the same file，already get fd_manager_lock and fdent_lock, trying to get fdent_data_lock
the deadlock occured between thread A and thread B, because each thread wants to get the lock of another thread
so when cleanup a cache file, we should hold fd_manager_lock until it finished, if we cannot hold it, we can ignore it temporarily.

Another deadlock condition is in NoCacheLoadAndPost, because it trying to hold fd_manager_lock after hold fdent_data_lock

In short，We should lock in the order fd_manager_lock->fdent_lock->fdent_data_lock， if we trying to hold fd_manager_lock after hold fdent_lock or fdent_data_lock，we should use try_lock. The NoCacheLoadAndPost deadlock condition I didn't find a nice way to solve it，but it will only triggered if didn't have enough disk after cleaned up cache.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/s3fs-fuse/s3fs-fuse/pull/1151 **Author:** [@liuyongqing](https://github.com/liuyongqing) **Created:** 9/11/2019 **Status:** ✅ Merged **Merged:** 1/30/2020 **Merged by:** [@ggtakec](https://github.com/ggtakec) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`b762a0a`](https://github.com/s3fs-fuse/s3fs-fuse/commit/b762a0a85bc98925ee6e481e8bde03b3d53c3d54) fix deadlock due to fdmanager_lock and fdent_data_lock ### 📊 Changes **5 files changed** (+49 additions, -29 deletions) <details> <summary>View changed files</summary> 📝 `src/fdcache.cpp` (+6 -25) 📝 `src/fdcache.h` (+0 -2) 📝 `test/integration-test-main.sh` (+29 -0) 📝 `test/small-integration-test.sh` (+9 -2) 📝 `test/test-utils.sh` (+5 -0) </details> ### 📄 Description @gaul ，the previous pull request is：https://github.com/s3fs-fuse/s3fs-fuse/pull/1146, still have some situations not fully considered, so I closed the previous pull request. Deadlocks will appear in the following situations also： thread A call s3fs_write, already get the fdent_data_lock and cache_cleanup_lock（for clean up cache dir）, after cleaning one file, and trying to get fd_manager_lock for Close the FdEntity. thread B call s3fs_open for the same file，already get fd_manager_lock and fdent_lock, trying to get fdent_data_lock the deadlock occured between thread A and thread B, because each thread wants to get the lock of another thread so when cleanup a cache file, we should hold fd_manager_lock until it finished, if we cannot hold it, we can ignore it temporarily. Another deadlock condition is in NoCacheLoadAndPost, because it trying to hold fd_manager_lock after hold fdent_data_lock In short，We should lock in the order fd_manager_lock->fdent_lock->fdent_data_lock， if we trying to hold fd_manager_lock after hold fdent_lock or fdent_data_lock，we should use try_lock. The NoCacheLoadAndPost deadlock condition I didn't find a nice way to solve it，but it will only triggered if didn't have enough disk after cleaned up cache. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>