Skip to content

Commit

Permalink
PM / devfreq: Teach lockdep about locking order
Browse files Browse the repository at this point in the history
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.

Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, but I've looked through the various callback
implementations and don't see anything obvious.  If it does trigger any
lockdep splats, those should be fixed.

Signed-off-by: Rob Clark <[email protected]>
  • Loading branch information
robclark authored and intel-lab-lkp committed Aug 22, 2023
1 parent d00b097 commit ce83b1e
Showing 1 changed file with 6 additions and 0 deletions.
6 changes: 6 additions & 0 deletions drivers/devfreq/devfreq.c
Original file line number Diff line number Diff line change
Expand Up @@ -817,6 +817,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
}

mutex_init(&devfreq->lock);

/* Teach lockdep about lock ordering wrt. shrinker: */
fs_reclaim_acquire(GFP_KERNEL);
might_lock(&devfreq->lock);
fs_reclaim_release(GFP_KERNEL);

devfreq->dev.parent = dev;
devfreq->dev.class = devfreq_class;
devfreq->dev.release = devfreq_dev_release;
Expand Down

0 comments on commit ce83b1e

Please sign in to comment.