linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@chromium.org>
To: Grant Grundler <grundler@chromium.org>
Cc: Rajat Jain <rajatja@chromium.org>,
	Rajat Khandelwal <rajat.khandelwal@linux.intel.com>,
	linux-pci@vger.kernel.org,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	linux-kernel@vger.kernel.org,
	Oliver O 'Halloran <oohall@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCHv2 pci-next 2/2] PCI/AER: Rate limit the reporting of the correctable errors
Date: Mon, 5 Jun 2023 20:44:10 -0700	[thread overview]
Message-ID: <CANEJEGs_ni14PZ0VQcNHF+epBspQwOWLu1Yo8KyF3RhpGscV6w@mail.gmail.com> (raw)
In-Reply-To: <CANEJEGscz3F-6cZcp7dBVekpxHMNXZWgUW2ic3xd6hm3xWH6ZQ@mail.gmail.com>

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

On Wed, May 17, 2023 at 11:11 PM Grant Grundler <grundler@chromium.org>
wrote:

> On Fri, Apr 7, 2023 at 12:46 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> ...
> > But I don't think we need output in a single step; we just need a
> > single instance of ratelimit_state (or one for CPER path and another
> > for native AER path), and that can control all the output for a single
> > error.  E.g., print_hmi_event_info() looks like this:
> >
> >   static void print_hmi_event_info(...)
> >   {
> >     static DEFINE_RATELIMIT_STATE(rs, ...);
> >
> >     if (__ratelimit(&rs)) {
> >       printk("%s%s Hypervisor Maintenance interrupt ...");
> >       printk("%s Error detail: %s\n", ...);
> >       printk("%s      HMER: %016llx\n", ...);
> >     }
> >   }
> >
> > I think it's nice that the struct ratelimit_state is explicit and
> > there's no danger of breaking it when adding another printk later.
>
> Since the output is spread across at least two functions, I think your
> proposal is a better solution.
>
> I'm not happy with the patch series I sent in my previous reply as an
> attachment. It's only marginally better than the original code.
>

Despite not being happy about it, after a week of vacation I now think it
would be better to include them as is since they solve the immediate
problems and then solve the above two issues in additional patches. The two
changes I have prepared so far correctly fix the original issues they
intended to fix and don't affect the new issues we've found.

I'll post a V3 of this series tonight after making sure it at least
compiles and "looks right".

cheers,
grant


> I need another day or two to see if I can implement your proposal
> correctly.
>
> cheers,
> grant
>

[-- Attachment #2: Type: text/html, Size: 2577 bytes --]

  reply	other threads:[~2023-06-06  4:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 17:51 [PATCHv2 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO Grant Grundler
2023-03-17 17:51 ` [PATCHv2 pci-next 2/2] PCI/AER: Rate limit the reporting of the correctable errors Grant Grundler
2023-04-06 19:50   ` Bjorn Helgaas
2023-04-07 18:53     ` Grant Grundler
2023-04-07 19:46       ` Bjorn Helgaas
2023-04-07 23:46         ` Grant Grundler
2023-05-17 16:02           ` Bjorn Helgaas
2023-05-17 21:02             ` Grant Grundler
2023-05-18  5:58             ` Grant Grundler
2023-04-07 23:47         ` Grant Grundler
2023-04-07 23:49         ` Grant Grundler
2023-05-18  6:11         ` Grant Grundler
2023-06-06  3:44           ` Grant Grundler [this message]
2023-06-06  3:45           ` Grant Grundler
2023-03-17 18:50 ` [PATCHv2 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO Sathyanarayanan Kuppuswamy
2023-03-17 19:30   ` Bjorn Helgaas
2023-03-19  6:00     ` Grant Grundler

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=CANEJEGs_ni14PZ0VQcNHF+epBspQwOWLu1Yo8KyF3RhpGscV6w@mail.gmail.com \
    --to=grundler@chromium.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=oohall@gmail.com \
    --cc=rajat.khandelwal@linux.intel.com \
    --cc=rajatja@chromium.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 NNTP newsgroup(s).