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

builder baseMap concurrent write fix lock #11588

Closed
wants to merge 3 commits into from

Conversation

cstyan
Copy link
Contributor

@cstyan cstyan commented Jan 5, 2024

It looks like with either sufficiently large line formats, or line formats that have some kind of operation that results in two line formats being executed concurrently (somehow, I do not understand how), it's possible for us to end up with a concurrent write as part of LineFormatter.Process calls.

This AFAICT existed before #11484 but a query was executed in one of our environments today that made us think the panic was from those changes. I suspect the baseMap usage is the underlying cause, and can confirm by deploying the changes from here into one of our environments tomorrow and running the same query I saw today that caused the panic.

@cstyan cstyan requested a review from a team as a code owner January 5, 2024 01:58
Copy link
Contributor

github-actions bot commented Jan 5, 2024

Trivy scan found the following vulnerabilities:

  • HIGH, Target: docker.io/grafana/loki:main-6c4699d (alpine 3.18.4), Type: alpine openssl: Incorrect cipher key and IV length processing in libcrypto3 v3.1.3-r0. Fixed in v3.1.4-r0
  • HIGH, Target: docker.io/grafana/loki:main-6c4699d (alpine 3.18.4), Type: alpine openssl: Incorrect cipher key and IV length processing in libssl3 v3.1.3-r0. Fixed in v3.1.4-r0
    \nTo see more details on these vulnerabilities, and how/where to fix them, please run docker build -t grafana/loki:main-6c4699d -f cmd/loki/Dockerfile .
    trivy i grafana/loki:main-6c4699d on your branch. If these were not introduced by your PR, please considering fixing them in via a subsequent PR. Thanks!

Copy link
Contributor

@dannykopping dannykopping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple notes, but what's unclear to me is why this would address the issue fully... The panic occurs at pkg/logql/log/labels.go:468 which is when the newly-retrieved map from the pool is clear-ed, suggesting that we're putting a map back into the pool without removing all references to it. We can add the locks and that'll make the problem go away, but is the underlying issue not the references?

Comment on lines +929 to +930
//for _, tt := range tests {
// t.Run(tt.fmt, func(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
//for _, tt := range tests {
// t.Run(tt.fmt, func(t *testing.T) {

ls := labels.FromStrings("cluster", "us-central-0")
builder := NewBaseLabelsBuilder().ForLabels(ls, ls.Hash())
wg := sync.WaitGroup{}
wg.Add(1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this not need to be in the loop?


}
wg.Done()
time.Sleep(2 * time.Second)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the sleep for?

@cstyan
Copy link
Contributor Author

cstyan commented Jan 10, 2024

superseded by #11607

@cstyan cstyan closed this Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants