Page MenuHomeFreeBSD

Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array
ClosedPublic

Authored by hselasky on Apr 27 2019, 3:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 29, 10:56 AM
Unknown Object (File)
Mon, Mar 18, 9:38 AM
Unknown Object (File)
Feb 28 2024, 6:50 AM
Unknown Object (File)
Jan 29 2024, 5:52 PM
Unknown Object (File)
Jan 26 2024, 12:31 PM
Unknown Object (File)
Jan 26 2024, 12:31 PM
Unknown Object (File)
Jan 26 2024, 12:31 PM
Unknown Object (File)
Jan 26 2024, 12:27 PM
Subscribers

Details

Summary

Using an array to keep track of multicast memberships introduce multiple races if the APIs are exercised in parallell. Moving state structures around in memory when new members are removed makes debugging more difficult. By using a STAILQ() the memory location of the IPv4 and IPv6 multicast filters become fixed and use after free issues will be more easy to track.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 24725

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@pho : Please re-test this patch with D20109 applied at the same time as this one!

Address assert found by @pho by applying proper lock.

@pho : Please re-test this patch with D20109 applied at the same time as this one!

I'm a bit low on free test H/W. I'll see what I can do tomorrow.

@pho: OK , just make sure you grab the latest D20080 and D20109 !

For those that review: The IPv4 changes are almost identical to the IPv6 changes! Only different structures with different name.

I ran the two multicast tests I have repeatedly with D20080.56996.diff and D20109.56998.diff.
No problems seen.

sys/netinet/in_mcast.c
343

Extre newline.

sys/netinet/in_var.h
270

Indeed, I can't see why one of the _FOREACH macros cannot be used.

sys/netinet6/in6_mcast.c
2303

Is this supposed to be IN6_MULTI_LOCK()? Note that we lock it further below.

sys/netpfil/pf/if_pfsync.c
2379–2380

We should probably assert that imo_head is empty following the removal?

2403

We should wrap this in a helper routine.

sys/netinet6/in6_mcast.c
2303

Yes, you're right. I'll update the patch tomorrow.

hselasky added inline comments.
sys/netinet/in_var.h
270

Fixed in next patch revision.

sys/netpfil/pf/if_pfsync.c
2379–2380

We might just loop here. I'll fix in next patch revision.

2403

Will be fixed in next patch version.

hselasky marked 3 inline comments as done.

Address comments from @markj .

sys/netinet/in_mcast.c
2429

Might as well switch it to bool and write !is_final.

sys/netinet/in_var.h
242

Why did you make this a typedef?

248

I can't see why all of this stuff is here and not in ip_var.h. There are some consumers that do not include ip_var.h, but they can be fixed. At least, there should be a comment here or in in_var.h explaining the relationship.

sys/netpfil/pf/if_pfsync.c
1397

Missing space after the last comma.

sys/netinet/in_mcast.c
1596

There is a LOR here. We hold the non-sleepable inp lock at this point.

sys/netinet/in_mcast.c
98

@markj: The locking order is described here. Can you show a witness warning with the LOR?

sys/netinet/in_mcast.c
98

I haven't tried to reproduce it yet. In the code I referenced, we acquire the inp wlock, followed by the in_multi lock.

@markj: I will have a look at your comments and respond with a new patch. I'm currently a bit busy.

sys/netinet/in_mcast.c
1596

I can probably move this locking a bit earlier to resolve that.

hselasky added inline comments.
sys/netinet/in_var.h
242

To make future changes easier, like changing the queue type.

hselasky marked an inline comment as done.

Fix some style nits pointed out by @markj .

sys/netinet/in_var.h
248

Can you explain a bit more? I believe I've already tried this and that is the reason for the #ifdef _NETINET_IN_VAR_H_ I've added. The structures must be defined in the correct order, because not always we use pointers. Else the order wouldn't matter.

sys/netinet/in_var.h
242

Just write STAILQ_HEAD(in_mfilter_head, in_mfilter). Then you get a struct in_mfilter_head and you can change the queue type easily.

hselasky marked an inline comment as done.

Update as per @markj 's comment.

sys/netinet/in_var.h
244

Style: extra space after '*'.

245

The naming is kind of weird IMO. Usually we would call these ip_mfilter_alloc(), ip_mfilter_free(), IP_MFILTER_FOREACH, etc..

248

Doesn't this suggest that we should not expose the mfilter list accessors directly but instead define them in a C file as functions on a ip_moptions structure?

sys/netinet/ip_carp.c
1476

This line is too long, ditto below.

sys/netinet6/in6_var.h
649

I think it would be a bit simpler to just store a count of the filters in the moptions structure.

sys/netpfil/pf/if_pfsync.c
2351

This line is too long.

Address comments from @markj .

sys/netinet/in_var.h
248

Can we leave this AS-IS for now, hence it is most compatible with the old way of doing things. And then later we can move things around which also will produce more diffs?

sys/netinet6/in6_var.h
649

The STAILQ() is already traversed several times, so there is no real benefit of keeping a separate counter. Can this change be made separately later on?

sys/netpfil/pf/if_pfsync.c
2351

Fixed.

hselasky marked 3 inline comments as done.

Address comments from @markj .

I have no objection to the latest diff, but IMO the conversion from arrays to an STAILQ should be done in a way that does not require conditional definition of struct ip_moptions in ip_var.h.

sys/netinet/in_var.h
248

I have no objection to the current diff aside from the one nit, but I would have found this diff easier to review if the conversion from an array to STAILQ was done in a separate diff.

sys/netinet6/in6_var.h
645

Should be IP6_MFILTER_FOREACH.

This revision is now accepted and ready to land.Jun 19 2019, 6:14 PM
hselasky added inline comments.
sys/netinet/in_var.h
248

OK

hselasky marked an inline comment as done.

Fix naming of multicast foreach.

This revision now requires review to proceed.Jun 19 2019, 8:41 PM

Please ACK. Patch will be submitted tomorrow after some additional build testing.

@markj: Thank you for spending time reviewing this patch.

sys/netinet/ip_var.h
98

I meant to note earlier that imo_epoch_ctx appears to be unused.

Remove unused epoch contexts as suggested by @markj .

This revision is now accepted and ready to land.Jun 21 2019, 4:46 PM