Hi,
I have started to look at igt for testing and want to use CRC tests. To
implement support for this I need to move away from the simple kms
helper.
When looking around for examples I came across Thomas' nice shadow
helper and thought, yes this is perfect for drm/gud. So I'll switch to
that before I move away from the simple kms helper.
The async framebuffer flushing code path now uses a shadow buffer and
doesn't touch the framebuffer when it shouldn't. I have also taken the
opportunity to inline the synchronous flush code path and make this the
default flushing stategy.
Noralf.
Cc: Maxime Ripard <mripard(a)kernel.org>
Cc: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: dri-devel(a)lists.freedesktop.org
Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org>
---
Changes in v2:
- Drop patch (Thomas):
drm/gem: shadow_fb_access: Prepare imported buffers for CPU access
- Use src as variable name for iosys_map (Thomas)
- Prepare imported buffer for CPU access in the driver (Thomas)
- New patch: make sync flushing the default (Thomas)
- Link to v1: https://lore.kernel.org/r/20221122-gud-shadow-plane-v1-0-9de3afa3383e@tronn…
---
Noralf Trønnes (6):
drm/gud: Fix UBSAN warning
drm/gud: Don't retry a failed framebuffer flush
drm/gud: Split up gud_flush_work()
drm/gud: Prepare buffer for CPU access in gud_flush_work()
drm/gud: Use the shadow plane helper
drm/gud: Enable synchronous flushing by default
drivers/gpu/drm/gud/gud_drv.c | 1 +
drivers/gpu/drm/gud/gud_internal.h | 1 +
drivers/gpu/drm/gud/gud_pipe.c | 222 ++++++++++++++++++-------------------
3 files changed, 112 insertions(+), 112 deletions(-)
---
base-commit: 7257702951305b1f0259c3468c39fc59d1ad4d8b
change-id: 20221122-gud-shadow-plane-ae37a95d4d8d
Best regards,
--
Noralf Trønnes <noralf(a)tronnes.org>
From: Rob Clark <robdclark(a)chromium.org>
vm_open() is not allowed to fail. Fortunately we are guaranteed that
the pages are already pinned, thanks to the initial mmap which is now
being cloned into a forked process, and only need to increment the
refcnt. So just increment it directly. Previously if a signal was
delivered at the wrong time to the forking process, the
mutex_lock_interruptible() could fail resulting in the pages_use_count
not being incremented.
Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
Cc: stable(a)vger.kernel.org
Signed-off-by: Rob Clark <robdclark(a)chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 3b7b71391a4c..b602cd72a120 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -571,12 +571,20 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
- int ret;
WARN_ON(shmem->base.import_attach);
- ret = drm_gem_shmem_get_pages(shmem);
- WARN_ON_ONCE(ret != 0);
+ mutex_lock(&shmem->pages_lock);
+
+ /*
+ * We should have already pinned the pages when the buffer was first
+ * mmap'd, vm_open() just grabs an additional reference for the new
+ * mm the vma is getting copied into (ie. on fork()).
+ */
+ if (!WARN_ON_ONCE(!shmem->pages_use_count))
+ shmem->pages_use_count++;
+
+ mutex_unlock(&shmem->pages_lock);
drm_gem_vm_open(vma);
}
--
2.38.1
>
> On Thu, Nov 24, 2022 at 01:08:57AM +0000, Dominic Jones wrote:
> > > On Fri, Oct 28, 2022 at 02:51:43PM +0000, Dominic Jones wrote:
> > > > Updating the machine's kernel from v5.19.x to v6.0.x causes the machine to not
> > > > successfully boot. The machine boots successfully (and exhibits stable operation)
> > > > with version v5.19.17 and multiple earlier releases in the 5.19 line. Multiple releases
> > > > from the 6.0 line (including 6.0.0, 6.0.3, and 6.0.5), with no other changes to the
> > > > software environment, do not boot. Instead, the machine hangs after loading services
> > > > but before presenting a display manager; the machine instead shows repetitive hard
> > > > drive activity at this point and then no apparent activity.
> > > >
> > > > ''uname'' output for the machine successfully running v5.19.17 is:
> > > >
> > > > Linux [MACHINE_NAME] 5.19.17 #1 SMP PREEMPT_DYNAMIC Mon Oct 24 13:32:29 2022 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
> > > >
> > > > The machine is an OCZ Neutrino netbook, running a custom OS build largely similar to
> > > > LFS development. The kernel update uses ''make olddefconfig''.
> > >
> > > Can you use 'git bisect' to find the offending change that causes this
> > > to happen?
> >
> > Bisection is complete. Here's what it returned.
> >
> > ---
> >
> > 3a194f3f8ad01bce00bd7174aaba1563bcc827eb is the first bad commit
> > commit 3a194f3f8ad01bce00bd7174aaba1563bcc827eb
> > Author: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
> > Date: Thu Jul 14 13:24:14 2022 +0900
> >
> > mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present pud entry
> >
> > follow_pud_mask() does not support non-present pud entry now. As long as
> > I tested on x86_64 server, follow_pud_mask() still simply returns
> > no_page_table() for non-present_pud_entry() due to pud_bad(), so no severe
> > user-visible effect should happen. But generally we should call
> > follow_huge_pud() for non-present pud entry for 1GB hugetlb page.
> >
> > Update pud_huge() and follow_huge_pud() to handle non-present pud entries.
> > The changes are similar to previous works for pud entries commit
> > e66f17ff7177 ("mm/hugetlb: take page table lock in follow_huge_pmd()") and
> > commit cbef8478bee5 ("mm/hugetlb: pmd_huge() returns true for non-present
> > hugepage").
> >
> > Link: https://lkml.kernel.org/r/20220714042420.1847125-3-naoya.horiguchi@linux.dev
> > Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
> > Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com>
> > Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com>
> > Cc: David Hildenbrand <david(a)redhat.com>
> > Cc: kernel test robot <lkp(a)intel.com>
> > Cc: Liu Shixin <liushixin2(a)huawei.com>
> > Cc: Muchun Song <songmuchun(a)bytedance.com>
> > Cc: Oscar Salvador <osalvador(a)suse.de>
> > Cc: Yang Shi <shy828301(a)gmail.com>
> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
> >
> > arch/x86/mm/hugetlbpage.c | 8 +++++++-
> > mm/hugetlb.c | 32 ++++++++++++++++++++++++++++++--
> > 2 files changed, 37 insertions(+), 3 deletions(-)
> >
I got two replies here, so I'm responding to both for visibility.
From Greg K H:
> Great! Please work with those developers to figure out why this is
> causing a problem for your system.
From Thorsten L:
> Many thx for this. A fix for that particular commit for recently
> committed to 6.0.y:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…
>
> That thus bears the question: does your problem still happen with the
> latest 6.0.y version?
Version 6.0.9 appears to fix the issue, with no regression as of 6.0.10.
(The issue appeared in 6.0.7. I didn't test 6.0.8 since 6.0.9 had already
appeared by the time bisection was complete.)
Thanks!
Dominic Jones
jonesd(a)xmission.com
Hello!
The first patch fixes an issue reported by Sami, where linux panic()s
when bringing secondary CPUs online. The problem was the Spectre
workarounds trying to allocate a new slot for mitigating KVM when
those pages are no longer writeable.
While debugging that issue, I spotted the Spectre-BHB KVM mitigation was
over-riding the Spectre-v2 KVM Mitigation. It's supposed to happen the
other way round.
The backports aren't the same as mainline because the spectre mitigation code
was totally rewritten for v5.10, and prior to that the KVM infrastructure
is very different.
Thanks,
James Morse (2):
arm64: Fix panic() when Spectre-v2 causes Spectre-BHB to re-allocate
KVM vectors
arm64: errata: Fix KVM Spectre-v2 mitigation selection for
Cortex-A57/A72
arch/arm64/kernel/cpu_errata.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
--
2.30.2
Hello!
The first patch fixes an issue reported by Sami, where linux panic()s
when bringing secondary CPUs online. The problem was the Spectre
workarounds trying to allocate a new slot for mitigating KVM when
those pages are no longer writeable.
While debugging that issue, I spotted the Spectre-BHB KVM mitigation was
over-riding the Spectre-v2 KVM Mitigation. It's supposed to happen the
other way round.
The backports aren't the same as mainline because the spectre mitigation code
was totally rewritten for v5.10, and prior to that the KVM infrastructure
is very different.
Thanks,
James Morse (2):
arm64: Fix panic() when Spectre-v2 causes Spectre-BHB to re-allocate
KVM vectors
arm64: errata: Fix KVM Spectre-v2 mitigation selection for
Cortex-A57/A72
arch/arm64/kernel/cpu_errata.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
--
2.30.2
Hello!
The first patch fixes an issue reported by Sami, where linux panic()s
when bringing secondary CPUs online. The problem was the Spectre
workarounds trying to allocate a new slot for mitigating KVM when
those pages are no longer writeable.
While debugging that issue, I spotted the Spectre-BHB KVM mitigation was
over-riding the Spectre-v2 KVM Mitigation. It's supposed to happen the
other way round.
The backports aren't the same as mainline because the spectre mitigation code
was totally rewritten for v5.10, and prior to that the KVM infrastructure
is very different.
Thanks,
James Morse (2):
arm64: Fix panic() when Spectre-v2 causes Spectre-BHB to re-allocate
KVM vectors
arm64: errata: Fix KVM Spectre-v2 mitigation selection for
Cortex-A57/A72
arch/arm64/kernel/cpu_errata.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
--
2.30.2