linux-kernel - Re: [PATCH] tty/serial: add support for Xilinx PS UART

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 20 Apr 2011 16:35:35 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	John Linn <John.Linn@...inx.com>
Cc:	<linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>
Subject: Re: [PATCH] tty/serial: add support for Xilinx PS UART

> I see the subtle locking issue you mention.
> 
> This looks like a good way to help it, but it's not clear to me what to
> do in an isr 
> if the function returns a NULL for the tty.  In other places you can say
> the tty

It can happen, you must deal with it.

> It seems easier in this case to just move the tty =
> port->state->port.tty to after 
> the lock is acquired.

It can still be NULL.

> I'm sure there's something obvious I'm missing here.

It varies what drivers do but essentially what has occurred is that the
user side of the tty has gone away and you have an IRQ still. Your port
is still around as the lifetime of the port is the lifetime of your
serial driver creating/deleting it, but your tty has gone.

In those cases you need to do whatever needs doing to handle the IRQ and
processing that doesn't require the tty. That varies by device, in many
cases for example you read the data and chuck it rather than stuffing it
into the flip buffer.

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/