[lkml]   [2000]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectOddness in i_shared_lock and page_table_lock nesting hierarchies ?
The vma list lock  can nest with i_shared_lock, as per Kanoj Sarcar's
note on mem-mgmt locks (Documentation/vm/locking), and currently
vma list lock == mm->page_table_lock.
But there appears to be some inconsistency in the hierarchy of these
2 locks. (By vma list lock I mean vmlist_access/modify_lock(s) )

Looking at mmap code, it appears that the vma list lock
i.e. page_table_lock right now, is to be acquired first
(e.g insert_vm_struct which acquires i_shared_lock internally,
is called under the page_table_lock/vma list lock).
Elsewhere in madvise too, I see a similar hierarchy.
In the unmap code, care has been taken not to have these locks
acquired simultaneously.

However, in the vmtruncate code, it looks like the hierarchy is
There, the i_shared_lock is acquired, in order to traverse the i_mmap
and inside the loop it calls zap_page_range, which aquires the

This is odd. Isn't there a possibility of a deadlock if mmap and
for the same file happen simultaneously (on an SMP) ?

I'm wondering if this could be a side effect of the doubling up of the
page_table_lock as a vma list lock ?

Or have I missed something ?

[I have checked upto 2.4-test10-pre5 ]

I had put this query up on linux-mm, as part of a much larger mail, but
didn't get any response yet, so I thought of putting up a more focussed
query this time.


Suparna Bhattacharya
Systems Software Group, IBM Global Services, India
E-mail :
Phone : 91-80-5267117, Extn : 2525

>List: linux-mm
>Subject: Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
>From: Kanoj Sarcar <>
>Date: 2000-10-13 18:19:06
>[Download message RAW]

>> On Thu, 12 Oct 2000, David S. Miller wrote:
>> >
>> > page_table_lock is supposed to protect normal page table activity
>> > what's done in page fault handler) from swapping out.
>> > However, grabbing this lock in swap-out code is completely missing!
>> >
>> > Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
>> Yeah, it's an easy mistake to make.
>> I've made it myself - grepping for page_table_lock and coming up empty
>> places where I expected it to be.
>> In fact, if somebody sends me patches to remove the
>> stuff completely, and replace them with explicit page_table_lock things,
>> I'll apply it pretty much immediately. I don't like information hiding,
>> and right now that's the only thing that the vmlist_access_lock() stuff
>> doing.

>I came up with the vmlist_access_lock/vmlist_modify_lock names early in
>2.3. The reasoning behind that was that in most places where the "vmlist
>lock" was being taken was to protect the vmlist chain, vma_t fields or
>mm_struct fields. The fact that implementation wise this lock could be
>the same as page_table_lock was a good idea that you suggested.
>Nevertheless, the name was chosen to indicate what type of things it was
>guarding. For example, in the future, you might actually have a different
>(possibly sleeping) lock to guard the vmachain etc, but still have a
>spin lock for the page_table_lock (No, I don't want to be drawn into a
>discussion of why this might be needed right now). Some of this is
>mentioned in Documentation/vm/locking.
>Just thought I would mention, in case you don't recollect some of this
>history. Of course, I understand the "information hiding" part.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.052 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site