On Wed, Dec 08, 2021 at 02:41:47AM +0300, Vitaliy Makkoveev wrote: > [IN] looks strange. If this field modified after creation it is > mutable. There are cases when such field could modified only once, > but it still is atomic. > > We have cases where we do assignment only once, like `unp_addr’ > when we bind(2)ing socket and we don’t modify if until socket’s > destruction. Since we could connect to successfully bind(2)ed > socket only we could say within unp_connect() that `unp_addr’ > could be accessed without lock. > > We also have the case where we could bind(2) already connected > socket. I such case we could say `unp_addr’ is atomic because > this is the pointer assignment which points to read-only data > and this data immutable until socket’s destruction. > > But `unp_addr’ is still mutable.
Please stop saying that a thing is simply "atomic". If one sees "atomic" in a locking annotation, one has no idea what exactly it means. Nearly everything in the kernel can be seen as "atomic" by choosing a suitable story. Whenever a piece of code accesses shared data without locking, there has to be a well-defined protocol for the accesses. Otherwise the code cannot function reliably. Locking annotations should at least hint toward the protocol. Annotation "immutable after creation" or "immutable after setting" are clearly better than just "atomic".
