The vkms driver does not need to create a platform device, as there is
no real platform resources associated it, it only did so because it was
simple to do that in order to get a device to use for resource
management of drm resources. Change the driver to use the faux device
instead as this is NOT a real platform device.
Cc: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Melissa Wen <melissa.srw@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v4: - api tweaked due to parent pointer added to faux_device create
function.
- fixed space I removed in the .h file
v3: new patch in the series. For an example of the api working, does
not have to be merged at this time, but I can take it if the
maintainers give an ack.
drivers/gpu/drm/vkms/vkms_drv.c | 28 ++++++++++++++--------------
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index e0409aba9349..b3fa0e7c7751 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -10,7 +10,7 @@
*/
#include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
#include <linux/dma-mapping.h>
#include <drm/clients/drm_client_setup.h>
@@ -177,25 +177,25 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
static int vkms_create(struct vkms_config *config)
{
int ret;
- struct platform_device *pdev;
+ struct faux_device *fdev;
struct vkms_device *vkms_device;
- pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ fdev = faux_device_create(DRIVER_NAME, NULL, NULL);
+ if (!fdev)
+ return -ENODEV;
- if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
+ if (!devres_open_group(&fdev->dev, NULL, GFP_KERNEL)) {
ret = -ENOMEM;
goto out_unregister;
}
- vkms_device = devm_drm_dev_alloc(&pdev->dev, &vkms_driver,
+ vkms_device = devm_drm_dev_alloc(&fdev->dev, &vkms_driver,
struct vkms_device, drm);
if (IS_ERR(vkms_device)) {
ret = PTR_ERR(vkms_device);
goto out_devres;
}
- vkms_device->platform = pdev;
+ vkms_device->faux_dev = fdev;
vkms_device->config = config;
config->dev = vkms_device;
@@ -229,9 +229,9 @@ static int vkms_create(struct vkms_config *config)
return 0;
out_devres:
- devres_release_group(&pdev->dev, NULL);
+ devres_release_group(&fdev->dev, NULL);
out_unregister:
- platform_device_unregister(pdev);
+ faux_device_destroy(fdev);
return ret;
}
@@ -259,19 +259,19 @@ static int __init vkms_init(void)
static void vkms_destroy(struct vkms_config *config)
{
- struct platform_device *pdev;
+ struct faux_device *fdev;
if (!config->dev) {
DRM_INFO("vkms_device is NULL.\n");
return;
}
- pdev = config->dev->platform;
+ fdev = config->dev->faux_dev;
drm_dev_unregister(&config->dev->drm);
drm_atomic_helper_shutdown(&config->dev->drm);
- devres_release_group(&pdev->dev, NULL);
- platform_device_unregister(pdev);
+ devres_release_group(&fdev->dev, NULL);
+ faux_device_destroy(fdev);
config->dev = NULL;
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 00541eff3d1b..f56af53856f7 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -209,13 +209,13 @@ struct vkms_config {
* struct vkms_device - Description of a VKMS device
*
* @drm - Base device in DRM
- * @platform - Associated platform device
+ * @faux_dev - Associated faux device
* @output - Configuration and sub-components of the VKMS device
* @config: Configuration used in this VKMS device
*/
struct vkms_device {
struct drm_device drm;
- struct platform_device *platform;
+ struct faux_device *faux_dev;
struct vkms_output output;
const struct vkms_config *config;
};
--
2.48.1
On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > The vkms driver does not need to create a platform device, as there is > no real platform resources associated it, it only did so because it was > simple to do that in order to get a device to use for resource > management of drm resources. Change the driver to use the faux device > instead as this is NOT a real platform device. > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > Cc: Simona Vetter <simona@ffwll.ch> > Cc: Melissa Wen <melissa.srw@gmail.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Maxime Ripard <mripard@kernel.org> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: David Airlie <airlied@gmail.com> > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Lyude Paul <lyude@redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Thanks for the modification, it seems to work. Louis chauvet
Hi Am 10.02.25 um 15:37 schrieb Louis Chauvet: > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: >> The vkms driver does not need to create a platform device, as there is >> no real platform resources associated it, it only did so because it was >> simple to do that in order to get a device to use for resource >> management of drm resources. Change the driver to use the faux device >> instead as this is NOT a real platform device. >> >> Cc: Louis Chauvet <louis.chauvet@bootlin.com> >> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> >> Cc: Simona Vetter <simona@ffwll.ch> >> Cc: Melissa Wen <melissa.srw@gmail.com> >> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> >> Cc: Maxime Ripard <mripard@kernel.org> >> Cc: Thomas Zimmermann <tzimmermann@suse.de> >> Cc: David Airlie <airlied@gmail.com> >> Cc: dri-devel@lists.freedesktop.org >> Reviewed-by: Lyude Paul <lyude@redhat.com> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > Thanks for the modification, it seems to work. Should this patch be merged through DRM trees? drm-misc-next is at v6.14-rc4 and has struct faux_device. Best regards Thomas > > Louis chauvet > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : > Hi > > Am 10.02.25 um 15:37 schrieb Louis Chauvet: >> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: >>> The vkms driver does not need to create a platform device, as there is >>> no real platform resources associated it, it only did so because it was >>> simple to do that in order to get a device to use for resource >>> management of drm resources. Change the driver to use the faux device >>> instead as this is NOT a real platform device. >>> >>> Cc: Louis Chauvet <louis.chauvet@bootlin.com> >>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> >>> Cc: Simona Vetter <simona@ffwll.ch> >>> Cc: Melissa Wen <melissa.srw@gmail.com> >>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> >>> Cc: Maxime Ripard <mripard@kernel.org> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de> >>> Cc: David Airlie <airlied@gmail.com> >>> Cc: dri-devel@lists.freedesktop.org >>> Reviewed-by: Lyude Paul <lyude@redhat.com> >>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > >> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> >> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> >> >> Thanks for the modification, it seems to work. > > Should this patch be merged through DRM trees? drm-misc-next is at > v6.14-rc4 and has struct faux_device. Hi, I was not aware the faux-device was merged, as it is a new feature, I expected it to reach drm-misc-next on 6.15-rc1. I plan to merge [1] today/tomorrow (well tested with platform_device), and then I will submit an updated version of this patch (only trivial conflicts, but never tested with multiple VKMS devices). [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ Thanks, Louis Chauvet > Best regards > Thomas > > > >> >> Louis chauvet >> > -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote: > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : > > Hi > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet: > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > > > > The vkms driver does not need to create a platform device, as there is > > > > no real platform resources associated it, it only did so because it was > > > > simple to do that in order to get a device to use for resource > > > > management of drm resources. Change the driver to use the faux device > > > > instead as this is NOT a real platform device. > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > > Cc: Simona Vetter <simona@ffwll.ch> > > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > > > Cc: Maxime Ripard <mripard@kernel.org> > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > Cc: David Airlie <airlied@gmail.com> > > > > Cc: dri-devel@lists.freedesktop.org > > > > Reviewed-by: Lyude Paul <lyude@redhat.com> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > Thanks for the modification, it seems to work. > > > > Should this patch be merged through DRM trees? drm-misc-next is at > > v6.14-rc4 and has struct faux_device. > > Hi, > > I was not aware the faux-device was merged, as it is a new feature, I > expected it to reach drm-misc-next on 6.15-rc1. I added it to Linus's tree just so that DRM could get these changes into their tree now :) > I plan to merge [1] today/tomorrow (well tested with platform_device), and > then I will submit an updated version of this patch (only trivial conflicts, > but never tested with multiple VKMS devices). > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ Great, thanks! greg k-h
Hi everyone,
> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> >
> >
> > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > Hi
> > >
> > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > The vkms driver does not need to create a platform device, as there is
> > > > > no real platform resources associated it, it only did so because it was
> > > > > simple to do that in order to get a device to use for resource
> > > > > management of drm resources. Change the driver to use the faux device
> > > > > instead as this is NOT a real platform device.
> > > > >
> > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > >
> > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > >
> > > > Thanks for the modification, it seems to work.
> > >
> > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > v6.14-rc4 and has struct faux_device.
> >
> > Hi,
> >
> > I was not aware the faux-device was merged, as it is a new feature, I
> > expected it to reach drm-misc-next on 6.15-rc1.
>
> I added it to Linus's tree just so that DRM could get these changes into
> their tree now :)
>
> > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > then I will submit an updated version of this patch (only trivial conflicts,
> > but never tested with multiple VKMS devices).
> >
> > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>
> Great, thanks!
>
> greg k-h
Testing this patch again as part of some IGT tests I'm working on,
I noticed that, applying this patch on top of the latest drm-misc-next
triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
drm_gem_get_pages():
if (WARN_ON(!obj->filp))
return ERR_PTR(-EINVAL);
To double check that the cause were not my local changes, I checked
out commit 2d4d775d11d3 ("drm: pl111: fix inconsistent indenting
warning"), which doesn't contain any vkms config changes, applied this
patch and the result is the same.
Louis, do you also see this warning?
For reference, the log is at the end of this email.
Jose
---
[ 110.126952] [drm] Initialized vkms 1.0.0 for vkms on minor 1
[ 110.129193] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
[ 110.326759] ------------[ cut here ]------------
[ 110.326769] WARNING: CPU: 5 PID: 1106 at drivers/gpu/drm/drm_gem.c:571 drm_gem_get_pages+0x5e9/0x780
[ 110.326795] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc e1000 parport i2c_piix4 pcspkr i2c_smbus joydev loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci zram vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
[ 110.326892] CPU: 5 UID: 42 PID: 1106 Comm: KMS thread Not tainted 6.14.0-rc4+ #2
[ 110.326898] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 110.326902] RIP: 0010:drm_gem_get_pages+0x5e9/0x780
[ 110.326909] Code: 8d bd 78 fe ff ff e8 76 ca 8c fe 48 8d bd 78 fe ff ff e8 ea d9 8a fe e8 75 1a 17 01 e9 4b ff ff ff 48 8d 58 ff e9 6a fe ff ff <0f> 0b 49 c7 c7 ea ff ff ff e9 40 ff ff ff 0f 0b e9 0f fb ff ff 4c
[ 110.326914] RSP: 0018:ffffc9000572f550 EFLAGS: 00010246
[ 110.326919] RAX: 1ffff11024531402 RBX: ffff88812298a000 RCX: 0000000000000000
[ 110.326923] RDX: dffffc0000000000 RSI: ffff8881125d54c8 RDI: ffff88812298a010
[ 110.326927] RBP: ffffc9000572f750 R08: 8000000000000063 R09: fffff52000ae5ef0
[ 110.326929] R10: ffffc9000572f787 R11: ffff888104638528 R12: 0000000000000000
[ 110.326932] R13: ffff88812298a168 R14: ffff88812298a0e8 R15: ffff88812298a190
[ 110.326936] FS: 00007f3cf4e536c0(0000) GS:ffff8883af080000(0000) knlGS:0000000000000000
[ 110.326940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 110.326944] CR2: 00007f3cd40337f8 CR3: 00000001394e4000 CR4: 00000000000006f0
[ 110.326951] Call Trace:
[ 110.326954] <TASK>
[ 110.326957] ? show_regs.cold+0x19/0x1e
[ 110.326965] ? __warn.cold+0xbd/0x17f
[ 110.326970] ? drm_gem_get_pages+0x5e9/0x780
[ 110.326975] ? report_bug+0x20b/0x2d0
[ 110.326982] ? handle_bug+0x60/0xa0
[ 110.326988] ? exc_invalid_op+0x1c/0x50
[ 110.326993] ? asm_exc_invalid_op+0x1f/0x30
[ 110.327000] ? drm_gem_get_pages+0x5e9/0x780
[ 110.327005] ? kasan_save_stack+0x4d/0x60
[ 110.327011] ? kasan_save_stack+0x3d/0x60
[ 110.327016] ? kasan_save_track+0x1c/0x70
[ 110.327020] ? kasan_save_alloc_info+0x3b/0x50
[ 110.327025] ? __pfx_drm_gem_get_pages+0x10/0x10
[ 110.327029] ? drm_atomic_helper_commit+0x7c/0x290
[ 110.327037] ? dma_resv_get_singleton+0x99/0x2b0
[ 110.327043] drm_gem_shmem_get_pages+0x69/0x1f0
[ 110.327048] drm_gem_shmem_vmap+0x1f8/0x670
[ 110.327054] drm_gem_shmem_object_vmap+0xd/0x20
[ 110.327058] drm_gem_vmap+0x70/0xd0
[ 110.327063] drm_gem_vmap_unlocked+0x4f/0xa0
[ 110.327067] drm_gem_fb_vmap+0xaf/0x3c0
[ 110.327073] vkms_prepare_fb+0x6e/0x80 [vkms]
[ 110.327081] drm_atomic_helper_prepare_planes+0x1a5/0xba0
[ 110.327088] drm_atomic_helper_commit+0x128/0x290
[ 110.327092] ? __pfx_drm_atomic_helper_commit+0x10/0x10
[ 110.327097] drm_atomic_commit+0x203/0x2d0
[ 110.327101] ? _raw_spin_lock_irqsave+0x97/0xf0
[ 110.327106] ? __pfx_drm_atomic_commit+0x10/0x10
[ 110.327110] ? __pfx___drm_printfn_info+0x10/0x10
[ 110.327116] ? drm_event_reserve_init+0x1cd/0x260
[ 110.327123] drm_mode_atomic_ioctl+0x1d2b/0x2d30
[ 110.327129] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 110.327134] ? __kasan_check_write+0x18/0x20
[ 110.327140] drm_ioctl_kernel+0x177/0x2f0
[ 110.327145] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 110.327149] ? __pfx_drm_ioctl_kernel+0x10/0x10
[ 110.327155] ? __kasan_check_write+0x18/0x20
[ 110.327160] drm_ioctl+0x557/0xc90
[ 110.327165] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 110.327170] ? __pfx_drm_ioctl+0x10/0x10
[ 110.327176] ? selinux_file_ioctl+0x106/0x250
[ 110.327181] ? fdget+0x2ca/0x3d0
[ 110.327185] ? selinux_file_ioctl+0x106/0x250
[ 110.327191] __x64_sys_ioctl+0x13c/0x1a0
[ 110.327198] x64_sys_call+0xf3b/0x1d70
[ 110.327202] do_syscall_64+0x82/0x160
[ 110.327208] ? irqentry_exit+0x3f/0x50
[ 110.327213] ? exc_page_fault+0x94/0x110
[ 110.327218] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 110.327223] RIP: 0033:0x7f3d100fda6d
[ 110.327234] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[ 110.327238] RSP: 002b:00007f3cf4e519b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 110.327244] RAX: ffffffffffffffda RBX: 00007f3cd402a440 RCX: 00007f3d100fda6d
[ 110.327247] RDX: 00007f3cf4e51a50 RSI: 00000000c03864bc RDI: 0000000000000035
[ 110.327250] RBP: 00007f3cf4e51a00 R08: 00000000000000d0 R09: 0000000000000001
[ 110.327254] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f3cf4e51a50
[ 110.327257] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007f3cd4029f20
[ 110.327262] </TASK>
[ 110.327264] ---[ end trace 0000000000000000 ]---
On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote: > Hi everyone, > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote: > > > > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : > > > > Hi > > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet: > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > > > > > > The vkms driver does not need to create a platform device, as there is > > > > > > no real platform resources associated it, it only did so because it was > > > > > > simple to do that in order to get a device to use for resource > > > > > > management of drm resources. Change the driver to use the faux device > > > > > > instead as this is NOT a real platform device. > > > > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > > > > Cc: Simona Vetter <simona@ffwll.ch> > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > > > > > Cc: Maxime Ripard <mripard@kernel.org> > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > Cc: David Airlie <airlied@gmail.com> > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com> > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > > > > Thanks for the modification, it seems to work. > > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at > > > > v6.14-rc4 and has struct faux_device. > > > > > > Hi, > > > > > > I was not aware the faux-device was merged, as it is a new feature, I > > > expected it to reach drm-misc-next on 6.15-rc1. > > > > I added it to Linus's tree just so that DRM could get these changes into > > their tree now :) > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and > > > then I will submit an updated version of this patch (only trivial conflicts, > > > but never tested with multiple VKMS devices). > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ > > > > Great, thanks! > > > > greg k-h > > Testing this patch again as part of some IGT tests I'm working on, > I noticed that, applying this patch on top of the latest drm-misc-next > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in > drm_gem_get_pages(): > > if (WARN_ON(!obj->filp)) > return ERR_PTR(-EINVAL); I don't see how the faux bus change would have anything to do with a filp as that's not related as far as I can tell. But I don't know the drm layer at all, where does that filp come from? thanks, greg k-h
On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote: > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote: > > Hi everyone, > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote: > > > > > > > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : > > > > > Hi > > > > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet: > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > > > > > > > The vkms driver does not need to create a platform device, as there is > > > > > > > no real platform resources associated it, it only did so because it was > > > > > > > simple to do that in order to get a device to use for resource > > > > > > > management of drm resources. Change the driver to use the faux device > > > > > > > instead as this is NOT a real platform device. > > > > > > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > > > > > Cc: Simona Vetter <simona@ffwll.ch> > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > > > > > > Cc: Maxime Ripard <mripard@kernel.org> > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > > Cc: David Airlie <airlied@gmail.com> > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com> > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > > > > > > Thanks for the modification, it seems to work. > > > > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at > > > > > v6.14-rc4 and has struct faux_device. > > > > > > > > Hi, > > > > > > > > I was not aware the faux-device was merged, as it is a new feature, I > > > > expected it to reach drm-misc-next on 6.15-rc1. > > > > > > I added it to Linus's tree just so that DRM could get these changes into > > > their tree now :) > > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and > > > > then I will submit an updated version of this patch (only trivial conflicts, > > > > but never tested with multiple VKMS devices). > > > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ > > > > > > Great, thanks! > > > > > > greg k-h > > > > Testing this patch again as part of some IGT tests I'm working on, > > I noticed that, applying this patch on top of the latest drm-misc-next > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in > > drm_gem_get_pages(): > > > > if (WARN_ON(!obj->filp)) > > return ERR_PTR(-EINVAL); > > I don't see how the faux bus change would have anything to do with a > filp as that's not related as far as I can tell. But I don't know the > drm layer at all, where does that filp come from? Yeah that filp is the shmem file that backs gem bo. That's very far away from anything device/driver related datastrctures. If this is a new failure due to the aux bux conversion then it would be really surprising. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote: > On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote: > > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote: > > > Hi everyone, > > > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote: > > > > > > > > > > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : > > > > > > Hi > > > > > > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet: > > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > > > > > > > > The vkms driver does not need to create a platform device, as there is > > > > > > > > no real platform resources associated it, it only did so because it was > > > > > > > > simple to do that in order to get a device to use for resource > > > > > > > > management of drm resources. Change the driver to use the faux device > > > > > > > > instead as this is NOT a real platform device. > > > > > > > > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > > > > > > Cc: Simona Vetter <simona@ffwll.ch> > > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > > > > > > > Cc: Maxime Ripard <mripard@kernel.org> > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > > > Cc: David Airlie <airlied@gmail.com> > > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com> > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > > > > > > > > > > > > Thanks for the modification, it seems to work. > > > > > > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at > > > > > > v6.14-rc4 and has struct faux_device. > > > > > > > > > > Hi, > > > > > > > > > > I was not aware the faux-device was merged, as it is a new feature, I > > > > > expected it to reach drm-misc-next on 6.15-rc1. > > > > > > > > I added it to Linus's tree just so that DRM could get these changes into > > > > their tree now :) > > > > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and > > > > > then I will submit an updated version of this patch (only trivial conflicts, > > > > > but never tested with multiple VKMS devices). > > > > > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ > > > > > > > > Great, thanks! > > > > > > > > greg k-h > > > > > > Testing this patch again as part of some IGT tests I'm working on, > > > I noticed that, applying this patch on top of the latest drm-misc-next > > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in > > > drm_gem_get_pages(): > > > > > > if (WARN_ON(!obj->filp)) > > > return ERR_PTR(-EINVAL); > > > > I don't see how the faux bus change would have anything to do with a > > filp as that's not related as far as I can tell. But I don't know the > > drm layer at all, where does that filp come from? > > Yeah that filp is the shmem file that backs gem bo. That's very far away > from anything device/driver related datastrctures. If this is a new > failure due to the aux bux conversion then it would be really surprising. Agreed, I find it surprising, but reverting the patch removes the warning. It's most likely an issue on my side, but I decided to double check just in case someone else is also seeing this warning. Jose > -Sima > > -- > Simona Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Hi Am 13.03.25 um 18:20 schrieb José Expósito: > On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote: >> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote: >>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote: >>>> Hi everyone, >>>> >>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote: >>>>>> >>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit : >>>>>>> Hi >>>>>>> >>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet: >>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: >>>>>>>>> The vkms driver does not need to create a platform device, as there is >>>>>>>>> no real platform resources associated it, it only did so because it was >>>>>>>>> simple to do that in order to get a device to use for resource >>>>>>>>> management of drm resources. Change the driver to use the faux device >>>>>>>>> instead as this is NOT a real platform device. >>>>>>>>> >>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com> >>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> >>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch> >>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com> >>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> >>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org> >>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de> >>>>>>>>> Cc: David Airlie <airlied@gmail.com> >>>>>>>>> Cc: dri-devel@lists.freedesktop.org >>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com> >>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> >>>>>>> >>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> >>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> >>>>>>>> >>>>>>>> Thanks for the modification, it seems to work. >>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at >>>>>>> v6.14-rc4 and has struct faux_device. >>>>>> Hi, >>>>>> >>>>>> I was not aware the faux-device was merged, as it is a new feature, I >>>>>> expected it to reach drm-misc-next on 6.15-rc1. >>>>> I added it to Linus's tree just so that DRM could get these changes into >>>>> their tree now :) >>>>> >>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and >>>>>> then I will submit an updated version of this patch (only trivial conflicts, >>>>>> but never tested with multiple VKMS devices). >>>>>> >>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/ >>>>> Great, thanks! >>>>> >>>>> greg k-h >>>> Testing this patch again as part of some IGT tests I'm working on, >>>> I noticed that, applying this patch on top of the latest drm-misc-next >>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in >>>> drm_gem_get_pages(): >>>> >>>> if (WARN_ON(!obj->filp)) >>>> return ERR_PTR(-EINVAL); >>> I don't see how the faux bus change would have anything to do with a >>> filp as that's not related as far as I can tell. But I don't know the >>> drm layer at all, where does that filp come from? >> Yeah that filp is the shmem file that backs gem bo. That's very far away >> from anything device/driver related datastrctures. If this is a new >> failure due to the aux bux conversion then it would be really surprising. > Agreed, I find it surprising, but reverting the patch removes the warning. > > It's most likely an issue on my side, but I decided to double check just > in case someone else is also seeing this warning. Any news on this issue? Best regards Thomas > > Jose > >> -Sima >> >> -- >> Simona Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Hi Thomas,
Thanks for the heads up, this issue fall through the cracks.
On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.03.25 um 18:20 schrieb José Expósito:
> > On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> > > On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > > > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > > > Hi everyone,
> > > > >
> > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > > > >
> > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > > > > no real platform resources associated it, it only did so because it was
> > > > > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > > > > management of drm resources. Change the driver to use the faux device
> > > > > > > > > > instead as this is NOT a real platform device.
> > > > > > > > > >
> > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > >
> > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > >
> > > > > > > > > Thanks for the modification, it seems to work.
> > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > > > > v6.14-rc4 and has struct faux_device.
> > > > > > > Hi,
> > > > > > >
> > > > > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > > > > I added it to Linus's tree just so that DRM could get these changes into
> > > > > > their tree now :)
> > > > > >
> > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > > > > but never tested with multiple VKMS devices).
> > > > > > >
> > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > > > > Great, thanks!
> > > > > >
> > > > > > greg k-h
> > > > > Testing this patch again as part of some IGT tests I'm working on,
> > > > > I noticed that, applying this patch on top of the latest drm-misc-next
> > > > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > > > > drm_gem_get_pages():
> > > > >
> > > > > if (WARN_ON(!obj->filp))
> > > > > return ERR_PTR(-EINVAL);
> > > > I don't see how the faux bus change would have anything to do with a
> > > > filp as that's not related as far as I can tell. But I don't know the
> > > > drm layer at all, where does that filp come from?
> > > Yeah that filp is the shmem file that backs gem bo. That's very far away
> > > from anything device/driver related datastrctures. If this is a new
> > > failure due to the aux bux conversion then it would be really surprising.
> > Agreed, I find it surprising, but reverting the patch removes the warning.
> >
> > It's most likely an issue on my side, but I decided to double check just
> > in case someone else is also seeing this warning.
>
> Any news on this issue?
I tested again with drm-misc-next. At the moment of writing this, the last
commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
access rules") and I still see a similar warning. The stack trace changed,
but the warning is still present.
I'm going to detail the exact steps I followed. Let's see if someone else is
able to reproduce the issue:
I started by applying the patches from this series that are not already merged:
- [PATCH v4 4/9] x86/microcode: move away from using a fake platform
- [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
- [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
- [PATCH v4 9/9] drm/vkms: convert to use faux_device
The last patch has small conflict in vkms_drv.h that I solved like this:
struct vkms_device {
struct drm_device drm;
struct faux_device *faux_dev;
const struct vkms_config *config;
};
And in vkms_drv.c:
static int vkms_create(struct vkms_config *config)
{
int ret;
struct faux_device *fdev;
struct vkms_device *vkms_device;
const char *dev_name;
dev_name = vkms_config_get_device_name(config);
fdev = faux_device_create(dev_name, NULL, NULL);
if (!fdev)
return -ENODEV;
Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
There is nothing special about my Fedora, it is the regular desktop version.
After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
For reference, the warning is at the end of my email.
Am I the only one sawing this warning?
Jose
---
[ 69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
[ 69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
[ 69.520944] ------------[ cut here ]------------
[ 69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
[ 69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
[ 69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
[ 69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
[ 69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
[ 69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
[ 69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
[ 69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
[ 69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
[ 69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
[ 69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
[ 69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
[ 69.521168] FS: 00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
[ 69.521172] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
[ 69.521179] Call Trace:
[ 69.521182] <TASK>
[ 69.521185] ? __pfx_dma_buf_vmap+0x10/0x10
[ 69.521193] ? dma_resv_get_singleton+0x9a/0x2a0
[ 69.521197] drm_gem_shmem_vmap_locked+0xc2/0x5f0
[ 69.521208] ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
[ 69.521212] ? __pfx_ww_mutex_lock+0x10/0x10
[ 69.521225] ? sched_clock_noinstr+0xd/0x20
[ 69.521230] ? local_clock_noinstr+0x13/0xf0
[ 69.521233] drm_gem_shmem_object_vmap+0xd/0x20
[ 69.521237] drm_gem_vmap_locked+0x70/0xf0
[ 69.521247] drm_gem_vmap+0x4c/0xa0
[ 69.521250] drm_gem_fb_vmap+0xb2/0x3b0
[ 69.521255] vkms_prepare_fb+0x6f/0x90 [vkms]
[ 69.521264] ? drm_atomic_helper_setup_commit+0xb7b/0x1320
[ 69.521268] drm_atomic_helper_prepare_planes+0x19f/0xb90
[ 69.521272] ? __pfx_drm_atomic_helper_commit+0x10/0x10
[ 69.521276] drm_atomic_helper_commit+0x126/0x2d0
[ 69.521279] ? __pfx_drm_atomic_helper_commit+0x10/0x10
[ 69.521282] drm_atomic_commit+0x205/0x2d0
[ 69.521290] ? _raw_spin_lock_irqsave+0x97/0xf0
[ 69.521295] ? __pfx_drm_atomic_commit+0x10/0x10
[ 69.521299] ? __pfx___drm_printfn_info+0x10/0x10
[ 69.521313] ? drm_event_reserve_init+0x1cd/0x260
[ 69.521318] drm_mode_atomic_ioctl+0x1c79/0x2d30
[ 69.521323] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 69.521326] ? __kasan_check_write+0x18/0x20
[ 69.521339] drm_ioctl_kernel+0x17b/0x2f0
[ 69.521343] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 69.521349] ? __pfx_drm_ioctl_kernel+0x10/0x10
[ 69.521353] ? __pfx_do_vfs_ioctl+0x10/0x10
[ 69.521361] ? __kasan_check_write+0x18/0x20
[ 69.521365] drm_ioctl+0x51b/0xbd0
[ 69.521369] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 69.521373] ? __pfx_drm_ioctl+0x10/0x10
[ 69.521378] ? selinux_file_ioctl+0xfc/0x260
[ 69.521390] __x64_sys_ioctl+0x143/0x1d0
[ 69.521394] x64_sys_call+0xf4b/0x1d70
[ 69.521404] do_syscall_64+0x82/0x2a0
[ 69.521408] ? __kasan_check_write+0x18/0x20
[ 69.521411] ? do_user_addr_fault+0x491/0xa60
[ 69.521420] ? irqentry_exit+0x3f/0x50
[ 69.521423] ? exc_page_fault+0x8b/0xe0
[ 69.521426] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 69.521430] RIP: 0033:0x7fbc078fd8ed
[ 69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[ 69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
[ 69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
[ 69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
[ 69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
[ 69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
[ 69.521464] </TASK>
[ 69.521466] ---[ end trace 0000000000000000 ]---
> Best regards
> Thomas
>
> >
> > Jose
> >
> > > -Sima
> > >
> > > --
> > > Simona Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
Hi
Am 13.06.25 um 13:55 schrieb José Expósito:
> Hi Thomas,
>
> Thanks for the heads up, this issue fall through the cracks.
>
> On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 13.03.25 um 18:20 schrieb José Expósito:
>>> On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
>>>> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
>>>>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
>>>>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>>>>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>>>>>>>>>> The vkms driver does not need to create a platform device, as there is
>>>>>>>>>>> no real platform resources associated it, it only did so because it was
>>>>>>>>>>> simple to do that in order to get a device to use for resource
>>>>>>>>>>> management of drm resources. Change the driver to use the faux device
>>>>>>>>>>> instead as this is NOT a real platform device.
>>>>>>>>>>>
>>>>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>>>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch>
>>>>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>>>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org>
>>>>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>> Cc: David Airlie <airlied@gmail.com>
>>>>>>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>
>>>>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>
>>>>>>>>>> Thanks for the modification, it seems to work.
>>>>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at
>>>>>>>>> v6.14-rc4 and has struct faux_device.
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was not aware the faux-device was merged, as it is a new feature, I
>>>>>>>> expected it to reach drm-misc-next on 6.15-rc1.
>>>>>>> I added it to Linus's tree just so that DRM could get these changes into
>>>>>>> their tree now :)
>>>>>>>
>>>>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and
>>>>>>>> then I will submit an updated version of this patch (only trivial conflicts,
>>>>>>>> but never tested with multiple VKMS devices).
>>>>>>>>
>>>>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>>>>>>> Great, thanks!
>>>>>>>
>>>>>>> greg k-h
>>>>>> Testing this patch again as part of some IGT tests I'm working on,
>>>>>> I noticed that, applying this patch on top of the latest drm-misc-next
>>>>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
>>>>>> drm_gem_get_pages():
>>>>>>
>>>>>> if (WARN_ON(!obj->filp))
>>>>>> return ERR_PTR(-EINVAL);
>>>>> I don't see how the faux bus change would have anything to do with a
>>>>> filp as that's not related as far as I can tell. But I don't know the
>>>>> drm layer at all, where does that filp come from?
>>>> Yeah that filp is the shmem file that backs gem bo. That's very far away
>>>> from anything device/driver related datastrctures. If this is a new
>>>> failure due to the aux bux conversion then it would be really surprising.
>>> Agreed, I find it surprising, but reverting the patch removes the warning.
>>>
>>> It's most likely an issue on my side, but I decided to double check just
>>> in case someone else is also seeing this warning.
>> Any news on this issue?
> I tested again with drm-misc-next. At the moment of writing this, the last
> commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
> access rules") and I still see a similar warning. The stack trace changed,
> but the warning is still present.
>
> I'm going to detail the exact steps I followed. Let's see if someone else is
> able to reproduce the issue:
>
> I started by applying the patches from this series that are not already merged:
>
> - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
> - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
> - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
> - [PATCH v4 9/9] drm/vkms: convert to use faux_device
>
> The last patch has small conflict in vkms_drv.h that I solved like this:
>
> struct vkms_device {
> struct drm_device drm;
> struct faux_device *faux_dev;
> const struct vkms_config *config;
> };
>
> And in vkms_drv.c:
>
> static int vkms_create(struct vkms_config *config)
> {
> int ret;
> struct faux_device *fdev;
> struct vkms_device *vkms_device;
> const char *dev_name;
>
> dev_name = vkms_config_get_device_name(config);
> fdev = faux_device_create(dev_name, NULL, NULL);
> if (!fdev)
> return -ENODEV;
>
> Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
> There is nothing special about my Fedora, it is the regular desktop version.
>
> After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
> For reference, the warning is at the end of my email.
>
> Am I the only one sawing this warning?
>
> Jose
>
> ---
>
> [ 69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> [ 69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> [ 69.520944] ------------[ cut here ]------------
> [ 69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
> [ 69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> [ 69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
> [ 69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> [ 69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
That's dmabuf. could be related to the fact that there's no real DMA
possible with the faux_device. We now have support for
dmabuf-without-DMA, sort of. Could you please replace
DRM_GEM_SHMEM_DRIVER_OPS with the new
DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual
hardware-DMA functionality.
[1]
https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104
Best regards
Thomas
> [ 69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
> [ 69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
> [ 69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
> [ 69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
> [ 69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
> [ 69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
> [ 69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
> [ 69.521168] FS: 00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
> [ 69.521172] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
> [ 69.521179] Call Trace:
> [ 69.521182] <TASK>
> [ 69.521185] ? __pfx_dma_buf_vmap+0x10/0x10
> [ 69.521193] ? dma_resv_get_singleton+0x9a/0x2a0
> [ 69.521197] drm_gem_shmem_vmap_locked+0xc2/0x5f0
> [ 69.521208] ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
> [ 69.521212] ? __pfx_ww_mutex_lock+0x10/0x10
> [ 69.521225] ? sched_clock_noinstr+0xd/0x20
> [ 69.521230] ? local_clock_noinstr+0x13/0xf0
> [ 69.521233] drm_gem_shmem_object_vmap+0xd/0x20
> [ 69.521237] drm_gem_vmap_locked+0x70/0xf0
> [ 69.521247] drm_gem_vmap+0x4c/0xa0
> [ 69.521250] drm_gem_fb_vmap+0xb2/0x3b0
> [ 69.521255] vkms_prepare_fb+0x6f/0x90 [vkms]
> [ 69.521264] ? drm_atomic_helper_setup_commit+0xb7b/0x1320
> [ 69.521268] drm_atomic_helper_prepare_planes+0x19f/0xb90
> [ 69.521272] ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [ 69.521276] drm_atomic_helper_commit+0x126/0x2d0
> [ 69.521279] ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [ 69.521282] drm_atomic_commit+0x205/0x2d0
> [ 69.521290] ? _raw_spin_lock_irqsave+0x97/0xf0
> [ 69.521295] ? __pfx_drm_atomic_commit+0x10/0x10
> [ 69.521299] ? __pfx___drm_printfn_info+0x10/0x10
> [ 69.521313] ? drm_event_reserve_init+0x1cd/0x260
> [ 69.521318] drm_mode_atomic_ioctl+0x1c79/0x2d30
> [ 69.521323] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 69.521326] ? __kasan_check_write+0x18/0x20
> [ 69.521339] drm_ioctl_kernel+0x17b/0x2f0
> [ 69.521343] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 69.521349] ? __pfx_drm_ioctl_kernel+0x10/0x10
> [ 69.521353] ? __pfx_do_vfs_ioctl+0x10/0x10
> [ 69.521361] ? __kasan_check_write+0x18/0x20
> [ 69.521365] drm_ioctl+0x51b/0xbd0
> [ 69.521369] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 69.521373] ? __pfx_drm_ioctl+0x10/0x10
> [ 69.521378] ? selinux_file_ioctl+0xfc/0x260
> [ 69.521390] __x64_sys_ioctl+0x143/0x1d0
> [ 69.521394] x64_sys_call+0xf4b/0x1d70
> [ 69.521404] do_syscall_64+0x82/0x2a0
> [ 69.521408] ? __kasan_check_write+0x18/0x20
> [ 69.521411] ? do_user_addr_fault+0x491/0xa60
> [ 69.521420] ? irqentry_exit+0x3f/0x50
> [ 69.521423] ? exc_page_fault+0x8b/0xe0
> [ 69.521426] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 69.521430] RIP: 0033:0x7fbc078fd8ed
> [ 69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> [ 69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
> [ 69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
> [ 69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
> [ 69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
> [ 69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
> [ 69.521464] </TASK>
> [ 69.521466] ---[ end trace 0000000000000000 ]---
>
>
>
>> Best regards
>> Thomas
>>
>>> Jose
>>>
>>>> -Sima
>>>>
>>>> --
>>>> Simona Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Hi,
On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.06.25 um 13:55 schrieb José Expósito:
> > Hi Thomas,
> >
> > Thanks for the heads up, this issue fall through the cracks.
> >
> > On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 13.03.25 um 18:20 schrieb José Expósito:
> > > > On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> > > > > On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > > > > > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > > > > > > no real platform resources associated it, it only did so because it was
> > > > > > > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > > > > > > management of drm resources. Change the driver to use the faux device
> > > > > > > > > > > > instead as this is NOT a real platform device.
> > > > > > > > > > > >
> > > > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > >
> > > > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the modification, it seems to work.
> > > > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > > > > > > v6.14-rc4 and has struct faux_device.
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > > > > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > > > > > > I added it to Linus's tree just so that DRM could get these changes into
> > > > > > > > their tree now :)
> > > > > > > >
> > > > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > > > > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > > > > > > but never tested with multiple VKMS devices).
> > > > > > > > >
> > > > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > > > > > > Great, thanks!
> > > > > > > >
> > > > > > > > greg k-h
> > > > > > > Testing this patch again as part of some IGT tests I'm working on,
> > > > > > > I noticed that, applying this patch on top of the latest drm-misc-next
> > > > > > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > > > > > > drm_gem_get_pages():
> > > > > > >
> > > > > > > if (WARN_ON(!obj->filp))
> > > > > > > return ERR_PTR(-EINVAL);
> > > > > > I don't see how the faux bus change would have anything to do with a
> > > > > > filp as that's not related as far as I can tell. But I don't know the
> > > > > > drm layer at all, where does that filp come from?
> > > > > Yeah that filp is the shmem file that backs gem bo. That's very far away
> > > > > from anything device/driver related datastrctures. If this is a new
> > > > > failure due to the aux bux conversion then it would be really surprising.
> > > > Agreed, I find it surprising, but reverting the patch removes the warning.
> > > >
> > > > It's most likely an issue on my side, but I decided to double check just
> > > > in case someone else is also seeing this warning.
> > > Any news on this issue?
> > I tested again with drm-misc-next. At the moment of writing this, the last
> > commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
> > access rules") and I still see a similar warning. The stack trace changed,
> > but the warning is still present.
> >
> > I'm going to detail the exact steps I followed. Let's see if someone else is
> > able to reproduce the issue:
> >
> > I started by applying the patches from this series that are not already merged:
> >
> > - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
> > - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
> > - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
> > - [PATCH v4 9/9] drm/vkms: convert to use faux_device
> >
> > The last patch has small conflict in vkms_drv.h that I solved like this:
> >
> > struct vkms_device {
> > struct drm_device drm;
> > struct faux_device *faux_dev;
> > const struct vkms_config *config;
> > };
> >
> > And in vkms_drv.c:
> >
> > static int vkms_create(struct vkms_config *config)
> > {
> > int ret;
> > struct faux_device *fdev;
> > struct vkms_device *vkms_device;
> > const char *dev_name;
> >
> > dev_name = vkms_config_get_device_name(config);
> > fdev = faux_device_create(dev_name, NULL, NULL);
> > if (!fdev)
> > return -ENODEV;
> >
> > Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
> > There is nothing special about my Fedora, it is the regular desktop version.
> >
> > After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
> > For reference, the warning is at the end of my email.
> >
> > Am I the only one sawing this warning?
> >
> > Jose
> >
> > ---
> >
> > [ 69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> > [ 69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> > [ 69.520944] ------------[ cut here ]------------
> > [ 69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
> > [ 69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> > [ 69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
> > [ 69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> > [ 69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
>
> That's dmabuf. could be related to the fact that there's no real DMA
> possible with the faux_device. We now have support for dmabuf-without-DMA,
> sort of. Could you please replace DRM_GEM_SHMEM_DRIVER_OPS with the new
> DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual
> hardware-DMA functionality.
I don't see the warning anymore :) However, could this change introduce
unexpected side-effects?
Since Louis and Greg didn't see this warning, I'm a bit worried that it
is caused by something unrelated in my dev environment.
If the change can cause other issues, I'd prefer to avoid it. It is weird
that I'm the only one seeing it.
Jose
> [1] https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104
>
> Best regards
> Thomas
>
>
> > [ 69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
> > [ 69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
> > [ 69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
> > [ 69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
> > [ 69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
> > [ 69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
> > [ 69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
> > [ 69.521168] FS: 00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
> > [ 69.521172] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
> > [ 69.521179] Call Trace:
> > [ 69.521182] <TASK>
> > [ 69.521185] ? __pfx_dma_buf_vmap+0x10/0x10
> > [ 69.521193] ? dma_resv_get_singleton+0x9a/0x2a0
> > [ 69.521197] drm_gem_shmem_vmap_locked+0xc2/0x5f0
> > [ 69.521208] ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
> > [ 69.521212] ? __pfx_ww_mutex_lock+0x10/0x10
> > [ 69.521225] ? sched_clock_noinstr+0xd/0x20
> > [ 69.521230] ? local_clock_noinstr+0x13/0xf0
> > [ 69.521233] drm_gem_shmem_object_vmap+0xd/0x20
> > [ 69.521237] drm_gem_vmap_locked+0x70/0xf0
> > [ 69.521247] drm_gem_vmap+0x4c/0xa0
> > [ 69.521250] drm_gem_fb_vmap+0xb2/0x3b0
> > [ 69.521255] vkms_prepare_fb+0x6f/0x90 [vkms]
> > [ 69.521264] ? drm_atomic_helper_setup_commit+0xb7b/0x1320
> > [ 69.521268] drm_atomic_helper_prepare_planes+0x19f/0xb90
> > [ 69.521272] ? __pfx_drm_atomic_helper_commit+0x10/0x10
> > [ 69.521276] drm_atomic_helper_commit+0x126/0x2d0
> > [ 69.521279] ? __pfx_drm_atomic_helper_commit+0x10/0x10
> > [ 69.521282] drm_atomic_commit+0x205/0x2d0
> > [ 69.521290] ? _raw_spin_lock_irqsave+0x97/0xf0
> > [ 69.521295] ? __pfx_drm_atomic_commit+0x10/0x10
> > [ 69.521299] ? __pfx___drm_printfn_info+0x10/0x10
> > [ 69.521313] ? drm_event_reserve_init+0x1cd/0x260
> > [ 69.521318] drm_mode_atomic_ioctl+0x1c79/0x2d30
> > [ 69.521323] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [ 69.521326] ? __kasan_check_write+0x18/0x20
> > [ 69.521339] drm_ioctl_kernel+0x17b/0x2f0
> > [ 69.521343] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [ 69.521349] ? __pfx_drm_ioctl_kernel+0x10/0x10
> > [ 69.521353] ? __pfx_do_vfs_ioctl+0x10/0x10
> > [ 69.521361] ? __kasan_check_write+0x18/0x20
> > [ 69.521365] drm_ioctl+0x51b/0xbd0
> > [ 69.521369] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [ 69.521373] ? __pfx_drm_ioctl+0x10/0x10
> > [ 69.521378] ? selinux_file_ioctl+0xfc/0x260
> > [ 69.521390] __x64_sys_ioctl+0x143/0x1d0
> > [ 69.521394] x64_sys_call+0xf4b/0x1d70
> > [ 69.521404] do_syscall_64+0x82/0x2a0
> > [ 69.521408] ? __kasan_check_write+0x18/0x20
> > [ 69.521411] ? do_user_addr_fault+0x491/0xa60
> > [ 69.521420] ? irqentry_exit+0x3f/0x50
> > [ 69.521423] ? exc_page_fault+0x8b/0xe0
> > [ 69.521426] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [ 69.521430] RIP: 0033:0x7fbc078fd8ed
> > [ 69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> > [ 69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > [ 69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
> > [ 69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
> > [ 69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
> > [ 69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
> > [ 69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
> > [ 69.521464] </TASK>
> > [ 69.521466] ---[ end trace 0000000000000000 ]---
> >
> >
> >
> > > Best regards
> > > Thomas
> > >
> > > > Jose
> > > >
> > > > > -Sima
> > > > >
> > > > > --
> > > > > Simona Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > > --
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Frankenstrasse 146, 90461 Nuernberg, Germany
> > > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> > > HRB 36809 (AG Nuernberg)
> > >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
Hi
Am 13.06.25 um 17:28 schrieb José Expósito:
> Hi,
>
> On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 13.06.25 um 13:55 schrieb José Expósito:
>>> Hi Thomas,
>>>
>>> Thanks for the heads up, this issue fall through the cracks.
>>>
>>> On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 13.03.25 um 18:20 schrieb José Expósito:
>>>>> On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
>>>>>> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
>>>>>>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
>>>>>>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>>>>>>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>>>>>>>>>>>> The vkms driver does not need to create a platform device, as there is
>>>>>>>>>>>>> no real platform resources associated it, it only did so because it was
>>>>>>>>>>>>> simple to do that in order to get a device to use for resource
>>>>>>>>>>>>> management of drm resources. Change the driver to use the faux device
>>>>>>>>>>>>> instead as this is NOT a real platform device.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>>>>>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch>
>>>>>>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>>>>>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org>
>>>>>>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>>>> Cc: David Airlie <airlied@gmail.com>
>>>>>>>>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>>
>>>>>>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the modification, it seems to work.
>>>>>>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at
>>>>>>>>>>> v6.14-rc4 and has struct faux_device.
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I was not aware the faux-device was merged, as it is a new feature, I
>>>>>>>>>> expected it to reach drm-misc-next on 6.15-rc1.
>>>>>>>>> I added it to Linus's tree just so that DRM could get these changes into
>>>>>>>>> their tree now :)
>>>>>>>>>
>>>>>>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and
>>>>>>>>>> then I will submit an updated version of this patch (only trivial conflicts,
>>>>>>>>>> but never tested with multiple VKMS devices).
>>>>>>>>>>
>>>>>>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>>>>>>>>> Great, thanks!
>>>>>>>>>
>>>>>>>>> greg k-h
>>>>>>>> Testing this patch again as part of some IGT tests I'm working on,
>>>>>>>> I noticed that, applying this patch on top of the latest drm-misc-next
>>>>>>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
>>>>>>>> drm_gem_get_pages():
>>>>>>>>
>>>>>>>> if (WARN_ON(!obj->filp))
>>>>>>>> return ERR_PTR(-EINVAL);
>>>>>>> I don't see how the faux bus change would have anything to do with a
>>>>>>> filp as that's not related as far as I can tell. But I don't know the
>>>>>>> drm layer at all, where does that filp come from?
>>>>>> Yeah that filp is the shmem file that backs gem bo. That's very far away
>>>>>> from anything device/driver related datastrctures. If this is a new
>>>>>> failure due to the aux bux conversion then it would be really surprising.
>>>>> Agreed, I find it surprising, but reverting the patch removes the warning.
>>>>>
>>>>> It's most likely an issue on my side, but I decided to double check just
>>>>> in case someone else is also seeing this warning.
>>>> Any news on this issue?
>>> I tested again with drm-misc-next. At the moment of writing this, the last
>>> commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
>>> access rules") and I still see a similar warning. The stack trace changed,
>>> but the warning is still present.
>>>
>>> I'm going to detail the exact steps I followed. Let's see if someone else is
>>> able to reproduce the issue:
>>>
>>> I started by applying the patches from this series that are not already merged:
>>>
>>> - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
>>> - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
>>> - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
>>> - [PATCH v4 9/9] drm/vkms: convert to use faux_device
>>>
>>> The last patch has small conflict in vkms_drv.h that I solved like this:
>>>
>>> struct vkms_device {
>>> struct drm_device drm;
>>> struct faux_device *faux_dev;
>>> const struct vkms_config *config;
>>> };
>>>
>>> And in vkms_drv.c:
>>>
>>> static int vkms_create(struct vkms_config *config)
>>> {
>>> int ret;
>>> struct faux_device *fdev;
>>> struct vkms_device *vkms_device;
>>> const char *dev_name;
>>>
>>> dev_name = vkms_config_get_device_name(config);
>>> fdev = faux_device_create(dev_name, NULL, NULL);
>>> if (!fdev)
>>> return -ENODEV;
>>>
>>> Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
>>> There is nothing special about my Fedora, it is the regular desktop version.
>>>
>>> After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
>>> For reference, the warning is at the end of my email.
>>>
>>> Am I the only one sawing this warning?
>>>
>>> Jose
>>>
>>> ---
>>>
>>> [ 69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
>>> [ 69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
>>> [ 69.520944] ------------[ cut here ]------------
>>> [ 69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
>>> [ 69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
>>> [ 69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
>>> [ 69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
>>> [ 69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
>> That's dmabuf. could be related to the fact that there's no real DMA
>> possible with the faux_device. We now have support for dmabuf-without-DMA,
>> sort of. Could you please replace DRM_GEM_SHMEM_DRIVER_OPS with the new
>> DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual
>> hardware-DMA functionality.
> I don't see the warning anymore :) However, could this change introduce
> unexpected side-effects?
Great that it works. I plan to roll this out for most of the
GEM-SHMEM-based drivers and it will hopefully not cause any problems.
>
> Since Louis and Greg didn't see this warning, I'm a bit worried that it
> is caused by something unrelated in my dev environment.
> If the change can cause other issues, I'd prefer to avoid it. It is weird
> that I'm the only one seeing it.
Could be related to the test environment, but I cannot point to the
difference.
Best regards
Thomas
>
> Jose
>
>> [1] https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104
>>
>> Best regards
>> Thomas
>>
>>
>>> [ 69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
>>> [ 69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
>>> [ 69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
>>> [ 69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
>>> [ 69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
>>> [ 69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
>>> [ 69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
>>> [ 69.521168] FS: 00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
>>> [ 69.521172] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
>>> [ 69.521179] Call Trace:
>>> [ 69.521182] <TASK>
>>> [ 69.521185] ? __pfx_dma_buf_vmap+0x10/0x10
>>> [ 69.521193] ? dma_resv_get_singleton+0x9a/0x2a0
>>> [ 69.521197] drm_gem_shmem_vmap_locked+0xc2/0x5f0
>>> [ 69.521208] ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
>>> [ 69.521212] ? __pfx_ww_mutex_lock+0x10/0x10
>>> [ 69.521225] ? sched_clock_noinstr+0xd/0x20
>>> [ 69.521230] ? local_clock_noinstr+0x13/0xf0
>>> [ 69.521233] drm_gem_shmem_object_vmap+0xd/0x20
>>> [ 69.521237] drm_gem_vmap_locked+0x70/0xf0
>>> [ 69.521247] drm_gem_vmap+0x4c/0xa0
>>> [ 69.521250] drm_gem_fb_vmap+0xb2/0x3b0
>>> [ 69.521255] vkms_prepare_fb+0x6f/0x90 [vkms]
>>> [ 69.521264] ? drm_atomic_helper_setup_commit+0xb7b/0x1320
>>> [ 69.521268] drm_atomic_helper_prepare_planes+0x19f/0xb90
>>> [ 69.521272] ? __pfx_drm_atomic_helper_commit+0x10/0x10
>>> [ 69.521276] drm_atomic_helper_commit+0x126/0x2d0
>>> [ 69.521279] ? __pfx_drm_atomic_helper_commit+0x10/0x10
>>> [ 69.521282] drm_atomic_commit+0x205/0x2d0
>>> [ 69.521290] ? _raw_spin_lock_irqsave+0x97/0xf0
>>> [ 69.521295] ? __pfx_drm_atomic_commit+0x10/0x10
>>> [ 69.521299] ? __pfx___drm_printfn_info+0x10/0x10
>>> [ 69.521313] ? drm_event_reserve_init+0x1cd/0x260
>>> [ 69.521318] drm_mode_atomic_ioctl+0x1c79/0x2d30
>>> [ 69.521323] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [ 69.521326] ? __kasan_check_write+0x18/0x20
>>> [ 69.521339] drm_ioctl_kernel+0x17b/0x2f0
>>> [ 69.521343] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [ 69.521349] ? __pfx_drm_ioctl_kernel+0x10/0x10
>>> [ 69.521353] ? __pfx_do_vfs_ioctl+0x10/0x10
>>> [ 69.521361] ? __kasan_check_write+0x18/0x20
>>> [ 69.521365] drm_ioctl+0x51b/0xbd0
>>> [ 69.521369] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [ 69.521373] ? __pfx_drm_ioctl+0x10/0x10
>>> [ 69.521378] ? selinux_file_ioctl+0xfc/0x260
>>> [ 69.521390] __x64_sys_ioctl+0x143/0x1d0
>>> [ 69.521394] x64_sys_call+0xf4b/0x1d70
>>> [ 69.521404] do_syscall_64+0x82/0x2a0
>>> [ 69.521408] ? __kasan_check_write+0x18/0x20
>>> [ 69.521411] ? do_user_addr_fault+0x491/0xa60
>>> [ 69.521420] ? irqentry_exit+0x3f/0x50
>>> [ 69.521423] ? exc_page_fault+0x8b/0xe0
>>> [ 69.521426] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>> [ 69.521430] RIP: 0033:0x7fbc078fd8ed
>>> [ 69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
>>> [ 69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>>> [ 69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
>>> [ 69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
>>> [ 69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
>>> [ 69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
>>> [ 69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
>>> [ 69.521464] </TASK>
>>> [ 69.521466] ---[ end trace 0000000000000000 ]---
>>>
>>>
>>>
>>>> Best regards
>>>> Thomas
>>>>
>>>>> Jose
>>>>>
>>>>>> -Sima
>>>>>>
>>>>>> --
>>>>>> Simona Vetter
>>>>>> Software Engineer, Intel Corporation
>>>>>> http://blog.ffwll.ch
>>>> --
>>>> --
>>>> Thomas Zimmermann
>>>> Graphics Driver Developer
>>>> SUSE Software Solutions Germany GmbH
>>>> Frankenstrasse 146, 90461 Nuernberg, Germany
>>>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>>>> HRB 36809 (AG Nuernberg)
>>>>
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> Hi everyone,
>
> > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > >
> > >
> > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > Hi
> > > >
> > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > no real platform resources associated it, it only did so because it was
> > > > > > simple to do that in order to get a device to use for resource
> > > > > > management of drm resources. Change the driver to use the faux device
> > > > > > instead as this is NOT a real platform device.
> > > > > >
> > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > >
> > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > >
> > > > > Thanks for the modification, it seems to work.
> > > >
> > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > v6.14-rc4 and has struct faux_device.
> > >
> > > Hi,
> > >
> > > I was not aware the faux-device was merged, as it is a new feature, I
> > > expected it to reach drm-misc-next on 6.15-rc1.
> >
> > I added it to Linus's tree just so that DRM could get these changes into
> > their tree now :)
> >
> > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > then I will submit an updated version of this patch (only trivial conflicts,
> > > but never tested with multiple VKMS devices).
> > >
> > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> >
> > Great, thanks!
> >
> > greg k-h
>
> Testing this patch again as part of some IGT tests I'm working on,
> I noticed that, applying this patch on top of the latest drm-misc-next
> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> drm_gem_get_pages():
>
> if (WARN_ON(!obj->filp))
> return ERR_PTR(-EINVAL);
I forgot to mention that this warning is triggered just by `sudo modprobe vkms`.
Sorry for the additional email.
Jose
> To double check that the cause were not my local changes, I checked
> out commit 2d4d775d11d3 ("drm: pl111: fix inconsistent indenting
> warning"), which doesn't contain any vkms config changes, applied this
> patch and the result is the same.
>
> Louis, do you also see this warning?
>
> For reference, the log is at the end of this email.
> Jose
>
> ---
>
> [ 110.126952] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> [ 110.129193] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> [ 110.326759] ------------[ cut here ]------------
> [ 110.326769] WARNING: CPU: 5 PID: 1106 at drivers/gpu/drm/drm_gem.c:571 drm_gem_get_pages+0x5e9/0x780
> [ 110.326795] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc e1000 parport i2c_piix4 pcspkr i2c_smbus joydev loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci zram vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> [ 110.326892] CPU: 5 UID: 42 PID: 1106 Comm: KMS thread Not tainted 6.14.0-rc4+ #2
> [ 110.326898] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
> [ 110.326902] RIP: 0010:drm_gem_get_pages+0x5e9/0x780
> [ 110.326909] Code: 8d bd 78 fe ff ff e8 76 ca 8c fe 48 8d bd 78 fe ff ff e8 ea d9 8a fe e8 75 1a 17 01 e9 4b ff ff ff 48 8d 58 ff e9 6a fe ff ff <0f> 0b 49 c7 c7 ea ff ff ff e9 40 ff ff ff 0f 0b e9 0f fb ff ff 4c
> [ 110.326914] RSP: 0018:ffffc9000572f550 EFLAGS: 00010246
> [ 110.326919] RAX: 1ffff11024531402 RBX: ffff88812298a000 RCX: 0000000000000000
> [ 110.326923] RDX: dffffc0000000000 RSI: ffff8881125d54c8 RDI: ffff88812298a010
> [ 110.326927] RBP: ffffc9000572f750 R08: 8000000000000063 R09: fffff52000ae5ef0
> [ 110.326929] R10: ffffc9000572f787 R11: ffff888104638528 R12: 0000000000000000
> [ 110.326932] R13: ffff88812298a168 R14: ffff88812298a0e8 R15: ffff88812298a190
> [ 110.326936] FS: 00007f3cf4e536c0(0000) GS:ffff8883af080000(0000) knlGS:0000000000000000
> [ 110.326940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 110.326944] CR2: 00007f3cd40337f8 CR3: 00000001394e4000 CR4: 00000000000006f0
> [ 110.326951] Call Trace:
> [ 110.326954] <TASK>
> [ 110.326957] ? show_regs.cold+0x19/0x1e
> [ 110.326965] ? __warn.cold+0xbd/0x17f
> [ 110.326970] ? drm_gem_get_pages+0x5e9/0x780
> [ 110.326975] ? report_bug+0x20b/0x2d0
> [ 110.326982] ? handle_bug+0x60/0xa0
> [ 110.326988] ? exc_invalid_op+0x1c/0x50
> [ 110.326993] ? asm_exc_invalid_op+0x1f/0x30
> [ 110.327000] ? drm_gem_get_pages+0x5e9/0x780
> [ 110.327005] ? kasan_save_stack+0x4d/0x60
> [ 110.327011] ? kasan_save_stack+0x3d/0x60
> [ 110.327016] ? kasan_save_track+0x1c/0x70
> [ 110.327020] ? kasan_save_alloc_info+0x3b/0x50
> [ 110.327025] ? __pfx_drm_gem_get_pages+0x10/0x10
> [ 110.327029] ? drm_atomic_helper_commit+0x7c/0x290
> [ 110.327037] ? dma_resv_get_singleton+0x99/0x2b0
> [ 110.327043] drm_gem_shmem_get_pages+0x69/0x1f0
> [ 110.327048] drm_gem_shmem_vmap+0x1f8/0x670
> [ 110.327054] drm_gem_shmem_object_vmap+0xd/0x20
> [ 110.327058] drm_gem_vmap+0x70/0xd0
> [ 110.327063] drm_gem_vmap_unlocked+0x4f/0xa0
> [ 110.327067] drm_gem_fb_vmap+0xaf/0x3c0
> [ 110.327073] vkms_prepare_fb+0x6e/0x80 [vkms]
> [ 110.327081] drm_atomic_helper_prepare_planes+0x1a5/0xba0
> [ 110.327088] drm_atomic_helper_commit+0x128/0x290
> [ 110.327092] ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [ 110.327097] drm_atomic_commit+0x203/0x2d0
> [ 110.327101] ? _raw_spin_lock_irqsave+0x97/0xf0
> [ 110.327106] ? __pfx_drm_atomic_commit+0x10/0x10
> [ 110.327110] ? __pfx___drm_printfn_info+0x10/0x10
> [ 110.327116] ? drm_event_reserve_init+0x1cd/0x260
> [ 110.327123] drm_mode_atomic_ioctl+0x1d2b/0x2d30
> [ 110.327129] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 110.327134] ? __kasan_check_write+0x18/0x20
> [ 110.327140] drm_ioctl_kernel+0x177/0x2f0
> [ 110.327145] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 110.327149] ? __pfx_drm_ioctl_kernel+0x10/0x10
> [ 110.327155] ? __kasan_check_write+0x18/0x20
> [ 110.327160] drm_ioctl+0x557/0xc90
> [ 110.327165] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [ 110.327170] ? __pfx_drm_ioctl+0x10/0x10
> [ 110.327176] ? selinux_file_ioctl+0x106/0x250
> [ 110.327181] ? fdget+0x2ca/0x3d0
> [ 110.327185] ? selinux_file_ioctl+0x106/0x250
> [ 110.327191] __x64_sys_ioctl+0x13c/0x1a0
> [ 110.327198] x64_sys_call+0xf3b/0x1d70
> [ 110.327202] do_syscall_64+0x82/0x160
> [ 110.327208] ? irqentry_exit+0x3f/0x50
> [ 110.327213] ? exc_page_fault+0x94/0x110
> [ 110.327218] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 110.327223] RIP: 0033:0x7f3d100fda6d
> [ 110.327234] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> [ 110.327238] RSP: 002b:00007f3cf4e519b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 110.327244] RAX: ffffffffffffffda RBX: 00007f3cd402a440 RCX: 00007f3d100fda6d
> [ 110.327247] RDX: 00007f3cf4e51a50 RSI: 00000000c03864bc RDI: 0000000000000035
> [ 110.327250] RBP: 00007f3cf4e51a00 R08: 00000000000000d0 R09: 0000000000000001
> [ 110.327254] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f3cf4e51a50
> [ 110.327257] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007f3cd4029f20
> [ 110.327262] </TASK>
> [ 110.327264] ---[ end trace 0000000000000000 ]---
On Mon, Feb 10, 2025 at 03:37:42PM +0100, Louis Chauvet wrote: > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote: > > The vkms driver does not need to create a platform device, as there is > > no real platform resources associated it, it only did so because it was > > simple to do that in order to get a device to use for resource > > management of drm resources. Change the driver to use the faux device > > instead as this is NOT a real platform device. > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com> > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > Cc: Simona Vetter <simona@ffwll.ch> > > Cc: Melissa Wen <melissa.srw@gmail.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Cc: Maxime Ripard <mripard@kernel.org> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > Cc: David Airlie <airlied@gmail.com> > > Cc: dri-devel@lists.freedesktop.org > > Reviewed-by: Lyude Paul <lyude@redhat.com> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> > > Thanks for the modification, it seems to work. Great, thanks for testing! greg k-h
© 2016 - 2025 Red Hat, Inc.