1. 20 6月, 2006 2 次提交
    • A
      [PATCH] fix deadlocks in AUDIT_LIST/AUDIT_LIST_RULES · 9044e6bc
      Al Viro 提交于
      We should not send a pile of replies while holding audit_netlink_mutex
      since we hold the same mutex when we receive commands.  As the result,
      we can get blocked while sending and sit there holding the mutex while
      auditctl is unable to send the next command and get around to receiving
      what we'd sent.
      
      Solution: create skb and put them into a queue instead of sending;
      once we are done, send what we've got on the list.  The former can
      be done synchronously while we are handling AUDIT_LIST or AUDIT_LIST_RULES;
      we are holding audit_netlink_mutex at that point.  The latter is done
      asynchronously and without messing with audit_netlink_mutex.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9044e6bc
    • A
      [PATCH] inotify (1/5): split kernel API from userspace support · 2d9048e2
      Amy Griffis 提交于
      The following series of patches introduces a kernel API for inotify,
      making it possible for kernel modules to benefit from inotify's
      mechanism for watching inodes.  With these patches, inotify will
      maintain for each caller a list of watches (via an embedded struct
      inotify_watch), where each inotify_watch is associated with a
      corresponding struct inode.  The caller registers an event handler and
      specifies for which filesystem events their event handler should be
      called per inotify_watch.
      Signed-off-by: NAmy Griffis <amy.griffis@hp.com>
      Acked-by: NRobert Love <rml@novell.com>
      Acked-by: NJohn McCutchan <john@johnmccutchan.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2d9048e2
  2. 18 6月, 2006 3 次提交
    • O
      [PATCH] arm_timer: remove a racy and obsolete PF_EXITING check · f53ae1dc
      Oleg Nesterov 提交于
      arm_timer() checks PF_EXITING to prevent BUG_ON(->exit_state)
      in run_posix_cpu_timers().
      
      However, for some reason it does so only for CPUCLOCK_PERTHREAD
      case (which is imho wrong).
      
      Also, this check is not reliable, PF_EXITING could be set on
      another cpu without any locks/barriers just after the check,
      so it can't prevent from attaching the timer to the exiting
      task.
      
      The previous patch makes this check unneeded.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f53ae1dc
    • O
      [PATCH] run_posix_cpu_timers: remove a bogus BUG_ON() · 30f1e3dd
      Oleg Nesterov 提交于
      do_exit() clears ->it_##clock##_expires, but nothing prevents
      another cpu to attach the timer to exiting process after that.
      arm_timer() tries to protect against this race, but the check
      is racy.
      
      After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and
      before do_exit() calls 'schedule() local timer interrupt can find
      tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu
      does sys_wait4) interrupted task has ->signal == NULL.
      
      At this moment exiting task has no pending cpu timers, they were
      cleanuped in __exit_signal()->posix_cpu_timers_exit{,_group}(),
      so we can just return from irq.
      
      John Stultz recently confirmed this bug, see
      
      	http://marc.theaimsgroup.com/?l=linux-kernel&m=115015841413687Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30f1e3dd
    • O
      [PATCH] check_process_timers: fix possible lockup · 8f17fc20
      Oleg Nesterov 提交于
      If the local timer interrupt happens just after do_exit() sets PF_EXITING
      (and before it clears ->it_xxx_expires) run_posix_cpu_timers() will call
      check_process_timers() with tasklist_lock + ->siglock held and
      
      	check_process_timers:
      
      		t = tsk;
      		do {
      			....
      
      			do {
      				t = next_thread(t);
      			} while (unlikely(t->flags & PF_EXITING));
      		} while (t != tsk);
      
      the outer loop will never stop.
      
      Actually, the window is bigger.  Another process can attach the timer
      after ->it_xxx_expires was cleared (see the next commit) and the 'if
      (PF_EXITING)' check in arm_timer() is racy (see the one after that).
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8f17fc20
  3. 01 6月, 2006 1 次提交
  4. 22 5月, 2006 4 次提交
    • L
      Revert "[PATCH] sched: fix interactive task starvation" · f1adad78
      Linus Torvalds 提交于
      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: NCon Kolivas <kernel@kolivas.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f1adad78
    • Z
      [PATCH] Fix a NO_IDLE_HZ timer bug · 0662b713
      Zachary Amsden 提交于
      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: NZachary Amsden <zach@vmware.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0662b713
    • P
      [PATCH] cpuset: might_sleep_if check in cpuset_zones_allowed · 92d1dbd2
      Paul Jackson 提交于
      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: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      92d1dbd2
    • P
      [PATCH] cpuset: update cpuset_zones_allowed comment · 36be57ff
      Paul Jackson 提交于
      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: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      36be57ff
  5. 16 5月, 2006 2 次提交
  6. 12 5月, 2006 1 次提交
    • L
      ptrace_attach: fix possible deadlock schenario with irqs · f358166a
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@osdl.org>
      f358166a
  7. 08 5月, 2006 1 次提交
    • L
      Fix ptrace_attach()/ptrace_traceme()/de_thread() race · f5b40e36
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@osdl.org>
      f5b40e36
  8. 01 5月, 2006 12 次提交
  9. 28 4月, 2006 2 次提交
  10. 26 4月, 2006 2 次提交
  11. 20 4月, 2006 5 次提交
  12. 15 4月, 2006 2 次提交
  13. 14 4月, 2006 1 次提交
  14. 11 4月, 2006 2 次提交