Re: [PATCH v2] rcu: fix a race in hlist_nulls_for_each_entry_rcu macro

[Roman Gushchin <klamm@yandex-team.ru>]

On 22.05.2013 17:27, David Laight wrote:
>> So yes, the patch appears to fix the bug, but it sounds not logical to
>> me.
>
> I was confused because the copy of the code I found was different
> (it has some checks for reusaddr - which force a function call in the
> loop).
>
> The code being compiled is:
>
> begin:
> 	result = NULL;
> 	badness = -1;
> 	udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
> 		score = compute_score2(sk, net, saddr, sport,
> 				      daddr, hnum, dif);
> 		if (score > badness) {
> 			result = sk;
> 			badness = score;
> 			if (score == SCORE2_MAX)
> 				goto exact_match;
> 		}
> 	}
> 	/*
> 	 * if the nulls value we got at the end of this lookup is
> 	 * not the expected one, we must restart lookup.
> 	 * We probably met an item that was moved to another chain.
> 	 */
> 	if (get_nulls_value(node) != slot2)
> 		goto begin;
>
> Which is entirely inlined - so the compiler is allowed to assume
> that no other code modifies any of the data.
> Hence it is allowed to cache the list head value.
> Indeed it could convert the last line to "for (;;);".
>
> A asm volatile ("":::"memory") somewhere would fix it.
>

Yes, it does. It was my first attempt to fix the issue.
But putting such instructions into each such cycle isn't a good idea, IMHO.

Regards,
Roman