Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread H. Peter Anvin
On 01/15/2014 10:20 PM, HATAYAMA Daisuke wrote:
> (2014/01/16 14:53), H. Peter Anvin wrote:
>> On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
>>>
>>> This is not typo in my intention.
>>>
>>> generic_processor_info() has two more cases where it ignores cpus.
>>> In either cases, printed messages are tagged with "ACPI" because this
>>> function is called when parsing ACPI MADT table in acpi_boot_init();
>>> this function is also being used to parse other kind of tables but
>>> the "ACPI" tag would mean that the function was first for ACPI only.
>>>
>>
>> But it has nothing to do with ACPI -- it is an APIC ID from the command
>> line -- so that would be actively misleading.
>>
>> -hpa
>>
> 
> I never disagree to the fix itself. I wanted to explain why I wrote so.
> 
> I thought it was better to unify tags in the same function because they
> should bleong to the same component, here I mean ACPI, but it's better
> to avoid the confusion, which is bigger impact.
> 

Indeed.  All good now.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread HATAYAMA Daisuke

(2014/01/16 14:53), H. Peter Anvin wrote:

On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:


This is not typo in my intention.

generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with "ACPI" because this
function is called when parsing ACPI MADT table in acpi_boot_init();
this function is also being used to parse other kind of tables but
the "ACPI" tag would mean that the function was first for ACPI only.



But it has nothing to do with ACPI -- it is an APIC ID from the command
line -- so that would be actively misleading.

-hpa



I never disagree to the fix itself. I wanted to explain why I wrote so.

I thought it was better to unify tags in the same function because they
should bleong to the same component, here I mean ACPI, but it's better
to avoid the confusion, which is bigger impact.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread H. Peter Anvin
On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
> 
> This is not typo in my intention.
> 
> generic_processor_info() has two more cases where it ignores cpus.
> In either cases, printed messages are tagged with "ACPI" because this
> function is called when parsing ACPI MADT table in acpi_boot_init();
> this function is also being used to parse other kind of tables but
> the "ACPI" tag would mean that the function was first for ACPI only.
> 

But it has nothing to do with ACPI -- it is an APIC ID from the command
line -- so that would be actively misleading.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread HATAYAMA Daisuke

(2014/01/16 6:09), tip-bot for H. Peter Anvin wrote:

Commit-ID:  5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
Gitweb: http://git.kernel.org/tip/5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
Author: H. Peter Anvin 
AuthorDate: Wed, 15 Jan 2014 13:02:08 -0800
Committer:  H. Peter Anvin 
CommitDate: Wed, 15 Jan 2014 13:02:08 -0800

x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

Make disabled_cpu_apicid static and read_mostly, and fix a couple of
typos.

Reported-by: Ingo Molnar 
Link: http://lkml.kernel.org/r/20140115182511.ga22...@gmail.com
Signed-off-by: H. Peter Anvin 
Cc: HATAYAMA Daisuke 
---
  arch/x86/kernel/apic/apic.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e78ab8c..7f26c9a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -79,7 +79,7 @@ physid_mask_t phys_cpu_present_map;
   * disable_cpu_apicid=, mostly used for the kdump 2nd kernel to
   * avoid undefined behaviour caused by sending INIT from AP to BSP.
   */
-unsigned int disabled_cpu_apicid = BAD_APICID;
+static unsigned int disabled_cpu_apicid __read_mostly = BAD_APICID;

  /*
   * Map cpu index to physical APIC ID
@@ -2124,7 +2124,7 @@ int generic_processor_info(int apicid, int version)
 * boot_cpu_physical_apicid is designed to have the apicid
 * returned by read_apic_id(), i.e, the apicid of the
 * currently booting-up processor. However, on some platforms,
-* it is temporarilly modified by the apicid reported as BSP
+* it is temporarily modified by the apicid reported as BSP
 * through MP table. Concretely:
 *
 * - arch/x86/kernel/mpparse.c: MP_processor_info()
@@ -2145,7 +2145,7 @@ int generic_processor_info(int apicid, int version)
disabled_cpu_apicid == apicid) {
int thiscpu = num_processors + disabled_cpus;

-   pr_warning("ACPI: Disabling requested cpu."
+   pr_warning("APIC: Disabling requested cpu."
   " Processor %d/0x%x ignored.\n",
   thiscpu, apicid);


This is not typo in my intention.

generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with "ACPI" because this
function is called when parsing ACPI MADT table in acpi_boot_init();
this function is also being used to parse other kind of tables but
the "ACPI" tag would mean that the function was first for ACPI only.

int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
phys_cpu_present_map);

/*
 * If boot cpu has not been detected yet, then only allow upto
 * nr_cpu_ids - 1 processors and keep one slot free for boot cpu
 */
if (!boot_cpu_detected && num_processors >= nr_cpu_ids - 1 &&
apicid != boot_cpu_physical_apicid) {
int thiscpu = max + disabled_cpus - 1;

pr_warning(
"ACPI: NR_CPUS/possible_cpus limit of %i almost"
" reached. Keeping one slot for boot cpu."
"  Processor %d/0x%x ignored.\n", max, thiscpu, apicid);

disabled_cpus++;
return -ENODEV;
}

if (num_processors >= nr_cpu_ids) {
int thiscpu = max + disabled_cpus;

pr_warning(
"ACPI: NR_CPUS/possible_cpus limit of %i reached."
"  Processor %d/0x%x ignored.\n", max, thiscpu, apicid);

disabled_cpus++;
return -EINVAL;
}


--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread HATAYAMA Daisuke

(2014/01/16 6:09), tip-bot for H. Peter Anvin wrote:

Commit-ID:  5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
Gitweb: http://git.kernel.org/tip/5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
Author: H. Peter Anvin h...@zytor.com
AuthorDate: Wed, 15 Jan 2014 13:02:08 -0800
Committer:  H. Peter Anvin h...@zytor.com
CommitDate: Wed, 15 Jan 2014 13:02:08 -0800

x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

Make disabled_cpu_apicid static and read_mostly, and fix a couple of
typos.

Reported-by: Ingo Molnar mi...@kernel.org
Link: http://lkml.kernel.org/r/20140115182511.ga22...@gmail.com
Signed-off-by: H. Peter Anvin h...@linux.intel.com
Cc: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
  arch/x86/kernel/apic/apic.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e78ab8c..7f26c9a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -79,7 +79,7 @@ physid_mask_t phys_cpu_present_map;
   * disable_cpu_apicid=int, mostly used for the kdump 2nd kernel to
   * avoid undefined behaviour caused by sending INIT from AP to BSP.
   */
-unsigned int disabled_cpu_apicid = BAD_APICID;
+static unsigned int disabled_cpu_apicid __read_mostly = BAD_APICID;

  /*
   * Map cpu index to physical APIC ID
@@ -2124,7 +2124,7 @@ int generic_processor_info(int apicid, int version)
 * boot_cpu_physical_apicid is designed to have the apicid
 * returned by read_apic_id(), i.e, the apicid of the
 * currently booting-up processor. However, on some platforms,
-* it is temporarilly modified by the apicid reported as BSP
+* it is temporarily modified by the apicid reported as BSP
 * through MP table. Concretely:
 *
 * - arch/x86/kernel/mpparse.c: MP_processor_info()
@@ -2145,7 +2145,7 @@ int generic_processor_info(int apicid, int version)
disabled_cpu_apicid == apicid) {
int thiscpu = num_processors + disabled_cpus;

-   pr_warning(ACPI: Disabling requested cpu.
+   pr_warning(APIC: Disabling requested cpu.
Processor %d/0x%x ignored.\n,
   thiscpu, apicid);


This is not typo in my intention.

generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with ACPI because this
function is called when parsing ACPI MADT table in acpi_boot_init();
this function is also being used to parse other kind of tables but
the ACPI tag would mean that the function was first for ACPI only.

int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
phys_cpu_present_map);

/*
 * If boot cpu has not been detected yet, then only allow upto
 * nr_cpu_ids - 1 processors and keep one slot free for boot cpu
 */
if (!boot_cpu_detected  num_processors = nr_cpu_ids - 1 
apicid != boot_cpu_physical_apicid) {
int thiscpu = max + disabled_cpus - 1;

pr_warning(
ACPI: NR_CPUS/possible_cpus limit of %i almost
 reached. Keeping one slot for boot cpu.
  Processor %d/0x%x ignored.\n, max, thiscpu, apicid);

disabled_cpus++;
return -ENODEV;
}

if (num_processors = nr_cpu_ids) {
int thiscpu = max + disabled_cpus;

pr_warning(
ACPI: NR_CPUS/possible_cpus limit of %i reached.
  Processor %d/0x%x ignored.\n, max, thiscpu, apicid);

disabled_cpus++;
return -EINVAL;
}


--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread H. Peter Anvin
On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
 
 This is not typo in my intention.
 
 generic_processor_info() has two more cases where it ignores cpus.
 In either cases, printed messages are tagged with ACPI because this
 function is called when parsing ACPI MADT table in acpi_boot_init();
 this function is also being used to parse other kind of tables but
 the ACPI tag would mean that the function was first for ACPI only.
 

But it has nothing to do with ACPI -- it is an APIC ID from the command
line -- so that would be actively misleading.

-hpa


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread HATAYAMA Daisuke

(2014/01/16 14:53), H. Peter Anvin wrote:

On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:


This is not typo in my intention.

generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with ACPI because this
function is called when parsing ACPI MADT table in acpi_boot_init();
this function is also being used to parse other kind of tables but
the ACPI tag would mean that the function was first for ACPI only.



But it has nothing to do with ACPI -- it is an APIC ID from the command
line -- so that would be actively misleading.

-hpa



I never disagree to the fix itself. I wanted to explain why I wrote so.

I thought it was better to unify tags in the same function because they
should bleong to the same component, here I mean ACPI, but it's better
to avoid the confusion, which is bigger impact.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos

2014-01-15 Thread H. Peter Anvin
On 01/15/2014 10:20 PM, HATAYAMA Daisuke wrote:
 (2014/01/16 14:53), H. Peter Anvin wrote:
 On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:

 This is not typo in my intention.

 generic_processor_info() has two more cases where it ignores cpus.
 In either cases, printed messages are tagged with ACPI because this
 function is called when parsing ACPI MADT table in acpi_boot_init();
 this function is also being used to parse other kind of tables but
 the ACPI tag would mean that the function was first for ACPI only.


 But it has nothing to do with ACPI -- it is an APIC ID from the command
 line -- so that would be actively misleading.

 -hpa

 
 I never disagree to the fix itself. I wanted to explain why I wrote so.
 
 I thought it was better to unify tags in the same function because they
 should bleong to the same component, here I mean ACPI, but it's better
 to avoid the confusion, which is bigger impact.
 

Indeed.  All good now.

-hpa

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/