Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a9b00df6-cacc-56e7-82d9-e7b2875aa898@redhat.com>
Date:   Tue, 20 Sep 2022 17:04:35 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH v2] locking/qspinlock: Do spin-wait in slowpath if
 preemptible
Content-Language: en-US
To:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Boqun Feng <boqun.feng@gmail.com>
Cc:     linux-kernel@vger.kernel.org
References: <20220920195542.1548164-1-longman@redhat.com>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <20220920195542.1548164-1-longman@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/20/22 15:55, Waiman Long wrote:
> There are some code paths in the kernel where arch_spin_lock() will be
> called directly when the lock isn't expected to be contended and critical
> section is short. For example, tracing_saved_cmdlines_size_read()
> in kernel/trace/trace.c does that.
>
> In most cases, preemption is also not disabled. This creates a problem
> for the qspinlock slowpath which expects preemption to be disabled
> to guarantee the safe use of per cpu qnodes structure. To work around
> these special use cases, add a preemption count check in the slowpath
> and do a simple spin-wait when preemption isn't disabled.
>
> Fixes: a33fda35e3a7 ("Introduce a simple generic 4-byte queued spinlock")
> Signed-off-by: Waiman Long <longman@redhat.com>

On second thought, I believe the proper way to fix this is to make sure 
that all the callers of arch_spin_lock() has preemption properly 
disabled. Will work on another patch set to do that. So please ignore 
this patch and sorry for the noise.

Cheers,
Longman