Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems

[Tejun Heo <tj@kernel.org>]

Hello, Gwendal.

On Fri, Jan 20, 2017 at 02:19:46PM -0500, Tejun Heo wrote:
> On Fri, Jan 20, 2017 at 12:08:10PM -0500, tedheadster wrote:
> > kobject_get(pata_legacy.1): ref=3++ (ata_tport_add:ata_host_register:ata_host_activate)
> > kobject_get(pata_legacy.1): ref=4++ (ata_tport_add:ata_host_register:ata_host_activate)
> > XXX kobject_get(pata_legacy.1): ref=5++ (kobject_add:device_add:ata_tport_add)
> > XXX kobject_put(pata_legacy.1): ref=6-- (device_del:ata_tport_delete:ata_host_detach)
> > XXX kobject_put(pata_legacy.1): ref=5-- (ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
> > XXX kobject_put(pata_legacy.1): ref=4-- (klist_put:klist_del:device_del)
> > XXX kobject_put(pata_legacy.1): ref=3-- (klist_devices_put:klist_put:klist_del)
> > XXX kobject_put(pata_legacy.1): ref=2-- (platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
> 
> So, three gets from the transport path but only two puts.  That seems
> to be the culprit.  Looking into it.

So, Matthew discovered that pata_legacy isn't releasing resources
after probe failure.  After some debugging, it turns out that the
transport code is taking three refs but only putting two preventing
the ata port from going away.

Can you please explain why the libata transport code is explicitly
pinning the parent device and then putting it in the release methods?
device_add/del() already gets and puts the parent, so I don't get why
this part is necessary.  Is this intentional?

Also, it looks like there is a ref leak on the transport device
itself.  Its release function never gets called and thus the parent
device (ata_port) stays pinned too.

Thanks.

-- 
tejun