What is the significance of __releases & __acquires in rpm_callback() of power/runtime.c ?

[Peter Teoh]

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-__releases()-correctly---td20799721.html

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 at 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111011/e2990a62/attachment-0001.html