What is the significance of __releases & __acquires in rpm_callback() of power/runtime.c ?
While going thro’ run time power management code in K39 power/runtime.c file, am seeing a function definition as given below. Any idea, what “__releases” & “__acquires” are doing in this function definition? static int rpm_callback(int (*cb)(struct device *), struct device *dev) __releases(&dev->power.lock) __acquires(&dev->power.lock) { int retval; …. return retval; }
read up: http://en.wikipedia.org/wiki/Sparse it was introduced to facilitate static source code checking, and the "attribute" itself is part of GCC: http://www.unixwiz.net/techtips/gnu-c-attributes.html Reading up here: http://old.nabble.com/A-question-about-sparse%3A-how-to-use-__acquires()-and... http://www.gossamer-threads.com/lists/linux/kernel/680631 https://lkml.org/lkml/2006/8/22/325 my understanding is that the annotation will help u to identify whether is lock is to be release or acquired, and if u did not do it (eg, in a if-then loop, only one part release the lock, but not the other), locks contentions problem may happened - so the parser (sparse) will immediately highlight that. normally not releasing a lock will lead to CPU hard-hanging, or CPU-reaching 100% utilization bugs. and if the lock can be used for both purpose, then u have to double declare it (as release + acquire type): http://old.nabble.com/linux-next%3A-manual-merge-of-the-percpu-tree-with-Linus'-tree-td26126413.html On Mon, Oct 10, 2011 at 6:58 PM, venu <bvg_1@yahoo.com> wrote:
While going thro’ run time power management code in K39 power/runtime.c file, am seeing a function definition as given below. Any idea, what “__releases” & “__acquires” are doing in this function definition?
static int rpm_callback(int (*cb)(struct device *), struct device *dev) __releases(&dev->power.lock) __acquires(&dev->power.lock) { int retval; …. return retval; }
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
participants (2)
-
Peter Teoh -
venu