linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Jan Kara <jack@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mel Gorman <mgorman@suse.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: Crash with PREEMPT_RT on aarch64 machine
Date: Mon, 7 Nov 2022 11:49:01 -0500	[thread overview]
Message-ID: <359cc93a-fce0-5af2-0fd5-81999fad186b@redhat.com> (raw)
In-Reply-To: <Y2kf6tcX47Cl7q0W@linutronix.de>

On 11/7/22 10:10, Sebastian Andrzej Siewior wrote:
> + locking, arm64
>
> On 2022-11-07 14:56:36 [+0100], Jan Kara wrote:
>>> spinlock_t and raw_spinlock_t differ slightly in terms of locking.
>>> rt_spin_lock() has the fast path via try_cmpxchg_acquire(). If you
>>> enable CONFIG_DEBUG_RT_MUTEXES then you would force the slow path which
>>> always acquires the rt_mutex_base::wait_lock (which is a raw_spinlock_t)
>>> while the actual lock is modified via cmpxchg.
>> So I've tried enabling CONFIG_DEBUG_RT_MUTEXES and indeed the corruption
>> stops happening as well. So do you suspect some bug in the CPU itself?
> If it is only enabling CONFIG_DEBUG_RT_MUTEXES (and not whole lockdep)
> then it looks very suspicious.
> CONFIG_DEBUG_RT_MUTEXES enables a few additional checks but the main
> part is that rt_mutex_cmpxchg_acquire() + rt_mutex_cmpxchg_release()
> always fail (and so the slowpath under a raw_spinlock_t is done).
>
> So if it is really the fast path (rt_mutex_cmpxchg_acquire()) then it
> somehow smells like the CPU is misbehaving.
>
> Could someone from the locking/arm64 department check if the locking in
> RT-mutex (rtlock_lock()) is correct?
>
> rtmutex locking uses try_cmpxchg_acquire(, ptr, ptr) for the fastpath
> (and try_cmpxchg_release(, ptr, ptr) for unlock).
> Now looking at it again, I don't see much difference compared to what
> queued_spin_trylock() does except the latter always operates on 32bit
> value instead a pointer.

Both the fast path of queued spinlock and rt_spin_lock are using 
try_cmpxchg_acquire(), the only difference I saw is the size of the data 
to be cmpxchg'ed. qspinlock uses 32-bit integer whereas rt_spin_lock 
uses 64-bit pointer. So I believe it is more on how the arm64 does 
cmpxchg. I believe there are two different ways of doing it depending on 
whether LSE atomics is available in the platform. So exactly what arm64 
system is being used here and what hardware capability does it have?

Cheers,
Longman


  parent reply	other threads:[~2022-11-07 16:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 11:54 Crash with PREEMPT_RT on aarch64 machine Jan Kara
2022-11-04 16:30 ` Sebastian Andrzej Siewior
2022-11-07 13:56   ` Jan Kara
2022-11-07 15:10     ` Sebastian Andrzej Siewior
2022-11-07 16:30       ` Jan Kara
2022-11-07 17:12         ` Sebastian Andrzej Siewior
2022-11-07 16:49       ` Waiman Long [this message]
2022-11-08 10:53         ` Mark Rutland
2022-11-08 17:45           ` Jan Kara
2022-11-09  9:55             ` Mark Rutland
2022-11-09 10:11               ` Pierre Gondois
2022-11-09 10:54                 ` Jan Kara
2022-11-09 11:01               ` Jan Kara
2022-11-09 13:52                 ` Pierre Gondois
2022-11-09 14:21                   ` Pierre Gondois
2022-11-09 12:57         ` Will Deacon
2022-11-09 15:40           ` Jan Kara
2022-11-11 14:27             ` Jan Kara
2022-11-14 12:41               ` Will Deacon
2022-11-28 15:58                 ` Sebastian Andrzej Siewior
2022-11-28 20:30                   ` kernel test robot
2022-11-28 21:11                   ` kernel test robot
2022-11-29  5:16                   ` kernel test robot
2022-11-29  5:26                   ` kernel test robot
2022-11-29  6:48                   ` kernel test robot
2022-11-29  7:39                   ` kernel test robot
2022-11-30 17:20                   ` Pierre Gondois
2022-12-01 12:37                     ` Jan Kara
2022-11-30 20:22                   ` Mel Gorman
2022-12-01 17:09                     ` Mel Gorman
     [not found] ` <20221104080637.626-1-hdanton@sina.com>
2022-11-07 12:41   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=359cc93a-fce0-5af2-0fd5-81999fad186b@redhat.com \
    --to=longman@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).