Messages in this thread | | | Date | Wed, 22 Feb 2006 13:11:06 +1100 | From | David Gibson <> | Subject | Re: RFC: Block reservation for hugetlbfs |
| |
On Wed, Feb 22, 2006 at 11:38:42AM +1100, Nick Piggin wrote: > David Gibson wrote: > >On Tue, Feb 21, 2006 at 03:18:59PM +1100, Nick Piggin wrote: > > >>This introduces > >>tree_lock(r) -> hugetlb_lock > >> > >>And we already have > >>hugetlb_lock -> lru_lock > >> > >>So we now have tree_lock(r) -> lru_lock, which would deadlock > >>against lru_lock -> tree_lock(w), right? > >> > >>From a quick glance it looks safe, but I'd _really_ rather not > >>introduce something like this. > > > > > >Urg.. good point. I hadn't even thought of that consequence - I was > >more worried about whether I need i_lock or i_mutex to protect my > >updates to i_blocks. > > > >Would hugetlb_lock -> tree_lock(r) be any preferable (I think that's a > >possible alternative). > > > > Yes I think that should avoid the introduction of new lock dependency.
Err... "Yes" appears to contradict the rest of you statement, since my suggestion would still introduce a lock dependency, just a different one one. It is not at all obvious to me how to avoid a lock dependency entirely.
Also, any thoughts on whether I need i_lock or i_mutex or something else would be handy..
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson - 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/
| |