I've been seeing these warnings for a couple of weeks now. Any
pointers on how to address this would be much appreciated.
[ 57.207457] ==
[ 57.207470] WARNING: possible circular locking dependency detected
[ 57.207483] 5.11.0-rc7
Hello,
Eric, sorry for the delay.
On (20/12/11 10:03), Eric Biggers wrote:
> > [..]
> >
> > [ 1598.658233] __rwsem_down_read_failed_common+0x186/0x201
> > [ 1598.658235] call_rwsem_down_read_failed+0x14/0x30
> > [ 1598.658238] down_read+0x2e/0x45
> > [ 1598.658240] rmap_walk_file+0x73/0x1ce
On Fri, Dec 11, 2020 at 01:08:07PM +0900, Sergey Senozhatsky wrote:
> On (20/12/10 19:48), Eric Biggers wrote:
> > >
> > > [ 133.454836] Chain exists of:
> > > jbd2_handle --> fscrypt_init_mutex --> fs_reclaim
> > >
> > > [ 133.454840] Possible unsafe locking scenario:
> > >
On (20/12/11 13:08), Sergey Senozhatsky wrote:
> >
> > How interested are you in having this fixed? Did you encounter an actual
> > deadlock or just the lockdep report?
>
Got one more. fscrypt_get_encryption_info() again, but from ext4_lookup().
[ 162.840909] kswapd0/80 is trying to acquire lo
On (20/12/10 19:48), Eric Biggers wrote:
> >
> > [ 133.454836] Chain exists of:
> > jbd2_handle --> fscrypt_init_mutex --> fs_reclaim
> >
> > [ 133.454840] Possible unsafe locking scenario:
> >
> > [ 133.454841]CPU0CPU1
> > [ 133.454843]-
On Fri, Dec 11, 2020 at 12:36:57PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> I got the following lockdep splat the other day, while running some
> tests on 4.19. I didn't test other stable kernels, but it seems that
> 5.4 should also have similar problem.
>
> As far as I can tell, ext4_dir_open(
Hi,
I got the following lockdep splat the other day, while running some
tests on 4.19. I didn't test other stable kernels, but it seems that
5.4 should also have similar problem.
As far as I can tell, ext4_dir_open() has been removed quite recently:
https://www.mail-archive.com/linux-f2fs-devel@l
==
>>> [ 1917.361406] WARNING: possible circular locking dependency detected
>>> [ 1917.361413] 5.9.0.g7cf726a-master #2 Tainted: G S E
>>> [ 1917.361417] --
>>> [ 1917.361422] kwork
On 10/20/20 1:15 AM, Paolo Valente wrote:
>> Il giorno 20 ott 2020, alle ore 08:15, Mike Galbraith ha
>> scritto:
>>
>> [ 1917.361401] ==
>> [ 1917.361406] WARNING: possible circular locking dependency detected
&g
gt; [ 1917.361401] ==
> [ 1917.361406] WARNING: possible circular locking dependency detected
> [ 1917.361413] 5.9.0.g7cf726a-master #2 Tainted: G S E
> [ 1917.361417] --
> [ 1917.36
[ 1917.361401] ==
[ 1917.361406] WARNING: possible circular locking dependency detected
[ 1917.361413] 5.9.0.g7cf726a-master #2 Tainted: G S E
[ 1917.361417] --
[ 1917.361422] kworker
On Tue, Aug 11, 2020 at 12:17:13PM +0100, Will Deacon wrote:
> On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> > diff --git a/drivers/tty/serial/amba-pl011.c
> > b/drivers/tty/serial/amba-pl011.c
> > index 8efd7c2a34fe..1717790ece2b 100644
> > --- a/drivers/tty/serial/amba-
On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote:
> > Using magic-sysrq via a keyboard interrupt over the serial console results
> > in
> > the following lockdep splat with the PL011 UART driver on v5.8. I can
> >
On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote:
> Hi,
>
> Using magic-sysrq via a keyboard interrupt over the serial console results in
> the following lockdep splat with the PL011 UART driver on v5.8. I can
> reproduce
> the issue under QEMU with arm64 defconfig + PROVE_LOCKING.
>
6.387378] ==
[ 56.387391] WARNING: possible circular locking dependency detected
[ 56.387401] 5.8.0 #2 Not tainted
[ 56.387411] --
[ 56.387421] swapper/0/0 is trying to acquire lock:
[ 56.387467] b190db294ab0 (conso
abled. A couple of questions below:
Sorry I forgot to update but I did try on Friday and I could not manage
to trigger it on D06/Kunpeng920 either. I used 5.8.0-rc4.
> Thanks,
> Zenghui
>
> [ 103.855511] ==
> [ 103.861664] WA
rgot to update but I did try on Friday and I could not manage
> to trigger it on D06/Kunpeng920 either. I used 5.8.0-rc4.
>
>
> > > Thanks,
> > > Zenghui
> > >
> > > [ 103.855511] ==
running guests
> with GICv4 enabled. A couple of questions below:
Sorry I forgot to update but I did try on Friday and I could not manage
to trigger it on D06/Kunpeng920 either. I used 5.8.0-rc4.
> > Thanks,
> > Zenghui
> >
> > [ 103.855511] =======
em is and hope someone can have a look!
I can't manage to trigger this splat on my D05, despite running guests
with GICv4 enabled. A couple of questions below:
Thanks,
Zenghui
[ 103.855511] ==
[ 103.861664] WARNING: possible circul
> From: yuzenghui
> Sent: Thursday, July 9, 2020 12:50 PM
> To: Salil Mehta
> Cc: Marc Zyngier ; Thomas Gleixner ;
> Linux
> Kernel Mailing List ;
> linux-arm-ker...@lists.infradead.org; Zhuangyuzeng (Yisen)
> ; Wanghaibin (D)
> Subject: Re: [REPORT] possible circu
On 2020/7/9 18:54, Salil Mehta wrote:
Hi Yuzenghui,
I will try to reproduce it today at our platform. Just one question is it easily
reproducible or is a rare occurrence?
Salil, it's 100% reproducible once you start a guest. You don't even
need to assign hostdev to the VM.
Thanks,
Zenghui
> linux-arm-ker...@lists.infradead.org
> Cc: Zhuangyuzeng (Yisen) ; Salil Mehta
> ; Wanghaibin (D)
> Subject: [REPORT] possible circular locking dependency when booting a VM on
> arm64
> host
>
> Hi All,
>
> I had seen the following lockdep splat when booting a guest
nghui
[ 103.855511] ==
[ 103.861664] WARNING: possible circular locking dependency detected
[ 103.867817] 5.8.0-rc4+ #35 Tainted: GW
[ 103.872932] --
[ 103.879083] CPU 2/KVM/20515 is t
=
[ 51.013875] WARNING: possible circular locking dependency detected
[ 51.014378] 5.2.0-rc2 #1 Not tainted
[ 51.014672] --
[ 51.015182] trinity-c2/886 is trying to acquire lock:
[ 51.015593] 000
r_store() does not completely eliminate circular locking dependency
> >> as shown by the following lockdep splat when the system is shut down:
> >>
> >> [ 2095.079697] Chain exists of:
> >> [ 2095.079697] kn->count#278 --> memcg_cache_ids_sem --> slab_mutex
On 5/16/20 10:19 PM, Qian Cai wrote:
On Apr 27, 2020, at 7:56 PM, Waiman Long wrote:
It turns out that switching from slab_mutex to memcg_cache_ids_sem in
slab_attr_store() does not completely eliminate circular locking dependency
as shown by the following lockdep splat when the system is
> On Apr 27, 2020, at 7:56 PM, Waiman Long wrote:
>
> It turns out that switching from slab_mutex to memcg_cache_ids_sem in
> slab_attr_store() does not completely eliminate circular locking dependency
> as shown by the following lockdep splat when the system is shut down:
>
> On Apr 27, 2020, at 7:56 PM, Waiman Long wrote:
>
> A lockdep splat is observed by echoing "1" to the shrink sysfs file
> and then shutting down the system:
>
> [ 167.473392] Chain exists of:
> [ 167.473392] kn->count#279 --> mem_hotplug_lock.rw_sem --> slab_mutex
> [ 167.473392]
> [
> On Apr 27, 2020, at 7:56 PM, Waiman Long wrote:
>
> v2:
> - Use regular cmpxchg() instead of x86-only try_cmpxchg() in patch 2.
> - Add patches 3 and 4 to fix circular locking dependency showing up
> at shutdown time.
>
> With lockdep enabled, issuing the follo
> On Apr 28, 2020, at 10:07 AM, Waiman Long wrote:
>
> Trylock is handled differently from lockdep's perspective as trylock can
> failed. When trylock succeeds, the critical section is executed. As long as
> it doesn't try to acquire another lock in the circular chain, the execution
> will
> On Apr 28, 2020, at 10:06 AM, Waiman Long wrote:
>
> On 4/27/20 10:11 PM, Qian Cai wrote:
>>
>>> On Apr 27, 2020, at 9:39 PM, Waiman Long wrote:
>>>
>>> The sequence that was prevented by this patch is "kn->count -->
>>> mem_hotplug_lock.rwsem". This sequence isn't directly in the splat.
On 4/27/20 10:11 PM, Qian Cai wrote:
On Apr 27, 2020, at 9:39 PM, Waiman Long wrote:
The sequence that was prevented by this patch is "kn->count -->
mem_hotplug_lock.rwsem". This sequence isn't directly in the splat. Once this link is
broken, the 3-lock circular loop cannot be formed. Maybe
On 19/09/2019 15.27, Martin Hundebøll wrote:
But we haven't been able to reproduce locally.
Scratch that. It's reliably reproduced by sending/saturating the uart
with outgoing data.
// Martin
201.633281] ==
[ 201.639473] WARNING: possible circular locking dependency detected
[ 201.645667] 4.19.22 #1 Not tainted
[ 201.649078] --
[ 201.655270] kworker/u2:0/7 is trying to acquire lock:
[ 201.660337
[ Upstream commit 1cec3f27168d7835ff3d23ab371cd548440131bb ]
This fixes a longstanding lockdep warning triggered by
fstests/btrfs/011.
Circular locking dependency check reports warning[1], that's because the
btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock
held. The
From: Anand Jain
[ Upstream commit 1cec3f27168d7835ff3d23ab371cd548440131bb ]
This fixes a longstanding lockdep warning triggered by
fstests/btrfs/011.
Circular locking dependency check reports warning[1], that's because the
btrfs_scrub_dev() calls the stack #0 below with, the fs
3.16.72-rc1 review patch. If anyone has any objections, please let me know.
--
From: Fabrice Gasnier
commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer
From: Fabrice Gasnier
commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the II
From: Fabrice Gasnier
commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the II
From: Fabrice Gasnier
commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the II
On Mon, 25 Mar 2019 14:01:23 +0100
Fabrice Gasnier wrote:
> This fixes a possible circular locking dependency detected warning seen
> with:
> - CONFIG_PROVE_LOCKING=y
> - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
>
> When
On Mon, 25 Mar 2019 13:51:17 +0100
Fabrice Gasnier wrote:
> On 3/24/19 4:47 PM, Jonathan Cameron wrote:
> > On Fri, 22 Mar 2019 14:54:06 +0100
> > Fabrice Gasnier wrote:
> >
> >> This fixes a possible circular locking dependency detected warning seen
> >&
image memory: 944K
> [ 15.393319] Run /init as init process
> [ 15.477473] random: init: uninitialized urandom read (12 bytes read)
> [ 15.558322]
> [ 15.559003] ==
> [ 15.561203] WARNING: possible circular locking depende
Cc-ing Sahara
On (03/29/19 16:35), Sergey Senozhatsky wrote:
> 5.1.0-rc2-next-20190329
>
> [8.168722] ==
> [8.168723] WARNING: possible circular locking dependency detected
> [8.168724] 5.1.0-rc2-next-201
5.1.0-rc2-next-20190329
[8.168722] ==
[8.168723] WARNING: possible circular locking dependency detected
[8.168724] 5.1.0-rc2-next-20190329-dbg-00014-g4d25d68aaf88-dirty #3228 Not
tainted
[8.168725
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the IIO consumer interface, e.g. iio_channel_get(), the consumer
device will likely call
On 3/24/19 4:47 PM, Jonathan Cameron wrote:
> On Fri, 22 Mar 2019 14:54:06 +0100
> Fabrice Gasnier wrote:
>
>> This fixes a possible circular locking dependency detected warning seen
>> with:
>> - CONFIG_PROVE_LOCKING=y
>> - consumer/provider IIO devices (ex: &
On Fri, 22 Mar 2019 14:54:06 +0100
Fabrice Gasnier wrote:
> This fixes a possible circular locking dependency detected warning seen
> with:
> - CONFIG_PROVE_LOCKING=y
> - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
>
> When
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the IIO consumer interface, e.g. iio_channel_get(),
the consumer device will likely call
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Anand Jain
commit 1cec3f27168d7835ff3d23ab371cd548440131bb upstream.
This fixes a longstanding lockdep warning triggered by
fstests/btrfs/011.
Circular locking dependency check reports
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xiubo Li
commit b34e9a15b37b8ddbf06a4da142b0c39c74211eb4 upstream.
The call trace:
XXX/1910 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] might_fault+0x57/0xb0
but task is alrea
From: Xiubo Li
commit b34e9a15b37b8ddbf06a4da142b0c39c74211eb4 upstream.
The call trace:
XXX/1910 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] might_fault+0x57/0xb0
but task is already holding lock:
(&idev->info_lock){+.+...}, at: [] uio_write+0x46/0x130 [uio]
which lock alread
. Similarly to a
situation in loop_set_fd() this can create a circular locking dependency
if this was the last reference holding the file open. Delay dropping of
the file reference until we have released loop_ctl_mutex.
Reported-by: Tetsuo Handa
Signed-off-by: Jan Kara
Signed-off-by: Jens Axboe
. Similarly to a
situation in loop_set_fd() this can create a circular locking dependency
if this was the last reference holding the file open. Delay dropping of
the file reference until we have released loop_ctl_mutex.
Reported-by: Tetsuo Handa
Signed-off-by: Jan Kara
Signed-off-by: Jens Axboe
Compiling kernel on an aarch64 server with the latest mainline (rc2) generated
this,
[ 910.263839] WARNING: possible circular locking dependency detected
[ 910.263841] 4.20.0-rc2+ #4 Tainted: GWL
[ 910.263843] --
[ 910.263844
On Wed, 7 Nov 2018, Andrew Morton wrote:
> On Wed, 7 Nov 2018 15:43:36 -0800 Andrew Morton
> wrote:
>
> > On Tue, 23 Oct 2018 08:30:04 +0800 kernel test robot
> > wrote:
> >
> > > Greetings,
> > >
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > >
> >
On Wed, 7 Nov 2018 15:43:36 -0800 Andrew Morton
wrote:
> On Tue, 23 Oct 2018 08:30:04 +0800 kernel test robot
> wrote:
>
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi
--+---+---+
>
> [ 29.227068] random: get_random_bytes called from key_alloc+0x2b0/0x44d
> with crng_init=1
> [ 32.046253] random: get_random_bytes called from
> __ip_select_ident+0x45/0x93 with crng_init=1
> [ 33.592007] random: get_random_bytes called from key_alloc+0x2b0/0x44d
> with crng_init=1
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Xiubo Li
[ Upstream commit b34e9a15b37b8ddbf06a4da142b0c39c74211eb4 ]
The call trace:
XXX/1910 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] might_fault+0x57/0xb0
but task is al
] [ 57.651003] synth uevent: /module/pcmcia_core: unknown uevent action
string [ 71.189062] [ 71.191953]
== [ 71.192813] WARNING:
possible circular locking dependency detected [ 71.193664]
4.12.0-10480-g3f906ba #1 Not tainted [ 71.194355
> HI:3700] [ 57.651003] synth uevent: /module/pcmcia_core: unknown uevent
> action string [ 71.189062] [ 71.191953]
> == [ 71.192813] WARNING:
> possible circular locking dependency detected [ 71.193664]
&g
From: Xiubo Li
[ Upstream commit b34e9a15b37b8ddbf06a4da142b0c39c74211eb4 ]
The call trace:
XXX/1910 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] might_fault+0x57/0xb0
but task is already holding lock:
(&idev->info_lock){+.+...}, at: [] uio_write+0x46/0x130 [uio]
which lock alr
From: Xiubo Li
The call trace:
XXX/1910 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] might_fault+0x57/0xb0
but task is already holding lock:
(&idev->info_lock){+.+...}, at: [] uio_write+0x46/0x130 [uio]
which lock already depends on the new lock.
the existing dependency chain (
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Leon Romanovsky
commit 1ff5325c3ca1843228a86549318bbd3b414b9207 upstream.
Avoid circular locking dependency by calling
to uobj_alloc_commit() outside of xrcd_tree_mutex lock
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Leon Romanovsky
commit 1ff5325c3ca1843228a86549318bbd3b414b9207 upstream.
Avoid circular locking dependency by calling
to uobj_alloc_commit() outside of xrcd_tree_mutex lock
Hello, Prateek.
On Mon, Jan 15, 2018 at 05:32:18PM +0530, Prateek Sood wrote:
> My understanding of WQ_MEM_RECLAIM was that it needs to be used for
> cases where memory pressure could cause deadlocks.
Yes, that is the primary role; however, there are a couple places
where we need it to isolate a
On 01/02/2018 09:46 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
>> task T is waiting for cpuset_mutex acquired
>> by kworker/2:1
>>
>> sh ==> cpuhp/2 ==> kworker/2:1 ==> sh
>>
>> kworker/2:3 ==> kthreadd ==> Task T ==> kworker/2:1
>>
>> It seems
On Wed, Jan 10, 2018 at 01:41:01PM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> On Wed, Jan 10, 2018 at 12:08:21PM -0800, Paul E. McKenney wrote:
> > And one additional question... How are we pushing this upstream? By
> > default, I would push things starting this late into the merge window
> > fo
Hello, Paul.
On Wed, Jan 10, 2018 at 12:08:21PM -0800, Paul E. McKenney wrote:
> And one additional question... How are we pushing this upstream? By
> default, I would push things starting this late into the merge window
> following the next one (v4.17), but would be more than willing to make
>
On Tue, Jan 09, 2018 at 08:00:22AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 09, 2018 at 07:37:52AM -0800, Tejun Heo wrote:
> > Hello, Paul.
> >
> > On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote:
> > > > The code was previously using both system_power_efficient_wq and
> > > >
On Tue, Jan 09, 2018 at 07:37:52AM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote:
> > > The code was previously using both system_power_efficient_wq and
> > > system_workqueue (for the expedited path). I guess the options were
> > > ei
Hello, Paul.
On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote:
> > The code was previously using both system_power_efficient_wq and
> > system_workqueue (for the expedited path). I guess the options were
> > either using two workqueues or dropping POWER_EFFICIENT. I have no
> > i
On Tue, Jan 09, 2018 at 05:44:48AM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> On Mon, Jan 08, 2018 at 08:20:16PM -0800, Paul E. McKenney wrote:
> > OK, so I can put WQ_MEM_RECLAIM on the early boot creation of RCU's
> > workqueue_struct as shown below, right?
>
> Yes, this looks good to me. Just
Hello, Paul.
On Mon, Jan 08, 2018 at 08:20:16PM -0800, Paul E. McKenney wrote:
> OK, so I can put WQ_MEM_RECLAIM on the early boot creation of RCU's
> workqueue_struct as shown below, right?
Yes, this looks good to me. Just one question.
> +struct workqueue_struct *rcu_gp_workqueue;
> +
> void
On Mon, Jan 08, 2018 at 07:42:11PM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> On Mon, Jan 08, 2018 at 04:31:27PM -0800, Paul E. McKenney wrote:
> > +static int __init rcu_init_wq_rescuer(void)
> > +{
> > + WARN_ON(init_rescuer(rcu_gp_workqueue));
> > + return 0;
> > +}
> > +core_initcall(rcu_i
Hello, Paul.
On Mon, Jan 08, 2018 at 04:31:27PM -0800, Paul E. McKenney wrote:
> +static int __init rcu_init_wq_rescuer(void)
> +{
> + WARN_ON(init_rescuer(rcu_gp_workqueue));
> + return 0;
> +}
> +core_initcall(rcu_init_wq_rescuer);
So, what I don't get is why RCU needs to call this expl
On Mon, Jan 08, 2018 at 02:52:38PM -0800, Paul E. McKenney wrote:
> On Mon, Jan 08, 2018 at 04:28:23AM -0800, Tejun Heo wrote:
> > Hello, Paul.
> >
> > Sorry about the delay. Travel followed by cold. :(
> >
> > On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote:
> > > Actually, aft
On Mon, Jan 08, 2018 at 04:28:23AM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> Sorry about the delay. Travel followed by cold. :(
>
> On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote:
> > Actually, after taking a quick look, could you please supply me with
> > a way of mark a stat
Hello, Paul.
Sorry about the delay. Travel followed by cold. :(
On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote:
> Actually, after taking a quick look, could you please supply me with
> a way of mark a statically allocated workqueue as WQ_MEM_RECLAIM after
> the fact? Otherwise
On Tue, Jan 02, 2018 at 09:44:08AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 02, 2018 at 08:16:56AM -0800, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
> > > task T is waiting for cpuset_mutex acquired
> > > by kworker/2:1
> > >
> > > sh ==>
On Tue, Jan 02, 2018 at 08:16:56AM -0800, Tejun Heo wrote:
> Hello,
>
> On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
> > task T is waiting for cpuset_mutex acquired
> > by kworker/2:1
> >
> > sh ==> cpuhp/2 ==> kworker/2:1 ==> sh
> >
> > kworker/2:3 ==> kthreadd ==> Task T ==>
Hello,
On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
> task T is waiting for cpuset_mutex acquired
> by kworker/2:1
>
> sh ==> cpuhp/2 ==> kworker/2:1 ==> sh
>
> kworker/2:3 ==> kthreadd ==> Task T ==> kworker/2:1
>
> It seems that my earlier patch set should fix this scenario:
On 12/13/2017 09:36 PM, Tejun Heo wrote:
> Hello, Prateek.
>
> On Wed, Dec 13, 2017 at 01:20:46PM +0530, Prateek Sood wrote:
>> This change makes the usage of cpuset_hotplug_workfn() from cpu
>> hotplug path synchronous. For memory hotplug it still remains
>> asynchronous.
>
> Ah, right.
>
>> Me
On 2017-12-18 20:06:12 [-0500], Steven Rostedt wrote:
> On Mon, 18 Dec 2017 18:55:24 -0600
> Grygorii Strashko wrote:
>
> > Hi All,
> >
> > I've tried to run stress-ng on TI am57xx-evm (SMP, 2 cpu) and caught 2
> > "INFO: possible circular locking d
On Mon, 18 Dec 2017 18:55:24 -0600
Grygorii Strashko wrote:
> Hi All,
>
> I've tried to run stress-ng on TI am57xx-evm (SMP, 2 cpu) and caught 2
> "INFO: possible circular locking dependency detected"
>
> Command 1 (log 1):
> ## stress-ng --class cpu
Hi All,
I've tried to run stress-ng on TI am57xx-evm (SMP, 2 cpu) and caught 2 "INFO:
possible circular locking dependency detected"
Command 1 (log 1):
## stress-ng --class cpu --all 0 -t 5m & stress-ng --class memory --all 0
--vm-bytes 90% -t 5m
Command 2 (log 2):
## s
gt; | Kernel_panic-not_syncing:Fatal_exception | 0 | 15
>> |
>> +---+---++
>>
>> [3.252870] CPU feature 'AVX registers' is not supported.
>> [3.261404]
>|
> +---+---++
>
> [3.252870] CPU feature 'AVX registers' is not supported.
> [3.261404] AVX2 or AES-NI instructions are not detected.
> [3.262708] A
On 12/15/2017 06:52 PM, Tejun Heo wrote:
> Hello, Prateek.
>
> On Fri, Dec 15, 2017 at 02:24:55PM +0530, Prateek Sood wrote:
>> Following are two ways to improve cgroup_transfer_tasks(). In
>> both cases task in PF_EXITING state would be left in source
>> cgroup. It would be removed from cgroup_ex
On 12/13/2017 09:36 PM, Tejun Heo wrote:
> Hello, Prateek.
>
> On Wed, Dec 13, 2017 at 01:20:46PM +0530, Prateek Sood wrote:
>> This change makes the usage of cpuset_hotplug_workfn() from cpu
>> hotplug path synchronous. For memory hotplug it still remains
>> asynchronous.
>
> Ah, right.
>
>> Me
Hello, Prateek.
On Fri, Dec 15, 2017 at 02:24:55PM +0530, Prateek Sood wrote:
> Following are two ways to improve cgroup_transfer_tasks(). In
> both cases task in PF_EXITING state would be left in source
> cgroup. It would be removed from cgroup_exit() in exit path.
>
> diff --git a/kernel/cgroup
On 12/13/2017 09:10 PM, Tejun Heo wrote:
Hi TJ,
> Hello, Prateek.
>
> On Wed, Dec 13, 2017 at 07:58:24PM +0530, Prateek Sood wrote:
>> Did you mean something like below. If not then could you
>> please share a patch for this problem in
>> cgroup_transfer_tasks().
>
> Oh we surely can add a new i
Hello, Prateek.
On Wed, Dec 13, 2017 at 01:20:46PM +0530, Prateek Sood wrote:
> This change makes the usage of cpuset_hotplug_workfn() from cpu
> hotplug path synchronous. For memory hotplug it still remains
> asynchronous.
Ah, right.
> Memory migration happening from cpuset_hotplug_workfn() is
Hello, Prateek.
On Wed, Dec 13, 2017 at 07:58:24PM +0530, Prateek Sood wrote:
> Did you mean something like below. If not then could you
> please share a patch for this problem in
> cgroup_transfer_tasks().
Oh we surely can add a new iterator but we can just count in
cgroup_transfer_tasks() too,
On 12/11/2017 09:02 PM, Tejun Heo wrote:
> Hello, Prateek.
>
> On Fri, Dec 08, 2017 at 05:15:55PM +0530, Prateek Sood wrote:
>> There is one deadlock issue during cgroup migration from cpu
>> hotplug path when a task T is being moved from source to
>> destination cgroup.
>>
>> kworker/0:0
>> cpuse
On 12/11/2017 08:50 PM, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Dec 05, 2017 at 12:01:17AM +0100, Peter Zijlstra wrote:
>>> AFAICS, this should remove the circular dependency you originally
>>> reported. I'll revert the two cpuset commits for now.
>>
>> So I liked his patches in that we woul
Hello, Prateek.
On Fri, Dec 08, 2017 at 05:15:55PM +0530, Prateek Sood wrote:
> There is one deadlock issue during cgroup migration from cpu
> hotplug path when a task T is being moved from source to
> destination cgroup.
>
> kworker/0:0
> cpuset_hotplug_workfn()
>cpuset_hotplug_update_tasks(
Hello, Peter.
On Tue, Dec 05, 2017 at 12:01:17AM +0100, Peter Zijlstra wrote:
> > AFAICS, this should remove the circular dependency you originally
> > reported. I'll revert the two cpuset commits for now.
>
> So I liked his patches in that we would be able to go back to
> synchronous sched_doma
t/?h=for-4.15-fixes&id=e8b3f8db7aad99fcc5234fc5b89984ff6620de3d
>>>
>>> AFAICS, this should remove the circular dependency you originally
>>> reported. I'll revert the two cpuset commits for now.
>>
>> So I liked his patches in that we would be able to go
rcular dependency you originally
>> reported. I'll revert the two cpuset commits for now.
>
> So I liked his patches in that we would be able to go back to
> synchronous sched_domain building.
>
https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git/commit/?h=for-4
1 - 100 of 484 matches
Mail list logo
