menuconfig SAMPLES
bool "Sample kernel code"
help
You can build and test sample kernel code here.
if SAMPLES
config SAMPLE_TRACE_EVENTS
tristate "Build trace_events examples -- loadable modules only"
depends on EVENT_TRACING && m
help
This build trace event example modules.
config SAMPLE_TRACE_PRINTK
tristate "Build trace_printk module - tests various trace_printk formats"
depends on EVENT_TRACING && m
help
This builds a module that calls trace_printk() and can be used to
test various trace_printk() calls from a module.
config SAMPLE_KOBJECT
tristate "Build kobject examples -- loadable modules only"
depends on m
help
This config option will allow you to build a number of
different kobject sample modules showing how to use kobjects,
ksets, and ktypes properly.
If in doubt, say "N" here.
config SAMPLE_KPROBES
tristate "Build kprobes examples -- loadable modules only"
depends on KPROBES && m
help
This build several kprobes example modules.
config SAMPLE_KRETPROBES
tristate "Build kretprobes example -- loadable modules only"
default m
depends on SAMPLE_KPROBES && KRETPROBES
config SAMPLE_HW_BREAKPOINT
tristate "Build kernel hardware breakpoint examples -- loadable module only"
depends on HAVE_HW_BREAKPOINT && m
help
This builds kernel hardware breakpoint example modules.
config SAMPLE_KFIFO
tristate "Build kfifo examples -- loadable modules only"
depends on m
help
This config option will allow you to build a number of
different kfifo sample modules showing how to use the
generic kfifo API.
If in doubt, say "N" here.
config SAMPLE_KDB
tristate "Build kdb command example -- loadable modules only"
depends on KGDB_KDB && m
help
Build an example of how to dynamically add the hello
command to the kdb shell.
config SAMPLE_RPMSG_CLIENT
tristate "Build rpmsg client sample -- loadable modules only"
depends on RPMSG && m
help
Build an rpmsg client sample driver, which demonstrates how
to communicate with an AMP-configured remote processor over
the rpmsg bus.
config SAMPLE_LIVEPATCH
tristate "Build live patching sample -- loadable modules only"
depends on LIVEPATCH && m
help
Builds a sample live patch that replaces the procfs handler
for /proc/cmdline to print "this has been live patched".
config SAMPLE_CONFIGFS
tristate "Build configfs patching sample -- loadable modules only"
depends on CONFIGFS_FS && m
help
Builds a sample configfs interface.
config SAMPLE_CONNECTOR
tristate "Build connector sample -- loadable modules only"
depends on CONNECTOR && m
help
When enabled, this builds both a sample kernel module for
the connector interface and a user space tool to communicate
with it.
See also Documentation/connector/connector.txt
config SAMPLE_SECCOMP
tristate "Build seccomp sample code -- loadable modules only"
depends on SECCOMP_FILTER && m
help
Build samples of seccomp filters using various methods of
BPF filter construction.
config SAMPLE_BLACKFIN_GPTIMERS
tristate "Build blackfin gptimers sample code -- loadable modules only"
depends on BLACKFIN && BFIN_GPTIMERS && m
help
Build samples of blackfin gptimers sample module.
config SAMPLE_VFIO_MDEV_MTTY
tristate "Build VFIO mtty example mediated device sample code -- loadable modules only"
depends on VFIO_MDEV_DEVICE && m
help
Build a virtual tty sample driver for use as a VFIO
mediated device
endif # SAMPLES
ue='2'>2
drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()
I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
call in intel_unpin_fb_obj() returns NULL, resulting in an oops
immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
tries to dereference it.
It seems to be some race condition where the object is going away at
shutdown time, since both times happened when shutting down the X
server. The call chains were different:
- VT ioctl(KDSETMODE, KD_TEXT):
intel_cleanup_plane_fb+0x5b/0xa0 [i915]
drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
intel_atomic_commit_tail+0x749/0xfe0 [i915]
intel_atomic_commit+0x3cb/0x4f0 [i915]
drm_atomic_commit+0x4b/0x50 [drm]
restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
intel_fbdev_set_par+0x18/0x70 [i915]
fb_set_var+0x236/0x460
fbcon_blank+0x30f/0x350
do_unblank_screen+0xd2/0x1a0
vt_ioctl+0x507/0x12a0
tty_ioctl+0x355/0xc30
do_vfs_ioctl+0xa3/0x5e0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x13/0x94
- i915 unpin_work workqueue:
intel_unpin_work_fn+0x58/0x140 [i915]
process_one_work+0x1f1/0x480
worker_thread+0x48/0x4d0
kthread+0x101/0x140
and this patch purely papers over the issue by adding a NULL pointer
check and a WARN_ON_ONCE() to avoid the oops that would then generally
make the machine unresponsive.
Other callers of i915_gem_object_to_ggtt() seem to also check for the
returned pointer being NULL and warn about it, so this clearly has
happened before in other places.
[ Reported it originally to the i915 developers on Jan 8, applying the
ugly workaround on my own now after triggering the problem for the
second time with no feedback.
This is likely to be the same bug reported as
https://bugs.freedesktop.org/show_bug.cgi?id=98829
https://bugs.freedesktop.org/show_bug.cgi?id=99134
which has a patch for the underlying problem, but it hasn't gotten to
me, so I'm applying the workaround. ]
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>