[ovs-dev] [PATCH 3/3] util: munlockall() and retry when locked memory allocation fails

[Ben Pfaff]

On Fri, Mar 26, 2021 at 07:52:18PM +0100, Ilya Maximets wrote:
> On 3/26/21 7:30 PM, Ben Pfaff wrote:
> > From: James Page <james.page at ubuntu.com>
> > 
> > Normally when OVS runs on a server the effective system limit for
> > locked memory is unlimited as the ovs-vswitchd runs as the root
> > user in the root namespace of the server.
> > 
> > When OVS is run in a non-priviledged container a system limit will
> > apply and its possible that this limit will be reached during
> > normal operation.
> > 
> > If this occurs unlock all memory and re-attempt (re)allocation of
> > memory rather than fail and abort.
> > 
> > If this subsequent attempt also fails abort the process as before.
> > 
> > Signed-off-by: James Page <james.page at ubuntu.com>
> > [blp at ovn.org adapted to cover more cases]
> > Signed-off-by: Ben Pfaff <blp at ovn.org>
> > ---
> 
> Hi, Ben and James.
> 
> I'll repeat here what I said in a comment on github.
> 
> DPDK uses memory locking for mempool pages and it relies on these
> pages not being moved or unloaded, because it uses physical addresses
> to configure hardware NICs.  Also, some DPDK drivers are using memory
> locking to lock in memory pages that are used for driver-specific
> device I/O.  Unlocking any of these pages in runtime will likely crash
> the system by NMI if such a page will be moved or swapped without
> notifying the device and driver.
> 
> Blindly unlocking all the memory is very dangerous.
> 
> I'd say it's much more safe to just run OVS without passing --mlockall.
> Or we need to itroduce a special cmdline flag to allow dynamic unlocking
> and also forbid DPDK initialization if this flag enabled.
> And all this should be sufficiently documented.

I don't have a dog in this fight.  I'll leave it to you and James to
figure out the preferred behavior.

Patches 1 and 2 may be of interest either way.