🐛 Prevent race when informers are started more than once#2758
🐛 Prevent race when informers are started more than once#2758k8s-ci-robot merged 1 commit intokubernetes-sigs:mainfrom
Conversation
|
Done |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold |
pkg/cache/internal/informers.go
Outdated
| // It doesn't return start because it can't return an error, and it's not a runnable directly. | ||
| func (ip *Informers) Start(ctx context.Context) error { | ||
| select { | ||
| case <-ip.startWait: |
There was a problem hiding this comment.
Do we need a lock around this?
There was a problem hiding this comment.
No, this is a channel
There was a problem hiding this comment.
That's not how I meant it :)
What if you have one goroutine in l.198 and another one then just going through l.191?
I would assume the same data race.
Don't we have to make sure an additional goroutine can't go through l.190-l.195 while another one is inside
l.197-216?
There was a problem hiding this comment.
Put all of it under the lock
|
/hold cancel |
b9c9be8 to
c2c96b0
Compare
If `Informers` are started a second time, there is a possibility for a data race because it sets a `ctx` field on itself. This write is protected by a mutex, but reads from that field are not.
|
/lgtm /hold |
|
LGTM label has been added. DetailsGit tree hash: 59bffd29e2eca09280185b4878884fe155112efb |
|
/hold cancel |
If
Informersare started a second time, there is a possibility for a data race because it sets actxfield on itself. This write is protected by a mutex, but reads from that field are not.As it is generally unclear and untested what happens when a cache is started a second time, simply error out to make the user aware that they were starting the cache a second time.