Killing off __cond_lock()

[Peter Zijlstra <peterz@infradead.org>]

Hi all,

So the kernel has this __cond_lock() crap pile, which is implemented
like:

#define __acquire(x)       __context__(x,1)
#define __cond_lock(x,c)   ((c) ? ({ __acquire(x); 1; }) : 0)

Now the problem with this is that people send ugly patches like:

https://lkml.org/lkml/2012/3/24/57
http://www.spinics.net/lists/mm-commits/msg80386.html

That basically wrap an existing function in an inline function just to
use __cond_lock() on the return value.

It would be ever so much nicer if we could declare such functions like:

struct anon_vma *page_lock_anon_vma(struct page *page)
	__cond_acquires(RCU) 
	__cond_acquires(page_lock_anon_vma(page)->root->lock);

Meaning that if the return value is true (non-zero), it would acquire
that lock/context. One could of course add some shorter means of
referring to the return value, but simply using the function in the
expression should be simple enough.

In order to implement this I guess we need to extend the
__attribute__((context(expr,in,out))) thing. 

Currently in,out are explicit value constants, but I guess if we make
them expressions we could evaluate them and get dynamic behaviour.

Thus allowing something like:

int spin_trylock(spinlock_t *lock)
	__attribute__((context(lock, 0, !!spin_trylock(lock));

meaning that the context would be incremented by 1 if the return value
were true.

Having only briefly looked at the sparse source, is this feasible to
implement or do we get chicken/egg problems wrt using a function before
its declaration is complete, and referring a return value before the
function is part of an expression?

If this yields problems, are there better ways of solving this issue?