From: Nathan Lynch <nathanl@linux.ibm.com>
To: Kajol Jain <kjain@linux.ibm.com>
Cc: ravi.bangoria@linux.ibm.com, maddy@linux.vnet.ibm.com,
anju@linux.vnet.ibm.com, peterz@infradead.org,
gregkh@linuxfoundation.org, suka@us.ibm.com,
alexander.shishkin@linux.intel.com, mingo@kernel.org,
mpetlan@redhat.com, yao.jin@linux.intel.com, ak@linux.intel.com,
mamatha4@linux.vnet.ibm.com, acme@kernel.org, jmario@redhat.com,
namhyung@kernel.org, linuxppc-dev@lists.ozlabs.org,
jolsa@kernel.org, kan.liang@linux.intel.com
Subject: Re: [PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
Date: Mon, 11 May 2020 16:07:39 -0500 [thread overview]
Message-ID: <87blmu2nac.fsf@linux.ibm.com> (raw)
In-Reply-To: <20200506110737.14904-3-kjain@linux.ibm.com>
Hi,
Kajol Jain <kjain@linux.ibm.com> writes:
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 48e8f4b17b91..8cf242aad98f 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -20,6 +20,7 @@
> #include <asm/io.h>
> #include <linux/byteorder/generic.h>
>
> +#include <asm/rtas.h>
> #include "hv-24x7.h"
> #include "hv-24x7-catalog.h"
> #include "hv-common.h"
> @@ -57,6 +58,75 @@ static bool is_physical_domain(unsigned domain)
> }
> }
>
> +/*
> + * The Processor Module Information system parameter allows transferring
> + * of certain processor module information from the platform to the OS.
> + * Refer PAPR+ document to get parameter token value as '43'.
> + */
> +
> +#define PROCESSOR_MODULE_INFO 43
> +#define PROCESSOR_MAX_LENGTH (8 * 1024)
> +
> +DEFINE_SPINLOCK(rtas_local_data_buf_lock);
> +EXPORT_SYMBOL(rtas_local_data_buf_lock);
This should be static and not exported, correct?
> +
> +static u32 phys_sockets; /* Physical sockets */
> +static u32 phys_chipspersocket; /* Physical chips per socket*/
> +static u32 phys_coresperchip; /* Physical cores per chip */
> +
> +/*
> + * Function read_sys_info_pseries() make a rtas_call which require
> + * data buffer of size 8K. As standard 'rtas_data_buf' is of size
> + * 4K, we are adding new local buffer 'rtas_local_data_buf'.
Sorry if this has been covered before but I don't understand why it
would require a larger buffer; by my reading this call will return *ten
bytes* of output. Also, current versions of PAPR+ limit the output
length to 4002 bytes. I feel like I'm missing something.
> + */
> +static __be16 rtas_local_data_buf[PROCESSOR_MAX_LENGTH] __cacheline_aligned;
> +
> +/*
> + * read_sys_info_pseries()
> + * Retrieve the number of sockets and chips per socket and cores per
> + * chip details through the get-system-parameter rtas call.
> + */
> +void read_sys_info_pseries(void)
> +{
> + int call_status, len, ntypes;
> +
> + /*
> + * Making system parameter: chips and sockets and cores per chip
> + * default to 1.
> + */
> + phys_sockets = 1;
> + phys_chipspersocket = 1;
> + phys_coresperchip = 1;
> + memset(rtas_local_data_buf, 0, PROCESSOR_MAX_LENGTH * sizeof(__be16));
Modifying global state outside of any critical section...? How do
you prevent readers from seeing inconsistent results?
> + spin_lock(&rtas_local_data_buf_lock);
> +
> + call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
> + NULL,
> + PROCESSOR_MODULE_INFO,
> + __pa(rtas_local_data_buf),
> + PROCESSOR_MAX_LENGTH);
> +
> + spin_unlock(&rtas_local_data_buf_lock);
Using this lock this way fails to provide any protection to the data
buffer or the phys_* variables.
> +
> + if (call_status != 0) {
> + pr_info("Error calling get-system-parameter (0x%x)\n",
> + call_status);
To be robust, this should handle busy (-2) and extended delay (990x)
statuses. And if it's going to log errors it should use pr_err() and use
decimal, not hex, to report the RTAS call status, since that's how
they're specified in PAPR+.
next prev parent reply other threads:[~2020-05-11 21:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 11:07 [PATCH v8 0/5] powerpc/hv-24x7: Expose chip/sockets info to add json file metric support for the hv_24x7 socket/chip level events Kajol Jain
2020-05-06 11:07 ` [PATCH v8 1/5] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run Kajol Jain
2020-05-06 11:07 ` [PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details Kajol Jain
2020-05-11 21:07 ` Nathan Lynch [this message]
2020-05-18 5:32 ` kajoljain
2020-05-06 11:07 ` [PATCH v8 3/5] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show " Kajol Jain
2020-05-06 11:07 ` [PATCH v8 4/5] Documentation/ABI: Add ABI documentation for chips and sockets Kajol Jain
2020-05-06 11:07 ` [PATCH v8 5/5] powerpc/hv-24x7: Update post_mobility_fixup() to handle migration Kajol Jain
2020-05-08 22:10 ` kbuild test robot
2020-05-11 19:40 ` Nathan Lynch
2020-05-13 6:20 ` kajoljain
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=87blmu2nac.fsf@linux.ibm.com \
--to=nathanl@linux.ibm.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=anju@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jmario@redhat.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=mamatha4@linux.vnet.ibm.com \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@linux.ibm.com \
--cc=suka@us.ibm.com \
--cc=yao.jin@linux.intel.com \
/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).