All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: naveen.osdev@gmail.com, u-boot@lists.u-boot-project.org
Subject: Re: [PATCH] bootstage: fix unchecked malloc and undersized buffer in bootstage_mark_code()
Date: Wed, 2 Sep 2026 10:31:46 -0600	[thread overview]
Message-ID: <20260902163146.GD1764417@bill-the-cat> (raw)
In-Reply-To: <CAFLszTi62jXxPw0zecRUu1jdGt5L1gM3SRtiLsov5TDvT2wtOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On Wed, Sep 02, 2026 at 06:29:48AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 1 Sept 2026 at 08:03, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Sep 01, 2026 at 07:47:36AM -0600, Simon Glass wrote:
> > > Hi Naveen,
> > >
> > > On 2026-09-01T10:23:25, Naveen Kumar Chaudhary <naveen.osdev@gmail.com> wrote:
> > > > bootstage: fix unchecked malloc and undersized buffer in bootstage_mark_code()
> > > >
> > > > bootstage_mark_code() allocated the label buffer without checking the
> > > > result and then dereferenced it, risking a NULL pointer crash on
> > > > allocation failure. The length calculation also failed to account for
> > > > the "," and ": " separators emitted by the snprintf() calls, so the
> > > > assembled string could be silently truncated. Additionally, when file
> > > > and func are NULL and linenum is -1, the buffer was passed on
> > > > uninitialized.
> > >
> > > Please rewrite in present tense per U-Boot / Linux convention, e.g.
> > > 'allocates the label buffer without checking the result', 'fails to
> > > account for', 'is passed on uninitialised'. This patch aims to change
> > > the current code.
> >
> > Hi Simon,
> >
> > As I said the other day, please stop telling people to rewrite their
> > commit messages when it's already clear and understandable. This simply
> > leads to confusion and frustration among our contributors.
> 
> Then do we need to change this?
> 
> https://docs.u-boot-project.org/en/latest/develop/sending_patches.html#commit-message-conventions

No, it's conventions and guidelines. One should do that. And if there's
no commit message, or there's barely anything in a commit message,
that's useful. But if someone wrote something, and what they wrote
matches what they did, that's what's important.

> Also, we could perhaps introduce an AGENTS.md file, so at least the AI
> assistants follow the guidelines?

AI assistants are a bad at writing commit messages to start with.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-09-02 16:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 10:23 [PATCH] bootstage: fix unchecked malloc and undersized buffer in bootstage_mark_code() Naveen Kumar Chaudhary
2026-09-01 13:47 ` Simon Glass
2026-09-01 14:03   ` Tom Rini
2026-09-02 12:29     ` Simon Glass
2026-09-02 16:31       ` Tom Rini [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=20260902163146.GD1764417@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=naveen.osdev@gmail.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.u-boot-project.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.