[Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

[Chris Wilson]

On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > i915_drpc_info missed covering a few register read with the runtime pm
> > wakelock. Be simple and cover the entire function with a single wakelock
> > so that new additions are not similarly missed in future.
> >
> >   WARNING: CPU: 2 PID: 1334 at drivers/gpu/drm/i915/intel_drv.h:1743 gen6_read32+0x192/0x1e0 [i915]
> >   RPM wakelock ref not held during HW access
> >   Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver netconsole nfsd auth_rpcgss ipmi_watchdog ipmi_poweroff ipmi_devintf ipmi_msghandler overlay btrfs xor raid6_pq dm_mod sg sd_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ata_generic pata_acpi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel kvm_intel snd_hda_codec kvm eeepc_wmi irqbypass snd_hda_core crct10dif_pclmul crc32_pclmul crc32c_intel asus_wmi sparse_keymap ghash_clmulni_intel snd_hwdep i915 rfkill ppdev pcbc aesni_intel ata_piix crypto_simd glue_helper snd_pcm pata_via cryptd pcspkr snd_timer drm_kms_helper syscopyarea snd sysfillrect libata sysimgblt fb_sys_fops soundcore shpchp drm wmi parport_pc parport tpm_infineon video
> >   CPU: 2 PID: 1334 Comm: php5 Not tainted 4.10.0-rc8-01615-g1f58c8e #1
> >   Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 1002 04/01/2011
> >   Call Trace:
> >    dump_stack+0x63/0x8a
> >    __warn+0xcb/0xf0
> >    warn_slowpath_fmt+0x4f/0x60
> >    ? seq_vprintf+0x35/0x50
> >    gen6_read32+0x192/0x1e0 [i915]
> >    i915_drpc_info+0x55d/0x990 [i915]
> >    seq_read+0xf2/0x3b0
> >    full_proxy_read+0x51/0x80
> >    __vfs_read+0x28/0x130
> >    ? security_file_permission+0x9b/0xc0
> >    ? rw_verify_area+0x4e/0xb0
> >    vfs_read+0xa8/0x170
> >    SyS_read+0x46/0xa0
> >    entry_SYSCALL_64_fastpath+0x1a/0xa9
> >   RIP: 0033:0x7fd97bf175a0
> >   RSP: 002b:00007ffdf730db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> >   RAX: ffffffffffffffda RBX: 00007fd978028738 RCX: 00007fd97bf175a0
> >   RDX: 0000000000002000 RSI: 00007fd97740e0d8 RDI: 0000000000000005
> >   RBP: 0000000000000001 R08: 0000000000e97840 R09: 00007fd977ef8d58
> >   R10: 0000000000000027 R11: 0000000000000246 R12: 00007fd977ef8d58
> >   R13: 0000000000000000 R14: 0000000000eb4640 R15: 0000000000000000
> >
> > Reported-by: kernel test robot <xiaolong.ye at intel.com>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> While reading this I pondered if mutexing the whole read sequence
> would add value. To give 'atomic' snapshot of state.

An atomic snapshot of state that may be updated by hw in some cases? :)
Otoh, adding locking around hw state reads makes debugging harder.

I don't think it would help very much, and hinder in others. Atomic
reports are nice, in theory, and sometime vital. Not convinced that this
is the case here.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre