All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>,
	Borislav Petkov <bp@kernel.org>,
	linux-edac <linux-edac@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] EDAC/mce_amd: Do not print a stray newline
Date: Fri, 14 Aug 2026 09:43:07 -0400	[thread overview]
Message-ID: <20260814134307.GA1650@yaz-khff2.amd.com> (raw)
In-Reply-To: <20260812235839.GDan0Ir1Cx8KEu-0TM@fat_crate.local>

On Wed, Aug 12, 2026 at 04:58:39PM -0700, Borislav Petkov wrote:
> On Tue, Jul 14, 2026 at 09:04:55AM -0400, Yazen Ghannam wrote:
> > -	pr_emerg(HW_ERR "%s Ext. Error Code: %d", smca_get_long_name(bank_type), xec);
> > +	memset(buf, 0, sizeof(buf));
> > +	p = buf;
> > +	end = buf + sizeof(buf);
> > +
> > +	p += scnprintf(p, end - p, "%s Ext. Error Code: %d", smca_get_long_name(bank_type), xec);
> > +
> > +	pr_emerg(HW_ERR "%s", buf);
> 
> Yes, I think this is the right idea, albeit with a couple of improvements:
> 
> 1. We should define our own vararg log() function - static, used only in this
>    file, which gets a format string and params and vscnprintf()s into our
>    local, heap-allocated string array of 256 initially, we can grow it later
>    if needed
> 
> 2. Function will be a fire-and-forget and should not care about ptr
>    advancement, buffer size, yadda yadda - log() will do that
> 
> 3. When string buffer is full, log() will complain ofc.
> 
> 4. When logging is done, we will have log_print() which goes over the whole
>    string array and splits it into, say, 100-ish chars and breaks the lines
>    then, during printing. We would use a space " " so that we can mark where
>    we can break the string

The delimiter would need more thought. There are a few strings with
spaces like "Ext. Error Code", etc. Though maybe you mean we can use
extra spaces like double-space between strings?

> 
> 5. No locking yet - we can do that later, if really needed
> 
> This way we'll be able to handle all kinds of error record formats but still
> keep them compact enough so that they can go out in a couple of printk()
> calls.
> 
> The other advantage when having a buffer like that is, if you look at kdump
> memory image, you can find the buffer in memory and actually dump its contents
> - one more way to get to the error.
> 
> Thoughts?
> 
> Lemme know if you have cycles to do this. If not, I can take a stab at it
> myself.
> 

I like the idea but I'm not familiar with the concepts. It'll take me
some time to figure it out, so I don't have cycles to do it now.

Thanks,
Yazen

  reply	other threads:[~2026-08-14 13:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12  3:16 [PATCH] EDAC/mce_amd: Do not print a stray newline Borislav Petkov
2026-07-13 18:44 ` Yazen Ghannam
2026-07-13 23:22   ` Borislav Petkov
2026-07-14 10:28     ` Srivatsa S. Bhat
2026-07-14 13:04       ` Yazen Ghannam
2026-07-20  5:13         ` Srivatsa S. Bhat
2026-07-29 19:52           ` Yazen Ghannam
2026-08-12 23:58         ` Borislav Petkov
2026-08-14 13:43           ` Yazen Ghannam [this message]
2026-08-14 15:11             ` Borislav Petkov

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=20260814134307.GA1650@yaz-khff2.amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=bp@kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srivatsa@csail.mit.edu \
    /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.