devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).