Skip to content
Snippets Groups Projects
  1. May 31, 2006
  2. May 21, 2006
    • Linus Torvalds's avatar
      Revert "[PATCH] sched: fix interactive task starvation" · f1adad78
      Linus Torvalds authored
      
      This reverts commit 5ce74abe (and its
      dependent commit 8a5bc075), because of
      audio underruns.
      
      Reported by Rene Herman <rene.herman@keyaccess.nl>, who also pinpointed
      the exact cause of the underruns:
      
        "Audio underruns galore, with only ogg123 and firefox (browsing the
         GIT tree online is also a nice trigger by the way).
      
         If I back it out, everything is fine for me again."
      
      Cc: Rene Herman <rene.herman@keyaccess.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Acked-by: default avatarCon Kolivas <kernel@kolivas.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f1adad78
    • Zachary Amsden's avatar
      [PATCH] Fix a NO_IDLE_HZ timer bug · 0662b713
      Zachary Amsden authored
      
      Under certain timing conditions, a race during boot occurs where timer
      ticks are being processed on remote CPUs.  The remote timer ticks can
      increment jiffies, and if this happens during a window when a timeout is
      very close to expiring but a local tick has not yet been delivered, you can
      end up with
      
      1) No softirq pending
      2) A local timer wheel which is not synced to jiffies
      3) No high resolution timer active
      4) A local timer which is supposed to fire before the current jiffies value.
      
      In this circumstance, the comparison in next_timer_interrupt overflows,
      because the base of the comparison for high resolution timers is jiffies,
      but for the softirq timer wheel, it is relative the the current base of the
      wheel (jiffies_base).
      
      Signed-off-by: default avatarZachary Amsden <zach@vmware.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0662b713
    • Paul Jackson's avatar
      [PATCH] cpuset: might_sleep_if check in cpuset_zones_allowed · 92d1dbd2
      Paul Jackson authored
      
      It's too easy to incorrectly call cpuset_zone_allowed() in an atomic
      context without __GFP_HARDWALL set, and when done, it is not noticed until
      a tight memory situation forces allocations to be tried outside the current
      cpuset.
      
      Add a 'might_sleep_if()' check, to catch this earlier on, instead of
      waiting for a similar check in the mutex_lock() code, which is only rarely
      invoked.
      
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      92d1dbd2
    • Paul Jackson's avatar
      [PATCH] cpuset: update cpuset_zones_allowed comment · 36be57ff
      Paul Jackson authored
      
      Update the kernel/cpuset.c:cpuset_zone_allowed() comment.
      
      The rule for when mm/page_alloc.c should call cpuset_zone_allowed()
      was intended to be:
      
        Don't call cpuset_zone_allowed() if you can't sleep, unless you
        pass in the __GFP_HARDWALL flag set in gfp_flag, which disables
        the code that might scan up ancestor cpusets and sleep.
      
      The explanation of this rule in the comment above cpuset_zone_allowed() was
      stale, as a result of a restructuring of some __alloc_pages() code in
      November 2005.
      
      Rewrite that comment ...
      
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      36be57ff
  3. May 15, 2006
  4. May 11, 2006
    • Linus Torvalds's avatar
      ptrace_attach: fix possible deadlock schenario with irqs · f358166a
      Linus Torvalds authored
      
      Eric Biederman points out that we can't take the task_lock while holding
      tasklist_lock for writing, because another CPU that holds the task lock
      might take an interrupt that then tries to take tasklist_lock for writing.
      
      Which would be a nasty deadlock, with one CPU spinning forever in an
      interrupt handler (although admittedly you need to really work at
      triggering it ;)
      
      Since the ptrace_attach() code is special and very unusual, just make it
      be extra careful, and use trylock+repeat to avoid the possible deadlock.
      
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f358166a
  5. May 07, 2006
    • Linus Torvalds's avatar
      Fix ptrace_attach()/ptrace_traceme()/de_thread() race · f5b40e36
      Linus Torvalds authored
      
      This holds the task lock (and, for ptrace_attach, the tasklist_lock)
      over the actual attach event, which closes a race between attacking to a
      thread that is either doing a PTRACE_TRACEME or getting de-threaded.
      
      Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
      for noticing a lost return value in my first version.
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f5b40e36
  6. May 01, 2006
  7. Apr 28, 2006
  8. Apr 26, 2006
  9. Apr 20, 2006
  10. Apr 19, 2006
    • OGAWA Hirofumi's avatar
      [PATCH] Add more prevent_tail_call() · 5a7b46b3
      OGAWA Hirofumi authored
      
      Those also break userland regs like following.
      
         00000000 <sys_chown16>:
            0:	0f b7 44 24 0c       	movzwl 0xc(%esp),%eax
            5:	83 ca ff             	or     $0xffffffff,%edx
            8:	0f b7 4c 24 08       	movzwl 0x8(%esp),%ecx
            d:	66 83 f8 ff          	cmp    $0xffffffff,%ax
           11:	0f 44 c2             	cmove  %edx,%eax
           14:	66 83 f9 ff          	cmp    $0xffffffff,%cx
           18:	0f 45 d1             	cmovne %ecx,%edx
           1b:	89 44 24 0c          	mov    %eax,0xc(%esp)
           1f:	89 54 24 08          	mov    %edx,0x8(%esp)
           23:	e9 fc ff ff ff       	jmp    24 <sys_chown16+0x24>
      
      where the tailcall at the end overwrites the incoming stack-frame.
      
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      [ I would _really_ like to have a way to tell gcc about calling
        conventions. The "prevent_tail_call()" macro is pretty ugly ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5a7b46b3
    • Rafael J. Wysocki's avatar
      [PATCH] swsusp: prevent possible image corruption on resume · 4a3b98a4
      Rafael J. Wysocki authored
      
      The function free_pagedir() used by swsusp for freeing its internal data
      structures clears the PG_nosave and PG_nosave_free flags for each page
      being freed.
      
      However, during resume PG_nosave_free set means that the page in
      question is "unsafe" (ie.  it will be overwritten in the process of
      restoring the saved system state from the image), so it should not be
      used for the image data.
      
      Therefore free_pagedir() should not clear PG_nosave_free if it's called
      during resume (otherwise "unsafe" pages freed by it may be used for
      storing the image data and the data may get corrupted later on).
      
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4a3b98a4
    • Eric W. Biederman's avatar
      [PATCH] task: Make task list manipulations RCU safe · 5e85d4ab
      Eric W. Biederman authored
      
      While we can currently walk through thread groups, process groups, and
      sessions with just the rcu_read_lock, this opens the door to walking the
      entire task list.
      
      We already have all of the other RCU guarantees so there is no cost in
      doing this, this should be enough so that proc can stop taking the
      tasklist lock during readdir.
      
      prev_task was killed because it has no users, and using it will miss new
      tasks when doing an rcu traversal.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5e85d4ab
  11. Apr 14, 2006
  12. Apr 11, 2006
Loading