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: <49E4D2FF.8090906@csr.com>
Date:	Tue, 14 Apr 2009 19:16:31 +0100
From:	David Vrabel <david.vrabel@....com>
To:	Greg KH <greg@...ah.com>
CC:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: device_for_each_child() before device_add() doesn't work

Greg KH wrote:
> On Tue, Apr 14, 2009 at 05:54:40PM +0100, David Vrabel wrote:
>> Calling device_for_each_child() on a device that has yet to be added
>> (with device_add()) used to work.  UWB subsystem currently tries to do this.
>>
>> Since "driver core: move klist_children into private structure"[1] this
>> no longer works (an oops occurs in device_for_each_chid()).  Is it
>> something that ought to work? Or should the UWB subsystem be changed to
>> not do this?
> 
> Why would you call device_for_each_child() if you have never added it to
> the bus?  How would you expect that to work, as there will never be any
> children for it?

The children of a UWB radio controller (RC) are it's neighbors.  When 
assigning a random DevAddr to an RC we need to check that the address is 
  unique within the beacon group.  We use device_for_each_child() here 
to check that the generated DevAddr is not used by any of its neighbors.

This address must be assigned during initialization and during normal 
operation and in the past we didn't need to special case the address 
assignment during initialization.

David
--
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