Page MenuHomeFreeBSD

hselasky (Hans Petter Selasky)
User

Projects

User Details

User Since
Nov 28 2014, 6:55 PM (237 w, 3 d)

Recent Activity

Today

D20630: ACPI support for USB , mainly hub. is now accepted and ready to land.

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

Mon, Jun 17, 6:58 PM
hselasky added inline comments to D20630: ACPI support for USB , mainly hub..
Mon, Jun 17, 6:55 PM

Fri, Jun 14

hselasky added inline comments to D20630: ACPI support for USB , mainly hub..
Fri, Jun 14, 9:55 AM

Thu, Jun 13

hselasky added inline comments to D20630: ACPI support for USB , mainly hub..
Thu, Jun 13, 4:22 PM
hselasky added a comment to D20630: ACPI support for USB , mainly hub..

^^^ only .c and .h files

Thu, Jun 13, 4:19 PM
hselasky added a comment to D20630: ACPI support for USB , mainly hub..
  1. This script should be run on every USB C- and H- file before
  2. commit to enforce correct style.

#

Thu, Jun 13, 4:19 PM

Wed, Jun 12

hselasky added a comment to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

@markj : Ping

Wed, Jun 12, 12:05 PM

Tue, Jun 11

hselasky committed rS348896: MFC r348797:.
MFC r348797:
Tue, Jun 11, 8:54 AM
hselasky committed rS348895: MFC r348797:.
MFC r348797:
Tue, Jun 11, 8:53 AM
hselasky committed rS348894: MFC r348797:.
MFC r348797:
Tue, Jun 11, 8:53 AM
hselasky committed rS348893: MFC r348797:.
MFC r348797:
Tue, Jun 11, 8:50 AM

Mon, Jun 10

hselasky committed rS348858: MFC r348631:.
MFC r348631:
Mon, Jun 10, 1:39 PM
hselasky committed rS348857: MFC r348631:.
MFC r348631:
Mon, Jun 10, 1:37 PM
hselasky committed rS348856: MFC r348631:.
MFC r348631:
Mon, Jun 10, 1:37 PM
hselasky committed rS348855: MFC r348631:.
MFC r348631:
Mon, Jun 10, 1:36 PM
hselasky committed rS348853: MFC r348604:.
MFC r348604:
Mon, Jun 10, 1:17 PM
hselasky committed rS348852: MFC r348604:.
MFC r348604:
Mon, Jun 10, 1:17 PM
hselasky committed rS348851: MFC r348604:.
MFC r348604:
Mon, Jun 10, 1:16 PM

Sun, Jun 9

hselasky committed rS348832: MFC r348603:.
MFC r348603:
Sun, Jun 9, 8:22 AM
hselasky committed rS348831: MFC r348603:.
MFC r348603:
Sun, Jun 9, 8:19 AM
hselasky committed rS348830: MFC r348603:.
MFC r348603:
Sun, Jun 9, 8:18 AM

Sat, Jun 8

hselasky committed rS348797: Fix for reading the configuration descriptor in libusb. Catch invalid.
Fix for reading the configuration descriptor in libusb. Catch invalid
Sat, Jun 8, 9:34 AM

Thu, Jun 6

hselasky added inline comments to D20293: ucom(4): synchronously execute param changes.
Thu, Jun 6, 6:53 PM
hselasky added a comment to D20293: ucom(4): synchronously execute param changes.
In D20293#443794, @ian 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.

Thu, Jun 6, 6:52 PM
hselasky added a comment to D20293: ucom(4): synchronously execute param changes.

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?

Thu, Jun 6, 6:33 PM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Update as per @markj 's comment.

Thu, Jun 6, 3:17 PM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Fix for buildworld.

Thu, Jun 6, 2:23 PM
hselasky added a comment to D20109: Need to wait for epoch callbacks to complete before detaching network interface.

Ping.

Thu, Jun 6, 10:06 AM
hselasky added inline comments to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.
Thu, Jun 6, 10:02 AM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Fix some style nits pointed out by @markj .

Thu, Jun 6, 9:57 AM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Address comments from @markj .

Thu, Jun 6, 9:51 AM
hselasky added inline comments to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.
Thu, Jun 6, 9:47 AM

Wed, Jun 5

hselasky added a comment to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

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

Wed, Jun 5, 11:41 AM

Tue, Jun 4

hselasky committed rS348631: In usb(4) fix a lost completion event issue towards libusb(3). It may happen.
In usb(4) fix a lost completion event issue towards libusb(3). It may happen
Tue, Jun 4, 4:40 PM
hselasky committed rS348604: In xhci(4) there is no stream ID in the completion TRB..
In xhci(4) there is no stream ID in the completion TRB.
Tue, Jun 4, 9:01 AM
hselasky committed rS348603: Make sure the DMA tags get freed in mlx5en(4)..
Make sure the DMA tags get freed in mlx5en(4).
Tue, Jun 4, 8:06 AM
hselasky added inline comments to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.
Tue, Jun 4, 7:04 AM

Mon, Jun 3

hselasky accepted D20502: Allocate wired pages in linux_alloc_pages()..

Looks good.

Mon, Jun 3, 5:08 PM

Wed, May 29

hselasky added a comment to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

@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.

Wed, May 29, 9:25 AM
hselasky added a comment to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

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

Wed, May 29, 9:22 AM
hselasky added a comment to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

@jtl: Can you please comment?

Wed, May 29, 7:34 AM

Sat, May 25

hselasky added a comment to D20109: Need to wait for epoch callbacks to complete before detaching network interface.

@jtl: Imagine the following scenario.

Sat, May 25, 10:00 AM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Address comment from @markj .

Sat, May 25, 9:44 AM
hselasky updated the diff for D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.

Address comments from @markj .

Sat, May 25, 9:41 AM
hselasky added inline comments to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.
Sat, May 25, 9:40 AM

Fri, May 24

hselasky added inline comments to D20080: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ() instead of an array.
Fri, May 24, 10:45 PM
hselasky abandoned D18041: LKPI updates for drm-v4.18.

Already committed or no longer applicable.

Fri, May 24, 10:42 PM
hselasky commandeered D18041: LKPI updates for drm-v4.18.
Fri, May 24, 10:41 PM
hselasky added a comment to D20109: Need to wait for epoch callbacks to complete before detaching network interface.

@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.

Fri, May 24, 10:41 PM
hselasky updated the diff for D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

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

Fri, May 24, 1:23 PM
hselasky added a comment to D18041: LKPI updates for drm-v4.18.

Is this patch still relevant?

Fri, May 24, 12:16 PM
hselasky added a comment to D20293: ucom(4): synchronously execute param changes.

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?

Fri, May 24, 11:44 AM
hselasky added a comment to D20293: ucom(4): synchronously execute param changes.

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

Fri, May 24, 7:04 AM

Thu, May 23

hselasky abandoned D20097: Fix regression issues after r346645 in the LinuxKPI.

Issues appear resolved.

Thu, May 23, 2:00 PM

Wed, May 22

hselasky accepted D20353: ipheth.4: Exaplain how to manually configure USB tethering on an Apple device.
Wed, May 22, 10:38 AM
hselasky added a comment to D20353: ipheth.4: Exaplain how to manually configure USB tethering on an Apple device.

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

Wed, May 22, 10:17 AM
hselasky accepted D20117: Restructure mbuf send tags to provide stronger guarantees..
Wed, May 22, 7:41 AM

Tue, May 21

hselasky added a comment to D20320: linuxkpi: allow M_EXEC flag for __vmalloc().

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

Tue, May 21, 8:01 AM

Mon, May 20

hselasky added a comment to D20320: linuxkpi: allow M_EXEC flag for __vmalloc().

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().

Mon, May 20, 10:44 AM
hselasky added a comment to D20320: linuxkpi: allow M_EXEC flag for __vmalloc().

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

Mon, May 20, 7:45 AM

May 18 2019

hselasky accepted D20293: ucom(4): synchronously execute param changes.

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

May 18 2019, 10:25 AM

May 17 2019

hselasky added a comment to D20109: Need to wait for epoch callbacks to complete before detaching network interface.

@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.

May 17 2019, 6:14 AM

May 16 2019

hselasky committed rS347883: MFC r347325:.
MFC r347325:
May 16 2019, 6:33 PM
hselasky committed rS347881: MFC r347324:.
MFC r347324:
May 16 2019, 6:29 PM
hselasky committed rS347880: MFC r347323:.
MFC r347323:
May 16 2019, 6:28 PM
hselasky committed rS347879: MFC r347322:.
MFC r347322:
May 16 2019, 6:27 PM
hselasky committed rS347877: MFC r347321:.
MFC r347321:
May 16 2019, 6:26 PM
hselasky committed rS347876: MFC r347320:.
MFC r347320:
May 16 2019, 6:25 PM
hselasky committed rS347875: MFC r347319:.
MFC r347319:
May 16 2019, 6:25 PM
hselasky committed rS347874: MFC r347318:.
MFC r347318:
May 16 2019, 6:24 PM
hselasky committed rS347873: MFC r347317:.
MFC r347317:
May 16 2019, 6:23 PM
hselasky committed rS347872: MFC r347316:.
MFC r347316:
May 16 2019, 6:23 PM
hselasky committed rS347871: MFC r347315:.
MFC r347315:
May 16 2019, 6:22 PM
hselasky committed rS347870: MFC r347314:.
MFC r347314:
May 16 2019, 6:21 PM
hselasky committed rS347869: MFC r347313:.
MFC r347313:
May 16 2019, 6:20 PM
hselasky committed rS347868: MFC r347312:.
MFC r347312:
May 16 2019, 6:19 PM
hselasky committed rS347867: MFC r347311:.
MFC r347311:
May 16 2019, 6:18 PM
hselasky committed rS347866: MFC r347310:.
MFC r347310:
May 16 2019, 6:17 PM
hselasky committed rS347865: MFC r347309:.
MFC r347309:
May 16 2019, 6:17 PM
hselasky committed rS347864: MFC r347308:.
MFC r347308:
May 16 2019, 6:16 PM
hselasky committed rS347863: MFC r347307:.
MFC r347307:
May 16 2019, 6:13 PM
hselasky committed rS347862: MFC r347306:.
MFC r347306:
May 16 2019, 6:13 PM
hselasky committed rS347861: MFC r347305:.
MFC r347305:
May 16 2019, 6:12 PM
hselasky committed rS347860: MFC r347304:.
MFC r347304:
May 16 2019, 6:11 PM
hselasky committed rS347859: MFC r347303:.
MFC r347303:
May 16 2019, 6:10 PM
hselasky committed rS347858: MFC r347302:.
MFC r347302:
May 16 2019, 6:09 PM
hselasky committed rS347857: MFC r347301:.
MFC r347301:
May 16 2019, 6:08 PM
hselasky committed rS347856: MFC r347300:.
MFC r347300:
May 16 2019, 6:08 PM
hselasky committed rS347855: MFC r347299:.
MFC r347299:
May 16 2019, 6:07 PM
hselasky committed rS347854: MFC r347298:.
MFC r347298:
May 16 2019, 6:06 PM
hselasky committed rS347853: MFC r347297:.
MFC r347297:
May 16 2019, 6:05 PM
hselasky committed rS347851: MFC r347295:.
MFC r347295:
May 16 2019, 6:02 PM
hselasky committed rS347850: MFC r347294:.
MFC r347294:
May 16 2019, 6:01 PM
hselasky committed rS347849: MFC r347293:.
MFC r347293:
May 16 2019, 6:01 PM
hselasky committed rS347847: MFC r347292:.
MFC r347292:
May 16 2019, 6:00 PM
hselasky committed rS347846: MFC r347291:.
MFC r347291:
May 16 2019, 5:59 PM
hselasky committed rS347845: MFC r347290:.
MFC r347290:
May 16 2019, 5:58 PM
hselasky committed rS347844: Fix minor compile issue after MFC r347288..
Fix minor compile issue after MFC r347288.
May 16 2019, 5:57 PM
hselasky committed rS347842: MFC r347289:.
MFC r347289:
May 16 2019, 5:51 PM
hselasky committed rS347841: MFC r347288:.
MFC r347288:
May 16 2019, 5:51 PM