Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

objtool warnings in kernel/trace/ring_buffer.c #331

Closed
nickdesaulniers opened this issue Jan 27, 2019 · 2 comments
Closed

objtool warnings in kernel/trace/ring_buffer.c #331

nickdesaulniers opened this issue Jan 27, 2019 · 2 comments
Assignees
@topperc
Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 [TOOL] objtool warning is produced by the kernel's objtool

Comments

@nickdesaulniers
Copy link
Member

non asm goto related x86_64 allyesconfig mainline:

kernel/trace/ring_buffer.o: warning: objtool: rb_advance_reader()+0x523: return with modified stack frame
kernel/trace/ring_buffer.o: warning: objtool: rb_advance_reader()+0x0: stack state mismatch: cfa1=7+64 cfa2=7+8
@nickdesaulniers nickdesaulniers added [BUG] Untriaged Something isn't working [ARCH] x86_64 This bug impacts ARCH=x86_64 [TOOL] objtool warning is produced by the kernel's objtool labels Jan 27, 2019
@nickdesaulniers nickdesaulniers mentioned this issue Jan 27, 2019
Closed
@nickdesaulniers nickdesaulniers added the low priority This bug is not critical and not a priority label Jan 28, 2019
@nickdesaulniers
Copy link
Member Author

#351 (comment)
https://reviews.llvm.org/D57982

@nickdesaulniers nickdesaulniers added [BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Submitted A patch has been submitted for review and removed [BUG] Untriaged Something isn't working labels Feb 12, 2019
@tpimh tpimh removed the low priority This bug is not critical and not a priority label Mar 10, 2019
@nickdesaulniers
Copy link
Member Author

fixed in https://reviews.llvm.org/rL355947

@nickdesaulniers nickdesaulniers added [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 and removed [PATCH] Submitted A patch has been submitted for review labels May 8, 2019
nathanchance pushed a commit that referenced this issue Nov 28, 2019
@ickle @jlahtine-intel
drm/i915: Protect context while grabbing its name for the request
d231c15 
Inside print_request(), we query the context/timeline name. Nothing
immediately protects the context from being freed if the request is
complete -- we rely on serialisation by the caller to keep the name
valid until they finish using it. Inside intel_engine_dump(), we
generally only print the requests in the execution queue protected by the
engine->active.lock, but we also show the pending execlists ports which
are not protected and so require a rcu_read_lock to keep the pointer
valid.

[ 1695.700883] BUG: KASAN: use-after-free in i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.700981] Read of size 8 at addr ffff8887344f4d50 by task gem_ctx_persist/2968
[ 1695.701068]
[ 1695.701156] CPU: 1 PID: 2968 Comm: gem_ctx_persist Tainted: G     U            5.4.0-rc6+ #331
[ 1695.701246] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 1695.701334] Call Trace:
[ 1695.701424]  dump_stack+0x5b/0x90
[ 1695.701870]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.701964]  print_address_description.constprop.7+0x36/0x50
[ 1695.702408]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.702856]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.702947]  __kasan_report.cold.10+0x1a/0x3a
[ 1695.703390]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.703836]  i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.704241]  print_request+0x82/0x2e0 [i915]
[ 1695.704638]  ? fwtable_read32+0x133/0x360 [i915]
[ 1695.705042]  ? write_timestamp+0x110/0x110 [i915]
[ 1695.705133]  ? _raw_spin_lock_irqsave+0x79/0xc0
[ 1695.705221]  ? refcount_inc_not_zero_checked+0x91/0x110
[ 1695.705306]  ? refcount_dec_and_mutex_lock+0x50/0x50
[ 1695.705709]  ? intel_engine_find_active_request+0x202/0x230 [i915]
[ 1695.706115]  intel_engine_dump+0x2c9/0x900 [i915]

Fixes: c36eebd ("drm/i915/gt: execlists->active is serialised by the tasklet")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-1-chris@chris-wilson.co.uk
(cherry picked from commit fecffa4)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@topperc topperc

Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 [TOOL] objtool warning is produced by the kernel's objtool
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tpimh @nickdesaulniers @topperc