All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] powerpc/pseries: read the lpar name from the firmware
Date: Tue, 07 Dec 2021 08:32:39 -0600	[thread overview]
Message-ID: <87bl1so588.fsf@linux.ibm.com> (raw)
In-Reply-To: <20211203154321.13168-1-ldufour@linux.ibm.com>

Hi Laurent,

Laurent Dufour <ldufour@linux.ibm.com> writes:
> +/*
> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55 to
> + * read the LPAR name.
> + */
> +#define SPLPAR_LPAR_NAME_TOKEN	55
> +static void read_lpar_name(struct seq_file *m)
> +{
> +	int rc, len, token;
> +	union {
> +		char raw_buffer[RTAS_DATA_BUF_SIZE];
> +		struct {
> +			__be16 len;

This:

> +			char name[RTAS_DATA_BUF_SIZE-2];
                                       ^^^^^^

should be 4000, not (4K - 2), according to PAPR (it's weird and I don't
know the reason).


> +		};
> +	} *local_buffer;
> +
> +	token = rtas_token("ibm,get-system-parameter");
> +	if (token == RTAS_UNKNOWN_SERVICE)
> +		return;
> +
> +	local_buffer = kmalloc(sizeof(*local_buffer), GFP_KERNEL);
> +	if (!local_buffer)
> +		return;
> +
> +	do {
> +		spin_lock(&rtas_data_buf_lock);
> +		memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
> +		rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
> +			       __pa(rtas_data_buf), RTAS_DATA_BUF_SIZE);
> +		if (!rc)
> +			memcpy(local_buffer->raw_buffer, rtas_data_buf,
> +			       RTAS_DATA_BUF_SIZE);
> +		spin_unlock(&rtas_data_buf_lock);
> +	} while (rtas_busy_delay(rc));
> +
> +	if (rc != 0) {
> +		pr_err_once(
> +			"%s %s Error calling get-system-parameter (0x%x)\n",
> +			__FILE__, __func__, rc);

The __FILE__ and __func__ in the message seem unnecessary, and rc should
be reported in decimal so the error meaning is apparent.

Is there a reasonable fallback for VMs where this parameter doesn't
exist? PowerVM partitions should always have it, but what do we want the
behavior to be on other hypervisors?


> +	} else {
> +		/* Force end of string */
> +		len = be16_to_cpu(local_buffer->len);
> +		if (len >= (RTAS_DATA_BUF_SIZE-2))
> +			len = RTAS_DATA_BUF_SIZE-2;

Could use min() or clamp(), and it would be better to build the
expression using the value of sizeof(local_buffer->name).

> +		local_buffer->name[len] = '\0';

If 'len' can be (RTAS_DATA_BUF_SIZE - 2), then this writes past the end
of the buffer, no?


WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3] powerpc/pseries: read the lpar name from the firmware
Date: Tue, 07 Dec 2021 08:32:39 -0600	[thread overview]
Message-ID: <87bl1so588.fsf@linux.ibm.com> (raw)
In-Reply-To: <20211203154321.13168-1-ldufour@linux.ibm.com>

Hi Laurent,

Laurent Dufour <ldufour@linux.ibm.com> writes:
> +/*
> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55 to
> + * read the LPAR name.
> + */
> +#define SPLPAR_LPAR_NAME_TOKEN	55
> +static void read_lpar_name(struct seq_file *m)
> +{
> +	int rc, len, token;
> +	union {
> +		char raw_buffer[RTAS_DATA_BUF_SIZE];
> +		struct {
> +			__be16 len;

This:

> +			char name[RTAS_DATA_BUF_SIZE-2];
                                       ^^^^^^

should be 4000, not (4K - 2), according to PAPR (it's weird and I don't
know the reason).


> +		};
> +	} *local_buffer;
> +
> +	token = rtas_token("ibm,get-system-parameter");
> +	if (token == RTAS_UNKNOWN_SERVICE)
> +		return;
> +
> +	local_buffer = kmalloc(sizeof(*local_buffer), GFP_KERNEL);
> +	if (!local_buffer)
> +		return;
> +
> +	do {
> +		spin_lock(&rtas_data_buf_lock);
> +		memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
> +		rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
> +			       __pa(rtas_data_buf), RTAS_DATA_BUF_SIZE);
> +		if (!rc)
> +			memcpy(local_buffer->raw_buffer, rtas_data_buf,
> +			       RTAS_DATA_BUF_SIZE);
> +		spin_unlock(&rtas_data_buf_lock);
> +	} while (rtas_busy_delay(rc));
> +
> +	if (rc != 0) {
> +		pr_err_once(
> +			"%s %s Error calling get-system-parameter (0x%x)\n",
> +			__FILE__, __func__, rc);

The __FILE__ and __func__ in the message seem unnecessary, and rc should
be reported in decimal so the error meaning is apparent.

Is there a reasonable fallback for VMs where this parameter doesn't
exist? PowerVM partitions should always have it, but what do we want the
behavior to be on other hypervisors?


> +	} else {
> +		/* Force end of string */
> +		len = be16_to_cpu(local_buffer->len);
> +		if (len >= (RTAS_DATA_BUF_SIZE-2))
> +			len = RTAS_DATA_BUF_SIZE-2;

Could use min() or clamp(), and it would be better to build the
expression using the value of sizeof(local_buffer->name).

> +		local_buffer->name[len] = '\0';

If 'len' can be (RTAS_DATA_BUF_SIZE - 2), then this writes past the end
of the buffer, no?


  reply	other threads:[~2021-12-07 14:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 15:43 [PATCH v3] powerpc/pseries: read the lpar name from the firmware Laurent Dufour
2021-12-03 15:43 ` Laurent Dufour
2021-12-07 14:32 ` Nathan Lynch [this message]
2021-12-07 14:32   ` Nathan Lynch
2021-12-07 16:07   ` Laurent Dufour
2021-12-07 16:07     ` Laurent Dufour
2021-12-07 17:07     ` Nathan Lynch
2021-12-07 17:07       ` Nathan Lynch
2021-12-07 17:18       ` Laurent Dufour
2021-12-07 17:18         ` Laurent Dufour
2021-12-07 17:24         ` Laurent Dufour
2021-12-08 15:21         ` Nathan Lynch
2021-12-08 15:21           ` Nathan Lynch
2021-12-09  8:54           ` Laurent Dufour
2021-12-09  8:54             ` Laurent Dufour
2021-12-09 13:53             ` Nathan Lynch
2021-12-09 13:53               ` Nathan Lynch
2021-12-09 15:59               ` Laurent Dufour
2021-12-09 15:59                 ` Laurent Dufour

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=87bl1so588.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=ldufour@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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.