linux-kernel - Re: drivers/base/core.c: about device_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Apr 2013 06:48:44 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Federico Vaga <federico.vaga@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Alessandro Rubini <rubini@...dd.com>
Subject: Re: drivers/base/core.c: about device_find_child() function

On Thu, Apr 11, 2013 at 01:52:36PM +0200, Federico Vaga wrote:
> Hello,
> 
> I'm using the function device_find_child() [drivers/base/core.c] to retrieve 
> a specific child of a device. I see that this function invokes 
> get_device(child) when a child matches. I think that this function must 
> return the reference to the child device without getting it.

No, it should not, otherwise the device could "disappear" at any moment,
and the caller who had the handle, would now have a stale pointer.

> The function's comment does not explicitly talk about an increment of the 
> refcount of the device. So, "man 9 device_find_child" and various derivative 
> webpages do not talk about this. The developer is not correctly informed 
> about this function, unless (s)he looks at the source code.

You are right, I would gladly take a patch adding that comment to the
function, can you send me one?

> I see that users of this function, usually, immediately do put_device() after 
> the call to device_find_child(), so it is not expected that a 
> device_find_child() does a get_device() on the found child.
> 
> 
>    Immediately does put_device():
>      drivers/firewire/core-device.c
>      drivers/rpmsg/virtio_rpmsg_bus.c
>      drivers/s390/kvm/kvm_virtio.c

That's correct.

>    They effectively need a get_device():
>      drivers/net/bluetooth/hci_sysfs.c
>      drivers/net/dsa/dsa.c

Please fix these.

>    Maybe bugged because they do not do put_device():
>      drivers/media/platform/s5p-mfc/s5p_mfc.c
>      drivers/tty/serial/serial_core.c
>    Probably I'm wrong on this and I do not find the associated put_device()

I think the serial core is correct, but I'll audit it, the media one
should be fixed as well.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/