warden: Maybe illumos.org/issues/17584 is related?

→ BUG 17584: Null pointer leading to a crash when using NAT66 (New)

And possibly illumos.org/issues/15555

→ BUG 15555: ipf: NULL pointer dereference in fr_tcp_age() / fr_movequeue() (New)

rzezeski: For the stack frame thing, illumos.org/issues/17585

→ FEATURE 17585: MDB should look past mutex_enter() and find the real stack frame (New)

jclulow: that looks like the same issue to me (17584), though based on warden's mdb I think I confirmed oifq != NULL, and that would suggest nifq is. Given the logic in fr_tcp_age() to derive nifq, I would not be surprised.

rzezeski: There is some mention of that being the case in 15555 too

that would be an annoying one to verify over IRC

It's almost certainly a race because we're not locking the thing

in some subset of cases

yea

I'm not sure why I've never seen this, I have a lot of ipf-based NAT stuff going on

But maybe it's because I don't allow IPv6 in the house

IPv6 does tend to find sharp edges in our code, though it's getting better

this was my first time looking into ipf code, and I'm sure there's history there but man this could really be cleaned up

looks like it was meant to compile from source in all sorts of different contexts

the macro-soup is certainly hard on the eyes

I wish I could win the lotto and spend all my time bringing up vxlnat^H^H^H^H^H^H knat. (The secret sauce is use of `conn_t`!)

rzezeski: you are correct regarding ipf's "single-source for all platforms" philosophy.

Sorry I didn’t replay sooner… we are in different TZ (CEST here) and this evening I has been away for a meeting

I confirm I’m using IPv6 and NAT too… it make sense for me that bugs referenced by jclulow are related to my issue

Tomorrow I’ll post info about my ipf configuration. Thanks to you all until now. Surely I’m with rzezeski: troubleshooting such a problem via IRC doesn’t look viable! :)