- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 12 2020
Jun 10 2020
Jun 9 2020
I'm also happy to just change the subr_stats.c code. Having RB_TREE and ARB_TREE bound tightly like this makes another RB_TREE change I'm considering impossible.
Jun 7 2020
Don't depend on anyone else's bool type.
Jun 6 2020
Remove redundant assignments.
Jun 5 2020
This change makes a newly inserted node black, not red, and lets RB_INSERT_COLOR make it red if it needs to be. So rb_link_node no longer needs to be concerned with redness - the default black color is correct. Nowhere else in sys/ is code that depend on rb_color, rb_is_red or rb_is_black, so delete them and the tree.h macros that had been defined to enable them.
Fix color in rb_link_node.
Fix indentation.
Jun 4 2020
Fix order of arguments in the RB_SET_COLOR invocation in rbtree.h.
Jun 3 2020
Replace "typeof" with "__typeof".
Restore COLOR in a way that linux compatibilty headers demand.
Correct an error in determining the redness of the successor of an interior node being deleted.
Jun 2 2020
Jun 1 2020
I apologize for failing to test for successful compilation.
Change the null test back to a redness test, in a way to encourage the compiler to skip the test when possible.
Discard the second part of the change and see if the first part is broken.
An assignment to black can be dropped in one case, but not the other, so fix that.
May 30 2020
May 27 2020
May 21 2020
May 18 2020
Use a local variable for RB_PARENT(old, field).
May 16 2020
May 15 2020
Feb 24 2020
Feb 23 2020
Feb 22 2020
This change makes the second argument to swp_pager_getswapspace redundant. A future change might as well eliminate it.
Feb 1 2020
In D23391#514739, @kib wrote:In D23391#514734, @dougm wrote:Subsequent testing by Peter appears to have absolved r357173 of blame, so I'm going ahead with this commit.
Do you mean that isci(4) was broken anyway ? Are any other drivers were reported as broken ?
Subsequent testing by Peter appears to have absolved r357173 of blame, so I'm going ahead with this commit.
Search abandoned. No evident bug here.
A complete undo. Not even comment and style changes get preserved. If this too leads to a test failure, then I consider r357173 absolved. If not, then I question my sanity.
Revert everything from the original patch except a comment, and a few places where null pointer checks had "!= NULL" added.
Redo. I left an extra AUGMENT hanging around. Undo iommu, undo delete, leave augment.
This time, revert the iommu changes. Leave the tree changes alone.
Change nothing but the parts of tree.h related to deletion, restoring those to their original implementation. Hope to find that udp test still passes.
Jan 31 2020
Undo those parts of r357173 made to sys/tree.h specifically intended to reduce code duplication in deletion, without undoing those parts specific to augmentation.
Jan 29 2020
Before I commit this patch, can you determine if the problem was present before or after r357173?
The lines added here were also in https://reviews.freebsd.org/D23189?id=66970 which passed this test, so I'm stumped at the moment.
Jan 28 2020
Jan 27 2020
Jan 26 2020
Restore the intel_gas changes that exploit RB_AUGMENT - the ones that eliminate the need to walk from leaf to root to update free_down, and the ones that eliminate the need to use RB_NEXT to update free_after fields. But don't change the topmost-fit search method of lowermatch, or use free_down to speed up uppermatch. The order in which the match functions consider entries is not changed.
Jan 24 2020
Jan 23 2020
Discard everything about x86/iommu/intel_* and just leave the tree.h changes, so that they don't get trapped in a discussion of other things.
Resolve conflicts.
Jan 22 2020
It seems harmless.
Jan 21 2020
Jan 20 2020
Jan 18 2020
Push the setting of a->entry->start down into dmar_gas_match_one. Add a documentary comment before that function.
Fix the upper limits passed to dmar_gas_match_one from dmar_gas_uppermatch.
Jan 17 2020
Stop sending the prev entry to dmar_gas_match_insert. I was sending the prev entry sometimes and the next entry sometimes, but the insert function was only using them for assertion checking anyway.
Update assertion code to test first and last, rather than free_after.
Rework intel_gas.c more than I had planned. Along with free_down, keep a first and last value for each entry describing the least and greatest value in the subtree rooted there. Update these in the augment routine. In lowermatch, look for the fit with greatest address less than the lowaddr, which I understand to be an upper bound on the address. In uppermatch, duplicate the lowermatch code, looking for the fit with least address greater than highaddr, which I understand to be a lower bound on the address.
Jan 16 2020
Correct the augmentation after RB_INSERT so that the newly inserted node is augmented too, before its parent.
In D23189#508661, @kib wrote:If RB_ code would do the walk, I am fine with it.
Did you tested this on a machine with DMAR enabled ? You may ask Peter, long-running high-load networking tests exercise the GAS allocator quite efficiently.
Jan 15 2020
Jan 2 2020
Add an important omitted line.
Jan 1 2020
Dec 31 2019
Dec 30 2019
Dec 29 2019
Yes I think it should be fixed by r355985. At least, the bug fixed in r355985 could cause this panic. This is a VMIO buffer and so should contain managed pages.
Dec 27 2019
Dec 22 2019
In D22897#501357, @pho wrote:With D22897.65888.diff I got this after 5 hours:
Dec 21 2019
Dec 20 2019
This approach has a fatal flaw. It may be impossible to distinguish parent from child without a complete search-from-root.