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
