Re: mutex_lock_slowpath warning using mxser tty driver (input/output error)

[Jiri Slaby <jirislaby@gmail.com>]

On 04/03/2009 02:33 AM, Johannes Weiner wrote:
> On Thu, Apr 02, 2009 at 11:55:08PM +0100, Alan Cox wrote:
>> On Thu, 02 Apr 2009 22:23:57 +0200
>> Jiri Slaby <jirislaby@gmail.com> wrote:
>>
>>> On 04/02/2009 08:44 PM, Alan Cox wrote:
>>>>> It appears to want to lock a mutex in interrupt context, something
>>>>> that's a definite no-no.
>>>>>
>>>>> CCed the folks who might know a thing or two about the driver.
>>>> Moxa is not a USB driver so the USB trace at the end makes no sense at
>>>> all.
>>> Yes, unreliable stack entries, but echo_set_canon_col is called from irq
>>> context and locks mutex.
>> Which means that either the driver is calling the ldisc receive handlers
>> from an IRQ directly (not allowed) or calling the tty_flip_buffer_push
>> paths and set tty->low_latency
>>
>> 2.6.29 is the first kernel that catches this bug with warnings.
> 
> It sets tty->low_latency = 1 on ->open(), unconditionally, and does
> tty_flip_buffer_push() from the interrupt handler.
> 
> Both things seem to have been there for a very long time (git-blame
> says longer than git).

I have no idea why it was added in fact and so whether it is sufficient
and correct just to remove the tty->low_latency setting hence I can't
fix it on my own.

It was added when Alan merged moxa's updated driver in (from
full-linux-history git):

commit c8caa4c1a9cda2fa01fa89c29020e31f5a923e0b
Author: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date:   Wed Dec 22 01:14:43 2004 -0800

[PATCH] Bring Moxa serial back into being

Moxa have released several driver updates now including support up to
2.6.8 but don't themselves feel its worth the effort of doing a cleaned
up merge for the base kernel.  So I pulled their latest driver release
(1.8) and removed all the macro gunge that makes it build on
2.2.0->2.6.8.  I then fixed it to run on 2.6.9/10 and fixed a bug in the
break handling.

It still doesn't do PCI hotplug but I don't have any PCI moxa cards to
really tackle that particular case.

I've also merged Adriank Bunk's two 'could be static' changes into this
diff set.