* [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
@ 2020-07-28 13:58 Daniel Vetter
2020-07-30 12:03 ` [Linaro-mm-sig] " Christian König
2020-07-30 12:17 ` Thomas Hellström (Intel)
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Vetter @ 2020-07-28 13:58 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, Daniel Vetter,
Sumit Semwal, Christian König, linux-media, linaro-mm-sig,
Dave Chinner, Qian Cai, linux-xfs, linux-fsdevel,
Thomas Hellström, Andrew Morton, Jason Gunthorpe, linux-mm,
linux-rdma, Maarten Lankhorst
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we already
have primed):
mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
I hope that's not inconsistent with anything mm or fs does, adding
relevant people.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Dave Chinner <david@fromorbit.com>
Cc: Qian Cai <cai@lca.pw>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: Thomas Hellström (Intel) <thomas_os@shipmail.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: linux-mm@kvack.org
Cc: linux-rdma@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
drivers/dma-buf/dma-resv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 0e6675ec1d11..9678162a4ac5 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void)
struct mm_struct *mm = mm_alloc();
struct ww_acquire_ctx ctx;
struct dma_resv obj;
+ struct address_space mapping;
int ret;
if (!mm)
return -ENOMEM;
dma_resv_init(&obj);
+ address_space_init_once(&mapping);
mmap_read_lock(mm);
ww_acquire_init(&ctx, &reservation_ww_class);
@@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void)
if (ret == -EDEADLK)
dma_resv_lock_slow(&obj, &ctx);
fs_reclaim_acquire(GFP_KERNEL);
+ /* for unmap_mapping_range on trylocked buffer objects in shrinkers */
+ i_mmap_lock_write(&mapping);
+ i_mmap_unlock_write(&mapping);
#ifdef CONFIG_MMU_NOTIFIER
lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
__dma_fence_might_wait();
--
2.27.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Linaro-mm-sig] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
2020-07-28 13:58 [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv Daniel Vetter
@ 2020-07-30 12:03 ` Christian König
2020-07-30 12:17 ` Thomas Hellström (Intel)
1 sibling, 0 replies; 6+ messages in thread
From: Christian König @ 2020-07-30 12:03 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-xfs, Maarten Lankhorst, linux-rdma,
Intel Graphics Development, Dave Chinner, Christian König,
linaro-mm-sig, linux-mm, Jason Gunthorpe, Qian Cai,
linux-fsdevel, Daniel Vetter, Andrew Morton, linux-media
Am 28.07.20 um 15:58 schrieb Daniel Vetter:
> GPU drivers need this in their shrinkers, to be able to throw out
> mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> but that loop is resolved by trylocking in shrinkers.
>
> So full hierarchy is now (ignore some of the other branches we already
> have primed):
>
> mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
>
> I hope that's not inconsistent with anything mm or fs does, adding
> relevant people.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: "Christian König" <christian.koenig@amd.com>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: Qian Cai <cai@lca.pw>
> Cc: linux-xfs@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: Thomas Hellström (Intel) <thomas_os@shipmail.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Jason Gunthorpe <jgg@mellanox.com>
> Cc: linux-mm@kvack.org
> Cc: linux-rdma@vger.kernel.org
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/dma-buf/dma-resv.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 0e6675ec1d11..9678162a4ac5 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void)
> struct mm_struct *mm = mm_alloc();
> struct ww_acquire_ctx ctx;
> struct dma_resv obj;
> + struct address_space mapping;
> int ret;
>
> if (!mm)
> return -ENOMEM;
>
> dma_resv_init(&obj);
> + address_space_init_once(&mapping);
>
> mmap_read_lock(mm);
> ww_acquire_init(&ctx, &reservation_ww_class);
> @@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void)
> if (ret == -EDEADLK)
> dma_resv_lock_slow(&obj, &ctx);
> fs_reclaim_acquire(GFP_KERNEL);
> + /* for unmap_mapping_range on trylocked buffer objects in shrinkers */
> + i_mmap_lock_write(&mapping);
> + i_mmap_unlock_write(&mapping);
> #ifdef CONFIG_MMU_NOTIFIER
> lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> __dma_fence_might_wait();
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
2020-07-28 13:58 [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv Daniel Vetter
2020-07-30 12:03 ` [Linaro-mm-sig] " Christian König
@ 2020-07-30 12:17 ` Thomas Hellström (Intel)
2020-07-30 13:17 ` Daniel Vetter
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Hellström (Intel) @ 2020-07-30 12:17 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, Daniel Vetter, Sumit Semwal,
Christian König, linux-media, linaro-mm-sig, Dave Chinner,
Qian Cai, linux-xfs, linux-fsdevel, Andrew Morton,
Jason Gunthorpe, linux-mm, linux-rdma, Maarten Lankhorst
On 7/28/20 3:58 PM, Daniel Vetter wrote:
> GPU drivers need this in their shrinkers, to be able to throw out
> mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> but that loop is resolved by trylocking in shrinkers.
>
> So full hierarchy is now (ignore some of the other branches we already
> have primed):
>
> mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
>
> I hope that's not inconsistent with anything mm or fs does, adding
> relevant people.
>
Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
don't allocate any memory AFAICT.
Since huge page-table-entry splitting may happen under the i_mmap_lock
from unmap_mapping_range() it might be worth figuring out how new page
directory pages are allocated, though.
/Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
2020-07-30 12:17 ` Thomas Hellström (Intel)
@ 2020-07-30 13:17 ` Daniel Vetter
2020-07-30 16:45 ` Thomas Hellström (Intel)
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Vetter @ 2020-07-30 13:17 UTC (permalink / raw)
To: Thomas Hellström (Intel)
Cc: DRI Development, Intel Graphics Development, Daniel Vetter,
Sumit Semwal, Christian König,
open list:DMA BUFFER SHARING FRAMEWORK,
moderated list:DMA BUFFER SHARING FRAMEWORK, Dave Chinner,
Qian Cai, linux-xfs, linux-fsdevel, Andrew Morton,
Jason Gunthorpe, Linux MM, linux-rdma, Maarten Lankhorst
On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
<thomas_os@shipmail.org> wrote:
>
>
> On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > GPU drivers need this in their shrinkers, to be able to throw out
> > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> > but that loop is resolved by trylocking in shrinkers.
> >
> > So full hierarchy is now (ignore some of the other branches we already
> > have primed):
> >
> > mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
> >
> > I hope that's not inconsistent with anything mm or fs does, adding
> > relevant people.
> >
> Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
> don't allocate any memory AFAICT.
>
> Since huge page-table-entry splitting may happen under the i_mmap_lock
> from unmap_mapping_range() it might be worth figuring out how new page
> directory pages are allocated, though.
ofc I'm not an mm expert at all, but I did try to scroll through all
i_mmap_lock_write/read callers. Found the following:
- kernel/events/uprobes.c in build_map_info:
/*
* Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
* reclaim. This is optimistic, no harm done if it fails.
*/
- I got lost in the hugetlb.c code and couldn't convince myself it's
not allocating page directories at various levels with something else
than GFP_KERNEL.
So looks like the recursion is clearly there and known, but the
hugepage code is too complex and flying over my head.
-Daniel
>
> /Thomas
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
2020-07-30 13:17 ` Daniel Vetter
@ 2020-07-30 16:45 ` Thomas Hellström (Intel)
2020-09-17 13:19 ` Daniel Vetter
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Hellström (Intel) @ 2020-07-30 16:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development, Daniel Vetter,
Sumit Semwal, Christian König,
open list:DMA BUFFER SHARING FRAMEWORK,
moderated list:DMA BUFFER SHARING FRAMEWORK, Dave Chinner,
Qian Cai, linux-xfs, linux-fsdevel, Andrew Morton,
Jason Gunthorpe, Linux MM, linux-rdma, Maarten Lankhorst
On 7/30/20 3:17 PM, Daniel Vetter wrote:
> On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
> <thomas_os@shipmail.org> wrote:
>>
>> On 7/28/20 3:58 PM, Daniel Vetter wrote:
>>> GPU drivers need this in their shrinkers, to be able to throw out
>>> mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
>>> but that loop is resolved by trylocking in shrinkers.
>>>
>>> So full hierarchy is now (ignore some of the other branches we already
>>> have primed):
>>>
>>> mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
>>>
>>> I hope that's not inconsistent with anything mm or fs does, adding
>>> relevant people.
>>>
>> Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
>> don't allocate any memory AFAICT.
>>
>> Since huge page-table-entry splitting may happen under the i_mmap_lock
>> from unmap_mapping_range() it might be worth figuring out how new page
>> directory pages are allocated, though.
> ofc I'm not an mm expert at all, but I did try to scroll through all
> i_mmap_lock_write/read callers. Found the following:
>
> - kernel/events/uprobes.c in build_map_info:
>
> /*
> * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
> * reclaim. This is optimistic, no harm done if it fails.
> */
>
> - I got lost in the hugetlb.c code and couldn't convince myself it's
> not allocating page directories at various levels with something else
> than GFP_KERNEL.
>
> So looks like the recursion is clearly there and known, but the
> hugepage code is too complex and flying over my head.
> -Daniel
OK, so I inverted your annotation and ran a memory hog, and got the
below splat. So clearly your proposed reclaim->i_mmap_lock locking order
is an already established one.
So
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com>
8<---------------------------------------------------------------------------------------------
[ 308.324654] WARNING: possible circular locking dependency detected
[ 308.324655] 5.8.0-rc2+ #16 Not tainted
[ 308.324656] ------------------------------------------------------
[ 308.324657] kswapd0/98 is trying to acquire lock:
[ 308.324658] ffff92a16f758428 (&mapping->i_mmap_rwsem){++++}-{3:3},
at: rmap_walk_file+0x1c0/0x2f0
[ 308.324663]
but task is already holding lock:
[ 308.324664] ffffffffb0960240 (fs_reclaim){+.+.}-{0:0}, at:
__fs_reclaim_acquire+0x5/0x30
[ 308.324666]
which lock already depends on the new lock.
[ 308.324667]
the existing dependency chain (in reverse order) is:
[ 308.324667]
-> #1 (fs_reclaim){+.+.}-{0:0}:
[ 308.324670] fs_reclaim_acquire+0x34/0x40
[ 308.324672] dma_resv_lockdep+0x186/0x224
[ 308.324675] do_one_initcall+0x5d/0x2c0
[ 308.324676] kernel_init_freeable+0x222/0x288
[ 308.324678] kernel_init+0xa/0x107
[ 308.324679] ret_from_fork+0x1f/0x30
[ 308.324680]
-> #0 (&mapping->i_mmap_rwsem){++++}-{3:3}:
[ 308.324682] __lock_acquire+0x119f/0x1fc0
[ 308.324683] lock_acquire+0xa4/0x3b0
[ 308.324685] down_read+0x2d/0x110
[ 308.324686] rmap_walk_file+0x1c0/0x2f0
[ 308.324687] page_referenced+0x133/0x150
[ 308.324689] shrink_active_list+0x142/0x610
[ 308.324690] balance_pgdat+0x229/0x620
[ 308.324691] kswapd+0x200/0x470
[ 308.324693] kthread+0x11f/0x140
[ 308.324694] ret_from_fork+0x1f/0x30
[ 308.324694]
other info that might help us debug this:
[ 308.324695] Possible unsafe locking scenario:
[ 308.324695] CPU0 CPU1
[ 308.324696] ---- ----
[ 308.324696] lock(fs_reclaim);
[ 308.324697] lock(&mapping->i_mmap_rwsem);
[ 308.324698] lock(fs_reclaim);
[ 308.324699] lock(&mapping->i_mmap_rwsem);
[ 308.324699]
*** DEADLOCK ***
[ 308.324700] 1 lock held by kswapd0/98:
[ 308.324701] #0: ffffffffb0960240 (fs_reclaim){+.+.}-{0:0}, at:
__fs_reclaim_acquire+0x5/0x30
[ 308.324702]
stack backtrace:
[ 308.324704] CPU: 1 PID: 98 Comm: kswapd0 Not tainted 5.8.0-rc2+ #16
[ 308.324705] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/29/2019
[ 308.324706] Call Trace:
[ 308.324710] dump_stack+0x92/0xc8
[ 308.324711] check_noncircular+0x12d/0x150
[ 308.324713] __lock_acquire+0x119f/0x1fc0
[ 308.324715] lock_acquire+0xa4/0x3b0
[ 308.324716] ? rmap_walk_file+0x1c0/0x2f0
[ 308.324717] ? __lock_acquire+0x394/0x1fc0
[ 308.324719] down_read+0x2d/0x110
[ 308.324720] ? rmap_walk_file+0x1c0/0x2f0
[ 308.324721] rmap_walk_file+0x1c0/0x2f0
[ 308.324722] page_referenced+0x133/0x150
[ 308.324724] ? __page_set_anon_rmap+0x70/0x70
[ 308.324725] ? page_get_anon_vma+0x190/0x190
[ 308.324726] shrink_active_list+0x142/0x610
[ 308.324728] balance_pgdat+0x229/0x620
[ 308.324730] kswapd+0x200/0x470
[ 308.324731] ? lockdep_hardirqs_on_prepare+0xf5/0x170
[ 308.324733] ? finish_wait+0x80/0x80
[ 308.324734] ? balance_pgdat+0x620/0x620
[ 308.324736] kthread+0x11f/0x140
[ 308.324737] ? kthread_create_worker_on_cpu+0x40/0x40
[ 308.324739] ret_from_fork+0x1f/0x30
>> /Thomas
>>
>>
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
2020-07-30 16:45 ` Thomas Hellström (Intel)
@ 2020-09-17 13:19 ` Daniel Vetter
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2020-09-17 13:19 UTC (permalink / raw)
To: Thomas Hellström (Intel)
Cc: Daniel Vetter, DRI Development, Intel Graphics Development,
Daniel Vetter, Sumit Semwal, Christian König,
open list:DMA BUFFER SHARING FRAMEWORK,
moderated list:DMA BUFFER SHARING FRAMEWORK, Dave Chinner,
Qian Cai, linux-xfs, linux-fsdevel, Andrew Morton,
Jason Gunthorpe, Linux MM, linux-rdma, Maarten Lankhorst
On Thu, Jul 30, 2020 at 06:45:14PM +0200, Thomas Hellström (Intel) wrote:
>
> On 7/30/20 3:17 PM, Daniel Vetter wrote:
> > On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
> > <thomas_os@shipmail.org> wrote:
> > >
> > > On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > > > GPU drivers need this in their shrinkers, to be able to throw out
> > > > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> > > > but that loop is resolved by trylocking in shrinkers.
> > > >
> > > > So full hierarchy is now (ignore some of the other branches we already
> > > > have primed):
> > > >
> > > > mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
> > > >
> > > > I hope that's not inconsistent with anything mm or fs does, adding
> > > > relevant people.
> > > >
> > > Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
> > > don't allocate any memory AFAICT.
> > >
> > > Since huge page-table-entry splitting may happen under the i_mmap_lock
> > > from unmap_mapping_range() it might be worth figuring out how new page
> > > directory pages are allocated, though.
> > ofc I'm not an mm expert at all, but I did try to scroll through all
> > i_mmap_lock_write/read callers. Found the following:
> >
> > - kernel/events/uprobes.c in build_map_info:
> >
> > /*
> > * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
> > * reclaim. This is optimistic, no harm done if it fails.
> > */
> >
> > - I got lost in the hugetlb.c code and couldn't convince myself it's
> > not allocating page directories at various levels with something else
> > than GFP_KERNEL.
> >
> > So looks like the recursion is clearly there and known, but the
> > hugepage code is too complex and flying over my head.
> > -Daniel
>
> OK, so I inverted your annotation and ran a memory hog, and got the below
> splat. So clearly your proposed reclaim->i_mmap_lock locking order is an
> already established one.
>
> So
>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com>
No one complaining that this is a terrible idea and two reviews from
people who know stuff, so I went ahead and pushed this to drm-misc-next.
Thanks for taking a look at this.
-Daniel
>
> 8<---------------------------------------------------------------------------------------------
>
> [ 308.324654] WARNING: possible circular locking dependency detected
> [ 308.324655] 5.8.0-rc2+ #16 Not tainted
> [ 308.324656] ------------------------------------------------------
> [ 308.324657] kswapd0/98 is trying to acquire lock:
> [ 308.324658] ffff92a16f758428 (&mapping->i_mmap_rwsem){++++}-{3:3}, at:
> rmap_walk_file+0x1c0/0x2f0
> [ 308.324663]
> but task is already holding lock:
> [ 308.324664] ffffffffb0960240 (fs_reclaim){+.+.}-{0:0}, at:
> __fs_reclaim_acquire+0x5/0x30
> [ 308.324666]
> which lock already depends on the new lock.
>
> [ 308.324667]
> the existing dependency chain (in reverse order) is:
> [ 308.324667]
> -> #1 (fs_reclaim){+.+.}-{0:0}:
> [ 308.324670] fs_reclaim_acquire+0x34/0x40
> [ 308.324672] dma_resv_lockdep+0x186/0x224
> [ 308.324675] do_one_initcall+0x5d/0x2c0
> [ 308.324676] kernel_init_freeable+0x222/0x288
> [ 308.324678] kernel_init+0xa/0x107
> [ 308.324679] ret_from_fork+0x1f/0x30
> [ 308.324680]
> -> #0 (&mapping->i_mmap_rwsem){++++}-{3:3}:
> [ 308.324682] __lock_acquire+0x119f/0x1fc0
> [ 308.324683] lock_acquire+0xa4/0x3b0
> [ 308.324685] down_read+0x2d/0x110
> [ 308.324686] rmap_walk_file+0x1c0/0x2f0
> [ 308.324687] page_referenced+0x133/0x150
> [ 308.324689] shrink_active_list+0x142/0x610
> [ 308.324690] balance_pgdat+0x229/0x620
> [ 308.324691] kswapd+0x200/0x470
> [ 308.324693] kthread+0x11f/0x140
> [ 308.324694] ret_from_fork+0x1f/0x30
> [ 308.324694]
> other info that might help us debug this:
>
> [ 308.324695] Possible unsafe locking scenario:
>
> [ 308.324695] CPU0 CPU1
> [ 308.324696] ---- ----
> [ 308.324696] lock(fs_reclaim);
> [ 308.324697] lock(&mapping->i_mmap_rwsem);
> [ 308.324698] lock(fs_reclaim);
> [ 308.324699] lock(&mapping->i_mmap_rwsem);
> [ 308.324699]
> *** DEADLOCK ***
>
> [ 308.324700] 1 lock held by kswapd0/98:
> [ 308.324701] #0: ffffffffb0960240 (fs_reclaim){+.+.}-{0:0}, at:
> __fs_reclaim_acquire+0x5/0x30
> [ 308.324702]
> stack backtrace:
> [ 308.324704] CPU: 1 PID: 98 Comm: kswapd0 Not tainted 5.8.0-rc2+ #16
> [ 308.324705] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 07/29/2019
> [ 308.324706] Call Trace:
> [ 308.324710] dump_stack+0x92/0xc8
> [ 308.324711] check_noncircular+0x12d/0x150
> [ 308.324713] __lock_acquire+0x119f/0x1fc0
> [ 308.324715] lock_acquire+0xa4/0x3b0
> [ 308.324716] ? rmap_walk_file+0x1c0/0x2f0
> [ 308.324717] ? __lock_acquire+0x394/0x1fc0
> [ 308.324719] down_read+0x2d/0x110
> [ 308.324720] ? rmap_walk_file+0x1c0/0x2f0
> [ 308.324721] rmap_walk_file+0x1c0/0x2f0
> [ 308.324722] page_referenced+0x133/0x150
> [ 308.324724] ? __page_set_anon_rmap+0x70/0x70
> [ 308.324725] ? page_get_anon_vma+0x190/0x190
> [ 308.324726] shrink_active_list+0x142/0x610
> [ 308.324728] balance_pgdat+0x229/0x620
> [ 308.324730] kswapd+0x200/0x470
> [ 308.324731] ? lockdep_hardirqs_on_prepare+0xf5/0x170
> [ 308.324733] ? finish_wait+0x80/0x80
> [ 308.324734] ? balance_pgdat+0x620/0x620
> [ 308.324736] kthread+0x11f/0x140
> [ 308.324737] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 308.324739] ret_from_fork+0x1f/0x30
>
>
>
> > > /Thomas
> > >
> > >
> > >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-17 13:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-28 13:58 [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv Daniel Vetter
2020-07-30 12:03 ` [Linaro-mm-sig] " Christian König
2020-07-30 12:17 ` Thomas Hellström (Intel)
2020-07-30 13:17 ` Daniel Vetter
2020-07-30 16:45 ` Thomas Hellström (Intel)
2020-09-17 13:19 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).