On 11 December 2014 at 14:16, Martin Pieuchot <mpieuc...@nolizard.org> wrote: > On 11/12/14(Thu) 12:37, frantisek holop wrote: >> > > login: kernel: page fault trap, code=0 >> > > Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx >> > > ddb{0}> trace >> > > in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at >> > > in_selectsrc+0xd8 >> > > >> > > udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8 >> > > sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b >> > > sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1 >> > > sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at >> > > sys_sendto+0x6c >> > > syscall() at syscall+0x144 >> > > --- syscall (number 259) --- >> > > 0x2: >> > > ddb{0}> >> >> run0 usb dongle + dhclient through a home router, >> with one special route added that is forwarded through >> a linux box (on the same home router network) which >> is connected to a vpn in a different country. >> it is added like this: >> >> # route add 192.168.10.2 $LINUX_IP >> >> jenkins is running a shell script, that is running >> tests on the 192.168.10.2 web site accessible only >> through the vpn. the tests are simple selenium tests >> recorded through the firefox plugin. a quick google >> reveals that jenkins itself might be using some >> udp/multicast functionality: >> https://wiki.jenkins-ci.org/display/JENKINS/Auto-discovering+Jenkins+on+the+network > > Could you try the diff below and let me know if it improves the > situation? It should prevent your kernel to panic. Even though, > more work might be required to have working socket w/ multicast > using USB devices upon resume. > > What's happening is simply a use after free because there's no way to > invalidate multicast options attached to a pcb when an interface is > detached. I which multicast would have been implemented using route > entries instead of this hack... > > Change below works around this problem by using interface indexes. >
Makes sense to me. OK mikeb