Page MenuHomeFreeBSD

kp (Kristof Provost)
Troubleshooter

Projects

User Details

User Since
Sep 28 2014, 7:22 PM (321 w, 1 d)

Recent Activity

Yesterday

kp added inline comments to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.
Mon, Nov 23, 10:15 PM
kp added a comment to D27346: pf: Fix tag hashing.

Do you have a pointer to the syzcaller reproducer for this issue? I'd like to add a test.

Mon, Nov 23, 10:13 PM
kp added inline comments to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.
Mon, Nov 23, 5:50 PM

Sun, Nov 22

kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

Try putting entries in the witness_order_list_entry in kern/subr_witness.c specifying the ifnet_sx -> in_multi_sx ordering as correct. That should get better information. Likely the issue is a cycle of length larger than 2 (e.g. in_multi_sx before mystery lock, mystery lock before ifnet_sx, ifnet_sx before in_multi_sx).

Sun, Nov 22, 10:41 AM

Sat, Nov 21

kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

The more I look at this the more it looks like it's either flat out a witness bug, or witness not correctly expressing what's going on.

Sat, Nov 21, 3:49 PM

Fri, Nov 20

kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

Perhaps time to make sure entire kernel & all modules are built from scratch, without reusing old obj files, and without ccache -- just to make sure it's a clean slate?

Fri, Nov 20, 10:27 PM
kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

It's not clear to me where the other order is (i.e. where we take the multicast lock first, and then the ifnet lock).

Same... and WITNESS didn't record where the initial order happened, so it's not giving anything useful here.

Fri, Nov 20, 5:04 PM
kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

kldload pf; for i in $(seq 1 25); do kyua test -k /usr/tests/sys/netpfil/pf/Kyuafile names; done -- I consistently hit it within 5 iterations of this loop on a mostly idle system, usually within two or three. Normally it's after we've scribbled over something within the now-dead interface and I've triggered the panic in mtrash_ctor() w/ INVARIANTS on, but in the above backtrace it actually trapped instead since I had a little more activity going on.

Fri, Nov 20, 4:08 PM
kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

This is the classic race of ioctl handler vs. interface detachment.

Fri, Nov 20, 3:41 PM
kp updated the diff for D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

Remove now pointless do {} while(0) wrappers. While here also remove a stale comment.

Fri, Nov 20, 3:36 PM
kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

I'm still trying to track down what seems to be scribbling on freed memory when I run the pf:names test, but I note that it's also complaining about LOR ifnet_sx (vnet_if_return, though it points to the last line that dropped it?) -> in_multi_sx (in_ifdetach)

Fri, Nov 20, 3:31 PM
kp closed D27255: pf tests: Basic source tracking test.
Fri, Nov 20, 10:11 AM
kp committed rS367869: pf tests: Basic source tracking test.
pf tests: Basic source tracking test
Fri, Nov 20, 10:11 AM
kp closed D27254: pf: Fix incorrect assertion.
Fri, Nov 20, 10:09 AM
kp committed rS367867: pf: Fix incorrect assertion.
pf: Fix incorrect assertion
Fri, Nov 20, 10:08 AM
kp updated the diff for D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

Fix comment style(9)

Fri, Nov 20, 9:38 AM

Thu, Nov 19

kp accepted D25034: riscv: honor the environment set via the kernel config file.

I'm happy with it as-is.

Thu, Nov 19, 4:25 PM
kp added a comment to D27278: if: Remove ifnet_rwlock.

I'd like to be able to MFC D27279. I didn't expect it to rely on this patch, and I suspect this one can't be safely merged to stable/12 because it might break kernel ABI compatibility.

Thu, Nov 19, 3:57 PM
kp updated the diff for D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

Clarify comment

Thu, Nov 19, 3:44 PM
kp added inline comments to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.
Thu, Nov 19, 3:37 PM
kp added a comment to D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.

I'm not sure that this is actually safe, unfortunately... we're now holding an rwlock and may need to sleep to acquire an sx in, e.g., me_reassign() (via if_vmove -> ifp->if_reassign -> me_reassign) if someone created a cloner and moved it into the now-dying vnet.

if_vmove() probably actually needs to assert that it won't be recursing on the ifnet locks here.

Thu, Nov 19, 3:26 PM
kp requested review of D27279: if: Acquire ifnet lock when returning interfaces to their home vnet.
Thu, Nov 19, 1:55 PM
kp added a reviewer for D27278: if: Remove ifnet_rwlock: marieheleneka_gmail.com.
Thu, Nov 19, 1:54 PM
kp requested review of D27278: if: Remove ifnet_rwlock.
Thu, Nov 19, 1:53 PM

Tue, Nov 17

kp requested review of D27255: pf tests: Basic source tracking test.
Tue, Nov 17, 4:30 PM
kp requested review of D27254: pf: Fix incorrect assertion.
Tue, Nov 17, 4:30 PM

Sun, Nov 15

kp committed rS367706: MFC r366500:.
MFC r366500:
Sun, Nov 15, 11:56 AM
kp committed rS367705: bridge: epoch-ification.
bridge: epoch-ification
Sun, Nov 15, 11:46 AM

Wed, Nov 4

kp added a comment to D27018: Duplicate frames only once when using dup-to pf rule.
In D27018#604255, @kp wrote:

Also, it appears to panic:
...
It looks like this happens because we enqueue an mbuf and free it later. ip_input() has an mbuf pointer to a freed mbuf here.

Oh, I missed it... I'll have a look at it, how do you produce this panic? Do you know if the mbuf pointer of ip_input() corresponds to the real one or the dupliacted one?

Wed, Nov 4, 1:03 PM

Tue, Nov 3

kp accepted D27023: igmp: convert igmpstat to use PCPU counters.
Tue, Nov 3, 10:21 PM
kp added inline comments to D27023: igmp: convert igmpstat to use PCPU counters.
Tue, Nov 3, 8:09 PM
kp added a comment to D27018: Duplicate frames only once when using dup-to pf rule.

Also, it appears to panic:

Tue, Nov 3, 3:18 PM
kp added a comment to D27018: Duplicate frames only once when using dup-to pf rule.

I can reproduce the problem at least. I'll see if I can get a sane test case out of it as well.

Tue, Nov 3, 2:49 PM

Mon, Nov 2

kp accepted D27060: ifconfig: properly detect invalid mediaopt keywords..
Mon, Nov 2, 9:11 PM

Fri, Oct 30

kp added a comment to D27023: igmp: convert igmpstat to use PCPU counters.
In D27023#602923, @kp wrote:

What else in the kernel wants to have access to this information?

Nothing yet. NetApp has a module that aggregates stats from various protocols, so that's where this patch is coming from. It would seem that a read-only copy is enough for this use-case, if that's your concern.

I was mostly just wondering. If I'd noticed the inverse (i.e. V_igmpstat is in the header but used nowhere else) I'd be inclined to reverse that. Generally you want as little visibility for your data as possible.
It may be worth adding a comment here to explain why it's in the header.

Fri, Oct 30, 7:42 PM
kp added a comment to D27023: igmp: convert igmpstat to use PCPU counters.

What else in the kernel wants to have access to this information?

Fri, Oct 30, 6:18 PM
kp added a comment to D27018: Duplicate frames only once when using dup-to pf rule.

Can you describe a setup that demonstrates the problem this fixes?
(Ideally in the form of a test case, but if you can describe a setup I can probably write the test case.)

Fri, Oct 30, 2:29 PM

Wed, Oct 28

kp accepted D26990: Optimize set_syscall_retval for riscv.

Do we see measurable performance improvements with this?

Wed, Oct 28, 9:47 PM

Tue, Oct 27

kp committed rS367078: riscv: Minor cleanup in startup code.
riscv: Minor cleanup in startup code
Tue, Oct 27, 12:44 PM

Mon, Oct 26

kp accepted D26953: riscv: add support for SBI legacy replacement functions.
Mon, Oct 26, 3:00 PM
kp committed rS367058: MFC r366648:.
MFC r366648:
Mon, Oct 26, 1:24 PM
kp committed rS367057: MFC r366667:.
MFC r366667:
Mon, Oct 26, 1:24 PM
kp committed rS367056: MFC r366647:.
MFC r366647:
Mon, Oct 26, 1:23 PM
kp added a comment to D26953: riscv: add support for SBI legacy replacement functions.

Other than the incorrect comparison in the assertion I think this is good to go.

Mon, Oct 26, 8:34 AM

Sun, Oct 25

kp accepted D26952: riscv: remove sbi_clear_ipi().
Sun, Oct 25, 10:31 PM

Oct 24 2020

kp added inline comments to D26918: riscv: improve exception code names.
Oct 24 2020, 3:44 PM
kp accepted D26918: riscv: improve exception code names.

Thank you for making the pun.

Oct 24 2020, 3:38 PM

Oct 20 2020

kp accepted D26858: Move list_cloners to libifconfig.
Oct 20 2020, 3:47 PM

Oct 19 2020

kp accepted D26858: Move list_cloners to libifconfig.

I love to see more ifconfig code move into libifconfig.

Oct 19 2020, 1:59 PM

Oct 18 2020

kp accepted D26797: Shutting down doesn't destroy cloned interfaces.
Oct 18 2020, 1:19 PM

Oct 15 2020

kp accepted D26795: [pfctl_tests] Add missing void to empty function declaration.
Oct 15 2020, 6:06 AM

Oct 14 2020

kp accepted D26779: Rewrite pfctl_test in C to reduce testsuite run time.

Other than the file name nit I think this can go in.

Oct 14 2020, 5:16 PM
kp added a comment to D26779: Rewrite pfctl_test in C to reduce testsuite run time.

Yeah, the errno made the difference. The tests pass now (and quite a lot faster than before).

Oct 14 2020, 5:12 PM
kp added a comment to D26779: Rewrite pfctl_test in C to reduce testsuite run time.

Simple /usr/tests/sbin/pfctl % sudo kyua test (So I start kyua in the /usr/tests/sbin/pfctl directory)

Oct 14 2020, 4:30 PM
kp added a comment to D26779: Rewrite pfctl_test in C to reduce testsuite run time.

I've not yet looked into the why, but this seems to fail for me:

Oct 14 2020, 4:24 PM

Oct 13 2020

kp committed rS366667: pf: do not remove kifs that are referenced by rules.
pf: do not remove kifs that are referenced by rules
Oct 13 2020, 11:04 AM

Oct 12 2020

kp committed rS366648: pf tests: Test that 'set skip on <group>' works on new group members.
pf tests: Test that 'set skip on <group>' works on new group members
Oct 12 2020, 12:41 PM
kp closed D26742: pf: Create a kif for flags.
Oct 12 2020, 12:40 PM
kp committed rS366647: pf: create a kif for flags.
pf: create a kif for flags
Oct 12 2020, 12:40 PM
kp added inline comments to D26742: pf: Create a kif for flags.
Oct 12 2020, 7:03 AM

Oct 11 2020

kp requested review of D26742: pf: Create a kif for flags.
Oct 11 2020, 7:57 PM

Oct 9 2020

kp accepted D26607: riscv pmap: zero reserved pte bits in ppn for l2 leaf entries, too.
Oct 9 2020, 9:46 AM · riscv

Oct 7 2020

kp accepted D26698: Remove yet another useless assignment.
Oct 7 2020, 12:20 PM

Oct 6 2020

kp closed D26418: bridge: Call member interface ioctl() without NET_EPOCH.
Oct 6 2020, 7:20 PM
kp committed rS366500: bridge: call member interface ioctl() without NET_EPOCH.
bridge: call member interface ioctl() without NET_EPOCH
Oct 6 2020, 7:20 PM
kp accepted D26694: Don't use critical section when calling intr_irq_handler().
Oct 6 2020, 5:41 PM

Oct 5 2020

kp added a comment to D26537: devfs.rules: unhide pf in vnet jails.
In D26537#591054, @bz wrote:

We'll probably want to add more of these in the future for vnets, so happy we start to lay the grounds.
Will you work on jail/jail.conf to also pick the right set for devfs depending on whether the vnet option is given? If not you should given @jamie a ping6.

Oct 5 2020, 7:28 PM
kp closed D26537: devfs.rules: unhide pf in vnet jails.
Oct 5 2020, 7:27 PM
kp committed rS366461: devfs.rules: unhide pf in vnet jails.
devfs.rules: unhide pf in vnet jails
Oct 5 2020, 7:27 PM
kp accepted D26671: riscv: De-Arm a couple of names.
Oct 5 2020, 12:33 PM
kp accepted D26671: riscv: De-Arm a couple of names.

You missed the opportunity for a disarming pun.

Oct 5 2020, 12:27 PM

Oct 3 2020

kp retitled D26418: bridge: Call member interface ioctl() without NET_EPOCH from bridge: Do not enter NET_EPOCH in bridge_ioctl() to bridge: Call member interface ioctl() without NET_EPOCH.
Oct 3 2020, 3:42 PM
kp updated the diff for D26418: bridge: Call member interface ioctl() without NET_EPOCH.

bridge: Call member interface ioctl() without NET_EPOCH

Oct 3 2020, 3:42 PM

Oct 2 2020

kp committed rS366355: riscv: handle access faults in user mode.
riscv: handle access faults in user mode
Oct 2 2020, 7:30 AM
kp closed D26621: riscv: Handle access faults in user mode.
Oct 2 2020, 7:30 AM

Oct 1 2020

kp closed D26622: riscv: Add memmmap so we can mmap /dev/mem.
Oct 1 2020, 3:05 PM
kp committed rS366315: riscv: Add memmmap so we can mmap /dev/mem.
riscv: Add memmmap so we can mmap /dev/mem
Oct 1 2020, 3:05 PM
kp added a comment to D26544: riscv: Panic on PMP errors.

Should we be doing something for user load/store/fetch faults? Probably a SIGBUS?

Oct 1 2020, 8:35 AM
kp requested review of D26622: riscv: Add memmmap so we can mmap /dev/mem.
Oct 1 2020, 8:34 AM
kp requested review of D26621: riscv: Handle access faults in user mode.
Oct 1 2020, 8:34 AM

Sep 30 2020

kp committed rS366284: riscv: Panic on PMP errors.
riscv: Panic on PMP errors
Sep 30 2020, 8:24 AM
kp closed D26544: riscv: Panic on PMP errors.
Sep 30 2020, 8:24 AM

Sep 27 2020

kp updated the diff for D26544: riscv: Panic on PMP errors.

Hopefully correct patch

Sep 27 2020, 3:55 PM
kp updated the diff for D26544: riscv: Panic on PMP errors.

Update panic message

Sep 27 2020, 3:54 PM

Sep 24 2020

kp added a comment to D26544: riscv: Panic on PMP errors.

Those would also be unrecoverable errors, right?

Sep 24 2020, 11:43 AM
kp added a comment to D26537: devfs.rules: unhide pf in vnet jails.
In D26537#590825, @bz wrote:

Did we ever fix this one?

https://www.openbsd.org/errata48.html
005: SECURITY FIX: December 17, 2010 All architectures
Insufficent initialization of the pf rule structure in the ioctl handler may allow userland to modify kernel memory. By default root privileges are needed to add or modify pf rules.

https://ftp.openbsd.org/pub/OpenBSD/patches/4.8/common/005_pf.patch

Sep 24 2020, 11:37 AM
kp requested review of D26544: riscv: Panic on PMP errors.
Sep 24 2020, 10:54 AM

Sep 23 2020

kp requested review of D26537: devfs.rules: unhide pf in vnet jails.
Sep 23 2020, 7:14 PM

Sep 22 2020

kp accepted D26501: RISC-V: build SiFive drivers and DTB in GENERIC.
Sep 22 2020, 6:33 AM

Sep 21 2020

kp added inline comments to D26501: RISC-V: build SiFive drivers and DTB in GENERIC.
Sep 21 2020, 7:49 AM

Sep 18 2020

kp added a comment to D26474: Fix potential a dereference of a null value.

It looks like that call to icmp6_error() is no longer present: https://reviews.freebsd.org/rS364982

Sep 18 2020, 11:09 AM

Sep 12 2020

kp requested review of D26418: bridge: Call member interface ioctl() without NET_EPOCH.
Sep 12 2020, 10:06 PM
kp accepted D26417: pfctl_test: avoid 200 calls to atf_get_srcdir.
Sep 12 2020, 8:09 PM
kp committed rS365669: MFC r365457:.
MFC r365457:
Sep 12 2020, 6:58 PM
kp committed rS365659: MFC r365457:.
MFC r365457:
Sep 12 2020, 12:45 PM

Sep 11 2020

kp closed D26389: dtrace: Fix fbt return probes on RISC-V.
Sep 11 2020, 9:16 AM
kp committed rS365626: dtrace: fix fbt return probes on RISC-V.
dtrace: fix fbt return probes on RISC-V
Sep 11 2020, 9:16 AM

Sep 10 2020

kp updated the diff for D26389: dtrace: Fix fbt return probes on RISC-V.
  • Return a1 as well as it can sometimes be used for return values.
  • Set rtval to 0 because it's never used. Remove it as an argument for dtrace_invop().
Sep 10 2020, 6:01 PM
kp added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.
In D26389#586875, @kp wrote:

An alternative might be to pass a1 (as opposed to the 0 we pass now) in the return dtrace_probe(). That'll let scripts access it as arg2. That'd be different from all other platforms, but arg2 is not defined for the return probe anyway.

So this:

Sep 10 2020, 3:22 PM
kp updated the diff for D26389: dtrace: Fix fbt return probes on RISC-V.

Use trapframe rather than rval

Sep 10 2020, 3:21 PM