Looks good.

Don't forget to MFC.

Remove unused epoch contexts as suggested by @markj .

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

Fix naming of multicast foreach.

Address comments from @markj .

Address comments from @markj .

Fix the last few comments I've added and this is ready to go.

^^^ only .c and .h files

2. This script should be run on every USB C- and H- file before
3. commit to enforce correct style.

#

@markj : Ping

In D20293#443794, @ian wrote:

In D20293#443792, @hselasky wrote:

I understand you want synchronous behaviour, but how about implementing a drain command, which is called unlocked from the TTY layer, just before the end of the IOCTL return. Won't that fix the problems you see?

I don't understand what you're saying at all. It's just a normal sane expectation that open/close/read/write/ioctl calls all behave synchronously, and it's especially imporant in serial comms where there is interaction between the read/write data and the other calls that configure the comms or manipulate line state. Also, I've never seen anything documented in relation to ttydevsw that even hints that it's okay to return before the action is complete.

I understand you want synchronous behaviour, but how about implementing a drain command, which is called unlocked from the TTY layer, just before the end of the IOCTL return. Won't that fix the problems you see?

Update as per @markj 's comment.

Fix for buildworld.

Ping.

Fix some style nits pointed out by @markj .

Address comments from @markj .

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

Looks good.

@jtl: Given that we don't have a significant number of panics in this area, I don't see a problem just freeing the fragments. I.E. the current behaviour leads to a panic if a fragment is leftover from an interface. This is only done when interfaces are destroyed and does not affect LINK-flapping.

@kbowling : This is what the previous version of this patch does.

@jtl: Can you please comment?

@jtl: Imagine the following scenario.

Address comment from @markj .

Address comments from @markj .

Already committed or no longer applicable.

@jtl: The refcount approach is not insufficient. We can do both ways, only that the synchronous approach is more safe-playing in my opinion and it is not that expensive and doesn't need additional checking in the multicast deferred destruction code-path for NULL pointers and destroyed resources, which the refcount approach will require.

Fix according to input from @jtl . Set rcvif to NULL when a network interface vanishes.

Is this patch still relevant?

The part that runs off the USB process threads is fine. But what contexts can ucom_param() be called from. Is there any chance of race here?

What happens if there are two threads calling the function where you drop the lock?

Issues appear resolved.

Should you mention something about permanent quirks in /boot/loader.conf via usb_quirk.ko ?

The LinuxKPI is there to be able to compile 95% of the linux code :-) The rest must be patched.

I mean just add a new function for these special allocations and then patch the Linux code. That way we don't need to evaluate the "other" argument for __vmalloc().

Is this variant frequently used? Why not create a new inline function for this: __vmalloc_exec() ?

Just make sure that ucom_param() won't race when you drop the lock.

@glebius: Multicast destruction is deferred. When we destroy a multicast address we need to call the if_ioctl of the belonging network interface to remove any multicast addresses. That's the problem. I think draining is a good way to implement a safe solution instead of using refcounts. Then we ensure that the ifnet is in a certain state when the multicast destruction callbacks are invoked.