Skip to content
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

Config is not thread-safe #4942

Closed
Stebalien opened this issue Apr 18, 2018 · 14 comments · Fixed by #5634
Closed

Config is not thread-safe #4942

Stebalien opened this issue Apr 18, 2018 · 14 comments · Fixed by #5634
Assignees
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@Stebalien
Copy link
Member

While we try to make it thread-safe by copying the config on read (see Repo.Config()) this doesn't really fix the problem because we have, e.g., maps inside of it. Furthermore, while not safety issue, the profile apply commands don't compose atomically.

Instead of exposing Config(), SetConfig(), BackupConfig(), etc., we should probably provide the following two methods:

ReadConfig(read func (cfg *Config) error) error

// Not sure about the signature but I'd *like* backups to be atomic.
UpdateConfig(update func (cfg *Config) error, backup bool) (backup string, err error)
@Stebalien Stebalien added the kind/bug A bug in existing code (including security flaws) label Apr 18, 2018
@qiwaa
Copy link
Contributor

qiwaa commented Oct 12, 2018

I am very interested in this. Can I help with this?

@Stebalien
Copy link
Member Author

I'd like to get someone (@magik6k? @schomatis?) to comment on the design first.

@magik6k
Copy link
Member

magik6k commented Oct 16, 2018

Looks good to me

@Stebalien
Copy link
Member Author

@chenminjian then go ahead.

@qiwaa
Copy link
Contributor

qiwaa commented Oct 16, 2018

OK.

@schomatis
Copy link
Contributor

SGTM

@kevina
Copy link
Contributor

kevina commented Oct 16, 2018

This SGTM but I would need to see how the implementation works out.

Stebalien added a commit that referenced this issue Oct 23, 2018
This fixes the data-race in the config. Depends
on: ipfs/go-ipfs-config#16.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

However, we'll still need the Clone function for the new `--dry-run` flag
introduced in #5455.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@ghost ghost assigned Stebalien Oct 23, 2018
@ghost ghost added the status/in-progress In progress label Oct 23, 2018
@schomatis
Copy link
Contributor

@Stebalien Is this blocked by #5634 or can @chenminjian still attempt a fix here?

@Stebalien
Copy link
Member Author

Not really. That fixes the thread-safety issue but still doesn't allow for atomic config updates. For that, we need this change (so we can apply transformations while holding a lock on the entire config.

@Stebalien
Copy link
Member Author

Really, I'm not sure if there is a thread-safety issue anymore (if ever?). However, having a way to clone the config is still useful.

@schomatis
Copy link
Contributor

However, having a way to clone the config is still useful.

Ok, pinging @chenminjian then, as he seemed really interested in this and has already landed some pretty useful patches regarding the go-ipfs config system.

Stebalien added a commit that referenced this issue Dec 14, 2018
This fixes a data-race in the config.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@Stebalien
Copy link
Member Author

Digging that PR back up, it looks like it addressed two separate issues:

  1. It deep-clones the config before updating it. This probably wasn't necessary as we (a) dereference it and then (b) replace (not modify) mutable datastructures.
  2. It replaces the stored config by pointer instead of by-value. This was the actual data race.

Stebalien added a commit that referenced this issue Dec 14, 2018
This fixes a data-race in the config.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Dec 14, 2018
This fixes a data-race in the config.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@qiwaa
Copy link
Contributor

qiwaa commented Dec 18, 2018

❤️ Thanks for pinging me. I watched go-ipfs, so I didn't notice this email immediately.

@qiwaa
Copy link
Contributor

qiwaa commented Dec 18, 2018

However, having a way to clone the config is still useful.

This has been implemented in the latest go-ipfs-config.

Stebalien added a commit that referenced this issue Dec 20, 2018
This fixes a data-race in the config.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Dec 20, 2018
This fixes a data-race in the config.

This does not fix #4942 as there's still a
logical race: parallel config updates clobber each other.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@ghost ghost removed the status/in-progress In progress label Dec 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants