Got it fixed.
The problem was related to not setting the CAP_SYS_ADMIN capability at
daemon-unix.c. Follows the patch bellow to set the capability and dynamically
extract the group from OVS_USER_ID instead of forcing it to :hugetlbfs.
diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
index 839114f3e..3b94164ea 100644
--- a/lib/daemon-unix.c
+++ b/lib/daemon-unix.c
@@ -818,6 +818,9 @@ daemon_become_new_user_linux(bool access_datapath
OVS_UNUSED)
ret = capng_update(CAPNG_ADD, cap_sets, CAP_NET_ADMIN)
|| capng_update(CAPNG_ADD, cap_sets, CAP_NET_RAW);
}
+ if (!ret) {
+ ret = capng_update(CAPNG_ADD, cap_sets, CAP_SYS_ADMIN);
+ }
} else {
ret = -1;
}
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
index c6d9aa1b8..94290a847 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
EnvironmentFile=/etc/openvswitch/default.conf
EnvironmentFile=-/etc/sysconfig/openvswitch
@begin_dpdk@
-ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
+ExecStartPre=-/bin/sh -c 'chown :$(echo $OVS_USER_ID | tr ":" "\n" | tail -1)
/dev/hugepages'
ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
@end_dpdk@
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
Regards,
Marcos Schwarz
----- Original Message -----
From: "Marcos Felipe Schwarz" <[email protected]>
To: "Ben Pfaff" <[email protected]>
Cc: [email protected]
Sent: Friday, January 5, 2018 5:38:46 PM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS
2.8.0
Hi Ben,
I couldn't find a working solution for supporting running ovs as root and as
another user.
There seems to be some difference when running ovs-vswithd without the --user
parameter and with --user=root:root which affects the permission to use UIO.
Only without --user I'm able to use UIO.
So my current fix includes to remove "--ovs-user=${OVS_USER_ID} \" from
ovs-vswitchd.service.
Comparing the logs from each execution the difference is that when using --user
the following error appears:
2018-01-05T19:33:08.285Z|00012|dpdk|ERR|EAL: Cannot obtain physical addresses:
No such file or directory. Only vfio will function.
My guess is that when the daemon is switch from native root:root to the --user
root:root it looses some permission related to /proc/self/pagemap. Do you have
any suggestion on how to move forward? One way around would be to define an
exception to not try to switch the user when the value is root:root.
Regards,
Marcos Schwarz
----- Original Message -----
From: "Ben Pfaff" <[email protected]>
To: "Marcos Felipe Schwarz" <[email protected]>
Cc: [email protected]
Sent: Monday, November 27, 2017 6:31:39 PM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS
2.8.0
On Tue, Nov 21, 2017 at 12:08:51PM -0200, Marcos Felipe Schwarz wrote:
> Hi,
>
> The current solution for running OVS with non-root user in Fedora makes it
> not possible to support UIO drivers [1].
> Setting the user to root:root via /etc/sysconfig/openvswitch should be a
> solution, but it is also currently broken, since the systemd
> ovs-vswitchd.service is forcing the group :hugetlbfs to /dev/hugepages [2],
> which breaks root access to it.
> Would it be possible to change the permissions only if the user in not root?
> Currently I can only make UIO work on fedora removing this hardcoded
> permissions on the systemd files. I believe that either root:root should not
> conflict with the systemd script or be explicitly unsupported.
>
> [1] For Linux kernel 4.0 and newer, the ability to obtain physical page frame
> numbers for unprivileged users from /proc/self/pagemap was removed.
> Source.
> http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766bd95a658b5e0686a62ec04f5b0
> [2] ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages.
> https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
Are you able to submit a patch to solve the problem? It sounds like you
have a specific idea about what should be done.
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
