1. 10 Jul, 2009 1 commit
  2. 20 Sep, 2008 1 commit
    • Paul Mundt's avatar
      sh: Support kernel stacks smaller than a page. · c15c5f8c
      Paul Mundt authored
      This follows the powerpc commit f6a61680
      '[POWERPC] Fix kernel stack allocation alignment'.
      SH has traditionally forced the thread order to be relative to the page
      size, so there were never any situations where the same bug was
      triggered by slub. Regardless, the usage of > 8kB stacks for the larger
      page sizes is overkill, so we switch to using slab allocations there,
      as per the powerpc change.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  3. 01 Aug, 2008 3 commits
  4. 28 Jul, 2008 2 commits
  5. 25 Jul, 2008 1 commit
  6. 28 Jan, 2008 3 commits
  7. 31 Jul, 2007 1 commit
  8. 05 Mar, 2007 1 commit
  9. 13 Feb, 2007 1 commit
  10. 13 Dec, 2006 1 commit
    • Rafael J. Wysocki's avatar
      [PATCH] PM: Fix SMP races in the freezer · 8a102eed
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  11. 06 Dec, 2006 1 commit
    • Paul Mundt's avatar
      sh: Fixup various PAGE_SIZE == 4096 assumptions. · 510c72ad
      Paul Mundt authored
      There were a number of places that made evil PAGE_SIZE == 4k
      assumptions that ended up breaking when trying to play with
      8k and 64k page sizes, this fixes those up.
      The most significant change is the way we load THREAD_SIZE,
      previously this was done via:
      	mov	#(THREAD_SIZE >> 8), reg
      	shll8	reg
      to avoid a memory access and allow the immediate load. With
      a 64k PAGE_SIZE, we're out of range for the immediate load
      size without resorting to special instructions available in
      later ISAs (movi20s and so on). The "workaround" for this is
      to bump up the shift to 10 and insert a shll2, which gives a
      bit more flexibility while still being much cheaper than a
      memory access.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  12. 27 Sep, 2006 5 commits
  13. 26 Mar, 2006 1 commit
  14. 12 Jan, 2006 1 commit
  15. 23 Jun, 2005 1 commit
    • Jesper Juhl's avatar
      [PATCH] streamline preempt_count type across archs · dcd497f9
      Jesper Juhl authored
      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
      Signed-off-by: default avatarJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  16. 28 May, 2005 1 commit
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!