10.4-stable systematically crashing inside pselect() when a tun device is used

Kristof Provost kristof at sigsegv.be
Sun Nov 19 11:11:34 UTC 2017


On 18 Nov 2017, at 17:16, Jukka A. Ukkonen wrote:
> Hello all,
>
> As briefly stated in the subject I have a 10-stable system on
> which I have been testing a program which opens either a tun
> device or a tap device, waits in pselect() for the descriptor
> to become readable, and then proceeds to read the packet/frame.
> When using a tun descriptor the pselect() call systematically
> panics the kernel with the complaints shown in the text dump
> snippet at the end of this message. When using a tap device
> the same code works just fine.

Can you post the code that you use to trigger this too?

> Fatal trap 12: page fault while in kernel mode
> cpuid = 10; apic id = 13
> fault virtual address	= 0x8
Clearly a NULL pointer dereference (into a struct).

> trap number             = 12
> panic: page fault
> cpuid = 10
> KDB: stack backtrace:
> #0 0xffffffff80a97b60 at kdb_backtrace+0x60
> #1 0xffffffff80a57d26 at vpanic+0x126
> #2 0xffffffff80a57bf3 at panic+0x43
> #3 0xffffffff80e8b84d at trap_fatal+0x35d
> #4 0xffffffff80e8bb68 at trap_pfault+0x308
> #5 0xffffffff80e8b1ca at trap+0x47a
> #6 0xffffffff80e6f93c at calltrap+0x8
> #7 0xffffffff80aaa645 at taskqueue_run_locked+0xf5

So this happens on a task queue, but we don’t know which one from the 
backtrace.
It’s not immediately obvious where this would be happening, so it’d 
be quite useful if you could post the user space code (and setup) that 
triggers this.

Regards,
Kristof


More information about the freebsd-questions mailing list