All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>,
	Jason Wessel <jason.wessel@windriver.com>,
	tglx@linutronix.de, mingo@kernel.org, gregkh@linuxfoundation.org,
	linux-arm-msm@vger.kernel.org,
	kgdb-bugreport@lists.sourceforge.net, nm@ti.com,
	linux-mips@linux-mips.org, dalias@libc.org,
	catalin.marinas@arm.com, vigneshr@ti.com,
	linux-aspeed@lists.ozlabs.org, linux-sh@vger.kernel.org,
	peterz@infradead.org, will.deacon@arm.com, mhocko@suse.com,
	paulus@samba.org, hpa@zytor.com, sparclinux@vger.kernel.org,
	marex@denx.de, sfr@canb.auug.org.au, ysato@users.sourceforge.jp,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	pombredanne@nexb.com, tony@atomide.com, mingo@redhat.com,
	joel@jms.id.au, linux-serial@vger.kernel.org,
	rolf.evers.fischer@aptiv.com, jhogan@kernel.org, asierra@xes-inc.
Subject: Re: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
Date: Tue, 30 Oct 2018 12:31:03 +0000	[thread overview]
Message-ID: <20181030123103.GL30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>

On Tue, Oct 30, 2018 at 11:56:28AM +0000, Daniel Thompson wrote:
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently.  The first is a serial series and the second is a
> > kgdb series.
> 
> Indeed.
> 
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
> 
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.

I'm concerned about calling smp_call_function() from IRQ context with
IRQs disabled - that will block the ability of the _calling_ CPU to
process IPIs from other CPUs in the system.  If we have other CPUs
waiting on their IPIs to complete on _this_ CPU, we could end up
deadlocking while trying to grab the CSD lock.

This is the intention of warnings in smp_call_function*() - to catch
cases where deadlocks _can_ occur, but do not reliably show up.

The exceptions to the warning (disregarding oops_in_progress) are
chosen to allow IRQs-disabled calls when we're sure that the rest of
the system isn't going to be sending the calling CPU an IPI (eg,
because the CPU isn't marked online, and we only send IPIs to online
CPUs, or if we're still early in the kernel boot and hence have no
other CPUs running.)  The exception is oops_in_progress, which can
occur at any time - even with the current CPU already holding some
CSD locks (eg, oops while trying to send an IPI.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>,
	Jason Wessel <jason.wessel@windriver.com>,
	tglx@linutronix.de, mingo@kernel.org, gregkh@linuxfoundation.org,
	linux-arm-msm@vger.kernel.org,
	kgdb-bugreport@lists.sourceforge.net, nm@ti.com,
	linux-mips@linux-mips.org, dalias@libc.org,
	catalin.marinas@arm.com, vigneshr@ti.com,
	linux-aspeed@lists.ozlabs.org, linux-sh@vger.kernel.org,
	peterz@infradead.org, will.deacon@arm.com, mhocko@suse.com,
	paulus@samba.org, hpa@zytor.com, sparclinux@vger.kernel.org,
	marex@denx.de, sfr@canb.auug.org.au, ysato@users.sourceforge.jp,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	pombredanne@nexb.com, tony@atomide.com, mingo@redhat.com,
	joel@jms.id.au, linux-serial@vger.kernel.org,
	rolf.evers.fischer@aptiv.com, jhogan@kernel.org,
	asierra@xes-inc.com, linux-snps-arc@lists.infradead.org,
	dan.carpenter@oracle.com, ying.huang@intel.com, riel@surriel.com,
	frederic@kernel.org, jslaby@suse.com, paul.burton@mips.com,
	rppt@linux.vnet.ibm.com, bp@alien8.de, luto@kernel.org,
	andriy.shevchenko@linux.intel.com,
	linux-arm-kernel@lists.infradead.org, christophe.leroy@c-s.fr,
	andrew@aj.id.au, linux-kernel@vger.kernel.org,
	ralf@linux-mips.org, rkuo@codeaurora.org,
	Jisheng.Zhang@synaptics.com, vgupta@synopsys.com,
	benh@kernel.crashing.org, jk@ozlabs.org, mpe@ellerman.id.au,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
	davem@davemloft.net, kstewart@linuxfoundation.org
Subject: Re: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
Date: Tue, 30 Oct 2018 12:31:03 +0000	[thread overview]
Message-ID: <20181030123103.GL30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>

On Tue, Oct 30, 2018 at 11:56:28AM +0000, Daniel Thompson wrote:
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently.  The first is a serial series and the second is a
> > kgdb series.
> 
> Indeed.
> 
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
> 
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.

I'm concerned about calling smp_call_function() from IRQ context with
IRQs disabled - that will block the ability of the _calling_ CPU to
process IPIs from other CPUs in the system.  If we have other CPUs
waiting on their IPIs to complete on _this_ CPU, we could end up
deadlocking while trying to grab the CSD lock.

This is the intention of warnings in smp_call_function*() - to catch
cases where deadlocks _can_ occur, but do not reliably show up.

The exceptions to the warning (disregarding oops_in_progress) are
chosen to allow IRQs-disabled calls when we're sure that the rest of
the system isn't going to be sending the calling CPU an IPI (eg,
because the CPU isn't marked online, and we only send IPIs to online
CPUs, or if we're still early in the kernel boot and hence have no
other CPUs running.)  The exception is oops_in_progress, which can
occur at any time - even with the current CPU already holding some
CSD locks (eg, oops while trying to send an IPI.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: nm@ti.com, linux-mips@linux-mips.org, dalias@libc.org,
	vigneshr@ti.com, linux-aspeed@lists.ozlabs.org,
	linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, mhocko@suse.com, paulus@samba.org,
	hpa@zytor.com, sparclinux@vger.kernel.org, jslaby@suse.com,
	mingo@kernel.org, marex@denx.de, sfr@canb.auug.org.au,
	ysato@users.sourceforge.jp, linux-hexagon@vger.kernel.org,
	x86@kernel.org, Jisheng.Zhang@synaptics.com, tony@atomide.com,
	mingo@redhat.com, joel@jms.id.au, linux-serial@vger.kernel.org,
	kgdb-bugreport@lists.sourceforge.net, jhogan@kernel.org,
	rolf.evers.fischer@aptiv.com, asierra@xes-inc.com,
	linux-snps-arc@lists.infradead.org, dan.carpenter@oracle.com,
	ying.huang@intel.com, riel@surriel.com,
	linux-arm-msm@vger.kernel.org, frederic@kernel.org,
	pombredanne@nexb.com, rppt@linux.vnet.ibm.com, bp@alien8.de,
	luto@kernel.org, tglx@linutronix.de,
	andriy.shevchenko@linux.intel.com,
	linux-arm-kernel@lists.infradead.org, andrew@aj.id.au,
	gregkh@linuxfoundation.org,
	Douglas Anderson <dianders@chromium.org>,
	ralf@linux-mips.org, rkuo@codeaurora.org, paul.burton@mips.com,
	vgupta@synopsys.com, jk@ozlabs.org,
	Jason Wessel <jason.wessel@windriver.com>,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
	davem@davemloft.net, kstewart@linuxfoundation.org
Subject: Re: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
Date: Tue, 30 Oct 2018 12:31:03 +0000	[thread overview]
Message-ID: <20181030123103.GL30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>

On Tue, Oct 30, 2018 at 11:56:28AM +0000, Daniel Thompson wrote:
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently.  The first is a serial series and the second is a
> > kgdb series.
> 
> Indeed.
> 
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
> 
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.

I'm concerned about calling smp_call_function() from IRQ context with
IRQs disabled - that will block the ability of the _calling_ CPU to
process IPIs from other CPUs in the system.  If we have other CPUs
waiting on their IPIs to complete on _this_ CPU, we could end up
deadlocking while trying to grab the CSD lock.

This is the intention of warnings in smp_call_function*() - to catch
cases where deadlocks _can_ occur, but do not reliably show up.

The exceptions to the warning (disregarding oops_in_progress) are
chosen to allow IRQs-disabled calls when we're sure that the rest of
the system isn't going to be sending the calling CPU an IPI (eg,
because the CPU isn't marked online, and we only send IPIs to online
CPUs, or if we're still early in the kernel boot and hence have no
other CPUs running.)  The exception is oops_in_progress, which can
occur at any time - even with the current CPU already holding some
CSD locks (eg, oops while trying to send an IPI.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
Date: Tue, 30 Oct 2018 12:31:03 +0000	[thread overview]
Message-ID: <20181030123103.GL30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>

On Tue, Oct 30, 2018@11:56:28AM +0000, Daniel Thompson wrote:
> On Mon, Oct 29, 2018@11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently.  The first is a serial series and the second is a
> > kgdb series.
> 
> Indeed.
> 
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
> 
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.

I'm concerned about calling smp_call_function() from IRQ context with
IRQs disabled - that will block the ability of the _calling_ CPU to
process IPIs from other CPUs in the system.  If we have other CPUs
waiting on their IPIs to complete on _this_ CPU, we could end up
deadlocking while trying to grab the CSD lock.

This is the intention of warnings in smp_call_function*() - to catch
cases where deadlocks _can_ occur, but do not reliably show up.

The exceptions to the warning (disregarding oops_in_progress) are
chosen to allow IRQs-disabled calls when we're sure that the rest of
the system isn't going to be sending the calling CPU an IPI (eg,
because the CPU isn't marked online, and we only send IPIs to online
CPUs, or if we're still early in the kernel boot and hence have no
other CPUs running.)  The exception is oops_in_progress, which can
occur at any time - even with the current CPU already holding some
CSD locks (eg, oops while trying to send an IPI.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

  reply	other threads:[~2018-10-30 12:31 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 18:07 [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` [PATCH 1/7] serial: qcom_geni_serial: Finish supporting sysrq Douglas Anderson
2018-11-02 16:47   ` Stephen Boyd
2018-11-02 16:47     ` Stephen Boyd
2018-10-29 18:07 ` [PATCH 2/7] serial: core: Allow processing sysrq at port unlock time Douglas Anderson
2018-10-30  5:31   ` Doug Anderson
2018-10-29 18:07 ` [PATCH 3/7] serial: qcom_geni_serial: Process " Douglas Anderson
2018-10-29 18:07 ` [PATCH 4/7] serial: core: Include console.h from serial_core.h Douglas Anderson
2018-10-29 18:07 ` [PATCH 5/7] serial: 8250: Process sysrq at port unlock time Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07 ` [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus() Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-30  8:25   ` Peter Zijlstra
2018-10-30  8:25     ` Peter Zijlstra
2018-10-30  8:25     ` Peter Zijlstra
2018-10-30  8:25     ` Peter Zijlstra
2018-10-30  8:25     ` Peter Zijlstra
2018-10-30  9:41   ` Daniel Thompson
2018-10-30  9:41     ` Daniel Thompson
2018-10-30  9:41     ` Daniel Thompson
2018-10-30  9:41     ` Daniel Thompson
2018-10-30  9:41     ` Daniel Thompson
2018-10-30 22:21     ` Doug Anderson
2018-10-30 22:21       ` Doug Anderson
2018-10-30 22:21       ` Doug Anderson
2018-10-30 22:21       ` Doug Anderson
2018-10-30 22:21       ` Doug Anderson
2018-10-29 18:07 ` [PATCH 7/7] kgdb: Remove irq flags and local_irq_enable/disable from roundup Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-29 18:07   ` Douglas Anderson
2018-10-30 11:46   ` Daniel Thompson
2018-10-30 11:46     ` Daniel Thompson
2018-10-30 11:46     ` Daniel Thompson
2018-10-30 11:46     ` Daniel Thompson
2018-10-30 11:46     ` Daniel Thompson
2018-10-30 11:46     ` Daniel Thompson
2018-10-30 22:22     ` Doug Anderson
2018-10-30 22:22       ` Doug Anderson
2018-10-30 22:22       ` Doug Anderson
2018-10-30 22:22       ` Doug Anderson
2018-10-30 22:22       ` Doug Anderson
2018-10-30 22:22       ` Doug Anderson
2018-10-30 11:56 ` [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb Daniel Thompson
2018-10-30 11:56   ` Daniel Thompson
2018-10-30 11:56   ` Daniel Thompson
2018-10-30 11:56   ` Daniel Thompson
2018-10-30 12:31   ` Russell King - ARM Linux [this message]
2018-10-30 12:31     ` Russell King - ARM Linux
2018-10-30 12:31     ` Russell King - ARM Linux
2018-10-30 12:31     ` Russell King - ARM Linux
2018-10-30 22:20   ` Doug Anderson
2018-10-30 22:20     ` Doug Anderson
2018-10-30 22:20     ` Doug Anderson
2018-10-30 22:20     ` Doug Anderson
2018-10-30 12:36 ` Andy Shevchenko
2018-10-30 12:36   ` Andy Shevchenko
2018-10-30 12:36   ` Andy Shevchenko
2018-10-30 12:36   ` Andy Shevchenko
2018-10-30 12:36   ` Andy Shevchenko

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=20181030123103.GL30658@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=asierra@xes-inc. \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=jhogan@kernel.org \
    --cc=joel@jms.id.au \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nm@ti.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=pombredanne@nexb.com \
    --cc=rolf.evers.fischer@aptiv.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.com \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /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.