lkml.org 
[lkml]   [1997]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kernel programming questions


    On Tue, 1 Jul 1997, Tim Hollebeek wrote:

    > Richard B. Johnson writes ...
    > >
    > > On Mon, 30 Jun 1997, Michael Bruck wrote:
    > >
    > > > Ok, two short questions:
    > > >
    > > > Is there a arch-independant type available for the
    > > > save_flags macro ? (flags_t ??)
    > > >

    No, anyway the save_flags macro is defined in a very different way for UP
    (where it actually saves the contents of the 32 bit EFLAGS register) and
    SMP, where it actually returns a value (boolean on x86, integer between 0
    and 2 on SPARC) to tell restore_flags what to do wrt the global irq lock.

    The name save_flags and restore_flags are actually misleading for SMP
    machines.

    BTW: for the SPARC, there is a macro called save_and_cli, which performs
    the equivalent of save_flags followed by cli, this is very frequent in the
    code and should be generalized to all architectures, some will benefit.
    On PPC for example, cli() is a read modify write of the MSR (PSR on
    SPARC), and reading this register twice is quite expensive (each "move
    from MSR" costs the equivalent of up to 12 "normal" instructions on a 604).

    > > > Is there a problem that could prevent one from using memory
    > > > alloc'd from stack in the kernel like
    > > >
    > > > int foo(int bar)
    > > > {
    > > > int foo_bar[bar];
    > > > ...
    > > > }
    > >
    > > Even though that works.... There SHOULD be a problem with it! Don't
    > > write code like that. For some reason gcc lets you get away with it.
    > > If you must write code like that it's broken from the start. Automatic
    > > variables are supposed to be automatic, not dynamic.
    >
    > First of all, the point that only gcc supports it isn't that important
    > since Linux already uses a _ton_ of gcc-isms. Second, C9X will add
    > support for the above to the official C language, so it isn't that evil.

    It isn't evil, it's a potential kernel stack bomb. This should only be done
    if you are _absolutely_ sure that it's only for a few tens of bytes.
    And in this case you should allocate an array of the maximum size you
    expect. There is hidden overhead with this type of declaration, i.e., that
    the compiler has to keep somewhere (in the stack) a pointer to the base
    address of each such variable. It also has to reload this pointer when the
    variable is accessed and registers are in short supply (always on x86).
    OTOH, it is perfectly acceptable in user code, and it helps to avoid
    memory leaks.

    Gabriel

    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:4.698 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site