On ma, 2016-12-12 at 11:53 +0000, Chris Wilson wrote: > Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
kerneldoc speaks of forward-order, so better update that. > after drm_mm_scan_add_block() we can further simplify the list > manipulations when generating the temporary scan-hole. > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> <SNIP> > @@ -787,13 +783,8 @@ bool drm_mm_scan_add_block(struct drm_mm_scan *scan, > Â mm->scan_active++; > Â > Â hole = list_prev_entry(node, node_list); > - > - node->scanned_preceeds_hole = hole->hole_follows; > - hole->hole_follows = 1; > - list_del(&node->node_list); > - node->node_list.prev = &hole->node_list; > - node->node_list.next = &scan->prev_scanned_node->node_list; > - scan->prev_scanned_node = node; > + DRM_MM_BUG_ON(list_next_entry(hole, node_list) != node); > + __list_del_entry(&node->node_list); At least be explicit by adding a comment that we avoid poisoning the pointers to be able to unwind. > @@ -887,8 +878,8 @@ bool drm_mm_scan_remove_block(struct drm_mm_scan *scan, > Â node->mm->scan_active--; > Â > Â prev_node = list_prev_entry(node, node_list); > - > - prev_node->hole_follows = node->scanned_preceeds_hole; Comment might be in place here too; "node->node_list has been removed from the list but by carefully avoiding..." > + DRM_MM_BUG_ON(list_next_entry(prev_node, node_list) != > + Â Â Â Â Â Â list_next_entry(node, node_list)); > Â list_add(&node->node_list, &prev_node->node_list); > Â > Â return (node->start + node->size > scan->hit_start && I'm feeling bit uncanny about avoiding poisoning. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation
