On 22/12/2017 17:18, Mircea CIRJALIU-MELIU wrote: > > >> -----Original Message----- >> From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] >> Sent: Friday, 22 December 2017 18:02 >> To: Adalber Lazăr <alazar@xxxxxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx >> Cc: linux-mm@xxxxxxxxx; Radim Krčmář <rkrcmar@xxxxxxxxxx>; Xiao >> Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx>; Mihai Donțu >> <mdontu@xxxxxxxxxxxxxxx>; Nicusor CITU <ncitu@xxxxxxxxxxxxxxx>; >> Mircea CIRJALIU-MELIU <mcirjaliu@xxxxxxxxxxxxxxx>; Marian Cristian >> ROTARIU <mrotariu@xxxxxxxxxxxxxxx> >> Subject: Re: [RFC PATCH v4 08/18] kvm: add the VM introspection subsystem >> >> On 18/12/2017 20:06, Adalber Lazăr wrote: >>> + /* VMAs will be modified */ >>> + down_write(&req_mm->mmap_sem); >>> + down_write(&map_mm->mmap_sem); >>> + >> >> Is there a locking rule when locking multiple mmap_sems at the same >> time? As it's written, this can cause deadlocks. > > First req_mm, second map_mm. > The other function uses the same nesting. You could have two tasks, both of which register themselves as the introspector of the other. That would cause a deadlock. There may be also other cases in the kernel that lock two VMAs at the same time, and you have to be consistent with those. Usually what you do is comparing pointers and locking the lowest address first. Alternatively, you could have a separate lock that is taken by everyone who needs more than one lock, that is: down_write(&some_mm->mmap_sem); but: mutex_lock(&locking_many_mmaps); down_write(&some_mm->mmap_sem); down_write(&another_mm->mmap_sem); mutex_unlock(&locking_many_mmaps); ... up_write(&some_mm->mmap_sem); up_write(&another_mm->mmap_sem); However, I'm not sure how it works for mmap_sem. We'll have to ask the mm guys, let me Cc a few of them randomly. Paolo
