ACPICA commit b233720031a480abd438f2e9c643080929d144c3
ASL operation_regions declare a range of addresses that it uses. In a
perfect world, the range of addresses should be used exclusively by
the AML interpreter. The OS can use this information to decide which
drivers to load so that the AML interpreter and device drivers use
different regions of memory.
During table load, the address information is added to a global
address range list. Each node in this list contains an address range
as well as a namespace node of the operation_region. This list is
deleted at ACPI shutdown.
Unfortunately, ASL operation_regions can be declared inside of control
methods. Although this is not recommended, modern firmware contains
such code. New module level code changes unintentionally removed the
functionality of adding and removing nodes to the global address
range list.
A few months ago, support for adding addresses has been re-
implemented. However, the removal of the address range list was
missed and resulted in some systems to crash due to the address list
containing bogus namespace nodes from operation_regions declared in
control methods. In order to fix the crash, this change removes
dynamic operation_regions after control method termination.
Link: https://github.com/acpica/acpica/commit/b2337200
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475
Cc: stable(a)vger.kernel.org # 4.20+
Fixes: 4abb951b73ff (ACPICA: AML interpreter: add region addresses in global list during initialization)
Reported-by: Michael J Gruber <mjg(a)fedoraproject.org>
Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com>
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
---
drivers/acpi/acpica/nsobject.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/acpica/nsobject.c b/drivers/acpi/acpica/nsobject.c
index 8638f43cfc3d..79d86da1c892 100644
--- a/drivers/acpi/acpica/nsobject.c
+++ b/drivers/acpi/acpica/nsobject.c
@@ -186,6 +186,10 @@ void acpi_ns_detach_object(struct acpi_namespace_node *node)
}
}
+ if (obj_desc->common.type == ACPI_TYPE_REGION) {
+ acpi_ut_remove_address_range(obj_desc->region.space_id, node);
+ }
+
/* Clear the Node entry in all cases */
node->object = NULL;
--
2.17.2
ACPICA commit b233720031a480abd438f2e9c643080929d144c3
ASL operation_regions declare a range of addresses that it uses. In a
perfect world, the range of addresses should be used exclusively by
the AML interpreter. The OS can use this information to decide which
drivers to load so that the AML interpreter and device drivers use
different regions of memory.
During table load, the address information is added to a global
address range list. Each node in this list contains an address range
as well as a namespace node of the operation_region. This list is
deleted at ACPI shutdown.
Unfortunately, ASL operation_regions can be declared inside of control
methods. Although this is not recommended, modern firmware contains
such code. New module level code changes unintentionally removed the
functionality of adding and removing nodes to the global address
range list.
A few months ago, support for adding addresses has been re-
implemented. However, the removal of the address range list was
missed and resulted in some systems to crash due to the address list
containing bogus namespace nodes from operation_regions declared in
control methods. In order to fix the crash, this change removes
dynamic operation_regions after control method termination.
Link: https://github.com/acpica/acpica/commit/b2337200
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475
Cc: stable(a)vger.kernel.org # 4.20+
Fixes: 4abb951b73ff (ACPICA: AML interpreter: add region addresses in global list during initialization)
Reported-by: Michael J Gruber <mjg(a)fedoraproject.org>
Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com>
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
---
drivers/acpi/acpica/nsobject.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/acpica/nsobject.c b/drivers/acpi/acpica/nsobject.c
index 8638f43cfc3d..79d86da1c892 100644
--- a/drivers/acpi/acpica/nsobject.c
+++ b/drivers/acpi/acpica/nsobject.c
@@ -186,6 +186,10 @@ void acpi_ns_detach_object(struct acpi_namespace_node *node)
}
}
+ if (obj_desc->common.type == ACPI_TYPE_REGION) {
+ acpi_ut_remove_address_range(obj_desc->region.space_id, node);
+ }
+
/* Clear the Node entry in all cases */
node->object = NULL;
--
2.17.2
On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
>
> v5.0.6: Failed to apply! Possible dependencies:
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>
> v4.19.33: Failed to apply! Possible dependencies:
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>
> v4.14.110: Failed to apply! Possible dependencies:
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>
This is a minor context difference. There is no actual dependency on the
c0ad4aa4d841 patch. It would be easy to produce new version that could
go in these trees. I'm not sure what the right action is in that case.
Should I spin a new version with the different locking in the context?
Also, I can't find this commit in tip. It's visible in gitweb but it's not
in the tip tree as far as I can tell.
> v4.9.167: Failed to apply! Possible dependencies:
> 8a8c69c32778 ("sched/core: Add rq->lock wrappers")
> 92509b732baf ("sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock")
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> cb42c9a3ebbb ("sched/core: Add debugging code to catch missing update_rq_clock() calls")
> d1ccc66df8bf ("sched/core: Clean up comments")
> d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()")
>
> v4.4.178: Failed to apply! Possible dependencies:
> 2a67e741bbbc ("rcu: Create transitive rnp->lock acquisition functions")
> 3e71a462dd48 ("sched/core: Move task_rq_lock() out of line")
> 3ea94de15ce9 ("sched/core: Fix incorrect wait time and wait count statistics")
> 46a5d164db53 ("rcu: Stop disabling interrupts in scheduler fastpaths")
> 8a8c69c32778 ("sched/core: Add rq->lock wrappers")
> 958c5f848e17 ("stop_machine: Change stop_one_cpu() to rely on cpu_stop_queue_work()")
> bf89a304722f ("stop_machine: Avoid a sleep and wakeup in stop_one_cpu()")
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default")
> d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()")
> e7904a28f533 ("locking/lockdep, sched/core: Implement a better lock pinning scheme")
> fecbf6f01fbd ("rcu: Simplify rcu_sched_qs() control flow")
>
> v3.18.138: Failed to apply! Possible dependencies:
> 1a43a14a5bd9 ("sched: Fix schedule_tail() to disable preemption")
> 1b537c7d1e58 ("sched/core: Remove check of p->sched_class")
> 1d7e974cbf2f ("sched/deadline: Don't check SD_BALANCE_FORK")
> 3960c8c0c789 ("sched: Make dl_task_time() use task_rq_lock()")
> 3e71a462dd48 ("sched/core: Move task_rq_lock() out of line")
> 4c9a4bc89a9c ("sched: Allow balance callbacks for check_class_changed()")
> 5cc389bcee08 ("sched: Move code around")
> 5e16bbc2fb40 ("sched: Streamline the task migration locking a little")
> 67dfa1b756f2 ("sched/deadline: Implement cancel_dl_timer() to use in switched_from_dl()")
> 6c1d9410f007 ("sched: Move p->nr_cpus_allowed check to select_task_rq()")
> 74b8a4cb6ce3 ("sched: Clarify ordering between task_rq_lock() and move_queued_task()")
> 8a8c69c32778 ("sched/core: Add rq->lock wrappers")
> c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> cbce1a686700 ("sched,lockdep: Employ lock pinning")
> dfa50b605c2a ("sched: Make finish_task_switch() return 'struct rq *'")
> f4e9d94a5bf6 ("sched/deadline: Don't balance during wakeup if wakee is pinned")
>
>
> How should we proceed with this patch?
>
I haven't look that far back. This patch should be pretty self contained. I don't
think it's worth pulling it back to these trees if it would require all of these
patches. The risk would out-weigh the reward.
Cheers,
Phil
> --
> Thanks,
> Sasha
--
shadow mm's pin count got increased in workload preparation phase, which
is after workload scanning.
it will get decreased in complete_current_workload() anyway after
workload completion.
Sometimes, if a workload meets a scanning error, its shadow mm pin count
will not get increased but will get decreased in the end.
This patch lets shadow mm's pin count not go below 0.
v2: add fixes tag and cc stable kernel (zhenyu wang)
Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization")
Cc: zhenyuw(a)linux.intel.com
Cc: stable(a)vger.kernel.org #4.14+
Signed-off-by: Yan Zhao <yan.y.zhao(a)intel.com>
---
upstream commit id: 663a50ceac75c2208d2ad95365bc8382fd42f44d
---
drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index dadacbe558ab..1a1f7eb46d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1629,7 +1629,7 @@ void intel_vgpu_unpin_mm(struct intel_vgpu_mm *mm)
if (WARN_ON(mm->type != INTEL_GVT_MM_PPGTT))
return;
- atomic_dec(&mm->pincount);
+ atomic_dec_if_positive(&mm->pincount);
}
/**
--
2.17.1
Hi Greg,
This was not marked for stable but it fixes a commit which has been
backported to 4.14-stable.
1) 5b06bbcfc2c6 fixes ca37e57bbe0c
2) 7ee18d677989 will again fix 5b06bbcfc2c6
But you will need to add:
090edbe23ff5 ("x86/power/64: Use struct desc_ptr for the IDT in struct saved_context")
and
896c80bef4d3 ("x86/power/32: Move SYSENTER MSR restoration to fix_processor_context()")
to apply 7ee18d677989.
All of them are attached to this mail for you.
--
Regards
Sudip
This commit was first released with 5.0:
commit 9ebdfe5230f2e50e3ba05c57723a06e90946815a
Author: Jim Mattson <jmattson(a)google.com>
Date: Mon Nov 26 11:22:32 2018 -0800
kvm: nVMX: NMI-window and interrupt-window exiting should wake L2 from HLT
According to the SDM, "NMI-window exiting" VM-exits wake a logical
processor from the same inactive states as would an NMI and
"interrupt-window exiting" VM-exits wake a logical processor from the
same inactive states as would an external interrupt. Specifically, they
wake a logical processor from the shutdown state and from the states
entered using the HLT and MWAIT instructions.
Fixes: 6dfacadd5858 ("KVM: nVMX: Add support for activity state HLT")
Signed-off-by: Jim Mattson <jmattson(a)google.com>
Reviewed-by: Peter Shier <pshier(a)google.com>
Suggested-by: Sean Christopherson <sean.j.christopherson(a)intel.com>
[Squashed comments of two Jim's patches and used the simplified code
hunk provided by Sean. - Radim]
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
This commit does not apply clean to 4.19, only due to restructuring
that split out a portion of arch/x86/kvm/vmx.c into
arch/x86/kvm/vmx/nested.c.
The following procedure can be followed to allow the patch to apply
clean to 4.19:
git checkout linux-4.19.y
git format-patch -1 9ebdfe5230f2e50e3ba05c57723a06e90946815a
perl -pi -e 's[arch/x86/kvm/vmx/nested.c][arch/x86/kvm/vmx.c]g'
0001-kvm-nVMX-NMI-window-and-interrupt-window-exiting-sho.patch
git am 0001-kvm-nVMX-NMI-window-and-interrupt-window-exiting-sho.patch
I have been using this patch in our own 4.19-based production
environment (which heavily uses nested KVM for product simulation)
since January, 2019, along with several other nVMX patches. All of the
other nVMX patches have since made it into 4.19 except for this one. I
expect this one did not make the stable list because it did not apply
cleanly without help.
I don't have a specific test to reproduce the problem that this fix
addresses. I had specific problems that were addressed by other nVMX
patches, but this was one I chose to add as a preventative measure
based upon the description and the likelihood that the problem might
impact us.
Please consider including this patch into 4.19. I don't mind
maintaining it local if there is some reason it doesn't qualify for
stable. But, if this could help others, I'm happy to share the above
method of getting it into 4.19 safely.
Thank you!
--
Mark Mielke <mark.mielke(a)gmail.com>
-Werror can be handy for development, but enabling it for production
builds is a bad idea -- other compilers might produce unexpected
warnings, or #included library headers might trigger warnings.
In my case, libelf's (not elfutil's!) headers trigger several -Wundef
warnings. This wasn't a problem before 056d28d135bc, since gcc doesn't
emit warnings for system headers, but now that there's a
-I/usr/include/libelf/ in the gcc command line, those warnings appear
and break the build.
CC'ing stable@ since 056d28d135bc has also been included in stable
versions.
Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location")
Signed-off-by: Luis Ressel <aranea(a)aixah.de>
Cc: stable(a)vger.kernel.org
---
tools/objtool/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 53f8be0f4a1f..ad2c11a881db 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -34,7 +34,7 @@ INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/objtool/arch/$(ARCH)/include
WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS)
+CFLAGS += $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS)
LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
# Allow old libelf to be used:
--
2.21.0
Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when
configuring the kernel, then two machines were reported to have noise
after installing the new kernel. Put them in the blacklist, the
noise disappears.
https://bugs.launchpad.net/bugs/1821663
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang(a)canonical.com>
---
In the V2, put the Intel entry in the blacklist according to pciid's
order, and change the machine name "Intel Laptop 8086:2064" to
"Intel SDP 8086:2064".
sound/pci/hda/hda_intel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index ece256a3b48f..2ec91085fa3e 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2142,6 +2142,8 @@ static struct snd_pci_quirk power_save_blacklist[] = {
SND_PCI_QUIRK(0x8086, 0x2040, "Intel DZ77BH-55K", 0),
/* https://bugzilla.kernel.org/show_bug.cgi?id=199607 */
SND_PCI_QUIRK(0x8086, 0x2057, "Intel NUC5i7RYB", 0),
+ /* https://bugs.launchpad.net/bugs/1821663 */
+ SND_PCI_QUIRK(0x8086, 0x2064, "Intel SDP 8086:2064", 0),
/* https://bugzilla.redhat.com/show_bug.cgi?id=1520902 */
SND_PCI_QUIRK(0x8086, 0x2068, "Intel NUC7i3BNB", 0),
/* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
@@ -2150,6 +2152,8 @@ static struct snd_pci_quirk power_save_blacklist[] = {
SND_PCI_QUIRK(0x17aa, 0x367b, "Lenovo IdeaCentre B550", 0),
/* https://bugzilla.redhat.com/show_bug.cgi?id=1572975 */
SND_PCI_QUIRK(0x17aa, 0x36a7, "Lenovo C50 All in one", 0),
+ /* https://bugs.launchpad.net/bugs/1821663 */
+ SND_PCI_QUIRK(0x1631, 0xe017, "Packard Bell NEC IMEDIA 5204", 0),
{}
};
#endif /* CONFIG_PM */
--
2.17.1