1. 24 6月, 2009 1 次提交
    • T
      linker script: throw away .discard section · 405d967d
      Tejun Heo 提交于
      x86 throws away .discard section but no other archs do.  Also,
      .discard is not thrown away while linking modules.  Make every arch
      and module linking throw it away.  This will be used to define dummy
      variables for percpu declarations and definitions.
      
      This patch is based on Ivan Kokshaysky's alpha percpu patch.
      
      [ Impact: always throw away everything in .discard ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Bryan Wu <cooloney@kernel.org>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      405d967d
  2. 13 5月, 2008 1 次提交
  3. 29 1月, 2008 1 次提交
  4. 17 10月, 2007 1 次提交
    • J
      uml: throw out CONFIG_MODE_TT · 42fda663
      Jeff Dike 提交于
      This patchset throws out tt mode, which has been non-functional for a while.
      
      This is done in phases, interspersed with code cleanups on the affected files.
      
      The removal is done as follows:
      	remove all code, config options, and files which depend on
      CONFIG_MODE_TT
      	get rid of the CHOOSE_MODE macro, which decided whether to
      call tt-mode or skas-mode code, and replace invocations with their
      skas portions
      	replace all now-trivial procedures with their skas equivalents
      
      There are now a bunch of now-redundant pieces of data structures, including
      mode-specific pieces of the thread structure, pt_regs, and mm_context.  These
      are all replaced with their skas-specific contents.
      
      As part of the ongoing style compliance project, I made a style pass over all
      files that were changed.  There are three such patches, one for each phase,
      covering the files affected by that phase but no later ones.
      
      I noticed that we weren't freeing the LDT state associated with a process when
      it exited, so that's fixed in one of the later patches.
      
      The last patch is a tidying patch which I've had for a while, but which caused
      inexplicable crashes under tt mode.  Since that is no longer a problem, this
      can now go in.
      
      This patch:
      
      Start getting rid of tt mode support.
      
      This patch throws out CONFIG_MODE_TT and all config options, code, and files
      which depend on it.
      
      CONFIG_MODE_SKAS is gone and everything that depends on it is included
      unconditionally.
      
      The few changed lines are in re-written Kconfig help, lines which needed
      something skas-related removed from them, and a few more which weren't
      strictly deletions.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42fda663
  5. 31 8月, 2007 1 次提交
  6. 19 5月, 2007 2 次提交
  7. 11 5月, 2007 1 次提交
    • J
      uml: iRQ stacks · c14b8494
      Jeff Dike 提交于
      Add a separate IRQ stack.  This differs from i386 in having the entire
      interrupt run on a separate stack rather than starting on the normal kernel
      stack and switching over once some preparation has been done.  The underlying
      mechanism, is of course, sigaltstack.
      
      Another difference is that interrupts that happen in userspace are handled on
      the normal kernel stack.  These cause a wait wakeup instead of a signal
      delivery so there is no point in trying to switch stacks for these.  There's
      no other stuff on the stack, so there is no extra stack consumption.
      
      This quirk makes it possible to have the entire interrupt run on a separate
      stack - process preemption (and calls to schedule()) happens on a normal
      kernel stack.  If we enable CONFIG_PREEMPT, this will need to be rethought.
      
      The IRQ stack for CPU 0 is declared in the same way as the initial kernel
      stack.  IRQ stacks for other CPUs will be allocated dynamically.
      
      An extra field was added to the thread_info structure.  When the active
      thread_info is copied to the IRQ stack, the real_thread field points back to
      the original stack.  This makes it easy to tell where to copy the thread_info
      struct back to when the interrupt is finished.  It also serves as a marker of
      a nested interrupt.  It is NULL for the first interrupt on the stack, and
      non-NULL for any nested interrupts.
      
      Care is taken to behave correctly if a second interrupt comes in when the
      thread_info structure is being set up or taken down.  I could just disable
      interrupts here, but I don't feel like giving up any of the performance gained
      by not flipping signals on and off.
      
      If an interrupt comes in during these critical periods, the handler can't run
      because it has no idea what shape the stack is in.  So, it sets a bit for its
      signal in a global mask and returns.  The outer handler will deal with this
      signal itself.
      
      Atomicity is had with xchg.  A nested interrupt that needs to bail out will
      xchg its signal mask into pending_mask and repeat in case yet another
      interrupt hit at the same time, until the mask stabilizes.
      
      The outermost interrupt will set up the thread_info and xchg a zero into
      pending_mask when it is done.  At this point, nested interrupts will look at
      ->real_thread and see that no setup needs to be done.  They can just continue
      normally.
      
      Similar care needs to be taken when exiting the outer handler.  If another
      interrupt comes in while it is copying the thread_info, it will drop a bit
      into pending_mask.  The outer handler will check this and if it is non-zero,
      will loop, set up the stack again, and handle the interrupt.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c14b8494
  8. 01 11月, 2006 1 次提交
  9. 01 8月, 2006 1 次提交
    • R
      [PATCH] vDSO hash-style fix · 0b0bf7a3
      Roland McGrath 提交于
      The latest toolchains can produce a new ELF section in DSOs and
      dynamically-linked executables.  The new section ".gnu.hash" replaces
      ".hash", and allows for more efficient runtime symbol lookups by the
      dynamic linker.  The new ld option --hash-style={sysv|gnu|both} controls
      whether to produce the old ".hash", the new ".gnu.hash", or both.  In some
      new systems such as Fedora Core 6, gcc by default passes --hash-style=gnu
      to the linker, so that a standard invocation of "gcc -shared" results in
      producing a DSO with only ".gnu.hash".  The new ".gnu.hash" sections need
      to be dealt with the same way as ".hash" sections in all respects; only the
      dynamic linker cares about their contents.  To work with older dynamic
      linkers (i.e.  preexisting releases of glibc), a binary must have the old
      ".hash" section.  The --hash-style=both option produces binaries that a new
      dynamic linker can use more efficiently, but an old dynamic linker can
      still handle.
      
      The new section runs afoul of the custom linker scripts used to build vDSO
      images for the kernel.  On ia64, the failure mode for this is a boot-time
      panic because the vDSO's PT_IA_64_UNWIND segment winds up ill-formed.
      
      This patch addresses the problem in two ways.
      
      First, it mentions ".gnu.hash" in all the linker scripts alongside ".hash".
       This produces correct vDSO images with --hash-style=sysv (or old tools),
      with --hash-style=gnu, or with --hash-style=both.
      
      Second, it passes the --hash-style=sysv option when building the vDSO
      images, so that ".gnu.hash" is not actually produced.  This is the most
      conservative choice for compatibility with any old userland.  There is some
      concern that some ancient glibc builds (though not any known old production
      system) might choke on --hash-style=both binaries.  The optimizations
      provided by the new style of hash section do not really matter for a DSO
      with a tiny number of symbols, as the vDSO has.  If someone wants to use
      =gnu or =both for their vDSO builds and worry less about that
      compatibility, just change the option and the linker script changes will
      make any choice work fine.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b0bf7a3
  10. 11 9月, 2005 1 次提交
    • P
      [PATCH] i386 / uml: add dwarf sections to static link script · a7d0c210
      Paolo 'Blaisorblade' Giarrusso 提交于
      Inside the linker script, insert the code for DWARF debug info sections. This
      may help GDB'ing a Uml binary. Actually, it seems that ld is able to guess
      what I added correctly, but normal linker scripts include this section so it
      should be correct anyway adding it.
      
      On request by Sam Ravnborg <sam@ravnborg.org>, I've added it to
      asm-generic/vmlinux.lds.s. I've also moved there the stabs debug section,
      used the new macro in i386 linker script and added DWARF debug section to
      that.
      
      In the truth, I've not been able to verify the difference in GDB behaviour
      after this change (I've seen large improvements with another patch). This
      may depend on my binutils version, older one may have worse defaults.
      
      However, this section is present in normal linker script, so add it at
      least for the sake of cleanness.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a7d0c210
  11. 08 7月, 2005 1 次提交
    • J
      [PATCH] uml: skas0 - separate kernel address space on stock hosts · d67b569f
      Jeff Dike 提交于
      UML has had two modes of operation - an insecure, slow mode (tt mode) in
      which the kernel is mapped into every process address space which requires
      no host kernel modifications, and a secure, faster mode (skas mode) in
      which the UML kernel is in a separate host address space, which requires a
      patch to the host kernel.
      
      This patch implements something very close to skas mode for hosts which
      don't support skas - I'm calling this skas0.  It provides the security of
      the skas host patch, and some of the performance gains.
      
      The two main things that are provided by the skas patch, /proc/mm and
      PTRACE_FAULTINFO, are implemented in a way that require no host patch.
      
      For the remote address space changing stuff (mmap, munmap, and mprotect),
      we set aside two pages in the process above its stack, one of which
      contains a little bit of code which can call mmap et al.
      
      To update the address space, the system call information (system call
      number and arguments) are written to the stub page above the code.  The
      %esp is set to the beginning of the data, the %eip is set the the start of
      the stub, and it repeatedly pops the information into its registers and
      makes the system call until it sees a system call number of zero.  This is
      to amortize the cost of the context switch across multiple address space
      updates.
      
      When the updates are done, it SIGSTOPs itself, and the kernel process
      continues what it was doing.
      
      For a PTRACE_FAULTINFO replacement, we set up a SIGSEGV handler in the
      child, and let it handle segfaults rather than nullifying them.  The
      handler is in the same page as the mmap stub.  The second page is used as
      the stack.  The handler reads cr2 and err from the sigcontext, sticks them
      at the base of the stack in a faultinfo struct, and SIGSTOPs itself.  The
      kernel then reads the faultinfo and handles the fault.
      
      A complication on x86_64 is that this involves resetting the registers to
      the segfault values when the process is inside the kill system call.  This
      breaks on x86_64 because %rcx will contain %rip because you tell SYSRET
      where to return to by putting the value in %rcx.  So, this corrupts $rcx on
      return from the segfault.  To work around this, I added an
      arch_finish_segv, which on x86 does nothing, but which on x86_64 ptraces
      the child back through the sigreturn.  This causes %rcx to be restored by
      sigreturn and avoids the corruption.  Ultimately, I think I will replace
      this with the trick of having it send itself a blocked signal which will be
      unblocked by the sigreturn.  This will allow it to be stopped just after
      the sigreturn, and PTRACE_SYSCALLed without all the back-and-forth of
      PTRACE_SYSCALLing it through sigreturn.
      
      This runs on a stock host, so theoretically (and hopefully), tt mode isn't
      needed any more.  We need to make sure that this is better in every way
      than tt mode, though.  I'm concerned about the speed of address space
      updates and page fault handling, since they involve extra round-trips to
      the child.  We can amortize the round-trip cost for large address space
      updates by writing all of the operations to the data page and having the
      child execute them all at the same time.  This will help fork and exec, but
      not page faults, since they involve only one page.
      
      I can't think of any way to help page faults, except to add something like
      PTRACE_FAULTINFO to the host.  There is PTRACE_SIGINFO, but UML doesn't use
      siginfo for SIGSEGV (or anything else) because there isn't enough
      information in the siginfo struct to handle page faults (the faulting
      operation type is missing).  Adding that would make PTRACE_SIGINFO a usable
      equivalent to PTRACE_FAULTINFO.
      
      As for the code itself:
      
      - The system call stub is in arch/um/kernel/sys-$(SUBARCH)/stub.S.  It is
        put in its own section of the binary along with stub_segv_handler in
        arch/um/kernel/skas/process.c.  This is manipulated with run_syscall_stub
        in arch/um/kernel/skas/mem_user.c.  syscall_stub will execute any system
        call at all, but it's only used for mmap, munmap, and mprotect.
      
      - The x86_64 stub calls sigreturn by hand rather than allowing the normal
        sigreturn to happen, because the normal sigreturn is a SA_RESTORER in
        UML's address space provided by libc.  Needless to say, this is not
        available in the child's address space.  Also, it does a couple of odd
        pops before that which restore the stack to the state it was in at the
        time the signal handler was called.
      
      - There is a new field in the arch mmu_context, which is now a union.
        This is the pid to be manipulated rather than the /proc/mm file
        descriptor.  Code which deals with this now checks proc_mm to see whether
        it should use the usual skas code or the new code.
      
      - userspace_tramp is now used to create a new host process for every UML
        process, rather than one per UML processor.  It checks proc_mm and
        ptrace_faultinfo to decide whether to map in the pages above its stack.
      
      - start_userspace now makes CLONE_VM conditional on proc_mm since we need
        separate address spaces now.
      
      - switch_mm_skas now just sets userspace_pid[0] to the new pid rather
        than PTRACE_SWITCH_MM.  There is an addition to userspace which updates
        its idea of the pid being manipulated each time around the loop.  This is
        important on exec, when the pid will change underneath userspace().
      
      - The stub page has a pte, but it can't be mapped in using tlb_flush
        because it is part of tlb_flush.  This is why it's required for it to be
        mapped in by userspace_tramp.
      
      Other random things:
      
      - The stub section in uml.lds.S is page aligned.  This page is written
        out to the backing vm file in setup_physmem because it is mapped from
        there into user processes.
      
      - There's some confusion with TASK_SIZE now that there are a couple of
        extra pages that the process can't use.  TASK_SIZE is considered by the
        elf code to be the usable process memory, which is reasonable, so it is
        decreased by two pages.  This confuses the definition of
        USER_PGDS_IN_LAST_PML4, making it too small because of the rounding down
        of the uneven division.  So we round it to the nearest PGDIR_SIZE rather
        than the lower one.
      
      - I added a missing PT_SYSCALL_ARG6_OFFSET macro.
      
      - um_mmu.h was made into a userspace-usable file.
      
      - proc_mm and ptrace_faultinfo are globals which say whether the host
        supports these features.
      
      - There is a bad interaction between the mm.nr_ptes check at the end of
        exit_mmap, stack randomization, and skas0.  exit_mmap will stop freeing
        pages at the PGDIR_SIZE boundary after the last vma.  If the stack isn't
        on the last page table page, the last pte page won't be freed, as it
        should be since the stub ptes are there, and exit_mmap will BUG because
        there is an unfreed page.  To get around this, TASK_SIZE is set to the
        next lowest PGDIR_SIZE boundary and mm->nr_ptes is decremented after the
        calls to init_stub_pte.  This ensures that we know the process stack (and
        all other process mappings) will be below the top page table page, and
        thus we know that mm->nr_ptes will be one too many, and can be
        decremented.
      
      Things that need fixing:
      
      - We may need better assurrences that the stub code is PIC.
      
      - The stub pte is set up in init_new_context_skas.
      
      - alloc_pgdir is probably the right place.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d67b569f
  12. 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