Re: tty's use of file_list_lock and file_move

["Jon Smirl" <jonsmirl@gmail.com>]

On 7/11/06, Paul Fulghum <paulkf@microgate.com> wrote:
> Alan Cox wrote:
> > Ar Maw, 2006-07-11 am 18:08 -0400, ysgrifennodd Jon Smirl:
> >
> >>What about adjusting things so the BKL isn't required? I tried
> >>completely removing it and died in release_dev. tty_mutex is already
> >>locks a lot of stuff, maybe it can be adjusted to allow removal of the
> >>BKL.
> >
> >
> > Thats what is happening currently. However it is being done piece by
> > piece, slowly and carefully.
>
> I hate to chime in since I don't have time in the near term
> to contribute to the subject, but I do like the idea of removing
> the BKL dependence as a first step. I find its semantics akward to keep
> track of, and error prone. More explicit locking, even global, would clear things
> up for a later push to finer grained (per tty?) locking (where appropriate).
>
> Making the necessary changes to all the individual drivers,
> as Russel's comment about explicitly dropping the new lock when
> sleeping pointed out, would be a time consuming (and probably
> tedious) task.

I'm still looking at doing work in the tty layer but it is turning out
to be more complex that I initially thought. I may give removing the
BLK another attempt when I understand things better.

I have all of the lock debugging turned on in my kernel. I did get
nice messages when I did dumb things like sleeping with locks held or
deadlocking that led to quickly fixing the code. Much better than the
old system of freezing the box up.

--
Jon Smirl
jonsmirl@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/