User Details
- User Since
- May 12 2014, 8:03 PM (360 w, 6 d)
Wed, Mar 24
I can confirm don't have any out-of-tree consumers of linuxkpi, so looks fine to me.
Feb 16 2021
Feb 14 2021
Feb 12 2021
Thanks for looking into this for me.
Feb 4 2021
Feb 3 2021
Feb 2 2021
Fix lock leak. Sorry, this review was based off of an
older version of my patch that didn't have that fixed.
I've confirmed that this is now in sync with what was
tested internally at $WORK
Feb 1 2021
Change the value of M_NORECLAIM to avoid the style issue
Fix overflap between new flag and count field
Jan 29 2021
Sorry about the delay in coming back to this; I've had to deal with a number of critical issues at work. I ported the patch that we tested internally to main and posted it to this review:
Jan 15 2021
sorry I got distracted by a different critical issue at work. Will be able to return to this next week
Jan 7 2021
This patch doesn't work. After the goto retry, nothing stops the cancelling thread from seeing state still in WORK_ST_CANCEL, and then the timer thread can come in and change it to TASK, causing the same bug.
I don't think that spinning is the right answer. That could hold the CPU that the callout needs to make progress, resulting in a livelock.
Dec 13 2020
Dec 9 2020
Removing the ability to create unnamed vlans is an unnecessary POLA violation. It can make sense for the user to establish a convention that vlanX is for vlan tag X, but we absolutely shouldn't bake that assumption into the kernel.
Nov 21 2020
Try putting entries in the witness_order_list_entry in kern/subr_witness.c specifying the ifnet_sx -> in_multi_sx ordering as correct. That should get better information. Likely the issue is a cycle of length larger than 2 (e.g. in_multi_sx before mystery lock, mystery lock before ifnet_sx, ifnet_sx before in_multi_sx).
Oct 20 2020
Aug 25 2020
Jul 3 2020
What's the status of this? We're hitting this problem very frequently at Isilon and this patch does fix the issue.
Jun 20 2020
Jun 18 2020
May 25 2020
Jan 24 2020
Jan 20 2020
Jan 10 2020
Jan 9 2020
Jan 7 2020
Jan 2 2020
Dec 21 2019
Dec 3 2019
Nov 26 2019
Oct 30 2019
Oct 23 2019
Oct 8 2019
I suspect that means that your BIOS pre-allocated enough bus numbers to the bridge to account for the VFs. Perhaps we should add a pcib method that recursively checks that a contiguous range of bus numbers is assigned to the bridge?
Oct 1 2019
Aug 27 2019
Oct 4 2018
Sep 19 2018
Jun 12 2018
May 17 2018
May 16 2018
May 7 2018
The message that I got at BSDCan last year is that they wanted to see at least a full IETF draft before these changes could be merged in, which is why my work on it stalled. Has people's position on this changed?
FWIW, I had a short email conversation with the writers of that draft about a year ago and they went radio silent pretty quickly. I assumed that they weren't working on it anymore.
Mar 19 2018
Mar 14 2018
Move non-fib test into separate test file
Mar 8 2018
Mar 7 2018
I've written some unit tests that covering these cases here:
Mar 5 2018
I don't think that this conversation is going to go anywhere productive. Do you have specific technical objection to raise about this change?
Uploaded the wrong test to this review; fixed now
Move route(8) tests to their own atf test file
Mar 1 2018
Add ATF test cases for IPv4/IPv6 subnet route migration
Feb 28 2018
Check for NULL pointers
Feb 21 2018
Feb 16 2018
Clarify manpage update as per rgrimes' suggestion
Fix the manpage to document that the gateway parameter is
optional for most route subcommands.