- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] [PATCH] crypto: algapi - fix NULL dereference in crypto_remove_spawns()

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot <syzkaller(a)googlegroups.com> Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/algapi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/crypto/algapi.c b/crypto/algapi.c index 9895cafcce7e..395b082d03a9 100644 --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -166,6 +166,18 @@ void crypto_remove_spawns(struct crypto_alg *alg, struct list_head *list, spawn->alg = NULL; spawns = &inst->alg.cra_users; + + /* + * We may encounter an unregistered instance here, since + * an instance's spawns are set up prior to the instance + * being registered. An unregistered instance will have + * NULL ->cra_users.next, since ->cra_users isn't + * properly initialized until registration. But an + * unregistered instance cannot have any users, so treat + * it the same as ->cra_users being empty. + */ + if (spawns->next == NULL) + break; } } while ((spawns = crypto_more_spawns(alg, &stack, &top, &secondary_spawns))); -- 2.15.1

7 years, 4 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH 4.14 00/14] 4.14.12-stable review

by Greg Kroah-Hartman

On Thu, Jan 04, 2018 at 04:12:31PM -0800, Kevin Hilman wrote: > kernelci.org bot <bot(a)kernelci.org> writes: > > > stable-rc/linux-4.14.y boot: 118 boots: 4 failed, 113 passed with 1 offline (v4.14.11-15-g732141e47ee6) > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.11-15… > > > > Tree: stable-rc > > Branch: linux-4.14.y > > Git Describe: v4.14.11-15-g732141e47ee6 > > Git Commit: 732141e47ee614d70aeb8ad828a977ad19447e87 > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 68 unique boards, 23 SoC families, 16 builds out of 185 > > > > Boot Regressions Detected: > > TL;DR; All is well. Thanks for the summary of all of these, and for your continued testing. greg k-h

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/i915: forward hotplug events again

by Rodrigo Vivi

As mentioned on commit '88be58be886f ("drm/i915/fbdev: Always forward hotplug events") we have real valid cases of hotplugs where fbdev is not fully setup yet. Unfortunately this remove the checkpoint after the sync point. So probably we can live without it. Or we need a more robust serialization. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Fixes: a45b30a6c5db ("drm/i915/fbdev: Serialise early hotplug events with async fbdev config") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Lukas Wunner <lukas(a)wunner.de> Cc: jrg2718(a)gmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> --- drivers/gpu/drm/i915/intel_fbdev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index da48af11eb6b..7a6069b389f2 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -801,8 +801,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev) return; intel_fbdev_sync(ifbdev); - if (ifbdev->vma) - drm_fb_helper_hotplug_event(&ifbdev->helper); + drm_fb_helper_hotplug_event(&ifbdev->helper); } void intel_fbdev_restore_mode(struct drm_device *dev) -- 2.13.6

7 years, 4 months

2
1
0 0

Re: [Linux-stable-mirror] [Intel-gfx] [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

by Rodrigo Vivi

On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote: > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote: > > Quoting Kenneth Graunke (2018-01-04 19:38:05) > > > Geminilake requires the 3D driver to select whether barriers are > > > intended for compute shaders, or tessellation control shaders, by > > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when > > > switching pipelines. Failure to do this properly can result in GPU > > > hangs. > > > > > > Unfortunately, this means it needs to switch mid-batch, so only > > > userspace can properly set it. To facilitate this, the kernel needs > > > to whitelist the register. > > > > > > Signed-off-by: Kenneth Graunke <kenneth(a)whitecape.org> > > > Cc: stable(a)vger.kernel.org > > > --- > > > drivers/gpu/drm/i915/i915_reg.h | 2 ++ > > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++ > > > 2 files changed, 7 insertions(+) > > > > > > Hello, > > > > > > We unfortunately need to whitelist an extra register for GPU hang fix > > > on Geminilake. Here's the corresponding Mesa patch: > > > > Thankfully it appears to be context saved. Has a w/a name been assigned > > for this? > > -Chris > > There doesn't appear to be one. The workaround page lists it, but there > is no name. The register description has a note saying that you need to > set this, but doesn't call it out as a workaround. It mentions only BXT:ALL, but not mention to GLK. Should we add to both then? > > That's why I put a generic comment, rather than the name. On Display side we started using the row name for this case, to help easily finding this later. ex: "Display WA #0390: skl,kbl" The number for this apparently is: WA #0862 Maybe we could use this one to start /* GT WA #0862: bxt,glk */ GT? GEM? Unnamed WA #0862? Thanks, Rodrigo. > > --Ken > _______________________________________________ > Intel-gfx mailing list > Intel-gfx(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [patch 8/9] userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails

by akpm＠linux-foundation.org

From: Andrea Arcangeli <aarcange(a)redhat.com> Subject: userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails The previous fix 384632e67e0829 ("userfaultfd: non-cooperative: fix fork use after free") corrected the refcounting in case of UFFD_EVENT_FORK failure for the fork userfault paths. That still didn't clear the vma->vm_userfaultfd_ctx of the vmas that were set to point to the aborted new uffd ctx earlier in dup_userfaultfd. Link: http://lkml.kernel.org/r/20171223002505.593-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff -puN fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails fs/userfaultfd.c --- a/fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails +++ a/fs/userfaultfd.c @@ -570,11 +570,14 @@ out: static void userfaultfd_event_wait_completion(struct userfaultfd_ctx *ctx, struct userfaultfd_wait_queue *ewq) { + struct userfaultfd_ctx *release_new_ctx; + if (WARN_ON_ONCE(current->flags & PF_EXITING)) goto out; ewq->ctx = ctx; init_waitqueue_entry(&ewq->wq, current); + release_new_ctx = NULL; spin_lock(&ctx->event_wqh.lock); /* @@ -601,8 +604,7 @@ static void userfaultfd_event_wait_compl new = (struct userfaultfd_ctx *) (unsigned long) ewq->msg.arg.reserved.reserved1; - - userfaultfd_ctx_put(new); + release_new_ctx = new; } break; } @@ -617,6 +619,20 @@ static void userfaultfd_event_wait_compl __set_current_state(TASK_RUNNING); spin_unlock(&ctx->event_wqh.lock); + if (release_new_ctx) { + struct vm_area_struct *vma; + struct mm_struct *mm = release_new_ctx->mm; + + /* the various vma->vm_userfaultfd_ctx still points to it */ + down_write(&mm->mmap_sem); + for (vma = mm->mmap; vma; vma = vma->vm_next) + if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) + vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX; + up_write(&mm->mmap_sem); + + userfaultfd_ctx_put(release_new_ctx); + } + /* * ctx may go away after this if the userfault pseudo fd is * already released. _

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [patch 7/9] mm/sparse.c: wrong allocation for mem_section

by akpm＠linux-foundation.org

From: Baoquan He <bhe(a)redhat.com> Subject: mm/sparse.c: wrong allocation for mem_section In 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") mem_section is allocated at runtime to save memory. While it allocates the first dimension of array with sizeof(struct mem_section). It costs extra memory, should be sizeof(struct mem_section*). Fix it. Link: http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-bhe@redhat.com Fixes: 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") Signed-off-by: Baoquan He <bhe(a)redhat.com> Tested-by: Dave Young <dyoung(a)redhat.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Atsushi Kumagai <ats-kumagai(a)wm.jp.nec.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section mm/sparse.c --- a/mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section +++ a/mm/sparse.c @@ -211,7 +211,7 @@ void __init memory_present(int nid, unsi if (unlikely(!mem_section)) { unsigned long size, align; - size = sizeof(struct mem_section) * NR_SECTION_ROOTS; + size = sizeof(struct mem_section*) * NR_SECTION_ROOTS; align = 1 << (INTERNODE_CACHE_SHIFT); mem_section = memblock_virt_alloc(size, align); } _

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [patch 3/9] mm/mprotect: add a cond_resched() inside change_pmd_range()

by akpm＠linux-foundation.org

From: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Subject: mm/mprotect: add a cond_resched() inside change_pmd_range() While testing on a large CPU system, detected the following RCU stall many times over the span of the workload. This problem is solved by adding a cond_resched() in the change_pmd_range() function. [ 850.962530] INFO: rcu_sched detected stalls on CPUs/tasks: [ 850.962584] 154-....: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612 [ 850.962605] (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864) [ 850.962895] Sending NMI from CPU 955 to CPUs 154: [ 850.992667] NMI backtrace for cpu 154 [ 850.993069] CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3 [ 850.993258] NIP: c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18 [ 850.993503] REGS: 00000000a4b0fb44 TRAP: 0501 Not tainted (4.15.0-rc3+) [ 850.993707] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22422082 XER: 00000000 [ 850.994386] CFAR: 00000000006cf8f0 SOFTE: 1 GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000 GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00 GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00 GPR12: ffffffffffffffff c00000000fb25100 [ 850.995976] NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c [ 850.996174] LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420 [ 850.996401] Call Trace: [ 850.996600] [c00003ef9b1cb8c0] [c00003fa8fff7d40] 0xc00003fa8fff7d40 (unreliable) [ 850.996959] [c00003ef9b1cba40] [c0000000000688a8] flush_hash_range+0x48/0x100 [ 850.997261] [c00003ef9b1cba90] [c000000000071b14] __flush_tlb_pending+0x44/0xd0 [ 850.997600] [c00003ef9b1cbac0] [c000000000071fa8] hpte_need_flush+0x408/0x470 [ 850.997958] [c00003ef9b1cbb30] [c0000000002c646c] change_protection_range+0xaac/0xf10 [ 850.998180] [c00003ef9b1cbcb0] [c0000000002f2510] change_prot_numa+0x30/0xb0 [ 850.998502] [c00003ef9b1cbce0] [c00000000013a950] task_numa_work+0x2d0/0x3e0 [ 850.998816] [c00003ef9b1cbda0] [c00000000011ea30] task_work_run+0x130/0x190 [ 850.999121] [c00003ef9b1cbe00] [c00000000001bcd8] do_notify_resume+0x118/0x120 [ 850.999421] [c00003ef9b1cbe30] [c00000000000b744] ret_from_except_lite+0x70/0x74 [ 850.999716] Instruction dump: [ 850.999959] 60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378 [ 851.000575] e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008 Link: http://lkml.kernel.org/r/20171214140551.5794-1-khandual@linux.vnet.ibm.com Signed-off-by: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Suggested-by: Nicholas Piggin <npiggin(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mprotect.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -puN mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range mm/mprotect.c --- a/mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range +++ a/mm/mprotect.c @@ -166,7 +166,7 @@ static inline unsigned long change_pmd_r next = pmd_addr_end(addr, end); if (!is_swap_pmd(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd) && pmd_none_or_clear_bad(pmd)) - continue; + goto next; /* invoke the mmu notifier if the pmd is populated */ if (!mni_start) { @@ -188,7 +188,7 @@ static inline unsigned long change_pmd_r } /* huge pmd was handled */ - continue; + goto next; } } /* fall through, the trans huge pmd just split */ @@ -196,6 +196,8 @@ static inline unsigned long change_pmd_r this_pages = change_pte_range(vma, pmd, addr, next, newprot, dirty_accountable, prot_numa); pages += this_pages; +next: + cond_resched(); } while (pmd++, addr = next, addr != end); if (mni_start) _

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [patch 2/9] kernel/acct.c: fix the acct->needcheck check in check_free_space()

by akpm＠linux-foundation.org

From: Oleg Nesterov <oleg(a)redhat.com> Subject: kernel/acct.c: fix the acct->needcheck check in check_free_space() As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check is very wrong, we need time_is_after_jiffies() to make sys_acct() work. Ignoring the overflows, the code should "goto out" if needcheck > jiffies, while currently it checks "needcheck < jiffies" and thus in the likely case check_free_space() does nothing until jiffies overflow. In particular this means that sys_acct() is simply broken, acct_on() sets acct->needcheck = jiffies and expects that check_free_space() should set acct->active = 1 after the free-space check, but this won't happen if jiffies increments in between. This was broken by commit 32dc73086015 ("get rid of timer in kern/acct.c") in 2011, then another (correct) commit 795a2f22a8ea ("acct() should honour the limits from the very beginning") made the problem more visible. Link: http://lkml.kernel.org/r/20171213133940.GA6554@redhat.com Fixes: 32dc73086015 ("get rid of timer in kern/acct.c") Reported-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp> Suggested-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp> Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/acct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space kernel/acct.c --- a/kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space +++ a/kernel/acct.c @@ -102,7 +102,7 @@ static int check_free_space(struct bsd_a { struct kstatfs sbuf; - if (time_is_before_jiffies(acct->needcheck)) + if (time_is_after_jiffies(acct->needcheck)) goto out; /* May block */ _

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs

by Benjamin Gilbert

[resending with less web] Hi all, In our regression tests on kernel 4.14.11, we're occasionally seeing a run of "bad pmd" messages during boot, followed by a "BUG: unable to handle kernel paging request". This happens on no more than a couple percent of boots, but we've seen it on AWS HVM, GCE, Oracle Cloud VMs, and local QEMU instances. It always happens immediately after "Loading compiled-in X.509 certificates". I can't reproduce it on 4.14.10, nor, so far, on 4.14.11 with pti=off. Here's a sample backtrace: [ 4.762964] Loading compiled-in X.509 certificates [ 4.765620] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee000(800000007d6000e3) [ 4.769099] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee008(800000007d8000e3) [ 4.772479] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee010(800000007da000e3) [ 4.775919] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee018(800000007dc000e3) [ 4.779251] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee020(800000007de000e3) [ 4.782558] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee028(800000007e0000e3) [ 4.794160] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee030(800000007e2000e3) [ 4.797525] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee038(800000007e4000e3) [ 4.800776] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee040(800000007e6000e3) [ 4.804100] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee048(800000007e8000e3) [ 4.807437] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee050(800000007ea000e3) [ 4.810729] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee058(800000007ec000e3) [ 4.813989] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee060(800000007ee000e3) [ 4.817294] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee068(800000007f0000e3) [ 4.820713] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee070(800000007f2000e3) [ 4.823943] ../source/mm/pgtable-generic.c:40: bad pmd ffff8b39bf7ee078(800000007f4000e3) [ 4.827311] BUG: unable to handle kernel paging request at fffffe27c1fdfba0 [ 4.830109] IP: free_page_and_swap_cache+0x6/0xa0 [ 4.831999] PGD 7f7ef067 P4D 7f7ef067 PUD 0 [ 4.833779] Oops: 0000 [#1] SMP PTI [ 4.835197] Modules linked in: [ 4.836450] CPU: 0 PID: 45 Comm: modprobe Not tainted 4.14.11-coreos #1 [ 4.839009] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 [ 4.841551] task: ffff8b39b5a71e40 task.stack: ffffb92580558000 [ 4.844062] RIP: 0010:free_page_and_swap_cache+0x6/0xa0 [ 4.846238] RSP: 0018:ffffb9258055bc98 EFLAGS: 00010297 [ 4.848300] RAX: 0000000000000000 RBX: fffffe27c0001000 RCX: ffff8b39bf7ef4f8 [ 4.851184] RDX: 000000000007f7ee RSI: fffffe27c1fdfb80 RDI: fffffe27c1fdfb80 [ 4.854090] RBP: ffff8b39bf7ee000 R08: 0000000000000000 R09: 0000000000000162 [ 4.856946] R10: ffffffffffffff90 R11: 0000000000000161 R12: fffffe27ffe00000 [ 4.859777] R13: ffff8b39bf7ef000 R14: fffffe2800000000 R15: ffffb9258055bd60 [ 4.862602] FS: 0000000000000000(0000) GS:ffff8b39bd200000(0000) knlGS:0000000000000000 [ 4.865860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.868175] CR2: fffffe27c1fdfba0 CR3: 000000002d00a001 CR4: 00000000001606f0 [ 4.871162] Call Trace: [ 4.872188] free_pgd_range+0x3a5/0x5b0 [ 4.873781] free_ldt_pgtables.part.2+0x60/0xa0 [ 4.875679] ? arch_tlb_finish_mmu+0x42/0x70 [ 4.877476] ? tlb_finish_mmu+0x1f/0x30 [ 4.878999] exit_mmap+0x5b/0x1a0 [ 4.880327] ? dput+0xb8/0x1e0 [ 4.881575] ? hrtimer_try_to_cancel+0x25/0x110 [ 4.883388] mmput+0x52/0x110 [ 4.884620] do_exit+0x330/0xb10 [ 4.886044] ? task_work_run+0x6b/0xa0 [ 4.887544] do_group_exit+0x3c/0xa0 [ 4.889012] SyS_exit_group+0x10/0x10 [ 4.890473] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 4.892364] RIP: 0033:0x7f4a41d4ded9 [ 4.893812] RSP: 002b:00007ffe25d85708 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 4.896974] RAX: ffffffffffffffda RBX: 00005601b3c9e2e0 RCX: 00007f4a41d4ded9 [ 4.899830] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 4.902647] RBP: 00005601b3c9d0e8 R08: 000000000000003c R09: 00000000000000e7 [ 4.905743] R10: ffffffffffffff90 R11: 0000000000000246 R12: 00005601b3c9d090 [ 4.908659] R13: 0000000000000004 R14: 0000000000000001 R15: 00007ffe25d85828 [ 4.911495] Code: e0 01 48 83 f8 01 19 c0 25 01 fe ff ff 05 00 02 00 00 3e 29 43 1c 5b 5d 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 <48> 8b 57 20 48 89 fb 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 48 [ 4.919014] RIP: free_page_and_swap_cache+0x6/0xa0 RSP: ffffb9258055bc98 [ 4.921801] CR2: fffffe27c1fdfba0 [ 4.923232] ---[ end trace e79ccb938bf80a4e ]--- [ 4.925166] Kernel panic - not syncing: Fatal exception [ 4.927390] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Traces were obtained via virtual serial port. The backtrace varies a bit, as does the comm. The kernel config and a collection of backtraces are attached. Our diff on top of vanilla 4.14.11 (unchanged from 4.14.10, and containing nothing especially relevant): https://github.com/coreos/linux/compare/v4.14.11...coreos:v4.14.11-coreos I'm happy to try test builds, etc. For ease of reproduction if needed, an affected OS image: https://storage.googleapis.com/builds.developer.core-os.net/boards/amd64-us… and a wrapper script to start it with QEMU: https://storage.googleapis.com/builds.developer.core-os.net/boards/amd64-us… Get in with "ssh -p 2222 core@localhost". Corresponding debug symbols: https://storage.googleapis.com/builds.developer.core-os.net/boards/amd64-us… https://storage.googleapis.com/builds.developer.core-os.net/boards/amd64-us… --Benjamin Gilbert

7 years, 4 months

7
32
0 0

[Linux-stable-mirror] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

by Anusha Srivatsa

Since the firmwares are not yet released to public repo, disable them on Geminilake. v2: Remove the firmware versions (Michal) v3: Remove unwanted defines (Rodrigo) Correct commit message (Michal) Cc: Michal Wajdeczko <michal.wajdeczko(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Anusha Srivatsa <anusha.srivatsa(a)intel.com> Fixes: 90f192c8241e ("drm/i915/GuC/GLK: Load GuC on GLK") Fixes: db5ba0d8931e ("drm/i915/GLK/HuC: Load HuC on GLK") Reviewed-by: Michal Wajdeczko <michal.wajdeczko(a)intel.com> --- drivers/gpu/drm/i915/intel_guc_fw.c | 9 --------- drivers/gpu/drm/i915/intel_huc.c | 11 ----------- 2 files changed, 20 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c b/drivers/gpu/drm/i915/intel_guc_fw.c index cbc51c9..3b09329 100644 --- a/drivers/gpu/drm/i915/intel_guc_fw.c +++ b/drivers/gpu/drm/i915/intel_guc_fw.c @@ -39,9 +39,6 @@ #define KBL_FW_MAJOR 9 #define KBL_FW_MINOR 39 -#define GLK_FW_MAJOR 10 -#define GLK_FW_MINOR 56 - #define GUC_FW_PATH(platform, major, minor) \ "i915/" __stringify(platform) "_guc_ver" __stringify(major) "_" __stringify(minor) ".bin" @@ -54,8 +51,6 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE); #define I915_KBL_GUC_UCODE GUC_FW_PATH(kbl, KBL_FW_MAJOR, KBL_FW_MINOR) MODULE_FIRMWARE(I915_KBL_GUC_UCODE); -#define I915_GLK_GUC_UCODE GUC_FW_PATH(glk, GLK_FW_MAJOR, GLK_FW_MINOR) - static void guc_fw_select(struct intel_uc_fw *guc_fw) { struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw); @@ -82,10 +77,6 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw) guc_fw->path = I915_KBL_GUC_UCODE; guc_fw->major_ver_wanted = KBL_FW_MAJOR; guc_fw->minor_ver_wanted = KBL_FW_MINOR; - } else if (IS_GEMINILAKE(dev_priv)) { - guc_fw->path = I915_GLK_GUC_UCODE; - guc_fw->major_ver_wanted = GLK_FW_MAJOR; - guc_fw->minor_ver_wanted = GLK_FW_MINOR; } else { DRM_WARN("%s: No firmware known for this platform!\n", intel_uc_fw_type_repr(guc_fw->type)); diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index 974be3d..8ed0518 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -54,10 +54,6 @@ #define KBL_HUC_FW_MINOR 00 #define KBL_BLD_NUM 1810 -#define GLK_HUC_FW_MAJOR 02 -#define GLK_HUC_FW_MINOR 00 -#define GLK_BLD_NUM 1748 - #define HUC_FW_PATH(platform, major, minor, bld_num) \ "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \ __stringify(minor) "_" __stringify(bld_num) ".bin" @@ -74,9 +70,6 @@ MODULE_FIRMWARE(I915_BXT_HUC_UCODE); KBL_HUC_FW_MINOR, KBL_BLD_NUM) MODULE_FIRMWARE(I915_KBL_HUC_UCODE); -#define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \ - GLK_HUC_FW_MINOR, GLK_BLD_NUM) - static void huc_fw_select(struct intel_uc_fw *huc_fw) { struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw); @@ -103,10 +96,6 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw) huc_fw->path = I915_KBL_HUC_UCODE; huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR; huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR; - } else if (IS_GEMINILAKE(dev_priv)) { - huc_fw->path = I915_GLK_HUC_UCODE; - huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR; - huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR; } else { DRM_WARN("%s: No firmware known for this platform!\n", intel_uc_fw_type_repr(huc_fw->type)); -- 2.7.4

7 years, 4 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror