Possible mis-backport of 4abb951b in 4.19.35 ("ACPICA: AML interpreter: add region addresses...")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I noticed 4.19.35 got a backport of mainline 4abb951b, but it appears to
be a duplicate backport that landed in the wrong function.  We can see
this in the stable-queue repo:

stable-queue$ find . -name '*acpica-aml-interpreter-add-region-addr*' |grep 4.19
./releases/4.19.6/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch
./releases/4.19.3/revert-acpica-aml-interpreter-add-region-addresses-in.patch
./releases/4.19.35/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch
./releases/4.19.2/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch

So it was added to 4.19.2, reverted in .3, re-added in .6, and then
finally patched into a similar looking but wrong function in .35

If we diff the .6 and .35 versions, we see the function difference:

-@@ -417,6 +417,10 @@ acpi_ds_eval_region_operands(struct acpi
+@@ -523,6 +523,10 @@ acpi_ds_eval_table_region_operands(struc

I don't know what the history is/was around the 2/3/6 churn, but the
re-addition in 4.19.35 to a different function sure looks wrong.

The commit adds a call "status = acpi_ut_add_address_range(..." and if
we check mainline, there is only one in that file, but in 4.19.35+ there
now are two calls - since the two functions had similar context and
comments, it isn't hard to see how patch could/would apply it a 2nd time
in the wrong place.

I didn't check if any of the other currently maintained linux-stable
versions also had this possible issue.

Paul.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux