Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 2387accd authored by Guru Das Srinagesh's avatar Guru Das Srinagesh Committed by Gerrit - the friendly Code Review server
Browse files

haven: gh_msgq: Disallow multiple registrations with same label



Multiple clients racing with each other to register with the same label
could possibly succeed in doing so, contrary to design, which mandates
that only one client should be able to register with a given label, and
others should receive an -EBUSY. This is due to the below two reasons:
  1. Checking for a label's cap_table_entry in the global
     gh_msgq_cap_list and then allocating one if none is found is
     not an atomic operation all under one spinlock.
  2. The cap_entry_lock spinlock protecting the cap_table_entry is
     relinquished prematurely, before the client_desc can be set in
     cap_table_entry.
Two clients attempting to register by passing in the same label could
potentially each find no corresponding cap_table_entry and then each
proceed to allocate a new entry (adding it to the global
gh_msgq_cap_list). Continuing with this scenario, both freshly-allocated
cap_table_entry's will have their client_desc set to NULL and so will
have a client_desc allocated and return successfully.
Fix this by:
1. Bringing the cap_table_entry existence check and allocation steps
   under the same spinlock, thereby preventing further allocations if
   the cap_table_entry already exists.
2. Removing the spinlock from within gh_mgsq_alloc_entry() because it is
   now being called with the same spinlock held.
3. Extending cap_entry_lock's critical section to cover the allocation
   of client_desc as well. This will prevent the overwriting of
   client_desc in the case of a race condition where two clients obtain
   the same cap_table_entry and both of them find their client_desc's to
   be NULL and then each proceed to allocate one and assign it to the
   same cap_table_entry one after the other.
4. Changing the allocation flags to GFP_ATOMIC to avoid sleeping within
   a critical section.

Change-Id: I99072d466e91151302a50e5f35f2b2a8d5ee5c48
Signed-off-by: default avatarGuru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: default avatarKishor Krishna Bhat <quic_kishkris@quicinc.com>
parent b6845fdd
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment