lkml.org 
[lkml]   [2016]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 07/15] lockdep: Implement crossrelease feature
    On Mon, Sep 19, 2016 at 11:41:02AM +0900, Byungchul Park wrote:

    > > But since these threads are independently scheduled there is no point in
    > > transferring the point in time thread A does W to thread B. There is no
    > > relation there.
    > >
    > > B could have already executed the complete or it could not yet have
    > > started execution at all or anything in between, entirely random.
    >
    > Of course B could have already executed the complete or it could not yet
    > have started execution at all or anything in between. But it's not entirely
    > random.
    >
    > It might be a random point since they are independently scheduled, but it's
    > not entirely random. And it's a random point among valid points which lockdep
    > needs to consider. For example,
    >
    >
    > CONTEXT 1 CONTEXT 2(forked one)
    > ========= =====================
    > (a) acquire F
    > acquire A acquire G
    > acquire B wait_for_completion Z
    > acquire C
    > (b) acquire H
    > fork 2 acquire I
    > acquire D acquire J
    > complete Z acquire K
    >

    I'm hoping you left out the releases for brevity? Because calling fork()
    with locks held is _really_ poor form.

    > I can provide countless examples with which I can say you're wrong.
    > In this case, all acquires between (a) and (b) must be ignored when
    > generating dependencies with complete operation of Z.

    I still don't get the point. Why does this matter?

    Sure, A-C are irrelevant in this example, but I don't see how they're
    differently irrelevant from a whole bunch of other prior state action.


    Earlier you said the algorithm for selecting the dependency is the first
    acquire observed in the completing thread after the
    wait_for_completion(). Is this correct?


    W z

    A a
    for (i<0;i<many;i++) {
    A x[i]
    R x[i]
    }
    R a

    <IRQ>
    A b
    R b
    C z
    </IRQ>

    That would be 'a' in this case, but that isn't at all related. Its just
    as irrelevant as your A-C. And we can pick @many as big as needed to
    flush the prev held cyclic buffer (although I've no idea how that
    matters either).

    What we want here is to link z to b, no? That is the last, not the first
    acquire, it also is independent of when W happened.

    At the same time, picking the last is no guarantee either, since that
    can equally miss dependencies. Suppose the IRQ handler did:

    <IRQ>
    A c
    R c
    A b
    R b
    C z
    </IRQ>

    instead. We'd miss the z depends on c relation, and since they're
    independent lock sections, lockdep wouldn't make a b-c relation either.


    Clearly I'm still missing stuff...

    \
     
     \ /
      Last update: 2016-09-19 10:52    [W:2.933 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site