AML opcodes come in two lengths: 1-byte opcodes and 2-byte, extended opcodes.
If an error occurs due to illegal opcodes during table load, the AML parser
needs to continue loading the table. In order to do this, it needs to skip
parsing of the offending opcode and operands associated with that opcode.
This change fixes the AML parse loop to correctly skip parsing of incorrect
extended opcodes. Previously, only the short opcodes were skipped correctly.
Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com>
---
drivers/acpi/acpica/psloop.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c
index 34fc2f7476ed..b0789c483b0f 100644
--- a/drivers/acpi/acpica/psloop.c
+++ b/drivers/acpi/acpica/psloop.c
@@ -417,6 +417,7 @@ acpi_status acpi_ps_parse_loop(struct acpi_walk_state *walk_state)
union acpi_parse_object *op = NULL; /* current op */
struct acpi_parse_state *parser_state;
u8 *aml_op_start = NULL;
+ u8 opcode_length;
ACPI_FUNCTION_TRACE_PTR(ps_parse_loop, walk_state);
@@ -540,8 +541,19 @@ acpi_status acpi_ps_parse_loop(struct acpi_walk_state *walk_state)
"Skip parsing opcode %s",
acpi_ps_get_opcode_name
(walk_state->opcode)));
+
+ /*
+ * Determine the opcode length before skipping the opcode.
+ * An opcode can be 1 byte or 2 bytes in length.
+ */
+ opcode_length = 1;
+ if ((walk_state->opcode & 0xFF00) ==
+ AML_EXTENDED_OPCODE) {
+ opcode_length = 2;
+ }
walk_state->parser_state.aml =
- walk_state->aml + 1;
+ walk_state->aml + opcode_length;
+
walk_state->parser_state.aml =
acpi_ps_get_next_package_end
(&walk_state->parser_state);
--
2.17.1
The table load process omitted adding the operation region address
range to the global list. This omission is problematic because the OS
queries the global list to check for address range conflicts before
deciding which drivers to load. This commit may result in warning
messages that look like the following:
[ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213)
[ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
However, these messages do not signify regressions. It is a result of
properly adding address ranges within the global address list.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
Tested-by: Jean-Marc Lenoir <archlinux(a)jihemel.com>
Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com>
---
drivers/acpi/acpica/dsopcode.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index e9fb0bf3c8d2..78f9de260d5f 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -417,6 +417,10 @@ acpi_ds_eval_region_operands(struct acpi_walk_state *walk_state,
ACPI_FORMAT_UINT64(obj_desc->region.address),
obj_desc->region.length));
+ status = acpi_ut_add_address_range(obj_desc->region.space_id,
+ obj_desc->region.address,
+ obj_desc->region.length, node);
+
/* Now the address and length are valid for this opregion */
obj_desc->region.flags |= AOPOBJ_DATA_VALID;
--
2.17.1
Hi,
I can now confirm that the boot failure is due to the absence of commit
8183d99f4a22 ("powerpc/lib/feature-fixups: use raw_patch_instruction()")
Greg, could you please apply that patch to 4.14 stable ?
Thanks
Christophe
Le 17/10/2018 à 18:36, Christophe LEROY a écrit :
> Hi,
>
> Yes I discovered the same issue today on MPC8321E, I plan to look at it
> more closely tomorrow morning (Paris Time).
>
> I think we are missing commit 8183d99f4a22c2abbc543847a588df3666ef0c0c ,
> I didn't realise it when we applied the serie to 4.14,
> patch_instruction() is called too early without that patch.
>
> If you have opportunity to test now, you are welcome, otherwise I'll
> test it tomorrow.
>
> Christophe
>
> Le 17/10/2018 à 17:18, David Gounaris a écrit :
>> Hello, I got into troubles when I upgraded to Linux kernel 4.14.76 on
>> boards with MPC8321.
>>
>>
>> The symptom that I see is that the boot process gets cyclic, and no
>> printouts are seen from the Linux kernel. It seems like it resets.
>>
>>
>> When I revert the following commits it works again.
>>
>> af1a8101794dfea897290e057f61086dabfe6c91, powerpc/lib: fix book3s/32
>> boot failure due to code patching
>> 609fbeddb24c4035d24fc32d82dc08b30ae3dfc0, powerpc: Avoid code patching
>> freed init sections
>>
>> Any ideas of how to continue?
>>
>> BR / David Gounaris
>>
>>
>>
Although the power management code never calls the system-wide and runtime
suspend callbacks concurrently, runtime power state changes can happen
while the system is being suspended or resumed. See also the dpm_suspend()
and dpm_resume() calls in hibernation_snapshot(). Make sure the sd driver
supports this. This patch avoids that the following call trace is reported
during system-wide suspend:
WARNING: CPU: 0 PID: 701 at drivers/scsi/scsi_lib.c:3047 scsi_device_quiesce+0x4b/0xd0
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:scsi_device_quiesce+0x4b/0xd0
Call Trace:
scsi_bus_suspend_common+0x71/0xe0
scsi_bus_freeze+0x15/0x20
dpm_run_callback+0x88/0x360
__device_suspend+0x1c4/0x840
async_suspend+0x1f/0xb0
async_run_entry_fn+0x6e/0x2c0
process_one_work+0x4ae/0xa20
worker_thread+0x63/0x5a0
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
Fixes: cd84a62e0078 ("block, scsi: Change the preempt-only flag into a counter")
Cc: Lee Duncan <lduncan(a)suse.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Luis Chamberlain <mcgrof(a)kernel.org>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche(a)acm.org>
---
drivers/scsi/scsi_lib.c | 15 ++++++---------
include/scsi/scsi_device.h | 1 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7db3c5fae469..6c18a61176e5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -3052,11 +3052,12 @@ scsi_device_quiesce(struct scsi_device *sdev)
int err;
/*
- * It is allowed to call scsi_device_quiesce() multiple times from
- * the same context but concurrent scsi_device_quiesce() calls are
- * not allowed.
+ * Since all scsi_device_quiesce() and scsi_device_resume() calls
+ * are serialized it is safe here to check the device state without
+ * holding the SCSI device state mutex.
*/
- WARN_ON_ONCE(sdev->quiesced_by && sdev->quiesced_by != current);
+ if (sdev->sdev_state == SDEV_QUIESCE)
+ return 0;
blk_set_preempt_only(q);
@@ -3072,9 +3073,7 @@ scsi_device_quiesce(struct scsi_device *sdev)
mutex_lock(&sdev->state_mutex);
err = scsi_device_set_state(sdev, SDEV_QUIESCE);
- if (err == 0)
- sdev->quiesced_by = current;
- else
+ if (err)
blk_clear_preempt_only(q);
mutex_unlock(&sdev->state_mutex);
@@ -3098,8 +3097,6 @@ void scsi_device_resume(struct scsi_device *sdev)
* device deleted during suspend)
*/
mutex_lock(&sdev->state_mutex);
- WARN_ON_ONCE(!sdev->quiesced_by);
- sdev->quiesced_by = NULL;
blk_clear_preempt_only(sdev->request_queue);
if (sdev->sdev_state == SDEV_QUIESCE)
scsi_device_set_state(sdev, SDEV_RUNNING);
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 202f4d6a4342..ef86c8adc5d5 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -226,7 +226,6 @@ struct scsi_device {
unsigned char access_state;
struct mutex state_mutex;
enum scsi_device_state sdev_state;
- struct task_struct *quiesced_by;
unsigned long sdev_data[0];
} __attribute__((aligned(sizeof(unsigned long))));
--
2.19.1.568.g152ad8e336-goog
Although the power management code never calls the system-wide and runtime
suspend callbacks concurrently, runtime power state changes can happen
while the system is being suspended or resumed. See also the dpm_suspend()
and dpm_resume() calls in hibernation_snapshot(). Make sure the sd driver
supports this. This patch avoids that the following call trace is reported
during system-wide suspend:
WARNING: CPU: 0 PID: 701 at drivers/scsi/scsi_lib.c:3047 scsi_device_quiesce+0x4b/0xd0
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:scsi_device_quiesce+0x4b/0xd0
Call Trace:
scsi_bus_suspend_common+0x71/0xe0
scsi_bus_freeze+0x15/0x20
dpm_run_callback+0x88/0x360
__device_suspend+0x1c4/0x840
async_suspend+0x1f/0xb0
async_run_entry_fn+0x6e/0x2c0
process_one_work+0x4ae/0xa20
worker_thread+0x63/0x5a0
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
Fixes: cd84a62e0078 ("block, scsi: Change the preempt-only flag into a counter")
Cc: Lee Duncan <lduncan(a)suse.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Luis Chamberlain <mcgrof(a)kernel.org>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche(a)acm.org>
---
drivers/scsi/scsi_lib.c | 16 +++++-----------
include/scsi/scsi_device.h | 1 -
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 62348412ed1b..3106e910e766 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -3040,13 +3040,11 @@ scsi_device_quiesce(struct scsi_device *sdev)
int err;
/*
- * It is allowed to call scsi_device_quiesce() multiple times from
- * the same context but concurrent scsi_device_quiesce() calls are
- * not allowed.
+ * Since all scsi_device_quiesce() and scsi_device_resume() calls
+ * are serialized it is safe to check the device state without holding
+ * the SCSI device state mutex.
*/
- WARN_ON_ONCE(sdev->quiesced_by && sdev->quiesced_by != current);
-
- if (sdev->quiesced_by == current)
+ if (sdev->sdev_state == SDEV_QUIESCE)
return 0;
blk_set_pm_only(q);
@@ -3063,9 +3061,7 @@ scsi_device_quiesce(struct scsi_device *sdev)
mutex_lock(&sdev->state_mutex);
err = scsi_device_set_state(sdev, SDEV_QUIESCE);
- if (err == 0)
- sdev->quiesced_by = current;
- else
+ if (err)
blk_clear_pm_only(q);
mutex_unlock(&sdev->state_mutex);
@@ -3089,8 +3085,6 @@ void scsi_device_resume(struct scsi_device *sdev)
* device deleted during suspend)
*/
mutex_lock(&sdev->state_mutex);
- WARN_ON_ONCE(!sdev->quiesced_by);
- sdev->quiesced_by = NULL;
blk_clear_pm_only(sdev->request_queue);
if (sdev->sdev_state == SDEV_QUIESCE)
scsi_device_set_state(sdev, SDEV_RUNNING);
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 202f4d6a4342..ef86c8adc5d5 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -226,7 +226,6 @@ struct scsi_device {
unsigned char access_state;
struct mutex state_mutex;
enum scsi_device_state sdev_state;
- struct task_struct *quiesced_by;
unsigned long sdev_data[0];
} __attribute__((aligned(sizeof(unsigned long))));
--
2.19.1.568.g152ad8e336-goog