Messages in this thread | | | Date | Sun, 7 Feb 1999 20:32:24 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: Linux-2.2.2-pre2.. |
| |
On Sun, 7 Feb 1999, Linus Torvalds wrote:
>No, do_tty_hangup() will never be called asynchronously: it will always be >called from a synchronous kernel context (either from within the scheduler >or from processes that do a run_task_queue() on their own). > >If the caller already held the kernel lock, lock_kernel() is indeed a >no-op, but that's how it's designed: it doesn't need to do anything at >that point.
From schedule():
... release_kernel_lock(prev, this_cpu); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/* Do "administrative" work here while we don't hold any locks */ if (bh_active & bh_mask) do_bottom_half(); run_task_queue(&tq_scheduler); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...
When do_tty_hangup() runs current->lock_depth can be easily >=0 and we have the real spinlock unlocked so lock_kernel() does nothing and do_tty_hangup() can race fine with the other CPU that is holding the lock now.
I hope I am not doing mistakes but so far I haven't seen anything in the code that invalidated my theory.
Supposing that I am right, I don't know if do_tty_hangup() is supposed to be run only from release_dev() and so I don't know if the real bug that is causing this race is that run_task_queue(&tq_scheduler) is not run before returning from release_dev(). But if do_tty_hangup() can't be run from the scheduler, why don't we use a new task queue (tq_tty_hangup) instead of tq_scheduler in first place?
Another little curiosity, why tty_hangup() exists and we don't use tty_vhangup() for everything?
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |