linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jin Dongming <jin.dongming@np.css.fujitsu.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andi Kleen <andi@firstfloor.org>,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	ACPI <linux-acpi@vger.kernel.org>,
	LKLM <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] [Patch-next] ACPI, APEI, ERST Fix the wrong checking of Serialization Header's length
Date: Tue, 17 Aug 2010 11:14:44 +0900	[thread overview]
Message-ID: <4C69F094.1040607@np.css.fujitsu.com> (raw)
In-Reply-To: <1282008836.2744.1490.camel@yhuang-dev>

(2010/08/17 10:33), Huang Ying wrote:
> On Tue, 2010-08-17 at 08:54 +0800, Jin Dongming wrote:
>> header_length in struct acpi_table_erst is not the length of struct
>> acpi_table_erst, but the length of Serialization Header.
>>
>> In erst_check_table(), header_length is used for checking the length
>> of struct acpi_table_erst. So I think it is wrong.
> 
> Why "think"? Do you have a machine with header_length set as you said?

I have such machine, and I confirmed that the header_length returned by firmware
is same as what I described in the above description.

And further more, according to the spec document of ACPI 4.0(page 515),
it is written like following.

  Field                      Byte length   Byte offset   Description
  Serialization Header Size  4             0x24          Length in bytes of
                                                         the serialization header.

> 
>> This patch fixed it and I confirmed it on x86_64 next-tree.
>>
>> Signed-off-by: Jin Dongming <jin.dongming@np.css.fujitsu.com>
>> ---
>>  drivers/acpi/apei/erst.c |   13 ++++++++-----
>>  include/acpi/actbl1.h    |   14 +++++++++++---
>>  2 files changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
>> index 864dd46..28a5caf 100644
>> --- a/drivers/acpi/apei/erst.c
>> +++ b/drivers/acpi/apei/erst.c
>> @@ -358,7 +358,8 @@ static struct apei_exec_ins_type erst_ins_type[] = {
>>  static inline void erst_exec_ctx_init(struct apei_exec_context *ctx)
>>  {
>>  	apei_exec_ctx_init(ctx, erst_ins_type, ARRAY_SIZE(erst_ins_type),
>> -			   ERST_TAB_ENTRY(erst_tab), erst_tab->entries);
>> +			   ERST_TAB_ENTRY(erst_tab),
>> +			   erst_tab->seri_header.entries);
>>  }
>>  
>>  static int erst_get_erange(struct erst_erange *range)
>> @@ -749,12 +750,14 @@ __setup("erst_disable", setup_erst_disable);
>>  
>>  static int erst_check_table(struct acpi_table_erst *erst_tab)
>>  {
>> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
>> +	if (erst_tab->common_header.length < sizeof(struct acpi_table_erst))
>>  		return -EINVAL;
>> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
>> +
>> +	if (erst_tab->seri_header.length != sizeof(struct acpi_erst_header))
>>  		return -EINVAL;
>> -	if (erst_tab->entries !=
>> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
>> +
>> +	if (erst_tab->seri_header.entries !=
>> +	    (erst_tab->common_header.length - sizeof(struct acpi_table_erst)) /
>>  	    sizeof(struct acpi_erst_entry))
>>  		return -EINVAL;
>>  
>> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
>> index c637b75..821f8ac 100644
>> --- a/include/acpi/actbl1.h
>> +++ b/include/acpi/actbl1.h
>> @@ -283,13 +283,21 @@ enum acpi_einj_command_status {
>>   *
>>   ******************************************************************************/
>>  
>> -struct acpi_table_erst {
>> -	struct acpi_table_header header;	/* Common ACPI table header */
>> -	u32 header_length;
>> +/* ERST Serialization Header */
>> +
>> +struct acpi_erst_header {
>> +	u32 length;
>>  	u32 reserved;
>>  	u32 entries;
>>  };
>>  
>> +/* ERST Header */
>> +
>> +struct acpi_table_erst {
>> +	struct acpi_table_header common_header;	/* Common ACPI table header */
>> +	struct acpi_erst_header seri_header;	/* ERST Serialization Header */
>> +};
> 
> I don't think it is necessary to change the header definition, and
> seri_header is not a good name for me.
Why I added this structure here is that I don't want to do following checking.
For example,
	if (header_length != 0x0c) {
		...
	}

Though it is simple, it is really difficult for us to understand the real meaning
of the code.
> 
> Best Regards,
> Huang Ying
> 
> 
> 
> 



  reply	other threads:[~2010-08-17  2:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17  0:54 [PATCH 1/4] [Patch-next] ACPI, APEI, ERST Fix the wrong checking of Serialization Header's length Jin Dongming
2010-08-17  1:33 ` Huang Ying
2010-08-17  2:14   ` Jin Dongming [this message]
2010-08-17  3:22     ` Huang Ying
2010-08-17  4:44       ` Jin Dongming
2010-08-18  5:34         ` Huang Ying
2010-08-18  8:35           ` Jin Dongming
2010-08-20 19:26           ` Yinghai Lu
2010-08-23  0:26             ` Huang Ying

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=4C69F094.1040607@np.css.fujitsu.com \
    --to=jin.dongming@np.css.fujitsu.com \
    --cc=andi@firstfloor.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=sfr@canb.auug.org.au \
    --cc=ying.huang@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).