1. 17 Mar, 2009 6 commits
    • Masami Hiramatsu's avatar
      module: fix refptr allocation and release order · 6e2b7574
      Masami Hiramatsu authored
      Impact: fix ref-after-free crash on failed module load
      
      Fix refptr bug: Change refptr allocation and release order not to access a module
      data structure pointed by 'mod' after freeing mod->module_core.
      This bug will cause kernel panic(e.g. failed to find undefined symbols).
      
      This bug was reported on systemtap bugzilla.
      http://sources.redhat.com/bugzilla/show_bug.cgi?id=9927Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Eric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      6e2b7574
    • Linus Torvalds's avatar
      Avoid 64-bit "switch()" statements on 32-bit architectures · ee568b25
      Linus Torvalds authored
      Commit ee6f779b ("filp->f_pos not
      correctly updated in proc_task_readdir") changed the proc code to use
      filp->f_pos directly, rather than through a temporary variable.  In the
      process, that caused the operations to be done on the full 64 bits, even
      though the offset is never that big.
      
      That's all fine and dandy per se, but for some unfathomable reason gcc
      generates absolutely horrid code when using 64-bit values in switch()
      statements.  To the point of actually calling out to gcc helper
      functions like __cmpdi2 rather than just doing the trivial comparisons
      directly the way gcc does for normal compares.  At which point we get
      link failures, because we really don't want to support that kind of
      crazy code.
      
      Fix this by just casting the f_pos value to "unsigned long", which
      is plenty big enough for /proc, and avoids the gcc code generation issue.
      Reported-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Zhang Le <r0bertz@gentoo.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ee568b25
    • Masami Hiramatsu's avatar
      prevent boosting kprobes on exception address · 30390880
      Masami Hiramatsu authored
      Don't boost at the addresses which are listed on exception tables,
      because major page fault will occur on those addresses.  In that case,
      kprobes can not ensure that when instruction buffer can be freed since
      some processes will sleep on the buffer.
      
      kprobes-ia64 already has same check.
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30390880
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm · 18439c39
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
        dm crypt: wait for endio to complete before destruction
        dm crypt: fix kcryptd_async_done parameter
        dm io: respect BIO_MAX_PAGES limit
        dm table: rework reference counting fix
        dm ioctl: validate name length when renaming
      18439c39
    • Linus Torvalds's avatar
      Fast TSC calibration: calculate proper frequency error bounds · 9e8912e0
      Linus Torvalds authored
      In order for ntpd to correctly synchronize the clocks, the frequency of
      the system clock must not be off by more than 500 ppm (or, put another
      way, 1:2000), or ntpd will end up giving up on trying to synchronize
      properly, and ends up reseting the clock in jumps instead.
      
      The fast TSC PIT calibration sometimes failed this test - it was
      assuming that the PIT reads always took about one microsecond each (2us
      for the two reads to get a 16-bit timer), and that calibrating TSC to
      the PIT over 15ms should thus be sufficient to get much closer than
      500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
      error value).
      
      However, that assumption does not always hold: apparently some hardware
      is either very much slower at reading the PIT registers, or there was
      other noise causing at least one machine to get 700+ ppm errors.
      
      So instead of using a fixed 15ms timing loop, this changes the fast PIT
      calibration to read the TSC delta over the individual PIT timer reads,
      and use the result to calculate the error bars on the PIT read timing
      properly.  We then successfully calibrate the TSC only if the maximum
      error bars fall below 500ppm.
      
      In the process, we also relax the timing to allow up to 25ms for the
      calibration, although it can happen much faster depending on hardware.
      Reported-and-tested-by: default avatarJesper Krogh <jesper@krogh.cc>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9e8912e0
    • Linus Torvalds's avatar
      Fix potential fast PIT TSC calibration startup glitch · a6a80e1d
      Linus Torvalds authored
      During bootup, when we reprogram the PIT (programmable interval timer)
      to start counting down from 0xffff in order to use it for the fast TSC
      calibration, we should also make sure to delay a bit afterwards to allow
      the PIT hardware to actually start counting with the new value.
      
      That will happens at the next CLK pulse (1.193182 MHz), so the easiest
      way to do that is to just wait at least one microsecond after
      programming the new PIT counter value.  We do that by just reading the
      counter value back once - which will take about 2us on PC hardware.
      Reported-and-tested-by: default avatarjohn stultz <johnstul@us.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a6a80e1d
  2. 16 Mar, 2009 26 commits
  3. 15 Mar, 2009 3 commits
    • Kyle McMartin's avatar
      parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y · 5bee17f1
      Kyle McMartin authored
      CC      drivers/parisc/sba_iommu.o
      drivers/parisc/sba_iommu.c:1373: error: expected identifier or '('
      before '}' token
      make[2]: *** [drivers/parisc/sba_iommu.o] Error 1
      make[1]: *** [drivers/parisc] Error 2
      make: *** [drivers] Error 2
      
      Don't know how this has gone missed for so long... clearly I need
      to do builds on my C8000 more often.
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5bee17f1
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · fbd8104c
      Linus Torvalds authored
      * master.kernel.org:/home/rmk/linux-2.6-arm: (23 commits)
        [ARM] Fix virtual to physical translation macro corner cases
        [ARM] update mach-types
        [ARM] 5421/1: ftrace: fix crash due to tracing of __naked functions
        MX1 fix include
        [ARM] 5419/1: ep93xx: fix build warnings about struct i2c_board_info
        [ARM] 5418/1: restore lr before leaving mcount
        ARM: OMAP: board-omap3beagle: set i2c-3 to 100kHz
        ARM: OMAP: Allow I2C bus driver to be compiled as a module
        ARM: OMAP: sched_clock() corrected
        ARM: OMAP: Fix compile error if pm.h is included
        [ARM] orion5x: pass dram mbus data to xor driver
        [ARM] S3C64XX: Fix s3c64xx_setrate_clksrc
        [ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/irq.c
        [ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/s3c6400-clock.c
        [ARM] S3C64XX: Fix USB host clock mux list
        [ARM] S3C64XX: Fix name of USB host clock.
        [ARM] S3C64XX: Rename IRQ_UHOST to IRQ_USBH
        [ARM] S3C64XX: Do gpiolib configuration earlier
        [ARM] S3C64XX: Staticise s3c64xx_init_irq_eint()
        [ARM] SMDK6410: Declare iodesc table static
        ...
      fbd8104c
    • Alexander Duyck's avatar
      igb: remove ASPM L0s workaround · 682337fe
      Alexander Duyck authored
      The L0s workaround should be moved into a pci quirk and so it is not
      necessary in the driver.  This update removes the L0s workaround from the
      igb driver.
      
      This was the second half of the PCI quirk patch that Matthew Wilcox did
      not pick up when he picked up the quirk patch.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      682337fe
  4. 14 Mar, 2009 5 commits