-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Move location of quit channel closing in exp manager #3638
Conversation
If it happens after stopping timers any timers firing before all timers are stopped will still run the revocation function. With plugin auto-crash-recovery this could end up instantiating a plugin that could then try to unwrap a token from a nil token store. This also plumbs in core so that we can grab a read lock during the operation and check standby/sealed status before running it (after grabbing the lock).
vault/expiration.go
Outdated
tokenView *BarrierView | ||
tokenStore *TokenStore | ||
logger log.Logger | ||
coreStateLock *sync.RWMutex |
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.
If we are storing core
, we don't need to also store the state lock
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.
It's true, the main reason I kept it like this is I would really rather not plumb through core, I just also figured we should check standby and sealed while we were at it and didn't feel like storing two pointers to bools. So I left it the easiest way to plumb back out.
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.
One small comment, otherwise LGTM
@@ -969,13 +980,24 @@ func (m *ExpirationManager) expireID(leaseID string) { | |||
return | |||
default: | |||
} | |||
|
|||
m.coreStateLock.RLock() | |||
if m.quitContext.Err() == context.Canceled { |
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.
Small nit, but this might be a better way of handling this case:
select {
case <- m.quitContext.Done():
m.logger.Error("expiration: core context canceled, not attempting further revocation of lease", "lease_id", leaseID)
m.coreStateLock.RUnlock()
return
default:
}
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.
This should be safe; see https://golang.org/pkg/context/#pkg-variables
Canceled is the error returned by Context.Err when the context is canceled.
It's defined behavior so should be reliable.
If it happens after stopping timers any timers firing before all timers
are stopped will still run the revocation function. With plugin
auto-crash-recovery this could end up instantiating a plugin that could
then try to unwrap a token from a nil token store.
This also plumbs in core so that we can grab a read lock during the
operation and check standby/sealed status before running it (after
grabbing the lock).