lkml.org 
[lkml]   [2004]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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