[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101124164329.75368d71@lxorguk.ukuu.org.uk>
Date: Wed, 24 Nov 2010 16:43:29 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Alexander Gordeev <lasaine@....cs.msu.su>
Cc: linux-kernel@...r.kernel.org,
"Nikita V\. Youshchenko" <yoush@...msu.su>,
linuxpps@...enneenne.com, Rodolfo Giometti <giometti@...eenne.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Arnd Bergmann <arnd@...db.de>,
Al Viro <viro@...iv.linux.org.uk>,
Nick Piggin <npiggin@...nel.dk>,
"Alan \"I must be out of my tree\" Cox" <alan@...ux.intel.com>,
Jason Wessel <jason.wessel@...driver.com>,
Philippe Langlais <philippe.langlais@...ricsson.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCHv5 05/17] tty: don't allow ldisc dcd_change() after ldisc
halt
On Wed, 24 Nov 2010 19:15:43 +0300
Alexander Gordeev <lasaine@....cs.msu.su> wrote:
> There was a possibility that uart_handle_dcd_change() could obtain a
> reference to ldisc while running in parallel with tty_set_ldisc() on
> different CPU but call dcd_change() operation after tty_ldisc_close()
> which is incorrect.
How can this occur ?
> + spin_lock_irqsave(&tty->dcd_change_lock, flags);
> +
> + ld = tty_ldisc_ref(tty);
What is the expecting lock ordering rule here ?
I don't see why this patch is needed. You've got an ldisc ref from
tty_ldisc_ref, until you drop that ldisc ref you are fine. If for some
reason that is not the case then there is a bug in the ldisc code.
Alan
--
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