linux-kernel - Re: [Linaro-mm-sig] [PATCH 6/7] reservation: cross-device reservation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <510F8602.9080806@canonical.com>
Date:	Mon, 04 Feb 2013 10:57:22 +0100
From:	Maarten Lankhorst <maarten.lankhorst@...onical.com>
To:	Inki Dae <inki.dae@...sung.com>
CC:	Maarten Lankhorst <m.b.lankhorst@...il.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [Linaro-mm-sig] [PATCH 6/7] reservation: cross-device reservation
 support

Op 04-02-13 08:06, Inki Dae schreef:
>> +/**
>> + * ticket_commit - commit a reservation with a new fence
>> + * @ticket:    [in]    the reservation_ticket returned by
>> + * ticket_reserve
>> + * @entries:   [in]    a linked list of struct reservation_entry
>> + * @fence:     [in]    the fence that indicates completion
>> + *
>> + * This function will call reservation_ticket_fini, no need
>> + * to do it manually.
>> + *
>> + * This function should be called after a hardware command submission is
>> + * completed succesfully. The fence is used to indicate completion of
>> + * those commands.
>> + */
>> +void
>> +ticket_commit(struct reservation_ticket *ticket,
>> +                 struct list_head *entries, struct fence *fence)
>> +{
>> +       struct list_head *cur;
>> +
>> +       if (list_empty(entries))
>> +               return;
>> +
>> +       if (WARN_ON(!fence)) {
>> +               ticket_backoff(ticket, entries);
>> +               return;
>> +       }
>> +
>> +       list_for_each(cur, entries) {
>> +               struct reservation_object *bo;
>> +               bool shared;
>> +
>> +               reservation_entry_get(cur, &bo, &shared);
>> +
>> +               if (!shared) {
>> +                       int i;
>> +                       for (i = 0; i < bo->fence_shared_count; ++i) {
>> +                               fence_put(bo->fence_shared[i]);
>> +                               bo->fence_shared[i] = NULL;
>> +                       }
>> +                       bo->fence_shared_count = 0;
>> +                       if (bo->fence_excl)
>> +                               fence_put(bo->fence_excl);
>> +
>> +                       bo->fence_excl = fence;
>> +               } else {
>> +                       if (WARN_ON(bo->fence_shared_count >=
>> +                                   ARRAY_SIZE(bo->fence_shared))) {
>> +                               mutex_unreserve_unlock(&bo->lock);
>> +                               continue;
>> +                       }
>> +
>> +                       bo->fence_shared[bo->fence_shared_count++] = fence;
>> +               }
> Hi,
>
> I got some questions to fence_excl and fence_shared. At the above
> code, if bo->fence_excl is not NULL then it puts bo->fence_excl and
> sets a new fence to it. This seems like that someone that committed a
> new fence, wants to access the given dmabuf exclusively even if
> someone is accessing the given dmabuf.
Yes, if there were shared fences, they had to issue a wait for the previous exclusive fence, so if you add
(possibly hardware) wait ops on those shared fences to your command stream, it follows that you also
waited for the previous exclusive fence implicitly.

If there is only an exclusive fence, you have to issue some explicit wait op  on it before you start the rest
of the commands.
> On the other hand, in case of fence_shared, someone wants to access
> that dmabuf non-exclusively. So this case seems like that the given
> dmabuf could be accessed by two more devices. So I guess that the
> fence_excl could be used for write access(may need buffer sync like
> blocking) and read access for the fence_shared(may not need buffer
> sync). I'm not sure that I understand these two things correctly so
> could you please give me more comments for them?
Correct, if you create a shared fence, you still have to emit a wait op for the exclusive fence.
> Thanks,
> Inki Dae
>
>> +               fence_get(fence);
>> +
>> +               mutex_unreserve_unlock(&bo->lock);
>> +       }
>> +       reservation_ticket_fini(ticket);
>> +}
>> +EXPORT_SYMBOL(ticket_commit);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/