[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1362355465.3221.82.camel@thor.lan>
Date: Sun, 03 Mar 2013 19:04:25 -0500
From: Peter Hurley <peter@...leysoftware.com>
To: David Miller <davem@...emloft.net>
Cc: sasha.levin@...cle.com, samuel@...tiz.org,
gregkh@...uxfoundation.org, jslaby@...e.cz, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ircomm: release tty before sleeping potentially
indefintely
On Sun, 2013-03-03 at 17:47 -0500, David Miller wrote:
> From: Sasha Levin <sasha.levin@...cle.com>
> Date: Sun, 3 Mar 2013 17:35:53 -0500
>
> > ircomm_tty_block_til_ready would hold tty lock while blocking. Since the sleep
> > might take a long time we can prevent other processes from accessing the tty,
> > causing hung tasks and a dead tty.
> >
> > Diagnosed-by: Peter Hurley <peter@...leysoftware.com>
> > Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
>
> But then you invalidate all of the tty state tests made under
> the lock at the beginning of this function, before enterring
> the loop. If you drop the lock, those pieces of state could
> change.
Yes, the state could change. For example, the tty could be hung up while
ircomm_tty_block_til_ready() is sleeping. Or the session leader could be
exiting and SIGHUPed this task. Or the port could have been shutdown.
All these are re-tested in the loop. What state test isn't repeated?
> I'm not applying this.
That's certainly your perogative.
But you should know this bug hangs the entire tty subsystem.
This is the correct fix and exactly how this is done by the tty port.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists