[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221107163016.cnzhknmdnhajfxdh@quack3>
Date: Mon, 7 Nov 2022 17:30:16 +0100
From: Jan Kara <jack@...e.cz>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Mel Gorman <mgorman@...e.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Catalin Marinas <catalin.marinas@....com>
Subject: Re: Crash with PREEMPT_RT on aarch64 machine
On Mon 07-11-22 16:10:34, 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.
Just to confirm, CONFIG_DEBUG_RT_MUTEXES is the only thing I've enabled and
the list corruption disappeared.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists