Re: [PATCH v4 5/6] scsi: core: Protect host state changes with the host lock

On Mon, 3 Aug 2026 at 19:11, Bart Van Assche <[email protected]> wrote:
>
> On 8/3/26 10:01 AM, John Garry wrote:
> > On 31/07/2026 22:52, Bart Van Assche wrote:
> >> @@ -411,8 +413,8 @@ struct Scsi_Host *scsi_host_alloc(const struct
> >> scsi_host_template *sht, int priv
> >>           return NULL;
> >>       shost->host_lock = &shost->default_lock;
> >> -    spin_lock_init(shost->host_lock);
> >> -    shost->shost_state = SHOST_CREATED;
> >> +    scoped_guard(spinlock_init, shost->host_lock)
> >
> > Please forgive my ignorance, but what does spinlock_init do here in
> > relation to setting shost->shost_state?
> >
> > Elsewhere we have scoped_guard(spinlock_irq, shost->host_lock) for
> > protecting setting shost->shost_state and this makes sense to me.
> > However I am curious what scoped_guard(spinlock_init, ...) does.
>
> Support for scoped_guard(*_init, ...) and guard(*_init)(...) was
> introduced in January of this year. My understanding of commit
> d084a73714f8 ("compiler-context-analysis: Introduce scoped init guards")
> is as follows:
> * The referenced synchronization object is initialized. In this case
>    that means calling spinlock_init(shost->host_lock).
> * Compiler warnings triggered by __guarded_by() are suppressed for the
>    referenced synchronization object. In this case, the compiler is told
>    not to assume that shost->host_lock is acquired at the start of the
>    guarded code block and released at the end of the guarded code block.
>
> Marco, please correct me if I got this wrong.

Right - documentation also summarizes this:
https://docs.kernel.org/next/dev-tools/context-analysis.html#supported-kernel-primitives