linux-kernel - drivers/misc/habanalabs: atomic

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-next>] [day] [month] [year] [list]

Date:   Mon, 21 Sep 2020 16:08:37 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     oded.gabbay@...il.com, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        obitton@...ana.ai, lee.jones@...aro.org, oshpigelman@...ana.ai
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: drivers/misc/habanalabs: atomic_t api usage inconsistencies

All,

While I was looking at the atomic_t api usages for an unrelated issue,
I noticed free_slots_cnt in struct hl_cq incerment/decrement/reads are
not consistent.

atomic_inc() and atomic_set() are used, however instead of atomic_read()
the value is referenced directly in
drivers/misc/habanalabs/common/hw_queue.c

hl_queue_add_ptr()
atomic_t *free_slots = &hdev->completion_queue[q->cq_id].free_slots_cnt;

hl_hw_queue_schedule_cs()

atomic_t *free_slots = &hdev->completion_queue[i].free_slots_cnt;

Any reason why this is necessary. I don't know that this is causing
any problems, it is just odd that access is inconsistent.

thanks,
-- Shuah