[PATCH 1/3] drm/ttm: fix ttm_bo_bulk_move_helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 31, 2018 at 05:17:33PM +0200, Christian König wrote:
> Am 31.08.2018 um 17:15 schrieb Michel Dänzer:
> >On 2018-08-31 3:10 p.m., Christian König wrote:
> >>Staring at the function for six hours, just to essentially move one line
> >>of code.
> >That sucks, but the commit log should describe what the problem was and
> >how this patch solves it.
> >
> >
> >>Signed-off-by: Christian König <christian.koenig at amd.com>
> >>---
> >>  drivers/gpu/drm/ttm/ttm_bo.c | 13 ++++++++-----
> >>  1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>index 35d53d81f486..138c98902033 100644
> >>--- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>@@ -250,15 +250,18 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
> >>  static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
> >>  				    struct list_head *lru, bool is_swap)
> >>  {
> >>+	struct list_head *list;
> >>  	LIST_HEAD(entries);
> >>  	LIST_HEAD(before);
> >>-	struct list_head *list1, *list2;
> >>-	list1 = is_swap ? &pos->last->swap : &pos->last->lru;
> >>-	list2 = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
> >>+	reservation_object_assert_held(pos->last->resv);
> >>+	list = is_swap ? &pos->last->swap : &pos->last->lru;
> >>+	list_cut_position(&entries, lru, list);
> >>+
> >>+	reservation_object_assert_held(pos->first->resv);
> >>+	list = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
> >>+	list_cut_position(&before, &entries, list);
> >So the problem was that the first list_cut_position call could result in
> >list2 pointing to la-la-land? Good catch!
> 
> Yes, exactly. Thought that would be obvious, but going to add that
> to the commit log.
> 
> Can I get a tested-by? You where much better at reproducing that than I'm.
> 

Michel, Christian, thanks so much to take care of this when I was on
vacation. And sorry to let you take a long time for finding the cause.

Is that because I didn't hold the resveration before cut the list from
position "first" and "last"? May I know in which cases, we must hold the
bo's reservation firstly?

Thanks,
Ray




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux