From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Daniel Palmer <daniel@0x0f.com>
Cc: alison.wang@nxp.com, angelo@kernel-space.org, trini@konsulko.com,
me@ziyao.cc, jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com,
u-boot@lists.denx.de
Subject: Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
Date: Mon, 29 Dec 2025 21:44:42 +0800 [thread overview]
Message-ID: <aVKFyqkgt_n_4qX7@google.com> (raw)
In-Reply-To: <CAFr9PXkk_eVwFG4SA1BCB_S+kUoJHPSdsOJZK5bXB+=_an91Mw@mail.gmail.com>
Hi Daniel,
On Mon, Dec 29, 2025 at 10:42:54AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Mon, 29 Dec 2025 at 04:13, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > >
> > > One thing I found when I did the bootinfo parsing in my version is if
> > > I corrupted (during relocation etc) the bootinfo this type of loop
> > > would often get stuck forever.
> > > I'm not sure what the technical limit of the number of bootinfo
> > > entries is but bounding this to something reasonable feels like a good
> > > idea.
> >
> > In that scenario, I assume the correct error handling would be to add a
> > loop limit and trigger a panic() if exceeded?
>
> Yeah I think so, if you didn't find the last bootinfo entry within
> some reasonable bounds everything is probably broken and you shouldn't
> continue.
> I think for most real machines (Amiga etc) there aren't many entries
> but for the virt machine maybe there is an entry per virtio mmio
> device so there might actually be a lot of them there.
So the problem becomes determining a reasonable limit.
I think we can safely assume the bootinfo buffer won't exceed a 4KB
page size. Since the minimum record size is 4 bytes (tag + size),
setting the maximum records to 4096 / 4 =1024 should be a safe
assumption?
Regards,
Kuan-Wei
next prev parent reply other threads:[~2025-12-29 14:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 1/4] serial: Add Goldfish TTY driver Kuan-Wei Chiu
2025-12-27 2:07 ` Yao Zi
2025-12-27 14:06 ` Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 2/4] m68k: Add support for M68040 CPU Kuan-Wei Chiu
2025-12-28 1:28 ` Daniel Palmer
2025-12-28 19:29 ` Kuan-Wei Chiu
2025-12-29 1:54 ` Daniel Palmer
2025-12-29 13:27 ` Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 3/4] board: Add QEMU m68k virt board support Kuan-Wei Chiu
2025-12-28 1:16 ` Daniel Palmer
2025-12-28 19:13 ` Kuan-Wei Chiu
2025-12-29 1:42 ` Daniel Palmer
2025-12-29 13:44 ` Kuan-Wei Chiu [this message]
2025-12-31 3:20 ` Daniel Palmer
2025-12-26 17:54 ` [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine Kuan-Wei Chiu
2025-12-26 18:09 ` Tom Rini
2025-12-26 18:57 ` Kuan-Wei Chiu
2025-12-26 18:59 ` Tom Rini
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=aVKFyqkgt_n_4qX7@google.com \
--to=visitorckw@gmail.com \
--cc=alison.wang@nxp.com \
--cc=angelo@kernel-space.org \
--cc=daniel@0x0f.com \
--cc=eleanor15x@gmail.com \
--cc=jserv@ccns.ncku.edu.tw \
--cc=me@ziyao.cc \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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