From: Nicolai Stange <nicstange@gmail.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
Alex Deucher <alexander.deucher@amd.com>,
Daniel Vetter <daniel.vetter@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/radeon: don't add files at control minor debugfs directory
Date: Mon, 05 Dec 2016 09:39:12 +0100 [thread overview]
Message-ID: <87pol6ahxr.fsf@gmail.com> (raw)
In-Reply-To: <5b8f4c38-c993-90af-5417-5e2e3cc38b58@amd.com> ("Christian \=\?utf-8\?Q\?K\=C3\=B6nig\=22's\?\= message of "Mon, 5 Dec 2016 08:42:49 +0100")
Christian König <christian.koenig@amd.com> writes:
> Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
>> On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
>>> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
>>> struct drm_device's ->control member is always NULL.
>>>
>>> In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses
>>> ->control->debugfs_root though. This results in the following Oops:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
>>> IP: radeon_debugfs_add_files+0x90/0x100 [radeon]
>>> PGD 0
>>> Oops: 0000 [#1] SMP
>>> [...]
>>> Call Trace:
>>> ? work_on_cpu+0xb0/0xb0
>>> radeon_fence_driver_init+0x120/0x150 [radeon]
>>> si_init+0x122/0xd50 [radeon]
>>> ? _raw_spin_unlock_irq+0x2c/0x40
>>> ? device_pm_check_callbacks+0xb3/0xc0
>>> radeon_device_init+0x958/0xda0 [radeon]
>>> radeon_driver_load_kms+0x9a/0x210 [radeon]
>>> drm_dev_register+0xa9/0xd0 [drm]
>>> drm_get_pci_dev+0x9c/0x1e0 [drm]
>>> radeon_pci_probe+0xb8/0xe0 [radeon]
>>> [...]
>>>
>>> Fix this by omitting the drm_debugfs_create_files() call for the
>>> control minor debugfs directory which is now non-existent anyway.
>>>
>>> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
>>> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>> Applied to drm-misc with Dave's irc ack, thanks for your patch.
>
> If it's still worth it the patch is Reviewed-by: Christian König
> <christian.koenig@amd.com>.
>
> On the other hand when ->control is always NULL, why do we still have
> ->control anyway?
Yes, I was wondering about that, too.
Quoting from 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"):
Since I don't like dead uabi, let's remove it. But since this would be
a really big change I think it's better to start out small by simply
not registering anything. We can garbage-collect the dead code later
on, once we're sure it's really not used anywhere.
I'd too prefer compile time errors by purging ->control here. Daniel?
> And BTW: Please double check the other drivers as well.
# git grep '\->control' -- drivers/gpu/
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control->debugfs_root,
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control);
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control);
Oops.
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c: ib_packet->control = (1 << 23) | (1 << 31) |
drivers/gpu/drm/drm_drv.c: return &dev->control;
That's drm_minor_get_slot(dev, type), but grepping for DRM_MINOR_CONTROL
doesn't yield anything -> dead code.
drivers/gpu/drm/gma500/psb_intel_sdvo.c: switch (sdvo->controlled_output) {
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= type;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output = 0;
drivers/gpu/drm/i915/intel_sdvo.c: switch (sdvo->controlled_output) {
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= type;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output = 0;
drivers/gpu/drm/msm/msm_debugfs.c: ret = late_init_minor(dev->control);
Not an oops but dead code.
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control->debugfs_root,
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control);
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control);
Oops.
I'll send compile-only tested patches either tonight or tomorrow. Shall
they cover the oopses only or the dead code as well?
Thanks,
Nicolai
WARNING: multiple messages have this Message-ID (diff)
From: Nicolai Stange <nicstange@gmail.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
Alex Deucher <alexander.deucher@amd.com>,
Daniel Vetter <daniel.vetter@intel.com>,
<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/radeon: don't add files at control minor debugfs directory
Date: Mon, 05 Dec 2016 09:39:12 +0100 [thread overview]
Message-ID: <87pol6ahxr.fsf@gmail.com> (raw)
In-Reply-To: <5b8f4c38-c993-90af-5417-5e2e3cc38b58@amd.com> ("Christian \=\?utf-8\?Q\?K\=C3\=B6nig\=22's\?\= message of "Mon, 5 Dec 2016 08:42:49 +0100")
Christian König <christian.koenig@amd.com> writes:
> Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
>> On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
>>> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
>>> struct drm_device's ->control member is always NULL.
>>>
>>> In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses
>>> ->control->debugfs_root though. This results in the following Oops:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
>>> IP: radeon_debugfs_add_files+0x90/0x100 [radeon]
>>> PGD 0
>>> Oops: 0000 [#1] SMP
>>> [...]
>>> Call Trace:
>>> ? work_on_cpu+0xb0/0xb0
>>> radeon_fence_driver_init+0x120/0x150 [radeon]
>>> si_init+0x122/0xd50 [radeon]
>>> ? _raw_spin_unlock_irq+0x2c/0x40
>>> ? device_pm_check_callbacks+0xb3/0xc0
>>> radeon_device_init+0x958/0xda0 [radeon]
>>> radeon_driver_load_kms+0x9a/0x210 [radeon]
>>> drm_dev_register+0xa9/0xd0 [drm]
>>> drm_get_pci_dev+0x9c/0x1e0 [drm]
>>> radeon_pci_probe+0xb8/0xe0 [radeon]
>>> [...]
>>>
>>> Fix this by omitting the drm_debugfs_create_files() call for the
>>> control minor debugfs directory which is now non-existent anyway.
>>>
>>> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
>>> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>> Applied to drm-misc with Dave's irc ack, thanks for your patch.
>
> If it's still worth it the patch is Reviewed-by: Christian König
> <christian.koenig@amd.com>.
>
> On the other hand when ->control is always NULL, why do we still have
> ->control anyway?
Yes, I was wondering about that, too.
Quoting from 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"):
Since I don't like dead uabi, let's remove it. But since this would be
a really big change I think it's better to start out small by simply
not registering anything. We can garbage-collect the dead code later
on, once we're sure it's really not used anywhere.
I'd too prefer compile time errors by purging ->control here. Daniel?
> And BTW: Please double check the other drivers as well.
# git grep '\->control' -- drivers/gpu/
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control->debugfs_root,
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control);
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: adev->ddev->control);
Oops.
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c: ib_packet->control = (1 << 23) | (1 << 31) |
drivers/gpu/drm/drm_drv.c: return &dev->control;
That's drm_minor_get_slot(dev, type), but grepping for DRM_MINOR_CONTROL
doesn't yield anything -> dead code.
drivers/gpu/drm/gma500/psb_intel_sdvo.c: switch (sdvo->controlled_output) {
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= type;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
drivers/gpu/drm/gma500/psb_intel_sdvo.c: psb_intel_sdvo->controlled_output = 0;
drivers/gpu/drm/i915/intel_sdvo.c: switch (sdvo->controlled_output) {
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= type;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
drivers/gpu/drm/i915/intel_sdvo.c: intel_sdvo->controlled_output = 0;
drivers/gpu/drm/msm/msm_debugfs.c: ret = late_init_minor(dev->control);
Not an oops but dead code.
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control->debugfs_root,
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control);
drivers/gpu/drm/qxl/qxl_debugfs.c: qdev->ddev->control);
Oops.
I'll send compile-only tested patches either tonight or tomorrow. Shall
they cover the oopses only or the dead code as well?
Thanks,
Nicolai
next prev parent reply other threads:[~2016-12-05 8:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-03 14:47 [PATCH] drm/radeon: don't add files at control minor debugfs directory Nicolai Stange
2016-12-05 7:27 ` Daniel Vetter
2016-12-05 7:27 ` Daniel Vetter
2016-12-05 7:42 ` Christian König
2016-12-05 7:42 ` Christian König
2016-12-05 8:04 ` Daniel Vetter
2016-12-05 8:04 ` Daniel Vetter
2016-12-05 8:39 ` Nicolai Stange [this message]
2016-12-05 8:39 ` Nicolai Stange
2016-12-05 8:48 ` Christian König
2016-12-05 8:48 ` Christian König
2016-12-05 9:11 ` Michel Dänzer
2016-12-05 9:11 ` Michel Dänzer
2016-12-05 9:51 ` Daniel Vetter
2016-12-05 9:51 ` Daniel Vetter
2016-12-05 20:30 ` [PATCH] drm/amdgpu: " Nicolai Stange
2016-12-05 20:33 ` Deucher, Alexander
2016-12-05 20:33 ` Deucher, Alexander
2016-12-06 2:01 ` Mike Lothian
2016-12-06 7:17 ` Daniel Vetter
2016-12-06 7:17 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pol6ahxr.fsf@gmail.com \
--to=nicstange@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.