On Wed, 15 May 2024 at 23:51, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: [...] > > And I just checked the current access-marking.txt to see where we > > might add more, and found the section "ACCESS-DOCUMENTATION OPTIONS" > > already exists. I think that section is perfectly reasonable as is, > > and it does explicitly talk about ASSERT_EXCLUSIVE* macros. > > > > Did you want to add it more prominently at the top? If so, maybe a > > brief forward-reference to that section might be helpful. > > How about like this? > > ------------------------------------------------------------------------ > > The Linux kernel provides the following access-marking options: > > 1. Plain C-language accesses (unmarked), for example, "a = b;" > > 2. Data-race marking, for example, "data_race(a = b);" > > 3. READ_ONCE(), for example, "a = READ_ONCE(b);" > The various forms of atomic_read() also fit in here. > > 4. WRITE_ONCE(), for example, "WRITE_ONCE(a, b);" > The various forms of atomic_set() also fit in here. > > 5. __data_racy, for example "int __data_racy a;" > > 6. KCSAN's negative-marking assertions, ASSERT_EXCLUSIVE_ACCESS() > and ASSERT_EXCLUSIVE_WRITER(), are desccribed in the > "ACCESS-DOCUMENTATION OPTIONS" section below. s/desccribed/described/ > ------------------------------------------------------------------------ > > Would that work? It works for me, if we agree that "negative marking" makes sense: if the other markings indicate the access is happening concurrently with others, a negative marking does the opposite. Thanks, -- Marco
