On 2012-09-19 11:27, Jan Kiszka wrote: > 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.
Err, forget it - the other way around is the problem. Sorry, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
