24 Jul, 2011

1 commit

  • This patch removes all the module loader hook implementations in the
    architecture specific code where the functionality is the same as that
    now provided by the recently added default hooks.

    Signed-off-by: Jonas Bonn
    Acked-by: Mike Frysinger
    Acked-by: Geert Uytterhoeven
    Tested-by: Michal Simek
    Signed-off-by: Rusty Russell

    Jonas Bonn
     

18 Jun, 2009

1 commit

  • It is generally agreed that it would be beneficial for u64 to be an
    unsigned long long on all architectures. ia64 (in common with several
    other 64-bit architectures) currently uses unsigned long. Migrating
    piecemeal is too painful; this giant patch fixes all compilation warnings
    and errors that come as a result of switching to use int-ll64.h.

    Note that userspace will still see __u64 defined as unsigned long. This
    is important as it affects C++ name mangling.

    [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
    u64 for start/end rather than unsigned long]

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Tony Luck

    Matthew Wilcox
     

02 Apr, 2009

1 commit


27 Mar, 2009

1 commit


11 Sep, 2008

1 commit

  • Broke the non modular builds by moving an essential function into
    modules.c. Fix this by moving it out again and into asm/sections.h as
    an inline. To do this, the definitions of struct fdesc and struct
    got_val have been lifted out of modules.c and put in asm/elf.h where
    they belong.

    Signed-off-by: James Bottomley
    Signed-off-by: Tony Luck

    James Bottomley
     

10 Sep, 2008

1 commit

  • It was introduced by "vsprintf: add support for '%pS' and '%pF' pointer
    formats" in commit 0fe1ef24f7bd0020f29ffe287dfdb9ead33ca0b2. However,
    the current way its coded doesn't work on parisc64. For two reasons: 1)
    parisc isn't in the #ifdef and 2) parisc has a different format for
    function descriptors

    Make dereference_function_descriptor() more accommodating by allowing
    architecture overrides. I put the three overrides (for parisc64, ppc64
    and ia64) in arch/kernel/module.c because that's where the kernel
    internal linker which knows how to deal with function descriptors sits.

    Signed-off-by: James Bottomley
    Acked-by: Benjamin Herrenschmidt
    Acked-by: Tony Luck
    Acked-by: Kyle McMartin
    Signed-off-by: Linus Torvalds

    James Bottomley
     

18 Jul, 2008

1 commit

  • module_free() refers the first parameter before checking.
    But it is called like below(in kernel/kprobes). The first parameter is always NULL.
    This happens when many probe points(>1024) are set by kprobes.
    I encountered this with using SystemTap. It can set many probes easily.

    static int __kprobes collect_one_slot(struct kprobe_insn_page *kip, int idx)
    {
    ...
    if (kip->nused == 0) {
    hlist_del(&kip->hlist);
    if (hlist_empty(&kprobe_insn_pages)) {
    ...
    } else {
    module_free(NULL, kip->insns); //<<< 1st param always NULL
    kfree(kip);
    }
    return 1;
    }
    return 0;
    }

    Signed-off-by: Akiyama, Nobuyuki
    Signed-off-by: Tony Luck

    Akiyama, Nobuyuki
     

07 Mar, 2008

1 commit


31 Jan, 2008

1 commit


30 Jan, 2008

1 commit

  • - add support for PER_CPU_ATTRIBUTES

    - fix generic smp percpu_modcopy to use per_cpu_offset() macro.

    Add the ability to use generic/percpu even if the arch needs to override
    several aspects of its operations. This will enable the use of generic
    percpu.h for all arches.

    An arch may define:

    __per_cpu_offset Do not use the generic pointer array. Arch must
    define per_cpu_offset(cpu) (used by x86_64, s390).

    __my_cpu_offset Can be defined to provide an optimized way to determine
    the offset for variables of the currently executing
    processor. Used by ia64, x86_64, x86_32, sparc64, s/390.

    SHIFT_PTR(ptr, offset) If an arch defines it then special handling
    of pointer arithmentic may be implemented. Used
    by s/390.

    (Some of these special percpu arch implementations may be later consolidated
    so that there are less cases to deal with.)

    Cc: Rusty Russell
    Cc: Andi Kleen
    Signed-off-by: Christoph Lameter
    Signed-off-by: Mike Travis
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    travis@sgi.com
     

12 May, 2007

1 commit


01 Jul, 2006

1 commit


07 Apr, 2006

1 commit

  • for_each_cpu() actually iterates across all possible CPUs. We've had mistakes
    in the past where people were using for_each_cpu() where they should have been
    iterating across only online or present CPUs. This is inefficient and
    possibly buggy.

    We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the
    future.

    This patch replaces for_each_cpu with for_each_possible_cpu under
    arch/ia64/kernel/.

    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Andrew Morton
    Signed-off-by: Tony Luck

    KAMEZAWA Hiroyuki
     

26 Oct, 2005

1 commit

  • In arch/ia64 change the explicit use of for-loops and NR_CPUS into the
    general for_each_cpu() or for_each_online_cpu() constructs, as
    appropriate. This widens the scope of potential future optimizations
    of the general constructs, as well as takes advantage of the existing
    optimizations of first_cpu() and next_cpu().

    Signed-off-by: John Hawkes
    Signed-off-by: Tony Luck

    hawkes@sgi.com
     

09 Jun, 2005

1 commit

  • Some bits of the kernel assume that gp always points to valid memory,
    in particular PHYSICAL_MODE_ENTER() assumes that both gp and sp are
    valid virtual addresses with associated physical pages. The IA64
    module loader puts gp well past the end of the module, with no physical
    backing. Offsets on gp are still valid, but physical mode addressing
    breaks for modules. Ensure that gp always falls within the module
    body. Also ensure that gp is 8 byte aligned.

    Signed-off-by: Keith Owens
    Signed-off-by: Tony Luck

    Keith Owens
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds