On Thu, May 16, 2024 at 08:35:02AM +0200, Marco Elver wrote: > 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/ Good eyes, fixed! > > ------------------------------------------------------------------------ > > > > 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. Very good, I will send this out shortly after v6.10-rc1 comes out and let's see where the bikeshedding leads. ;-) Thanx, Paul
