1. 07 3月, 2016 1 次提交
    • M
      powerpc/module: Only try to generate the ftrace_caller() stub once · 136cd345
      Michael Ellerman 提交于
      Currently we generate the module stub for ftrace_caller() at the bottom
      of apply_relocate_add(). However apply_relocate_add() is potentially
      called more than once per module, which means we will try to generate
      the ftrace_caller() stub multiple times.
      
      Although the current code deals with that correctly, ie. it only
      generates a stub the first time, it would be clearer to only try to
      generate the stub once.
      
      Note also on first reading it may appear that we generate a different
      stub for each section that requires relocation, but that is not the
      case. The code in stub_for_addr() that searches for an existing stub
      uses sechdrs[me->arch.stubs_section], ie. the single stub section for
      this module.
      
      A cleaner approach is to only generate the ftrace_caller() stub once,
      from module_finalize(). Although the original code didn't check to see
      if the stub was actually generated correctly, it seems prudent to add a
      check, so do that. And an additional benefit is we can clean the ifdefs
      up a little.
      
      Finally we must propagate the const'ness of some of the pointers passed
      to module_finalize(), but that is also an improvement.
      Reviewed-by: NBalbir Singh <bsingharora@gmail.com>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      136cd345
  2. 05 12月, 2015 1 次提交
  3. 02 10月, 2014 1 次提交
  4. 30 10月, 2013 1 次提交
  5. 08 6月, 2012 1 次提交
    • S
      powerpc: Fix kernel panic during kernel module load · 3c752965
      Steffen Rumler 提交于
      This fixes a problem which can causes kernel oopses while loading
      a kernel module.
      
      According to the PowerPC EABI specification, GPR r11 is assigned
      the dedicated function to point to the previous stack frame.
      In the powerpc-specific kernel module loader, do_plt_call()
      (in arch/powerpc/kernel/module_32.c), GPR r11 is also used
      to generate trampoline code.
      
      This combination crashes the kernel, in the case where the compiler
      chooses to use a helper function for saving GPRs on entry, and the
      module loader has placed the .init.text section far away from the
      .text section, meaning that it has to generate a trampoline for
      functions in the .init.text section to call the GPR save helper.
      Because the trampoline trashes r11, references to the stack frame
      using r11 can cause an oops.
      
      The fix just uses GPR r12 instead of GPR r11 for generating the
      trampoline code.  According to the statements from Freescale, this is
      safe from an EABI perspective.
      
      I've tested the fix for kernel 2.6.33 on MPC8541.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteffen Rumler <steffen.rumler.ext@nsn.com>
      [paulus@samba.org: reworded the description]
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3c752965
  6. 24 7月, 2011 1 次提交
  7. 21 11月, 2008 1 次提交
  8. 01 7月, 2008 1 次提交
  9. 21 12月, 2007 1 次提交
    • E
      [POWERPC] Optimize counting distinct entries in the relocation sections · eda09fbd
      Emil Medve 提交于
      When a module has relocation sections with tens of thousands of
      entries, counting the distinct/unique entries only (i.e. no
      duplicates) at load time can take tens of seconds and up to minutes.
      The sore point is the count_relocs() function which is called as part
      of the architecture specific module loading processing path:
      
      	-> load_module()			generic
      	   -> module_frob_arch_sections()	arch specific
      	      -> get_plt_size()		32-bit
      	      -> get_stubs_size()	64-bit
      		 -> count_relocs()
      
      Here count_relocs is being called to find out how many distinct
      targets of R_PPC_REL24 relocations there are, since each distinct
      target needs a PLT entry or a stub created for it.
      
      The previous counting algorithm has O(n^2) complexity.  Basically two
      solutions were proposed on the e-mail list: a hash based approach and
      a sort based approach.
      
      The hash based approach is the fastest (O(n)) but the has it needs
      additional memory and for certain corner cases it could take lots of
      memory due to the degeneration of the hash.  One such proposal was
      submitted here:
      
      http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
      
      The sort based approach is slower (O(n * log n + n)) but if the
      sorting is done "in place" it doesn't need additional memory.
      This has O(n + n * log n) complexity with no additional memory
      requirements.
      
      This commit implements the in-place sort option.
      Signed-off-by: NEmil Medve <Emilian.Medve@Freescale.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      eda09fbd
  10. 24 1月, 2007 1 次提交
  11. 11 12月, 2006 1 次提交
    • J
      [POWERPC] Generic BUG for powerpc · 73c9ceab
      Jeremy Fitzhardinge 提交于
      This makes powerpc use the generic BUG machinery.  The biggest reports the
      function name, since it is redundant with kallsyms, and not needed in general.
      
      There is an overall reduction of code, since module_32/64 duplicated several
      functions.
      
      Unfortunately there's no way to tell gcc that BUG won't return, so the BUG
      macro includes a goto loop.  This will generate a real jmp instruction, which
      is never used.
      
      [akpm@osdl.org: build fix]
      [paulus@samba.org: remove infinite loop in BUG_ON]
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      73c9ceab
  12. 25 10月, 2006 1 次提交
  13. 27 3月, 2006 1 次提交
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4