-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
lib/model: Acquire fmut lock in ensureIndexHandler (fixes #9234) #9235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Towards the end of the function f.folderCfgs and f.folderRunners are read without the lock.
@@ -1346,6 +1346,9 @@ func (m *model) ensureIndexHandler(conn protocol.Connection) *indexHandlerRegist | |||
deviceID := conn.DeviceID() | |||
connID := conn.ConnectionID() | |||
|
|||
// We must acquire fmut first when acquiring both locks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but does RLock
count as acquiring? Gut feeling says no...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why not? A read-lock can still produce a deadlock when race with a fmut-pmut (full) lock in another function, if the first (full lock) is acquired in both functions and then the subsequent locks (whether read or full) are blocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wasn't thinking "does the order matter" but rather "is an RLock enough to prevent deadlocks", but I see we already do precisely this thing in at least one other place and I can't think of an ordering that would cause a deadlock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh now I get - I indeed haven't thought about that just assumed it's ok. And I too can't think of how only acquiring a read-lock would cause a deadlock (not that this is a very strong indicator that there is none ':) ).
* main: lib/fs: Reduce memory usage in xattrs handling (syncthing#9251) lib/model: Improve LastSeen handling (syncthing#9256) lib/scanner: Record inode change time for directories and symlinks (syncthing#9250) lib/api: Improve ignore loading error handling (fixes syncthing#9253) (syncthing#9254) gui, man, authors: Update docs, translations, and contributors lib/fs: Better equality comparison in mtimefs cmd/stcrashreceiver: Add metrics for diskstore inventory cmd/stcrashreceiver: Minor cleanup, stricter file permissions cmd/stcrashreceiver: Add metrics for incoming reports cmd/ursrv: Add metrics for incoming reports gui, man, authors: Update docs, translations, and contributors gui: Specialize a special-purpose checkbox style (syncthing#9236) gui, man, authors: Update docs, translations, and contributors build: Support new nested namespaces in Weblate downloads lib/model: Acquire fmut lock in ensureIndexHandler (fixes syncthing#9234) (syncthing#9235) gui: Allow to translate "unknown device" (syncthing#9229)
Towards the end of the function f.folderCfgs and f.folderRunners are read without the lock.