lkml.org 
[lkml]   [2022]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] proc/vmcore: fix possible deadlock on concurrent mmap and read
On 01/25/22 at 05:09pm, Andrew Morton wrote:
> On Wed, 19 Jan 2022 20:34:17 +0100 David Hildenbrand <david@redhat.com> wrote:
>
> > Lockdep noticed that there is chance for a deadlock if we have
> > concurrent mmap, concurrent read, and the addition/removal of a
> > callback.
> >
> > As nicely explained by Boqun:
> >
> > "
> > Lockdep warned about the above sequences because rw_semaphore is a fair
> > read-write lock, and the following can cause a deadlock:
> >
> > TASK 1 TASK 2 TASK 3
> > ====== ====== ======
> > down_write(mmap_lock);
> > down_read(vmcore_cb_rwsem)
> > down_write(vmcore_cb_rwsem); // blocked
> > down_read(vmcore_cb_rwsem); // cannot get the lock because of the fairness
> > down_read(mmap_lock); // blocked
>
> I'm wondering about cc:stable. It's hard to believe that this is
> likely to be observed in real life. But the ongoing reports of lockdep
> splats will be irritating.

This is reported by Redhat CKI on Fedora ARK kernel. That kernel enables
many debug feature by default, that's why lockdep detected that. Usually
kdump kernel add 'nr_cpus=1' by default in our distros, so it won't
hurt. It may cause lock issue in theory, so should be false positive
warning. Since it has Fixes tag, cc:stable should be OK.

\
 
 \ /
  Last update: 2022-01-26 02:22    [W:0.538 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site