Comment 22 for bug 1830746

To clarify, the regression appears to be the same problem that the rlimit increase is fixing, but the applications failing now are simply bigger. In general, any application that calls mlockall() with MCL_FUTURE, but doesn't adjust its rlimit (or change its systemd service file to adjust LimitMEMLOCK) is very likely destined to crash later in its life.

I believe the only lp bugs for this regression are bug 1890394 and bug 1902879, which are both fix-committed and verified, so this bug should be ok to release (again) after those are released. Also I will note both of those applications (slick-greeter and lightdm-gtk-greeter) were fixed by commenting out their calls to mlockall.

There is also bug 1902871 and bug 1903199 but I believe those are both dups of bug 1900394.

Also finally to reflect on cryptsetup's use of mlockall(), since it's the origin for this bug; cryptsetup is maybe "better" about its use of mlockall() since it keeps the mlock only for the duration of an 'action':

        if (action->required_memlock)
                crypt_memory_lock(NULL, 1);

        set_int_handler(0);
        r = action->handler();

        if (action->required_memlock)
                crypt_memory_lock(NULL, 0);

however, as this bug shows, that action handler function can still attempt to allocate enough memory to reach the rlimit and cause allocation failures. Personally, I think cryptsetup should be fixed upstream to call setrlimit() to increase its RLIMIT_MEMLOCK to infinity, at least while the mlock is in effect.