Bug 153416 – swapoff -a >>> swapoff: /dev/mapper/crypt-swap: Cannot allocate memory

• Status: RESOLVED UPSTREAM
• Product: Gentoo Linux

[Description cilly 2006-10-30 01:51:47 UTC]

While running swap as encrypted, swapoff -a does not work:

swapoff -a >>> swapoff: /dev/mapper/crypt-swap: Cannot allocate memory

The Swap-memory is totally empty.

[Comment 1 cilly 2006-10-30 05:16:56 UTC]

This bug depends on:

# The Linux kernel supports the following overcommit handling modes
#
#  0    Heuristic overcommit handling. Obvious overcommits of
#       address space are refused. Used for a typical system. It
#       ensures a seriously wild allocation fails while allowing
#       overcommit to reduce swap usage.  root is allowed to 
#       allocate slighly more memory in this mode. This is the 
#       default.
#
#  1    Always overcommit. Appropriate for some scientific
#       applications.
#
#  2    Don't overcommit. The total address space commit
#       for the system is not permitted to exceed swap + a
#       configurable percentage (default is 50) of physical RAM.
#       Depending on the percentage you use, in most situations
#       this means a process will not be killed while accessing
#       pages but will receive errors on memory allocation as
#       appropriate.
#
# The overcommit policy is set via the sysctl `vm.overcommit_memory'.
# The overcommit percentage is set via `vm.overcommit_ratio'.
 
vm.overcommit_memory = 2
vm.overcommit_ratio = 0

If overcommit_memory is set to 2, then swapoff does not work.

Workaround:

sysctl -w vm.overcommit_memory=2
swapoff -a

...

[Comment 2 cilly 2006-10-30 05:18:58 UTC]

addition info:

does not depend on encrypted swap, bug is present even if swap is not encrypted

[Comment 3 cilly 2006-10-30 05:25:14 UTC]

This bug appears if:

vm.overcommit_ratio = 0

is set.

[Comment 4 cilly 2006-10-30 09:13:09 UTC]

(In reply to comment #1)
> 
> Workaround:
> 
> sysctl -w vm.overcommit_memory=2
> swapoff -a
> 
> ...
> 

sorry, the correct workaround must be:

sysctl -w vm.overcommit_memory=0
swapoff -a

or set ratio to default:

sysctl -w vm.overcommit_ratio=50
swapoff -a

[Comment 5 SpanKY 2006-10-30 18:07:01 UTC]

you didnt say anything about your system, but the behavior you're seeing looks completely correct to me ... dont screw with sysctl values and you wouldnt have problems :P

[Comment 6 cilly 2006-10-30 18:14:30 UTC]

(In reply to comment #5)
> you didnt say anything about your system, but the behavior you're seeing looks
> completely correct to me ... dont screw with sysctl values and you wouldnt have
> problems :P
> 

If not setting overcommit to 2 and ratio to 0 then the system would have crashed many times cause of users trying to exploit via forking

I agree, that the behavior is normal, but swapoff could give a more detailed hint... so this bug-report may be reassigned as a feature request.

[Comment 7 Alexander Holler 2006-10-31 02:32:48 UTC]

Have a look at /etc/security/limits.conf, especially the explanation of nproc.

[Comment 8 cilly 2006-10-31 02:55:39 UTC]

(In reply to comment #7)
> Have a look at /etc/security/limits.conf, especially the explanation of nproc.
> 

Hey alex, nice to see you here, you should have been @ #gentoo.de yesterday. Without limits.conf set but with overcommit 2 and ratio 0 the following code could not harm the system:

fork_exploit.c (by monsti)

#include <stdlib.h>
#define MEM 1024*1024
 
/*  gcc -o fork_exploit fork_exploit.c */
 
main()
{
        int size = MEM;
        for(;;)
        {
                char * mem = (char*)malloc(size);
                int i;
                if( mem == NULL )
                {
                        size = size/2;
                }
 
                for( i=0; i<size; i++ )
                        *(mem+i)= ' ';
                fork();
        }
}

----------

Without overcommit 2 and without ratio 0 the OOM-killer would have killed randomly other processes. Of course, overcommit 2 and ratio 0 does not replace limits.conf and additionally I would suggest to take a look at grsec, too.

[Comment 9 Daniel Drake (RETIRED) 2006-10-31 08:00:41 UTC]

Please report this upstream if you think it is a bug