Re: [PATCH] mm lock ordering summary

[Andrew Morton]

Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
>
> On Fri, 25 Jun 2004, Andrew Morton wrote:
> > Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
> > >
> > > + * mm->mmap_sem
> > > + *   page->flags PG_locked (lock_page)
> > > + *     mapping->i_mmap_lock
> > > + *       mm->page_table_lock
> > > + *         swap_list_lock (in swap_free etc's swap_info_get)
> > > + *         zone->lru_lock (in mark_page_accessed)
> > > + *         page->flags PG_maplock (page_map_lock)
> > > + *           anon_vma->lock
> > > + *             swap_device_lock (in swap_duplicate, swap_info_get)
> > > + *             mapping->private_lock (in __set_page_dirty_buffers)
> > > + *             inode_lock (in set_page_dirty's __mark_inode_dirty)
> > > + *               sb_lock (within inode_lock in fs/fs-writeback.c)
> > > + *               mapping->tree_lock (widely used, in set_page_dirty,
> > > + *                         in arch-dependent flush_dcache_mmap_lock,
> > > + *                         within inode_lock in __sync_single_inode)
> > 
> ...
> > the appropriate representation is
> > 
> > 	a
> > 	-> b
> > 
> > 	a
> > 	-> c
> 
> Well, I've expressed that as
>         a
>           b
>           c
> 

Yes, but what does

	a
	b
	  c
	  d

mean?

The above graph tells us that one or more of (swap_device_lock,
mapping->private_lock and inode_lock) nests inside one or more of
(swap_list_lock, zone->lru_lock and page->flags PG_maplock).

And has no way of telling us _where_, say, swap_device_lock nests inside
zone->lru_lock.

And it alleges that tree_lock nests inside lru_lock, which isn't so.  Is
it?  These guys used to have no locking relationship.  Hopefully that's
still the case.  But how to represent that?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/