Skip to content

Conversation

@mikechristie
Copy link
Collaborator

The kernel can end up taking a configfs lock then call up to userspace,
so we must not have a lock that is taken in this upcall and is taken
when interacting with configfs. As reported by sherlockxiao:

#595

this happens with the state_lock where during deletion the kernel will
hold the state_lock, but some code paths will hold the state_lock while
calling into configfs.

This moves our configfs access out of the state_lock.

The kernel can end up taking a configfs lock then call up to userspace,
so we must not have a lock that is taken in this upcall and is taken
when interacting with configfs. As reported by sherlockxiao:

open-iscsi#595

this happens with the state_lock where during deletion the kernel will
hold the state_lock, but some code paths will hold the state_lock while
calling into configfs.

This moves our configfs access out of the state_lock.
@lxbsz lxbsz changed the base branch from master to main August 10, 2022 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant