[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324484554.10752.16.camel@twins>
Date: Wed, 21 Dec 2011 17:22:34 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ted Ts'o <tytso@....edu>, Greg KH <greg@...ah.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
akpm@...ux-foundation.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 7/7] serial, 8250: Mostly avoid wakeups from under
port->lock
On Wed, 2011-12-21 at 16:03 +0000, Alan Cox wrote:
> > + BUG_ON(!state);
> > + tty = state->port.tty;
> > + tty_kref_get(tty);
> > + spin_unlock_irqrestore(&up->port.lock, flags);
> > + tty_wakeup(tty);
> > + tty_kref_put(tty);
>
> driver innards shouldn't know this stuff and this makes it worse rather
> than cleaning it up
Fair enough, if I can push it into serial_core.c I can probably fix that
one weird case as well, I couldn't inside the 8250 driver because the
port lock was taken by the serial core code.
> The basic idea looks fine but I really don't want magic lock hackery in
> the 8250 driver. We need a way of generalising this so the code is
> cleaner and the locking internal knowledge stays out of the driver itself.
>
> Also I think it's probably buggy - sending the x_char is forward progress
> so probably needs to cause a wakeup.
Could you explain that more, its not actually connecting with any
neurons..
> So for the moment NAK, but worthy of figuring out how to do it right
OK, will try and see if I can poke at it a level upwards..
--
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