About Linux Socket Filter
Hi: I am writing a socket filter program and using "tcpdump -dd vlan and arp" to filter out the arp packet whose protocol field is 8100(vlan). Everything is fine if I call recvfrom to receive the packet. However, if I open two packet socket in parallel (and use the select to demultiplex among them, then the program will sacrifice the arp protocol handling! My program get arp request/reply as usual, but the kernel cannot get any arp request anymore. And the linux kernel no longer receives any packet if I flush the arp table since kernel cannot get arp request. I insert debug information (printk) next to the ptype handling loop, netif_receive_skb (ret = pt_prev->func(skb, skb->dev, pt_prev)), and the kernel exactly print out the information. Does that mean the packet is exactly inserted into the queue of the socket and kernel path returns to the processing loop? How could user space program steal the packet? (Note that the two interface involved are the member of the bridge, but I think the ptype looping is after the handle bridge and should not sacrifice the arp handling.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
About Linux Socket Filter
Hi: I am writing a socket filter program and using tcpdump -dd vlan and arp to filter out the arp packet whose protocol field is 8100(vlan). Everything is fine if I call recvfrom to receive the packet. However, if I open two packet socket in parallel (and use the select to demultiplex among them, then the program will sacrifice the arp protocol handling! My program get arp request/reply as usual, but the kernel cannot get any arp request anymore. And the linux kernel no longer receives any packet if I flush the arp table since kernel cannot get arp request. I insert debug information (printk) next to the ptype handling loop, netif_receive_skb (ret = pt_prev-func(skb, skb-dev, pt_prev)), and the kernel exactly print out the information. Does that mean the packet is exactly inserted into the queue of the socket and kernel path returns to the processing loop? How could user space program steal the packet? (Note that the two interface involved are the member of the bridge, but I think the ptype looping is after the handle bridge and should not sacrifice the arp handling.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduling in interrupt and call trace
Hi all: I am tracking a driver bug in arm linux when I got a scheduling in interrupt context panic. I traced into kernel schedule() function, and found that "schedulingin interrupt" is a check point when the process scheduler is invoked, and the callstack reveals that the scheduler is invoked due to semaphore down(). After that, the program counter must located in BUG(), that is something like "(void *)0 = 0" if we really do scheduling in interrupt contxt, and should cause the kernel to panic. However, what i got is that the latest program counter is located within the do_IRQ() context when the kernel was crashed . But it seems that the stack trace is a kernel stack of process context since the bottom of the stack is ret_from_syscall. (I have not enabled the frame pointer when compiling the kernel, instead, I back traced by manually inspect each 32 bit value from the output of objdump) , and I think that the latest PC should point to the next instruction of "(void *) 0 = 0". Is there any possibility with which we got this incorrect information, or I have misunderstanding about "kernel system to interrupt context switch? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduling in interrupt and call trace
Hi all: I am tracking a driver bug in arm linux when I got a scheduling in interrupt context panic. I traced into kernel schedule() function, and found that schedulingin interrupt is a check point when the process scheduler is invoked, and the callstack reveals that the scheduler is invoked due to semaphore down(). After that, the program counter must located in BUG(), that is something like (void *)0 = 0 if we really do scheduling in interrupt contxt, and should cause the kernel to panic. However, what i got is that the latest program counter is located within the do_IRQ() context when the kernel was crashed . But it seems that the stack trace is a kernel stack of process context since the bottom of the stack is ret_from_syscall. (I have not enabled the frame pointer when compiling the kernel, instead, I back traced by manually inspect each 32 bit value from the output of objdump) , and I think that the latest PC should point to the next instruction of (void *) 0 = 0. Is there any possibility with which we got this incorrect information, or I have misunderstanding about kernel system to interrupt context switch? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
