1. 29 3月, 2011 2 次提交
    • A
      FRV: Do some cleanups · 5ca7202b
      Amerigo Wang 提交于
      1. frv doesn't support SMP, remove the useless SMP bits.
      
      2. frv has its own alloc_task_struct, so define __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
         (I am not sure if frv should use generic alloc_task_struct().)
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5ca7202b
    • D
      FRV: Missing node arg in alloc_thread_info_node() macro · 5ef9bdde
      David Howells 提交于
      There are two alloc_thread_info_node() macros defined (one for debugging and
      one for normal).  The commit that changed them most recently:
      
      	commit b6a84016
      	Author: Eric Dumazet <eric.dumazet@gmail.com>
      	Date:   Tue Mar 22 16:30:42 2011 -0700
      	Subject: mm: NUMA aware alloc_thread_info_node()
      
      didn't add the node argument into the macro argument list for the normal macro.
      This results in the following error:
      
      kernel/fork.c:267:39: error: macro "alloc_thread_info_node" passed 2 arguments, but takes just 1
      kernel/fork.c: In function 'dup_task_struct':
      kernel/fork.c:267: error: 'alloc_thread_info_node' undeclared (first use in this function)
      kernel/fork.c:267: error: (Each undeclared identifier is reported only once
      kernel/fork.c:267: error: for each function it appears in.)
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5ef9bdde
  2. 23 3月, 2011 1 次提交
  3. 14 5月, 2010 1 次提交
  4. 11 7月, 2009 1 次提交
  5. 12 6月, 2009 1 次提交
  6. 10 4月, 2009 2 次提交
  7. 26 7月, 2008 1 次提交
  8. 17 10月, 2007 1 次提交
  9. 01 8月, 2007 1 次提交
  10. 14 12月, 2006 1 次提交
    • R
      [PATCH] PM: Fix SMP races in the freezer · 8a102eed
      Rafael J. Wysocki 提交于
      Currently, to tell a task that it should go to the refrigerator, we set the
      PF_FREEZE flag for it and send a fake signal to it.  Unfortunately there
      are two SMP-related problems with this approach.  First, a task running on
      another CPU may be updating its flags while the freezer attempts to set
      PF_FREEZE for it and this may leave the task's flags in an inconsistent
      state.  Second, there is a potential race between freeze_process() and
      refrigerator() in which freeze_process() running on one CPU is reading a
      task's PF_FREEZE flag while refrigerator() running on another CPU has just
      set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it.  If
      the refrigerator wins the race, freeze_process() will state that PF_FREEZE
      hasn't been set for the task and will set it unnecessarily, so the task
      will go to the refrigerator once again after it's been thawed.
      
      To solve first of these problems we need to stop using PF_FREEZE to tell
      tasks that they should go to the refrigerator.  Instead, we can introduce a
      special TIF_*** flag and use it for this purpose, since it is allowed to
      change the other tasks' TIF_*** flags and there are special calls for it.
      
      To avoid the freeze_process()-refrigerator() race we can make
      freeze_process() to always check the task's PF_FROZEN flag after it's read
      its "freeze" flag.  We should also make sure that refrigerator() will
      always reset the task's "freeze" flag after it's set PF_FROZEN for it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8a102eed
  11. 11 7月, 2006 1 次提交
  12. 19 1月, 2006 1 次提交
    • D
      [PATCH] Handle TIF_RESTORE_SIGMASK for FRV · a411aee9
      David Howells 提交于
      Handle TIF_RESTORE_SIGMASK as added by David Woodhouse's patch entitled:
      
              [PATCH] 2/3 Add TIF_RESTORE_SIGMASK support for arch/powerpc
              [PATCH] 3/3 Generic sys_rt_sigsuspend
      
      It does the following:
      
       (1) Declares TIF_RESTORE_SIGMASK for FRV.
      
       (2) Invokes it over to do_signal() when TIF_RESTORE_SIGMASK is set.
      
       (3) Makes do_signal() support TIF_RESTORE_SIGMASK, using the signal mask saved
           in current->saved_sigmask.
      
       (4) Discards sys_rt_sigsuspend() from the arch, using the generic one instead.
      
       (5) Makes sys_sigsuspend() save the signal mask and set TIF_RESTORE_SIGMASK
           rather than attempting to fudge the return registers.
      
       (6) Makes sys_sigsuspend() return -ERESTARTNOHAND rather than looping
           intrinsically.
      
       (7) Makes setup_frame(), setup_rt_frame() and handle_signal() return 0 or
           -EFAULT rather than true/false to be consistent with the rest of the
            kernel.
      
      Due to the fact do_signal() is then only called from one place:
      
       (8) Make do_signal() no longer have a return value is it was just being
           ignored; force_sig() takes care of this.
      
       (9) Discards the old sigmask argument to do_signal() as it's no longer
           necessary.
      
      This patch depends on the FRV signalling patches as well as the
      sys_rt_sigsuspend patch.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a411aee9
  13. 13 1月, 2006 1 次提交
  14. 29 11月, 2005 1 次提交
    • D
      [PATCH] FRV: Make the FRV arch work again · 8080f231
      David Howells 提交于
      The attached patch implements a bunch of small changes to the FRV arch to
      make it work again.
      
      It deals with the following problems:
      
       (1) SEM_DEBUG should be SEMAPHORE_DEBUG.
      
       (2) The argument list to pcibios_penalize_isa_irq() has changed.
      
       (3) CONFIG_HIGHMEM can't be used directly in #if as it may not be defined.
      
       (4) page->private is no longer directly accessible.
      
       (5) linux/hardirq.h assumes asm/hardirq.h will include linux/irq.h
      
       (6) The IDE MMIO access functions are given pointers, not integers, and so
           get type casting errors.
      
       (7) __pa() is passed an explicit u64 type in drivers/char/mem.c, but that
           can't be cast directly to a pointer on a 32-bit platform.
      
       (8) SEMAPHORE_DEBUG should not be contingent on WAITQUEUE_DEBUG as that no
           longer exists.
      
       (9) PREEMPT_ACTIVE is too low a value.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8080f231
  15. 24 6月, 2005 1 次提交
    • J
      [PATCH] streamline preempt_count type across archs · dcd497f9
      Jesper Juhl 提交于
      The preempt_count member of struct thread_info is currently either defined
      as int, unsigned int or __s32 depending on arch.  This patch makes the type
      of preempt_count an int on all archs.
      
      Having preempt_count be an unsigned type prevents the catching of
      preempt_count < 0 bugs, and using int on some archs and __s32 on others is
      not exactely "neat" - much nicer when it's just int all over.
      
      A previous version of this patch was already ACK'ed by Robert Love, and the
      only change in this version of the patch compared to the one he ACK'ed is
      that this one also makes sure the preempt_count member is consistently
      commented.
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dcd497f9
  16. 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