linux-kernel - RE: [PATCH 1/1] staging: hv: Fix race condition on IC channel initialization (modified)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 May 2010 21:25:31 +0000
From:	Haiyang Zhang <haiyangz@...rosoft.com>
To:	Greg KH <gregkh@...e.de>
CC:	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'devel@...verdev.osuosl.org'" <devel@...verdev.osuosl.org>,
	"'virtualization@...ts.osdl.org'" <virtualization@...ts.osdl.org>,
	"Hank Janssen" <hjanssen@...rosoft.com>
Subject: RE: [PATCH 1/1] staging: hv: Fix race condition on IC channel
 initialization (modified)

> From: Greg KH [mailto:gregkh@...e.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.

> > +			    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. 

> 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.

> > +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.

> 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.

Thanks,

- Haiyang

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/