Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

Ingo Molnar wrote:
* Mike Travis <travis@xxxxxxx> wrote:

could you please send whatever .c changes you have already, so that
we can have a look at how the end result will look like? Doesnt have
to build, i'm just curious about how it looks like in practice,
semantically.

I will, and the full "allyesconfig" does compile. And it's basically
a benign change in that the functionality is still the same. I'm
currently reordering it a bit to clean it up.

btw., are the resulting instructions also expected to be the same? If
yes then you might want to verify it all by making sure the md5's of the
.o's do not change.

(If that's not possible (gcc decides to compile it a bit differently)
then no big deal, just wanted to mention the possibility.)

Ingo

Well, not exactly... ;-) It does institute the new API change that specifies
only pointers to cpumask's can be passed to functions and returned from
functions. I really wanted the default cpumask_t to be a constant so those
instances where the passed in cpumask is used as a read/write temp variable
would be caught. But it started getting messy.

One pain is:

typedef struct __cpumask_s *cpumask_t;
const cpumask_t xxx;

is not the same as:

typedef const struct __cpumask_s *const_cpumask_t;
const_cpumask_t xxx;

and I'm not exactly sure why. It came up when I tried to declare
functions that returned a constant cpumask_t pointer (node_to_cpumask,
cpumask_of_cpu, etc.)

The other major change I'm contemplating is to remove "cpumask_t" completely
(maybe cpumask_ptr_t?). This would force every instance of cpumask_t to be
examined. (I found quite a few I had missed in my original edits when I
added the task struct temp cpumask's.)

Oh yeah, one question ... is "current" always valid?

Thanks,
Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Idea
    ... But stand-alone function pointers don't carry as much information ... The const block declares things that are CONSTANT, ... ALL functions reside in the ... that "AT COMPILE TIME", just like constants, functions are put in a specific ...
    (comp.lang.pascal.delphi.misc)
  • Re: dynamic types
    ... CodeDom so any pointers on how to use it is helpful. ... ahead of time using CodeDom and then compile them into the assembly that ... versioning to compare the two type descriptions and then only do the real ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: memmove crash
    ... Pointers and ints are not the same size on all systems. ... system doesn't compile on yours, then I think I definately want to go back to assembly language. ... I can take an assembly program and recompile it on any other x86 linux system and it will compile and work without a problem, whereas if you take a C program that compiles on one person's x86 linux system, it may or may not compile on another's. ... If a program assembles and works on one x86 linux system, it will assemble and work on another x86 linux system just the same. ...
    (alt.lang.asm)
  • [RFC] [PATCH] 32-bit pointers in x86-64
    ... usage due to 64-bit pointers and longs in structures. ... such a GCC version could be used to produce a GNU/Linux ... Compile a native x86-32 libc and compile and test a full Debian or ... emit_move_insn (temp, val); ...
    (Linux-Kernel)
  • Re: F-16 OFP written in C++?
    ... I thought the big advantage of Ada was that it won't compile if a ... levels of indirection (pointers to pointers) which is sensible. ... testing environment. ... language can do exactly what ADA does. ...
    (rec.aviation.military)