linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Miche Baker-Harvey <miche@google.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xensource.com, Anton Blanchard <anton@samba.org>,
	Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [PATCH v3 2/3] hvc_init():  Enforce one-time initialization.
Date: Wed, 09 Nov 2011 18:24:12 +1100	[thread overview]
Message-ID: <1320823452.9376.31.camel@concordia> (raw)
In-Reply-To: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Tue, 2011-11-08 at 13:45 -0800, Miche Baker-Harvey wrote:
> hvc_init() must only be called once, and no thread should continue with hvc_alloc()
> until after initialization is complete.  The original code does not enforce either
> of these requirements.  A new mutex limits entry to hvc_init() to a single thread,
> and blocks all later comers until it has completed.
> 
> This patch fixes multiple crash symptoms.

Hi Miche,

A few nit-picky comments below ..

> @@ -84,6 +85,10 @@ static LIST_HEAD(hvc_structs);
>   * list traversal.
>   */
>  static DEFINE_SPINLOCK(hvc_structs_lock);
> +/*
> + * only one task does allocation at a time.
> + */
> +static DEFINE_MUTEX(hvc_ports_mutex);

The comment is wrong, isn't it? Only one task does _init_ at a time.
Once the driver is initialised allocs can run concurrently.

So shouldn't it be called hvc_init_mutex ?

> @@ -825,11 +830,15 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
>  	int i;
>  
>  	/* We wait until a driver actually comes along */
> +	mutex_lock(&hvc_ports_mutex);
>  	if (!hvc_driver) {
>  		int err = hvc_init();
> -		if (err)
> +		if (err) {
> +			mutex_unlock(&hvc_ports_mutex);
>  			return ERR_PTR(err);
> +		}
>  	}
> +	mutex_unlock(&hvc_ports_mutex);
>  
>  	hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
>  			GFP_KERNEL);

It'd be cleaner I think to do all the locking in hvc_init(). That's safe
as long as you recheck !hvc_driver in hvc_init() with the lock held.

cheers


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2011-11-09  7:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08 21:44 [PATCH RFC v3 0/3] Support multiple VirtioConsoles Miche Baker-Harvey
2011-11-08 21:44 ` [PATCH v3 1/3] virtio_console: Fix locking of vtermno Miche Baker-Harvey
2011-11-11  4:27   ` Rusty Russell
2011-11-17 19:09     ` Amit Shah
2011-11-08 21:45 ` [PATCH v3 2/3] hvc_init(): Enforce one-time initialization Miche Baker-Harvey
2011-11-09  7:24   ` Michael Ellerman [this message]
2011-11-11  4:30   ` Rusty Russell
2011-11-17 18:57     ` Miche Baker-Harvey
2011-11-21  5:01       ` Rusty Russell
2011-11-21 22:16         ` Miche Baker-Harvey
2011-11-22  0:58           ` Rusty Russell
2011-11-23 10:38       ` Amit Shah
2011-11-23 12:56         ` Amit Shah
2011-11-23 13:06           ` Sasha Levin
2011-11-23 13:15             ` Amit Shah
2011-11-28 23:40         ` Miche Baker-Harvey
2011-11-29 14:21           ` Amit Shah
2011-11-29 17:04             ` Miche Baker-Harvey
2011-11-29 17:50               ` Miche Baker-Harvey
2011-12-05 10:54                 ` Amit Shah
2011-12-06 17:05                   ` Miche Baker-Harvey
2011-12-08 12:08                     ` Amit Shah
2011-12-12 19:11                       ` Miche Baker-Harvey
2011-12-12 19:25                         ` Amit Shah
2011-12-16  6:00                     ` Amit Shah
2011-11-08 21:45 ` [PATCH v3 3/3] Use separate struct console structure for each hvc_console Miche Baker-Harvey
2011-11-09  8:05   ` Michael Ellerman

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=1320823452.9376.31.camel@concordia \
    --to=michael@ellerman.id.au \
    --cc=amit.shah@redhat.com \
    --cc=anton@samba.org \
    --cc=digitaleric@google.com \
    --cc=gregkh@suse.de \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=miche@google.com \
    --cc=mikew@google.com \
    --cc=rusty@rustcorp.com.au \
    --cc=sfr@canb.auug.org.au \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xensource.com \
    /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).