Bug 2211211

Summary:	clang TSA cannot guard sibling struct fields in C
Product:	Red Hat Enterprise Linux 9	Reporter:	Stefan Hajnoczi <stefanha>
Component:	clang	Assignee:	Tom Stellard <tstellar>
Status:	CLOSED MIGRATED	QA Contact:	qe-baseos-tools-bugs
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	9.2	CC:	jchecahi, kwolf, mprchlik, pbonzini, scoady, sipoyare, tbaeder, tstellar
Target Milestone:	rc	Keywords:	MigratedToJIRA, Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-25 00:39:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.