This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2211211 - clang TSA cannot guard sibling struct fields in C
Summary: clang TSA cannot guard sibling struct fields in C
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: clang
Version: 9.2
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Tom Stellard
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-05-30 18:28 UTC by Stefan Hajnoczi
Modified: 2023-08-25 00:39 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-25 00:39:47 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
LLVM 20403 0 None None None 2023-05-30 18:28:42 UTC
Red Hat Issue Tracker   RHEL-1651 0 None Migrated None 2023-08-25 00:39:40 UTC
Red Hat Issue Tracker RHELPLAN-158609 0 None None None 2023-05-30 18:32:46 UTC

Description Stefan Hajnoczi 2023-05-30 18:28:43 UTC 
Description of problem:
C programs often place locks alongside the struct fields that they protect. There is currently no syntax for using clang's TSA __attribute__((guarded_by(...))) with sibling struct fields in C programs.

This limits the usefulness of TSA in C programs. In QEMU, we are only able to use TSA with global mutexes for this reason.

Note this is a known limitation upstream. See https://bugs.llvm.org/show_bug.cgi?id=20403.

Version-Release number of selected component (if applicable):
clang-15.0.7-2.el9.x86_64

How reproducible:


Steps to Reproduce:
1. $ cat >a.c
#include <assert.h>
#include <pthread.h>

typedef pthread_mutex_t __attribute__((capability("mutex"))) mutex;

struct foo
{
    mutex lock;
    int counter __attribute__((guarded_by(/* how to express ->lock? */)));
};

static void foo_inc(struct foo *f)
{
    pthread_mutex_lock(&f->lock);
    f->counter++;
    pthread_mutex_unlock(&f->lock);
}

int main(int argc, char **argv)
{
    struct foo f = {};
    int ret;

    ret = pthread_mutex_init(&f.lock, NULL);
    assert(ret == 0);

    foo_inc(&f);

    ret = pthread_mutex_destroy(&f.lock);
    assert(ret == 0);
    return 0;
}

2. clang -Wthread-safety -o a a.c

Actual results:
Unable to compile because there is no syntax to guard ->counter with ->lock.

Expected results:
Able to compile and check that ->lock is held when ->counter is accessed.

Additional info:
Comment 1 Timm Bäder 2023-06-14 08:38:27 UTC 
The reproducer warns in C++: https://godbolt.org/z/qfYjsKzoG (where using this->lock works). Is the missing support for referencing struct members in C the only problem in the reproducer or are there other ones? What's needed to make the reproducer not warn?
Comment 2 Timm Bäder 2023-06-14 12:35:49 UTC 
Ah, I get it. In C++, member functions work, and in C, release_capability(f->lock) etc. works.
Comment 3 Kevin Wolf 2023-06-20 16:15:19 UTC 
(In reply to Timm Bäder from comment #1)
> The reproducer warns in C++: https://godbolt.org/z/qfYjsKzoG (where using
> this->lock works). Is the missing support for referencing struct members in
> C the only problem in the reproducer or are there other ones? What's needed
> to make the reproducer not warn?

I think the warning you're seeing is the expected result for the code above because the pthread lock functions don't have TSA annotations. In clean code, you should probably use separate wrapper functions if you created a new lock type with typedef, but as a quick hack to make the warning go away, adding these declarations is enough for me:

int pthread_mutex_lock(mutex *mutex) __attribute__((acquire_capability(*mutex)));
int pthread_mutex_unlock(mutex *mutex) __attribute__((release_capability(*mutex)));
Comment 4 Stephen Coady 2023-08-24 13:12:36 UTC 
This bug is about to be migrated to the RHEL project in JIRA. Once done, this bug should automatically be closed with a reference link to the new JIRA. Please continue any conversations there. For any questions, you can contact either me or Timm Bäder.
Comment 5 RHEL Program Management 2023-08-24 13:15:53 UTC 
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 6 RHEL Program Management 2023-08-25 00:39:47 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.
Note You need to log in before you can comment on or make changes to this bug.