[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D87173D.50906@suse.cz>
Date: Mon, 21 Mar 2011 10:15:41 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Jack Stone <jwjstone@...tmail.fm>, Mac <kmac@...zta.fm>,
linux-kernel@...r.kernel.org, linux-ppp@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...e.de>,
Jiri Slaby <jirislaby@...il.com>
Subject: Re: 'scheduling while atomic' during ppp connection on 2.6.37.1 and
2.6.38
On 03/20/2011 10:58 PM, Alan Cox wrote:
>> + spin_lock_irqsave(&dc->spin_mutex, flags);
>> if (port->port.count)
>> room = kfifo_avail(&port->fifo_ul);
>> - mutex_unlock(&port->tty_sem);
>> + spin_unlock_irqrestore(&dc->spin_mutex, flags);
>
> dc->spin_mutex does not protect port->port.count.
Neither port->tty_sem did.
Anyway is the test needed at all? I.e. could
tty->ops->write/chars_in_buffer/ntty_write_room be called with
port->port.count == 0 at all?
And the lock should not as well be needed. Kfifo assures atomicity where
there is only one reader and one writer which should be the case here.
Unless tty->ops->write can be called in parallel. And it should not,
that's what's tty->atomic_write_lock for.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists