Prev: [PATCH] Staging: Add new driver ipheth
Next: tty: implement BTM as mutex instead of BKL
From: Alan Cox on 30 Mar 2010 18:40
> This means we are still safe, because there is no code
> left that the new BTM fails to serialize with.

We hope. I'm currently poking at sorting out the locking properly and
quite frankly the locking rules for the current tty reference have me
baffled. It clearly works as we've not got a pile of dumps in the
bugzilla tree but its also quite a mystery *how*.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 31 Mar 2010 04:00
On Wednesday 31 March 2010 00:37:59 Alan Cox wrote:
>
> > This means we are still safe, because there is no code
> > left that the new BTM fails to serialize with.
>
> We hope. I'm currently poking at sorting out the locking properly and
> quite frankly the locking rules for the current tty reference have me
> baffled. It clearly works as we've not got a pile of dumps in the
> bugzilla tree but its also quite a mystery *how*.

Yes, that's why I didn't even attempt to find out why the BKL is
in some places or what it protects, but only changed the way it gets
taken and released.

We also have empirical evidence that turning the BKL into a semaphore
doesn't make the code fall apart, so I'm assuming that the mutex based
implementation with the explicit release-when-blocking instead of
implicit release-when-sleeping is still equivalent.

Are you more worried that the interface conversion (patches 1-8)
can introduce bugs and make your life harder, or that the mutex
based implementation from patch 9 causes problems that were previously
hidden by other bugs?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 31 Mar 2010 06:00
> Are you more worried that the interface conversion (patches 1-8)
> can introduce bugs and make your life harder, or that the mutex
> based implementation from patch 9 causes problems that were previously
> hidden by other bugs?

It doesn't really make any difference to me - I'm either removing the BKL
or the BKM.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 1 Apr 2010 09:00
On Wednesday 31 March 2010, Alan Cox wrote:
> > Are you more worried that the interface conversion (patches 1-8)
> > can introduce bugs and make your life harder, or that the mutex
> > based implementation from patch 9 causes problems that were previously
> > hidden by other bugs?
>
> It doesn't really make any difference to me - I'm either removing the BKL
> or the BKM.

Ok, great!

Greg, are you ok with merging these TTY patches in your tree for 2.6.35
then? There will be at least one more respin of it for minor changes
and anything that comes up during testing, but it's essentially what I
posted here.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 1 Apr 2010 10:20
> Greg, are you ok with merging these TTY patches in your tree for 2.6.35
> then? There will be at least one more respin of it for minor changes
> and anything that comes up during testing, but it's essentially what I
> posted here.

Can we please wait a bit with the tty bits. I'm slowing picking through
the job properly and there are a lot of low hanging fruit to clean up at
the driver end of things that is best done before we complicate the core
stuff.

I'll try and get some patches posted ASAP for those but for example most
of the BKL use in the drivers/char tty drivers is now done, and those
remaining are almost all in code that we should simply drop as its been
marked broken/obsolete anyway.

Arnd there is another problem I noticed in your changes - the ppp stuff
is not tty locking, its some kind of driver/network locking and I don't
claim to understand what is going on.

Another one that wants attention from someone brave is selection.c - that
isn't tty locking dependant either but relies on the callers happening
(mostly but not always!) to call it with the BKL held.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: [PATCH] Staging: Add new driver ipheth
Next: tty: implement BTM as mutex instead of BKL