LibAlias in FreeBSD
Hello Charles Mott I wrote this mail about my work with IPFW firewall. I am started my work over IPFW Sync driver and protocol similar like in PF firewall. My primery goal is to do sync on NAT states in firewall router cluster. About it, I need to know when NAT driver add, readd or delete alias to be notify from libalias I see one good approach to achieve this, but I must to asking if existing hidden drawbacks for such approach the author of libalias. My idea is to add new member like function callback into struct libalias. If it is different from NULL, then functions which update Alias DB will call that callback for notification. When my driver get info it will be send over network to other hosts. They must just update their Alias DBs. What are you thinking about such approach, change and hook of the existing code? -- Michael Pounov ELWIX - Embedded LightWeight unIX -
Re: LibAlias in FreeBSD
On Fri, May 27, 2022 at 04:18:54PM +0300, Michael Pounov wrote: > Hello Charles Mott > > I wrote this mail about my work with IPFW firewall. > I am started my work over IPFW Sync driver and protocol similar like in PF > firewall. > My primery goal is to do sync on NAT states in firewall router cluster. About > it, I need to know when NAT driver add, readd or delete alias to be notify > from libalias > I see one good approach to achieve this, but I must to asking if existing > hidden drawbacks for such approach the author of libalias. As long as the callback is internal to the kernel, it might work. libalias is CPU bound, any additional work will slow down the system, especially when libalias is called from the interrupt level of network drivers. > What are you thinking about such approach, change and hook of the existing > code? One can think about a ringbuffer which is filled by libalias and read by a different type of code. If the other code is too slow, the ringbuffer will override the entries. Please do not consider a dynamically allocated buffer.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #5 from John Baldwin --- Looks like it walked off the end of the mbuf chain as it tried to copy one byte too many. You could try going up to frame 8 (tcp_output) to see if the arguments passed to m_copydata() are still around (looks like we know the mbuf chain via m@entry for frame 9, but knowing the original length and offset and confirming it walked off the end would be good). You'd have to figure out why the length was wrong though and that might need more digging in the tp or the like. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #6 from iron.ud...@gmail.com --- (In reply to John Baldwin from comment #5) Oh...I'm not sure that I can do it by myself. I'm not so expirianced in debugging. Can I send you compressed core dump file? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #7 from John Baldwin --- Hmm, unfortunately it would need to be the contents of /boot/kernel and /usr/lib/debug/boot/kernel along with the vmcore. However, if you can stick those all in a tarball I can take a look at them. It might be simpler to store them at a URL and mail that to me directly. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #8 from iron.ud...@gmail.com --- (In reply to John Baldwin from comment #7) Emailed you link on archive. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 --- Comment #18 from benoitc --- is there anything that can be done for it ? Any update needed? It's kind of suprising nobody came with a solution in 3 years on such obvious issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 --- Comment #19 from benoitc --- is there anything that can be done for it ? Any update needed? It's kind of suprising nobody came with a solution in 3 years on such obvious issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #9 from Michael Tuexen --- (In reply to iron.udjin from comment #8) You might also send the link to me (tue...@freebsd.org) and Richard (rsch...@freebsd.org), if you are willing to do so. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #10 from iron.ud...@gmail.com --- (In reply to Michael Tuexen from comment #9) Done. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Adding a new member to m_pkthdr
For NIC offload of kernel TLS on the receive side, the kernel needs to know the "leaf" interface that packets arrive on up in the socket buffer layer when appending received packet data to a socket using KTLS. rcvif does not fully work since connections that transit a virtual interface like if_vlan or if_lagg rewrite m_rcvif to be the virtual interface. For KTLS transmit we are able to follow the transmit path down to configure KTLS on the leaf interface. However, while the receive path is usually a mirror of the transmit path, it is not always. In particular, when using a lagg(4) with LACP, the other end of the lagg is free to use whatever hash it chooses to distribute traffic across the lagg ports such that the receive and transmit sides of a connection may transit different ports within a lagg. To provide a leaf interface, I have a patch that adds a new field to m_pkthdr to track the leaf receive interface. It is optional and the only use currently anticipated is KTLS. In the current KTLS patches it is set on received packets by the mlx5 driver. Possibly it could be set more generically in ether_input instead of in individual drivers. It is serialized to an index and generation count while packets are deferred to a netisr similar to rcvif except that it is non-fatal if the ifp cannot be re-materialized when the mbuf is dequeued. Instead, the pointer is simply left as NULL. However, using more space in m_pkthdr is a non-trivial thing, so it's worth raising the conversation more broadly. The change to add this field is in https://reviews.freebsd.org/D35339. Drew has tested this isolated change under load at Netflix and found no impact on performance. -- John Baldwin
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #11 from Michael Tuexen --- (In reply to iron.udjin from comment #10) Thanks! I could download the tarball and will also have a look at it. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Re: LibAlias in FreeBSD
On this callback I will attach my function from ipfw_sync driver. This callback will return immediately with passed address. It will transfer just particular created list item like const pointer from In or Out arrays. I will read such data direct from Alias DB item without additional memory operations. About ringbuffer in libalias. Now db is organized on two hash arrays with 4001 count of elements, which contains heads of the lists. I have second way which also can do the work. It was made from me like shadow tables for broadcom chip states into switch firmware before more then 10 years ago. This approach don't touch original libalias structure, but have huge drawback. Delay from regular time by driven updates of shadow structures. I'm sure that isn't ok for router cluster cases. Because we have too small time when various packets can come on another router's ingress interface. I still believe that way with hooks on Alias DB updates with export of original address of DB list member will be right approach to be done. Most fastest and efficient Thanks from feedback. On 2022-05-27 18:35, Lutz Donnerhacke wrote: On Fri, May 27, 2022 at 04:18:54PM +0300, Michael Pounov wrote: Hello Charles Mott I wrote this mail about my work with IPFW firewall. I am started my work over IPFW Sync driver and protocol similar like in PF firewall. My primery goal is to do sync on NAT states in firewall router cluster. About it, I need to know when NAT driver add, readd or delete alias to be notify from libalias I see one good approach to achieve this, but I must to asking if existing hidden drawbacks for such approach the author of libalias. As long as the callback is internal to the kernel, it might work. libalias is CPU bound, any additional work will slow down the system, especially when libalias is called from the interrupt level of network drivers. What are you thinking about such approach, change and hook of the existing code? One can think about a ringbuffer which is filled by libalias and read by a different type of code. If the other code is too slow, the ringbuffer will override the entries. Please do not consider a dynamically allocated buffer.
