lkml.org 
[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
continue.

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.

Regards,
Bill

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean