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

Fix some more error handling #163

Merged

Conversation

javierhonduco
Copy link
Contributor

This PR doesn't address all the call-sites that need to have their return error checked but focuses on some APIs that I am experimenting with. For more context, see: #159

(this PR does not tackle the remaining batch API calls #162)

Thanks!

This PR doesn't address all the cases, including, but not limited
to the batch APIs
@javierhonduco javierhonduco changed the title Fix some error handling Fix some more error handling May 4, 2022
@javierhonduco javierhonduco marked this pull request as ready for review May 4, 2022 15:06
return fmt.Errorf("failed to resize map %s to %v: %w", b.name, maxEntries, syscall.Errno(-errC))
ret, errC := C.bpf_map__set_max_entries(b.bpfMap, C.uint(maxEntries))
if ret != 0 {
return fmt.Errorf("failed to resize map %s to %v: %w", b.name, maxEntries, errC)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why don't we want to use syscall.Errno(-errC)? In these cases you're using %w for errC, which is an int.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The second argument's type of any CGO call is error, which is the errno already.

It's confusing because Go doesn't require us to bind all the return values of a function, and before, as errC was the sole function return value we were reading, it was in reality the return value, which is a C.int, and not what we want.

That's why passing it to syscall.Errno always resulted in -1, EPERM(#147) [1]

[1]: For completeness, it returns -1on failure before libbpf 1.0, which hasn't been released yet, or if LibbpfStrictModeDirectErrs is not used (https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-guide).

Hope this makes sense, let me know if this is not what you meant!

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah yes of course, my confusion. I'd like to standardize naming of CGO errors that are int's as errorCode and the second return of type error as errno. I can handle that in the future.

Copy link
Contributor

@grantseltzer grantseltzer left a comment

Choose a reason for hiding this comment

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

LGTM!

return fmt.Errorf("failed to resize map %s to %v: %w", b.name, maxEntries, syscall.Errno(-errC))
ret, errC := C.bpf_map__set_max_entries(b.bpfMap, C.uint(maxEntries))
if ret != 0 {
return fmt.Errorf("failed to resize map %s to %v: %w", b.name, maxEntries, errC)
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah yes of course, my confusion. I'd like to standardize naming of CGO errors that are int's as errorCode and the second return of type error as errno. I can handle that in the future.

@grantseltzer grantseltzer merged commit a8620f7 into aquasecurity:main May 6, 2022
@javierhonduco javierhonduco deleted the fix-some-error-handling branch May 8, 2022 09:54
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.

None yet

2 participants