linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] rapidio: run discovery as an asynchronous process
Date: Wed, 3 Oct 2012 15:29:53 -0700	[thread overview]
Message-ID: <20121003152953.79aecece.akpm@linux-foundation.org> (raw)
In-Reply-To: <1349291923-22860-4-git-send-email-alexandre.bounine@idt.com>

On Wed,  3 Oct 2012 15:18:41 -0400
Alexandre Bounine <alexandre.bounine@idt.com> wrote:

> Modify mport initialization routine to run the RapidIO discovery process
> asynchronously. This allows to have an arbitrary order of enumerating and
> discovering ports in systems with multiple RapidIO controllers without
> creating a deadlock situation if enumerator port is registered after a
> discovering one.
> 
> Making netID matching to mportID ensures consistent net ID assignment in
> multiport RapidIO systems with asynchronous discovery process (global counter
> implementation is affected by race between threads).
> 
>
> ...
>
> +static void __devinit disc_work_handler(struct work_struct *_work)
> +{
> +	struct rio_disc_work *work = container_of(_work,
> +						  struct rio_disc_work, work);

There's a nice simple way to avoid such ugliness:

--- a/drivers/rapidio/rio.c~rapidio-run-discovery-as-an-asynchronous-process-fix
+++ a/drivers/rapidio/rio.c
@@ -1269,9 +1269,9 @@ struct rio_disc_work {
 
 static void __devinit disc_work_handler(struct work_struct *_work)
 {
-	struct rio_disc_work *work = container_of(_work,
-						  struct rio_disc_work, work);
+	struct rio_disc_work *work;
 
+	work = container_of(_work, struct rio_disc_work, work);
 	pr_debug("RIO: discovery work for mport %d %s\n",
 		 work->mport->id, work->mport->name);
 	rio_disc_mport(work->mport);
_

> +	pr_debug("RIO: discovery work for mport %d %s\n",
> +		 work->mport->id, work->mport->name);
> +	rio_disc_mport(work->mport);
> +
> +	kfree(work);
> +}
> +
>  int __devinit rio_init_mports(void)
>  {
>  	struct rio_mport *port;
> +	struct rio_disc_work *work;
> +	int no_disc = 0;
>  
>  	list_for_each_entry(port, &rio_mports, node) {
>  		if (port->host_deviceid >= 0)
>  			rio_enum_mport(port);
> -		else
> -			rio_disc_mport(port);
> +		else if (!no_disc) {
> +			if (!rio_wq) {
> +				rio_wq = alloc_workqueue("riodisc", 0, 0);
> +				if (!rio_wq) {
> +					pr_err("RIO: unable allocate rio_wq\n");
> +					no_disc = 1;
> +					continue;
> +				}
> +			}
> +
> +			work = kzalloc(sizeof *work, GFP_KERNEL);
> +			if (!work) {
> +				pr_err("RIO: no memory for work struct\n");
> +				no_disc = 1;
> +				continue;
> +			}
> +
> +			work->mport = port;
> +			INIT_WORK(&work->work, disc_work_handler);
> +			queue_work(rio_wq, &work->work);
> +		}
> +	}

I'm having a lot of trouble with `no_disc'.  afacit what it does is to
cease running async discovery for any remaining devices if the workqueue
allocation failed (vaguely reasonable) or if the allocation of a single
work item failed (incomprehensible).

But if we don't run discovery, the subsystem is permanently busted for
at least some devices, isn't it?

And this code is basically untestable unless the programmer does
deliberate fault injection, which makes it pretty much unmaintainable.

So...  if I haven't totally misunderstood, I suggest a rethink is in
order?

> +	if (rio_wq) {
> +		pr_debug("RIO: flush discovery workqueue\n");
> +		flush_workqueue(rio_wq);
> +		pr_debug("RIO: flush discovery workqueue finished\n");
> +		destroy_workqueue(rio_wq);
>  	}

  reply	other threads:[~2012-10-03 22:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 19:18 [PATCH 0/5] rapidio: patches to support multiple master ports Alexandre Bounine
2012-10-03 19:18 ` [PATCH 1/5] rapidio: fix blocking wait for discovery ready Alexandre Bounine
2012-10-03 22:20   ` Andrew Morton
2012-10-04 17:20     ` Bounine, Alexandre
2012-10-03 19:18 ` [PATCH 2/5] rapidio: use device lists handling on per-net basis Alexandre Bounine
2012-10-03 19:18 ` [PATCH 3/5] rapidio: run discovery as an asynchronous process Alexandre Bounine
2012-10-03 22:29   ` Andrew Morton [this message]
2012-10-04 19:08     ` Bounine, Alexandre
2012-10-03 19:18 ` [PATCH 4/5] rapidio/rionet: rework to support multiple RIO master ports Alexandre Bounine
2012-10-03 19:18 ` [PATCH 5/5] rapidio: add destination ID allocation mechanism Alexandre Bounine
2012-10-03 22:36   ` Andrew Morton
2012-10-04 20:39     ` Bounine, Alexandre

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=20121003152953.79aecece.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=alexandre.bounine@idt.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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).