NULL pointer dereference in i915_gem_request_alloc()
Hi Chris, I've uncovered a bug in i915_gem_request_alloc(): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_gem_request.c?h=v4.9#n425 ctx here may be NULL, and i915_gem_context_get() is unconditionally adding a reference to the supplied ctx, which makes things go boom when NULL. This happens for me in practice via: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c?h=v4.9#n12317 It appears engine->last_context may be NULL. The comment heading i915_gem_request_alloc() states that ctx shall be NULL and that an appropriate context will be chosen automatically. This is not what is currently implemented. My reproducer is an unaccelerated drm graphics toy which just sets a mode and submits page flips using dumb buffers. If I start Xorg first, the bug doesn't trigger, presumably because engine->last_context gets initialized. But running the toy from the console immediately after booting without starting Xorg, i915 explodes. I would have only mailed dri-devel but my last email there seems to be lost in a moderation queue, and I'd rather not subscribe to another relatively high-volume list. I've CC'd the list just in case it gets through. Thanks, Vito Caputo
RFC: fb restore on drm master close
On Wed, Jan 04, 2017 at 12:38:04AM -0800, St??phane Marchesin wrote: > On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter wrote: > > On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo at pengaru.com wrote: > >> Hello list, > >> > >> I've been playing with an unaccelerated drm program[1] and have been > >> annoyed that whenever this program exits the fbcon isn't restored, with > >> the display left completely off. > >> > >> This seems to happen because Xorg is still running from a different VT. > >> > >> Upon further investigation, it seems like the fb restore only occurs on > >> "lastclose", which explains what I'm observing. > >> > >> Why don't we perform the fb restore whenever the current master is > >> closed to cover this case, since masters are the ones that can change > >> modes? > > One case where it's useful not to do this is the handoff from a splash > screen to a display server. > If the handoff is avoiding the existing lastclose semantics somehow by having overlapping opens, couldn't drmDropMaster() be employed to avoid the masterclose restore when the splash screen closes? Regards, Vito Caputo
4.10-rc2 i915 LVDS display noise on X61s thinkpad
Hi All, Booted 4.10-rc2 today, and the display shows random spots of flickering short horizontal bars 1px tall, maybe 8 or 16px wide. Machine is the venerable X61s thinkpad, 1.8ghz, XGA. Problem was not present on 4.9.0, same kernel config. I'll see if I can get around to bisecting, consider this a heads-up. Attached config for the curious, it's clearly visible in my drm eye candy toy https://github.com/vcaputo/rototiller. Not on list so please CC me in replies, thanks Cheers, Vito Caputo -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.10.0-rc2 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEBUG_RODATA=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_MEMCG is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_DEBUG is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_N
NULL pointer dereference in i915_gem_request_alloc()
On Mon, Jan 02, 2017 at 10:09:35AM +, Chris Wilson wrote: > On Sun, Jan 01, 2017 at 03:16:31PM -0600, vcaputo at pengaru.com wrote: > > Hi Chris, > > > > I've uncovered a bug in i915_gem_request_alloc(): > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_gem_request.c?h=v4.9#n425 > > > > ctx here may be NULL, and i915_gem_context_get() is unconditionally > > adding a reference to the supplied ctx, which makes things go boom when > > NULL. > > ctx is not allowed to be NULL. > > > This happens for me in practice via: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c?h=v4.9#n12317 > > > > It appears engine->last_context may be NULL. > > It was meant to be using mmioflip if last_context was NULL, since we can > do that immediately (i.e. lower latency) than via queuing the csflip. > > > The comment heading i915_gem_request_alloc() states that ctx shall be > > NULL and that an appropriate context will be chosen automatically. This > > is not what is currently implemented. > > Comment is wrong. Ok, that makes sense, and thanks for the response. Is it appropriate to consider it fixed upstream at this point or is anything else needed from my end? Cheers, Vito Caputo
RFC: fb restore on drm master close
Hello list, I've been playing with an unaccelerated drm program[1] and have been annoyed that whenever this program exits the fbcon isn't restored, with the display left completely off. This seems to happen because Xorg is still running from a different VT. Upon further investigation, it seems like the fb restore only occurs on "lastclose", which explains what I'm observing. Why don't we perform the fb restore whenever the current master is closed to cover this case, since masters are the ones that can change modes? My github has a quick-n-dirty i915 implementation[2] which seems to fix this without negative effects, though I haven't exhaustively tested to see what breaks. This isn't a list I subscribe to so please CC me directly in any replies, thanks everyone! Regards, Vito Caputo 1. https://github.com/vcaputo/rototiller 2. https://github.com/torvalds/linux/compare/master...vcaputo:masterclose?expand=1
