Re: [PATCH] mm lock ordering summary

[Andrew Morton]

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)

What happened to "i_sem nests inside mmap_sem"?

This representation tends to lose information - it implies that all the
above locks are taken at the same time and it makes it harder to capture
information about where in the kernel the particular ranking occurs.

I mean, if some code does:

	down(a);
	down(b);

and some other code does

	down(a);
	down(c);

the appropriate representation is

	a
	-> b

	a
	-> c


-
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/