[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fork: out of memory
    Zlatko Calusic wrote:

    > These extra allocations would go to get_unused_fd() in fs/open.c.
    > I didn't find any other place (but I just started working on it, it will
    > take some time).
    > Some preliminary searching showed me that I will have to modify at
    > least 50 files!!! No big things, but absolutely neccessary if you ask
    > me (unless I have problems in logic :)).
    > Now the question:
    > When you say "atomically" do you mean "in one place" or with
    > GFP_ATOMIC? I understand differences between *_KERNEL and *_ATOMIC,
    > but... I'm not sure which one should be used in this case.
    > My vote for kmalloc(x, SLAB_KERNEL). :)
    > But, maybe I should doublecheck.
    > Well, whatever, my system will be first in line for corruptions. :)

    I think doing the array expansion in get_unused_fd should work fine, and
    there shouldn't be an atomicity problem if you allocate the new array
    first, then copy. The only trick to watch for is that after you
    allocate, check again that you still need the new space -- somebody else
    might have done the work first. No problem, just release the memory and

    Another trick you could use: put a function pointer to the routine to be
    used to free the array. At first it would be NULL if the first array is
    part of the files structure itself. Then it becomes kfree(), then
    possibly free_page() if you want to use a full page for the 1024 case.

    One more minor cleanup -- if there are many places in the kernel using
    files structures, maybe it would be worthwhile to define some wrapper
    routines for the oeprations, so that if we want to change the files
    structure again it will be easier to do so.


     \ /
      Last update: 2005-03-22 13:40    [W:0.020 / U:0.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site