From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>,
<intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>, <jani.saarinen@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>
Subject: Re: [RFT] Revert "lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING."
Date: Tue, 10 Dec 2024 17:55:35 -0500 [thread overview]
Message-ID: <Z1jG53Hy0PZKdJG2@intel.com> (raw)
In-Reply-To: <djny2tqz7mck5omsadowtn7flnegizoxgmpymyyfr3gvw4x7vf@67pbgkqftwxf>
On Tue, Dec 10, 2024 at 09:00:13AM -0800, Lucas De Marchi wrote:
> On Mon, Dec 09, 2024 at 03:53:51PM +0200, Luca Coelho wrote:
> > This reverts commit 560af5dc839eef08a273908f390cfefefb82aa04.
> >
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> > ---
> >
> > It seems that we have a few issues with this configuration in xe and
> > in i915. Let's try to revert it to see if the problems we're seeing
> > go away.
> >
> > Note, these are _real_ issues, but only if CONFIG_RT is enabled, so the actual issues need to be solved properly, but we can revert this change until then, to avoid regressions.
>
> +Jani Nikula, +Rodrigo
>
> I'm thinking about landing this in topic/core-for-CI. It seems we have
> quite a few locks to revisit - we are taking spinlocks while holding
> raw_spinlocks and until now there's no warning about this bug.
could you point to one case? I don't see us using the raw_spinlocks...
>
> It's a real problem only for PREEMPT_RT since otherwise there's
> no difference between the 2 lock types. However fixing this may involve
> quite a few changes: if we convert the lock to raw we may need to
> cascade the conversions to additional locks. The ones I identified are:
> pmu->lock, which would also need to have uncore->lock converted, which
> would then probably cascade to quite a few others :-/. I'm not sure
> converting uncore->lock will actually be a good thing.
hmm raw_spinlocks for the lowlevel might not be a bad idea, but perhaps
we need to convert the other way around the upper levels?
>
> I will keep digging.
Ack on getting this to topic/core-for-CI so we don't block our
CI while we investigate and fix this.
Thanks,
Rodrigo.
>
>
> Lucas De Marchi
>
>
> >
> >
> > lib/Kconfig.debug | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index f3d723705879..de4ffe09323b 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -1397,14 +1397,22 @@ config PROVE_LOCKING
> > For more details, see Documentation/locking/lockdep-design.rst.
> >
> > config PROVE_RAW_LOCK_NESTING
> > - bool
> > + bool "Enable raw_spinlock - spinlock nesting checks"
> > depends on PROVE_LOCKING
> > - default y
> > + default n
> > help
> > Enable the raw_spinlock vs. spinlock nesting checks which ensure
> > that the lock nesting rules for PREEMPT_RT enabled kernels are
> > not violated.
> >
> > + NOTE: There are known nesting problems. So if you enable this
> > + option expect lockdep splats until these problems have been fully
> > + addressed which is work in progress. This config switch allows to
> > + identify and analyze these problems. It will be removed and the
> > + check permanently enabled once the main issues have been fixed.
> > +
> > + If unsure, select N.
> > +
> > config LOCK_STAT
> > bool "Lock usage statistics"
> > depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
> > --
> > 2.45.2
> >
next prev parent reply other threads:[~2024-12-10 22:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 13:53 [RFT] Revert "lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING." Luca Coelho
2024-12-09 13:58 ` Luca Coelho
2024-12-09 14:44 ` ✓ CI.Patch_applied: success for " Patchwork
2024-12-09 14:44 ` ✓ CI.checkpatch: " Patchwork
2024-12-09 14:44 ` ✗ CI.KUnit: failure " Patchwork
2024-12-10 11:17 ` ✓ CI.Patch_applied: success for Revert "lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING." (rev2) Patchwork
2024-12-10 11:17 ` ✓ CI.checkpatch: " Patchwork
2024-12-10 11:19 ` ✓ CI.KUnit: " Patchwork
2024-12-10 11:45 ` ✓ CI.Build: " Patchwork
2024-12-10 11:48 ` ✓ CI.Hooks: " Patchwork
2024-12-10 11:51 ` ✓ CI.checksparse: " Patchwork
2024-12-10 12:19 ` ✓ Xe.CI.BAT: " Patchwork
2024-12-10 13:24 ` ✗ Xe.CI.Full: failure " Patchwork
2024-12-10 17:00 ` [RFT] Revert "lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING." Lucas De Marchi
2024-12-10 22:55 ` Rodrigo Vivi [this message]
2024-12-11 0:00 ` Lucas De Marchi
2024-12-12 9:31 ` Peter Zijlstra
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=Z1jG53Hy0PZKdJG2@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jani.saarinen@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=luciano.coelho@intel.com \
/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