All of lore.kernel.org
 help / color / mirror / Atom feed
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
> > 

  reply	other threads:[~2024-12-10 22:55 UTC|newest]

Thread overview: 19+ 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-09 17:23 ` ✓ i915.CI.BAT: success " Patchwork
2024-12-09 20:31 ` ✗ i915.CI.Full: 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.