On Thu, Aug 13, 2009 at 03:44:27PM +0200, Patrick McHardy wrote: > 홍신 shin hong wrote: > > Hi. I am reporting two suspected race bug related to atomic operations > > while I read net/netfilter/ipvs of Linux 2.6.30.4. > > > > (1) In net/netfilter/ipvs/ip_vs_core.c, ip_vs_in() first increments &cp->in_pkts > > and then reads variable for condition checking at line 1346-1351. > > > > However, these two atomic operations may not be executed atomically. > > For this reason, it may result race with other concurrent executions > > which manipulates &cp->in_pkts. > > > > (2) In net/netfilter/ipvs/ip_vs_wrr.c, ip_vs_wrr_max_weight() first > > checks &dest->weight > > and then reads the variable again to assign its value to a local variable. > > For the similar reason above, it seems that two atomic_read() operations > > may result different values so that it may result race condition. > > > > Please examine the code and let me know your opinion. Thanks. > > I'm not sure whether the IPVS guys are following the netfilter-devel > list, so I've CCed Wensong and Simon. Hi, my feeling is that with both of these is that while there are certainly correctness problems they shouldn't manifest in anything terribly bad happening. In both cases I feel that we are essentially dealing with inputs to a heuristic, and thus some noise in the input really ought not make much difference in the long run, although and individual packet or connection may be miss-classified. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
