As such, it gracefully enables locking *of all future memory allocations* (MCL_FUTURE) but the allocations themselves are not handled gracefully: mmap(2), sbrk(2), malloc(3) may fail when RLIMIT_MEMLOCK gets hit. In other works, memory locking is enabled once and then none of the memory allocations have to explicitly request locking which makes it hard to fail gracefully.
As a tactical fix, we can modify the LXD profiles shipped with our charms to set RLIMIT_MEMLOCK to "unlimited".
Frode,
OVS has the following checks:
1) a compile-time check for HAVE_MLOCKALL; MCL_CURRENT | MCL_FUTURE)` which fails gracefully and logs a messsage; /github. com/openvswitch /ovs/blob/ v2.13.1/ vswitchd/ ovs-vswitchd. c#L93-L103
2) An attempt to make all future memory allocations locked via `mlockall(
https:/
As such, it gracefully enables locking *of all future memory allocations* (MCL_FUTURE) but the allocations themselves are not handled gracefully: mmap(2), sbrk(2), malloc(3) may fail when RLIMIT_MEMLOCK gets hit. In other works, memory locking is enabled once and then none of the memory allocations have to explicitly request locking which makes it hard to fail gracefully.
As a tactical fix, we can modify the LXD profiles shipped with our charms to set RLIMIT_MEMLOCK to "unlimited".
The rationale is described in the commit message: /review. opendev. org/c/x/ charm-ovn- chassis/ +/765492/ 1//COMMIT_ MSG
https:/
Reviews: /review. opendev. org/c/x/ charm-ovn- chassis/ +/765492 /review. opendev. org/c/openstack /charm- neutron- openvswitch/ +/765493
https:/
https:/