#
# Common functions used by pktgen scripts
# - Depending on bash 3 (or higher) syntax
#
# Author: Jesper Dangaaard Brouer
# License: GPL
## -- General shell logging cmds --
function err() {
local exitcode=$1
shift
echo "ERROR: $@" >&2
exit $exitcode
}
function warn() {
echo "WARN : $@" >&2
}
function info() {
if [[ -n "$VERBOSE" ]]; then
echo "INFO : $@" >&2
fi
}
## -- Pktgen proc config commands -- ##
export PROC_DIR=/proc/net/pktgen
#
# Three different shell functions for configuring the different
# components of pktgen:
# pg_ctrl(), pg_thread() and pg_set().
#
# These functions correspond to pktgens different components.
# * pg_ctrl() control "pgctrl" (/proc/net/pktgen/pgctrl)
# * pg_thread() control the kernel threads and binding to devices
# * pg_set() control setup of individual devices
function pg_ctrl() {
local proc_file="pgctrl"
proc_cmd ${proc_file} "$@"
}
function pg_thread() {
local thread=$1
local proc_file="kpktgend_${thread}"
shift
proc_cmd ${proc_file} "$@"
}
function pg_set() {
local dev=$1
local proc_file="$dev"
shift
proc_cmd ${proc_file} "$@"
}
# More generic replacement for pgset(), that does not depend on global
# variable for proc file.
function proc_cmd() {
local result
local proc_file=$1
# after shift, the remaining args are contained in $@
shift
local proc_ctrl=${PROC_DIR}/$proc_file
if [[ ! -e "$proc_ctrl" ]]; then
err 3 "proc file:$proc_ctrl does not exists (dev added to thread?)"
else
if [[ ! -w "$proc_ctrl" ]]; then
err 4 "proc file:$proc_ctrl not writable, not root?!"
fi
fi
if [[ "$DEBUG" == "yes" ]]; then
echo "cmd: $@ > $proc_ctrl"
fi
# Quoting of "$@" is important for space expansion
echo "$@" > "$proc_ctrl"
local status=$?
result=$(grep "Result: OK:" $proc_ctrl)
# Due to pgctrl, cannot use exit code $? from grep
if [[ "$result" == "" ]]; then
grep "Result:" $proc_ctrl >&2
fi
if (( $status != 0 )); then
err 5 "Write error($status) occurred cmd: \"$@ > $proc_ctrl\""
fi
}
# Old obsolete "pgset" function, with slightly improved err handling
function pgset() {
local result
if [[ "$DEBUG" == "yes" ]]; then
echo "cmd: $1 > $PGDEV"
fi
echo $1 > $PGDEV
local status=$?
result=`cat $PGDEV | fgrep "Result: OK:"`
if [[ "$result" == "" ]]; then
cat $PGDEV | fgrep Result:
fi
if (( $status != 0 )); then
err 5 "Write error($status) occurred cmd: \"$1 > $PGDEV\""
fi
}
## -- General shell tricks --
function root_check_run_with_sudo() {
# Trick so, program can be run as normal user, will just use "sudo"
# call as root_check_run_as_sudo "$@"
if [ "$EUID" -ne 0 ]; then
if [ -x $0 ]; then # Directly executable use sudo
info "Not root, running with sudo"
sudo "$0" "$@"
exit $?
fi
err 4 "cannot perform sudo run of $0"
fi
}
/usb?id=39cb2c9a316e77f6dfba96c543e55b6672d5a37e'>usb/serial/f81534.c
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>