map: add map_extra, memlock, frozen to MapInfo #1570
Conversation
- Added MapInfo.MapExtra(), .Memlock() and .Frozen() methods. - Moved all unexported fields to a separate section within MapInfo. - Changed a few tests to use quicktest instead of manual if statements. This change required a small refactor to how fdinfo is used, since memlock and frozen are only available there. fdinfo is now always consulted regardless of the success of ObjInfo, and any empty fields are supplemented by data from fdinfo. Removed errMissingFields since its meaning sort of overlapped with ErrNotSupported. It was only used for getting ProgramInfo, which currently looks for just 2 fields. If we want to pull more fields from fdinfo, this no longer works for the majority of older kernels, since they'll always be missing some fields that were introduced later. Going forward, rely on ErrNotSupported to tell us if no fields were found in fdinfo, which would indicate there's no map info present because we're trying to query the wrong kind of fd (e.g. a program, link or regular file). Signed-off-by: Timo Beckers <timo@isovalent.com>
|
Interesting, that would have been useful, because I implemented my own way to read memlock. I could argue and wanted to push that this should be returned from the syscall instead of needing to parse fdinfo but not sure it would merge upstream. |
I'm not aware of the current attitude around uapi changes, but it seems like things haven't been added to map_/prog_info in quite a few releases now. And if we manage to get this changed now, the fdinfo user space code is in place and can't be removed for backwards-compat reasons. Personally, I'd direct my energy elsewhere. 😄 |
|
This is really cool by the way, it could simplify things on the Tetragon side, see cilium/tetragon@3f7f1f6, I had to extend the map info with memlock. Thanks to this, it might be possible to drop this code in the future. :) |
This change required a small refactor to how fdinfo is used, since memlock and frozen are only available there. fdinfo is now always consulted regardless of the success of ObjInfo, and any empty fields are supplemented by data from fdinfo.
Removed errMissingFields since its meaning sort of overlapped with ErrNotSupported. It was only used for getting ProgramInfo, which currently looks for just 2 fields. If we want to pull more fields from fdinfo, this no longer works for the majority of older kernels, since they'll always be missing some fields that were introduced later.
Going forward, rely on ErrNotSupported to tell us if no fields were found in fdinfo, which would indicate there's no map info present because we're trying to query the wrong kind of fd (e.g. a program, link or regular file).