lkml.org 
[lkml]   [2018]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: WARNING: locking bug in lock_downgrade
From
Date
On 12/12/2018 08:14 PM, Yang Shi wrote:
> Cc'ed Peter, Ingo and Waiman.
>
>
> It took me a few days to look into this warning, but I got lost in
> lockdep code.
>
>
> The problem is the commit dd2283f2605e ("mm: mmap: zap pages with read
> mmap_sem in munmap") does an optimization for munmap by downgrading
> write mmap_sem to read before zapping pages. But, lockdep reports
> downgrading a read lock.
>
>
> I'm pretty sure mmap_sem is held as write before downgrade_write() is
> called in the patch. And, there are 4 places which may downgrade a
> mmap_sem:
>
>     - munmap
>
>     - mremap
>
>     - brk
>
>     - clear_refs_write (fs/proc/task_mmu.c)
>
>
> The first three come from my patches, and they just do:
> down_write_killable() -> .. -> downgrade_write().
>
> But the last one is a little bit more complicated, it does down_read()
> ->.. -> up_read() ->.. -> down_write_killable() ->.. ->
> downgrade_write().
>
> And, the last one may be called from any process to touch the other
> processes' mmap_sem.
>
>
> By looking into lockdep code, I'm not sure if lockdep may get confused
> by such sequence or not?
>
>
> Any hint is appreciated.
>
>
> Regards,
>
> Yang

The warning was printed because hlock->read was set when doing the
downgrade_write(). So it is either downgrade_write() was called a second
time or a read lock was held originally. It is hard to tell what is the
root cause without a reproducer.

Cheers,
Longman

\
 
 \ /
  Last update: 2018-12-13 20:47    [W:0.054 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site