linux-stable.git/drivers/gpu/drm/drm_debugfs.c, branch linux-5.4.y

drm: avoid blocking in drm_clients_info's rcu section

2021-09-22T10:26:27+00:00

[ Upstream commit 5eff9585de220cdd131237f5665db5e6c6bdf590 ]

Inside drm_clients_info, the rcu_read_lock is held to lock
pid_task()->comm. However, within this protected section, a call to
drm_is_current_master is made, which involves a mutex lock in a future
patch. However, this is illegal because the mutex lock might block
while in the RCU read-side critical section.

Since drm_is_current_master isn't protected by rcu_read_lock, we avoid
this by moving it out of the RCU critical section.

The following report came from intel-gfx ci's
igt@debugfs_test@read_all_entries testcase:

=============================
[ BUG: Invalid wait context ]
5.13.0-CI-Patchwork_20515+ #1 Tainted: G        W
-----------------------------
debugfs_test/1101 is trying to lock:
ffff888132d901a8 (&dev->master_mutex){+.+.}-{3:3}, at:
drm_is_current_master+0x1e/0x50
other info that might help us debug this:
context-{4:4}
3 locks held by debugfs_test/1101:
 #0: ffff88810fdffc90 (&p->lock){+.+.}-{3:3}, at:
 seq_read_iter+0x53/0x3b0
 #1: ffff888132d90240 (&dev->filelist_mutex){+.+.}-{3:3}, at:
 drm_clients_info+0x63/0x2a0
 #2: ffffffff82734220 (rcu_read_lock){....}-{1:2}, at:
 drm_clients_info+0x1b1/0x2a0
stack backtrace:
CPU: 8 PID: 1101 Comm: debugfs_test Tainted: G        W
5.13.0-CI-Patchwork_20515+ #1
Hardware name: Intel Corporation CometLake Client Platform/CometLake S
UDIMM (ERB/CRB), BIOS CMLSFWR1.R00.1263.D00.1906260926 06/26/2019
Call Trace:
 dump_stack+0x7f/0xad
 __lock_acquire.cold.78+0x2af/0x2ca
 lock_acquire+0xd3/0x300
 ? drm_is_current_master+0x1e/0x50
 ? __mutex_lock+0x76/0x970
 ? lockdep_hardirqs_on+0xbf/0x130
 __mutex_lock+0xab/0x970
 ? drm_is_current_master+0x1e/0x50
 ? drm_is_current_master+0x1e/0x50
 ? drm_is_current_master+0x1e/0x50
 drm_is_current_master+0x1e/0x50
 drm_clients_info+0x107/0x2a0
 seq_read_iter+0x178/0x3b0
 seq_read+0x104/0x150
 full_proxy_read+0x4e/0x80
 vfs_read+0xa5/0x1b0
 ksys_read+0x5a/0xd0
 do_syscall_64+0x39/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Signed-off-by: Desmond Cheong Zhi Xi 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-3-desmondcheongzx@gmail.com
Signed-off-by: Sasha Levin

drm/debugfs: fix plain echo to connector "force" attribute

2020-08-19T06:16:02+00:00

[ Upstream commit c704b17071c4dc571dca3af4e4151dac51de081a ]

Using plain echo to set the "force" connector attribute fails with
-EINVAL, because echo appends a newline to the output.

Replace strcmp with sysfs_streq to also accept strings that end with a
newline.

v2: use sysfs_streq instead of stripping trailing whitespace

Signed-off-by: Michael Tretter 
Reviewed-by: Jani Nikula 
Signed-off-by: Emil Velikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20170817104307.17124-1-m.tretter@pengutronix.de
Signed-off-by: Sasha Levin

drm: debugfs: make drm_debugfs_create_files() never fail

2019-06-14T14:59:51+00:00

As stated before, there is no need to care if a debugfs function
succeeds or not, and no code logic in the kernel should ever change
based on a debugfs function return value, so make
drm_debugfs_create_files() never fail.  If it encounters an
odd/rare/impossible error (i.e. out of memory, or a duplicate debugfs
filename to be created), just keep on moving as if nothing improper had
happened.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20190614095110.3716-2-gregkh@linuxfoundation.org

drm: no need to check return value of debugfs_create functions

2019-06-13T14:39:16+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Because there is no need to check these functions, a number of local
functions can be made to return void to simplify things as nothing can
fail.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20190613133439.GA6715@kroah.com

drm: drop use of drmP.h in drm/*

2019-05-27T16:07:03+00:00

The use of the drmP.h header file is deprecated.
Remove use from all files in drm/*
so people do not look there and follow a bad example.

Build tested allyesconfig,allmodconfig on x86, arm etc.
Including alpha that is as always more challenging than
the rest.

Signed-off-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

drm: Merge drm_info.c into drm_debugfs.c

2018-11-22T08:52:27+00:00

Ever since

commit cb6458f97b53d7f73043206c18014b3ca63ac345
Author: Daniel Vetter 
Date:   Thu Aug 8 15:41:34 2013 +0200

    drm: remove procfs code, take 2

Having the code shared between procfs and debugfs in the separate
drm_info.c file stopped making sense. Merge them.

Noticed because Lyude asked some questions on irc about why we even
have drm_info_node and I remember this old story.

Cc: Lyude Paul 
Reviewed-by: Lyude Paul 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20181121213510.31260-1-daniel.vetter@ffwll.ch

drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation

2018-09-17T23:24:37+00:00

As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic modesetting internally (even though it might
not be exposing atomic capabilities).

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
Cc: stable@vger.kernel.org
Reviewed-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20180917173733.21293-1-lyude@redhat.com

drm: drop _mode_ from update_edit_property()

2018-07-13T16:40:27+00:00

Just makes it longer, and for most things in drm_connector.[hc] we
just use the drm_connector_ prefix. Done with sed + a bit of manual
fixup for the indenting.

Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-6-daniel.vetter@ffwll.ch

drm/debugfs: Add internal client debugfs file

2018-07-10T12:53:35+00:00

Print the names of the internal clients currently attached.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-6-noralf@tronnes.org

drm/debugfs: Fix framebuffer debugfs file init

2017-11-14T09:08:17+00:00

The introduction of: drm/framebuffer: Add framebuffer debugfs file
broke vgem. That patch assumed that all drivers had initialized the
dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
vgem doesn't need to call drm_mode_config_init().

Fix this by only creating the framebuffer debugfs file for modesetting
drivers.

Fixes: 45d58b40292b ("drm/framebuffer: Add framebuffer debugfs file")
Suggested-by: Chris Wilson 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Dave Airlie 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20171113231201.26177-1-noralf@tronnes.org