On 9/1/20 10:52 AM, Tuong Tong Lien wrote:
> Ok, I've got your concern now. Actually when writing this code, I had the
> same thought as you, but decided to relax it because of the following reasons:
> 1. I don't want to use any locking methods here that can lead to competition
> (thus affect overall performance...);
> 2. The list is not an usual list but a fixed "ring" of persistent elements
> (no one will insert/remove any element after it is created);
> 3. It does _not_ matter at all if the function calls will result in the same
> element, or one call points to the 1st element while another at the same time
> points to the 3rd one, etc. as long as it returns an element in the list.
> Also, the per-cpu pointer is _not_ required to exactly point to the next
> element, but needs to be moved on this or next time..., so just relaxing!
> 4. Isn't a "write" to the per-cpu variable atomic?
>
I think I will give up, this code is clearly racy, and will consider TIPC as
broken.
Your patch only silenced syzbot report, but the bug is still there.
