Potential uvwasi_fd_table_renumber() deadlock #89

cjihrig · 2020-01-21T15:01:23Z

uvwasi_fd_table_renumber() locks the file descriptor table, acquires the source and destination mutexes, performs the renumber operation, releases the mutexes, and unlocks the file descriptor table.

An operation that takes two file descriptors (such as uvwasi_path_rename()) could have acquired one of its fd mutex locks, but not the other. If uvwasi_fd_table_renumber() is called during this window of time, deadlock can occur (uvwasi_fd_table_renumber() waits for the mutex that uvwasi_path_rename() has, and uvwasi_path_rename() waits for the file descriptor table lock that uvwasi_fd_table_renumber() has).

The file descriptor table API could add lock and unlock APIs so that calls like uvwasi_path_rename() can acquire everything at once.

The text was updated successfully, but these errors were encountered:

uvwasi_path_rename(), uvwasi_path_link(), uvwasi_path_open(), and uvwasi_fd_renumber() operate on multiple file descriptors. uvwasi_fd_renumber() has been updated prior to this commit, and is not relevant here. The other three functions would perform the following locking operations: - lock the file table - acquire a file descriptor mutex - unlock the file table - unlock the file table again - acquire another file descriptor mutex - unlock the file table - unlock the two mutexes Attempting to acquire the second mutex introduced the possibility of deadlock because another thread could attempt to acquire the first mutex while holding the file table lock. This commit ensures that multiple mutexes are either: - acquired in a single lock of the file table - or, only acquired after releasing previously held mutexes Fixes: #89

Original commit message: prevent locking fd table while holding a mutex uvwasi_path_rename(), uvwasi_path_link(), uvwasi_path_open(), and uvwasi_fd_renumber() operate on multiple file descriptors. uvwasi_fd_renumber() has been updated prior to this commit, and is not relevant here. The other three functions would perform the following locking operations: - lock the file table - acquire a file descriptor mutex - unlock the file table - unlock the file table again - acquire another file descriptor mutex - unlock the file table - unlock the two mutexes Attempting to acquire the second mutex introduced the possibility of deadlock because another thread could attempt to acquire the first mutex while holding the file table lock. This commit ensures that multiple mutexes are either: - acquired in a single lock of the file table - or, only acquired after releasing previously held mutexes Fixes: nodejs/uvwasi#89

Original commit message: prevent locking fd table while holding a mutex uvwasi_path_rename(), uvwasi_path_link(), uvwasi_path_open(), and uvwasi_fd_renumber() operate on multiple file descriptors. uvwasi_fd_renumber() has been updated prior to this commit, and is not relevant here. The other three functions would perform the following locking operations: - lock the file table - acquire a file descriptor mutex - unlock the file table - unlock the file table again - acquire another file descriptor mutex - unlock the file table - unlock the two mutexes Attempting to acquire the second mutex introduced the possibility of deadlock because another thread could attempt to acquire the first mutex while holding the file table lock. This commit ensures that multiple mutexes are either: - acquired in a single lock of the file table - or, only acquired after releasing previously held mutexes Fixes: nodejs/uvwasi#89 PR-URL: nodejs#31432 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: David Carlier <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Jiawen Geng <[email protected]>

Original commit message: prevent locking fd table while holding a mutex uvwasi_path_rename(), uvwasi_path_link(), uvwasi_path_open(), and uvwasi_fd_renumber() operate on multiple file descriptors. uvwasi_fd_renumber() has been updated prior to this commit, and is not relevant here. The other three functions would perform the following locking operations: - lock the file table - acquire a file descriptor mutex - unlock the file table - unlock the file table again - acquire another file descriptor mutex - unlock the file table - unlock the two mutexes Attempting to acquire the second mutex introduced the possibility of deadlock because another thread could attempt to acquire the first mutex while holding the file table lock. This commit ensures that multiple mutexes are either: - acquired in a single lock of the file table - or, only acquired after releasing previously held mutexes Fixes: nodejs/uvwasi#89 PR-URL: #31432 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: David Carlier <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Jiawen Geng <[email protected]>

cjihrig mentioned this issue Jan 22, 2020

prevent locking fd table while holding a mutex #90

Merged

cjihrig closed this as completed in #90 Jan 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Potential uvwasi_fd_table_renumber() deadlock #89

Potential uvwasi_fd_table_renumber() deadlock #89

cjihrig commented Jan 21, 2020

Potential uvwasi_fd_table_renumber() deadlock #89

Potential uvwasi_fd_table_renumber() deadlock #89

Comments

cjihrig commented Jan 21, 2020