Re: tty's use of file_list_lock and file_move

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

On 7/10/06, Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Jul 10, 2006 at 07:49:31PM -0400, Jon Smirl wrote:
> > How about the use of lock/unlock_kernel(). Is there some hidden global
> > synchronization going on? Every time lock/unlock_kernel() is used
> > there is a tty_struct available. My first thought would be to turn
> > this into a per tty spinlock. Looking at where it is used it looks
> > like it was added to protect all of the VFS calls. I see no obvious
> > coordination with other ttys that isn't handled by other locks.
>
> No, it was just a case of not being worth it to get rid of the BKL for
> the tty subsystem, since opening and closing tty's isn't exactly a
> common event.  Switching it to use a per-tty spinlock makes sense if
> we're going to rototill the code, but to be honest it's probably not
> going to make a noticeable difference on any benchmark and most
> workloads.

I tried changing it to a per tty spinlock. Now I know that the code
relies on the BKL being broken when a task sleeps. That's a part of
the BKL I don't like, unlocks are happening implicitly instead of
explicitly. I always wonder if the code should have reacquired the BKL
when it woke up. In this case the sleep happens inside the line
discipline read functions.

Now I'm wondering if read and write should have taken BKL to begin
with. Read sleeps in a loop so after the first pass it has lost the
BKL. Read and write also have the own locking code internally.

--
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/