: ACPI: Rename ACPI processor device bus ID
RFC PATCH 1/1 : ACPI: Rename ACPI processor device bus ID
On some boxes several processors use the same processor bus id. But they are located in different scope. For example:
\_SB.SCK0.CPU0 \_SB.SCK1.CPU0
This follows the ACPI spec.
As they use the same bus id, it can't be registered when
registering proc I/F. It causes that the ACPI processor driver can't be bound with the processor device.
Rename the processor device bus id. And the new bus id will be generated as the following format:
CPU+ CPU ID
For example: If the cpu ID is 5, then the bus ID will be "CPU5".
If the CPU ID is 10, then the bus ID will be "CPUA".
--- drivers/acpi/processor_core.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/acpi/processor_core.c +10 -1
@@ -649,7 +649,16 @@return -ENODEV ; } } - +/* +* On some boxes several processors use the same processor bus id. +* But they are located in different scope. For example: +* \_SB.SCK0.CPU0 +* \_SB.SCK1.CPU0 +* Rename the processor device bus id. And the new bus id will be +* generated as the following format: +* CPU+CPU ID. +*/ +sprintf (acpi_device_bid (device),"CPU%X" , pr->id);ACPI_DEBUG_PRINT ((ACPI_DB_INFO ,"Processor [%d:%d]\n" , pr->id, pr->acpi_id));
drivers/acpi/processor_core.c line 661
Quoted 1 line · yakui_zhao
drivers/acpi/processor_core.c +1
-0+sprintf (acpi_device_bid (device),"CPU%X" , pr->id);
Is this safe against overflows, i.e. is pr->id something *we* set? Because if it is in any way read from the ACPI firmware, you have to either use snprintf, or use the format string to limit the %X to a safe lenght...
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 6 lines · Henrique de Moraes Holschuh
drivers/acpi/processor_core.c line 661
Quoted 1 line · yakui_zhao
drivers/acpi/processor_core.c +1
-0+sprintf (acpi_device_bid (device),"CPU%X" , pr->id);Is this safe against overflows, i.e. is
pr->idsomething *we* set? Because if it is in any way read from the ACPI firmware, you have to either use snprintf, or use the format string to limit the %X to a safe lenght...
Thanks for pointing out this issue.
Now the array size of acpi_bus_id is 5. And when the cpu number is above 256, the overflow will happen. But it is very luck that the following three bytes are not used by other variable because of align. And this still can work.
Of course I already sent a patch, in which the array size is changed from 5 to 8.
At the same time if the cpu number is less than or equal to 256, the length of format string is safe.
thanks.
Best regards.
Yakui
Quoted 1 line
Quoted 15 lines · yakui_zhao
Quoted 6 lines · Henrique de Moraes Holschuh
drivers/acpi/processor_core.c line 661
Quoted 1 line · yakui_zhao
drivers/acpi/processor_core.c +1
-0+sprintf (acpi_device_bid (device),"CPU%X" , pr->id);Is this safe against overflows, i.e. is
pr->idsomething *we* set? Because if it is in any way read from the ACPI firmware, you have to either use snprintf, or use the format string to limit the %X to a safe lenght...Thanks for pointing out this issue.
Now the array size ofacpi_bus_idis 5. And when the cpu number is above 256, the overflow will happen. But it is very luck that the following three bytes are not used by other variable because of align. And this still can work.
Of course I already sent a patch, in which the array size is changed from 5 to 8.
Quoted 2 lines
At the same time if the cpu number is less than or equal to 256, the length of format string is safe.
Yeah, but I was really asking if, even with space for 8 chars, isn't there a risk of pr->id being, say, 0xfffffffe due to some wierdness...
If there is such a risk, you should use snprintf, or a a length limit in the format...
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 16 lines · Henrique de Moraes Holschuh
Quoted 15 lines · yakui_zhao
Quoted 6 lines · Henrique de Moraes Holschuh
drivers/acpi/processor_core.c line 661
Quoted 1 line · yakui_zhao
drivers/acpi/processor_core.c +1
-0+sprintf (acpi_device_bid (device),"CPU%X" , pr->id);Is this safe against overflows, i.e. is
pr->idsomething *we* set? Because if it is in any way read from the ACPI firmware, you have to either use snprintf, or use the format string to limit the %X to a safe lenght...Thanks for pointing out this issue.
Now the array size ofacpi_bus_idis 5. And when the cpu number is above 256, the overflow will happen. But it is very luck that the following three bytes are not used by other variable because of align. And this still can work.
Of course I already sent a patch, in which the array size is changed from 5 to 8.
Quoted 5 lines
Quoted 2 lines
At the same time if the cpu number is less than or equal to 256, the length of format string is safe.
Yeah, but I was really asking if, even with space for 8 chars, isn't there a risk of
pr->idbeing, say,0xfffffffedue to some wierdness...
If the pr->id is set to 0xfffffffe, it is a risk.
But in fact OS will get the correct cpu id by using the function of get_cpu_id. The result value is -1 or other correct cpu id.
So it is unnecessary to worry that the incorrect value is assigned to pr->id.
Of course it will be OK to use the snprintf instead of sprintf. thanks.
Quoted 4 lines
If there is such a risk, you should use snprintf, or a a length limit in the format...