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]
Message-ID: <20130411134844.GA3489@kroah.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ