On Sun, Oct 20, 2013 at 09:39:26AM +0300, Julian Anastasov wrote: > > Hello, > > On Sat, 19 Oct 2013, Hannes Frederic Sowa wrote: > > > On Sat, Oct 19, 2013 at 07:37:10PM +0300, Julian Anastasov wrote: > > > > > > Problem with process stack? May be some packet loop > > > happens? Because I can not reproduce such problem in my > > > virtual setup, I tested TEE too, with careful packet > > > matching and 1 CPU. Should I assume that you don't have such > > > oops when the patch is not applied, with the same TEE rule? > > > > Oh, sorry, you are right. It happens with an unpatched net-next kernel, too. > > > > I inserted the TEE rule in mangel/OUTGOING and had only one route, ip -6 r a > > default via fe80::1 dev eth0 which at the time of the panic was actually not > > reachable. > > Thanks for the confirmation! I'll try later > to reproduce such problem with TEE, it is interesting > to know the real reason for this loop. Yup, I have a patch in works wich defers the ndisc_send_ns call in rt6_probe into a workqueue out of the call stack. This should solve the problem. Still wonder if there is a nicer api as to create a new structure and pass the arguments via container_of dereferencing to the deferred function (and I don't think async calls are useable there). Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
