On Saturday 2010-11-27 10:06, Jozsef Kadlecsik wrote: > >a suspended process could cause any problem, we faced it already. * let there be a list of 6 entries of data, ABCDEF * proc A starts a dump and reads, say, 1 of 10 entries (A) * proc B adds a new entry at the start of the list, Z, and deletes an entry, A (and does these two actions atomically) * proc A reads the rest procA read the sequence ACDEF. In case of interfaces or ct entries, that does not matter, because they are pretty much independent of another. However, a ruleset's rules are not independent in this way. Suppose: Z = -A INPUT -m conntrack --ctstate ESTABLISHED A = -A INPUT -p icmp -j ACCEPT B = -A INPUT -p tcp --dport 22 -j ACCEPT C = -A INPUT -j DROP D = -A OUTPUT -p icmp -j ACCEPT E = -A OUTPUT -p tcp --dport 22 -j ACCEPT F = -A OUTPUT -j DROP One would want to either see ABCDEF, or ZBCDEF, because presenting ACDEF to the user, (a) -A INPUT -p icmp -j ACCEPT (c) -A INPUT -j DROP would mean to him that SSH cannot be accessed, which is not the case. We needs locks, yeah. The entire ruleset and chains are RCU-protected, and the actual packet processing holds rcu_read_lock for the entire period, so it is already guaranteed to see either ABCDEF or ZBCDEF, which is fine. When the kernel dumps however, and the skb is full, and it returns to userspace, no rcu and no mutex may be held, which gives away the guarantee of an atomic view. The chain might go away inbetween, unless I hold the writer lock. To hold the lock across the entire dump would require some semaphore, and it does not seem like a good idea to block users across returns to userspace either. Currently, the writer lock (mutex) is held as short as possible, to make a snapshot, or to actually do the replacement. It sort of works.. Does that help? -- 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
