-
Notifications
You must be signed in to change notification settings - Fork 203
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
DSA and IAA demos fail with "mmap: Operation not permitted" #1779
Comments
Which of the listed procfs + sysfs files & dirs are mounted, and need to be mounted, inside DSA/IAA example containers? |
I added the capability in my pod yaml, it can run with no issue. So the capability is needed, I think. |
I do not believe we need any extra host files or directories. The kernel patch is quite self-explaining: for certain devices check for sys_rawio capability. If no capability, return eperm. Another question is how should the dsa plugin handle this? If at all. |
I meant is there something that should be masked out of the container... |
Probably "everything" that the sys_rawio brings. DSA demo has worked without it before and the kernel side only needs the sys_rawio capability flag. |
runtimes mask out some |
Describe the bug
As Ubuntu hwe kernel updated from 6.5.0-35 to 6.5.0-41, DSA e2e started to fail. The failure seems to be related to a change in the kernel where (due to a security issue) access to the DSA/IAA accelerators is being denied without SYS_RAWIO capability: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=796aec4a5b5850967af0c42d4e84df2d748d570b
To Reproduce
Expected behavior
Pod Completes successfully.
System (please complete the following information):
Additional context
Adding:
might fix it temporarily.
The text was updated successfully, but these errors were encountered: