On Fri, 27 Jan 2017 18:08:35 +0000 KY Srinivasan <kys@xxxxxxxxxxxxx> wrote: > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@xxxxxxxxxxxxxxxxxx] > > Sent: Monday, January 23, 2017 5:40 PM > > To: KY Srinivasan <kys@xxxxxxxxxxxxx>; Haiyang Zhang > > <haiyangz@xxxxxxxxxxxxx> > > Cc: devel@xxxxxxxxxxxxxxxxxxxxxx; Stephen Hemminger > > <sthemmin@xxxxxxxxxxxxx> > > Subject: [PATCH 07/14] vmbus: remove conditional locking of vmbus_write > > > > All current usage of vmbus write uses the acquire_lock flag, therefore > > having it be optional is unnecessary. This also fixes a sparse warning > > since sparse doesn't like when a function has conditional locking. > > In order to avoid cross-tree dependency, I got this functionality into Greg's > tree first. I plan to submit patches to netvsc that will use this functionality. > As you know, we hold a higher level lock in the protocol stack when we send on > a sub-channel. This will avoid an unnecessary spin lock round trip in the data path. > > Regards, > > K. Y Conditional locking is in general a bad idea because it breaks static analysis tools like sparse. In order to have a non-locking code path then it is better to have a locked and unlocked version of the same functions. Also, in networking receive path is not specially single threaded. With my per-channel tasklet (and later NAPI), the each channel's receive path would be single threaded but there are still races possible in the shutdown logic (as written). Longer term it would be best if all vmbus events were handled per-channel without lock, ie networking is not a special case. Probably best to figure out how to make all VMBUS ring access lockless, ie it is callers responsibilty. Storage and networking are multi-queue already. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
