Re: Fixing the tty layer was Re: any chance of 2.6.0-test*?

[Dipankar Sarma]

On Mon, Jan 13, 2003 at 09:15:26AM +0000, Russell King wrote:
> > In that case would it not be better to replace all BKLs by a single tty
> > lock ?
> 
> No.  The tty layer relies on being able to safely reschedule with the
> BKL held.  If you replace it with a "tty lock" you need to find all
> those schedule() points throughout _every_ tty line discipline and
> tty driver and release that lock.

Yes, I get it now from this and Andi's mail. I hadn't thought about
that "special feature" of BKL :)

> 
> Basically, the tty later was written upon the assumption that there
> would be only _one_ thread of execution running tty code at any one
> time, and we only reschedule when we explicitly want to (which was
> the general kernel coding rule before we got spinlocks etc.)  Every
> point where a reschedule is possible, state checks are (should be)
> made to prevent races.

Hmm.. This understanding would make it easier for me to go take another look
at the tty layer.

> 
> When analysing the tty layer, you have to think not "what data does
> this protect" but "what code are we protecting".  Note that you must
> apply the same approach towards what were the global-cli points.
> 
> I don't think its the BKL points you have to worry about; they've
> stayed the same over many kernel versions.  The places that need
> deeper consideration are where the global-cli was replaced with the
> local-cli.  Obviously the latter is not a direct subsitute for the
> former.

BKL confused me here because I wasn't sure whether BKL was implicitly
protecting the tty driver code against anything else apart from itself.

Thanks
Dipankar