Re: Updated Linux 2.4 Status/TODO List (from the ALS show)

From: Kanoj Sarcar (
Date: Fri Oct 13 2000 - 13:19:06 EST

> On Thu, 12 Oct 2000, David S. Miller wrote:
> >
> > page_table_lock is supposed to protect normal page table activity (like
> > 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 in
> places where I expected it to be.
> In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
> 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 is
> 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

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST