[PATCH tip/locking/core 0/6] compiler-context-analysis: Scoped init guards
Christoph Hellwig
hch at lst.de
Thu Jan 22 06:30:42 UTC 2026
On Tue, Jan 20, 2026 at 11:52:11AM +0100, Peter Zijlstra wrote:
> > So I think the first step is to avoid implying the safety of guarded
> > member access by initialing the lock. We then need to think how to
> > express they are save, which would probably require explicit annotation
> > unless we can come up with a scheme that makes these accesses fine
> > before the mutex_init in a magic way.
>
> But that is exactly what these patches do!
>
> Note that the current state of things (tip/locking/core,next) is that
> mutex_init() is 'special'. And I agree with you that that is quite
> horrible.
>
> Now, these patches, specifically patch 6, removes this implied
> horribleness.
>
> The alternative is an explicit annotation -- as you suggest.
>
>
> So given something like:
>
> struct my_obj {
> struct mutex mutex;
> int data __guarded_by(&mutex);
> ...
> };
>
>
> tip/locking/core,next:
>
> init_my_obj(struct my_obj *obj)
> {
> mutex_init(&obj->mutex); // implies obj->mutex is taken until end of function
> obj->data = FOO; // OK, because &obj->mutex 'held'
> ...
> }
>
> And per these patches that will no longer be true. So if you apply just
> patch 6, which removes this implied behaviour, you get a compile fail.
> Not good!
>
> So patches 1-5 introduces alternatives.
>
> So your preferred solution:
>
> hch_my_obj(struct my_obj *obj)
> {
> mutex_init(&obj->mutex);
> mutex_lock(&obj->mutex); // actually acquires lock
> obj->data = FOO;
> ...
> }
>
> is perfectly fine and will work. But not everybody wants this. For the
> people that only need to init the data fields and don't care about the
> lock state we get:
>
> init_my_obj(struct my_obj *obj)
> {
> guard(mutex_init)(&obj->mutex); // initializes mutex and considers lock
> // held until end of function
> obj->data = FOO;
> ...
> }
And this is just as bad as the original version, except it is now
even more obfuscated.
> And for the people that *reaaaaaly* hate guards, it is possible to write
> something like:
>
> ugly_my_obj(struct my_obj *obj)
> {
> mutex_init(&obj->mutex);
> __acquire_ctx_lock(&obj->mutex);
> obj->data = FOO;
> ...
> __release_ctx_lock(&obj->mutex);
>
> mutex_lock(&obj->lock);
> ...
That's better. What would be even better for everyone would be:
mutex_prepare(&obj->mutex); /* acquire, but with a nice name */
obj->data = FOO;
mutex_init_prepared(&obj->mutex); /* release, barrier, actual init */
mutex_lock(&obj->mutex); /* IFF needed only */
More information about the Linux-security-module-archive
mailing list