[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260116152016.GI831050@noisy.programming.kicks-ass.net>
Date: Fri, 16 Jan 2026 16:20:16 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Christoph Hellwig <hch@....de>
Cc: Marco Elver <elver@...gle.com>, Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Will Deacon <will@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, Waiman Long <longman@...hat.com>,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH tip/locking/core] compiler-context-analysis: Support
immediate acquisition after initialization
On Fri, Jan 16, 2026 at 04:10:43PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 16, 2026 at 04:07:50PM +0100, Peter Zijlstra wrote:
> > LGTM; Steve, Christoph, does this work for you guys? Init and then lock
> > would look something like:
>
> Please do something that works without all these messy guards that just
> obfuscate the code.
I think we're doing to have to agree to disagree on this.
Something like:
scoped_guard (spinlock_init, &obj->lock) {
// init
}
is *much* clearer than something like:
spinlock_init(&obj->lock);
// init
spinlock_deinit(&obj->lock);
Exactly because it has explicit scope. (also my deinit naming might not
be optimal, it is ambiguous at best, probably confusing).
Not to mention that the scope things are far more robust vs error paths.
Powered by blists - more mailing lists