Messages in this thread | | | Date | Fri, 25 Jun 2004 17:41:50 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] mm lock ordering summary |
| |
Hugh Dickins <hugh@veritas.com> wrote: > > On Fri, 25 Jun 2004, Andrew Morton wrote: > > Hugh Dickins <hugh@veritas.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |