From: Robert Richter <rric@kernel.org>
To: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Cc: rjw@rjwysocki.net, lenb@kernel.org, tony.luck@intel.com,
bp@alien8.de, m.chehab@samsung.com, bp@suse.de,
linux-edac@vger.kernel.org, x86@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linaro-acpi@lists.linaro.org
Subject: Re: [PATCH v3 3/5] acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications.
Date: Fri, 13 Jun 2014 15:10:51 +0200 [thread overview]
Message-ID: <20140613131051.GY27560@rric.localhost> (raw)
In-Reply-To: <1402657380-18539-4-git-send-email-tomasz.nowicki@linaro.org>
On 13.06.14 13:02:58, Tomasz Nowicki wrote:
> @@ -811,6 +819,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
> int sev, sev_global = -1;
> int ret = NMI_DONE;
>
> + BUG_ON(!IS_ENABLED(ARCH_HAS_ACPI_APEI_NMI));
> +
Now that we have the ARCH_HAS_ACPI_APEI_NMI option, group nmi code,
put it in an #ifdef ... and make function stubs for the !nmi case
where necessary. That code should moved to patch #2. If an arch does
not support nmi code, we don't want to compile it into the kernel.
Also this patch is quit a bit large and should further split into
moving functional code into separate functions and the introduction of
the notifier setup. This makes review much easier.
I did not yet took a deep look into your notifier framework, but I
don't really see a reason for the dynamic collection of function
pointers in ghes_notify_tab. See below.
> raw_spin_lock(&ghes_nmi_lock);
> list_for_each_entry_rcu(ghes, &ghes_nmi, list) {
> if (ghes_read_estatus(ghes, 1)) {
> @@ -875,10 +885,6 @@ out:
> return ret;
> }
> +static int ghes_notify_init_nmi(struct ghes *ghes)
> +{
> + unsigned long len;
> + int status = 0;
> +
> + len = ghes_esource_prealloc_size(ghes->generic);
> + ghes_estatus_pool_expand(len);
> + mutex_lock(&ghes_list_mutex);
> + if (list_empty(&ghes_nmi))
> + status = register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0,
> + "ghes");
> + list_add_rcu(&ghes->list, &ghes_nmi);
> + mutex_unlock(&ghes_list_mutex);
> +
> + return status;
> +}
> +
> +static void ghes_notify_remove_nmi(struct ghes *ghes)
> +{
> + unsigned long len;
> +
> + mutex_lock(&ghes_list_mutex);
> + list_del_rcu(&ghes->list);
> + if (list_empty(&ghes_nmi))
> + unregister_nmi_handler(NMI_LOCAL, "ghes");
> + mutex_unlock(&ghes_list_mutex);
> + /*
> + * To synchronize with NMI handler, ghes can only be
> + * freed after NMI handler finishes.
> + */
> + synchronize_rcu();
> + len = ghes_esource_prealloc_size(ghes->generic);
> + ghes_estatus_pool_shrink(len);
> +}
> +
> +static void ghes_init_nmi(void)
> +{
> + if (!IS_ENABLED(ARCH_HAS_ACPI_APEI_NMI))
> + return;
> +
> + init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
> + ghes_notify_tab[ACPI_HEST_NOTIFY_NMI].init_call = ghes_notify_init_nmi;
> + ghes_notify_tab[ACPI_HEST_NOTIFY_NMI].remove_call =
> + ghes_notify_remove_nmi;
> +}
> +
So this is the only code of your whole patch set that actually changes
an entry, and just one time only during nmi init. Thus, there is no
need at all for ghes_notify_tab. Just create function stubs for
ghes_notify_{init,remove}_nmi for the !nmi case with the error message
in it and call the functions directly in the switch/cases.
> +static struct ghes_notify_setup
> + ghes_notify_tab[ACPI_HEST_NOTIFY_RESERVED] = {
> + [ACPI_HEST_NOTIFY_POLLED] = {"POLLED",
> + ghes_notify_init_polled,
> + ghes_notify_remove_polled},
> + [ACPI_HEST_NOTIFY_EXTERNAL] = {"EXT_IRQ",
> + ghes_notify_init_external,
> + ghes_notify_remove_external},
> + [ACPI_HEST_NOTIFY_LOCAL] = {"LOCAL_IRQ", NULL, NULL},
> + [ACPI_HEST_NOTIFY_SCI] = {"SCI",
> + ghes_notify_init_sci,
> + ghes_notify_remove_sci},
> + [ACPI_HEST_NOTIFY_NMI] = {"NMI", NULL, NULL},
> + [ACPI_HEST_NOTIFY_CMCI] = {"CMCI", NULL, NULL},
> + [ACPI_HEST_NOTIFY_MCE] = {"MCE", NULL, NULL},
> +};
Again, just keep the switch/case statements in the probe and removal
function and call the init/remove functions directly in them. This is
much easier.
If we need dynamic registration of handlers (which I don't see yet)
for the error sources above we could do this with an acpi notify
handler or so.
-Robert
next prev parent reply other threads:[~2014-06-13 13:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 11:02 [PATCH v3 0/5] APEI: Make APEI architecture independent Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 1/5] apei, mce: Factor out APEI architecture specific MCE calls Tomasz Nowicki
2014-06-13 13:54 ` Robert Richter
2014-06-19 14:17 ` Borislav Petkov
2014-06-24 9:01 ` Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 2/5] acpi, apei, ghes: Introduce ARCH_HAS_ACPI_APEI_NMI to make NMI error notification a GHES feature Tomasz Nowicki
2014-06-13 14:01 ` Robert Richter
2014-06-19 14:27 ` Borislav Petkov
2014-06-24 9:00 ` Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 3/5] acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications Tomasz Nowicki
2014-06-13 13:10 ` Robert Richter [this message]
2014-06-19 14:28 ` Borislav Petkov
2014-06-24 9:06 ` Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 4/5] apei, ghes, nmi: Factor out NMI arch-specific calls Tomasz Nowicki
2014-06-13 13:29 ` Robert Richter
2014-06-13 11:03 ` [PATCH v3 5/5] acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context Tomasz Nowicki
2014-06-13 13:35 ` Robert Richter
2014-06-13 13:14 ` [PATCH v3 0/5] APEI: Make APEI architecture independent Robert Richter
2014-06-13 13:20 ` 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=20140613131051.GY27560@rric.localhost \
--to=rric@kernel.org \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=lenb@kernel.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=tomasz.nowicki@linaro.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.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