kmemleak complaints in nvme PM

Andy Lutomirski luto at amacapital.net
Wed Apr 12 10:42:51 PDT 2017


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?

Also, I suspect this is all quite racy -- I don't see anything
preventing two user threads from writing to the sysfs fields at the
same time.



More information about the Linux-nvme mailing list