On Wed, Jan 08, 2020 at 04:53:06PM +1100, Alexey Kardashevskiy wrote: > > > On 08/01/2020 15:20, Alexey Kardashevskiy wrote: > > > > > > On 07/01/2020 16:54, David Gibson wrote: > >> On Tue, Jan 07, 2020 at 03:44:35PM +1100, Alexey Kardashevskiy wrote: > >>> > >>> > >>> On 06/01/2020 15:19, David Gibson wrote: > >>>>> + > >>>>> +static uint32_t client_package_to_path(const void *fdt, uint32_t > >>>>> phandle, > >>>>> + uint32_t buf, uint32_t len) > >>>>> +{ > >>>>> + char tmp[256]; > >>>> > >>>> Fixed sized buffers are icky. You could either dynamically allocate > >>>> this based on the size the client gives, or you could use > >>>> memory_region_get_ram_ptr() to read the data from the tree directly > >>>> into guest memory. > >>> > >>> @len comes from the guest, I am really not comfortable with allocating > >>> whatever (broken) guest requested. And if I limit @len by 1024 or > >>> similar, then a fixed size buffer will do too, no? > >> > >> I see your point. Does this call have a way to report failure? In > >> that case you could outright fail the call if it requests too long a > >> length. > > > > It returns length which can be 0 to signal an error. > > > > but with this particular method the bigger problem is that I cannot know > > in advance the actual path length from fdt_get_path(). I could double > > the size until fdt_get_path() succeeded, just seems overkill here. > > > > Property names seem to be limited by 32: > > > >>> len("ibm,query-interrupt-source-number") > 33 > > Awesome. Oh well :(
Yeah, as I suspected. Also 'ibm,associativity-reference-points'. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature