Warning triggered in drm_dp_delayed_destroy_work workqueue
Hi! I've been seeing this warning occasionally, not sure if it has been reported yet. It's not a regression as I remember seeing it in, at least, 5.7. Anyway, here it is: [ cut here ] sysfs group 'power' not found for kobject 'i2c-7' WARNING: CPU: 1 PID: 17996 at fs/sysfs/group.c:279 sysfs_remove_group+0x74/0x80 Modules linked in: ccm(E) dell_rbtn(E) iwlmvm(E) mei_wdt(E) mac80211(E) libarc4(E) uvcvideo(E) dell_laptop(E) videobuf2_vmalloc(E) intel_rapl_> soundcore(E) intel_soc_dts_iosf(E) rng_core(E) battery(E) acpi_pad(E) sparse_keymap(E) acpi_thermal_rel(E) intel_pch_thermal(E) int3402_therm> sysfillrect(E) intel_lpss(E) sysimgblt(E) fb_sys_fops(E) idma64(E) scsi_mod(E) virt_dma(E) mfd_core(E) drm(E) fan(E) thermal(E) i2c_hid(E) hi> CPU: 1 PID: 17996 Comm: kworker/1:1 Tainted: GE 5.8.0-rc2+ #36 Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020 Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper] RIP: 0010:sysfs_remove_group+0x74/0x80 Code: ff 5b 48 89 ef 5d 41 5c e9 79 bc ff ff 48 89 ef e8 01 b8 ff ff eb cc 49 8b 14 24 48 8b 33 48 c7 c7 90 ac 8b 93 e8 de b1 d4 ff <0f> 0b 5b> RSP: :b12d40c13c38 EFLAGS: 00010282 RAX: RBX: 936e6a60 RCX: 0027 RDX: 0027 RSI: 0086 RDI: 8e37de097b68 RBP: R08: 8e37de097b60 R09: 93fb4624 R10: 0904 R11: 0001002c R12: 8e37d3081c18 R13: 8e375f1450a8 R14: R15: 8e375f145410 FS: () GS:8e37de08() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 0004ab20a001 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: device_del+0x97/0x3f0 cdev_device_del+0x15/0x30 put_i2c_dev+0x7b/0x90 [i2c_dev] i2cdev_detach_adapter+0x33/0x60 [i2c_dev] notifier_call_chain+0x47/0x70 blocking_notifier_call_chain+0x3d/0x60 device_del+0x8f/0x3f0 device_unregister+0x16/0x60 i2c_del_adapter+0x247/0x300 drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper] drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper] process_one_work+0x1ae/0x370 worker_thread+0x50/0x3a0 ? process_one_work+0x370/0x370 kthread+0x11b/0x140 ? kthread_associate_blkcg+0x90/0x90 ret_from_fork+0x22/0x30 ---[ end trace 16486ad3c2627482 ]--- [ cut here ] Cheers, -- Luis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning triggered in drm_dp_delayed_destroy_work workqueue
On Fri, Jun 26, 2020 at 05:06:00PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 03:40:20PM +0200, Daniel Vetter wrote:
> > Adding Lyude, she's been revamping all the lifetime refcouting in the
> > dp code last few kernel releases. At a glance I don't even have an
> > idea what's going wrong here ...
>
> Already fixed by Imre I believe.
>
> 7d11507605a7 ("drm/dp_mst: Fix the DDC I2C device unregistration of an MST
> port")
>
Ah! It does seems to be the same issue indeed! Thanks a lot for pointing
me at this commit. Hopefully this fix can be included in 5.8. Not that
I'm seeing this WARNING frequently, but frequent enough to annoy me :-)
Cheers,
--
Luis
> > -Daniel
> >
> > On Thu, Jun 25, 2020 at 12:22 PM Luis Henriques wrote:
> > >
> > > Hi!
> > >
> > > I've been seeing this warning occasionally, not sure if it has been
> > > reported yet. It's not a regression as I remember seeing it in, at least,
> > > 5.7.
> > >
> > > Anyway, here it is:
> > >
> > > [ cut here ]
> > > sysfs group 'power' not found for kobject 'i2c-7'
> > > WARNING: CPU: 1 PID: 17996 at fs/sysfs/group.c:279
> > > sysfs_remove_group+0x74/0x80
> > > Modules linked in: ccm(E) dell_rbtn(E) iwlmvm(E) mei_wdt(E) mac80211(E)
> > > libarc4(E) uvcvideo(E) dell_laptop(E) videobuf2_vmalloc(E) intel_rapl_>
> > > soundcore(E) intel_soc_dts_iosf(E) rng_core(E) battery(E) acpi_pad(E)
> > > sparse_keymap(E) acpi_thermal_rel(E) intel_pch_thermal(E) int3402_therm>
> > > sysfillrect(E) intel_lpss(E) sysimgblt(E) fb_sys_fops(E) idma64(E)
> > > scsi_mod(E) virt_dma(E) mfd_core(E) drm(E) fan(E) thermal(E) i2c_hid(E)
> > > hi>
> > > CPU: 1 PID: 17996 Comm: kworker/1:1 Tainted: GE
> > > 5.8.0-rc2+ #36
> > > Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020
> > > Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper]
> > > RIP: 0010:sysfs_remove_group+0x74/0x80
> > > Code: ff 5b 48 89 ef 5d 41 5c e9 79 bc ff ff 48 89 ef e8 01 b8 ff ff eb
> > > cc 49 8b 14 24 48 8b 33 48 c7 c7 90 ac 8b 93 e8 de b1 d4 ff <0f> 0b 5b>
> > > RSP: :b12d40c13c38 EFLAGS: 00010282
> > > RAX: RBX: 936e6a60 RCX: 0027
> > > RDX: 0027 RSI: 0086 RDI: 8e37de097b68
> > > RBP: R08: 8e37de097b60 R09: 93fb4624
> > > R10: 0904 R11: 0001002c R12: 8e37d3081c18
> > > R13: 8e375f1450a8 R14: R15: 8e375f145410
> > > FS: () GS:8e37de08()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: CR3: 0004ab20a001 CR4: 003606e0
> > > DR0: DR1: DR2:
> > > DR3: DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > > device_del+0x97/0x3f0
> > > cdev_device_del+0x15/0x30
> > > put_i2c_dev+0x7b/0x90 [i2c_dev]
> > > i2cdev_detach_adapter+0x33/0x60 [i2c_dev]
> > > notifier_call_chain+0x47/0x70
> > > blocking_notifier_call_chain+0x3d/0x60
> > > device_del+0x8f/0x3f0
> > > device_unregister+0x16/0x60
> > > i2c_del_adapter+0x247/0x300
> > > drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper]
> > > drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper]
> > > process_one_work+0x1ae/0x370
> > > worker_thread+0x50/0x3a0
> > > ? process_one_work+0x370/0x370
> > > kthread+0x11b/0x140
> > > ? kthread_associate_blkcg+0x90/0x90
> > > ret_from_fork+0x22/0x30
> > > ---[ end trace 16486ad3c2627482 ]---
> > > [ cut here ]
> > >
> > > Cheers,
> > > --
> > > Luis
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: list_add corruption followed by BUG (stack guard page was hit)
Hi! I've just got the following WARNING followed by a BUG on rc7. Maybe it's already a known issue, but here it is anyway. Cheers, -- Luis [ 38.001304] [ cut here ] [ 38.001312] list_add corruption. prev->next should be next (8fe713397b88), but was . (prev=8fe715fb9140). [ 38.001337] WARNING: CPU: 3 PID: 501 at lib/list_debug.c:26 __list_add_valid+0x4d/0x70 [ 38.001340] Modules linked in: cdc_ether(E) usbnet(E) r8152(E) mii(E) hid_generic(E) usbhid(E) snd_hda_codec_hdmi(E) iwlmvm(E) dell_rbtn(E) mac80211(E) libarc4(E) snd_hda_codec_realtek(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_hda_codec_generic(E) coretemp(E) mei_wdt(E) dell_laptop(E) kvm_intel(E) ledtrig_audio(E) intel_rapl_msr(E) dell_smm_hwmon(E) snd_hda_intel(E) kvm(E) uvcvideo(E) snd_intel_dspcfg(E) videobuf2_vmalloc(E) irqbypass(E) iwlwifi(E) videobuf2_memops(E) rapl(E) snd_hda_codec(E) videobuf2_v4l2(E) intel_cstate(E) dell_wmi(E) joydev(E) snd_hwdep(E) pcspkr(E) serio_raw(E) intel_uncore(E) dell_smbios(E) videobuf2_common(E) dcdbas(E) snd_hda_core(E) iTCO_wdt(E) snd_pcm(E) videodev(E) wmi_bmof(E) snd_timer(E) dell_wmi_descriptor(E) intel_wmi_thunderbolt(E) iTCO_vendor_support(E) mei_me(E) snd(E) cfg80211(E) soundcore(E) tpm_crb(E) mc(E) rfkill(E) mei(E) intel_pch_thermal(E) sg(E) processor_thermal_device(E) intel_rapl_common(E) intel_soc_dts_iosf(E) battery(E) tpm _tis(E) [ 38.001397] int3403_thermal(E) tpm_tis_core(E) tpm(E) dell_smo8800(E) intel_hid(E) evdev(E) rng_core(E) int3400_thermal(E) int3402_thermal(E) acpi_thermal_rel(E) int340x_thermal_zone(E) sparse_keymap(E) acpi_pad(E) ac(E) nft_counter(E) nft_ct(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) i2c_dev(E) nf_tables(E) parport_pc(E) ppdev(E) nfnetlink(E) lp(E) parport(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) btrfs(E) blake2b_generic(E) xor(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) dm_crypt(E) cbc(E) encrypted_keys(E) dm_mod(E) sd_mod(E) t10_pi(E) rtsx_pci_sdmmc(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) mmc_core(E) aesni_intel(E) crypto_simd(E) cryptd(E) glue_helper(E) ahci(E) nouveau(E) i915(E) mxm_wmi(E) i2c_i801(E) i2c_smbus(E) libahci(E) ttm(E) i2c_algo_bit(E) rtsx_pci(E) xhci_pci(E) drm_kms_helper(E) intel_lpss_pci(E) libata(E) syscopyarea(E) intel_lpss(E) xhci_hcd(E) idma64(E) sysfillrect(E) virt_dma( E) [ 38.001461] sysimgblt(E) scsi_mod(E) fb_sys_fops(E) mfd_core(E) usbcore(E) usb_common(E) drm(E) fan(E) thermal(E) i2c_hid(E) hid(E) wmi(E) video(E) button(E) [ 38.001482] CPU: 3 PID: 501 Comm: kworker/3:4 Tainted: GE 5.8.0-rc7 #43 [ 38.001485] Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020 [ 38.001513] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 38.001521] RIP: 0010:__list_add_valid+0x4d/0x70 [ 38.001527] Code: c3 4c 89 c1 48 c7 c7 98 34 ed af e8 7f 16 c9 ff 0f 0b 31 c0 c3 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 e8 34 ed af e8 65 16 c9 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 38 35 ed af e8 [ 38.001530] RSP: 0018:a47680417ca0 EFLAGS: 00010286 [ 38.001535] RAX: RBX: 8fe713397b88 RCX: 0027 [ 38.001538] RDX: 0027 RSI: 0096 RDI: 8fe71e197b68 [ 38.001541] RBP: 8fe7133977e8 R08: 8fe71e197b60 R09: 0084 [ 38.001544] R10: a47680417b48 R11: a47680417b4d R12: 8fe71869f800 [ 38.001547] R13: 8fe715fb9140 R14: 8fe71869f940 R15: 8fe713397b68 [ 38.001551] FS: () GS:8fe71e18() knlGS: [ 38.001555] CS: 0010 DS: ES: CR0: 80050033 [ 38.001558] CR2: 7f9e3f7159d0 CR3: 00040e60a004 CR4: 003606e0 [ 38.001561] DR0: DR1: DR2: [ 38.001563] DR3: DR6: fffe0ff0 DR7: 0400 [ 38.001566] Call Trace: [ 38.001593] drm_dp_queue_down_tx+0x5c/0x110 [drm_kms_helper] [ 38.001604] ? i2c_register_adapter+0x1d0/0x390 [ 38.001627] drm_dp_send_enum_path_resources+0x54/0x120 [drm_kms_helper] [ 38.001650] drm_dp_send_link_address+0x682/0x990 [drm_kms_helper] [ 38.001657] ? prepare_to_wait_event+0x7e/0x150 [ 38.001661] ? finish_wait+0x3f/0x80 [ 38.001684] drm_dp_check_and_send_link_address+0xad/0xd0 [drm_kms_helper] [ 38.001707] drm_dp_mst_link_probe_work+0x94/0x180 [drm_kms_helper] [ 38.001714] process_one_work+0x1ae/0x370 [ 38.001720] worker_thread+0x50/0x3a0 [ 38.001725] ? process_one_work+0x370/0x370 [ 38.001729] kthread+0x11b/0x140 [ 38.001734] ? kthread_associate_blkcg+0x90/0x90 [ 38.001741] ret_from_fork+0x22/0x30 [ 38.001747] ---[ end trace ca03f107384f1adc ]--- [ 38.001759] BUG: stack guard page was hit at 62c9d455 (stack is e3f6f298..86ee600f) [ 38.001766] kernel stac
[PATCH] drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init()
This fixes the following build failure:
drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function
`msm_dsi_pll_28nm_8960_init':
dsi_pll_28nm.c:(.text+0x1198): multiple definition of
`msm_dsi_pll_28nm_8960_init'
drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first defined here
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
index 80b6038334a6..2cf1664723e8 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
@@ -97,8 +97,8 @@ static inline struct msm_dsi_pll *msm_dsi_pll_28nm_init(
struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device *pdev,
int id);
#else
-struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device *pdev,
- int id)
+static inline struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(
+ struct platform_device *pdev, int id)
{
return ERR_PTR(-ENODEV);
}
[PATCH] drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)
On Tue, Mar 15, 2016 at 12:56:45PM -0500, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> [Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
> an additional NULL pointer guard that is required for kernels 3.17 and older.
>
Thank you, Nicolai. I'll queue this backport for the 3.16.
Cheers,
--
LuÃs
> To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
> use common fence implementation for fences, v4" requires this additional
> NULL pointer guard.]
>
> An arbitrary amount of time can pass between spin_unlock and
> radeon_fence_wait_any, so we need to ensure that nobody frees the
> fences from under us.
>
> Based on the analogous fix for amdgpu.
>
> Signed-off-by: Nicolai Hähnle
> Reviewed-by: Christian König (v1 + fix)
> Tested-by: Lutz Euler
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_sa.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
> b/drivers/gpu/drm/radeon/radeon_sa.c
> index c507896..7d11901 100644
> --- a/drivers/gpu/drm/radeon/radeon_sa.c
> +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> @@ -349,8 +349,15 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
> /* see if we can skip over some allocations */
> } while (radeon_sa_bo_next_hole(sa_manager, fences, tries));
>
> + for (i = 0; i < RADEON_NUM_RINGS; ++i) {
> + if (fences[i])
> + radeon_fence_ref(fences[i]);
> + }
> +
> spin_unlock(&sa_manager->wq.lock);
> r = radeon_fence_wait_any(rdev, fences, false);
> + for (i = 0; i < RADEON_NUM_RINGS; ++i)
> + radeon_fence_unref(&fences[i]);
> spin_lock(&sa_manager->wq.lock);
> /* if we have nothing to wait for block */
> if (r == -ENOENT) {
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
>
> Please consider
>
> 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
> the per-process entries, 2012-08-24
>
> for application to the 3.4.y tree.
Thanks, I'll queue this for 3.5 kernel as well.
Cheers,
--
Luis
>
> Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
> The problem is reproducible on
>
> * Debian's 3.2.y-based kernel with drm backported from 3.4.37
> * a Debian kernel close to 3.4.4
> * a Debian kernel close to 3.5.5
> * vanilla 3.4.4
>
> He is not able to reproduce the problem on
>
> * Debian's older 3.2.y-based kernels without the 3.4.y drm backport
> * a Debian kernel close to 3.6.4; various newer kernels
> * vanilla 3.4.4 + this patch
>
> The patch was applied upstream during the 3.6-rc4 cycle, so newer
> kernels don't need it.
>
> http://bugs.debian.org/703468 has details, including a screenshot of
> the boot failure ("unable to handling kernel paging request at
> c9000b7ff000" in i915_gem_init_ppgtt).
>
> Thoughts welcome, as always.
>
> Regards,
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
>
> Please consider
>
> 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
> the per-process entries, 2012-08-24
>
> for application to the 3.4.y tree.
Thanks, I'll queue this for 3.5 kernel as well.
Cheers,
--
Luis
>
> Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
> The problem is reproducible on
>
> * Debian's 3.2.y-based kernel with drm backported from 3.4.37
> * a Debian kernel close to 3.4.4
> * a Debian kernel close to 3.5.5
> * vanilla 3.4.4
>
> He is not able to reproduce the problem on
>
> * Debian's older 3.2.y-based kernels without the 3.4.y drm backport
> * a Debian kernel close to 3.6.4; various newer kernels
> * vanilla 3.4.4 + this patch
>
> The patch was applied upstream during the 3.6-rc4 cycle, so newer
> kernels don't need it.
>
> http://bugs.debian.org/703468 has details, including a screenshot of
> the boot failure ("unable to handling kernel paging request at
> c9000b7ff000" in i915_gem_init_ppgtt).
>
> Thoughts welcome, as always.
>
> Regards,
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.5.y.z extended stable] Patch "drm: Prevent overwriting from userspace underallocating core ioctl" has been added to staging queue
This is a note to let you know that I have just added a patch titled
drm: Prevent overwriting from userspace underallocating core ioctl
to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
--
>From c0614f3697a7cbaa3ef53b8ef64866797e5112c0 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Wed, 16 Oct 2013 11:22:44 +0100
Subject: drm: Prevent overwriting from userspace underallocating core ioctl
structs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20:34 2010 +1000
drm: block userspace under allocating buffer and having drivers overwrite
it (v2)
to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Reviewed-by: Ville Syrj?l?
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/drm_drv.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8a9d079..df54da9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -422,9 +422,16 @@ long drm_ioctl(struct file *filp,
asize = drv_size;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
+ u32 drv_size;
+
ioctl = &drm_ioctls[nr];
- cmd = ioctl->cmd;
+
+ drv_size = _IOC_SIZE(ioctl->cmd);
usize = asize = _IOC_SIZE(cmd);
+ if (drv_size > asize)
+ asize = drv_size;
+
+ cmd = ioctl->cmd;
} else
goto err_i1;
--
1.8.3.2
[3.5.y.z extended stable] Patch "drm: Pad drm_mode_get_connector to 64-bit boundary" has been added to staging queue
This is a note to let you know that I have just added a patch titled
drm: Pad drm_mode_get_connector to 64-bit boundary
to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
--
>From 81019eb6f5b7e60b588128f63e0bfaf34b650bcf Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Wed, 16 Oct 2013 09:49:02 +0100
Subject: drm: Pad drm_mode_get_connector to 64-bit boundary
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.
64-bit kernel:
sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
32-bit userspace:
sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.
Reported-by: Pavel Roskin
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie
[ luis: backported to 3.5:
- file rename: include/uapi/drm/drm_mode.h -> include/drm/drm_mode.h ]
Signed-off-by: Luis Henriques
---
include/drm/drm_mode.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..f604a1a 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -223,6 +223,8 @@ struct drm_mode_get_connector {
__u32 connection;
__u32 mm_width, mm_height; /**< HxW in millimeters */
__u32 subpixel;
+
+ __u32 pad;
};
#define DRM_MODE_PROP_PENDING (1<<0)
--
1.8.3.2
[PATCH 3.5 13/78] drm: Prevent overwriting from userspace underallocating core ioctl structs
3.5.7.26 -stable review patch. If anyone has any objections, please let me
know.
--
From: Chris Wilson
commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20:34 2010 +1000
drm: block userspace under allocating buffer and having drivers overwrite
it (v2)
to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Reviewed-by: Ville Syrj?l?
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/drm_drv.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8a9d079..df54da9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -422,9 +422,16 @@ long drm_ioctl(struct file *filp,
asize = drv_size;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
+ u32 drv_size;
+
ioctl = &drm_ioctls[nr];
- cmd = ioctl->cmd;
+
+ drv_size = _IOC_SIZE(ioctl->cmd);
usize = asize = _IOC_SIZE(cmd);
+ if (drv_size > asize)
+ asize = drv_size;
+
+ cmd = ioctl->cmd;
} else
goto err_i1;
--
1.8.3.2
[PATCH 3.5 14/78] drm: Pad drm_mode_get_connector to 64-bit boundary
3.5.7.26 -stable review patch. If anyone has any objections, please let me
know.
--
From: Chris Wilson
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.
64-bit kernel:
sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
32-bit userspace:
sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4
Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.
Reported-by: Pavel Roskin
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie
[ luis: backported to 3.5:
- file rename: include/uapi/drm/drm_mode.h -> include/drm/drm_mode.h ]
Signed-off-by: Luis Henriques
---
include/drm/drm_mode.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..f604a1a 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -223,6 +223,8 @@ struct drm_mode_get_connector {
__u32 connection;
__u32 mm_width, mm_height; /**< HxW in millimeters */
__u32 subpixel;
+
+ __u32 pad;
};
#define DRM_MODE_PROP_PENDING (1<<0)
--
1.8.3.2
amdgpu WARNING when switching to external display
Hi! I have been seeing the following splat for quite a while (since I got this laptop!). It happens every time I switch from the laptop display to an external display with: xrandr --output eDP --off --output HDMI-A-0 --auto --primary Not sure what information is needed to debug this, but here's the lspci for the video card: 65:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 (rev c5) (prog-if 00 [VGA controller]) Subsystem: AIstone Global Limited Device 137d Flags: bus master, fast devsel, latency 0, IRQ 65, IOMMU group 19 Memory at 7c (64-bit, prefetchable) [size=256M] Memory at dc00 (64-bit, prefetchable) [size=2M] I/O ports at e000 [size=256] Memory at dc50 (32-bit, non-prefetchable) [size=512K] Capabilities: Kernel driver in use: amdgpu Cheers, -- Luís [ 48.702238] amdgpu :65:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:142 [ 48.702273] [ cut here ] [ 48.702274] WARNING: CPU: 15 PID: 3540 at drivers/gpu/drm/amd/amdgpu/../display/dc/hubbub/dcn31/dcn31_hubbub.c:151 dcn31_program_compbuf_size+0xc8/0x220 [amdgpu] [ 48.702467] Modules linked in: nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink ctr ccm nls_utf8 nls_cp437 vfat fat af_packet uvcvideo uvc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc amdgpu snd_sof_amd_acp63 snd_sof_amd_vangogh snd_sof_amd_rembrandt snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci amdxcp iwlmvm snd_sof gpu_sched drm_panel_backlight_quirks snd_sof_utils joydev drm_buddy snd_sof_xtensa_dsp snd_soc_core mousedev drm_ttm_helper snd_hda_codec_conexant snd_compress mac80211 snd_hda_codec_generic snd_hda_codec_hdmi ttm intel_rapl_msr libarc4 drm_exec snd_pcm_dmaengine intel_rapl_common snd_hda_intel drm_suballoc_helper snd_intel_dspcfg drm_client_lib edac_mce_amd snd_intel_sdw_acpi iwlwifi drm_display_helper snd_hda_codec snd_pci_ps hid_multitouch snd_soc_acpi_amd_match cec kvm_amd hid_generic snd_pci_acp6x sdhci_pci snd_hda_core kvm snd_hwdep irqbypass snd_pcm sdhci_uhs2 input_leds asus_wmi rapl [ 48.702547] ucsi_acpi snd_pci_acp5x i2c_hid_acpi snd_timer sparse_keymap drm_kms_helper i2c_hid sdhci sp5100_tco snd_rn_pci_acp3x serio_raw platform_profile cfg80211 efi_pstore snd wmi_bmof cqhci snd_acp_config hid thunderbolt agpgart typec_ucsi i2c_piix4 k10temp i2c_algo_bit snd_soc_acpi typec i2c_smbus mmc_core tpm_crb ccp soundcore snd_pci_acp3x rfkill roles tpm_tis tpm_tis_core evdev drm button mac_hid tpm rng_core thermal amd_pmc ac efivarfs serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic algif_skcipher af_alg video ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3 xhci_pci xhci_hcd dm_crypt aesni_intel gf128mul crypto_simd cryptd encrypted_keys trusted dm_mod battery wmi loop nvme nvme_core hwmon ext4 crc16 mbcache jbd2 usb_storage usbcore usb_common sd_mod scsi_mod scsi_common [ 48.702633] CPU: 15 UID: 0 PID: 3540 Comm: Xorg Not tainted 6.14.4-0-edge #1-Alpine [ 48.702637] Hardware name: TUXEDO TUXEDO InfinityBook Pro AMD Gen9/GXxHRXx, BIOS N.1.14A13 03/06/2025 [ 48.702639] RIP: 0010:dcn31_program_compbuf_size+0xc8/0x220 [amdgpu] [ 48.702746] Code: 00 48 8b 43 28 8b 88 d8 01 00 00 48 8b 43 20 0f b6 50 76 48 8b 43 18 8b b0 14 01 00 00 e8 90 01 0e 00 85 c0 0f 85 31 01 00 00 <0f> 0b 48 8b 45 f0 65 48 2b 04 25 28 00 00 00 0f 85 33 01 00 00 48 [ 48.702748] RSP: 0018:b75b412236a0 EFLAGS: 00010202 [ 48.702751] RAX: 0001 RBX: 93e706f59000 RCX: 001f [ 48.702752] RDX: RSI: 397a RDI: 93e71ab0 [ 48.702754] RBP: b75b412236b8 R08: b75b412236a4 R09: 0019 [ 48.702755] R10: b22f0888 R11: 0003 R12: 0004 [ 48.702756] R13: 93e71e94 R14: 93e714c0 R15: 93e706f59000 [ 48.702758] FS: 7f9810f35240() GS:93f5a01c() knlGS: [ 48.702760] CS: 0010 DS: ES: CR0: 80050033 [ 48.702761] CR2: 7f9db04f14b0 CR3: 00011c24e000 CR4: 00750ef0 [ 48.702763] PKRU: 5554 [ 48.702764] Call Trace: [ 48.702766] [ 48.702768] dcn20_optimize_bandwidth+0xe1/0x220 [amdgpu] [ 48.702899] dc_commit_state_no_check+0xc8c/0xe40 [amdgpu] [ 48.703018] dc_commit_streams+0x3b5/0x4f0 [amdgpu] [ 48.703114] ? dc_dmub_srv_cmd_run+0x13/0x20 [amdgpu] [ 48.703209] ? srso_alias_return_thunk+0x5/0xfbef5 [ 48.703216] amdgpu_dm_atomic_commit_tail+0x6c0/0x3c30 [amdgpu] [ 48.703327] ? srso_alias_return_thunk+0x5/0xfbef5 [ 48.703329] ? dcn314_validate_bandwidth+0xfc/0x2c0 [amdgpu] [ 48.703436] ? srso_alias_return_thunk+0x5/0xfbef5 [ 48.703438] ? dma_resv_get_fences+0x9f/0x280 [ 48.703441] ? srso_alias_return_thunk+0x5/0xfbef5
