For each kdbus domain, we maintain an ID-counter to guarantee unique IDs
across all objects. We also used to use it for message IDs. However, this
requires touching a shared cacheline on each message transaction, even
though we never guaranteed global ordering across buses, anyway.

Introduce a separate counter which is used solely for message IDs.
Semantics stay the same, but it no longer relates to IDs across buses.

Reviewed-by: Daniel Mack <dan...@zonque.org>
Signed-off-by: David Herrmann <dh.herrm...@gmail.com>
---
 ipc/kdbus/bus.h     | 2 ++
 ipc/kdbus/message.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/ipc/kdbus/bus.h b/ipc/kdbus/bus.h
index 238986e..8c2acae 100644
--- a/ipc/kdbus/bus.h
+++ b/ipc/kdbus/bus.h
@@ -44,6 +44,7 @@ struct kdbus_user;
  * @domain:            Domain of this bus
  * @creator:           Creator of the bus
  * @creator_meta:      Meta information about the bus creator
+ * @last_message_id:   Last used message id
  * @policy_db:         Policy database for this bus
  * @name_registry:     Name registry of this bus
  * @conn_rwlock:       Read/Write lock for all lists of child connections
@@ -67,6 +68,7 @@ struct kdbus_bus {
        struct kdbus_meta_proc *creator_meta;
 
        /* protected by own locks */
+       atomic64_t last_message_id;
        struct kdbus_policy_db policy_db;
        struct kdbus_name_registry *name_registry;
 
diff --git a/ipc/kdbus/message.c b/ipc/kdbus/message.c
index 432dba4..ae565cd 100644
--- a/ipc/kdbus/message.c
+++ b/ipc/kdbus/message.c
@@ -671,7 +671,7 @@ static struct kdbus_staging *kdbus_staging_new(struct 
kdbus_bus *bus,
        if (!staging)
                return ERR_PTR(-ENOMEM);
 
-       staging->msg_seqnum = atomic64_inc_return(&bus->domain->last_id);
+       staging->msg_seqnum = atomic64_inc_return(&bus->last_message_id);
        staging->n_parts = 0; /* we reserve n_parts, but don't enforce them */
        staging->parts = (void *)(staging + 1);
 
-- 
2.5.0

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

Reply via email to