hello! I'm seeing similiar problems to the ones that Josh Green reported some time ago on this list (but alas didn't seem to get any further attention...) The problem seems to be so far, that when modifying the iptables structures by adding/flushing the rules, a state can be reached sooner or later (indeterministic! smells like race) where the data structure becomes invalid (although there are checks in the kernel which would prevent that); the result is either ip_tables.c:ipt_do_tables() causing an oops due to bad pointer dereferencing (or the kernel freezing w/o further notice at all), or the iptables tool being unable to retrieve/modify the rules from the kernel (and getting ENOMEM/EINVAL) or simply segfaulting due to other inconsistencies with the data... I was able to avoid corruption by replacing all vmalloc()/vfree() calls by kmalloc()/kfree()'s respectively in ip_tables.c; another variant which I was suggested to try helped as well: inserting flush_tlb_all() calls after every vmalloc() in said source file; I assumed so far, the issue must be alchemy specific, as I experienced this on a DbAu1550 board; and Josh had it on a DbAu1100; As it's a rather easy to trigger bug, I would have expected to see more bug reports if it affected more than just the alchemy's on 2.6.x; I tried it with a few kernel revisions from linux-mips' cvs (from 2.6.10 upto 2.6.12rc2); also tried different compilers (debian's cross-gcc's 3.4.4 and 3.3.3), even switched the alchemy to little endian operation... all the same; everything else I use on that board has been rather stable so far, iptables are the only part which show up this vmalloc-issue so far... as to reproducing the bug, it's rather easy for me: a script repeatedly performing rule modifications should trigger the issue rather easily (possibly called over a remote ssh/telnet session, in order to create a bit of traffic as well...) set -x while : do iptables -F || exit 1 iptables -A INPUT -i lo -j ACCEPT || exit 1 iptables -A INPUT -p udp -i eth0 --dport domain -j ACCEPT || exit 1 iptables -A INPUT -p udp -i eth0 --dport 6666 -j ACCEPT || exit 1 iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT || exit 1 iptables -A INPUT -p tcp -i eth0 --dport http -j ACCEPT || exit 1 iptables -A INPUT -p tcp -i eth0 --dport https -j ACCEPT || exit 1 iptables -A INPUT -p tcp -i eth0 --dport 3496 -j ACCEPT || exit 1 done or alternatively (requiring state & multiport helpers) while : do iptables -F iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT || exit 1 iptables -A INPUT -i lo -j ACCEPT || exit 1 iptables -A INPUT -p udp -i eth0 -m multiport --dports domain,6666 -j ACCEPT || exit 1 iptables -A INPUT -p tcp -i eth0 -m multiport --dports ssh,http,https,3496 -j ACCEPT || exit 1 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT || exit 1 iptables -A OUTPUT -o lo -j ACCEPT || exit 1 iptables -A OUTPUT -p udp -o eth0 -m multiport --dports ntp -j ACCEPT || exit 1 iptables -A OUTPUT -p tcp -o eth0 -m multiport --dports www,https,8444,8445,8446,8454,8455,8456,8464,8465,8466,9225 -j ACCEPT || exit 1 done regards, -- Herbert Valerio Riedel <hvr@xxxxxxxxxx>
