virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'devel@driverdev.osuosl.org'" <devel@driverdev.osuosl.org>,
	"'virtualization@lists.osdl.org'" <virtualization@lists.osdl.org>,
	Hank Janssen <hjanssen@microsoft.com>
Subject: Re: [PATCH 1/1] staging: hv: Fix race condition on IC channel initialization (modified)
Date: Wed, 26 May 2010 14:48:42 -0700	[thread overview]
Message-ID: <20100526214842.GA27908@suse.de> (raw)
In-Reply-To: <1FB5E1D5CA062146B38059374562DF7266B8C72B@TK5EX14MBXC128.redmond.corp.microsoft.com>

On Wed, May 26, 2010 at 09:25:31PM +0000, Haiyang Zhang wrote:
> > From: Greg KH [mailto:gregkh@suse.de]
> > > +	static atomic_t ic_channel_initcnt = ATOMIC_INIT(0);
> > Why is this an atomic_t?
> 
> As discussed previously, I used atomic_t to handle more general case 
> if vmbus interrupts happen on every cpu.

Ok, but then you should use a lock to protect the variable, not an atomic_t.

> 
> > > +			    VmbusChannelOpen(newChannel, 2 * PAGE_SIZE,
> > > +					     2 * PAGE_SIZE, NULL, 0,
> > > +					     hv_cb_utils[cnt].callback,
> > > +					     newChannel) == 0) {
> > > +				hv_cb_utils[cnt].channel = newChannel;
> > > +				mb();
> > 
> > What is the mb() call for?  Why is it necessary?  (hint, if you need it,
> > something else is really wrong...)
> 
> It ensures the channel assignment happens before the wakeup call: 
> osd_WaitEventSet(ic_channel_ready), if the compiler optimization re-arrange 
> the execution order. 

If you care about this, because some other thread is looking at it, then
you really need to protect it with a lock.  Don't rely on a mb() to get
it all correct for you (hint, I doubt it will...)

> > Something wierd happened with your indentation here, it doesn't line up
> > properly.  That call to VmbusChannelOpen() needs to go in a full tab,
> > not 4 spaces.
> > 
> > Please always run your patch through the checkpatch.pl script before
> > sending it to me.
> 
> Sure, I will replace it with TAB. I already ran checkpatch.pl on 
> this patch -- no error:
> staging-next-2.6> scripts/checkpatch.pl 0525-Fix-race-condition-on-IC-channel-initialization.patch
> total: 0 errors, 0 warnings, 71 lines checked
> 
> 0525-Fix-race-condition-on-IC-channel-initialization.patch has no obvious style problems and is ready for submission.

Looks like a bug in checkpatch.pl, go poke Andy about that please.

> > > +struct osd_waitevent *ic_channel_ready;
> > 
> > What's with the "ic_" naming scheme here?  It should be "hv_" right?
> 
> IC stands for "integration components", such as Shutdown, Timesync, 
> Heartbeat, etc.

Yes, I know what it stands for, but the rest of the world doesn't :)

> > As you are using this "ic_channel_ready variable only within the
> > vmbus_bus_init() call, why not just make it local to there?  Then
> > there's no need to do the create/init/wait/free sequence outside the
> > init call.
> > 
> > The init call should just do all of this for us, right?
> 
> The ic_channel_ready variable is called by VmbusChannelProcessOffer /
> osd_WaitEventSet(ic_channel_ready) to wake up vmbus_init(). So it's
> not a local variable.

But again, this logic should be within the init call, as it's part of
the proper init sequence.  So just put it in that call please.

thanks,

greg k-h

  reply	other threads:[~2010-05-26 21:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1FB5E1D5CA062146B38059374562DF7266B8C4AC@TK5EX14MBXC128.redmond.corp.microsoft.com>
2010-05-26 20:51 ` [PATCH 1/1] staging: hv: Fix race condition on IC channel initialization (modified) Greg KH
2010-05-26 21:25   ` Haiyang Zhang
2010-05-26 21:48     ` Greg KH [this message]
2010-05-26 22:03       ` Hank Janssen
2010-05-26 22:23       ` Haiyang Zhang
2010-05-26 22:30         ` Greg KH
2010-05-26 22:52           ` Haiyang Zhang
2010-05-27 23:22             ` Greg KH
2010-05-27  6:16     ` Jiri Slaby
2010-05-26 16:54 Haiyang Zhang

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=20100526214842.GA27908@suse.de \
    --to=gregkh@suse.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=haiyangz@microsoft.com \
    --cc=hjanssen@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.osdl.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).