[lkml]   [2001]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectMaximum size of automatic allocation? (was: [PATCH] fs/devfs/base.c)
    On Sunday 27 May 2001 15:21, Richard Gooch wrote:
    > Akash Jain writes:
    > > in fs/devfs/base.c,
    > > the struct devfsd_notify_struct is approx 1056 bytes, allocating it
    > > on a stack of 8k seems unreasonable. here we simply move it to the
    > > heap, i don't think it is a _must_ be on stack type thing
    > I absolutely don't want this patch applied. It's bogus. It is
    > entirely safe to alloc 1 kB on the stack in this code, since it has a
    > short and well-controlled code path from syscall entry to the
    > function. This is not some function that can be called from some
    > random place in the kernel and thus has a random call path.
    > Using the stack is much faster than calling kmalloc() and it also
    > doesn't add to system memory pressure. That's why I did it this way
    > in the first place. Further, it's much safer to use the stack, since
    > the memory is freed automatically. Thus, there's less scope for
    > introducing errors.
    > Please fix your checker to deal with this class of functions which
    > have a well-defined call path. I'd suggest looking at the total stack
    > allocations from syscall entry point all the way to the end function.
    > Ideally, you'd trace the call path to every function, but of course
    > that may be computationally infeasible. Hopefully it's feasible to do
    > this for any function which has a stack allocation which exceeds some
    > threshold.

    I did the same thing in my directory indexing patch, but with a much
    larger buffer: 2728 bytes. I traced the path from the syscall and all
    the paths out as well. I did cause a stack overflow with this because
    gcc took the union of two such allocations in different control blocks
    instead of the intersection, much to my surprise. This was cured by
    using fancier code to eliminate one of the allocations. Al since broke
    this out into a separate function, making it more obviously safe, but
    note: it has to be broken out further so that there are no complex
    trees of calls descending from the stack storage pig.

    This call appends a new block to a file then splits the contents of
    some other block into the new block using some workspace on the stack.
    The block has to be appended outside the function, otherwise the big
    stack allocation gets carried arbitrarily far through the kernel (think
    recursive allocation). Similarly for mark_buffer_dirty and just to be
    safe, brelse as well. Mark_buffer_dirty didn't use to have a big hairy
    call chain attached to it but it does now. Even lowly brelse might
    evolve this way without warning. The only safe thing to do is avoid
    all calls outside the subystem and comment the others.

    My question: assuming the entire call chain is documented, exactly how
    much of the 8K kernel stack is safe to use?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:54    [W:0.023 / U:5.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site