Re: Thread Safety Analysis and the Linux kernel

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Mar 06, 2025 at 08:18:37AM -0800, Bart Van Assche wrote:
> On 3/6/25 1:47 AM, Peter Zijlstra wrote:
> > That no longer works for the case of:
> > 
> > DEFINE_GUARD_COND(mutex, _try, mutex_trylock(_T))
> > 
> > which expands to have a constructor like:
> > 
> > static inline struct mutex * class_mutex_try_constructor(struct mutex *_T)
> > {
> > 	struct mutex * t = ({ void *_t = _T; if (_T && !(mutex_trylock(_T))) _t = NULL; _t; });
> > 	return t;
> > }
> 
> Hi Peter,
> 
> Would it be acceptable to introduce variants of the conditional locking
> functions that return the mutex pointer instead of a boolean to indicate
> whether or not locking succeeded? 

So I don't think we need to do that. All that is important is that the
thing can track the return value of the constructor to the argument of
the destructor. What actually happens inside those functions is
immaterial.

(I got myself slightly confused when writing that earlier email).

Anyway, for DEFINE_GUARD_COND() we can do:

        EXTEND_CLASS(_name, _ext, \
-                    ({ void *_t = _T; if (_T && !(_condlock)) _t = NULL; _t; }), \
+                    ({ void *_t = (_condlock) ? _T : NULL; _t; }), \
                     class_##_name##_t _T) \

But it becomes a little more tricky for DEFINE_LOCK_GUARD_1_COND().

Still, like I argued above, I don't think it matters.