On Fri, Jan 27, 2017 at 10:36:16AM -0800, Stephen Hemminger wrote: > 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. Sparse doesn't do any sort of proper flow analysis. It's the wrong tool for checking locking. Of course, Smatch is not much better. I've been saying for years that I need to re-write the locking checks but I always get distracted... But at least it does flow analysis and understands conditional locking. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
