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

[Chore] Fix lint errors caused by casting int to int32 #2368

Merged
merged 4 commits into from
Sep 10, 2024

Conversation

kevin85421
Copy link
Member

@kevin85421 kevin85421 commented Sep 10, 2024

Why are these changes needed?

It may cause overflow when casting int to int32, and golangci-lint relies on gosec's rule G115 to check it. However, G115 causes some false positives, and the gosec community is still working on the issue: securego/gosec#1212. We should remove //nolint until the false positive issue is solved.

Open an issue to track the progress: #2369

Related issue number

Checks

  • I've made sure the tests are passing.
  • Testing Strategy
    • Unit tests
    • Manual tests
    • This PR is not tested :(

Signed-off-by: kaihsun <kaihsun@anyscale.com>
Signed-off-by: kaihsun <kaihsun@anyscale.com>
}

rayContainer.LivenessProbe = &corev1.Probe{
InitialDelaySeconds: utils.DefaultLivenessProbeInitialDelaySeconds,
TimeoutSeconds: int32(probeTimeout),
Copy link
Member Author

Choose a reason for hiding this comment

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

The linter is not smart enough to determine whether casting probeTimeout (int) to int32 will cause an overflow, but it can determine if an overflow will occur when casting utils.DefaultLivenessProbeTimeoutSeconds or utils.DefaultHeadLivenessProbeTimeoutSeconds.

Copy link
Member

@MortalHappiness MortalHappiness Sep 10, 2024

Choose a reason for hiding this comment

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

I think it is not the fault of the linter. Because utils.DefaultLivenessProbeTimeoutSeconds is a constant so the linter can easily find it will not cause error if casted to int32. But for the int32(probeTimeout) case, the linter cannot determine if it will cause an overflow because it does not know whether probeTimeout is assigned with some other values in between.

Copy link
Member Author

@kevin85421 kevin85421 Sep 10, 2024

Choose a reason for hiding this comment

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

You can check securego/gosec#1212. The gosec community seems to consider it as a false positive because probeTimeout should be either utils.DefaultLivenessProbeTimeoutSeconds or utils.DefaultHeadLivenessProbeTimeoutSeconds which is smaller than MaxInt32 and should not cause overflow when casting.

@@ -769,21 +769,20 @@ func (r *RayClusterReconciler) reconcilePods(ctx context.Context, instance *rayv
if worker.NumOfHosts <= 0 {
worker.NumOfHosts = 1
}
numExpectedPods := workerReplicas * worker.NumOfHosts
numExpectedPods := int(workerReplicas * worker.NumOfHosts)
Copy link
Member Author

@kevin85421 kevin85421 Sep 10, 2024

Choose a reason for hiding this comment

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

Converting int32 to int will not cause overflow. Therefore, I decide to convert int32 to int instead of converting int to int32.

Copy link
Contributor

Choose a reason for hiding this comment

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

The code is doing the opposite, it converts to int instead of int32?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh yeah, it is a typo in my comment.

.golangci.yml Outdated
@@ -4,6 +4,9 @@ linters-settings:
gosec:
excludes:
- G601
# G115 is reporting false positives in golangci-lint v1.60.3.
Copy link
Member Author

Choose a reason for hiding this comment

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

G115 is reporting false negatives, and the gosec community still hasn't reached a final conclusion. Therefore, I’ve decided to disable it by default: securego/gosec#1212.

@kevin85421 kevin85421 changed the title [Chore] Fix lint errors [Chore] Fix lint errors by disabling G115 Sep 10, 2024
Signed-off-by: kaihsun <kaihsun@anyscale.com>
@kevin85421 kevin85421 changed the title [Chore] Fix lint errors by disabling G115 [Chore] Fix lint errors caused by casting int to int32 Sep 10, 2024
@kevin85421
Copy link
Member Author

cc @MortalHappiness @andrewsykim

ray-operator/controllers/ray/raycluster_controller.go Outdated Show resolved Hide resolved
@@ -251,7 +251,7 @@ func (r *RayServiceReconciler) calculateStatus(ctx context.Context, rayServiceIn
if numServeEndpoints > math.MaxInt32 {
return errstd.New("numServeEndpoints exceeds math.MaxInt32")
}
rayServiceInstance.Status.NumServeEndpoints = int32(numServeEndpoints) //nolint:gosec // Already checked in the previous line.
rayServiceInstance.Status.NumServeEndpoints = int32(numServeEndpoints) //nolint:gosec // This is a false positive from gosec. See https://github.com/securego/gosec/issues/1212 for more details.
Copy link
Member

Choose a reason for hiding this comment

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

I think this is not a false positive. The type of numServeEndPonits is int, so it may be 32 or 64 bits depending on the system. If it is 64 bits, then casting it to int32 will cause overflow. So this comment should not be changed.

Copy link
Member Author

Choose a reason for hiding this comment

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

numServeEndpoints should be between 0 and MaxInt32, so converting it to int32 should not cause an overflow. Based on securego/gosec#1212, the gosec community considers it as a false positive.

@andrewsykim
Copy link
Collaborator

@chiayi and I were also debugging this yesterday as part of #2296. Adding checks for overflow didn't seem to resolve the lint error but maybe we missed something.

@chiayi chiayi mentioned this pull request Sep 10, 2024
4 tasks
Signed-off-by: kaihsun <kaihsun@anyscale.com>
Copy link
Collaborator

@andrewsykim andrewsykim left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -769,21 +769,20 @@ func (r *RayClusterReconciler) reconcilePods(ctx context.Context, instance *rayv
if worker.NumOfHosts <= 0 {
worker.NumOfHosts = 1
}
numExpectedPods := workerReplicas * worker.NumOfHosts
numExpectedPods := int(workerReplicas * worker.NumOfHosts)
Copy link
Contributor

Choose a reason for hiding this comment

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

The code is doing the opposite, it converts to int instead of int32?

@kevin85421
Copy link
Member Author

@MortalHappiness I merge this PR for now to unblock other PRs. If my replies don't make sense to you, we can discuss offline and maybe open a follow up PR instead.

@kevin85421 kevin85421 merged commit fb58429 into ray-project:master Sep 10, 2024
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants