Bug 437214

This is going into more a kernel issue now -- this patch I've found
supposedly does what the customer is doing, however, it is not in any
upstream kernel code a s far as I can tell.

http://marc.info/?l=linux-mm&m=118402827803338&w=4

I'll see about getting this put into the kernel queue.

Thanks,
Adam


This event sent from IssueTracker by bbraswel  [Support Engineering Group]
 issue 165270

I used a slightly modified, scaled down version of the program to test.  I
wanted to see if it made any difference if the data was dynamically or
statically allocated.  It did not make a difference.  With the memory
statically allocated, it still allowed the data to grow larger than the
ulimit.

However, I did find that setting the limit on total virtual memory did
take affect and blocked the program from running.

I will be looking into the vm's allocation and growth code to see if I
can determine why the limit is not being enforced.


Bill Braswell

$ cat ulimit_static.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>


#define ALLOC_SIZE 1024
#define CELL_COUNT 2000

char   array[ALLOC_SIZE * CELL_COUNT];

main ()
{
        struct rlimit datasize;
        int    index;

        if (-1 == getrlimit (RLIMIT_DATA, &datasize))
                perror ("Error getting limit values");
        else
                printf ("Data limit is: %lu\\n", datasize.rlim_cur);

        for (index = 0; index <= (ALLOC_SIZE * CELL_COUNT); index +=
4096)
                array[index] = 0;
        printf("paged in %ld bytes of memory\\n", (ALLOC_SIZE *
CELL_COUNT));
        if (-1 == getrlimit (RLIMIT_DATA, &datasize))
                perror ("Error getting limit values");
        else
                printf ("Data limit is: %lu\\n", datasize.rlim_cur);
}

$ ulimit -d 10
$ ./ulimit_static
Data limit is: 10240
paged in 2048000 bytes of memory
Data limit is: 10240
$ ulimit -v 1024
[bbraswel@bbraswel tmp]$ ./ulimit_static
Killed


This event sent from IssueTracker by bbraswel  [Support Engineering Group]
 issue 165270

Is there any progress on this?  Our developers want ulimit -d to work, we're
aware that ulimit -v works, but it's not the best choice for this particular
application.  I'll get more specifics.

Created attachment 309783 [details]
rlimit test patch

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Please let us know if the customer needs a test kernel or test rpm 
with the test patch stated in comment#13.

many thanks.

Providing the patched kernel or a test rpm would greatly help and speed up
testing on our side for providing feedback.

You can get test kernel based on RHEL-4u6 at
http://people.redhat.com/vmayatsk/bz437214/

Only i686 and x86_64 packages are available (disk quota limits).

Thanks for the test rpms. I have installed the x86_64 kernel packages and
testing is looking good so far with ulimit now actually limiting the memory:

$ ./testRLimit
Data limit is: 18446744073709551615
[35000]Total allocation = 2293760000
$ ./malloctest
Data limit is: 18446744073709551615
[35000]Total allocation = 2293760000
$ ulimit -d 10
$ ./testRLimit
Segmentation fault (core dumped)
$ ./malloctest
Segmentation fault (core dumped)

The kernel and patch have been running now for a good while with no issues to be
seen, thanks once again. Is there an ETA on when this will be packaged into a
release?

What does updating PM score mean?  Can we expect this to be in a release soon?

any progress here. I'm a paying customer and I'd like to get it fixed. is the best route to call this into redhat and just point to this bugzilla?

Still awaiting a response as well, will this be fixed in 4.8 release?

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.