1. 17 10月, 2007 27 次提交
  2. 20 9月, 2007 1 次提交
    • J
      uml: fix irqstack crash · 508a9274
      Jeff Dike 提交于
      This patch fixes a crash caused by an interrupt coming in when an IRQ stack
      is being torn down.  When this happens, handle_signal will loop, setting up
      the IRQ stack again because the tearing down had finished, and handling
      whatever signals had come in.
      
      However, to_irq_stack returns a mask of pending signals to be handled, plus
      bit zero is set if the IRQ stack was already active, and thus shouldn't be
      torn down.  This causes a problem because when handle_signal goes around
      the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
      returned mask, faking handle_signal into believing that it shouldn't tear
      down the IRQ stack and return thread_info pointers back to their original
      values.
      
      This will eventually cause a crash, as the IRQ stack thread_info will
      continue pointing to the original task_struct and an interrupt will look
      into it after it has been freed.
      
      The fix is to stop passing a signal number into to_irq_stack.  Rather, the
      pending signals mask is initialized beforehand with the bit for sig already
      set.  References to sig in to_irq_stack can be replaced with references to
      the mask.
      
      [akpm@linux-foundation.org: use UL]
      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>
      508a9274
  3. 31 8月, 2007 1 次提交
  4. 30 7月, 2007 1 次提交
    • A
      Remove fs.h from mm.h · 4e950f6f
      Alexey Dobriyan 提交于
      Remove fs.h from mm.h. For this,
       1) Uninline vma_wants_writenotify(). It's pretty huge anyway.
       2) Add back fs.h or less bloated headers (err.h) to files that need it.
      
      As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files
      rebuilt down to 3444 (-12.3%).
      
      Cross-compile tested without regressions on my two usual configs and (sigh):
      
      alpha              arm-mx1ads        mips-bigsur          powerpc-ebony
      alpha-allnoconfig  arm-neponset      mips-capcella        powerpc-g5
      alpha-defconfig    arm-netwinder     mips-cobalt          powerpc-holly
      alpha-up           arm-netx          mips-db1000          powerpc-iseries
      arm                arm-ns9xxx        mips-db1100          powerpc-linkstation
      arm-assabet        arm-omap_h2_1610  mips-db1200          powerpc-lite5200
      arm-at91rm9200dk   arm-onearm        mips-db1500          powerpc-maple
      arm-at91rm9200ek   arm-picotux200    mips-db1550          powerpc-mpc7448_hpc2
      arm-at91sam9260ek  arm-pleb          mips-ddb5477         powerpc-mpc8272_ads
      arm-at91sam9261ek  arm-pnx4008       mips-decstation      powerpc-mpc8313_rdb
      arm-at91sam9263ek  arm-pxa255-idp    mips-e55             powerpc-mpc832x_mds
      arm-at91sam9rlek   arm-realview      mips-emma2rh         powerpc-mpc832x_rdb
      arm-ateb9200       arm-realview-smp  mips-excite          powerpc-mpc834x_itx
      arm-badge4         arm-rpc           mips-fulong          powerpc-mpc834x_itxgp
      arm-carmeva        arm-s3c2410       mips-ip22            powerpc-mpc834x_mds
      arm-cerfcube       arm-shannon       mips-ip27            powerpc-mpc836x_mds
      arm-clps7500       arm-shark         mips-ip32            powerpc-mpc8540_ads
      arm-collie         arm-simpad        mips-jazz            powerpc-mpc8544_ds
      arm-corgi          arm-spitz         mips-jmr3927         powerpc-mpc8560_ads
      arm-csb337         arm-trizeps4      mips-malta           powerpc-mpc8568mds
      arm-csb637         arm-versatile     mips-mipssim         powerpc-mpc85xx_cds
      arm-ebsa110        i386              mips-mpc30x          powerpc-mpc8641_hpcn
      arm-edb7211        i386-allnoconfig  mips-msp71xx         powerpc-mpc866_ads
      arm-em_x270        i386-defconfig    mips-ocelot          powerpc-mpc885_ads
      arm-ep93xx         i386-up           mips-pb1100          powerpc-pasemi
      arm-footbridge     ia64              mips-pb1500          powerpc-pmac32
      arm-fortunet       ia64-allnoconfig  mips-pb1550          powerpc-ppc64
      arm-h3600          ia64-bigsur       mips-pnx8550-jbs     powerpc-prpmc2800
      arm-h7201          ia64-defconfig    mips-pnx8550-stb810  powerpc-ps3
      arm-h7202          ia64-gensparse    mips-qemu            powerpc-pseries
      arm-hackkit        ia64-sim          mips-rbhma4200       powerpc-up
      arm-integrator     ia64-sn2          mips-rbhma4500       s390
      arm-iop13xx        ia64-tiger        mips-rm200           s390-allnoconfig
      arm-iop32x         ia64-up           mips-sb1250-swarm    s390-defconfig
      arm-iop33x         ia64-zx1          mips-sead            s390-up
      arm-ixp2000        m68k              mips-tb0219          sparc
      arm-ixp23xx        m68k-amiga        mips-tb0226          sparc-allnoconfig
      arm-ixp4xx         m68k-apollo       mips-tb0287          sparc-defconfig
      arm-jornada720     m68k-atari        mips-workpad         sparc-up
      arm-kafa           m68k-bvme6000     mips-wrppmc          sparc64
      arm-kb9202         m68k-hp300        mips-yosemite        sparc64-allnoconfig
      arm-ks8695         m68k-mac          parisc               sparc64-defconfig
      arm-lart           m68k-mvme147      parisc-allnoconfig   sparc64-up
      arm-lpd270         m68k-mvme16x      parisc-defconfig     um-x86_64
      arm-lpd7a400       m68k-q40          parisc-up            x86_64
      arm-lpd7a404       m68k-sun3         powerpc              x86_64-allnoconfig
      arm-lubbock        m68k-sun3x        powerpc-cell         x86_64-defconfig
      arm-lusl7200       mips              powerpc-celleb       x86_64-up
      arm-mainstone      mips-atlas        powerpc-chrp32
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4e950f6f
  5. 25 7月, 2007 1 次提交
    • J
      uml: more __init annotations · 97a1fcbb
      Jeff Dike 提交于
      2.6.23-rc1 turned up another batch of references from non-__init code to
      __init code.  In most cases, these were missing __init annotations.  In one
      case (os_drop_memory), the annotation was present but wrong.
      
      init_maps is __init, but for some reason was being very careful about the
      mechanism by which it allocated memory, checking whether it was OK to use
      kmalloc (at this point in the boot, it definitely isn't) and using either
      alloc_bootmem_low_pages or kmalloc/vmalloc.  So, the kmalloc/vmalloc code is
      removed.
      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>
      97a1fcbb
  6. 20 7月, 2007 1 次提交
    • N
      mm: fault feedback #2 · 83c54070
      Nick Piggin 提交于
      This patch completes Linus's wish that the fault return codes be made into
      bit flags, which I agree makes everything nicer.  This requires requires
      all handle_mm_fault callers to be modified (possibly the modifications
      should go further and do things like fault accounting in handle_mm_fault --
      however that would be for another patch).
      
      [akpm@linux-foundation.org: fix alpha build]
      [akpm@linux-foundation.org: fix s390 build]
      [akpm@linux-foundation.org: fix sparc build]
      [akpm@linux-foundation.org: fix sparc64 build]
      [akpm@linux-foundation.org: fix ia64 build]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Still apparently needs some ARM and PPC loving - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83c54070
  7. 18 7月, 2007 2 次提交
  8. 17 7月, 2007 1 次提交
    • J
      uml: Eliminate kernel allocator wrappers · e4c4bf99
      Jeff Dike 提交于
      UML had two wrapper procedures for kmalloc, um_kmalloc and um_kmalloc_atomic
      because the flag constants weren't available in userspace code.
      kern_constants.h had made kernel constants available for a long time, so there
      is no need for these wrappers any more.  Rather, userspace code calls kmalloc
      directly with the userspace versions of the gfp flags.
      
      kmalloc isn't a real procedure, so I had to essentially copy the inline
      wrapper around __kmalloc.
      
      vmalloc also had its own wrapper for no good reason.  This is now gone.
      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>
      e4c4bf99
  9. 09 6月, 2007 1 次提交
  10. 19 5月, 2007 2 次提交
  11. 11 5月, 2007 2 次提交
    • 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
    • J
      uml: tidy IRQ code · 2ea5bc5e
      Jeff Dike 提交于
      Some tidying of the irq code before introducing irq stacks.  Mostly
      style fixes, but the timer handler calls the timer code directly
      rather than going through the generic sig_handler_common_skas.
      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>
      2ea5bc5e