1. 16 2月, 2006 5 次提交
    • C
      [PATCH] neofb: avoid resetting display config on unblank (v2) · 9f672004
      Christian Trefzer 提交于
      There were two mistakes in the register-read-on-(un)blank approach.
      
      - First, without proper register (un)locking the value read back will always
        be zero, and this is what I missed entirely until just now.  Due to this,
        the logic could not be verified at all and I tried some bogus checks which
        are completely stupid.
      
      - Second, the LCD status bit will always be set to zero when the backlight
        has been turned off.  Reading the value back during unblank will disable the
        LCD unconditionally, regardless of the state it is supposed to be in, since
        we set it to zero beforehand.
      
      So this is what we do now:
      
      - create a new variable in struct neofb_par, and use that to determine
        whether to read back registers (initialized to true)
      
      - before actually blanking the screen, read back the register to sense any
        possible change made through Fn key combo
      
      - use proper neoUnlock() / neoLock() to actually read something
      
      - every call to neofb_blank() determines if we read back next time: blanking
        disables readback, unblanking (FB_BLANK_UNBLANK) enables it
      
      This should give us a nice and clean state machine.  Has been thoroughly
      tested on a Dell Latitude CPiA / NM220 Chip docked to a C/Dock2 with attached
      CRT in all possible combinations of LCD/CRT on/off.  I changed the config via
      Fn key, let the console blank, unblanked by keypress - works flawlessly.
      Signed-off-by: NChristian Trefzer <ctrefzer@gmx.de>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9f672004
    • O
      [PATCH] fix zap_thread's ptrace related problems · 5ecfbae0
      Oleg Nesterov 提交于
      1. The tracee can go from ptrace_stop() to do_signal_stop()
         after __ptrace_unlink(p).
      
      2. It is unsafe to __ptrace_unlink(p) while p->parent may wait
         for tasklist_lock in ptrace_detach().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5ecfbae0
    • O
      [PATCH] fix kill_proc_info() vs fork() theoretical race · dadac81b
      Oleg Nesterov 提交于
      copy_process:
      
      	attach_pid(p, PIDTYPE_PID, p->pid);
      	attach_pid(p, PIDTYPE_TGID, p->tgid);
      
      What if kill_proc_info(p->pid) happens in between?
      
      copy_process() holds current->sighand.siglock, so we are safe
      in CLONE_THREAD case, because current->sighand == p->sighand.
      
      Otherwise, p->sighand is unlocked, the new process is already
      visible to the find_task_by_pid(), but have a copy of parent's
      'struct pid' in ->pids[PIDTYPE_TGID].
      
      This means that __group_complete_signal() may hang while doing
      
      	do ... while (next_thread() != p)
      
      We can solve this problem if we reverse these 2 attach_pid()s:
      
      	attach_pid() does wmb()
      
      	group_send_sig_info() calls spin_lock(), which
      	provides a read barrier. // Yes ?
      
      I don't think we can hit this race in practice, but still.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dadac81b
    • O
      [PATCH] fix kill_proc_info() vs CLONE_THREAD race · 3f17da69
      Oleg Nesterov 提交于
      There is a window after copy_process() unlocks ->sighand.siglock
      and before it adds the new thread to the thread list.
      
      In that window __group_complete_signal(SIGKILL) will not see the
      new thread yet, so this thread will start running while the whole
      thread group was supposed to exit.
      
      I beleive we have another good reason to place attach_pid(PID/TGID)
      under ->sighand.siglock. We can do the same for
      
      	release_task()->__unhash_process()
      
      	de_thread()->switch_exec_pids()
      
      After that we don't need tasklist_lock to iterate over the thread
      list, and we can simplify things, see for example do_sigaction()
      or sys_times().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f17da69
    • L
      7775aa76
  2. 15 2月, 2006 35 次提交