kmemleak complaints in nvme PM

[Andy Lutomirski]

On Wed, Apr 12, 2017 at 7:47 PM, Rafael J. Wysocki <rjw at rjwysocki.net> wrote:
> On Wednesday, April 12, 2017 10:42:51 AM Andy Lutomirski wrote:
>> On Wed, Apr 12, 2017 at 10:29 AM, Christoph Hellwig <hch at lst.de> wrote:
>> > On Sun, Apr 09, 2017 at 03:47:35PM +0300, Sagi Grimberg wrote:
>> >> Hi folks,
>> >>
>> >> I got this kmemleak complaint [1] on nvme-loop (but I'm pretty
>> >> confident it should happen with any nvme transport).
>> >>
>> >> Initial code stare tells me that
>> >> dev_pm_qos_update_user_latency_tolerance() can (and usually will
>> >> in controller initializaion) allocate a dev_pm_qos_request, but I
>> >> didn't see a pairing free of that request.
>> >>
>> >> I'll try to find some time looking into it, but thought it might
>> >> be a good idea to throw it out here in the mean time...
>> >
>> > Seems like the only way to free dev->power.qos->latency_tolerance_req
>> > is to call dev_pm_qos_update_user_latency_tolerance with a negative
>> > val argument.  What an odd API..
>>
>> Greg and/or Rafael, what's the right way to fix this?  I would imagine
>> that the driver core should free pm_qos requests when the device goes
>> away, no?
>
> Yes, it should.
>

I don't see the bug.  dev_pm_qos_constraints_destroy() should take care of it.