I think this should be ready to go- upstream has accepted it. Are you happy with it?
Um, what do you mean by that, @cem ?
Just get rid of this paragraph entirely, and the header in the sample
I've tested this overnight on a Netflix server running at 90G.
This looks like a generic issue to me.
This patch looks good to me from a technical point of view. I have no opinion on /boot/efi vs. /efi, so won't comment on the ultimate merits of the change, but you're welcome to include a "Reviewed by:" from me if this goes in.
The test appears to grep for "lagg_" in the LOR messages and there are two that match:
Lock order reversal between "in_multi_sx"(sx) and "if_lagg sx"(sx)! Lock order "in_multi_sx"(sx) -> "if_lagg sx"(sx) first seen at: #0 0xffffffff80c7bfcd at witness_checkorder+0x46d #1 0xffffffff80c17b17 at _sx_xlock+0x67 #2 0xffffffff826d1bf0 at lagg_ioctl+0xe0 #3 0xffffffff80d3026d at if_addmulti+0x3fd #4 0xffffffff80dbfbdd at in_joingroup_locked+0x27d #5 0xffffffff80dbf932 at in_joingroup+0x42 #6 0xffffffff80dba825 at in_control+0xa25 #7 0xffffffff80d30a38 at ifioctl+0x3d8 #8 0xffffffff80c824d9 at kern_ioctl+0x289 #9 0xffffffff80c8219a at sys_ioctl+0x12a #10 0xffffffff810bd629 at amd64_syscall+0x749 #11 0xffffffff8109010e at fast_syscall_common+0xf8
Lock order reversal between "in_control"(sx) and "if_lagg sx"(sx)! Lock order "in_control"(sx) -> "if_lagg sx"(sx) first seen at: #0 0xffffffff80c7bfcd at witness_checkorder+0x46d #1 0xffffffff80c17b17 at _sx_xlock+0x67 #2 0xffffffff826d19ee at lagg_init+0x2e #3 0xffffffff80d36c1e at ether_ioctl+0x1be #4 0xffffffff826d20e1 at lagg_ioctl+0x5d1 #5 0xffffffff80dba7dd at in_control+0x9dd #6 0xffffffff80d30a38 at ifioctl+0x3d8 #7 0xffffffff80c824d9 at kern_ioctl+0x289 #8 0xffffffff80c8219a at sys_ioctl+0x12a #9 0xffffffff810bd629 at amd64_syscall+0x749 #10 0xffffffff8109010e at fast_syscall_common+0xf8
Update after 0b7472b3d8d2f1e90fade5236b44fd98d8e396c2
Fixed with D21924 by marius