1. 18 6月, 2006 5 次提交
    • 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
    • S
      [PATCH] sky2: netconsole suspend/resume interaction · 88d11360
      Stephen Hemminger 提交于
      A couple of fixes that should prevent crashes when using netconsole and
      suspend/resume. First, netconsole poll routine shouldn't run unless the
      device is up; second, the NAPI poll should be disabled during suspend.
      
      This is only an issue on sky2, because it has to have one NAPI poll
      routine for both ports on dual port boards. Normal drivers use
      netif_rx_schedule_prep and that checks for netif_running.
      Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      88d11360
    • J
      [PATCH] Fix missing ret assignment in __bio_map_user() error path · 99172157
      Jens Axboe 提交于
      If get_user_pages() returns less pages than what we asked for, we jump
      to out_unmap which will return ERR_PTR(ret).  But ret can contain a
      positive number just smaller than local_nr_pages, so be sure to set it
      to -EFAULT always.
      
      Problem found and diagnosed by Damien Le Moal <damien@sdl.hitachi.co.jp>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      99172157
    • J
      [PATCH] fix cdrom open · 16070428
      Jens Axboe 提交于
      Some time ago the cdrom open routine was changed so that we call the
      driver's open routine before checking to see if it is read only.  However,
      if we discovered that a read write open was not possible and the open
      flags required a writable open, we just returned -EROFS without calling
      the driver's release routine.   This seems to work for most cdrom drivers,
      but breaks the Powerpc iSeries virtual cdrom rather badly.
      
      This just inserts the release call in the error path to balance the call
      to "->open()" done by "open_for_data()".
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      16070428
  2. 15 6月, 2006 1 次提交
  3. 14 6月, 2006 6 次提交
  4. 13 6月, 2006 8 次提交
  5. 12 6月, 2006 12 次提交
  6. 11 6月, 2006 8 次提交