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
next prev parent reply other threads:[~2010-05-26 21:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 16:54 [PATCH 1/1] staging: hv: Fix race condition on IC channel initialization (modified) Haiyang Zhang
2010-05-26 20:51 ` 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:03 ` Hank Janssen
2010-05-26 22:23 ` Haiyang Zhang
2010-05-26 22:30 ` Greg KH
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
-- strict thread matches above, loose matches on Subject: below --
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.