From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Luca Weiss <luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2] pylibfdt: add FdtRo.get_path()
Date: Wed, 26 Jan 2022 17:35:11 +1100 [thread overview]
Message-ID: <YfDrn0DT/IvQ4sGK@yekko> (raw)
In-Reply-To: <2266584.iZASKD2KPV@g550jk>
[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]
On Tue, Jan 25, 2022 at 07:36:17PM +0100, Luca Weiss wrote:
> Hi David,
>
> On Dienstag, 25. Jänner 2022 05:48:34 CET David Gibson wrote:
> > On Sat, Jan 22, 2022 at 11:56:54AM +0100, Luca Weiss wrote:
> > > Add a new Python method wrapping fdt_get_path() from the C API.
> > >
> > > Also add a test for the new method.
> > >
> > > Signed-off-by: Luca Weiss <luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
> > > ---
> > > Changes in v2:
> > > - dynamically increase size of string buffer until it fits.
> > >
> > > The values are chosen relatively arbitrary, and terminates at lengths
> > > over than 4096 as I don't expect paths to be longer and there should
> > > be an exit condition to not eat up RAM in case of some bug.
> > >
> > > pylibfdt/libfdt.i | 27 +++++++++++++++++++++++++++
> > > tests/pylibfdt_tests.py | 7 +++++++
> > > 2 files changed, 34 insertions(+)
> > >
> > > diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i
> > > index ac70762..d103bb6 100644
> > > --- a/pylibfdt/libfdt.i
> > > +++ b/pylibfdt/libfdt.i
> > >
> > > @@ -443,6 +443,28 @@ class FdtRo(object):
> > > """
> > > return fdt_get_alias(self._fdt, name)
> > >
> > > + def get_path(self, nodeoffset):
> > > + """Get the full path of a node
> > > +
> > > + Args:
> > > + nodeoffset: Node offset to check
> > > +
> > > + Returns:
> > > + Full path to the node
> > > +
> > > + Raises:
> > > + FdtException if the path is longer than 'size' or other error
> > > occurs + """
> > > + size = 64
> > > + while size < 4096:
> > > + ret, path = fdt_get_path(self._fdt, nodeoffset, size)
> > > + if ret == -NOSPACE:
> > > + size += 64
> > > + continue
> > > + check_err(ret)
> > > + return path
> > > + raise ValueError('Node path is unexpectedly long')
> >
> > Ah... sorry, this isn't quite what I had in mind. The idea of
> > resizing the buffer is to avoid having an arbitrary limit, but you
> > still have the 4096 byte arbitrary limit here. As Simon suggests, 4k
> > would probably be a good *starting* point, rather than an ending
> > point. Not only are repeated calls expensive in Python, but
> > fdt_get_path() itself is also quite expensive, since it needs to scan
> > the dtb from the start. I'd also suggest doubling the buffer size on
> > each attempt, rather than increasing linearly.
>
> I do think that there should be a limit *somewhere* instead of hitting OOM if
> there would be some bug in the underlying implementation or the file provided?
> I'm fine with limiting it at 100MB or whatever but I would rather have a limit
> there than not have it.
Well, it can never exceed the size of the whole dtb, structurally, so
I don't think it's really a problem.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-01-26 6:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-22 10:56 [PATCH v2] pylibfdt: add FdtRo.get_path() Luca Weiss
[not found] ` <20220122105653.31219-1-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2022-01-24 17:57 ` Simon Glass
[not found] ` <CAPnjgZ2Zj7gaT8G6WrVCKunVZgRMgef-rQLRhSRk9siR-f69DQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-01-24 20:43 ` Luca Weiss
2022-01-25 4:48 ` David Gibson
2022-01-25 18:36 ` Luca Weiss
2022-01-26 6:35 ` David Gibson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfDrn0DT/IvQ4sGK@yekko \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.