Gen12 hw are failing to enable lpsp configuration due to PG3 was left on
due to valid usgae count of POWER_DOMAIN_AUDIO.
It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling
a crtc, it should be always i915_audio_component request to get/put
AUDIO_POWER_DOMAIN.
Cc: stable(a)vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta(a)intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 6c3b11de2daf..f31a579d7a52 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct intel_crtc_state *crtc_state)
mask |= BIT_ULL(intel_encoder->power_domain);
}
- if (HAS_DDI(dev_priv) && crtc_state->has_audio)
+ /*
+ * Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
+ * enable AUDIO power in order to enable a crtc.
+ */
+ if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) && crtc_state->has_audio)
mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
if (crtc_state->shared_dpll)
--
2.26.2
Summary: Security Advisory - linux - CVE-2020-10751
Tech Review: Xiao
Gatekeeper: Yue Tao
Lockdown Approval (if needed):
Branch Tag: LTS19, LTS18
IP Statement (form link or license statement, usually automated):
Crypto URL(s) (if needed): see http://wiki.wrs.com/PBUeng/LinuxProductDivisionExportProcess
Parent Template (where applicable):
-------------------------------------
Impacted area Impact y/n
------------------- -----------
docs/tech-pubs n
tests n
build system n
host dependencies n
RPM/packaging n
toolchain n
kernel code y
user code n
configuration files n
target configuration n
Other n
Applicable to Yocto/upstream n
New Kernel Warnings n
Comments (indicate scope for each "y" above):
---------------------------------------------
>From 11d31c9c777c235630d9a72bf316f48c5036e609 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 28 Apr 2020 09:59:02 -0400
Subject: [PATCH] selinux: properly handle multiple messages in
selinux_netlink_send()
commit fb73974172ffaaf57a7c42f35424d9aece1a5af6 upstream.
Fix the SELinux netlink_send hook to properly handle multiple netlink
messages in a single sk_buff; each message is parsed and subject to
SELinux access control. Prior to this patch, SELinux only inspected
the first message in the sk_buff.
Cc: stable(a)vger.kernel.org
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: Stephen Smalley <stephen.smalley.work(a)gmail.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
[OP: backport of eeef0d9fd40 from branch linux-5.4.y of linux-stable]
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
Added Files:
------------
No.
Removed Files:
--------------
No.
Remaining Changes (diffstat):
-----------------------------
security/selinux/hooks.c | 70 ++++++++++++++++++++++++++--------------
1 file changed, 45 insertions(+), 25 deletions(-)
Testing Applicable to:
----------------------
intel-x86-64
Testing Commands:
-----------------
CONFIG_SECURITY_SELINUX=y
bitbake virtual/kernel
Testing, Expected Results:
--------------------------
Build OK. No build err/warning caused by this modification.
Conditions of submission:
-------------------------
Build OK. No build err/warning caused by this modification.
Boot in qemu OK.
Arch built boot boardname
-------------------------------------
MIPS n n
MIPS64 n n
MIPS64n32 n n
ARM32 n n
ARM64 n n
x86 n n
x86_64 y n intel-x86-64
PPC n n
PPC64 n n
SPARC64 n n
On 2020-05-22 01:46, Robin Murphy wrote:
> On 2020-05-21 12:30, Prakash Gupta wrote:
>> Limit the iova size while freeing based on unmapped size. In absence
>> of
>> this even with unmap failure, invalid iova is pushed to iova rcache
>> and
>> subsequently can cause panic while rcache magazine is freed.
>
> Can you elaborate on that panic?
>
We have seen couple of stability issues around this.
Below is one such example:
kernel BUG at kernel/msm-4.19/drivers/iommu/iova.c:904!
iova_magazine_free_pfns
iova_rcache_insert
free_iova_fast
__iommu_unmap_page
iommu_dma_unmap_page
It turned out an iova pfn 0 got into iova_rcache. One possibility I see
is
where client unmap with invalid dma_addr. The unmap call will fail and
warn on
and still try to free iova. This will cause invalid pfn to be inserted
into
rcache. As and when the magazine with invalid pfn will be freed
private_find_iova() will return NULL for invalid iova and meet bug
condition.
>> Signed-off-by: Prakash Gupta <guptap(a)codeaurora.org>
>>
>> :100644 100644 4959f5df21bd 098f7d377e04 M drivers/iommu/dma-iommu.c
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index 4959f5df21bd..098f7d377e04 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -472,7 +472,8 @@ static void __iommu_dma_unmap(struct device *dev,
>> dma_addr_t dma_addr,
>> if (!cookie->fq_domain)
>> iommu_tlb_sync(domain, &iotlb_gather);
>> - iommu_dma_free_iova(cookie, dma_addr, size);
>> + if (unmapped)
>> + iommu_dma_free_iova(cookie, dma_addr, unmapped);
>
> Frankly, if any part of the unmap fails then things have gone
> catastrophically wrong already, but either way this isn't right. The
> IOVA API doesn't support partial freeing - an IOVA *must* be freed
> with its original size, or not freed at all, otherwise it will corrupt
> the state of the rcaches and risk a cascade of further misbehaviour
> for future callers.
>
I agree, we shouldn't be freeing the partial iova. Instead just making
sure if unmap was successful should be sufficient before freeing iova.
So change
can instead be something like this:
- iommu_dma_free_iova(cookie, dma_addr, size);
+ if (unmapped)
+ iommu_dma_free_iova(cookie, dma_addr, size);
> TBH my gut feeling here is that you're really just trying to treat a
> symptom of another bug elsewhere, namely some driver calling
> dma_unmap_* or dma_free_* with the wrong address or size in the first
> place.
>
This condition would arise only if driver calling dma_unmap/free_* with
0
iova_pfn. This will be flagged with a warning during unmap but will
trigger
panic later on while doing unrelated dma_map/unmap_*. If unmapped has
already
failed for invalid iova, there is no reason we should consider this as
valid
iova and free. This part should be fixed.
On 2020-05-22 00:19, Andrew Morton wrote:
> I think we need a cc:stable here?
>
Added now.
Thanks,
Prakash