- User Since
- Nov 28 2014, 6:55 PM (237 w, 3 d)
Fix the last few comments I've added and this is ready to go.
Fri, Jun 14
Thu, Jun 13
^^^ only .c and .h files
- This script should be run on every USB C- and H- file before
- commit to enforce correct style.
Wed, Jun 12
@markj : Ping
Tue, Jun 11
Mon, Jun 10
Sun, Jun 9
Sat, Jun 8
Thu, Jun 6
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.
Fix some style nits pointed out by @markj .
Address comments from @markj .
Wed, Jun 5
@markj: I will have a look at your comments and respond with a new patch. I'm currently a bit busy.
Tue, Jun 4
Mon, Jun 3
Wed, May 29
@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?
Sat, May 25
@jtl: Imagine the following scenario.
Address comment from @markj .
Address comments from @markj .
Fri, May 24
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?
Thu, May 23
Issues appear resolved.
Wed, May 22
Should you mention something about permanent quirks in /boot/loader.conf via usb_quirk.ko ?
Tue, May 21
The LinuxKPI is there to be able to compile 95% of the linux code :-) The rest must be patched.
Mon, May 20
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() ?
May 18 2019
Just make sure that ucom_param() won't race when you drop the lock.
May 17 2019
@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.