1. 18 7月, 2009 4 次提交
  2. 17 7月, 2009 3 次提交
  3. 15 7月, 2009 2 次提交
  4. 13 7月, 2009 5 次提交
  5. 12 7月, 2009 1 次提交
  6. 11 7月, 2009 6 次提交
  7. 10 7月, 2009 2 次提交
    • T
      hrtimer: Fix migration expiry check · 6ff7041d
      Thomas Gleixner 提交于
      The timer migration expiry check should prevent the migration of a
      timer to another CPU when the timer expires before the next event is
      scheduled on the other CPU. Migrating the timer might delay it because
      we can not reprogram the clock event device on the other CPU. But the
      code implementing that check has two flaws:
      
      - for !HIGHRES the check compares the expiry value with the clock
        events device expiry value which is wrong for CLOCK_REALTIME based
        timers.
      
      - the check is racy. It holds the hrtimer base lock of the target CPU,
        but the clock event device expiry value can be modified
        nevertheless, e.g. by an timer interrupt firing.
      
      The !HIGHRES case is easy to fix as we can enqueue the timer on the
      cpu which was selected by the load balancer. It runs the idle
      balancing code once per jiffy anyway. So the maximum delay for the
      timer is the same as when we keep the tick on the current cpu going.
      
      In the HIGHRES case we can get the next expiry value from the hrtimer
      cpu_base of the target CPU and serialize the update with the cpu_base
      lock. This moves the lock section in hrtimer_interrupt() so we can set
      next_event to KTIME_MAX while we are handling the expired timers and
      set it to the next expiry value after we handled the timers under the
      base lock. While the expired timers are processed timer migration is
      blocked because the expiry time of the timer is always <= KTIME_MAX.
      
      Also remove the now useless clockevents_get_next_event() function.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6ff7041d
    • J
      memory barrier: adding smp_mb__after_lock · ad462769
      Jiri Olsa 提交于
      Adding smp_mb__after_lock define to be used as a smp_mb call after
      a lock.
      
      Making it nop for x86, since {read|write|spin}_lock() on x86 are
      full memory barriers.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad462769
  8. 09 7月, 2009 3 次提交
  9. 08 7月, 2009 2 次提交
  10. 07 7月, 2009 3 次提交
    • A
      signals: declare sys_rt_tgsigqueueinfo in syscalls.h · 7afdbf23
      Arnd Bergmann 提交于
      sys_rt_tgsigqueueinfo needs to be declared in linux/syscalls.h so that
      architectures defining the system call table in C can reference it.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      LKML-Reference: <200907071023.44008.arnd@arndb.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7afdbf23
    • T
      linux/sysrq.h needs linux/errno.h · 82e3310a
      Tobias Doerffel 提交于
      In include/linux/sysrq.h the constant EINVAL is being used but is undefined
      if include/linux/errno.h is not included before.
      
      Fix this by adding #include <linux/errno.h> at the beginning.
      Signed-off-by: NTobias Doerffel <tobias.doerffel@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      82e3310a
    • H
      elf: fix multithreaded program core dumping on arm · a65e7bfc
      Hui Zhu 提交于
      Fix the multithread program core thread message error.
      
      This issue affects arches with neither has CORE_DUMP_USE_REGSET nor
      ELF_CORE_COPY_TASK_REGS, ARM is one of them.
      
      The thread message of core file is generated in elf_dump_thread_status.
      The register values is set by elf_core_copy_task_regs in this function.
      
      If an arch doesn't define ELF_CORE_COPY_TASK_REGS,
      elf_core_copy_task_regs() will do nothing.  Then the core file will not
      have the register message of thread.
      
      So add elf_core_copy_regs to set regiser values if ELF_CORE_COPY_TASK_REGS
      doesn't define.
      
      The following is how to reproduce this issue:
      
      cat 1.c
      #include <stdio.h>
      #include <pthread.h>
      #include <assert.h>
      
      void td1(void * i)
      {
             while (1)
             {
                     printf ("1\n");
                     sleep (1);
             }
      
             return;
      }
      
      void td2(void * i)
      {
             while (1)
             {
                     printf ("2\n");
                     sleep (1);
             }
      
             return;
      }
      
      int
      main(int argc,char *argv[],char *envp[])
      {
             pthread_t       t1,t2;
      
             pthread_create(&t1, NULL, (void*)td1, NULL);
             pthread_create(&t2, NULL, (void*)td2, NULL);
      
             sleep (10);
      
             assert(0);
      
             return (0);
      }
      arm-xxx-gcc -g -lpthread 1.c -o 1
      copy 1.c and 1 to a arm board.
      Goto this board.
      ulimit -c 1800000
      ./1
      # ./1
      1
      2
      1
      ...
      ...
      1
      1: 1.c:37: main: Assertion `0' failed.
      Aborted (core dumped)
      Then you can get a core file.
      gdb 1 core.xxx
      Without the patch:
      (gdb) info threads
       3 process 909  0x00000000 in ?? ()
       2 process 908  0x00000000 in ?? ()
      * 1 process 907  0x4a6e2238 in raise () from /lib/libc.so.6
      You can found that the pc of 909 and 908 is 0x00000000.
      With the patch:
      (gdb) info threads
       3 process 885  0x4a749974 in nanosleep () from /lib/libc.so.6
       2 process 884  0x4a749974 in nanosleep () from /lib/libc.so.6
      * 1 process 883  0x4a6e2238 in raise () from /lib/libc.so.6
      The pc of 885 and 884 is right.
      Signed-off-by: NHui Zhu <teawater@gmail.com>
      Cc: Amerigo Wang <xiyou.wangcong@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a65e7bfc
  11. 06 7月, 2009 1 次提交
  12. 03 7月, 2009 1 次提交
  13. 01 7月, 2009 7 次提交
    • J
      block: get rid of queue-private command filter · 018e0446
      Jens Axboe 提交于
      The initial patches to support this through sysfs export were broken
      and have been if 0'ed out in any release. So lets just kill the code
      and reclaim some space in struct request_queue, if anyone would later
      like to fixup the sysfs bits, the git history can easily restore
      the removed bits.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      018e0446
    • M
      block: Create bip slabs with embedded integrity vectors · 7878cba9
      Martin K. Petersen 提交于
      This patch restores stacking ability to the block layer integrity
      infrastructure by creating a set of dedicated bip slabs.  Each bip slab
      has an embedded bio_vec array at the end.  This cuts down on memory
      allocations and also simplifies the code compared to the original bvec
      version.  Only the largest bip slab is backed by a mempool.  The pool is
      contained in the bio_set so stacking drivers can ensure forward
      progress.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJens Axboe <axboe@carl.(none)>
      7878cba9
    • H
      usbnet: Remove private stats structure · d9d62f3f
      Herbert Xu 提交于
      Now that nothing uses the private stats structure we can remove it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9d62f3f
    • K
      fbdev: add mutex for fb_mmap locking · 537a1bf0
      Krzysztof Helt 提交于
      Add a mutex to avoid a circular locking problem between the mm layer
      semaphore and fbdev ioctl mutex through the fb_mmap() call.
      
      Also, add mutex to all places where smem_start and smem_len fields change
      so the mutex inside the fb_mmap() is actually used.  Changing of these
      fields before calling the framebuffer_register() are not mutexed.
      
      This is 2.6.31 material.  It removes one lockdep (fb_mmap() and
      register_framebuffer()) but there is still another one (fb_release() and
      register_framebuffer()).  It also cleans up handling of the smem_start and
      smem_len fields used by mutexed section of the fb_mmap().
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      537a1bf0
    • D
      spi: add spi_master flag word · 70d6027f
      David Brownell 提交于
      Add a new spi_master.flags word listing constraints relevant to that
      controller.  Define the first constraint bit: a half duplex restriction.
      Include that constraint in the OMAP1 MicroWire controller driver.
      
      Have the mmc_spi host be the first customer of this flag.  Its coding
      relies heavily on full duplex transfers, so it must fail when the
      underlying controller driver won't perform them.
      
      (The spi_write_then_read routine could use it too: use the
      temporarily-withdrawn full-duplex speedup unless this flag is set, in
      which case the existing code applies.  Similarly, any spi_master
      implementing only SPI_3WIRE should set the flag.)
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70d6027f
    • D
      spi: new spi->mode bits · b55f627f
      David Brownell 提交于
      Add two new spi_device.mode bits to accomodate more protocol options, and
      pass them through to usermode drivers:
      
       * SPI_NO_CS ... a second 3-wire variant, where the chipselect
         line is removed instead of a data line; transfers are still
         full duplex.
      
         This obviously has STRONG protocol implications since the
         chipselect transitions can't be used to synchronize state
         transitions with the SPI master.
      
       * SPI_READY ... defines open drain signal that's pulled low
         to pause the clock.  This defines a 5-wire variant (normal
         4-wire SPI plus READY) and two 4-wire variants (READY plus
         each of the 3-wire flavors).
      
         Such hardware flow control can be a big win.  There are ADC
         converters and flash chips that expose READY signals, but not
         many host controllers support it today.
      
      The spi_bitbang code should be changed to use SPI_NO_CS instead of its
      current nonportable hack.  That's a mode most hardware can easily support
      (unlike SPI_READY).
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: "Paulraj, Sandeep" <s-paulraj@ti.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b55f627f
    • K
      elf: limit max map count to safe value · 341c87bf
      KAMEZAWA Hiroyuki 提交于
      With ELF, at generating coredump, some more headers other than used
      vmas are added.
      
      When max_map_count == 65536, a core generated by following kinds of
      code can be unreadable because the number of ELF's program header is
      written in 16bit in Ehdr (please see elf.h) and the number overflows.
      
      ==
      	... = mmap(); (munmap, mprotect, etc...)
      	if (failed)
      		abort();
      ==
      
      This can happen in mmap/munmap/mprotect/etc...which calls split_vma().
      
      I think 65536 is not safe as _default_ and reduce it to 65530 is good
      for avoiding unexpected corrupted core.
      
      Anyway, max_map_count can be enlarged by sysctl if a user is brave..
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Acked-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      341c87bf