Hi Avri,
On 2020-07-27 21:05, Avri Altman wrote:
Dumping testbus registers needs to sleep a bit intermittently as there
are
too many of them. Skip them for those contexts where sleep is not
allowed.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-qcom.c | 15 +--
1 file changed,
> Dumping testbus registers needs to sleep a bit intermittently as there are
> too many of them. Skip them for those contexts where sleep is not allowed.
>
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufs-qcom.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> di
Dumping testbus registers needs to sleep a bit intermittently as there are
too many of them. Skip them for those contexts where sleep is not allowed.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-qcom.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers
Dumping testbus registers needs to sleep a bit intermittently as there are
too many of them. Skip them for those contexts where sleep is not allowed.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-qcom.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers
irq-remapping setup already, where irqs are disabled.
This causes a schedule-while-atomic bug:
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:747
in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
no locks held by swapper/0/1.
irq event stamp: 304
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ridge Kennedy
[ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]
While destroying a network namespace that contains a L2TP tunnel a
"BUG: scheduling while atomic" can be observed.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Ridge Kennedy
[ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]
While destroying a network namespace that contains a L2TP tunnel a
"BUG: scheduling while atomic" can be observed.
E
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ridge Kennedy
[ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]
While destroying a network namespace that contains a L2TP tunnel a
"BUG: scheduling while atomic" can be observed.
E
On Wed, Jul 26, 2017 at 03:25:05PM +0200, Artem Savkov wrote:
> On Wed, Jul 26, 2017 at 02:26:14PM +0200, Joerg Roedel wrote:
> > Yes, that should fix it, but I think its better to just move the
> > register_syscore_ops() call to a later initialization step, like in the
> > patch below. I tested it
On Wed, Jul 26, 2017 at 02:26:14PM +0200, Joerg Roedel wrote:
> Hi Artem, Thomas,
>
> On Wed, Jul 26, 2017 at 12:42:49PM +0200, Thomas Gleixner wrote:
> > On Tue, 25 Jul 2017, Artem Savkov wrote:
> >
> > > Hi,
> > >
> > > Commit 1c3c5ea "sched/core: Enable might_sleep() and smp_processor_id()
>
On Wed, 26 Jul 2017, Joerg Roedel wrote:
> Yes, that should fix it, but I think its better to just move the
> register_syscore_ops() call to a later initialization step, like in the
> patch below. I tested it an will queue it to my iommu/fixes branch.
Fair enough. Acked-by-me.
eue it to my iommu/fixes branch.
>From 461242d7211c901b6ccdf349cc89235bd5da Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Wed, 26 Jul 2017 14:17:55 +0200
Subject: [PATCH] iommu/amd: Fix schedule-while-atomic BUG in initialization
code
The register_syscore_ops() function takes a mutex and m
3.16.44-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ridge Kennedy
commit 12d656af4e3d2781b9b9f52538593e1717e7c979 upstream.
While destroying a network namespace that contains a L2TP tunnel a
"BUG: scheduling while atomic" can be observed.
Enab
Hi,
Looking at the thread discussion, except architecture discussion around the
IRQF_ONESHOT, I think it could go to upstream too.
I'll re-upload patch for upstream.
Thanks for reviewing.
BR,
Lionel
On 03/30/2017 09:54 AM, Lee Jones wrote:
> On Wed, 29 Mar 2017, Sebastian Andrzej Siewior wr
On Wed, 29 Mar 2017, Sebastian Andrzej Siewior wrote:
> On 2017-03-22 09:05:58 [-0700], Steven Rostedt wrote:
> > On Wed, 22 Mar 2017 16:18:43 +0100
> > Lionel Debieve wrote:
> >
> > > Use raw_spin_lock in enable/disable channel as it comes from
> > > interrupt context.
> > >
> > > BUG: sleepin
On 2017-03-22 09:05:58 [-0700], Steven Rostedt wrote:
> On Wed, 22 Mar 2017 16:18:43 +0100
> Lionel Debieve wrote:
>
> > Use raw_spin_lock in enable/disable channel as it comes from
> > interrupt context.
> >
> > BUG: sleeping function called from invalid context at
> > kernel/locking/rtmutex.c:
On Thu, 23 Mar 2017, Julia Cartwright wrote:
> On Thu, Mar 23, 2017 at 10:26:49AM +, Lee Jones wrote:
> > On Thu, 23 Mar 2017, Lionel DEBIEVE wrote:
> >
> > > On 03/22/2017 07:47 PM, Julia Cartwright wrote:
> > > > On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
> > > >> On
On Wed, 22 Mar 2017, Julia Cartwright wrote:
> On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
> > It will not be threaded because there are IRQF_ONESHOT used.
> >
> > ret = devm_request_threaded_irq(&pdev->dev, irq,
> > sti_mbox_irq_handl
On Thu, Mar 23, 2017 at 10:26:49AM +, Lee Jones wrote:
> On Thu, 23 Mar 2017, Lionel DEBIEVE wrote:
>
> > On 03/22/2017 07:47 PM, Julia Cartwright wrote:
> > > On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
> > >> On 03/22/2017 01:01 PM, Steven Rostedt wrote:
> > >>> On Wed
On Thu, 23 Mar 2017, Lionel DEBIEVE wrote:
> On 03/22/2017 07:47 PM, Julia Cartwright wrote:
> > On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
> >> On 03/22/2017 01:01 PM, Steven Rostedt wrote:
> >>> On Wed, 22 Mar 2017 12:37:59 -0500
> >>> Julia Cartwright wrote:
> >>>
> >>>
On 03/22/2017 07:47 PM, Julia Cartwright wrote:
> On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
>> On 03/22/2017 01:01 PM, Steven Rostedt wrote:
>>> On Wed, 22 Mar 2017 12:37:59 -0500
>>> Julia Cartwright wrote:
>>>
Which kernel were you testing on, here? From what I can
On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
>
> On 03/22/2017 01:01 PM, Steven Rostedt wrote:
> > On Wed, 22 Mar 2017 12:37:59 -0500
> > Julia Cartwright wrote:
> >
> > > Which kernel were you testing on, here? From what I can tell, this
> > > should have been fixed with
On 03/22/2017 01:01 PM, Steven Rostedt wrote:
On Wed, 22 Mar 2017 12:37:59 -0500
Julia Cartwright wrote:
Which kernel were you testing on, here? From what I can tell, this
should have been fixed with Thomas's commit:
2a1d3ab8986d ("genirq: Handle force threading of irqs with primary
and
On Wed, 22 Mar 2017 12:37:59 -0500
Julia Cartwright wrote:
> Which kernel were you testing on, here? From what I can tell, this
> should have been fixed with Thomas's commit:
>
>2a1d3ab8986d ("genirq: Handle force threading of irqs with primary
> and thread handler")
Thanks Julia for looki
On Wed, Mar 22, 2017 at 04:18:43PM +0100, Lionel Debieve wrote:
> Use raw_spin_lock in enable/disable channel as it comes from
> interrupt context.
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:995
> in_atomic(): 1, irqs_disabled(): 128, pid: 307, name: pulse
On 03/22/2017 05:05 PM, Steven Rostedt wrote:
> On Wed, 22 Mar 2017 16:18:43 +0100
> Lionel Debieve wrote:
>
>> Use raw_spin_lock in enable/disable channel as it comes from
>> interrupt context.
>>
>> BUG: sleeping function called from invalid context at
>> kernel/locking/rtmutex.c:995
>> in_atomi
On Wed, 22 Mar 2017 16:18:43 +0100
Lionel Debieve wrote:
> Use raw_spin_lock in enable/disable channel as it comes from
> interrupt context.
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:995
> in_atomic(): 1, irqs_disabled(): 128, pid: 307, name: pulseaudio
Use raw_spin_lock in enable/disable channel as it comes from
interrupt context.
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:995
in_atomic(): 1, irqs_disabled(): 128, pid: 307, name: pulseaudio
Preemption disabled at:
[] __handle_domain_irq+0x4c/0xec
CPU: 0 PID: 3
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alexander Aring
commit bdca1fd9a6df745857e23c6056494b7fe062b4e6 upstream.
This patch changes the spinlock to mutex for the available fakelb phy
list. When holding the spinlock the ieee802154_un
On 05/31/2016 09:07 PM, Daniel Bristot de Oliveira wrote:
> This patch series implements two kernel.panic_on_* like sysctl:
>
> kernel.panic_on_rcu_stall:
> panic() on RCU Stall detection.
>
> kernel.panic_on_sched_in_atomic:
> panic() on schedule while atomic
This patch series implements two kernel.panic_on_* like sysctl:
kernel.panic_on_rcu_stall:
panic() on RCU Stall detection.
kernel.panic_on_sched_in_atomic:
panic() on schedule while atomic detection.
These sysctls are useful to capture a vmcore when is not possible
to recompile
On Thu, Dec 10, 2015 at 06:06:59PM +0200, Semen Protsenko wrote:
> From: Sam Protsenko
>
> When using DES module the next bug appears:
>
> BUG: scheduling while atomic: kworker/0:1/63/0x0102
>
> With backtrace as follows:
>
> << cut here
+ Lokesh Vutla
+ linux-o...@vger.kernel.org
On Thu, Dec 10, 2015 at 6:06 PM, Semen Protsenko
wrote:
>
> From: Sam Protsenko
>
> When using DES module the next bug appears:
>
> BUG: scheduling while atomic: kworker/0:1/63/0x0102
>
> With backtrace as follows:
>
>
From: Sam Protsenko
When using DES module the next bug appears:
BUG: scheduling while atomic: kworker/0:1/63/0x0102
With backtrace as follows:
<< cut here >>>
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
[] (show_stack) fro
3.6.11.2 stable review patch.
If anyone has any objections, please let me know.
--
From: Larry Finger
[ Upstream commit 664899786cb49cb52f620e06ac19c0be524a7cfa ]
When run at debug 3 or higher, rtl8192cu reports a BUG as follows:
BUG: scheduling while atomic: kworker/u:0/5281/
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 664899786cb49cb52f620e06ac19c0be524a7cfa upstream.
When run at debug 3 or higher, rtl8192cu reports a BUG as follows:
BUG: scheduling while atomic: kworker/u:0/5281/0x0
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 664899786cb49cb52f620e06ac19c0be524a7cfa upstream.
When run at debug 3 or higher, rtl8192cu reports a BUG as follows:
BUG: scheduling while atomic: kworker/u:0/5281/0x0
3.5.7.9 -stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 664899786cb49cb52f620e06ac19c0be524a7cfa upstream.
When run at debug 3 or higher, rtl8192cu reports a BUG as follows:
BUG: scheduling while atomic: kworker/u:0/5281/0x
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 664899786cb49cb52f620e06ac19c0be524a7cfa upstream.
When run at debug 3 or higher, rtl8192cu reports a BUG as follows:
BUG: scheduling while atomic: kworker/u:0/5281/0x0
More importantly _exactly_what_ are you using the LOCK to protect?
Short recap, spinlocks are used to serialise, ie prevent races in SMP
systems, where turning the interrupts off, on a single processor, is
NOT good enough to prevent races between interrupt-handlers and core
kernel code accessing s
40 matches
Mail list logo
