From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 01/10] drivers: PL011: avoid potential unregister_driver call
Date: Thu, 12 Mar 2015 10:42:59 +0000 [thread overview]
Message-ID: <20150312104258.GI8656@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1425491994-23913-2-git-send-email-andre.przywara@arm.com>
On Wed, Mar 04, 2015 at 05:59:45PM +0000, Andre Przywara wrote:
> Although we care about not unregistering the driver if there are
> still ports connected during the .remove callback, we do miss this
> check in the pl011_probe function. So if the current port allocation
> fails, but there are other ports already registered, we will kill
> those.
> So factor out the port removal into a separate function and use that
> in the probe function, too.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/tty/serial/amba-pl011.c | 38 +++++++++++++++++++++-----------------
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 92783fc..961f9b0 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2235,6 +2235,24 @@ static int pl011_probe_dt_alias(int index, struct device *dev)
> return ret;
> }
>
> +/* unregisters the driver also if no more ports are left */
> +static void pl011_unregister_port(struct uart_amba_port *uap)
> +{
> + int i;
> + bool busy = false;
> +
> + for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
> + if (amba_ports[i] == uap)
> + amba_ports[i] = NULL;
> + else if (amba_ports[i])
> + busy = true;
> + }
> + pl011_dma_remove(uap);
> + if (!busy)
> + uart_unregister_driver(&amba_reg);
> +}
This is still racy, as I pointed out at the time this crap was dreamt
up.
There is _no_ locking between an individual driver's ->probe or ->remove
functions being called concurrently for different devices. The only
locking which the driver model guarantees is that a single struct device
can only be probed by one driver at a time.
Multiple struct device's can be in-progress of ->probe or ->remove
simultaneously.
However, this isn't your bug to solve... it's those who were proponents
of this crap approach.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-03-12 10:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 17:59 [PATCH v2 00/10] drivers: PL011: add ARM SBSA Generic UART support Andre Przywara
2015-03-04 17:59 ` [PATCH v2 01/10] drivers: PL011: avoid potential unregister_driver call Andre Przywara
2015-03-12 10:42 ` Russell King - ARM Linux [this message]
2015-04-08 15:39 ` Andre Przywara
2015-04-08 18:14 ` Russell King - ARM Linux
2015-03-04 17:59 ` [PATCH v2 02/10] drivers: PL011: refactor pl011_startup() Andre Przywara
2015-03-04 17:59 ` [PATCH v2 03/10] drivers: PL011: refactor pl011_shutdown() Andre Przywara
2015-03-04 17:59 ` [PATCH v2 04/10] drivers: PL011: refactor pl011_set_termios() Andre Przywara
2015-03-04 17:59 ` [PATCH v2 05/10] drivers: PL011: refactor pl011_probe() Andre Przywara
2015-03-04 17:59 ` [PATCH v2 06/10] drivers: PL011: replace UART_MIS reading with _RIS & _IMSC Andre Przywara
2015-03-12 10:46 ` Russell King - ARM Linux
2015-03-04 17:59 ` [PATCH v2 07/10] drivers: PL011: move cts_event workaround into separate function Andre Przywara
2015-03-07 3:00 ` Greg KH
2015-03-04 17:59 ` [PATCH v2 08/10] drivers: PL011: allow avoiding UART enabling/disabling Andre Przywara
2015-03-04 17:59 ` [PATCH v2 09/10] drivers: PL011: allow to supply fixed option string Andre Przywara
2015-03-04 17:59 ` [PATCH v2 10/10] drivers: PL011: add support for the ARM SBSA generic UART Andre Przywara
2015-03-09 15:59 ` Dave Martin
2015-03-12 10:52 ` Russell King - ARM Linux
2015-03-12 13:43 ` Andre Przywara
2015-03-12 13:49 ` Russell King - ARM Linux
2015-03-12 13:58 ` Andre Przywara
2015-03-07 3:01 ` [PATCH v2 00/10] drivers: PL011: add ARM SBSA Generic UART support Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150312104258.GI8656@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).