On Fri, Jan 27, 2017 at 10:36:16AM -0800, Stephen Hemminger wrote: > On Fri, 27 Jan 2017 18:08:35 +0000 > KY Srinivasan <k...@microsoft.com> wrote: > > > > -----Original Message----- > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Monday, January 23, 2017 5:40 PM > > > To: KY Srinivasan <k...@microsoft.com>; Haiyang Zhang > > > <haiya...@microsoft.com> > > > Cc: de...@linuxdriverproject.org; Stephen Hemminger > > > <sthem...@microsoft.com> > > > 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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
