On Fri, Sep 29, 2023 at 11:19:52AM +0200, Wolfram Sang wrote: > Yang Yingliang reported a memleak: > === > > I got memory leak as follows when doing fault injection test: > > unreferenced object 0xffff888014aec078 (size 8): > comm "xrun", pid 356, jiffies 4294910619 (age 16.332s) > hex dump (first 8 bytes): > 31 2d 30 30 31 63 00 00 1-001c.. > backtrace: > [<00000000eb56c0a9>] __kmalloc_track_caller+0x1a6/0x300 > [<000000000b220ea3>] kvasprintf+0xad/0x140 > [<00000000b83203e5>] kvasprintf_const+0x62/0x190 > [<000000002a5eab37>] kobject_set_name_vargs+0x56/0x140 > [<00000000300ac279>] dev_set_name+0xb0/0xe0 > [<00000000b66ebd6f>] i2c_new_client_device+0x7e4/0x9a0 > > If device_register() returns error in i2c_new_client_device(), > the name allocated by i2c_dev_set_name() need be freed. As > comment of device_register() says, it should use put_device() > to give up the reference in the error path. > > === > I think this solution is less intrusive and more robust than he > originally proposed solutions, though. > > Reported-by: Yang Yingliang <yangyingliang@xxxxxxxxxx> > Closes: http://patchwork.ozlabs.org/project/linux-i2c/patch/20221124085448.3620240-1-yangyingliang@xxxxxxxxxx/ > Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> Applied to for-next, thanks!
Attachment:
signature.asc
Description: PGP signature