Date: Sun, 12 Apr 2020 19:09:28 +0100 From: Alexander V. Chernikov <melifaro@freebsd.org> To: Li-Wen Hsu <lwhsu@freebsd.org> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org> Subject: Re: ipdivert tests and net.inet.ip.fw.default_to_accept Message-ID: <6963991586714482@vla4-4046ec513d04.qloud-c.yandex.net> In-Reply-To: <CAKBkRUx%2B5ZKgPtb2hcYOk2-Ddz8BgX8pLoG8yHMuDakMWKKhfw@mail.gmail.com> References: <CAKBkRUx%2B5ZKgPtb2hcYOk2-Ddz8BgX8pLoG8yHMuDakMWKKhfw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
12.04.2020, 18:45, "Li-Wen Hsu" <lwhsu@freebsd.org>: > (CC freebsd-testing@ for more people can join the discussion) > > Hi Alexander, Ehlo! > > I'm checking test failures and panics, and found that the two ipdivert > tests we added previously have never been tested correctly. I've Yep, I've been running tests manually but haven't managed to raise a pull request to auto-load ipdivert prior to the tests yet. > loaded ipdivert.ko to unskip them in test VM, and found that these > two tests will fail or panic the kernel when > net.inet.ip.fw.default_to_accept is not 1. Wow. That's an interesting one! I've been always testing them with default_to_accept set to 1, as it eases test configuration. > > I'm thinking: > > 1) Also checks for net.inet.ip.fw.default_to_accept=1 at the beginning > and skip the test if 0 Well, ipfw defaults are not that well isolated in vnet. Maybe a better way would be to just install allow-all rule in VNET jail and proceed normally. > 2) Is this lock order reversal normal? No. > 3) Does this panic indicate a bug in the relative code? Yes. Let me investigate it. > > How do you think? > > Details of running the two tests are as following: > > # kyua test divert:ipdivert_ip_input_local_success > divert:ipdivert_ip_input_local_success -> lock order reversal: > 1st 0xffffffff81c8e558 allprison (allprison) @ > /usr/src/sys/kern/kern_jail.c:953 > 2nd 0xffffffff81d9a750 vnet_sysinit_sxlock (vnet_sysinit_sxlock) @ > /usr/src/sys/net/vnet.c:577 > stack backtrace: > #0 0xffffffff80c28671 at witness_debugger+0x71 > #1 0xffffffff80bc7747 at _sx_slock_int+0x67 > #2 0xffffffff80cfd2ce at vnet_alloc+0x11e > #3 0xffffffff80b7fd93 at kern_jail_set+0x1a23 > #4 0xffffffff80b81670 at sys_jail_set+0x40 > #5 0xffffffff8105d09d at amd64_syscall+0x73d > #6 0xffffffff810328d0 at fast_syscall_common+0x101 > failed: 1 != 0 (1 != 0) [0.814s] > > # kyua test divert:ipdivert_ip_output_remote_success > divert:ipdivert_ip_output_remote_success -> panic: Duplicate free of > 0xfffff80003c3fa00 from zone 0xfffffe000a1d0000(mbuf) slab > 0xfffff80003c3ffd8(10) > cpuid = 3 > time = 1586710625 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0038476f70 > vpanic() at vpanic+0x182/frame 0xfffffe0038476fc0 > panic() at panic+0x43/frame 0xfffffe0038477020 > uma_dbg_free() at uma_dbg_free+0x1f2/frame 0xfffffe0038477060 > uma_zfree_arg() at uma_zfree_arg+0x130/frame 0xfffffe00384770b0 > m_free() at m_free+0xb9/frame 0xfffffe00384770e0 > m_freem() at m_freem+0x28/frame 0xfffffe0038477100 > div_send() at div_send+0x43c/frame 0xfffffe0038477170 > sosend_generic() at sosend_generic+0x44c/frame 0xfffffe0038477220 > sosend() at sosend+0x66/frame 0xfffffe0038477250 > kern_sendit() at kern_sendit+0x246/frame 0xfffffe00384772f0 > sendit() at sendit+0x1cc/frame 0xfffffe0038477340 > sys_sendto() at sys_sendto+0x4d/frame 0xfffffe0038477390 > amd64_syscall() at amd64_syscall+0x73d/frame 0xfffffe00384774b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00384774b0 > --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8007beeba, rsp = > 0x7fffffffdc68, rbp = 0x7fffffffdcb0 --- > KDB: enter: panic > > Best, > Li-Wen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6963991586714482>