On 2012-09-19 11:23, Avi Kivity wrote: > On 09/19/2012 12:19 PM, liu ping fan wrote: >> On Wed, Sep 19, 2012 at 5:14 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> Il 19/09/2012 11:11, liu ping fan ha scritto: >>>>>> Why not? devA will drop its local lock, devX will retake the big lock >>>>>> recursively, devB will take its local lock. In the end, we have biglock >>>>>> -> devB. >>>>>> >>>> But when adopting local lock, we assume take local lock, then biglock. >>> >>> No, because the local lock will be dropped before taking the biglock. >>> The order must always be coarse->fine. >>> >> But if we takes coarse firstly, then the mmio-dispatcher will still >> contend for the big lock against each other. > > Can you detail the sequence? > >> >>> I don't know if the front-end (device) lock should come before or after >>> the back-end (e.g. netdev) lock in the hierarchy, but that's another story. >>> >> I think fine->coarse may be the rule, since for some code path, it is >> not necessary to take coarse lock. > > coarse->fine doesn't mean you have to take the coarse lock. > > Valid: > lock(coarse) > lock(fine)
This is invalid due to prio inversion issues, independent of potential deadlocks. Jan > > Valid: > lock(find) > > Valid: > lock(coarse) > > Invalid: > lock(fine) > lock(coarse) > > -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux